Thursday, February 03, 2011

PIC TNC problem

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 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.


Lynn (D) said...

I have read something about "relaxed" checking somewhere in UI-View's host mode configuration settings? Maybe that makes it more forgiving of the lack of in the packet?

Have you tried hooking it up to APRSIS32? Given that packet format, if those come out all the time, APRSISCE/32 will be able to at least receive and display them.

And, when in CONV mode, I'm assuming that there's MYCALL and UNPROTO .... VIA .... that need to be sent before the CONV command? And Ctl-C takes you out of Converse mode? If that's all true, there's a possibility that a future CONVERSE mode port in APRSISCE/32 will support that TNC for all but software-based digipeating.

Unknown said...

Yes, a Converse mode port would do the job nicely. Thanks for the tip of trying APRSIS32. It works in Kenwood(APRS) mode on receive only, after an OpenCmd to put it into Converse mode.

A simple Converse port could just rely on the user script to make the right settings and get it into that mode. UI-View doesn't seem to take it out of Converse mode once it is in there. Gated stuff goes out as a third party packet using the set mycall and unproto settings.

Unknown said...

Lynn. Thank you for pointing me to the "relaxed" checking in Ui-View. That did solve the problem. It does however raise a question. The UI-View help says: UI-View needs to see frame headers that include frame type information, e.g. "". In certain exceptional circumstances this information isn't available, and so UI-View will discard all frames unless you check this option. PLEASE NOTE - with any sort of normal TNC in terminal mode, or if you use KISS, BPQ or AGWPE modes, you never need to use this option. This implies that this packet type info is normal output from a TNC in terminal mode. In order to be compatible with the forthcoming Converse port support in APRSISCE/32, do I still need to make my TNC output frame type information?

Lynn (D) said...

APRSISCE/32 already ignores this information if it is found in the Kenwood-specific modes. I do not plan to every require such information to be present.

I'm working on FTM-350 receive-only support and I need to ignore similar information in those packets (IIRC) in addition to recognizing and re-assembling a line-break between the packet header and payload.

Without owning all of these different TNCs, testing my implementation is going to be rather interesting to say the least. I foresee a bunch of configuration parameters governing the commands to send like MYCALL and UNPROTO VIA (or V) and so forth.

If only the world could standardize on KISS or at least offer a KISS-only firmware! The KISS packet contains the entire AX.25 header which includes the bits that some TNCs put in the <>.

The KISS, BPQ, and AGWPE modes all carry the fully encoded AX.25 header, hence the comment in the UI-View help file about not needing the "relaxed" option.

G4HYG said...

Hi Julian,

It's good to see someone else having a go at finishing the WB8WGA firmware. Which version are you modifying as there is a version 2 version of the firmware released by WB8WGA to fix some of the obvious bugs. While I was working on it about 18 months ago I logged all the changes I made and it came to well over 3000. The problem is that there is not much memory left to play with and it's a balance between making the necessary changes and improvements and having enough memory for it to work at all.

I also found that all of the hex code available on the internet with various mods was flawed with serious faults. One amateur had fixed the UI-View problems but had messed up the timing so that the audio tones on transmit and receive were 100's of Hz out. I contacted him to try and get it changed and offered to help him but he had given up on it and didn't want to start again! I don't blame him!

Have fun coding!


Chris, G4HYG

Unknown said...

Hi, Chris. I am working with the version 1 because I didn't need the temperature support and I thought it might be harder taking it out than starting with source code that didn't include it. I'll do a side by side with the version 2 code and see if I can spot any changes that might help.

I've had it running today with Ui-View for hours now. It also works fine on receive with APTSIS32. The only thing I still need to add if I can is flow control because lack of it can mess up gating to RF.