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

[A.J. Farmer (AJ3U)]

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
> 
> 
>