q Construct

The "q-construct" is implemented on APRS-IS to add the following capabilities to the Internet APRS transport mechanism.

The currently defined q constructs are:

Server Generated:

Client Generated:

Client generated q constructs will be verified if a new authorization algorithm is created.

Servers MUST have unique logins from any other server/IGate/client that insert data onto APRS-IS.  This is to prevent packets from being erroneously detected as looping. For instance, if my server's login is AE5PL and my weather client is AE5PL, my server will see ,qAC,AE5PL and consider this packet a looped packet. As logins can be any combination of 9 alphanumeric characters, this should not pose a problem.

IGates which append IGATECALL,I to the end of packets and which are directly connected to a server which supports the q construct will have the IGATECALL,I converted to qAR,IGATECALL, qAr,IGATECALL, or qAo,IGATECALL to support the extended capabilities of the q construct.

Servers will have the ability to selectively enable tracing on all packets through server configuration. This must be used judiciously and only when a loop condition is suspected due to the increased bandwidth demands that tracing creates.

q constructs will only appear on APRS-IS and are not to be used elsewhere due to bandwidth considerations.

For example, this is what happens to a packet without a q construct which enters the system via a verified connection:

Original packet:

Packet leaving the server if trace is off:

or, if trace is on:

Here is a similar example where the packet is gated to APRS-IS from RF:

Original packet:

Packet leaving the server if trace is off:

or, if trace is on:

Logins used on APRS-IS must not consist of exactly 8 characters from 0 to 9 or A to F as this would indicate a server generated IP address for the q construct.