Site menu LoRaMaDoR: amateur radio chat

LoRaMaDoR: amateur radio chat

Nothing like a lockdown to drive us to look for things to do. Ended up finishing the first "usable" version of a project I had started at the beginning of 2019: LoRaMaDoR.

What is LoRaMaDoR?

LoRaMaDoR is a communication system based on LoRa digital radio. The name is a wordplay with "LoRa" and "radioamador" (ham radio in Portuguese). The most obvious use case is live chat, but there's potential for many other uses.

The code can be found on GitHub. The project was inspired by AX.25 and its current vestigial incarnation, APRS. And of course the main inspiration was LoRaHam, a project with similar goals as ours.

As all other mentioned projects, LoRaMaDoR is a priori targeted for amateur radio operators. The callsign is the network address. But anyone can try it, actually. And they can even do it legally, since LoRa operates on unlicensed ISM bands.

Getting feet wet

In the video below, I am running LoRaMaDoR in 3 or 4 Arduinos, and I am interacting with one of them via USB serial port. I send "human" messages, and also ping a remote station to get an automatic response:

Command-line interface. The terminal is connected to the serial port of a TTGO LoRa32 Arduino.

Most hams have only one callsign. Just like APRS, if a ham operates more than one station, she can identify each one by adding a numeric suffix (SSID).

The idea of the command-line interface is to make the operation as simple as possible. To send a typical message, just type "callsign message"; the controller fills in the red tape to produce the final, valid packet.

LoRaMaDoR works without anything connected to the serial port. It responds to PINGs and can forward packets. It can be extended to be an autonomous weather sensor, location beacon, etc.

Why not use/collaborate to LoRaHam?

The LoRaHam project did not show movement for about two years, counting from the time I started to work on LoRaMaDoR.

I felt the network packet format is a bit too simple. There is no metadata section (used by PING to label the packet as PING) and there is no monotonic sequence number (detecting duplicates would have to compare the whole packet, including data).

LoRaHam does not use any error correction code (FEC), insisting on an error already committed by AX.25 and APRS. LoRa does have error-correction features by itself, but they have proven weak and wasteful in my tests. Even using the strongest type (4/8, 50% redundancy) it still delivers a couple corrupted bytes here and there.

Why LoRa?

The LoRa digital radio is by far the best on its class. It is easy to reach several miles with just 100mW of power and a stock antenna. The world record is 766km with just 25mW! LoRa is cheap, easy to source, and there are Arduino boards with LoRa included. No wires, no soldering.

LoRa speed is configurable over a wide range. More speed means leess reach and vice-versa. After many tests, I have adopted a set of parameters that deliver around 4000bps, with a reach of at least 4km.

LoRa can work in several ISM bands; the most common are 433MHz (70cm) and 915MHz (33cm). Note these bands also belong to amateur radio on a secondary basis. 70cm can go further, but I am using 33cm since, here in Brazil, hams cannot use spread-spectrum techniques on 70cm.

Of course, if spread-spectrum on 70cm is fair game in your country, just change the band to 433MHz at Radio.cpp. Even in Brazil, one could use 433MHz as long the power is within ISM limits.

Also, the LoRaMaDoR protocol does not depend on any LoRa-specific trait. It is perfectly possible to use other digital radios e.g. the CC1101 chip is narrowband, so it could be an alternative for the 70cm band. Si4463 could be used even in 1.3m and 2m bands.

Extrinsic goals

Several ham bands are underused. Digital radios are a simple way to occupy that space.

There is a lot of pressure to repurpose ham bands. In particular, all sub-GHz bands are extremely valuable. In some countries, amateurs have already lost part of the 1.3m (220MHz) and the current trend is to lose the whole 1.3m band.

The 70cm and 33cm band are also desired by other parties, but the danger of repurposing is less, since there is partial overlap with ISM.

Reference hardware

At the moment, I am using an Arduino-compatible little board: the TTGO LoRa32, with ESP32 controller. The board includes LoRa and an OLED display. Some kits include antenna, enclosure and/or a battery.

At the beginning, I used LoRa32u4 boards as well. These ones are of excellent quality, better than TTGO, but the inherent limitations of the AVR were a hurdle. After putting on a lot of optimization work, I quit them. (If you look into the code, you will find some remnants of LoRa32u4 support.)

LoRaMaDoR can be ported to many other platforms e.g. a Raspberry connected to LoRa. My current efforts concentrate on TTGO because this is what I have now. Most of the C++ code runs on Linux for coverage testing and Valgrinding. I use multicast to simulate radio broadcasting between many stations. a camada de rádio.

Project decisions

The most attractive trait of AX.25, APRS, and LoRaHam, is the network packets being human-readable, even though the final consumer is most often a machine. I tried to preserve this in LoRaMaDoR. Follows an example of wire packet (minus the FEC) and the meaning of each part:

PP5CRE-11<PU5EPX-11:21,PING,AAA=,BBB=CCC test 123

Destination: PP5CRE-11
Origin:      PU5EPX-11
Sequence #:  21
Parameters:  PING (key w/o value)
             AAA  (key w/ empty value)
             BBB  (value = CCC)
Payload:     test 123

The other half of usability is the CLI. The user never types the whole packet in the wire format. The sequence number and the origin are automatically filled in. Typically, in order to ping a remote station, the user would just type

PP5CRE-11:PING test 123

In the example above, even the message payload (test 123) is optional. If it exists, it is echoed in the PONG packet.

On the screenshot below, the user sends a broadcast message using the QC pseudo-callsign. The CLI is in debug mode, so the trasmitted packed in wire format is shown, as well as the duplicates received from repeaters:

Figure 1: Broadcasting a message (QC hello). In debug mode, transmitted packets are shown in wire format, as well as retransmissions.

On the screenshot below, there is no user action. The debug output shows the reception and forwareding of an automatic beacon packet (QB pseudo-callsign) coming from station PU5EPX-2:

Figure 2: Message received in debug mode. The network stack annotates the new neighbour based on the QB packet. This packet is forwarded, but only once; further `echoes` of this packet are ignored.

I feel it was a big mistake of AX.25 not to use FEC (forward error correction), and this mistake was inherited by APRS. In LoRaMaDoR, each packet is sent with a 20-byte Reed-Solomon (RS) code suffix.

At first stages of this project, I did some simulations with ad-hoc routing, and I found out it was not worth the effort. For small networks (4-5 stations) diffusion routing is enough, and ad-hoc routing grinds to a halt with 10 or more stations.

In order to handle bigger networks, the way to go is to study APRS in depth and adopt a similar solution: use Internet gateways and limit the diffusion to very few hops (just like WIDE-n does in APRS). This is the major milestone in the future.