Back on track, via the scenic route

The FoxTrak APRS tracker board is finished, and works, but I took the long way round getting there. Building the board was by far the easiest part of the project. Setting up and testing it was a trial of patience, ingenuity and lateral thinking.

After building the tracker it has to be programmed with your call and a few other options by connecting it to a computer and running some configuration software. The documentation was not specific and I was not sure if I could just connect it to a serial port. The tracker is just a 16F84A PIC which works at TTL logic levels, but a PC serial port produces RS-232 at +/- 12V. What's more, the FoxTrak website mentions a null modem adapter with MAX232 chip which is a TTL to RS-232 level converter, suggesting this might be required. However I had a USB to TTL serial adapter module that I bought some time ago for another project so I decided I should be able to use that. I did, and the configuration software was unable to detect the tracker.

After thinking about it for a few hours I decided to take a chance and use a normal serial connection. I used a Prolific USB to RS-232 serial adapter. That worked, and I was able to program my settings into the tracker.

The next step was to calibrate the tones produced by the tracker. 1200baud packet uses mark and space tones of 1200 and 2200Hz. Due to some hardware limitation of the 16F84A PIC, the tones are actually spaced about 1050Hz apart and the calibration software uses a default setting that puts them as near equally spaced over a centre frequency of 1700Hz as possible so the error in the generated tone frequency is shared equally between mark and space. To generate constant tones so you can measure them using a frequency counter you must connect to the tracker using a terminal program and send Esc T 0 or Esc T 1. I tried this using Windows HyperTerminal and nothing happened.

I now wasted quite a lot of time as I didn't know what was supposed to happen. I didn't know whether the PTT LED would illuminate when the test tone was produced so I didn't know whether the absence of a tone was because the PIC hadn't received the command to send it or some other reason. Eventually I decided that perhaps HyperTerminal wasn't talking to the tracker so I tried another terminal program called RealTerm. This time Esc T 0 immediately produced a nice waveform on my oscilloscope which also counted the frequency for me and told me the tones were within 1Hz of the documented frequency for the default calibration value. Good, or so I thought.

Now I wanted to feed the audio output into a radio and see if my Kenwood TM-D710 would decode the packets it produced. I had wired a push-to-make switch in the "Transmit Now" position but what I didn't know was whether the tracker would transmit a packet when it had no GPS data. I don't have a GPS I can use with it at the moment, but even if I had, I would have trouble getting a fix inside the shack due to the high electrical interference levels.

The tracker wouldn't transmit anything without a valid GPS fix, but it occurred to me that it must be possible to write a program that pretends to be a GPS and outputs NMEA packets to a serial port in order to test GPS applications. I didn't want to write such a program, but other people had the same idea and Google found me several GPS emulators. Unfortunately the so called "free downloads" required a fee of $30 to $40 to use them. Blow that, I'd rather spend that money on a real GPS receiver.

An enquiry on the APRS Yahoo! group and another few hours wait and I was pointed in the direction of two free GPS simulators: gpsfeed+ and NMEA Generator. With these I was able to send fake GPS positions to the tracker board. The GPS light came on, as did the PTT light whenever a position was sent. At last!

Around this point I wanted to change a couple of the settings I had programmed in to the tracker. I re-ran the configuration software and found that when I tried to write the new settings back to the PIC it failed with a mismatch error. Reading back the settings they were now corrupt. I could not seem to clear the problem and wondered if I had blown something up.

I tried another USB to serial converter, one with an FTDI chipset which is normally more reliable in transceiver control applications. That could not even detect the tracker board. Oh dear! As a last hope I tried the Prolific adapter again and, having in the process switched both the computer and the tracker off and on again it worked this time. It seems that if you are going to configure the tracker it's best to do it first before trying anything else. I was glad to have found a solution and that it was still working but I had wasted quite a lot of time getting to that point.

The next problem was getting the packets transmitted by the radio. I tried the Motorola GP300 first of all but for some reason it went into transmit as soon as I inserted the 2.5mm jack into the socket. So I tried the Kenwoods. Both the TH-F7E and its grandparent the TH-205E use the same type of connections. But on those I could not get PTT to work at all. I could really have done with some diagrams of how to wire up the tracker to these radios. I was, however, able to transmit some audio by manually pressing the radio PTT and then pressing the Transmit Now button on the tracker to send a packet. From this I was able to determine that no matter what audio level I used the TM-D710 would not decode the packets from the tracker.

I tried what must have been an infinite number of different level settings without success. Yet the tracker packets sounded exactly the same as ones I was receiving off-air which were being decoded. I remembered that I had the VX-8GR which also has a packet TNC so I decided to see if that could receive them. The Yaesu decoded the tracker packets over a wide range of audio level settings, even when the transmission was undermodulated. So what didn't the Kenwood like about them?

I decided to set up AGW Packet Engine to decode packets via my FT-817 which was conveniently connected up to a sound card. That decoded nothing either. Clearly something was wrong with the AFSK output from the FoxTrak board. Even though my VX-8GR could decode it, it was going to be of no use to me if its packets would not be decoded by my gateway.

Finally, on the basis that there was nothing left to try, I decided to try different calibration settings to vary the tone frequencies. After another fight with the serial adapters I programmed in a calibration value of 36 which should result in a mark tone of 1200Hz and a space of 2250Hz and was rewarded by beeps from the TM-D710 indicating that packets were being decoded. They were also appearing in the monitor log of the AGW Packet Engine. The VX-8GR was still decoding them, too. Success at last!

I am relieved that it works after all this effort. Now all that remains to be done is to acquire a serial GPS, figure out the radio PTT connections and box the FoxTrak up with a suitable battery pack to make it into a usable unit. That will take a while, since some of the bits and pieces (including the GPS) will be coming from China.

It is interesting that the calibration setting which resulted in the best decoding is one farthest from the default, which does not place the mark and space tones so that the difference between the actual and the correct tone frequencies is equally spaced between them. A few months ago I heard a mobile drive through the area beaconing on APRS and none of its packets were decoded. I wonder how many people build or buy these trackers - either the FoxTrak or the original TinyTrak which it is a clone of - and leave the settings to default not realizing that they are unintelligible to many radios?