Order Tray | Contact Us | Home | SIG Lists

[aprssig] APRS Message Idea

Robert Bruninga bruninga at usna.edu
Thu Mar 3 14:21:39 UTC 2005


>>> ajfarmer at spenet.com 3/2/05 11:43:36 PM >>>
>With APRS, when you send a message ... the software ...
>tries a number of times..., then gives up if the receiving 
>station does not ACK...

No that is only the simplistic way some new "aprs" software
works.  The original design tries on a decaying algoirthm
for rapid initial delivery, but less network load after a few
minutes.  But then it decays down to one retry every 30
minutes until the station eventually comes on the air.

>The problem is, if you are messaging a far away station, 
>you don't know if they are actually active on APRS [at] 
>the particular moment that you send the message.

With APRSdos the message will always eventually get
delivered.  Also some programs (WinAPRS etc) added
"retry-on-heard" so that the message will still be there 
until the station eventually comes on the air, and then
retries will continue...

> With cellular, the message gets delivered as soon as the 
>person gets back in range, with APRS, sorry, you missed 
>the guy by a few minutes...

No, just with simplistic "aprs" clones that never properly
implemented the full APRS decaying algorithm packet 
delivery system.  Original APRS software's work fine.

>I know this was not the original design or intent of APRS, 

Yes it was.  Justs some follow on softare clones took
too many shortcuts in the protocol and overall functional
features of APRS while being focused only on maps..

>but what do you all think of enabling this type of store 
>and forward capability? 

It should have been in all code.  But everyone tires of me
ranting  on these kinds of omissions in some present programs...

> This system could be separate from the standard "tactical" 
>"type of messaging currently used. 

Not needed to be separate...  The Decay algoirhtm covers 
ALL cases and requires NO user settings.  It works for rapid 
10 second message turnaround over good channels, and 
multiple retries over bad ones, and eventual delivery over long
periods of time.  ANd users cannot screw it up, or overload
the netowrk by chaning any settings.  Its automatic, its
fundamental and it is what APRS was designed to do.

Its just that too many other programs just took the simplistic
and very channel innefficient apprach of retry N times and
stop.

>What do you all think?   Already available somehow?

Yep, always been there, but only implemented in APRSdos,
WinAPRS (retry on heard), APRS+SA, APRscs and
maybe some I dont remember.

de Wb4APR, Bob




More information about the aprssig mailing list