[aprssig] Help with q-Constructs

[Pete Loveall AE5PL Lists]

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.

Hope this helps.

73,

Pete Loveall AE5PL
pete at ae5pl dot net



> -----Original Message-----
> From: John Gorkos
> Sent: Wednesday, May 16, 2012 2:54 PM
> 
> 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?