Order Tray | Contact Us | Home | SIG Lists

[aprssig] Help with q-Constructs

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Wed May 16 20:50:00 UTC 2012

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 http://www.aprs-is.net/qalgorithm.aspx 
(an invaluable reference, BTW, if you can grok it):

> All packets from an inbound connection that would normally be passed per current validation algorithm:
> {
> .... Non-applicable code removed....
>      If a q construct exists in the header:
>          Skip to "All packets with q constructs"
> .... Not this one so....
>      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...

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 5/16/2012 3:53 PM, John Gorkos wrote:
> I'm working on the javAPRSlib parsers again, and I need a little help 
> understanding the Q-constructs as injected by the APRS servers.
> Here's a sample beacon:
> *N0NPO-1 
> <http://aprs.fi/?c=raw&limit=&call=N0NPO-1>*>APOT21,WIDE1-1,WIDE2-2,qAS,KC0WIF-1 
> <http://aprs.fi/?c=raw&limit=&call=KC0WIF-1>:!4422.30N/10023.30W>235/008/A=000593 13.7V  76F
> So, this device is set to beacon to WIDE1-1, WIDE2-2.  According to 
> Pete's q-Construct page:
> *qAS* - 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).
> (http://www.aprs-is.net/q.aspx)
> 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?
> Thanks.
> John Gorkos
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20120516/073977fa/attachment.htm>

More information about the aprssig mailing list