[Xastir-dev] UIview object transmission vs APRSdos (fwd)

[Curt, WE7U]

On Fri, 30 Apr 2004, Curt, WE7U wrote:

> Forwarded from the APRSSIG mailing list.  Xastir acts like UI-View
> in this respect.  We need to change this operation at some point.

Implemented in Xastir now with respect to objects/items.  Should be
in anon CVS later today.  The decaying algorithm used in APRSdos now
applies to Xastir for objects/items.

The code still needs to be tweaked to add the decaying algorithm to
messaging.  I'll try to get to that soon.  It should improve
keyboard to keyboard messaging quite a bit to switch to this
algorithm.

My thoughts are to skip this decaying algorithm for the station
location.  That would cause the station to appear more quickly when
it first comes up on channel, but that's the only advantage I can
see.  Agree?

--Curt, WE7U


> ---------- Forwarded message ----------
> Date: Fri, 30 Apr 2004 11:10:33 -0400
> From: K3for at aol.com
> To: TAPR APRS Special Interest Group <aprssig at lists.tapr.org>
> Subject: [aprssig] UIview object transmission vs APRSdos
>
> We were planning on using UIview for our next scout
> event to keep track of about 50 troops as they moved
> from place to place at a big camporee.
>
> The plan was to simply have several laptops running
> UIview with a local map and then as we learned
> of the movements of troops via FRS, Voice, D7's or
> grapevine or 'whatever', a few APRS operators would
> click on the troop ICON and move it to the new location.
>
> This way all screens throughout the venue (maybe even
> WEB pages for the event) would always be updated.
> Unfortunately, we discoverd that UIview appears to perform
> a rudimentary and prohibitive transmission algorithm like
> WinAPRS used that would make it impossible to do this on this
> scale without total gridlock on the channel.
>
> We abandoned UIview and went back to APRSdos, which nicely
> uses (I thought) the original APRS "new-info-quickly/old-info-
> decays" algorithm.  This causes the movement of any
> object to quickly and reliably be updated on every
> screen while older objects  take up less and less air
> time.
>
> In APRSdos, if you move an object, it is transmitted
> immediately, then 16 seconds later, then 32, then
> 64 then 2 minutes then 4 then 8 then 16, etc...
> (if it has still not been moved since then).  So in the 30
> minutes since that troop moved to its new station,
> only 9 packets were required... yet, it had 4 chances
> to be delivered to everyone in the first 90 seconds.
>
> Compare this to the simplistic fixed rate approach:
>
> APRSdos will average 9 packets per 30 minute per
> troop or 0.004 of channel capacity.  With 50 troops, this
> is about 20% channel capacity and perfect for the
> APRS ALOHA channel. (Theoretical 36% with
> CSMA) and allowing other capacity for the buses
> and other moving GPS stations which do report
> every minute...
>
> Clients that use the fixed rate approach
> to give say 5 retries in 5 minutes will require
> THREE-TIMES as many packets (one per minute
> for 30 minutes) and will clog the channel.
>
> Further, it appears that UIview transmits all of its objects
> at once.  Even if you set to say only
> every 3 minutes and each of the main PC's is tracking
> 16 troops, then once every 3 minutes you get this
> minute long burst of objects.   An ALOHA channel
> where statistically everyone shares the channel cannot
> afford this kind of bulk transmissions...
>
> If anything in the above is inaccurate, or can be fixed, please
> let me know.
>
> Skip
> K3FOR