I have written about duplicate position records assigned different timestamps in the APRS – APRS-IS – archiver network, and the corruption of mapping as a result of false timestamps which causes zig zags in the mapping.
Most recently, I demonstrated that at APRS – APRS-IS latency.
I have been challenged that this just does not happen.
As a by product of developing code to circumvent the defects in the design and implementation, I have been running a rover stationary on the driveway during the day to supply test data to the filtering code, and of course these exceptions have occurred.
Here is an extract of the raw packets log from aprs.fi for just one case.
2016-01-26 16:20:25 AEDT: VK2OMD-8>APT314,WIDE1-1,WIDE2-2,qAR,VK2OMD-3:/052024h3429.91S/15027.12E>110/000/A=002263
2016-01-26 16:23:17 AEDT: VK2OMD-8>APT314,VK2RHR-1,WIDE1,VK1RGI-1,VK2RWG-1,WIDE2*,qAS,VK2KAW:/052024h3429.91S/15027.12E>110/000/A=002263
Inspection will reveal that both records have the GPS derived timestamp 052024h, and the message contents are identical, they are both a result of a single posit report at 052024UTC, the relay via VK2KAW has been assigned a timestamp some 173s (almost 3m) later and were the rover moving, this corrupted report would cause a track back and the next valid report would leap forward.
In six hours of operation, there were 36 posits transmitted, and 11 corrupt posits via VK2KAW logged by APRS-IS, that is 31% of valid posits have a false and corrupted posit generated in the wider network.
APRS fails by design, the core infrastructure does not detect these anomalies and discard them. Note that this scenario is ONLY provable because the tracker sends the HMS format timestamp… which almost no-one does.
This is only one source of corruption of posits, vulnerability to this one is designed into APRS, but it is detectable and fixable in core infrastructure.