[aprssig] APRS Message Idea
Robert Bruninga bruninga at usna.eduFri Mar 4 18:39:24 UTC 2005
- Previous message: [aprssig] Re: TH-D7AG Battery life
- Next message: [aprssig] APRS Message Idea
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>> 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
- Previous message: [aprssig] Re: TH-D7AG Battery life
- Next message: [aprssig] APRS Message Idea
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
