This is a version of a talk I gave at Dorkbot in May 2024. It was pretty funny because it had lots of pictures of Cilla Black, because my brain always says "Lorra lorra" in her voice when I think of LoRa. But I don't know how she would actually feel about it so this is MoRe SeRious.

At that point I'd just left the BBC, I like puzzles and was looking for interesting mini-projects. I love Bristol Wireless' ethos, and love the idea of tiny long distance packets of data, so maybe LoRa(WAN) would be fun?

However, I'm a self taught programmer, more comfortable at the Javascript or Python levels of the stack. I rarely RTFM 😬. Maybe bad a idea? -> ⚠️❌

So the rest of this is -
* A little bit about LoRa(WAN) and what it is
* The three main faffs I've discovered (so far)
* A few ideas of what we could do with it
* Links and tips

This is from the point of view of someone starting out, who found it all a bit tricky but got there in the end. We now have a working gateway up and running in Bedminster 🎉

Some definitions

LoRaWAN: ITU[*]-standardised protocol and network architecture for LoRa
[*]International Telecommunications Union

LoRa: proprietary radio communication technique for sending a few bytes[*] of data to other similarly equipped devices
[*]0.3 kbit/s - 27 kbit/s according to wikipedia

The Things Network (TTN): mechanism to route your bytes anywhere and do something with them

Semtech: company that make all the LoRa Radio chips and own the LoRa patent

Some examples of usage

Node to node (device to device) - Usually ESP32 + LoRa radio. The nodes talk to each other directly without intermediary. Meshtastic uses this to pass messages on, but often you'd just be getting a pair to talk to each other. This is reasonably easy to get going.

+--------+          +--------+
|Node    |<-------> |Node    |      
+--------+          +--------+

Node to Gateway to The Things Network typically ESP32 -> Raspberry Pi hat or dedicated gateway.

The Things Network's main business model seems to be running private LoRaWAN networks for companies. They also provide certified training and a conference. They also run a free, open network of gateways that anyone can add to or use. Here's a map of their gateways.

In this usage the node talks to the nearest gateway, even if it's not yours, and gets funneled to your part of the Things Network (TTN) where you can retrieve it. On the free tier it's not stored, so you need to get it and do something with it, e.g. via MQTT. This gives you better range but means you are restricted in what you can send and how often by fair use - and you need a library that supports TTN.

                                        +---+       	 
                 +-------+           	| T |       	 
+--------+       |Gateway|              | T |     +------+
|Node    | ----> |in     + -----------> | N | --> |MQTT  |
+--------+       |range  |           	|   |     |etc   |
                 +-------+ +-------+ 	+---+     +------+
 +--------+                |Gateway|      ^          	 
 |Node    | -------------->|in     + -----+          	 
 +--------+                |range  |                 	 
                           +-------+

TTN run the servers. These apparently can also be deployed on AWS - and an open source version of the server is available. I've not tried doing that - all my experiments have been via TTN's free tier with their servers.

The Faffs

Faff #1: Nodes
✅ It's reasonably easy to get device-to-device communication working.
✅ There are quite a few Arduino-IDE-compatible libraries and quite a few devices available
But!
⚠️ Get the wrong device and you're in a world of pain (Heltec, I'm looking at you)
✅  Unless! You use the RadioLib library
⚠️  Although! the RadioLib library doesn't actually have a simple device-to-device example

Faff #2: Gateways
⚠️The iC880A hat seemed to work but we couldn't see how to debug it or see packets
✅ The LR1302 hat worked fine (apart from a few weird bugs in the docs and also the spectral scan doesn't work)
⚠️The TTN indoor gateway worked seamlessly but the docs were super-confusing 

Faff #3: TTN
The mental model is a little confusing. You can have gateways and applications and these are separate. But the main issue is device setup.
All I can say here is:
* Find a library that supports LoRaWAN specification 1.1.0
* The rest is a world of pain
* I have never found a good explanation of what to put for regional parameters / technical specifications

If you are testing, just use all zeros for the EUI. You can also just make the number up, or some devices will generate it for you. Let the site autogenerate all the other numbers. 
You may be tempted to use v1.0.0 because it has fewer strange numbers to add DO NOT DO THIS.

Watch out for LSB/MSB (byte order) and hex, uint_32t - RadioLib is clear what you need here, many libraries are not

Worth it?

Hopefully
We could have lots of tiny, low-power devices dotted around Bristol, sending or receiving little pieces of information, all within community control. Like -

Allotment moisture sensors
Bird or animal detectors
Docks water quality sensors 
Bike path usage
Twinkly LED installations (maybe)
other things?

Tips and links

Use RadioLib for node devices
Use the LR1302 hat for a gateway
Use LilyGo devices for nodes
Use LoRaWAN protocol version 1.1.0