LoRa and The Things Network

Introduction

I’ve long been interested in LoRa¹, a Long-Range, low-power radio technology. The specs talk about a 10km range, but I wanted to get a feel for how it worked in practice. I was keen to try the simplest experiment which might work, rather than optimize for a particular application.

Much of my background knowledge comes from Andreas Spiess’ videos² so if the choices below are sensible, he deserves the credit:

• Having a single RF device isn’t much fun, so for my experiments I connected to The Things Network³.

• For my node I used the LILYGO T-Beam⁴ which partners a LoRa RF chip with an ESP32, a GPS receiver, and a natty OLED screen. There’s also support for an 18650 cell which makes it easy to use in the field. To be specific I bought a T-Beam T22_V1.1 20210222.

• I found a case on Thingverse⁵ which kept things neat and tidy.

Firmware

One advantage of the T-Beam is that people have been connecting it to The Things Network for years, and documenting the process⁶. That said, there are several different versions of the T-Beam, and some of the firmware available freely online doesn’t work with the latest hardware.

1. The Meshtastic firmware ⁷ appeared to work, though having only one device it was hard to be sure. It doesn’t use The Things Network, so this firmware is only really useful to test the toolchain and basic hardware.

2. I couldn’t get LMIC-node⁸ or LMIC-node-gps-tracker⁹ to work: the hardware initialization failed, though it wasn’t clear why. I didn’t spend long on them though, and it’s quite possible I was making a stupid mistake.

3. Version 1.2.1 of the TTGO T-Beam Tracker ¹⁰ worked after fixing the duplicate definition of hal_init. It connects to The Things Network and successfully logs its location. Version 1.2.2 released in July 2022 should compile without problems.

Furthermore, the USB-serial chip on recent versions of the board isn’t properly supported on the Mac (neither Intel or Apple Silicon both running Monterey 12.4). I didn’t explore third-party drivers, but just copied the files to a Raspberry Pi, and ran esptool there instead.

Experiments

Calling these experiments is rather pretentious. Having found that the device could send messages to the network, I wanted to know where it worked. Since the device has its own GPS, this was easy: turn it on and move it around.

I used the TTN Mapper¹¹ integration to view the data I sent to The Things Network, so there’s quite a long pipeline between the GPS chip and the thing I’m viewing. Not all the messages made it to the end, but I’ve not attempted to work out where they get lost.

I tried three things:

1. Leaving the device stationary in my home in Cambridge, UK. This works, but a significant fraction of packets are lost.

2. Cycling from home to the centre of Cambridge with the device in my pannier. This works reasonably well: about 75% of the packets sent made it to the map and it’s easy to see the route I took. Most of the gateways are closer to the centre of Cambridge than to my house, so on average the distance to the gateways is lower on this journey than at home.

3. Driving to Somerset, stopping irregularly en route, with the device on the front-seat of my car. This really didn’t work: for most of the journey no packets arrived. I suspect that speed is a key factor: those packets which are displayed were from roads where I was driving slowly. That’s not the whole story though: I parked in Henley for about an hour and saw but one packet.

Packet statistics

The statistics below are purely representative. They were taken at different times of day, and in different weather conditions. It seems safe to conclude that high spreading factors give us more range, and that whatever you do it is likely that some packets will be lost.

I was surprised to find that quite a lot of packets don’t arrive, and quite a few are sent multiple times.

Location	Spreading Factors	Lost	Received
			Once	Twice	Thrice	Four times	Five times
Garden	7	46%	44%	10%	0%	0%	0%
Home	7	43%	28%	30%	0%	0%	0%
Home	8	15%	15%	58%	12%	0%	0%
Home	9	6%	85%	9%	0%	0%	0%
Home	10	13%	3%	53%	31%	0%	0%
Home	11	38%	34%	28%	0%	0%	0%
Home	12	10%	26%	4%	11%	31%	19%
Cycle Ride	7	25%	56%	17%	3%	0%	0%

The firmware steadily ramped up the Spreading Factor when it was left to run overnight. As expected this increased the range, so much so that nearly a fifth of the packets were received by five gateways. A tenth of packets were lost, but perhaps I exceeded the maximum allowed usage here.

Conclusions

In broad terms I think this was a success: I have a device which logs its position over The Things Network. Happily, it was neither particularly expensive or difficult to set up.

Furthermore, it really does seem to be long-range. Assuming that the TTN gateway locations are accurate, the device is routinely sending data over 8km.

However there are caveats:

• Even when the device is stationary, a surprisingly high fraction of packets don’t arrive. This is mitigated—but not solved—by using a larger spreading factor. Sadly, the device seems oblivious that the packets have vanished into the aether.

• When the device is moving quickly (~70 mph) very few observations get through.

• I can’t quantify this, but I got the feeling that things happened a bit more slowly than I was expecting. In practical terms I found that if something didn’t appear to be working, just leaving it alone for ten minutes was sometimes enough to get the desired result.

I don’t think any of these problems are insurmountable, and it’s quite possible that they could be fixed with different configuration or software tweaks. Overall, it seems that LoRa and The Things Network might well be useful, but some care is needed when using it. Notably, in this setup, packets were lost without the node being aware of it.

Revised by Martin Oldfield on 05 Jul 2022, original version 04 Jul 2022.
Contact: Martin Oldfield, ex-atelier@mjoldfield.com
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.