Backtracking in APRS

Always interesting to look at glitches on APRS maps and investigate the cause. In this case, a local NMEA log provides evidence that the APRS track is faulty.

googleearth 14/11/2015 , 12:18:38 Google Earth

Above is an image of a track, red is from APRS and blue from a local NMEA capture.  Two ‘backtracks’ are evident on the red trace and not on the blue trace, they are artifacts of the design of APRS.

A small set of contiguous raw records from the findu database.


These records contain a timestamp from the originating GPS. Examining the timestamp, it is clear that record 3 is a duplicate of record 1, and record 7 is a duplicate of record 5.

The duplication is due to the posits submitted by VK2KAW which were not very stale, but accepted by the APRS core even though they carry a timestamp which would reliably expose the duplicates.

In this case, the duplicate posts were repeated by VK1RGI-1 located over 200km from the first digipeater VK2RHR-1.

The raw record of a packet repeated by VK1RGI-1 shows defects in the processing of the packet, it should have been heard at VK2KAW as


… more defective infrastructure.

APRS is exposed to radio propagation issues, and attempts to minimise that loss by providing multiple parallel paths for posit submission, but is not very clever in filtering out duplicates caused by this mechanism.

Source routing contributes to the problem. If intelligent digis did not repeat packets with paths that were very likely to have already been captured by an iGate, it would reduce the chance of duplicate submission and reduce network traffic. In this case, VK2RHR-1 is monitored by four or more iGates, and there is no need for any digi to repeat its traffic.

The result of the ‘design’ is a service that is of only novelty value in terms of reliable track data.