[aprssig] APRS Message Idea

[Keith - VE7GDH]

Bob WB4APR wrote on March 04, 2005 10:39 AM

(Oops... glad I caught the typo before sending it. Only one O in Bob! My spell checker didn't catch it. Good job there was human intervention. It could have been embarrassing!)

(I said... )
>>... 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 ...

(and you said...)
 
> 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:

No. It is just the APRS messages that I can set the retry interval, the number of tries, whether to retry on heard or not, and whether to expire the message or not. I don't know if I'm a control freak or not, but I kind of like the idea of being able to fine-tune the settings. I also don't happen to believe that just because the settings they are adjustable, there will be human error each time. If someone wants to avoid human error, they should stay off amateur radio, stay away from APRS, and probably not leave the house. Better stay in bed too.

> 1) users not knowing what to set when they need it

I like to think that I know how to use programs that I use. It is by using it that I become familiar with it.

> 2) Users forgetting what they set and abusing the channel

Some users of the highways forget the settings and drive too fast or bump into things. Most people don't.

> 3) Having to change it all the time for each and every
>    instance of message, and announcemnte and bulletin.

Nope. I set the message settings once and leave them unless I perceive a need to change them.

> 4) NOT changing it so that routine bulletins are treated
>    identically to UREGENT ones and adding QRM when
>    you can least afford it...

Gee whiz... I don't think I have ever considered any of my messages urgent. Maybe I should look into how to send an urgent message.

> 5) No discrimiination between new immediate info and
>    old less important info without user line-by-line intervention.

Ummm... if it's me entering the message, I would kind of know if it was any more important than anything I had previously sent. At a glance, I can also tell if any previous messages have gone un-acked. No matter how important I deem a message to be, it isn't going to help it get delivered. It is usually a matter of channel loading and whether the other station is within range of me or a digi that I can get to.

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

You mean if someone goofs? Sure, anything is possible. You must be talking about a scenario where there is no communications available to let the sender know about the goof. An urgent bulletin that goes out once and not again for 30 minutes? I would have to be pretty STUPID to do that. Why do you assume that APRS users are stupid? I give them more credit than that.

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

Here is what I found when I searched the APRS spec for "decay"... one and ONLY one mention of it. It doesn't say anything about "I have to use a certain" way of handling the timing. It just describes the various methods available.

(quoted from APRS spec)
Packet Timing: Since APRS packets are error-free, but are not guaranteed delivery, APRS transmits information redundantly. To assure rapid delivery of new or changing data, and to preserve channel capacity by reducing interference from old data, APRS should transmit new information more frequently than old information.

There are several algorithms in use to achieve this:
Decay Algorithm - Transmit a new packet once and n seconds later.
    Double the value of n for each new transmission. When n reaches the net
    cycle time, continue at that rate. Other factors besides "doubling" may be
    appropriate, such as for new message lines.
Fixed Rate - Transmit a new packet once and n seconds later. Transmit it x times and stop.
Message-on-Heard - Transmit a new packet according to either algorithm above. If the packet is still valid, and has not been 
acknowledged, and the net cycle time has been reached, then the recipient is probably not available. However, if a packet is then
subsequently heard from the recipient, try once again to transmit the packet.
Time-Out - This term is used to describe a time period beyond which it is reasonable to assume that a station no longer exists or is off the air if no packets have been heard from it. A period of 2 hours is suggested as the nominal default timeout. This time-out is not used in any transmitting algorithms, but is useful in some programs to decide when to cease displaying stations as "active".
Note that on HF, signals come and go, so decisions about activity may need to be more flexible.
(end of quote)

I think the point you were trying to make was that UI-View didn't do "decaying algorithm" for the sending of messages. You are right, but it doesn't stop me from sending messages. I know when a message has been acked or not. I know where the other station is or at least where they were last heard. I'm capable of knowing whether to wait until they show up again or if I need to deliver it by other means. Also (I hope) capable of deciding if I should be sending an announcement or a bulletin instead of a message.

> 1) There are no user settings to screw up

Maybe we should all become appliance operators with no chance to alter any settings? Kind of goes against the grain of amateur radio. Last time I looked, many hams were builders and experimenters and liked to have the ability to be able to adjust settings. If we screw up, it's too bad. Maybe we'll do better next time.

> 2) There are no user settings needed to get max performance
>    (the Decay algorithm always gives immediate and redundant
>    ( access)

I'm not going to argue whether a decaying algorithm works better or not, but I will argue that I am capable of analyzing the situation and know if there is a reasonable chance that the destination station should have received the message or if there is some reason why they wouldn't... such as looking at their last heard position. Did they just disappear behind a mountain, or perhaps reach their destination and go QRT? If I have a message set to go perhaps 5 or 10 times, I'm familiar enough with the program that I'm using that I know how to intervene if I have to... or just leave it with my usual setting of "retry on heard"... one of the methods mentioned in the spec.

> 2) New info gets immediate channel access and retries
>    (without dependence on user settings)

If I have a new message, I'll send it. Seems pretty simple. The only thing that would prevent me from sending it would be if there was an earlier message that hadn't been acked. I could over-ride the program and tell it to send it anyway, but that would be a human decision. If I thought the message was so important that I should try and send it even if an earlier message hadn't been acked yet, then I would try sending it.

> 3) Old info gets less and less channel access but good followup
>    (without dependence on user settings)

I hear what you are saying, but if the frequency is so clogged with traffic that messages aren't getting through and you aren't receiving acks, maybe the sender should consider other options. 

> 4) Important  Announcements get immediate urgent delivery
>    (without dependence on user settings)

I keep hearing this word "important". Whether the message is important or not won't really have any influence on the probability of it being delivered.
 
> 5) Routine Bulletins gets delivered with minimal QRM
>   (without dependence on user settings)

Seems to me that routine messages would have an equal chance of being delivered.

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

Seems to me that I would decide whether to send a message to a particular station, or whether to send an announcement or a bulletin. I am smart enough to decide which to send, aren't I?

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

To get the best possible performance in the middle of a crisis... good job there are humans involved. I think too that I'm capable of deciding (if I think that it's a crisis) whether I should "depend" on an APRS message being delivered. If APRS is the appropriate means to deliver the message, I would use it. If I really thought the message was important, I would make sure that it wasn't the only method of delivery that I had available. It would just be one of the tools available to me and I would use if I thought it was the right one to use. If I don't get an ack, I don't know that it was delivered. If I get an ack, I know it was delivered. If I get a reply, I will know that someone actually saw it.

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

I know several thousand of people that are capable of adjusting the settings you are referring to. Some of them are over on the UI-View list. Some are probably on this list too. Again, you don't seem to know the difference between messages, announcements and bulletins. I seem to recall sending a copy of the UI-View help file to you at your request about a week back. I think you will find most of what I am referring to in there.

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

Works for me. I just don't see any reason why a decaying algorithm will increase the chance of it being delivered. Perhaps it might have a better chance in the first few tries IF the recipient was in range and heading out of range. Once they are out of range, a fixed or decaying rate isn't going to make any difference.

> 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

I'm not saying that a message sent with a decaying algorithm for the timing isn't going to be delivered. If we were actually going to argue about it, the only thing I would really be wondering about would be whether the "decaying algorithm" message sent every 10 minutes or whatever the final rate is would have any better chance of being delivered than when the other one with fixed timing was re-sent when the station was next heard. Again, I would send the message via APRS if I deemed it the most appropriate way to send it. If it was really important, I would attempt to deliver it by other means if I didn't know for sure that it was received. If it was REALLY REALLY important, I would probably want to talk to someone to make sure that they followed my instructions implicitly. Wouldn't want the recipient to screw up and not completely understand my important message.

73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"