Callsign, SSID, Path and Data Type Compression

Callsigns contain only capital letters, digits and empty spaces. Up to six characters from such a 37 character set can easily be compressed into 4 CCCC bytes of the extended 256 character set.

Hence, all compressed APRS frames in this standard begin with 5 CCCCD bytes, irrespectively of the Data Type. Furthermore, the compressed frame length is voluntarily limited by design to maximum 45 bytes, which leaves up to 40 bytes of payload. For certain Data Types, the maximum length is even significantly lower. A maximum frame length of 45 bytes corresponds to a maximum airtime of 1.15 s with SF11.

Important

I‑gates should test whether the payload length of a received frame is in correspondence to the declared Data Type. Frames that do not comply, should be rejected.

The combination of the four first CCCC Base256 Callsign bytes and the in D declared Data Type with the corresponding payload length form the key —so to speak— to the i‑gate. This is what allows for a headerless frame design. It prevents the i‑gate from relaying frames that are not intended for this compressed frame link.

Callsign	SSID, Path Code & Data Type Code	Compressed Data
4 bytes	1 byte	≤ 40 bytes
`CCCC`	`D`

where:

CCCC: 4 bytes for the compressed 6 character Callsign
D: compresses into 1 byte:
- the SSID (between SSID 0 [none] and 15; included),
- the Path Code (between path 0 [none] and 3; included), and
- the Data Type Code (between type 0 and 3; included)

Base37

Base37 consist out of the following 37 ordered digits, starting with a space character:

digits = ' 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ'

Encoding CCCC

Perform input sanitisation and right padding with spaces up to 6 characters.
Treat the given 6 character callsign string as a Base37 encoding. Decode it first to an integer.
Then, encode this integer as a 4 byte Base256 CCCC bytestring.

Decoding CCCC

First, decode the given 4 byte Base256 CCCC bytestring to an integer.
Then, encode this integer as a 6 character Base37 string, corresponding to the callsign.

Encoding D

Perform input sanitisation.
Multiply the SSID integer by 16.
Multiply the Path Code by 4.
Then, algebraically add to these intermediate results to the Data Type Code integer from Table 4.
Finally, convert the resulting integer to a single Base256 D byte.

Decoding D

First, decode the given Base256 D byte to an integer.
The SSID equals the integer quotient after integer division of the decoded integer by 16.
The remainder of above integer division is subjected to a second integer division by 4.
The Path Code equals the integer quotient of this second integer division.
Whereas the Data Type Code equals the remainder this second integer division.

SSID Recommendations

A secondary station identifier is a number in the range 0-15, as an adjunct to the station Callsign. Similarly as with IEEE 802.11 wireless networks, an APRS SSID identifies a set of APRS station capabilities.

Table 3 SSID recommendations
SSID	APRS station type
0	primary station; usually fixed and message capable
1	generic additional station, digi, mobile, wx, etc.
2	generic additional station, digi, mobile, wx, etc.
3	generic additional station, digi, mobile, wx, etc.
4	generic additional station, digi, mobile, wx, etc.
5	other networks (D‑STAR, DMR, smartphones etc.)
6	special activity, satellite ops, camping, etc.
7	walkie talkies, HTs or other human portable
8	boats, sailboats, RVs or second main mobile
9	primary mobile (usually message capable)
10	Internet, (LoRa) i‑gates, echolink, Winlink, AVRS, APRN, etc.
11	balloons, aircraft, spacecraft, etc.
12	APRStt, DTMF, RFID, devices, one‑way (LoRa) trackers, etc.
13	weather stations
14	truckers or generally full time drivers
15	generic additional station, digi, mobile, wx, etc.

Tip

One-way trackers best use the 12 one‑way SSID indicator, whereas SSID 9 usually means a ham with full communication capabilities; both APRS message and voice.

Data Type Codes

Of all the Data Types defined in the APRS Protocol Reference, a subset was selected, based on popularity and suitability for LoRa.

Table 4 Data Type Codes
Data Type	ID (not used)	Data Type Code	payload
compressed geolocation — no timestamp	`!` or `=`	0	17 or 19 bytes
complete weather report — with compressed geolocation, no timestamp	`!` or `=`	0	28 or 29 bytes
status report (≤ 28 characters)	`>`	1	6—24 bytes
item report — with compressed geolocation	`)`	2	20—24 bytes
addressed message (≤ 51 characters)	`:`	3	10—45 bytes

Note

APRS 438 will not transmit any ID byte over LoRa. The ID will be added at the i‑gate.
Weather reports use the same IDs and Data Type Codes as position reports but with a Symbol Code _ overlay.
A Symbol Table Identifier nor a Symbol Code can be compressed.

Path Codes

The path codes are of little importance to LoRa APRS 438. Path codes mainly serve to instruct (VHF) APRS digipeaters. These digipeaters may be co‑located with a LoRa i‑gate or may obtain packets from Internet APRS‑IS. See also No Digipeating on the Uplink.

Table 5 Data Type Codes
station	recommended `n-N` paradigm path	Path Code
no digipeating		0
metropolitan fixed, mountain expeditions, balloons & aircraft	`WIDE2-1`	1
extremely remote fixed	`WIDE2-2`	N/A
metropolitan mobile	`WIDE1-1,WIDE2-1`	2
extremely remote mobile	`WIDE1-1,WIDE2-2`	N/A
space satellites	`ARISS,WIDE2-1`	3

Important

The first n digit in n-N paradigm paths indicates the coverage level of the digipeater, whereby 1 is for local fill‑in digipeaters and 2 is for county-level digipeaters.
The second N digit indicates the number of repeats at the indicated coverage level.