AmateurRadio.com

I have been playing around some more with the WB8WGA PIC TNC that I built. While it was quite fun to see what it managed to decode and have it working as a digipeater, I eventually wanted to get it talking to some real software. UI-View is supposed to be able to work with TNCs in Converse mode, so that was going to be the easiest thing to try. But in order to do that I needed to solve the problem of the firmware expecting a linefeed to terminate a command.

That problem turned out to be fairly easy to solve, though I ran into some problems by trying to make some other changes. The trouble with working with microcontrollers, at least when using assembler, is not just that they don’t have much memory but it isn’t an a seamless block and you have to take care of memory management. Consequently I found that adding one line of code could make the difference between the program compiling and getting an error on the lines of “you are writing to a location that has already been written to.” I’m a high level language kind of guy who expects the compiler to take care of all this for me. I suspect that major modifications to the code like adding KISS support is going to be beyond me.

Anyway, I managed to get it so that UI-View could make its various settings and put the TNC into Converse mode. I had to get rid of the message that comes up on entering Converse mode because it often clashed with UI-View sending a beacon. I then set some IS to RF gating options to generate a lot of traffic and found that the TNC kept going back into command mode. This appeared to be due to the timeout timer that throws you back into command mode if you start to type something and don’t hit Enter. This was a pretty annoying feature, quite apart from interfering with reliable operation, so I had to take that out, too.

It seemed like the TNC was ready to go. But although it would transmit beacons from UI-View perfectly well, the program would not display any received stations. I could see the decoded packets in UI-View’s Terminal window, but they never appeared on the map anywhere. I did some searching and found one complaint about this in the Fox Delta Yahoo! group (the Fox Delta Mini TNC is apparently based on the same firmware) but no solution.

There did not seem to be anything wrong with the packets and I spent a couple of hours trying various things to see if I could establish what the problem was. Eventually I hooked UI-View up to my Kenwood TM-D710 in packet mode and watched what happened. Packets were received and displayed as expected. So then I connected a terminal program to try to see what the received packets looked like. (This is Windows HyperTerminal with a special Terminal-Hex font that shows the hex value of non-printable characters.)

This is what the output from the Kenwood TNC looked like:

and this is the output from the PIC TNC:

As you can see, the only difference (apart from the fact that the PIC TNC is displaying the packets as it digipeated them while the Kenwood heard both the original and the digipeated versions) is the text UI or UI R in angle brackets before the colon that marks the start of the payload part of the packet. It doesn’t look like something significant enough to make UI-View ignore the packet. It isn’t something that appears in the raw packets listings at aprs.fi. I don’t know what it means or how to generate it in the output from my TNC. So I’m stumped at the moment and am hoping that someone who knows the answer will read this and point me in the direction of a solution.

One Response to “PIC TNC problem”