[aprssig] Whazzuuuuuuuuup!

VE7GDH ve7gdh at rac.ca
Sun Jan 8 13:37:25 EST 2006

Wes KD4RDB wrote on Jan 8 2006

> I have seen similar problems with my tracker moving around town. I came
> to the conclusion that UI-View acting as an IGATE was delaying delivery
> of packets to TCP... I found that in each case a ui-view station would
> deliver a packet late anywhere from 120seconds to 500 seconds. It was
> suggested that the guy's internet connection was queuing packets but I
> found this hard to believe.

I have seen it in the Vancouver BC / Seattle WA area. To the best of my
recollection, in every instance that I looked into where this was happening,
a digi or IGate "way down" near Seattle was involved. I don't recall what
the IGate was using. The most reasonable explanation I had seen was that a
digi with a squelched radio had the squelch set too loose and it was storing
packets until the squelch closed.

See also the message from Richard  K0AEM from a few minutes ago where he
observed a nearby UI-View IGate delaying some packets but while the CPU was
being overwhelmed with (or at least concentrating on!) a print job.

> That leaves me with the "If it quacks like a duck" cliché.

Good one, but I'm holding out for a bit more proof before I will conclude
there is only one cause or only one APRS client that is introducing out of
order packets  - hi!. I think that any APRS client that hears a beacon will
gate it. The APRS-IS apparently takes care of dupes but only going back 30
seconds. UI-View32 has dupe checking, but to the best of my knowledge, it
only applies to beacons it is digipeating - not that it is gating.

73 es cul - Keith VE7GDH
"I may be lost, but I know exactly where I am!"

More information about the aprssig mailing list