[aprssig] EchoLink APRS-IS Ojbects Mothballed

[Keith VE7GDH]

Bob WB4APR wrote...

> For delivering real-time message data, nothing beats the
> original APRS decay algorithm,
>
> TX once, then 8 seconds later, then 16, 32, 64, 128 and (in this
> application), stop there and quit.  This gives you 5 retries in
> a minute and then it shuts up.

Actually, that's 4 mins and 8 seconds - hi!

> This was how APRS was supposed to work. Too bad many popular clients 
> ignored these fundamentals and just implemented simplistic 1 minute 
> retries...

I'm not familiar with other APRS clients, but UI-View does a pretty good 
job with retries. It allows you to set the retry interval and how many 
times to try, and whether to "retry on heard" (if you hear the station 
again) and whether to expire and stop after X minutes. The retry 
interval must be at least double the number of times to try... e.g. set 
the retry interval to 10 seconds, try 5 times, and "retry on heard" and 
to never expire if you enter zero minutes, or e.g. expire in 60 minutes 
or whatever. No, it isn't an 8, 16, 32, 64, 128 second algorithm, but it 
would try 5 times over a 50 second period and then shut up until the 
other station is heard again. I don't have to wait 4 minutes and 8 
seconds to find out that I didn't get an ACK, and it doesn't keep trying 
forever.

If I told UI-View to retry 10 times, the retry interval couldn't be any 
shorter than 20 seconds.

If I told it to retry 100 times, the retry interval couldn't be any 
shorter than 200 seconds or 3 mins and 20 seconds. Obviously, setting it 
to values like this wouldn't lead to either quick delivery or quickly 
letting you know the message hadn't been delivered.

Your 8, 16, 32, 64 and 128 second algorithm has a nice binary ring to 
it, but it isn't necessarily better. It's just different.

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