Order Tray | Contact Us | Home | SIG Lists

[aprssig] UI-View - one source of delayed packets?

Mark Conner n9xtn at cox.net
Mon Oct 24 23:06:08 UTC 2005


I did a little checking into N0YXV's situation where "delayed packets"
appeared on the APRS-IS.  In this case, none of the packets were digipeated
and presumably heard direct by the respective Igates.  Here is the data:

20051021014102,WY0F-9>APT311,WIDE2-2,qAR,N0YXV-1:/210141z4054.08N/09824.98Wk
359/042/A=001919/TinyTrak3
20051021014311,WY0F-9>APT311,WIDE2-2,qAR,N0YXV-1:/210143z4055.54N/09824.99Wk
360/046/A=001899
20051021014438,WY0F-9>APT311,WIDE2-2,qAo,WY0F:/210144z4056.36N/09824.98Wk090
/017/A=001899
20051021014500,WY0F-9>APT311,WIDE2-2,qAo,WY0F:/210144z4056.37N/09824.76Wk015
/013/A=001902/TinyTrak3
20051021014516,WY0F-9>APT311,WIDE2-2,qAR,N0YXV-1:/210145z4056.46N/09824.77Wk
299/009/A=001899
20051021020831,WY0F-9>APT311,WIDE2-2,qAO,KC0MWM:/210141z4054.08N/09824.98Wk3
59/042/A=001919/TinyTrak3
20051021020845,WY0F-9>APT311,WIDE2-2,qAO,KC0MWM:/210143z4055.54N/09824.99Wk3
60/046/A=001899
20051021021313,WY0F-9>APT311,WIDE2-2,qAO,KC0MWM:/210144z4056.36N/09824.98Wk0
90/017/A=001899
20051021021515,WY0F-9>APT311,WIDE2-2,qAO,KC0MWM:/210144z4056.37N/09824.76Wk0
15/013/A=001902/TinyTrak3
20051021021517,WY0F-9>APT311,WIDE2-2,qAO,KC0MWM:/210145z4056.46N/09824.77Wk2
99/009/A=001899

Note that the first five packets were received in a timely fashion, then
appeared again about a half-hour later from the KC0MWM I-gate.  So I checked
the I-gate's data:

20051021013937,KC0MWM>APU25N,TCPIP*,qAC,KC0MWM:=4056.00N/09822.09W-PHG3230
Roger-Grand Island, NE {UIV32N}
20051021020829,KC0MWM>APU25N,WIDE1-1,qAR,N0YXV-1:=4056.00N/09822.09W-PHG3230
Roger-Grand Island, NE {UIV32N}
20051021020843,KC0MWM>APU25N,TCPIP*,qAC,KC0MWM:>180207z[KC0MWM at ARRL.NET]

This would seem to indicate KC0MWM's UI-View program restared around 0207Z
and dumped those five repeat packets onto the APRS-IS, presumably from the
TNC's serial buffer.  

APRS+SA appears to get around this problem by not connecting to the internet
for about 30 seconds after startup (I always wondered why it did that).
That gives it time to read in the buffer, but not hand it off to the
internet.  Can UI-View be set to do the same?

In any case, this points out a probable case of delayed packets not due to
digipeating delays.  

This is posted not to whiz on any operator or program, but to help
understand the problem.  

73 de Mark N9XTN







More information about the aprssig mailing list