APRS 434

Welcome to the home of APRS 434, the 434 MHz LoRa APRS amateur radio project that extends range by saving bytes.

Unlike some other ham radio LoRa APRS projects, this project aims at deploying LoRa the way it was intended; namely by being frugal about the number of bytes put on air. Doing so, reaps a number of benefits:

In dense urban environments and/or on flat terrain, LoRa works best when the data payload is kept to a strict minimum. This can be achieved taking full advantage of all 256 characters available for transmission with LoRa. The APRS frame compression protocols presented below aim precisely at doing that; for LoRa, or any other data link with an extended character set.

ESP32 tracker and i‑gate firmware adhering to these compression protocols is provided as well.

Index

An Open Standard for LoRa APRS Frame Compression

As a physical layer, LoRa permits sending any of the 256 characters from \00 to \ff. This is double the amount of the 7‑bit, 128 ASCII character set. Hence, there are ample opportunities for compressing AX.25 (packet radio) unnumbered information (UI) frames at the data link layer, namely:

AX.25 UI frame field compression opportunities with LoRa
Flag not required; explicit header provided by LoRa
Destination Address not required; software version provided by the i‑gate
Source Address any 6 out of 37 characters: 26 capital letters + 10 digits + space
SSID 1 out of 16 hexadecimal numerals
Digipeater Address any out of 5 recommended n-N paradigm paths
Control Field not required
Protocol ID not required
Information Field up to 256 out of 95 printable ASCII characters
first character = Data Type ID
Frame Check Sequence not required; FEC & CRC are provided by LoRa
Flag not required

Measurable Benefits

Reduced Packet Error Rate

APRS 434 geolocation beacons will encode a total of only 18 payload bytes at a time, tremendously increasing the chances of a flawless reception by an APRS 434 LoRa i-gate. Other firmware tends to consume about six times as many LoRa payload bytes.

LoRa may receive up to 20 dB under the noise floor, but keep in mind that the packet error rate (PER) as a function of the bit error rate (BER) increases with the number of transmitted bits.

\[PER = 1 - (1 - BER)^n \approx n \cdot BER\]

approximately, when $BER$ is small and $n$ is large, and where:

PER Examples

When used with an explicit header, LoRa packets will have the following 36 bit overhead: a 16 bit physical header PHDR, 4 bits of header CRC PHDR_CRC and another 16 bits of payload CRC.

payload 17 bytes 24 bytes 28 bytes 45 bytes 113 bytes
overhead 36 bits 36 bits 36 bits 36 bits 36 bits
n 172 bits 228 bits 260 bits 396 bits 940 bits
BER 0.1% 0.1% 0.1% 0.1% 0.1%
PER 15.8% 20.4% 22.9% 32.7% 61.0%

By consequence, the chances of correctly receiving a 17 byte payload are more than twice as high than with a 113 payload:

\[\frac{1-0.158}{1-0.610} \approx 2.18\]

In reality, above calculations are more convoluted as LoRa employs symbols that are chip jumps or discontinuities in chirps to convey information. Moreover, a preamble, consisting out of a configurable length preamble, a set sync word, a start frame delimiter (SDF) and a small pause precede the explicit header. The variable preamble is important as it trains the receiver at receiving the signal. Hence, the symbol length of this variable preamble also has an effect on the packet error rate. Details about the LoRa packet structure can be found here.

Airtime Reduction

Keeping the payload as small as possible, has an even more important reason: to reduce the airtime required to send the LoRa frame. As will be shown in the next section, LoRa slowTODO

Due to the LoRa symbol encoding scheme, airtime reductions occur in steps of 5 bytes when the spreading factor is SF12 and the bandwidth 125 kHz (CR=1, explicit header, CRC=on). This is depicted as the stepped top trace on the figure below. (Adapted from airtime-calculator.)

Figure 1: The top trace is for SF12BW125. The dot represents a total payload of 17 bytes as proposed for geolocation packets with compression.

payload 17 bytes 24 bytes 28 bytes 45 bytes 113 bytes
airtime with SF12 1.32 s 1.48 s 1.65 s 2.14 s 4.43 s
airtime with SF11 0.66 s 0.82 s 0.91 s 1.15 s 2.46 s

The Things Network (TTN) organisation, albeit a global LoRaWAN, is exemplary in stressing the importance of maintaining LoRa payloads small.

From Pure to Slotted ALOHA

TODO

pure ALOHA slotted ALOHA
Pure ALOHA protocol Slotted ALOHA protocol

Currently, the following LoRa link parameters are commonly in use among amateur radio operators:

With these settings, the symbol rate is:

\[R_s = \frac{R_c}{2^{SF}} = \frac{BW}{2^{SF}} = \frac{125\,000}{2^{12}} \approx 30.5\,\text{symbols/s}\]

Whereas the effective data rate $DR$ or bit rate $R_b$ can be calculated as follows:

\[DR = R_b = \frac{BW}{2^{SF}} \cdot SF \cdot \frac{4}{4 + CR} = \frac{125\,000}{2^{12}} \cdot 12 \cdot \frac{4}{5} \approx 293\,\text{bits/s} \approx 36.6\,\text{byte/s}\]

Finally, it was observed that amateur radio predominantly employs the LoRa sync word ‘0x12’; which is manufacturer recommended for private networks, different from LoRaWAN.

Summarised, the following LoRa link parameters are proposed for APRS:

LoRa parameter uplink downlink
Region I frequency 443.775 MHz 443.900 MHz
SF 12 12
BW 125 000 125 000
CR 1 (5/4) 1 (5/4)
preamble sync length 8 symbols 8 symbols
sync word 0x12 0x12
header explicit (20 bits) explicit (20 bits)
CRC on (16 bits) on (16 bits)
IQ polarisation normal inversed

Above parameters seem adequate for sending LoRa frames with short, compressed payloads over the largest possible distance when the number of participant nodes is relatively low. However, network simulations are deemed necessary to quantify the statistical capacity of a LoRa channel in different scenarios.

For an in depth tutorial slide series about LoRa (and LoRaWAN), please refer to Mobilefish.com, also available in video format on YouTube.

Considerations for Switching to SF11

Depending on how popular APRS over LoRa becomes and on how intensely it will get used, there might come a time when the LoRa channel gets saturated. Unlike packet radio, LoRa has no carrier sensing capability. Sending longer text messages, even when compressed, may aggravate the situation. The same holds true for meshing or (emergency) n-N paradigm digipeating on the same channel.

When this situation occurs, the ham radio community should seriously consider switching from SF12 to SF11. Doing so, would effectively double the data rate.

Not only would switching to SF11 reduce channel congestion; It would also save 50% on airtime and batteries. The range penalty from switching from SF12 to SF11 would in most circumstances be acceptable, provided the availability of i‑gates in an area is sufficient.

With a payload of only 17 bytes, the compressed geolocation frame is perfectly geared towards taking advantage of the reduced airtime offered by SF11 (see graph).

Unfortunately, most cheap i‑gates currently in use by ham operators are only capable of receiving one preset spreading factor. Therefore, a choice needs to be made between SF12 and SF11. Considering what some members of the amateur radio community have come to expect of LoRa, the faster data rate offered by SF11 ought to be preferred.

LoRa ICs and Modules

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 an 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 limited by design to a maximum of 45 bytes, which leaves up to 40  bytes for a payload. For certain Data Types, the maximum length is even significantly lower.

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 declared Data Type with the corresponding payload length forms the key so to speak to the i‑gate. This is what allowed 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:

Encoding CCCC

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

Decoding CCCC

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

Encoding D

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

Decoding D

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

Codec Algorithms for CCCCD

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.

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.

*: 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 foremost suitability for LoRa.

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

Note: Weather reports use the same Data Type IDs as position reports but with a Symbol Code _ overlay.

Digipeating on LoRa Channels

⚠ REFRAIN from digipeating on LoRa channels! Because of LoRa being a slow data rate mode, digipeating on LoRa channels quickly leads to unwanted channel congestion. Unlike AX.25 packet radio, LoRa does not offer carrier sensing.

Also consider that:

Hence, below n-N paradigm paths could be interpreted foremost as crossover AX.25 packet digipeating paths for any (VHF) digipeater co‑located with the LoRa (i‑)gate.

However, suppose meshing or n-N paradigm digipeating were to be allowed on a single LoRa channel; even for trackers. This would offer interesting emergency capabilities when no Internet is available. However, this would absolutely require switching from SF12 to the higher data rate offered by SF11 as explained before. In such a scenario, below table represents the LoRa device communicating its digipeating requirements to the mesh network.

Path 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  
metropolitan mobile WIDE1-1,WIDE2-1 2
extremely remote mobile WIDE1-1,WIDE2-2  
space satellites ARISS,WIDE2-1 3

Note:

Compressed Geolocation Frames

A compressed geolocation frame has a payload of either exactly 17 or 19 bytes.

Callsign SSID,
Path Code &
Data Type Code		 Compressed Data
4 bytes 1 byte 13 (or 15) bytes
CCCC D /XXXXYYYY$cs+(aa)

where:

Note:

Compressed Weather Report Frames

A compressed weather report frame has a payload of either exactly 28 or 29 bytes.

Callsign SSID,
Path Code &
Data Type Code		 Compressed Data
4 bytes 1 byte 23 (or 24) bytes
CCCC D /XXXXYYYY_csgtrrppPPhbb(S)

where:

Notes:

Compressed Text

In order to prevent channel congestion, it is crucial to limit the character set of messages. This allows for more frame compression. In resemblance to Morse code, the character set would contain only 26 Latin capital letters, the 10 digits, space and a few punctuation marks and symbols. Limiting the set to 42 characters lets it fit 6 times in the 256 character set of LoRa.

character set amount
Latin capital letters 26
digits 10
space 1
punctuation . ? 2
symbols - / _ 3
TOTAL 42

Encoding tttt

  1. Perform input sanitisation.
  2. Perform character replacement and filtering on the given string; only allow for charcters of the 42 character set.
  3. Treat the resulting text string as a Base42 encoding. Decode it first to an integer.
  4. Then, encode this integer as a Base256 tttt bytestring.

Decoding tttt

  1. First, decode the given Base256 tttt bytestring to an integer.
  2. Then, encode this integer as a Base42 string, corresponding to the text.

Codec Algorithms for tttt

Comments

⚠ REFRAIN from adding any comments! Adding more bytes to a LoRa frame only reduces the chances on successful reception. Rather, consider sending an occasional status report.

Compressed Status Report Frames

A compressed status report frame has a payload of between 6 and 24 bytes.

Callsign SSID,
Path Code &
Data Type Code		 Compressed Data
4 bytes 1 byte ≤ 19 bytes
CCCC D t(tttt…tttt)

where:

Compressed Item Report Frames

A compressed item report frame has a payload of between 20 and 24 bytes.

Callsign SSID,
Path Code &
Data Type Code		 Compressed Data
4 bytes 1 byte 15—19 bytes
CCCC D /XXXXYYYY$csTttt(tttt)

where:

Note: The i‑gate adds the Compression Type Byte T right behind cs.

Compressed Addressed Message Frames

Up to now, APRS has been unduly considered to be predominantly a one-way localisation technology. This went to the point that many mistakenly think the letter “P” in the acronym APRS would stand for “position.” Bob Bruninga WB4APR (SK), the spiritual father of APRS, deeply resented this situation.

“APRS is not a vehicle tracking system. It is a two-way tactical real-time digital communications system between all assets in a network sharing information about everything going on in the local area.”

In Bob’s view of APRS as being foremost a real-time situational and tactical tool, messaging definitely merits its place. One of the long-term goals is rendering APRS messaging more popular by offering messaging pager designs.

Below proposal for the compression of addressed message frames is primarily intended for uplink-only messaging or for direct messaging without the aid of a digipeater. The available message length of 51 characters is largely sufficient for, for example, SOTA self-spotting using APRS2SOTA.

On the other hand, two‑way messaging over a digipeater would definitely require:

The formulation of such a two‑way TDMA protocol is beyond the scope of this document.

A compressed addressed message frame has a payload of between 10 (for an empty ping) and 45 bytes.

Callsign SSID,
Path Code &
Data Type Code		 Compressed Data
4 bytes 1 byte ≤ 40 bytes
CCCC D EEEEF(tttt…tttt)

where:

Encoding and Decoding EEEE

The EEEE codec algorithms are identical to the CCCC codec algorithms.

Encoding F

  1. Perform input sanitisation.
  2. Multiply the SSID integer by 16.
  3. Then, algebraically add to this the Message No integer.
  4. Finally, convert the resulting integer to a single Base256 F byte.

Decoding F

  1. First, decode the given Base256 F byte to an integer.
  2. The SSID equals the integer quotient after integer division of the decoded integer by 16.
  3. Whereas the Message No equals the remainder of the decoded integer by 16 (modulo operation).

Codec Algorithms for EEEEF

ITU Regulation

From a ITU regulatory point of view, long range communication —which, by definition, includes LoRa— is not allowed on ISM (Industrial, Scientific & Medical) bands. ISM bands are intended for local use only.

The amateur radio service forms a sole exception to this, as its 70 cm UHF band happens to overlap the ITU Region 1 434 MHz ISM band as a primary service. Moreover, ham radio is not restricted to a 20 dBm (= 100 mW) power level, nor any 1% duty cycle limits on this band.

As a general rule, secondary users should always check whether a frequency is in use by a primary user before transmitting on air. However, LoRa has no carrier sensing capability. Therefore, secondary ISM band users lack the ability to check whether an amateur radio operator is using the 434 MHz band as a primary user.

Reducing Power Consumption

  1. OLED displays have a limited life span and consume quite a bit of power. An OLED screen and its driver can be put to sleep when the tracker is idle. The same holds true for the LoRa radio module and the ESP32. This needs to be investigated.
  2. GPS modules are also power hogs. It may be conceivable to use the WLAN receiver aboard an ESP32 for localisation, whereby the three strongest WLAN SSIDs are transmitted to the i‑gate. The i‑gate would then guess the tracker location from a freely available wardriving data service from the Internet. This is comparable to how Google Android smartphone localisation works.

Tracker Hardware:

I-Gate Hardware:

ESP32 Firmware Downloads

Tracker Firmware

See: https://github.com/aprs434/lora.tracker

Please, note that the tracker.json configuration file has been much simplified.

I-Gate Firmware

See: https://github.com/aprs434/lora.igate

Currently, the APRS 434 tracker is still compatible with the i-gate developed by Peter Buchegger, OE5BPA. However, this will soon change as more LoRa frame compression is added.

We feel confident that trackers with the proposed APRS 434 compressed LoRa frame will eventually become dominant because of the longer range merit. To smooth out the transition, we are developing an i‑gate capable of understanding both formats; i.e. compressed APRS 434 and longer, legacy OE5BPA.

It is strongly advised to install the accompanying APRS 434 i-gate as new releases will be automatically pulled over‑the‑air (OTA) via WiFi.

Development Road Map

tracker
firmware		 completed feature LoRa payload compatible with OE5BPA i‑gate
v0.0.0 ✓ original OE5BPA tracker 113 bytes ✓
v0.1.0 ✓ byte-saving tracker.json 87 bytes ✓
v0.2.0 ✓ fork of the OE5BPA tracker
with significantly less transmitted bytes		 44 bytes ✓
v0.3.0 ✓ Base91 compression of location, course and speed data 31 bytes ✓
v0.4.0 ✓ removal of the transmitted newline \n character at frame end 30 bytes ✓
    tracker and i-gate with frame address compression,
no custom header in payload		 17 bytes use the APRS 434 i‑gate
    randomly slotted ALOHA protocol to avoid repetitive collisions    

Currently, the APRS 434 tracker is still compatible with the i-gate developed by Peter Buchegger, OE5BPA. However, this will soon change as more LoRa frame compression is added.

We feel confident that trackers with the proposed APRS 434 compressed LoRa frame will eventually become dominant because of the longer range merit. To smooth out the transition, we are developing an i‑gate capable of understanding both formats; i.e. compressed APRS 434 and longer, legacy OE5BPA.

It is strongly advised to install the accompanying APRS 434 i-gate as new releases will be automatically pulled over‑the‑air (OTA) via WiFi.

Tracker Hardware

tracker
firmware		 completed feature
v0.3.1 ✓ coordinates displayed on screen
    reduced power consumption through SH1106 OLED sleep
    button press to activate OLED screen
    ESP32 power reduction

Messaging

At first, only uplink messaging to an i-gate will be considered. This is useful for status updates, SOTA self‑spotting, or even emergencies.

On the other hand, bidirectional messaging requires time division multiplexing between the up- and downlink, based on precise GPS timing. That is because channel isolation between different up- and downlink frequencies probably would require costly and bulky resonant cavities.

tracker
firmware		 completed feature
    add a library for the Xbox 360 Chatpad keyboard
    support for the M5Stack CardKB Mini keyboard

WiFi Geolocation

TBD

News, Social & Co-Development

Feel free to join our public Telegram Group for the latest news and cordial discussions.

You are invited to contribute code improvements to this project on GitHub. Here is a lightweight video introduction to using GitHub by Andreas Spiess, HB9BLA.

Acknowledgements

May 2022
Serge Y. Stroobandt, ON4AA