Saturday, November 10, 2007

APRS parsing logic changes

Today I did two changes which were recently requested by users.

The first one was actually done last weekend, but it needed some more testing and cleaning up, so I only deployed it on the production server today. The MIC-E parser now accepts some forms of corrupted packets. There are a number of broken igates and digipeaters out there, which corrupt MIC-E packets which often contain non-printable, non-ASCII characters in the 0x1C-0x1F range. At least aprsd has this bug (there is a patch in it's bug tracking system which fixes it) - it replaces the characters with spaces (0x20), and it seems that some igates or APRS-IS servers then replace the spaces with a single space, so that the MIC-E data is really broken.

I've added a kludge which manages to parse the location from some of these corrupted packets. It's ugly, but it usually works. Replacing corrupted or missing data with something I've guessed is not a good idea, but this will have to do for a while.

The second one was pointed out only last night by Chris, K6DBG. The speed of a target is now calculated from the positions of the current packet and the previously transmitted packet, instead of the previously accepted and stored packet. This is significant, because packets indicating that the target is moving faster than 500 km/h are discarded. These are usually caused by corrupted packets, or bad GPS data. Some APRS trackers transmit their position even if the GPS clearly indicates that it has no valid fix. Sometimes the GPS suddenly gives out a single invalid point which is hundreds or thousands of kilometers away.

If the invalid position was the first one transmitted by the station, it was accepted and stored to the database, and it could take days (to move to the true position at 500 km/h) before a new correct position packet was accepted. Now, the second correct position packet is already accepted and stored.


ChrisK said...

Thanks so much for the quick fix!

VY 73 de chris K6DBG

Hessu said...

No problem, it was actually quite easy to do, and the increase in memory requirement wasn't too bad after all (need to store previous coordinates twice).

Anonymous said...


The D-STAR based APRS, DPRS, has been gradually becoming popular in the world. DSTAR uses not only digits but also alphabetical characters, such as A, B, and C, for SSID. Your system treats the callsigns with an alphabetical SSID as "Not valid AX.25." This is correct. They are invalid in terms of the AX.25 rule, but valid in terms of the APRS spec.

Is it possible to change your system so that the callsigns with an alphabetical SSID are also accepted and displayed on the map?

Thanks for reading.