Thank you.  The q-algo doc is indeed chock full of goodness, and I'm sure understanding the behavior of "legacy" clients like UI-View makes seeing the big picture significantly easier.  Thanks to you and Lynn for steering my clear of the rocks.<div>
<br></div><div>John Gorkos</div><div><br><br><div class="gmail_quote">On Wed, May 16, 2012 at 5:08 PM, Pete Loveall AE5PL Lists <span dir="ltr"><<a href="mailto:hamlists@ametx.com" target="_blank">hamlists@ametx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">KC0WIF-1 is running an older version of UI-View (KC0WIF-1>APU25N,TCPIP*,qAC,T2NBRASKA:=4427.76NI10021.45W&APRS iGate - Pierre, SD) and is not using either the I or qAR construct.  That is why you see qAS.  T2NBRASKA knows the packet is being passed to it by KC0WIF-1 and, according to the q algorithm, can only assume that KC0WIF-1 is a server since there is no IGate indicator in the path.<br>

<br>
Hope this helps.<br>
<br>
73,<br>
<br>
Pete Loveall AE5PL<br>
pete at ae5pl dot net<br>
<div class="im"><br>
<br>
<br>
> -----Original Message-----<br>
> From: John Gorkos<br>
> Sent: Wednesday, May 16, 2012 2:54 PM<br>
><br>
> I'm working on the javAPRSlib parsers again, and I need a little help<br>
> understanding the Q-constructs as injected by the APRS servers.<br>
> Here's a sample beacon:<br>
</div>> N0NPO-1 <<a href="http://aprs.fi/?c=raw&limit=&call=N0NPO-1" target="_blank">http://aprs.fi/?c=raw&limit=&call=N0NPO-1</a>> >APOT21,WIDE1-<br>
> 1,WIDE2-2,qAS,KC0WIF-1 <<a href="http://aprs.fi/?c=raw&limit=&call=KC0WIF-1" target="_blank">http://aprs.fi/?c=raw&limit=&call=KC0WIF-1</a>><br>
<div class="im HOEnZb">> :!4422.30N/10023.30W>235/008/A=000593 13.7V  76F<br>
><br>
><br>
> So, this device is set to beacon to WIDE1-1, WIDE2-2.  According to Pete's q-<br>
> Construct page:<br>
> qAS - Packet was received from another server or generated by this server.<br>
> The latter case would be for a beacon generated by the server. Due to the<br>
> virtual nature of APRS-IS, use of beacon packets by servers is strongly<br>
> discouraged. The callSSID following the qAS is the login or IP address of the<br>
> first identifiable server (see algorithm).<br>
> (<a href="http://www.aprs-is.net/q.aspx" target="_blank">http://www.aprs-is.net/q.aspx</a>)<br>
> I don't believe this is the "latter case", so what exactly has happened here?<br>
> Is this as simple as the IGATE KC0WIF-1 picking this packet up directly on the<br>
> air and sending on to APRS-IS?  If that's the case, why isn't the qAR construct<br>
> used?  is there a simple explanation of the difference, that I can put in my<br>
> "APRS for Dummies and Naval Academy Graduates" notebook?<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig" target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</div></div></blockquote></div><br></div>