<div dir="ltr">Some more thoughts...<br><div class="gmail_extra"><br></div><div class="gmail_extra">On Sun, Mar 12, 2017 at 3:41 PM, K4FHK <span dir="ltr"><<a href="mailto:k4fhk@knobbe.us" target="_blank">k4fhk@knobbe.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The service has been changed today to use WHERE as the primary call<br>sign. I say primary since it will also accept messages on WHERE-IS,<br>WHERE-15, and still K4FHK-WI.</blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">If you're planning on using WHERE, why also support WHERE-IS and WHERE-15? I wouldn't really say it's been around long enough that you've got a large legacy user base on those SSIDs. I'd suggest just using WHERE and K4FHK-WI. Users would probably always prefer WHERE to WHERE-IS anyways, but it's up to you to support all four aliases and explain why in the future.</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that each result to wildcard queries will be handled with<br>individual APRS messages. So if someone has 15 active SSID's and you<br>query "where CALL-*", you will get 15 individual messages back.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">One thing that is often overlooked for -IS attached services which spawn multiple packets is that this won't work well for many RF users, for two reasons:</div><div class="gmail_extra">1. Many newer APRS modems are not tested against multiple packets back-to-back, so it isn't unusual to miss every other packet if you belch out a long string of them at once.</div><div class="gmail_extra">2. At least Aprx, if not other RF-gate/digipeater software packages, enforce Quality of Service (QoS) rules to protect the network from individual stations going bonkers. This means that your 15 packets will drain the token bucket in Aprx for the interface, and the last ten of them will be dropped instead of RF-gated.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The lack of any sort of queuing theory applied to APRS means that it is, on the RF side, very sensitive to traffic bursts, and not really possible to apply any sort of fair queuing methodologies. I've caught flak before for Aprx just enforcing a packet token bucket, but I stand behind Aprx dropping the 6th+ packet over an -IS node having the ability to tie up the local RF channel for an arbitrary length of time when it dumps a novel onto the APRS-IS in message form.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I suspect you'd see a better RF experience if you metered out packets at something like 3-5 second intervals from the source to allow the network to move each packet and the receiver to process each one sequentially. </div><div class="gmail_extra"><br></div><div class="gmail_extra">I do like the idea of WHERE, so please don't take me raising things you should look for as anything but helpful.<br clear="all"><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
<div class="gmail_quote"><br></div></div></div>