In another forum topic, a fellow club member recently asked me about APRS tracking, clients, and messaging. I started this topic to keep the topics separate and make it easier for others to join in.

To start, I'm not a fan of APRS tracking. APRS, when based on a shared, 300baud, AX25 packet channel with digipeaters, is just not the right tool for tracking. When you push APRS into that role, it floods the channel and ruins it for everyone. APRS is good for locating, but tracking is a different idea. This might seem like splitting hairs, but in practice it isn't.

When using APRS for locating, you set your system to beacon far less frequently, but more predictably. The other station rarely needs to know exactly what route you took between beacons (that is what tracking is about), so tight settings with Smart Beaconing or Genius Beaconing are really not needed in the vast majority of situations. A regular beacon every five to ten minutes is often more than adequate. This approach also gets away from the decay rate problems of Smart / Genius Beaconing. That approach can lead to such long delays between beacons (e.g. if you are not moving) that your last beacon gets old and disappears from other operators' screens. So, I am a fan of using our typical 2m APRS infrastructure for locating, but not so much for tracking.

With that out of the way, the two APRS software applications that I use most often are APRSIS32 and YAAC. These two packages both offer very full APRS functionality, implementing almost all aspects of the APRS specification. That can make them intimidating at first, as there are dozens of options and parameters that you can set to get exactly the experience that you want. APRSIS32 is Windows based and still sees the odd update, but seems to get less attention in this aspect than YAAC. YAAC is Java based and boasts a published API that other programmers can use to contribute new functionality. I have not noticed a huge performance difference between these two packages, despite YAAC running on the JVM interpreter. Your mileage may vary.

I mostly use APRSIS32 for portable / mobile use. It has more flexible options for maps and that can be very helpful at service events. It also handles objects and items more intuitively, albeit in a rather awkward way that I wish the author would consider improving. This application handles messaging well and implements the bulletin board function in what seems to be a reasonably correct way. Again, though, I wish the author would consider some user interface improvements, as it can be awkward to maintain these functions over the duration of an event.

There are several other popular APRS packages. Few of them seem to implement the entire APRS specification, though. If anyone has another favourite, please post your thoughts about it. 

Configuring any of the APRS software applications is a frustrating experience. This can be even more complicated if you need to use an external TNC. Read up on the material available on the Internet, then get a coffee (I suggest decaf), and then just be very patient and persistent. it will work eventually.

As for hardware, I don't have much Yaesu equipment. I have heard that Yeasu has a peculiar way of implementing the firmware for APRS that can make it easy to receive, but not so simple for transmitting. Often an external TNC is needed (e.g. Mobilink), and this just complicates the situation. I have been using almost exclusively Kenwood equipment for APRS. Kenwood seems to have implemented APRS more intuitively and completely. 

I hope that this helps.