<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
If I had to guess, N0NPO-1 was received by a station that is
connected to the UI-View instance KC0WIF-1 as an upstream server.
Whatever did the receiving probably didn't put the qAR in the
packet, and UI-View (guessing here) doesn't do any q-Construct
mucking but simply forwarded the packet to the APRS-IS server
upstream from there (probably a javAPRSSrvr instance somewhere).
When the packet got there, it wasn't from the logged on station, and
didn't have a q-Construct, so it got flagged as qAS using the logged
on server's callsign-SSID per the following processing rule from
<a class="moz-txt-link-freetext" href="http://www.aprs-is.net/qalgorithm.aspx">http://www.aprs-is.net/qalgorithm.aspx</a> (an invaluable reference,
BTW, if you can grok it):<br>
<br>
<blockquote type="cite">
<pre>All packets from an inbound connection that would normally be passed per current validation algorithm:
{
.... Non-applicable code removed....
</pre>
</blockquote>
<blockquote type="cite">
<pre> If a q construct exists in the header:
Skip to "All packets with q constructs"
.... Not this one so....
</pre>
</blockquote>
<blockquote type="cite">
<pre> If header is terminated with ,I:
{... Nope...
}
Else If the FROMCALL matches the login:
{... Nope...
}
Else
Append ,qAS,login
.... I suspect it's this that did it...
</pre>
</blockquote>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
<br>
On 5/16/2012 3:53 PM, John Gorkos wrote:
<blockquote
cite="mid:CAJcxM3yjqn11NSWDWKtB9_JBfPPRyVUpzK1tfYTKfhdAcpDdvw@mail.gmail.com"
type="cite">I'm working on the javAPRSlib parsers again, and I
need a little help understanding the Q-constructs as injected by
the APRS servers.
<div>Here's a sample beacon:</div>
<div><span class="raw_line"><b><a moz-do-not-send="true"
href="http://aprs.fi/?c=raw&limit=&call=N0NPO-1">N0NPO-1</a></b>>APOT21,WIDE1-1,WIDE2-2,qAS,<a
moz-do-not-send="true"
href="http://aprs.fi/?c=raw&limit=&call=KC0WIF-1">KC0WIF-1</a>:!4422.30N/10023.30W>235/008/A=000593 13.7V 76F</span></div>
<div><span class="raw_line"><br>
</span></div>
<div><span class="raw_line">So, this device is set to beacon to
WIDE1-1, WIDE2-2. According to Pete's q-Construct page:</span></div>
<div><span class="raw_line"><b>qAS</b> - Packet was received from
another server or generated by this server. The latter case
would be for a beacon generated by the server. Due to the
virtual nature of APRS-IS, use of beacon packets by servers is
strongly discouraged. The callSSID following the qAS is the
login or IP address of the first identifiable server (see
algorithm).</span></div>
<div><span class="raw_line">(<a moz-do-not-send="true"
href="http://www.aprs-is.net/q.aspx">http://www.aprs-is.net/q.aspx</a>)</span></div>
<div><span class="raw_line">I don't believe this is the "latter
case", so what exactly has happened here? Is this as simple
as the IGATE KC0WIF-1 picking this packet up directly on the
air and sending on to APRS-IS? If that's the case, why isn't
the qAR construct used? is there a simple explanation of the
difference, that I can put in my "APRS for Dummies and Naval
Academy Graduates" notebook?</span></div>
<div><span class="raw_line"><br>
</span></div>
<div><span class="raw_line">Thanks.</span></div>
<div><span class="raw_line">John Gorkos</span></div>
<div><span class="raw_line">AB0OO</span></div>
<div><span class="raw_line"><br>
</span></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>