APRS-IS depends very much on a timestamp created at the time that a record from an iGate is received.
Very few stations transmit a timestamp in the packet header even though accurate time is usually available when the GPS provides valid position data.
So in a network where packets are carried through many digipeaters (a result of the end user supplying an inappropriate PATH), and many of these digipeaters having several iGates listening, there is a need to weed out duplicates.
The mechanism to discard duplicates falls down when the duplicate submission is delayed significantly, and some network infrastructure is notorious for latency.
Here are a set of sequential APRS-IS raw records for VK2HJ-9 that demonstrate the issue.
- 2014-08-25 08:32:54 EST: VK2HJ-9>S4S5Q9,VK2RHR-1*,WIDE1*,WIDE2-1,qAR,VK2NR-5:`N-[qR_>/”;S}
- 2014-08-25 08:33:05 EST: VK2HJ-9>S4S5P8,WIDE1-1,WIDE2-1,qAR,VK2OMD-3:`N-lqR?>/”;S}
- 2014-08-25 08:33:33 EST: VK2HJ-9>S4S4W9,WIDE1-1,WIDE2-1,qAR,VK2OMD-3:`N.-qRZ>/”;;}
- 2014-08-25 08:34:23 EST: VK2HJ-9>S4S4T2,WIDE1-1,WIDE2-1,qAR,VK2OMD-3:`N.jp>F>/”;3}Dom from Goulburn
- 2014-08-25 08:35:12 EST: VK2HJ-9>S4S4Q4,WIDE1-1,WIDE2-1,qAR,VK2OMD-3:`N//n*L>/”;1}
- 2014-08-25 08:35:59 EST: VK2HJ-9>S4S3X9,WIDE1-1,WIDE2-1,qAR,VK2OMD-3:`N/WqHh>/”;,}
- 2014-08-25 08:36:12 EST: VK2HJ-9>S4S5Q9,VK2AMW-1,VK2RTM-1*,qAR,VK2YGV-5:`N-[qR_>/”;S} [Location changes too fast (adaptive limit)]
- 2014-08-25 08:36:14 EST: VK2HJ-9>S4S4Q4,VK2AMW-1,VK2RTM-1*,qAR,VK2YGV-5:`N//n*L>/”;1} [Location changes too fast (adaptive limit)]
aprs.fi flags record 7 above as defective because location changed too quickly, but if you look, record 7 is a duplicate of record 1 but delayed by more than 3min.
Likewise, record 8 is a duplicate of record 5, and the delay is only 1min, but submitted just 2s after record 7
Records 7 and 8 are effectively corrupted because they report positions at an incorrect time, and a track with those positions included is corrupt.
It appears that VK2YGV-5 has blocked sending records for some time, then unblocked and flushed the stored up records, albeit with significant delay. Delays of over 10min have been observed in traffic passing through VK2YGV-5 .
These are classic symptoms of some form of flow control not working properly.
VK2YGV-5 has a huge catchment from Lismore to south of Canberra and west of Dubbo, and figures in most of the delayed duplicates for NSW posits.
Kantronics and flow control
The Kantronics TNCs have a reputation for a fault that causes this kind of latency, and a common ham recipe is to restart them periodically.
This may or may not be VK2YGV-5’s problem.
The KPC3+ provides for XON/XOFF flow contol (XON/XOFF), but this MUST NOT be enabled for KISS mode, and KISS mode passes arbitrary binary data across the KISS link and if XON/XOFF is enabled, the link will be blocked by an XOFF byte.
So, fundamentally, the issue with KPC3+ is an operator error in configuration, but Kantronics could have protected their reputation against incompetent setup by not honouring XON/XOFF when in KISS mode.
But fundamentally, lack of monitoring by iGate operators of traffic which passed through their station to identify defects results in these problems going uncorrected.