[aprssig] APRS Message Idea

[Phillip B. Pacier]

Um... no, Bob.

You do not set the Bulletin and Announcement Intervals, they are preset 
according to the APRS Spec on those message types.  You select one like 
you would in WinAPRS or whatever else supports it.

You set a retry ONCE for ALL messages, not for "*Each* and *Every* message".

All of your arguments listed below are frivolous, 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.  We're just not going to switch back to 
DOS and run dosARPS anymore!  I'm sorry, but blasting the usefulness of 
the software is going to do nothing but turn people off from APRS 
completely.  In the spirit of amateur radio, please pre-read your 
responses before you hit the send key.  Thank you kindly.

73
Phil Pacier - AD6NH
http://www.aprsca.net

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