[aprssig] "Out-of-order" data on APRS-IS
washer at trlp.com
Tue Aug 9 12:31:37 CDT 2005
I don't know whether or not this is true, but I want to congratulate you on a BRILLIANT ANALYSIS... Nice job.
On Tue, 09 Aug 2005 13:18:24 -0400
"A.J. Farmer (AJ3U)" <ajfarmer at spenet.com> wrote:
> The problem could be a digi with a improperly set or malfunctioning squelch.
> The digi could be buffering packets and holding them for some time until
> its squelch indicates the frequency is clear. At that time it would
> dump everything in its buffer back out onto the frequency.
> Just a possibility.
> A.J. Farmer, AJ3U
> AE5PL Lists wrote:
> >>-----Original Message-----
> >>From: Mark Conner
> >>Posted At: Tuesday, August 09, 2005 9:51 AM
> >>Subject: [aprssig] "Out-of-order" data on APRS-IS
> >>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.
> > Look to RF. I have seen TNC's delay transmission over 35 minutes (there
> > is a Kantronics KPC3+ in Oklahoma that was doing this a couple of weeks
> > ago and may still be doing it, for instance)! While it is obvious by
> > your own analysis that this packet traversed a different RF path, you
> > still think this lies in APRS-IS. It doesn't. Look to the RF path when
> > these problems occur and you will likely find your problem.
> > There are two instances where we have seen excessive delays in APRS-IS:
> > improperly configured servers causing delayed loops through their local
> > environment (RF path will normally be the same in this case) or someone
> > uses older software and replays a log without disconnecting from RF and
> > APRS-IS. The first issue has been eliminated with javAPRSSrvr as it
> > does not allow those configurations. Non-javAPRSSrvr servers may still
> > exhibit this problem although there are no issues currently pointing to
> > a specific server configuration.
> > The second issue caused an admonition to be issued to everyone to be
> > sure that they disconnect from both RF and APRS-IS before replaying logs
> > in their clients.
> > Bottom line: Your initial analysis of a separate RF path was a good one.
> > Don't ignore it. The problem in all likelihood resides there, not in
> > the APRS-IS.
> > 73,
> > Pete Loveall AE5PL
> > mailto:pete at ae5pl.net
> > _______________________________________________
> > 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
More information about the aprssig