20180119

Despite being a bit long in the tooth, my Coastal Chipworks TNC-X remains an effective design for allowing a PC to send and receive AX.25 packet data, especially for APRS. The design has varied little since John Hansen W2FS first described it at a TAPR conference in 2003. It remains one of my go-to tools for getting on the air quickly. I especially like that nearly any VHF receiver (including a humble analog scanner) can be patched into the TNC-X with just an "aux cord", without having to fiddle with level settings - just turn the volume up about half way, and go.

I purchased my TNC-X as a kit in 2006 (board revision 2.3, dated August 3, 2005), with the optional metal enclosure and USB module. Unfortunately, that USB module has proven to be problematic recently, when trying to interface with Windows 10.

The module in question is a package from Linx - part number SDM-USB-QS1-S, lot number 10001. Under the covers, this module is really an FTDI USB-to-serial bridge. Coastal Chipworks prepared this module for shipment by first mounting pin headers on its castellated package (for easy plug-in installation into the socket on the TNC-X circuit board), then programming the module with the USB ID identifying the device as a TNC-X.

This device ID, Vendor ID 0x0403 (the company ID for FTDI) and Product ID 0xEBE0 (unique to the TNC-X), proved to be both a blessing and a curse. By securing a unique ID for its product, Coastal was able to have the device appear under its proper brand name in Windows Device Manager and Linux USB tools, making for a very professional presentation to the user. Unfortunately, it also meant that operating systems did not understand that the ultra-common FTDI USB-to-serial adaptor drivers would work fine with this new device, as those drivers only knew to look for FTDI's standard-issue device ID (vendor 0x0403 product 0x6001).

The easy solution to this in 2005 was to provide special Windows drivers that knew to make this connection between the driver and the custom device ID. Under Linux, things were more complicated - enterprising hams had to do some kernel hacking to get their devices working over USB. A few years later the TNC-X device ID was included in the mainstream kernel driver for FTDI chips, allowing Linux to automatically match that driver to the TNC-X without any hacking.

The solution of using a custom driver package for Windows eventually led to a new problem. Starting with Windows Vista, Microsoft began requiring equipment manufacturers to prove that their gear worked correctly with Windows. If a device and its driver had not passed through Microsoft's extensive (and expensive) testing regimen, then Windows would present the user with nagging warnings about using risky drivers. Later, with Windows 7 and especially Windows 10, it was no longer possible to install unsigned drivers at all. Coastal Chipworks eventually decided that the thousands of dollars required to achieve qualification with Microsoft were better spent elsewhere; from that point onward, the Linx/FTDI USB modules for new TNC-Xes were shipped with the original, generic device ID for FTDI adaptors (0x0403:0x6001). This meant that the FTDI driver built into Windows would work fine, and no custom Windows driver was required.

Unfortunately, this new approach did not help me, as my TNC-X still used the custom device ID. After some digging, I found that it is possible to re-program the USB module to use the standard FTDI device ID. All of my Windows PCs were running Win 10, though, so I could not get the OS on any of these PCs to talk to the TNC-X to make the change.

After more digging, I was able to find an open-source program for Linux that could re-program FTDI modules. Because the Linux kernel driver for FTDI cables still knows that it can talk to TNC-Xes, all I had to do was plug my TNC-X into a Linux box, then use this program to change the product ID of my module to the standard value. If I could do that, then Windows 10 would think the TNC-X was just another FTDI cable, and I'd be able to get them talking again.

I downloaded the source code and dependencies to a PC running Linux, compiled the utility, and ran it against the ID of the Linx module, asking it to display the configuration values. No dice. It turns out that the utility could speak to the module just fine, but because it did not understand the meaning of all of the EEPROM values, it would not parse the contents into readable values. Even worse, it would not send the command to change the device ID, because it could not figure out where to put those values.

I eventually figured out that the utility would still happily do a blind read of the binary EEPROM values, and save those contents to a file without attempting to decode them. I did this, then used a hex editor to change the contents of the dump file to set the product ID from 0xEBE0 to 0x6001 (the values "EB" and "E0" only appeared in one place, right next to each other, and right next to "04" and "03", so I figured I was in the right place). I tried writing the hacked file back to the module, but that failed because the checksum value within the file was no longer correct. Thankfully, the utility spit out both the correct and incorrect checksum values as part of the error message. I used the hex editor again to replace the old checksum with the new values (again, the old checksum values only appeared in one place in the data). I crossed my fingers, and ran the utility again to do a blind write of the modified dump file back to the USB module. The utility did not understand what all of the contents meant, but it didn't have to - it just wrote the data to the module as instructed.

This worked exactly as I had hoped. After unplugging the USB cable to the TNC-X, waiting a beat, and plugging it back in, the TNC-X was now reporting a product ID of 0x6001, just like a vanilla FTDI USB-to-serial cable. I unplugged the cable from the Linux box, then connected the TNC-X to a Windows 10 PC, and viola! Windows loaded the FTDI driver immediately, and within seconds I finally had AGWPE connected to the TNC-X over USB on Windows 10.

DISCLAIMER:

When I downloaded and re-uploaded the memory dump from the USB module, I knew full well that I could end up bricking the Linx module. I had plenty of other options (including working USB-to-serial adapters), so losing the USB module would have been ok. In the end, my gamble worked out, and by re-programming the module I saved a few bucks. There is no guaranty that this will work for anyone else's specific situation, so caveat emptor.