[aprssig] "Out-of-order" data on APRS-IS

[James Washer]

I don't know whether or not this is true, but I want to congratulate you on a BRILLIANT ANALYSIS... Nice job.

 - jim

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.
> 
> 73!
> 
> A.J. Farmer, AJ3U
> http://www.aj3u.com
> 
> 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
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig