Information on Installing USB Drivers for Apple and Linux

The Apple drivers can be downloaded from FTDI's Driver page . Linux drivers are supposedly now built into the kernel, though information on this driver is also available on the FTDI driver page.

TNC-X has been assigned the product ID (PID) of EBE0. All DLP USB modules that are supplied by me will have this PID burned into them. If you install the Apple drivers or use the Linux drivers built into it's kernel, you will have to configure them so that they use EBE0 as the PID. I have not tested TNC-X with either Apple or Linux operating systems and would be very interested in hearing from you if you have done so. If you run into problems, please contact me (john@hansen.net) for assistance.

A Note for all DLP-USB module users:

The KISS mode protocol specifies that no flow control be used (either hardware or software). However, some software that supports KISS mode tries to implement hardware flow control (WinTNC is one example). To accomodate this, it may be necessary to connect the RTS and CTS lines of the DLP-USB module together in order for it to work with some software. The procedure for doing this if you are using TNC-X's native serial port is described in the TNC-X manual. However, if you are using the DLP-USB module, this can be accomplished simply by shorting pins 21 and 22 of the DLP-USB socket. If you find that you are using the USB port and the unit receives fine but never transmits, jumpering these pins will probably solve your problem.

Linux Installation Hints from Dave Platt, AE5EO: (thanks, Dave!)

First-off - you're correct in that one does need to patch the Linux kernel sources in order to be able to use the USB module.

I've included a patch for the 2.4.22 version of the kernel (the one I'm using on most of my systems) down
at the end of this message. Patch, configure the kernel for USB support, USB serial converter support, and the
FTDI converter, recompile, install kernel and modules, and reboot. With this patch in place, the TNC-X is recognizedupon device plug-in and becomes /dev/ttyUSB0 (usually).

Second: the RTS/CTS hardware flow control issue exists even
when using the USB adapter. Linux seems to default the
hardware flow control feature to "enabled" when the USB drivers
are installed and bind to the device. The Linux "kissattach"
driver, used to bind the AX.25 network socket to the serial
port, does not disable RTS/CTS handshaking (although I suppose
it should, given what you say about the KISS spec). The software workaround for this is quite simple, fortunately.
In whatever AX.25 startup script one uses, one should simply
add the line

stty --file /dev/ttyUSB0 -crtscts

just before running

kissattach /dev/ttyUSB0 $PORTNAME $IPADDRESS

This will turn off RTS/CTS handshaking in the driver before
starting the KISS protocol, and eliminates the "can hear but
cannot speak" problem.

Suggestion #1 for your next PC-board spin (if you do one):
add a trace between pins 21 and 22 of the DLP footprint, to
loop back the RTS signal to CTS.

I've found (as have many folks) that the Linux USB support
is somewhat "iffy". There are a number of known race conditions
in the drivers and core logic. One of them can be triggered if
you unplug the TNC-X while it is in use, and then shut down the
"kissattach" process. On my system, this results in a kernel
"oops" in the USB hub support code... I believe that the
USB device structure is being accessed after it was already
closed and released by the hub logic. This doesn't crash the
system, but it does hang the "kissattach" process permanently.
The only way out is a reboot.

I've encountered another problem which I believe is probably
due to an interaction between the TNC-X design, and the
hardware I'm using it with, and (likely) the Linux kernel.
The TNX-C seems to work reliably when connected to one of
my HTs, running on battery power. However, it does _not_
work reliably if I connect it to a KDK 2-meter mobile,
running on my station's linear voltage supply. The
symptom is a USB error - the Linux kernel reports a USBinterrupt with the ERROR bit set in the host-controller status
register. This sometimes occurs when the TNC-X keys up the rig
(even at only 5 watts into a dummy load), and can even occur the
moment I plug in the cable to connect the TNC-X to the rig.
Once this error occurs, I cannot either receive or transmit
data to/from the TNC-X, unless I shut down its USB drivers and
reload them.

My guess at this point is that my setup is suffering from a
ground loop problem of some sort, and that currents caused by
a voltage differential are glitching the USB circuitry (eitherthe DLP, or the USB host controller in my laptop). I'm not sure
why the system doesn't recover from this - it may be a "crash" in
the DLP, or a driver bug in Linux.

I've checked for a DC voltage between the KDK ground, and the
TNC-X (with the cable between then disconnected)... there's
perhaps a few tenths of a volt of noise floating around,
but nothing severe. The system's reaction to this is worse than
I would have expected, but it seems quite consistent.My second suggestion, for any future TNC-X that you design, is to
move to a situation with full electrical isolation between the
computer and radio sides of the interface. This approach has
been quite successful for the sound-card-to-radio interfaces
(e.g. RigRunner, Rascal, and numerous homebrews) - it helps avoid
RF and noise problems, ground loops, and so forth. What I'd
suggest would be that use a couple of 1:1 audio isolation
transformers (for RCV Audio and TX Audio). Also, change
R18 to 1k, and replace Q1 with a 4N32 or similar Photodarlington
optoisolator. Return the radio sides of the 4N32 and the
audio transformers to a new (isolated) radio ground point which
goes out to the radio jacks/cable.

diff -u -r linux-2.4.22-orig/drivers/usb/serial/ftdi_sio.c linux-2.4.22/drivers/usb/serial/ftdi_sio.c
--- linux-2.4.22-orig/drivers/usb/serial/ftdi_sio.c 2003-12-29 11:13:20.000000000 -0800
+++ linux-2.4.22/drivers/usb/serial/ftdi_sio.c 2003-12-25 19:47:05.000000000 -0800
@@ -251,6 +251,7 @@
{ USB_DEVICE_VER(FTDI_VID, FTDI_XF_632_PID, 0, 0x3ff) },
{ USB_DEVICE_VER(FTDI_VID, FTDI_VNHCPCUSB_D_PID, 0, 0x3ff) },
{ USB_DEVICE_VER(FTDI_VID, FTDI_DSS20_PID, 0, 0x3ff) },
+ { USB_DEVICE_VER(FTDI_VID, FTDI_TNC_X_PID, 0, 0x3ff) },
{ USB_DEVICE_VER(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID, 0, 0x3ff) },
{ USB_DEVICE_VER(FTDI_MTXORB_VID, FTDI_MTXORB_1_PID, 0, 0x3ff) },
{ USB_DEVICE_VER(FTDI_MTXORB_VID, FTDI_MTXORB_2_PID, 0, 0x3ff) },
@@ -316,6 +317,7 @@
{ USB_DEVICE_VER(FTDI_VID, FTDI_XF_632_PID, 0x400, 0xffff) },
{ USB_DEVICE_VER(FTDI_VID, FTDI_VNHCPCUSB_D_PID, 0x400, 0xffff) },
{ USB_DEVICE_VER(FTDI_VID, FTDI_DSS20_PID, 0x400, 0xffff) },
+ { USB_DEVICE_VER(FTDI_VID, FTDI_TNC_X_PID, 0x400, 0xffff) },
{ USB_DEVICE_VER(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID, 0x400, 0xffff) },
{ USB_DEVICE_VER(FTDI_MTXORB_VID, FTDI_MTXORB_1_PID, 0x400, 0xffff) },
{ USB_DEVICE_VER(FTDI_MTXORB_VID, FTDI_MTXORB_2_PID, 0x400, 0xffff) },
@@ -392,6 +394,7 @@
{ USB_DEVICE(FTDI_VID, FTDI_XF_634_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_XF_632_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_DSS20_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_TNC_X_PID) },
{ USB_DEVICE(FTDI_NF_RIC_VID, FTDI_NF_RIC_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_VNHCPCUSB_D_PID) },
{ USB_DEVICE(FTDI_MTXORB_VID, FTDI_MTXORB_0_PID) },
diff -u -r linux-2.4.22-orig/drivers/usb/serial/ftdi_sio.h linux-2.4.22/drivers/usb/serial/ftdi_sio.h
--- linux-2.4.22-orig/drivers/usb/serial/ftdi_sio.h 2003-12-29 11:13:20.000000000 -0800
+++ linux-2.4.22/drivers/usb/serial/ftdi_sio.h 2003-12-25 19:50:50.000000000 -0800
@@ -113,6 +113,12 @@
#define FTDI_DSS20_PID 0xFC82

/*
+ * TNC-X USB-to-packet adapter
+ */
+
+#define FTDI_TNC_X_PID 0xEBE0
+
+/*
* Home Electronics (www.home-electro.com) USB gadgets
*/
#define FTDI_HE_TIRA1_PID 0xFA78 /* Tira-1 IR tranceiver */

Back to USB Install Page