# 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.

## 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

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:

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.

## 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 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)

### 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.

### 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)
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 in n-N paradigm paths indicates the coverage level of the digipeater, whereby 1 is for domestic fill‑in digipeaters and 2 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 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) • /: the Symbol Table Identifier • XXXX: the Base91 compressed longitude • YYYY: the Base91 compressed latitude • $: the Symbol Code
• cs: 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 Byte T right behind cs.
• 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 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)
• /: the Symbol Table Identifier
• XXXX: the Base91 compressed longitude
• YYYY: the Base91 compressed latitude
• _: the weather report Symbol Code
• cs: 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 hour
• pp: rainfall (in mm) over the past 24 hours
• PP: rainfall (in mm) since midnight
• h: 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 behind cs.

## 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

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 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)
• 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 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) • /: the Symbol Table Identifier • XXXX: the Base91 compressed longitude • YYYY: the Base91 compressed latitude • $: the Symbol Code
• cs: the compressed course and speed
• ttt(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.

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:

• 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)
• 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

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).

## 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:

• 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

### Tracker Firmware

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

### I-Gate Firmware

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
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,
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
support for the M5Stack CardKB Mini keyboard

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