> ## Documentation Index
> Fetch the complete documentation index at: https://docs.adsumnetworks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# LoRa and LoRaWAN IoT on nRF and ESP32

> Build a LoRa node or a LoRaWAN end device on an nRF or ESP32 board with a Semtech radio. The radio, the parts, the regions, LoRaWAN from join to frame counters, and the honest answer on what one transceiver can hear.

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.

<Note>
  Needs a [free account](/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.
</Note>

## What is supported

| | |
| :- | :- |
| **Radios** | Semtech SX1261, SX1262, SX1268 and the LLCC68 · SX1272, SX1276, SX1277, SX1278, SX1279 · LR2021 |
| **Hosts** | Any nRF52, nRF53 or nRF54L on the nRF Connect SDK · any ESP32 on ESP-IDF |
| **Boards** | Any board with one of those radios wired over SPI: a development kit, a breakout module, your own design, a Fanstel M.2 card |
| **Roles** | A sensor node, a point-to-point link, a receiver for your own protocol, a LoRaWAN end device, a single-channel listener |
| **Verified** | The node path on an nRF52840 with an SX1262, on nRF Connect SDK 3.3.1 |

## LoRa or LoRaWAN

Settle this before writing a line. The answer to almost every question changes with it.

| | **LoRa** | **LoRaWAN** |
| :- | :- | :- |
| What it is | A modulation: chirp spread spectrum | A protocol, a network server and a roaming model on top of LoRa |
| What you need | Two radios | End devices, a gateway, a network server, keys |
| Who sets the parameters | You | The regional parameters document |
| Can an SX1262 do it | Yes, fully | As an end device. Not as a gateway |

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

| Part | Channels at once | Spreading factors at once |
| :- | :- | :- |
| SX1262, SX127x | 1 | 1 |
| LR2021 | 1 | Several, on one channel |
| SX1301, SX1302, SX1303 | 8 | All of them |

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.

<div className="adsum-fig">
  <div className="adsum-lanes">
    <div className="adsum-lane"><b>Before you choose</b><span>Time on air and the messages an hour the law allows, for the spreading factor, bandwidth, coding rate and payload you have in mind.</span></div>
    <div className="adsum-lane"><b>When the radio will not answer</b><span>An 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.</span></div>
    <div className="adsum-lane"><b>When you want to know what is in the air</b><span>A 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.</span></div>
  </div>

  <p className="adsum-cap">Three jobs that are usually guessed at, each computed instead.</p>
</div>

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

<Steps>
  <Step title="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.</Step>
  <Step title="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.</Step>
  <Step title="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.</Step>
  <Step title="Treat it as a product">A connected device is in scope for the [Cyber Resilience Act](/cra-readiness).</Step>
</Steps>

## 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](/supported-hardware/fanstel/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](/satellite-ntn).

<CardGroup cols={2}>
  <Card title="Cellular IoT on nRF91" icon="tower-cell" href="/cellular">
    LTE-M, NB-IoT and GNSS bring-up, the board shell and the modem trace.
  </Card>

  <Card title="Satellite IoT: NB-NTN" icon="satellite" href="/satellite-ntn">
    The same nRF9151 modem reaching a satellite where there is no cell.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.