<div dir="ltr"><div style="font-size:12.8px"><span style="font-size:small">On Thu, Jan 21, 2016 at 4:03 PM, Martin Nile via aprssig </span><span dir="ltr" style="font-size:small"><<a href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a>></span><span style="font-size:small"> wrote:</span><br style="font-size:small"><blockquote class="gmail_quote" style="font-size:small;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>If you wish a full forecast<br></div><div>add the word "full" to your "where" and "when".  The full forecast is spread across</div><div>multiple APRS message.  The default "brief" forecast usually fits within a single</div><div>message.</div></div></blockquote></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">If possible, I'd encourage you to implement flow control on outgoing bursts of packets destined to a single station. I know that at least in APRX I enforce a token bucket that prevents more than a few packets ever getting RF-gated for a single station at once. I know some people have complained on this list before about these sorts of systems that return a burst of a dozen packets and the end user is only ever able to get a few of them because the local RF-gates drop most of the flood.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Something as simple as "Sleep 2 seconds after each packet" would be an easy start. Since you mentioned that this is single threaded, I assume you're not sending messages with message numbers which you track and re-transmit.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<br></div></div>