[aprssig] "Out-of-order" data on APRS-IS

Mark Conner n9xtn at cox.net
Mon Aug 8 20:42:31 EDT 2005

Here is an interesting, though not completely unusual, situation where
packets seem to get to FindU very late.  Below is an extract from the FindU
raw.cgi for my wife's APRS tracker (FindU accessed at 1523 UTC):


Note that at 14:56:14, FindU logged a posit that was actually sent at
14:52:31 and was originally logged to FindU at 14:52:32 (1 sec later).  The
second logging was after a delay of 3 min 43 sec.  

This packet did traverse 3 digipeaters but certainly in less than 3 min 43
sec.  I'm assuming the delay is between KC0QWN-10's antenna and the FindU
database.  Where this delay is occurring I'm not sure about.  

I'm also assuming that delays like this, while infrequent, occur often
enough to be a problem.  I see this on several balloon flights where I use
FindU to extract the data and multiple I-gates are on the balloon frequency.
At least one I-gate will be logging from 3 to as many as 10 minutes late
through the entire flight.  This is where no digipeaters are used, so all
reception at the I-gates' antennas are simultaneous to within milliseconds.
With time-stamped packets, it's possible to characterize this delay to an
accuracy of within a few seconds.  

As I recall, dupe filtering at the APRS-IS servers compares a just- received
packet to the one previously received for that station.  However, if the
delay is on the order of a few minutes, it's possible for the above
situation to happen where a delayed report ends up replacing the correct
"latest" report transmitted.  How difficult would it be to extend the dupe
filtering to compare against all packets received from a station for the
past few minutes?  I know it's not as simple as the present method, but how
difficult would it be?  

73 de Mark N9XTN

More information about the aprssig mailing list