One of Packet's problems is that it was more-or-less abandoned in the mid 90's when the World Wide Web came along. So the only stuff that one can get for this mode is of that vintage.
APRS on the other hand uses Packet Radio and is very successful. But still there are few to none turn key kits available for this variation of Packet.
It would seem that I'm not the only one thinking that this should be easier. I went looking for a TNC (Terminal Node Controller) that I could attach to the USB port of my computer. This was a mammoth task in itself. With newer machines leaving "legacy" connections behind, Ethernet and USB are the order of the day now. No more serial ports.
Then I happened upon SP9UOB's dsTNC. It is a dsPIC (a PIC that does DSP). It has all the makings of a low cost, easily constructed TNC. It can do 1200bd (the current data speed) and has aspirations on 9600bd with a firmware change.
|SP8UOB's original drawing|
Looks simple right? Problem is that it has a "proper" serial port. No USB. That I can fix. I've been doing lots of stuff with the FT232 USB-Serial converter chip lately so I added on to this design.
|My version of the TNC|
|The PCB I designed|
|The test board|
But I don't want to use it for APRS. I want to use it for normal Packet operations. In support of this the device supports the KISS mode. This mode allows the user to operate the device in a manner not unlike a normal modem; the attached computer will do all the work.
It does NOT work! Well, that's not quite true. It does support KISS and works just fine if all you want is an APRS modem. But a TNC is more than a modem. It has a CPU, RAM,Modems etc. What I found was that if the passing data packets were of a certain length they would be decoded. If they were shorter or longer they would not be decoded. This is flat no use with normal Packet operations.
After much gnashing of teeth and questioning of known working equipment I tracked down the problem. The firmware was not correct. The "TNC" part was not there.
I advised SP9UOB of my findings and he in turn sent me a patched version of his firmware. Indeed this worked - sort of. I could now decode passing data of any size but if the data was too long it would arrive garbled or even be missed altogether. SP9UOB has not selected the correct micro processor part and so it did not have enough RAM to store/decode the passing data. So it still doesn't work as I'd hoped it would.