LoRa is a modulation: Semtech's chirp spread spectrum, operating in sub-GHz ISM bands, trading data rate for range and power.
LoRaWAN and Meshtastic both use it, and they're architecturally opposite. They get discussed interchangeably, which does neither of them any favours. Both run on tarmac, and so do a bus route and a rally stage.
LoRaWAN is a star with a server¶
Devices talk to gateways. Gateways forward to a network server. The network server handles deduplication (several gateways often hear the same packet) and adaptive data rate, and in the 1.0.x deployments that dominate it also manages session keys. LoRaWAN 1.1 moves the join to a separate join server, which changes who holds the keys rather than whether somebody does. An application server sits behind that.
Devices join via OTAA, deriving session keys from a root key, with the
operator's infrastructure as the authority. There's a DevEUI, a JoinEUI and an entity whose
job is deciding whether you're allowed on.
The properties that follow:
- Range is gateway-to-device, which can be kilometres, and your coverage is whatever your gateways cover.
- Device power consumption is excellent. Class A devices transmit and then open two short receive windows, sleeping the rest of the time. Years on a battery is real.
- There's an operator, whether that's you or a public network.
- Downlink is constrained, which surprises people. You can't generally reach a Class A device on demand; you wait for it to transmit.
Meshtastic is peers with no server¶
No gateway, no network server, no join procedure. Nodes relay for each other, and your reach is a function of how many nodes sit between you and the destination.
The properties that follow:
- Coverage is emergent. It's whatever the node density gives you, and it changes as people move about.
- Power consumption is worse, because a relaying node has to listen.
- There's no operator and no authority. A node is its key.
- Capacity is low and shared. Every relay costs airtime, and duty-cycle limits in ISM bands are a hard constraint. A busy mesh congests.
When each is right¶
LoRaWAN suits fixed sensors reporting small amounts of data where you control the coverage or can buy it: utility metering, agricultural sensing, building monitoring. The star topology and the sleeping devices are right for that job.
Meshtastic suits places where there's no infrastructure and none is coming, and where the participants move: remote terrain, event coordination, resilience when the other networks are down.
They overlap far less than the shared radio suggests.
The duty cycle constraint both share¶
This one is routinely discovered late, so know it early. ISM band regulation limits transmit duty cycle; in Europe commonly 1% in the relevant sub-bands.
That's a hard ceiling on how much either system can say, and it's why LoRa is for telemetry and short messages rather than anything resembling bulk data. A design that assumes it can send whenever it likes will work beautifully on a bench and fail a regulatory check.
The price of coverage is where the radio argument becomes a human one.
A LoRaWAN gateway costs a few hundred pounds and covers a few kilometres. That means a farm, a university campus, a canal trust, a parish council can own its own network outright, with no monthly bill and no contract, and put two hundred sensors on it. The thing that becomes cheap is measuring a place. River levels across a catchment, soil moisture across a holding, temperature in every flat in a block to find the ones with damp, bin levels, bridge strain, bat activity. These are all projects that previously needed either a cellular subscription per device or a cable, and the subscription is what killed them. The same hardware in a lower-income country does the same job without requiring a mobile operator to have found the area worth covering.
Meshtastic answers a different question: what works when nothing works. A network that comes into being because people turned up with nodes, with no operator to bill and no infrastructure to fail, is the right shape for a flooded valley, a mountain rescue, a festival, a power cut lasting a week. Here at AxisOps we think the resilience case is badly undervalued because it is only needed occasionally. The plans most organisations hold for the loss of mobile coverage amount to hoping it does not happen.
For engineering, the lesson that generalises beyond radio is in the duty cycle. A hard regulatory ceiling on transmission forces you to decide what is worth saying, and designs built under that constraint are better: event-driven rather than polling, deltas rather than full state, local decisions rather than a round trip to ask permission. Plenty of systems with no radio at all would benefit from being written as though airtime cost money.
Ownership follows the architectural split, which is why these two are worth contrasting rather than comparing.
For LoRaWAN it is the network server. Whoever runs it holds the routing, the network session keys, every device's traffic metadata and the decision about who is allowed on the network. Under 1.0 it also holds the join authority and the application keys. One reason 1.1 exists is to split those off, into a join server and application keys the network server never sees, wherever a deployment runs 1.1. Use a public network and you have a telecoms relationship with everything that implies: coverage you do not control, a price that can change, a per-device fee and a company that knows where your sensors are and what they report. The devices are cheap and the dependency is not. The good news, and the reason we keep recommending it, is that the network server is software you can run yourself on a small machine, and the open implementations are mature. A LoRaWAN estate can be entirely yours, gateway to application, with nobody to pay. That is a choice most deployments do not realise they are making, because the hosted option is the one in the quick-start guide.
The pattern to watch is the quiet one: hosted network servers are free at the scale where you evaluate and priced per device at the scale where you depend on them. By then the join credentials, the device provisioning and the integrations all live in somebody's console, and the migration is a site visit to every sensor. Decide this on day one, because it is cheap on day one and expensive forever after.
Meshtastic has no such chokepoint, and that is its reason to exist. No operator means nobody to charge you, nobody to shut it down, nobody to serve an order on and nobody holding a list of participants. The cost is that you get no guarantees at all: no coverage commitment, no capacity, no delivery, and the network exists only while people keep their nodes on. That is an engineering trade, not an ideological one. What we would say is that the option of a network with no owner is a thing a society should keep, in the same way as footpaths, and it survives because the hardware is cheap and the firmware is open rather than because anyone is defending it.
The limit of both¶
Bandwidth. These are kilobits, and often hundreds of bits per second at long range and high spreading factors. Any design that drifts towards "and then we send the image" has left the technology somewhere behind it.