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:
- 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.
Index
- An Open Standard for LoRa APRS Frame Compression
- Measurable Benefits
- LoRa Link Parameters
- Callsign, SSID, Path and Data Type Compression
- Digipeating on LoRa Channels
- Compressed Geolocation Frames
- Compressed Weather Report Frames
- Compressed Text
- Comments
- Compressed Status Report Frames
- Compressed Item Report Frames
- Compressed Addressed Message Frames
- Reducing Power Consumption
- Recommended Hardware
- ESP32 Firmware Downloads
- Development Road Map
- News, Social & Co-Development
- Acknowledgements
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 |
- 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.
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:
- $(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
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.)
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 |
---|---|
LoRa Link Parameters
Currently, the following LoRa link parameters are commonly in use among amateur radio operators:
- In order to achieve a maximum range, Semtech — the company that developed LoRa — recommends selecting the maximum spreading factor $SF = 12$. This corresponds to 12 raw bits per symbol. Therefore, each symbol (or frequency chirp) holds $2^{12} = 4096\,\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}$.
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:
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)
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 below table.
- 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.
Codec Algorithms for CCCCD
- Python3 compression algorithms and tests
- MIT License
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:
- 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 displaying situational awareness in relation to other LoRa devices.
- In IARU Region I the central frequency of 433.900 MHz is proposed as a downlink channel from gateways to nodes. The proposal does not mention digipeating.
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:
- The first
n
digit inn-N
paradigm paths indicates the coverage level of the digipeater, whereby1
is for domestic fill‑in digipeaters and2
is for county-level digipeaters. - The second
N
digit indicates the number of repeats at the indicated coverage level.
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:
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)
/
: 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.
- In absence of
aa
, the i‑gate adds the Compression Type ByteT
right behindcs
. - When
aa
is present, the i‑gate will decompress the whole frame.
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:
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)
/
: 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
T
right behindcs
.
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
- Perform input sanitisation.
- Perform character replacement and filtering on the given string; only allow for charcters 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
tttt
bytestring.
Decoding tttt
- First, decode the given Base256
tttt
bytestring to an integer. - Then, encode this integer as a Base42 string, corresponding to the text.
Codec Algorithms for tttt
- Python3 compression algorithms and tests
- MIT License
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:
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)
t(tttt…tttt)
: between 1 and 19 bytes of compressed text from a limited 42 character set, corresponding to 28 uncompressed characters
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:
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)
/
: 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)
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 faster SF11 data mode, and
- GPS-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 | ≤ 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 (between type 0 and 3; included)
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 51 uncompressed characters
Encoding and Decoding EEEE
The EEEE
codec algorithms are identical to the CCCC
codec algorithms.
Encoding F
- 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
F
byte.
Decoding F
- First, decode the given Base256
F
byte 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).
Codec Algorithms for EEEEF
- Python3 compression algorithms and tests
- MIT License
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
- 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 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.
Recommended Hardware
Tracker Hardware:
- 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
I-Gate Hardware:
- 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
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
Data Link Layer
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
- 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 the bulk of the 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 asking the right questions, rendering this document more scholarly
- Pascal Schiks, PA3FKM, for providing insights about microcontroller stacks
- 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
May 2022
Serge Y. Stroobandt, ON4AA