Zig zags in APRS tracks

There are many causes of zig zag errors in APRS tracks, and they fall generally into two main categories:

  1. incorrect positions (ie the tracker was never there); and
  2. correct positions with incorrect timestamps.

The first is common and has a number of causes, but principally defects in software used in iGates, most of which is not maintained either by the iGate operator or original developer. APRS is pretty static, but most old software has significant defects.

The second category is again common, and mostly the result of the design of the APRS radio network and its vulnerability to network delays (some of which can be caused by defective equipment).

This article looks at a case in the second category where a vehicle appears to have done a U-turn on the highway, travelled back some distance then another U-turn and caught up their original track speed at the next posit. It is clearly an out of order packet. This article shows how to diagnose the cause from the raw packet log for the tracker.


Screenshot - 30_10_2015 , 08_36_44

Above is a map of the glitch that is not uncommon in APRS for one of several reasons. No, VK2HJ has not done U-turns on the highway, the zig zag track is incorrect.

Here are the relevant raw APRS records for VK2HJ-9 at that time.

If you examine the detail of these records (scroll right), you will see that there is a packet rejected at 07:41:59 because of rate limiting, but the same packet passes through the radio network and is resubmitted by VK2ASY-1 more that 220s later and it is not recognised as a duplicate of the earlier one (probably due to a quite long delay), and is accepted by the network and allocated a timestamp more than three minutes later than when it was originally transmitted… hence the zig zag.

Packets can be delayed by a digi that for one reason or another has an open squelch blocking the transmitter  for an extended time, and when the squelch finally closes, the digi sends all the packets it has buffered. Similar delays are caused with some iGate TNCs where flow control is incorrectly used and the data flow is choked off for an extended time. What is an extended time? I commonly see bursts of packets up to 2000s old.

Even if VK2HJ's packets were timestamped (which usually means very accurate time from the GPS), the network would not use the timestamp in duplicate detection or to discard stale posits.

The further packets are carried by digipeaters, the longer delay and the more opportunity for corruption or delayed packets being assigned an incorrect timestamp.

If you want an accurate and reliable track record, do not depend on APRS over radio.