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

[Stan Coleman [NØYXV]]

Don't know about UI-View haven't played with it and a buffer from a TNC. I do
know that from my experiences with Javaprssrvr and a PK-88 that the PK-88 will
hold all data untill something connects to it. When I've been testing and the
TNC has been running for a while and the program hasn't I always connect to the
TNC first with a terminal program (like Hyperterm but for Linux) and let the TNC
"Drain" it's data out before reconnecting the program. Now I don't know exactly
how much data was in the TNC (would very based on local traffic) but it looked
to me like it was a couple of days. In other words while I was testing I left
the radio and TNC on and turned off Javaprssrvr. Left for a weekend and came
back on Monday to finish. First thing I did was to "Drain" the TNC before
reconnecting to the internet. Looked to me like the whole weekend (low traffic
in our area) had been buffered in the TNC. Can't say for sure because the data
went by too fast and I didn't bother to capture it.

Looks to me like you could get "stale" data almost anytime you have to turn
either the computer or program or both off for even a couple of minutes.

--
visit us online at
www.gihams.org


Quoting Ron Stordahl <ron.stordahl at digikey.com>:

> Mark Conner wrote:
> >
> > 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?
> >
>
> Yes.  You can set any delay you wish before reconnecting to the internet
> using file/schedule_editor.  The format is "+nnn" where the delay is set
> in minutes.  I would guess most users have it set at 1 minute (if they
> read the user docs).
>
> But I wonder if the buffer you refer to ever gets flushed...if the tnc
> does hardware flow control and is full, perhaps the data just stays
> there until it is read?  Lengthening the delay may do no good.
>
> Ron, N5IN
> >
> > 73 de Mark N9XTN
> >
> >
> >
> >
> > _______________________________________________
> > aprssig mailing list
> > aprssig at lists.tapr.org
> > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> >
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>