Edge cases

Jump to: navigation, search

APRS as a protocol is kinda... freeform, sometimes. Some packets do not adhere to the specification - some more so than others.

Position packets

All-zero timestamp


This packet specifies a Zulu timestamp, but it's all zeroes. This isn't covered in the APRS spec, but is assumed to mean that no timestamp is available.

Zulu timestamps in the wrong format


The spec says that zulu time should be in the format DDHHMM, but some clients use HHMMSS (for which clients should be using the h timestamp identifier).

Zulu timestamps using Z instead z as an identifier

HS0BYW-3>APNN08,WIDE1-1,qAR,HS0BYW-2:/220258Z\\\\GF^SgsdpvxLG/A=000013 HDOP00.9 SATS09 VIN:14.1V

The spec says that z should be used to specify a timestamp in zulu time, but some clients use Z.

Message packets

Telemetry definitions

YO6ZO-10>APDW15,TCPIP*,qAC,T2ROMANIA::YO6ZO-10 :PARM.Temperatura_interioara,Temperatura_radiator_emisie_RoLink,Temperatura_exterioara

This packet is a message (identified by the : data type ID), but the message length (85) is over the maximum defined by the specification (67). C13 P68 notes that stations can send definitions of telemetry data as messages, but does not make any allowance for these to be longer than the maximum message length of 67 characters.

It's possible to detect these packets by the presence of the PARM., UNIT., EQNS. or BITS. prefix.

q Constructs


HA5PT-13>APDILX,qAE,HA5DI-12:!4725.08N/01901.09E>/A=000488MICROMITE SF12 BW125 4/5 FCNT#21225 GW#1 BP1/BE01000D

qAE is not a valid q-Construct, but shows up on packets from some Hungarian stations. APDILX (according to aprs.fi) is Bela, HA5DI: DIXPRS (software).