owenduffy.net

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.

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.

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. Continue reading APRS – APRS-IS latency