<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 26, 2016 at 7:38 AM, Robert Bruninga <span dir="ltr"><<a href="mailto:bruninga@usna.edu" target="_blank">bruninga@usna.edu</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">➢ "Total length of logins/callsigns may not exceed 9 characters including<br>
the SSID if present."<br>
<br>
TNC callsigns are 6 plus up to 2 digit SSID and a hyphen.  But for anything<br>
else that can also be put on the map as an object or item the field is 9.<br></blockquote><div><br></div><div>I'm talking about APRS station callsigns which aren't using TNCs but are directly attached to the Internet. Pete clarified offline that my interpretation was correct; seven character callsigns with one character SSIDs and eight or nine character station callsigns with no SSID are acceptable.</div><div><br></div><div>This does mean that any software parsing callsigns from the APRS-IS can't rely on them being 6x2 in length. Check your buffer lengths everyone!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> 2. What is the minimum length for SSn-N aliases? Two? One? Probably two to<br>
> meet the APRS minimum of three when the 'n' is appended?<br>
<br>
</span>The minimum length of any callsign or object/item in APRS is 3 characters.<br>
SSn-N seems to work, Im not sure about how actual hardware digipeaters<br>
handle say Sn-N?<br></blockquote><div><br></div><div>I came to that realization that that 3 minimum dictated 2 char minimum for SSn-N. Aliases must be 2-5 characters.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> 5. Is GATE still a valid special handling token worth documenting and<br>
> supporting?<br>
<br>
</span>Only a dual Port TNC or other VHF to HF gateway needs to handle it.<br></blockquote><div><br></div><div>Woah... I thought VHF to HF digis weren't at all allowed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> Do HF stations requesting GATE actually want to land on everyone's VHF<br>
</span>> LANs...<br>
<br>
Aboslutely not.  That would be the worst operating practice.  Unless someone<br>
is calling MAYDAY, etc...  so leave it in.<br></blockquote><div><br></div><div>So we don't want regular HF to VHF traffic either? Only for MAYDAYs seems like an incredibly small use case for developers to write in support for GATE on multi-port digipeaters. Any of our 30m operators want to chime in with what they want these days? Is it good enough to have your own I-gates and rely on RF-gate routing for any cross-band capabilities? That deprecates the GATE alias.</div><div><br></div><div><br></div><div>Thanks for the feedback.</div><div><div><div>--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.<wbr>com/</a></div></div></div></div></div></div>