[aprssig] APRS Message Idea

[Robert Bruninga]

>>> ad6nh at arrl.net 3/4/05 1:47:11 PM >>>
>You do not set the Bulletin and Announcement Intervals, 
>they are preset ...  You set a retry ONCE for ALL messages, 
>not for "*Each* and *Every* message".

Yep, that makes it even worse...
 Again, that is why such simplistic approach to communications
totally fails on RF in the field.  Each message line and bulletin 
line and announcement line has a different urgency!  And the 
urgency changes on a minute by minute basis as each line ages..

The two most common failiures of the simplistic fixed retry
and fixed interval method are as follows:

1) A new user sends an urgent announcement of immediate 
need to all stations at an event.  But only 2 stations get it 
the first time.  The next RETRY is 30 minutes later!!!
By then the urgency is over and your comm system FAILED.

2) Or, you train users to change their defaults to every minute
for rapid real-time delivery.  Now your event fails because
each station that sends any message traffic routine, 
or immediate, all keep sending everything every minute.
Your event fails from total overload of retries... of OLD data!
Or it times out and you don't get delivery while the guy is
out of his truck...  Again, your comm system FAILED to
deliver real-time info reliably..

>All of your arguments listed below are frivolous,...

Delivering new, urgent data quickly and not congesting
the channel with older retries at the same rate is not
frivilous.  It is fundamental to good human communications
design.

>and I'm kinda getting tired of hearing you blast the program 
>that  I doubt you have ever loaded on your computer and 
>looked at. 

Wrong. we planned our annual event here to use it,
everyone wanted to use UIview because they "heard it
was the greatest thing since sliced bread".  Fortunately we 
did a trial run the week before..  It was an absolulte failure 
for all the "frivilous" reasons I have noted before.  Remember, 
this was a real RF event.  It was a dozen or so stations all 
trying to keep track of 30 different companies of Students 
throughout  a day long event.    Lots of objects, lots of
messages, and lots of bulletins and announcments.

The lessons learned clearly, even by the most die-hard
users were that the fixed-rate algorithm for messages,
objects, bulletins and annoucnements  was abismal.
There was NO SETTING that would work.  It was 
either too high and the channel was hoplessly overloaded
and everything was not reilable due to congestion, or if 
they set the rate lower, then there was way too much 
latency.  Bulletins messages and announcemnts never got 
through in any reasonable time..

The only way to make it work was to agressively 
manage the rate in real time and to change it before
and after each new object or message or bulletin.  
Which anyone with a clue to what happens in a real 
event is the last kind of burden you want to put on your 
operators.  We abandoned it for the real event..

>We're just not going to switch back to DOS and run 
>dosARPS anymore!

Im not asking you to.  Im just warning everyone about
the dangers of these simplistic algorithms used by
many new clones of APRS that make no effort to manage
the network and the flow of data in real time...

>I'm sorry, but blasting the usefulness of the software is 
>going to do nothing but turn people off from APRS 
>completely. 

Im not trying to blast it.  I am only pointing out the significant 
weaknesses of the simplistic fixed-rate-fixed retry, no-smart
-ack systems used by some software.  And how performance 
at a real-time RF event is *drastically* reduced if said software 
is used for lots of bulletins, messages, and objects.  If all you 
use it for is to watch mobiles, or to message over the internet
you wont notice these problems.

But at all events that I am involved in, APRS is one of the 
primary station to station communications system and it consists
of a lot more traffic than just watching the mobiles drive around.

> In the spirit of amateur radio, please pre-read your 
>responses before you hit the send key.  Thank you kindly.

Sorry, but users need to not be blind to these shortcomings 
which will have drastic affects on their use of APRS in the
field if they plan on using it for messages, bulletins, and
lots of objects... (one of the primary missions of APRS, to
keep everyone informed in real time of everything that is
going on)...

de Wb4APR, Bob

Robert Bruninga wrote:

>>>>ve7gdh at rac.ca 3/3/05 11:35:58 PM >>>
>>>>        
>>>>
>>... those of us using UI-View32 know... it's close to ..perfect! 
>>...[user settings for] retry interval, number of times to try, 
>>retry on heard,  expire time, bulletin intervals of 2, 10, 
>>20 minutes announcement intervals of 2, 5, 10, 20, 30 ...
>>    
>>
>
>Ah, but that is the problem!  
>
>You list 6 user settings that have to be set to match the 
>specific immediate  NEED of *Each* and *Every* message 
>or bulletin or announcement.  The potential for comms failure
>due to human error is magnified tremendously  due to total 
>dependence on user detailed settings for each and every
>line sent:
>
>1) users not knowing what to set when they need it
>2) Users forgetting what they set and abusing the channel
>3) Having to change it all the time for each and every
>    instance of message, and announcemnte and bulletin.
>4) NOT changing it so that routine bulletins are treated
>    identically to UREGENT ones and adding QRM when
>    you can least afford it...
>5) No discrimiination between new immediate info and
>    old less important info without user line-by-line intervention.
>
>Imagine the consequence of a 2 minute announcement that 
>goes on for 3 hours of a Marathon!  Or an URGENT bulletin
>that someone enters that goes out once (and is lost due to
>collision) and then doesnt go out again for 30 minutes!!!!!!
>
>All becuse of a user interface and proliferation of options 
>caused by the simple failure to implement the original APRS 
>Decay algorithm which was specifically designed to *avoid* 
>all those problems:
>
>1) There are no user settings to screw up
>2) There are no user settings needed to get max performance
>    (the Decay algorithm always gives immediate and redundant
>    ( access)
>2) New info gets immediate channel access and retries
>    (without dependence on user settings)
>
>3) Old info gets less and less channel access but good followup
>    (without dependence on user settings)
>
>4) Important  Announcements get immediate urgent delivery
>    (without dependence on user settings)
>
>5) Routine Bulletins gets delivered with minimal QRM
>   (without dependence on user settings)
>
>Notice that with the Decay algorithm, there is no need for 
>any user settings because there is nothing a user can do 
>to improve his chances of delivery:  He already gets retries 
>almost immediately when the data is new, and he gets
>routine follow up for ultimate delivery, all while reducing 
>QRM to a minimum.
>
>Thus you get the best possible performmnce in the middle 
>of a crisis and you get the best possible channel sharing 
>during routine operations and  NOTHING is dependent 
>on ANY user settings or errors.
>
>On the other hand, software that requires the users to set 
>up to 6 different parameters on every message line or bulletin 
>or announcment and then having to manage  each line's
>parameters until delivered or canceled is about as far from 
>"perfect" as I can imagine...  
>
>The simplistic approach of fixed retries on fixed intervals
>just simply cannot provide both rapid initial delivery
>and efficient channel sharing without constant human
>intervention on a line-by-line basis. 
>
>The Decay algorithm does exactly both, about as best as
>possible and is totally automatic, and independent of user
>settings completely.
>etc.....
>
>de WB4APR, Bob
>
>
>_______________________________________________
>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