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

[Wes Johnston]

I've tracked packets that went thru UIView for an hour that were delayed
and mixed in with other packets all thru the hour.  I find it hard to
believe that UIView would have restarted so many times in an hour
(possible but improbable).  Although this is a good line of thinking,
and probably correct in this case, it doesn't explain what I saw a few
months ago... bummer.

As for preventing the buildup of sale data in the TNC's serial buffer, a
simple three wire serial cable will not support flow control, and the
TNC will continue to stream data out of it's buffer whether a program is
running or not.  A hardware solution for a software problem! ;-)  I
think it's pretty unlikely that we'll get Roger to make any changes to
ui-view.  He was sure helpful when he was around!

Wes



Mark Conner wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
> 
> 
>