Unlike some other ham radio LoRa APRS projects, this white paper and 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:
- less airtime,
- increased battery life,
- higher chances of good packet reception,
- hence, increased range,
- lower probability of packet collisions,
- therefore, more channel capacity.
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.
- An Open Standard for LoRa APRS Frame Compression
- Measurable Benefits
- APRS 434 LoRa Link Parameters
- Callsign, SSID, Path and Data Type Compression
- Digipeating on LoRa Channels
- Compressed Geolocation Frames
- Compressed Weather Report Frames
- Compressed Text
- No APRS Comments
- Compressed Status Report Frames
- Compressed Item Report Frames
- Compressed Addressed Message Frames
- From Pure to Reservation ALOHA
- Codec Algorithms
- ITU Regulation
- Reducing Power Consumption
- Recommended Hardware
- ESP32 Firmware Downloads
- Development Road Map
- News, Social & Co-Development
- Acknowledgements
- Major Revisions
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 | 6 out of 37 possible characters: 26 capital letters + 10 digits + space |
| SSID | 1 out of 16 hexadecimal digits |
| Digipeater Address | any out of 5 recommended n-N paradigm paths |
| Control Field | not required |
| Protocol ID | not required |
| Information Field | 256 characters of which 95 printable ASCII characters first character = Data Type ID |
| Frame Check Sequence | not required; FEC & CRC are provided by LoRa |
| Flag | not required |
- Source Address, SSID and Data Type ID can be compressed into only 5 payload bytes, compared to 26 payload bytes with OE5BPA firmware.
- It is customary to compress latitude, longitude, symbol, course and speed using Base91, which results in another 13 payload bytes; Data Type ID not included. APRS 434 will not differ in this respect.
- If APRS Mic-E compression were to be used instead, that would require another 16 payload bytes to compress latitude, longitude, symbol, course and speed; 7 bytes in the superfluous Destination Address and 9 bytes in the Information Field; Data Type ID included. Hence, this is not a good option.
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.
approximately, when
-
$(1-BER)$ : the probability of receiving a bit correctly -
$n$ : the number of bits in a packet; which is 8 times the number of bytes
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 as with a 113 payload:
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.
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 is a slow data rate mode.
Due to the LoRa symbol encoding scheme, airtime reductions occur in abrupt 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.)
| payload | 5 bytes | 17 bytes | 24 bytes | 28 bytes | 45 bytes | 113 bytes |
|---|---|---|---|---|---|---|
| airtime with SF12 | 0.83 s | 1.32 s | 1.48 s | 1.65 s | 2.14 s | 4.43 s |
| airtime with SF11 | 0.50 s | 0.66 s | 0.82 s | 0.91 s | 1.15 s | 2.46 s |
| airtime with SF10 | 0.25 s | 0.33 s | 0.37 s | 0.41 s | 0.56 s | 1.23 s |
The Things Network (TTN) organisation, albeit a global LoRaWAN, is exemplary in stressing the importance of maintaining LoRa payloads small.
The following LoRa link parameters are proposed for amateur radio LoRa APRS 434:
| LoRa parameter | uplink | downlink |
|---|---|---|
| Region I & II frequency | 434.100 MHz | 434.300 MHz |
| use | APRS‑IS uplink access & client‑to‑client | i‑gate downlink & digipeating for situational awareness |
| SF | 11 | 11 |
| BW | 125 000 Hz | 125 000 Hz |
| CR | 1 (5/4) | 1 (5/4) |
| preamble sync length | 8 symbols | 8 symbols |
| preamble sync word | 0x12 |
0x12 |
| header mode | explicit (20 bits) | explicit (20 bits) |
| CRC | on (16 bits) | on (16 bits) |
| IQ polarisation | normal | inversed |
- Above proposed frequencies are outside the interfering 433—434 MHz ISM band. Moreover, these frequencies maintain sufficient spectrum separation among one another as well as from the ubiquitous car lock keys and home weather stations on 433.920 MHz.
- In order to achieve a maximum range, Semtech — the company that developed LoRa — recommends selecting the maximum spreading factor
$SF = 12$ . However, SF12 is extremely slow, offering only a mere 36.6 byte/s. -
$SF = 11$ corresponds to 11 raw bits per symbol. Therefore, each symbol (or frequency chirp) holds$2^{11} = 2048,\text{chips}$ . - Likewise, the bandwidth is set to the smallest commonly available bandwidth among all LoRa ICs, namely
$BW = 125,\text{kHz}$ . This is by definition also the chip rate$R_c = BW$ . - To avoid any further overhead in an already slow mode, the forward error correction (FEC) coding rate is kept at
$CR = 1$ , which corresponds to$\frac{data}{data + FEC} = \frac{4}{5}$ . - It was observed that amateur radio predominantly employs the LoRa sync word
0x12; which is manufacturer recommended for private networks, and differs from LoRaWAN.
With these settings, the symbol rate is:
Whereas the effective data rate
Above parameters seem adequate for sending LoRa frames with short, compressed payloads over the next longest possible distance when the number of participant nodes is relatively low.
For an in depth tutorial slide series about LoRa (and LoRaWAN), please refer to Mobilefish.com, also available in video format on YouTube.
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.
In order to prevent such a congestion, APRS 434 decided to only employ SF11.
Doing so, effectively doubles the data rate over SF12. It also saves 50% on airtime and batteries. The slight range penalty from switching from SF12 to SF11 is in most circumstances absolutely 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, the choice was made to use SF11 exclusively. Considering what some members of the amateur radio community have come to expect of LoRa, the faster data rate offered by SF11 is more than warranted.
- Semtech LoRa products
- Semtech SX1278
- HopeRF LoRa modules
- HopeRF RFM98W
- G-NiceRF Lora1278F30 1 watt module
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 voluntarily 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.
A maximum frame length of 45 bytes corresponds to a maximum airtime of 2.14 s with SF12 or 1.15 s with SF11.
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 CallsignD: 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)
- 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
CCCCbytestring.
- First, decode the given 4 byte Base256
CCCCbytestring to an integer. - Then, encode this integer as a 6 character Base37 string, corresponding to the callsign.
- 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 below table.
- Finally, convert the resulting integer to a single Base256
Dbyte.
- First, decode the given Base256
Dbyte 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.
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.
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 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 |
Notes:
- APRS 434 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.
⚠ REFRAIN from digipeating on the uplink LoRa channel! Since LoRa is a slow data rate mode, digipeating on the LoRa 434.100 MHz uplink channel quickly leads to unwanted channel congestion. Unlike AX.25 packet radio, LoRa does not offer carrier sensing (CS); only channel activity detection (CAD)
Also consider that:
- LoRa was merely intended as an Internet access technology.
- Most LoRa gateways are connected to the APRS‑IS Internet server network and many users are merely interested in reaching APRS‑IS.
- There are hardly any, if any, low power portable LoRa devices able to display situational awareness in relation to other LoRa devices.
- Only in extremely remote areas without Internet access, digipeating may be considered, but only on the downlink channel 434.300 MHz.
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.
The path codes are of little importance to LoRa APRS 434. 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.
| 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 |
Note:
- The first
ndigit inn-Nparadigm paths indicates the coverage level of the digipeater, whereby1is for local fill‑in digipeaters and2is for county-level digipeaters. - The second
Ndigit indicates the number of repeats at the indicated coverage level.
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 | 12 (or 14) bytes |
CCCC |
D |
/XXXXYYYY$cs(aa) |
where:
CCCC: 4 bytes for the compressed 6 character CallsignD: 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 = 0
/: the Symbol Table IdentifierXXXX: the Base91 compressed longitudeYYYY: the Base91 compressed latitude$: the Symbol Codecs: the compressed course (in degrees) and speed (in knots)(aa): optionally, the compressed altitude (in feet)
Note:
- Terrestrial objects do not require sending altitude data. Anyhow, GPS height readings are notorious for being significantly inaccurate.
- APRS-IS already understands Base91
XXXXYYYYcompression when altitudeaais not used. - In absence of altitude
aa, the i‑gate adds the Compression Type ByteTright behindcs. - When
aais present, the i‑gate will instead need to decompress the whole frame and forward the uncompressed frame to APRS‑IS. - The parenthesis are not sent; these merely indicate optionality.
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:
CCCC: 4 bytes for the compressed 6 character CallsignD: 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 = 0
/: the Symbol Table IdentifierXXXX: the Base91 compressed longitudeYYYY: the Base91 compressed latitude_: the weather report Symbol Codecs: the compressed wind direction (in degrees) and sustained one-minute wind speed (in knots)g: gust (half of peak wind speed in km/h in the last 5 minutes)t: temperature (in kelvin above 173.15 K)rr: rainfall (in mm) over the past hourpp: rainfall (in mm) over the past 24 hoursPP: rainfall (in mm) since midnighth: humidity (in %)bb: barometric pressure (in Pa above 50000)(S): optionally, snowfall (in cm) over the past 24 hours
Notes:
- All numerical encodings are one or two byte Base256 encodings.
- Here is a fascinating list of weather records.
- The i‑gate adds the Compression Type Byte
Tright behindcs. - The parenthesis are not sent; these merely indicate optionality.
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 makes it fit 6 times in the 256 character set of LoRa.
| character subset | # of characters |
|---|---|
| Latin capital letters | 26 |
| digits | 10 |
| space | 1 |
punctuation . ? |
2 |
symbols - / @ |
3 |
| TOTAL | 42 |
- Perform input sanitisation.
- Perform character replacement and filtering on the given string; only allow for characters of the 42 character set.
- Treat the resulting text string as a Base42 encoding. Decode it first to an integer.
- Then, encode this integer as a Base256
ttttbytestring.
- First, decode the given Base256
ttttbytestring to an integer. - Then, encode this integer as a Base42 string, corresponding to the text.
⚠ REFRAIN from adding any APRS comments! Adding more bytes to a LoRa frame only reduces the chances on successful reception. Rather, consider sending an occasional status report.
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 | 1—19 bytes |
CCCC |
D |
t(tttt…tttt) |
where:
CCCC: 4 bytes for the compressed 6 character CallsignD: 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 = 1
t(tttt…tttt): between 1 and 19 bytes of compressed text from a limited 42 character set, corresponding to a maximum of 28 uncompressed characters
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:
CCCC: 4 bytes for the compressed 6 character CallsignD: 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 = 2
/: the Symbol Table IdentifierXXXX: the Base91 compressed longitudeYYYY: the Base91 compressed latitude$: the Symbol Codecs: the compressed course and speedttt(tttt): 3 to 7 bytes for the compressed Item Name (between 3 and 9 characters of the limited 42 character set)
Notes:
- The i‑gate adds the Compression Type Byte
Tright behindcs. - The parenthesis are not sent; these merely indicate optionality.
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:
- separate up- and downlinks,
- the faster SF11 data mode, and
- eventually GPS time-disciplined, dynamic time division multiple access (TDMA) multiplexing.
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 | 5—40 bytes |
CCCC |
D |
EEEEF(tttt…tttt) |
where:
CCCC: 4 bytes for the compressed 6 character CallsignD: 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 = 3
EEEE: 4 bytes for the compressed Addressee (up to 6 character callsign)F: compresses into 1 byte:- the Addressee SSID (between SSID 0 [none] and 15; included), and
- the Message No (from 0 to 15; included)
(tttt…tttt): up to 35 bytes of compressed text from a limited 42 character set, corresponding to a maximum of 51 uncompressed characters
The EEEE codec algorithms are identical to the CCCC codec algorithms.
- Perform input sanitisation.
- Multiply the SSID integer by 16.
- Then, algebraically add to this the Message No integer.
- Finally, convert the resulting integer to a single Base256
Fbyte.
- First, decode the given Base256
Fbyte to an integer. - The SSID equals the integer quotient after integer division of the decoded integer by 16.
- Whereas the Message No equals the remainder of the decoded integer by 16 (modulo operation).
Recent academic research investigated the collision of two LoRa packets of equal power when collided with a start time offset. It was found that first LoRa packet stands a high chance of being correctly received as long as its cyclic redundancy check (CRC) information was not interfered by the second LoRa packet. This very sensitive CRC information of a LoRa packet is sent in the explicit header, towards the beginning of the packet.
Other LoRa APRS implementations allow trackers and other clients to transmit at any moment of time, which inevitably results in packet collisions and the loss of the information of one or more packets. This situation is called pure ALOHA (P‑ALOHA). It is comparable to a pile up during a DXpedition.
Above situation can be improved upon by allowing the packet transmissions to start only at well defined moments in time. This form of medium access control (MAC) is called slotted ALOHA (S‑ALOHA). However, even with slotted ALOHA, packet collisions can still occur.
Taking this a step further, with reservation ALOHA (R‑ALOHA) the i‑gate temporarily assigns a time slot to a client that was successful in reaching the i‑gate in one of the vacant time slots. With this MAC scheme, packet collisions now can only occur at first access; resulting in a vastly more efficient use of the channel. This scheme is comparable to a controlled HF net. Reserved ALOHA is the medium access control proposed for APRS 434. This choice was dictated by the requirement for bidirectional messaging.
| pure ALOHA | slotted ALOHA |
|---|---|
 |
 |
Network simulations are deemed necessary to quantify the statistical capacity of a LoRa channel in these different scenarios.
The digits order for all Base codecs is: [space]0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ-./?@
- Python3 reference implementation of codec algorithms and tests
- C (for PC) codec algorithms and tests
- MIT License
Please, note that this codec is not an encryption algorithm as its algorithm is openly published here. Therefore, this codec is perfectly legal to use under amateur radio regulations.
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.
The modulation gain of LoRa over FSK is about 10 dB in the link budget. By consequence, a 10 W AFSK packet link could be replaced with a 1 W LoRa link.
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.
- 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.
- GPS modules are also power hogs. It may be conceivable to use the WiFi receiver aboard an ESP32 for localisation, whereby the MAC-address of the strongest WLAN is 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.
- TTGO T-Beam 433 MHz v0.7 or v1.1
- longer 433 MHz antenna with SMA male connector
- 16.9 mm long tiger tail wire soldered to the female SMA socket
- 5 V, 3 A microUSB charge adapter
- Panasonic NCR18650B Li-ion cell, or quality equivalent
- glue gun to stick the GPS antenna to the cell holder
- SH1106 1.3" I²C (4‑pin) OLED display (slightly larger than the usual 0.8" displays often sold with the TTGO T-Beam)
- enclosure
- Either:
- TTGO LORA32 433 MHz v2 (U.FL or SMA female RF socket), or
- maybe Heltec ESP32 LoRa 433 MHz v2 (U.FL female RF socket); subject to satisfactory receiver testing
- ⚠ DO NOT USE Heltec ESP32 LoRa 433 MHz v1 as it is as deaf as a post!
- 70 cm amateur radio colinear groundplane antenna with coaxial cable and connectors
- 16.9 mm long tiger tail wire soldered to the RF socket
- 5 V, 1 A microUSB power supply
- enclosure
See: https://github.com/aprs434/lora.tracker
Please, note that the tracker.json configuration file has been much simplified.
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 and reservation ALOHA is added.
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 firmware |
completed | feature | tracker 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 | ✓ |
| v0.5.0 | Q2 2023 | tracker and i-gate with frame address compression, no custom header in payload |
17 bytes | use the APRS 434 i‑gate |
| acknowledged biderectional messaging with reservation ALOHA protocol to avoid repetitive collisions | 17 bytes |
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 and reservation ALOHA is added.
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 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 |
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 |
Continuously running an onboard GPS receiver consumes a lot of tracker's valuable battery energy. Moreover, GPS reception is often abyssal both indoors and in so-called city canyons; i.e. narrow streets with tall buildings on the sides. This is due to the lack of view on open sky.
As ESP32 chips incorporate WiFi which consumes less energy than GPS reception, geolocation on the basis of the unique MAC address of WLAN base stations is better.
For this reason, smartphone OS companies like Google have initially war-driven entire countries to map the location of WLAN base stations. Nowadays, the same smartphone operating systems report these locations back to these companies' servers.
One could envision sending the compressed 64‑bit MAC address of the strongest received WLAN node to an APRS 434 i‑gate. The i‑gate would then look up the approximate geographic coordinates from an Internet service, modify the geolocation frame with this information before forwarding it to APRS‑IS. Conversely, APRS‑IS could be augmented to accept MAC-addresses and to perform the geolocation lookup.
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.
- Bernd Gasser, OE1ACM, for the earliest LoRa APRS experiments and code
- Christian Johann Bauer, OE3CJB, for the Base91 geolocation compression algorithm
- Peter Buchegger, OE5BPA, for providing a tracker and i‑gate firmware as open source code, in a handy PlatformIO environment, with over-the-air (OTA) i‑gate updates. This was the ideal starting point for running LoRa frame compression experiments.
- Folkert Tijdens, PA0FOT, for contributing
compression.cppand asking the right questions, rendering this document more scholarly - Pascal Schiks, PA3FKM, for providing insights about microcontroller stacks
- Ricardo Guzman Christie, CD2RXU, for developing client and i‑gate firmware employing the compression algorithms presented in this white paper.
- Greg Stroobandt, ON3GR, for cycling around the city with a privacy invading tracker
- Erwin Fiten, ON8AR, for testing firmware and reporting on long distance car approaches to the LoRa i‑gate
- Jan Engelen, DL6ZG, for testing firmware and providing feedback
- Github.com for hosting this project, free of charge
| date | changes |
|---|---|
| 2022‑05 | initial release |
| 2023‑03 | change in the order of the codec digits; also, @ instead of _ is now allowed in text messages |
| 2023-07 | separate up- and downlinks, SF11 |
Serge Y. Stroobandt, ON4AA
<script> MathJax = { tex: { inlineMath: [['$', '$']] } }; </script> <script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script> <script id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>