[aprssig] Delayed packets

[mconner at aer.com]

I've run into this quite frequently when using FindU to retrieve stored data for previous balloon flights.  Almost all the time, these packets are received direct so no digipeating is involved.  When delays are found in the record, every case I've checked into involved a UI-View client that was the I-gate.  These delays can be as much as 10 minutes.

This does not conclusively prove that UI-View is the problem, or is the only problem.  However, this and other discussions are a strong indicator that UI-View does have this behavior in some configurations.

Interestingly, this behavior comes and goes with some UI-View I-gates.  One in our area did this for a few days, with the delays becoming increasingly longer.  After the I-gate's owner restarted the software (maybe computer, too), the behavior went away.

Everyone seems to want to point to another component of the system, resulting in a circular firing squad.  Unfortunately the real data to analyze this exists (perhaps only fleetingly?) at the core servers prior to dupe checking.  It would be interesting to analyze and flag this behavior so the problem can be characterized.

It might be possible to do this by logging even the dupe-filtered data.  Check for identical time-stamped payloads that have duplicate reports sent out by FindU.  TinyTraks transmitting hour/min/sec in the time field are excellent for this.  If two of these make it out of the APRS-IS to the clients some minutes apart, then check who entered the second report into the system and the digis traversed.

Another (uglier) fix is to perform more dupe checking at the core servers.  From a previous post, the dupe checking is limited to 30 seconds to allow repeat transmissions of messages through.  Could a longer filtering time be applied to posits only?  Something like 300 seconds would catch all but the most egregious cases.

I have been logging APRS-IS data for several weeks now, using Perl and Ham-APRS-Parser on sourceforge, to get an idea of digipeater coverages in the NE/IA/KS area.  If I get time, I would like to modify the logging to store my time of receipt (I don't get the FindU store time until I look up the posits on the web) and post-process the log files for these dupes.  Once found, then investigate the paths and I-gates involved to see if the issue could be a digipeater or an I-gate.

Here's an example from my own mobile (a TinyTrak 3) and the local area from today:

20060606170316,N9XTN-9>APT311,W0NWS-3,WIDE1*,WIDE2-2,qAo,K0HAM-2:/170313h4109.35N/09555.58W>008/041/A=001053
20060606170417,N9XTN-9>APT311,W0NWS-3,WIDE1,N0WKF-2,N0ORU-1,WIDE2*,qAo,N0AN:/170313h4109.35N/09555.58W>008/041/A=001053

20060606173851,N9XTN-9>APT311,W0NWS-3,WIDE1*,WIDE2-2,qAo,K0HAM-2:/173850h4107.87N/09555.42W>128/008/A=001059
20060606173927,N9XTN-9>APT311,W0NWS-3,WIDE1,K0HAM-6,N0ORU-1,WIDE2*,qAo,N0AN:/173850h4107.87N/09555.42W>128/008/A=001059

The top pair are separated by 61 seconds, the bottom by 36 seconds.  There are three points of commonality, the W0NWS-3 digi in Omaha (about 8 mi N of my mobile's location, a KPC-3 I believe), the N0ORU-1 digipeater (UI-Digi 1.9b1) in southwest Iowa, and the N0AN UI-View I-gate north of Des Moines.  W0NWS-3 is not a problem because in both cases the time of transmission through this digi to the K0HAM-2 UI-View I-gate to receipt by FindU is less than 3 seconds.  The dupe reports transit N0ORU-1 and N0AN, so the delay could be either one.  Further analysis of other stations would probably eliminate one or the other.  I would expect that in this area there would not be a flood of traffic causing a digi to "hold" traffic for 30 seconds or more two different times within a 40 min period.

I think this would be an interesting diagnostic exercise.  This could be speeded up by having this logging on hand already.  If someone has a way to provide me undecoded APRS-IS data with a time hack (similar to the FindU extract above), I may be able to speed this up.  If you have decoded data, I'll need to have path information (everything between the > and :) included.

73 de Mark N9XTN