Skip to main content
LoRa is a radio. LoRaWAN is a network on top of it. Most of what goes wrong on a LoRa project comes from treating one as the other: a node that transmits and is never accepted, two radios that cannot hear each other, a single transceiver sold as a gateway. Adsum ships the knowledge that keeps the two apart, and the tools that put numbers on the decisions, curated by Omar Morceli and verified on an nRF52840 with an SX1262.
Needs a free account, registered once with GitHub or email; BLE, Wi-Fi and Ethernet don’t. Open a project that sets CONFIG_LORA or names a Semtech part and the LoRa knowledge loads on its own.

​
What is supported

​
LoRa or LoRaWAN

Settle this before writing a line. The answer to almost every question changes with it. “I want a LoRa gateway” usually means LoRaWAN, and that is a different conversation from “I want two boards to talk”.

​
One transceiver is not a gateway

The most expensive misunderstanding on this subject, so it comes before the parts. EU868 mandates three uplink channels across six spreading factors: eighteen combinations, and a single transceiver sits in one of them. A board with an SX1262 can be a node, a point-to-point link, a listener that hears a slice of the air, or a receiver for devices pinned to its channel. It cannot be a LoRaWAN gateway, and the agent says so rather than promising reception it cannot deliver. A real gateway needs an SX130x concentrator, which is not supported today; the knowledge says what building one takes.

​
Duty cycle binds before capacity

In Europe the mandatory sub-band allows 1% of the hour on air: 36 seconds, per device. At SF12 a 16-byte message occupies the channel for 1.3 seconds, which is about 27 messages an hour, and then the device must stop. That number decides whether a design is possible, and it is one command away: the agent works out the time on air, the effective rate and the duty-cycle budget for any spreading factor, bandwidth and payload, or sweeps the spreading factors to show the trade, before the battery life disappoints.
Before you chooseTime on air and the messages an hour the law allows, for the spreading factor, bandwidth, coding rate and payload you have in mind.
When the radio will not answerAn SX126x only ever tells you three hex words. The agent decodes a status, an interrupt word or an error word into plain words, with what to try next. It also knows that 0xFF and 0x00 are not chip states: they are a bus nobody is driving.
When you want to know what is in the airA capture in the standard packet-forwarder format becomes a report that names the devices heard and what their frame counters did, and states what fraction of the band was actually listened to. No keys and no network server needed: a LoRaWAN frame carries its address and counter in the clear.

Three jobs that are usually guessed at, each computed instead.

​
What the knowledge covers

  • The radio. Spreading factor, bandwidth and coding rate as a trade rather than a default; sensitivity, RSSI and why SNR is negative; bands, duty cycles and the transmit limits that belong in the code, region by region.
  • The parts. The SX126x command set and the four traps that cost days. The SX127x family and the band split that decides which modules can talk. The LR2021, LoRa Gen 4, with its multi-SF receiver, LR-FHSS and S-band, and the driver that does not exist yet. The SX130x concentrators, and what a real gateway would take.
  • LoRaWAN inside. Join, class A receive windows, frame counters, MAC commands, payload codecs, keys and their byte order, and provisioning a third-party device: where the hours are usually lost.
  • Your own protocol. What non-LoRaWAN LoRa packets look like in the field, how to describe one, and how to encrypt it when you own both ends.
  • What is out there. What LoRa devices are deployed, what one transceiver can hear of them, and why two LoRa radios cannot hear each other.
  • Building. A sensor on any MCU with any SX12xx; a receiver with a device registry, de-duplication, gap and liveness tracking and honest coverage; a two-node link across the two SDKs; a node on nRF Connect SDK or ESP-IDF, with the driver you have to choose.

​
Starting a LoRa project

1

Say which one you mean

LoRa between your own boards, or a LoRaWAN end device for a network. The agent asks if the project does not say.
2

Prove the radio before the driver

An SX126x answers over SPI with a status byte. Read it first; a bus that idles high has cost people days.
3

Choose the parameters on purpose

Message size, duty cycle and range set the spreading factor. Work out the time on air before you commit to it.
4

Treat it as a product

A connected device is in scope for the Cyber Resilience Act.

​
On the Fanstel gateways

The LEW840x’s M262X840XE card carries a second radio beside the Bluetooth one: an LR62XE, a Semtech SX1262 with a power amplifier for the 868 and 915 MHz bands, with its own antenna connector. Today’s LEW840x firmware does not drive it. The knowledge for bringing that radio up and running a LoRa scanner on the gateway is opened per account on request, and the firmware line is in preparation. See the LEW840x. Fanstel’s LBG20 family lists a LoRa option built on the LR2021, which would put LoRa sensors on the same gateway as satellite NB-NTN. There is no nRF Connect SDK driver for the LR2021 yet, so that is a port before it is a product. The knowledge already says what it would take. See satellite IoT.

Cellular IoT on nRF91

LTE-M, NB-IoT and GNSS bring-up, the board shell and the modem trace.

Satellite IoT: NB-NTN

The same nRF9151 modem reaching a satellite where there is no cell.