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

[Mark Conner]

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):

20050808145209,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145207h4109.84N/09555
.57W>019/018/A=001076
20050808145221,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145219h4109.89N/09555
.54W>074/014/A=001059
20050808145227,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145226h4109.89N/09555
.51W>138/011/A=001056/
20050808145232,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145231h4109.86N/09555
.51W>177/024/A=001053
20050808145344,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145343h4109.38N/09555
.54W>108/020/A=001062
20050808145423,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145421h4109.35N/09555
.42W>040/012/A=001099/
20050808145430,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145428h4109.38N/09555
.41W>352/018/A=001089
20050808145454,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145452h4109.42N/09555
.35W>106/015/A=001095/
20050808145501,K9XTN-9>APT311,RELAY,WIDE2-2,qAo,N9XTN:/145459h4109.41N/09555
.32W>160/011/A=001102
20050808145614,K9XTN-9>APT311,K0BOY-1,WY0F-15,WB0WNX,WIDE2*,qAo,KC0QWN-10:/1
45231h4109.86N/09555.51W>177/024/A=001053

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