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

[Curt, WE7U]

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

--
Curt, WE7U			    archer at eskimo dot com
Arlington, WA, USA		http://www.eskimo.com/~archer
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

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