<div dir="ltr"><div><div><div><div><div><div><div><div>Why LIVE APRS messaging does not work for many, yet can work very well for those that use the messaging feature properly.<br><br>Capitals for emphasis (not shouting)...<br><br>APRS operators must understand that ACKS in packet radio are much less reliable than outgoing messages. THis means four rules for live APRS messageing:<br></div><br></div><div>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***)<br><br></div>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.<br><br></div>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).<br><br></div>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.<br><br></div>*** 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.<br><br></div>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.<br><br></div>Live by these rules and dialogs on APRS messaging between clients that support the embedded REPLY-ACK function will FLY.<br><br></div>Bob, WB4APR<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 12:06 AM, John Bloodgood <span dir="ltr"></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div dir="ltr">
Bob, <br> <br>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.  <br> <br>v/r<br> <br>John Bloodgood, KD0SFY<br>Colorado Springs, CO<br> <br> <br>            <br>                                       </div></div>
</blockquote></div><br></div></div>