[aprssig] APRS messaging issues

[Robert Bruninga]

Why LIVE APRS messaging does not work for many, yet can work very well for
those that use the messaging feature properly.

Capitals for emphasis (not shouting)...

APRS operators must understand that ACKS in packet radio are much less
reliable than outgoing messages. THis means four rules for live APRS
messageing:

1) Turn off all automatic REPLY messages.  Those are a travesty to APRS and
should NEVER be routinely enabled!  They were only there for one purpose
(elaborated later***)

2) [combine with #3] Live operators should always SEND a human response to
every incoming message immediately.  (and NOT those stupid automatic REPLY
functions).  This human reply has a far greater probability of getting back
to the sender than the ACK.

3) [combine with #2] Senders should look for human response to any/all SENT
messages and cancel/kill them without waiting for an ack (since they can
see the other station got the message by #2 above).

4) PC APRS Operators should use APRS clients that have implemented the
REPLY-ACK algorithm that automatically includes embedded ACKs in outgoing
messages (see #2).  THis multiplies the probability of the sender getting
an ACK (embedded in the reply message) instead of waiting for a
stand-alone, bandwidth hogging ACK.

*** The ONLY reason the original APRSdos had an automatic REPLY function
was for live operations when a station was expecting incomming traffic but
had to step away from his post momentarily and did not want the net to be
confused by his real-time lack of response.  THe operator could set a REPLY
message, something like "QRX till 10:20" or something.    BUT THIS REPLY
FUNCTION WAS AUTOMATICALLY DISABLED as soon as the operator returned and
the PC detected ANY operator action (mouse movement or any key pressed).
THus an AUTO REPLY could never be left ON and forgotten.

SO, the #1 problem with live APRS messages are all those confounded and
USELESS auto REPLYS that re turned on.  If you see someone using them.
please try to explain that they are of NO ROUTINE VALUE and only DAMAGE the
network.

Live by these rules and dialogs on APRS messaging between clients that
support the embedded REPLY-ACK function will FLY.

Bob, WB4APR

On Tue, Jan 6, 2015 at 12:06 AM, John Bloodgood  wrote:

>  Bob,
>
> Have you encountered APRS message floods before?  Every time we try to
> have a multi-station chat, the constant re-transmissions of messages end up
> choking the local bandwidth.  Some of it is from digi-peaters, but a lot of
> it appears to be stations repeating their own messages 3, 4, 5 times, even
> after receiving ACKs.  We would really like to leverage more than just the
> ability to track people and create objects, but experiments with messaging
> lead to nothing but frustration.  Tonight we had four stations messaging
> each other and within about 15 minutes the congestion from repeats was
> significant.  Within 30 minutes the frequency was almost unusable.
>
> v/r
>
> John Bloodgood, KD0SFY
> Colorado Springs, CO
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20150106/377fa67e/attachment.html>