Same Radio, Three Completely Different Things
LoRa, LoRaWAN, and Helium get used interchangeably by people who should know better, and the confusion sends beginners down expensive wrong turns. So: LoRa is a modulation technique, not a network. LoRaWAN is a carrier-style network for battery-powered sensors that report to the cloud. Meshtastic and MeshCore are peer meshes for humans sending each other text. Helium is LoRaWAN with a cryptocurrency incentive layer bolted on, and its IoT side has shrunk by roughly three quarters from its peak.
If you want to text your friends when the cell network is down, you want a peer mesh and you should stop reading about LoRaWAN entirely. If you want three hundred soil moisture sensors reporting to a database, you want LoRaWAN and a peer mesh will frustrate you. These are not competing products. They barely overlap outside of sharing a radio chip and a chunk of unlicensed spectrum.
LoRa Is a Physical Layer, Nothing More
LoRa is chirp spread spectrum modulation. It encodes bits onto radio waves using frequency sweeps, which turns out to be remarkably robust against noise and gets absurd range for the power budget. It is a Semtech technology, it lives in the physical layer, and it says nothing whatsoever about addressing, routing, encryption, or who talks to whom.
It runs in license-free sub-GHz ISM bands: 868 MHz in Europe, 915 MHz across the Americas and Australia, 433 MHz in parts of Asia, plus a 2.4 GHz variant that trades range for data rate. Small payloads, low bit rates, long distances, tiny power draw.
Everything else in this article is a different answer to the question “now what do we do with that?”
The Three Answers
Peer Mesh: Meshtastic and MeshCore
Every node is a participant. Messages hop from radio to radio until they reach the destination, with no central authority and no internet dependency. Human-to-human text messaging, position sharing, small group chats. Nodes discover each other over the air.
There is no network operator. If you and a friend flash two radios and stand within range, you have a functioning network. Add repeaters on tall objects and the coverage area grows. Nobody bills you and nobody can switch it off.
LoRaWAN: Star of Stars
LoRaWAN is a MAC-layer protocol standardized by the LoRa Alliance, and it is architecturally the opposite of a mesh. End devices transmit to gateways. Gateways forward everything to a network server. The network server handles deduplication, device management, and adaptive data rate, then hands payloads to your application server.
Devices do not talk to each other. They do not route for each other. A sensor has no idea whether one gateway heard it or six did, and does not care, because the network server sorts that out. Encryption is AES-128 and end-to-end between device and application server.
What this architecture buys you is scale and battery life that peer meshes cannot touch. A LoRaWAN sensor can run ten years on a coin cell, because it wakes up, transmits a few bytes, and goes back to sleep without ever needing to listen for or relay anyone else’s traffic. Gateways reach over 10 km rural, roughly 3 km in dense urban. A network server handles millions of messages from thousands of gateways. You can even locate a device by triangulating it across three or more gateways with no GPS on board.
You can run LoRaWAN publicly (The Things Network) or privately on your own gateways and your own server, using identical hardware. That private option is the one home lab people usually want and usually miss.
Helium: LoRaWAN Plus Tokens
Helium is a LoRaWAN network where the gateways are owned by strangers who were paid in cryptocurrency to deploy them. The technical layer is ordinary LoRaWAN. The novelty was the incentive model: mine tokens by providing coverage, and a global IoT network materializes without a telco funding it.
The coverage genuinely materialized. The demand did not.
Side by Side
| Peer mesh | LoRaWAN | Helium IoT | |
|---|---|---|---|
| Topology | Mesh, every node routes | Star of stars | Star of stars |
| Talks to | Other radios | Gateway then cloud | Gateway then cloud |
| Needs internet | No | Yes, at the gateway | Yes, at the gateway |
| Primary payload | Human text, position | Sensor telemetry | Sensor telemetry |
| Device battery life | Days to weeks | Up to 10 years | Up to 10 years |
| Device-to-device | Yes | No | No |
| Who operates it | Nobody, or your community | You, or a provider | Strangers, paid in tokens |
| Cost model | Hardware only | Hardware plus server or subscription | Data credits |
| Works when the internet dies | Yes | No | No |
That last row is the one that decides most home lab arguments.
Duty Cycle, Dwell Time, and the Law
License-free does not mean rule-free, and the rules differ enough by region that copying a US tutorial in Europe will put you out of compliance.
In the EU, the 863 to 870 MHz band is regulated by ETSI under EN 300 220 and CEPT Recommendation 70-03. Duty cycle limits apply: 1% or 0.1% depending on the sub-band, over a rolling hour, with typical power capped at 25 mW. A 1% duty cycle means your device may transmit for a maximum of 36 seconds in any given hour. That constraint shapes everything about how you design a European deployment.
In the US, the FCC governs 902 to 928 MHz with no duty cycle limit, but a 400 ms maximum dwell time per channel and power up to 1 W. Different constraint, different design.
This matters for meshes too. A European Meshtastic or MeshCore repeater sitting in a busy channel is subject to the same duty cycle arithmetic as any other transmitter, which is one reason narrow-bandwidth presets and disciplined telemetry intervals are not just politeness.
Buy hardware for your region. A 915 MHz board is illegal to operate in the EU and a 868 MHz board is the wrong band in the US, and no firmware setting fixes a radio front end tuned for the wrong frequency.
Running LoRaWAN Yourself
The option most home lab people skip, because the marketing around LoRaWAN is aimed at enterprises, is that you can run the entire thing on your own hardware with no provider involved.
You need three pieces. A gateway, which is a LoRa concentrator with an internet uplink, available as an indoor unit for a couple of hundred dollars or as a Raspberry Pi plus a concentrator hat if you enjoy assembly. A network server, which is where ChirpStack comes in: open source, self-hostable, runs perfectly well in Docker on whatever box already hosts your other services. And your devices, which register to the network server and start reporting.
services: chirpstack: image: chirpstack/chirpstack:4 depends_on: [postgres, redis, mosquitto] volumes: - ./configuration/chirpstack:/etc/chirpstack chirpstack-gateway-bridge: image: chirpstack/chirpstack-gateway-bridge:4 ports: - "1700:1700/udp"The alternative is pointing your gateway at The Things Network, which is free for community use, handles the server side for you, and comes with the tradeoff that your data transits somebody else’s infrastructure. Both approaches use identical gateway hardware, so you can start on TTN and migrate to self-hosted later without rebuying anything.
Why bother instead of Zigbee or Z-Wave for sensors? Range. A LoRaWAN sensor at the far end of a property, in a detached barn, down a well, or on a boat at a mooring is trivially reachable, where a Zigbee mesh would need a chain of powered relays that do not exist out there. Battery life is the other reason. A Zigbee sensor eats a coin cell in months. A LoRaWAN sensor reporting every fifteen minutes can run for years.
Where LoRaWAN is the wrong tool for a home: anything you want to actuate quickly. Downlink to a sleeping Class A device only happens in a short window after that device uplinks, so “turn this on now” is not a thing LoRaWAN does well. Use it for reading the world, not for controlling it.
The Helium Reality Check
Helium is worth understanding as a case study, because the failure mode is instructive and the numbers are stark.
Helium passed a million deployed hotspots at its peak, announced back in late 2023. The IoT side has contracted hard since, and the exact size of the drop depends entirely on which number you are quoting, which matters before you trust any figure including mine. “Onboarded” counts every hotspot ever registered. “Active” counts the ones currently earning. Those two diverge enormously: Messari’s quarterly reports put network totals in the hundreds of thousands while active IoT hotspots sat in the low tens of thousands through late 2025. Blockworks publishes a live active-IoT-hotspot dashboard, and that is the number to look at rather than any total you see in a headline.
Whichever metric you pick, the direction is the same and it is steeply down. The infrastructure got built out at a pace no telco could match, and then the thing that never arrived was demand. Very few businesses turned up wanting to pay for sub-kilobit sensor connectivity badly enough to sustain that coverage.
The project responded by pivoting. Most of the focus and resources moved to Helium Mobile, a cellular offload play built on hotspots people deploy at home, where paying users exist. By May 2026 the MOBILE side captured roughly 40% of HNT emissions, up from about 25% in 2024, after a 2025 governance change scrapped the separate IOT and MOBILE tokens and started paying hotspots directly in HNT based on each subnetwork’s utility score. The IoT LoRaWAN network still runs and still works. It is no longer where the project’s attention lives.
Coverage, it turns out, was the easy half. If you are considering Helium as the connectivity layer for a project, evaluate it as what it is now: a functioning but shrinking LoRaWAN network with a token-based data credit system and an operator whose roadmap has moved elsewhere. For most home lab and small business cases, your own gateway plus The Things Network or a self-hosted ChirpStack is simpler, cheaper, and not subject to somebody else’s tokenomics.
A Note on 2.4 GHz LoRa
LoRa also exists at 2.4 GHz, and it confuses people who assume LoRa means sub-GHz by definition. The 2.4 GHz variant gets you higher data rates and worldwide regulatory consistency, since you are in the same band everywhere instead of juggling 868 and 915.
You give up the thing that made LoRa interesting. At 2.4 GHz you are back in the crowded band with WiFi and Bluetooth, and the propagation through walls and foliage is much worse. For mesh messaging or long-range sensors, sub-GHz remains the right answer. The 2.4 GHz parts have their uses in dense industrial settings and in products that need one SKU for every market, which is not the problem most readers here are solving.
Picking, Concretely
You want off-grid texting, hiking comms, or a neighborhood network that survives an outage. Peer mesh. Meshtastic or MeshCore, two radios minimum, repeaters on high ground if you want range. Nothing else on this page is relevant to you.
You want to instrument something: soil, water tanks, gates, temperature across a farm or a large property. LoRaWAN. Buy a gateway, run ChirpStack or point it at The Things Network, and enjoy sensors that outlive their own batteries’ shelf life. Do not try to make a mesh do this. A Meshtastic node burning battery to relay other people’s traffic is a poor sensor platform.
You want both. That is normal and they coexist happily. They are separate networks on separate channels using separate firmware, sharing only the band. Plan your airtime budget and site your antennas with each other in mind.
You were about to buy a Helium miner. Do not buy it for the tokens. If you want a LoRaWAN gateway, buy a LoRaWAN gateway and run it yourself.
The Short Version
LoRa is the radio. LoRaWAN is a sensor network that needs the internet to be useful. Peer meshes are for people who want to talk when the internet is gone. Helium was an interesting attempt at making the second one appear by paying strangers, and it worked right up until someone asked who the customer was.
Pick based on whether your payload is a human sentence or a battery-powered integer, and the rest of the decision makes itself.
