APRS – APRS-IS latency

A fundamental problem with APRS-IS is that archives assign a timestamp to a position report (posit) when the posit is received from the APRS-IS network. They do this even when the posit contains a timestamp which is almost always derived from the GPS and is quite accurate.

The archives such as findu.com and aprs.fi are not formally part of APRS-IS, but they are the visible interface to APRS-IS for many and are treated as part of the wider APRS-IS network in this article.

The APRS-IS network is designed to permit, encourage even, multiple submissions of the same originating posit via multiple iGates over multiple digipeater radio links.

You might expect that the maximum latency of two or three digipeater links might be a couple of seconds but not only is it ordinarily longer than that due to an overcommitted network, but defective infrastructure using old and misconfigured software can introduce much larger delays.

The effect of delayed duplicates is that they create false back and forth zig zags in a track, and make the mapping hopelessly inaccurate.

For this article, I will use data gained from a recent 100km rural trip using VHF APRS. For all of the trip, the rover was in range of a prominent digipeater which is monitored by many iGates, and for about half of the trip, the rover was in working distance of one of the iGates. About 200 posits were captured by APRS-IS, and they have a GPS derived HHMMSS timestamp.

Lets look at the latency.

Clip 114

Above is a chart of the difference between APRS archive timstamp and the GPS timestamp. A very large number of posits takes more than a couple of seconds to reach the APRS-IS archives.

Clip 115

The frequency distribution above shows that just 39% of posits take less than 3s to reach the findu APRS-IS archives, and a staggering 24% take more than 10s (and there are 5% greater than 100s).

By reprocessing the data to correct the APRS-IS arhive time using the GPS timestamp, it is found that there are only 146 unique posits, 54 or 27% are duplicates, and most of the long delayed posits are position reports which falsely map the rover at a location that it left often many minutes ago, and so the track hops backwards and forwards over the true track.

firefox 25/01/16 , 08:41:22 http://owenduffy.net/map/AprsDup.htm AprsDup - Mozilla Firefox

Above is an illustration of the mapping error caused. There are two transparent tracks shown, the light red track is the raw APRS-IS track, and the light blue track is using the reprocessed data with duplicates removed as described. The purple colour is where they are coincident (as they should be), where you see light blue or light red it is the result of APRS – APRS-IS – archive corruption of track data. The light blue track (and purple) is the correct track, and it has only 146 unique points against the red track which is 200 points, including 54 duplicate positions with inserted out of order due to delayed time stamps.

googleearth 25/01/16 , 18:38:46 Google Earth

Above is a comparison of the raw APRS-IS track in red, reprocessed APRS track in blue (and purple), and the cyan track is from a data logger capturing the GPS NMEA output.

You can browse an interactive zoomable map of the three tracks.

You might ask why the APRS-IS wider network does not use the HHMMSS timestamp where it is provided in a posit record, and why it then doesn’t use the unique key to delete duplicate submissions.