[aprssig] APRS Message Idea
Robert Bruninga
bruninga at usna.edu
Fri Mar 4 16:16:03 EST 2005
>>> ad6nh at arrl.net 3/4/05 1:47:11 PM >>>
>...I'm sorry, but blasting the usefulness of the software
>is going to do nothing but turn people off from APRS
>completely.
I wish people on this sig would not think that I am pushing
APRSdos (I published the source code. I only maintain it
for those users who still use it and find it invaluable for some
things...)
nor that I am denegrating software for any motive other
than I want APRS software that works and works well in
the field. It is very frustrating to me to hear and even see
and experience things like:
"APRS is too unreliable in real events"
"APRS is imposssible to use for real-time messaging"
"APRS chokes when there are too many objects"
etc.
When it is not APRS that is the problem, but a particular
implementation that didnt implement it properly. I am a user
of ham radio more than a programmer, I wrote APRS to
do what I have found to be the most immediate and
real-time things that are needed out in the field at real-time
RF events.
It is frustrating to me to see "APRS' not do the job it was
intended to do because of short-cuts taken in some software.
I point out all these shortcomings in the hope that other
authors will see the value of some of these features and
will include them in their software. To my knowledge, the
only software that tries to balance the urgent real-time
delivery while managing to share the network reliably
through the decaying algorithm for all packets and smart
acking for messages are:
APRSdos, XASTIR, APRS+SA and APRSscs.
But not enough people have used these nor have
tried to compare their software in real-time events with lots of
messages and bulletins and objects to notice the
difference.
Remember, I am only highlighting these problems so you
can avoid them in your system planning.. For example
if you have an event with lots and lots of moving objects
simply use one station for maintenance of the objects
using sofware with the decay algoirthm. Then everyone
else can use any software they want, because they receive
just fine.
If you have a few stations that will be doing most of the
messaging, use software there that does the decay rate
and smart acking... for the fastest througput and the least
load on the system.
Everyone else can use anything that can display the
event on the maps to their liking and everyone will be
happy... It's just useful to know in advance what works
better for what applicaiton and include it in your event
planning.
Bob
*-------------------------------------
Im not trying to blast it. I am only pointing out the significant
weaknesses of the simplistic fixed-rate-fixed retry, no-smart
-ack systems used by some software. And how performance
at a real-time RF event is *drastically* reduced if such software
is used [to transmit] lots of bulletins, messages, and objects.
If all you use it for is to watch mobiles, or to message over the
internet you wont notice these problems.
But at all events that I am involved in, APRS is one of the
primary station to station communications system and it consists
of a lot more traffic than just watching the mobiles drive around.
> In the spirit of amateur radio, please pre-read your
>responses before you hit the send key. Thank you kindly.
Sorry, but users need to not be blind to these shortcomings
which will have drastic affects on their use of APRS in the
field if they plan on using it for [sending] messages, bulletins,
and lots of objects... (one of the primary missions of APRS, to
keep everyone informed in real time of everything that is
going on)...
de Wb4APR, Bob
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
>
>
>
>
_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
More information about the aprssig
mailing list