Order Tray | Contact Us | Home | SIG Lists

[aprssig] APRS Message Idea

Robert Bruninga bruninga at usna.edu
Fri Mar 4 18:39:24 UTC 2005

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

de WB4APR, Bob

More information about the aprssig mailing list