Meshtastic vs LoRaWAN: What They Actually Do (and Why You'd Pick One Over the Other)

If you've gotten this far in your LoRa research, you've hit the wall where every glossary calls these two things 'LoRa networks' and walks away. The datasheets call the chip LoRa. The Alliance calls the protocol LoRaWAN. The GitHub repo calls the firmware Meshtastic. Nobody explains which layer is which, and so people spend half a forum thread arguing past each other about range and gateways and encryption when they're actually describing two different systems that share the same radio hardware. This post is the one that does the explaining.

The one-sentence version

1. LoRa — a radio modulation technique (the physics). Chirp spread spectrum on sub-GHz ISM bands. Made by Semtech.
2. LoRaWAN — a MAC protocol and network architecture that uses LoRa radios. Star-of-stars topology. Gateways, network servers, application servers. Managed by the LoRa Alliance.
3. Meshtastic — open-source firmware that also uses LoRa radios. Peer-to-peer mesh topology. No gateways, no network servers, no infrastructure required.

LoRa is the engine. LoRaWAN and Meshtastic are two different vehicles built around it. They can run on the exact same chip — an SX1262, for example — and produce completely incompatible networks. The difference is software, not silicon.

LoRa: the radio layer they share

LoRa stands for Long Range. It's a proprietary spread-spectrum modulation technique developed by Cycleo and acquired by Semtech in 2012. The key idea is chirp spread spectrum: the signal is spread across a wide bandwidth using frequency-sweeping chirps, which makes it unusually robust against noise and multipath interference. The tradeoff is throughput. A typical LoRa link moves a few hundred bytes per second at best — enough for a sensor reading or a short text message, not enough for voice or video.

LoRa operates in the unlicensed sub-GHz ISM bands: 868 MHz in Europe, 902–928 MHz in North America, 433 MHz and AS923 variants in parts of Asia and Oceania. These bands are shared with other devices under regional duty-cycle and power limits, which is why both LoRaWAN and Meshtastic have mechanisms to avoid hammering the air constantly. LoRa itself is just the modulation. It says nothing about how packets are addressed, routed, encrypted, or acknowledged. That's the job of whatever protocol sits on top of it.

LoRaWAN: infrastructure at scale

LoRaWAN is a network protocol specification maintained by the LoRa Alliance. The architecture is a star-of-stars: end devices talk to gateways, gateways forward packets to a network server over IP, and the network server routes traffic to your application server. End devices are almost always simple sensors or actuators. The intelligence lives in the network server.

A few things that follow from that architecture. Gateways are passive: they forward everything they hear without the device knowing which gateway received it. The network server deduplicates packets when multiple gateways pick up the same transmission. Join procedures (OTAA or ABP) handle device authentication. Device traffic is encrypted — session keys are derived during the join, and the spec mandates AES-128 for payload encryption and MIC verification. Power consumption can be very low because end devices spend almost all their time sleeping and only wake to transmit, then go back to sleep immediately. They don't route packets for anyone else.

The catch is the infrastructure dependency. A LoRaWAN deployment needs at least one gateway in range, that gateway needs an IP connection to reach a network server, and the network server needs to be running somewhere. You can use a public network like The Things Network for free up to a point, or you can run your own. Either way, the infrastructure has to exist before a single end device can get a message out.

Meshtastic: mesh without the infrastructure

Meshtastic is an open-source firmware project started in 2020. It uses the same LoRa chips as LoRaWAN but implements an entirely different network model: peer-to-peer mesh routing. There are no gateways. There are no network servers. Every node in range of every other node forms a flat mesh, and messages hop through the mesh toward their destination without any central coordination.

Routing is handled by a managed flood algorithm with a hop limit. Each packet carries a hop count; nodes decrement it and retransmit until either the hop limit reaches zero or the destination acknowledges receipt. More recent builds have introduced more selective routing to reduce channel congestion on dense networks, but the core premise remains: add a node anywhere in the mesh and it immediately starts routing traffic for everyone else nearby. No configuration, no join procedure, no server.

Channels in Meshtastic are AES-256 encrypted with a shared pre-shared key. The default channel ships with a known PSK (LongFast) that any Meshtastic node can join. Private channels use a key you generate and share out-of-band. There is no certificate authority and no network-level authentication — if you have the key, you're in the channel. Nodes pair to the Meshtastic app over Bluetooth for configuration and messaging. The whole thing can run with zero internet connectivity, which is the point.

Side by side

1. Infrastructure — LoRaWAN requires gateways + network server. Meshtastic requires nothing except at least two nodes.
2. Topology — LoRaWAN is star-of-stars (end devices to gateways). Meshtastic is a peer-to-peer mesh (every node routes).
3. Range — LoRaWAN gateway-to-device links can be very long (10–15 km in good conditions) because gateways run high-sensitivity receivers with proper antennas and backhaul. Meshtastic node-to-node links are typically 1–10 km depending on terrain; range can extend with more hops.
4. Latency — LoRaWAN: low and predictable for uplinks; downlinks are slower because network server must schedule a receive window. Meshtastic: variable, depends on hop count and channel congestion.
5. Throughput — Both are low. LoRaWAN end-device duty cycle limits constrain how often you can send. Meshtastic's flood routing amplifies channel usage with every additional hop.
6. Encryption — LoRaWAN uses AES-128 session keys negotiated per-device. Meshtastic uses AES-256 channel keys shared by all users of that channel.
7. Cost to deploy — LoRaWAN: gateway hardware plus ongoing server or network subscription. Meshtastic: just the nodes. No gateway, no subscription, no registration.
8. Regulatory compliance — Both operate on the same ISM bands and are subject to the same duty-cycle rules. A properly configured Meshtastic node and a properly configured LoRaWAN end device are both legal in their regions.
9. Ideal payload — LoRaWAN: sensor telemetry, small uplink messages from many devices. Meshtastic: text messaging, position sharing, and small data packets between people.

When LoRaWAN is the right call

LoRaWAN makes sense when you have infrastructure you can deploy or access, the devices are largely one-way senders, and you need to scale to many endpoints without manual coordination. Concrete cases where LoRaWAN is the correct answer:

• Agricultural monitoring — soil moisture sensors, weather stations, and livestock trackers spread across a large property feeding into a central dashboard. One gateway covers the farm.
• Smart city deployments — parking sensors, utility meters, and environmental monitoring where the city already operates or leases gateway infrastructure.
• Industrial IoT — factory floor sensors, asset trackers in a warehouse, or cold-chain monitors that need guaranteed uplinks to a backend system.
• Building automation — sensors and actuators inside a structure where a single gateway can reach everything and the data needs to land in a cloud application.
• Any scenario where you need more than a few dozen devices, need reliable downlink (commands to the device), or need to integrate with existing cloud infrastructure.

The common thread: LoRaWAN is an IoT network. It's designed to move small amounts of sensor data from many devices to a backend system. It is not designed for people messaging each other.

When Meshtastic is the right call

Meshtastic makes sense when the people using the network are also the infrastructure, when there's no existing gateway coverage, and when the use case is human communication rather than machine telemetry. Cases where Meshtastic is the right answer:

• Backcountry hiking and backpacking — a group spread across a trail where everyone carries a node. No cell, no satellite subscription required. Text messages and GPS positions hop across the group.
• Off-grid homesteads and rural properties — a small mesh with nodes at the house, barn, and gate. Walkie-talkie replacement that works when the cell signal doesn't reach.
• Events without infrastructure — festivals, races, and large outdoor gatherings where cell towers saturate. Each staff member with a node extends the mesh.
• Emergency preparedness — a neighborhood or family group with nodes staged at key locations. The mesh works even if cell and internet go down.
• Search and rescue support — teams can share GPS positions and short messages without relying on repeaters or cell coverage in remote terrain.
• Any scenario where there is no existing gateway, where the users are mobile and distributed, or where infrastructure would be impractical to deploy.

The common thread: Meshtastic is a people network. It's designed for humans to communicate with each other in the absence of normal infrastructure. It is not designed to scale to thousands of endpoints or integrate with cloud backends without additional bridging.

Can you run both on the same hardware?

Yes, but not simultaneously on a single device. An SX1262-based board can run Meshtastic firmware today, be erased and reflashed with a LoRaWAN stack tomorrow, and run Meshtastic again next week. The radio hardware is protocol-agnostic. What you cannot do is run both protocols at the same time on one device — the radio can only be in one mode, doing one thing, tuned to one configuration. A single node must pick one role.

There are projects and custom builds that attempt to bridge the two networks — a Meshtastic node that also acts as a LoRaWAN gateway, forwarding selected traffic to a network server, or vice versa. These exist but are not standard deployments and require significant custom configuration. For most users, the right answer is: pick the protocol that matches the use case, equip every participant with compatible hardware, and don't try to bridge the two unless you have a specific reason.

Why we chose Meshtastic for Beacon

The people who buy an OffGrid Beacon 2 are not deploying sensor networks. They're hiking with friends, building a family backup plan, or heading somewhere their phone stops being useful. They need to text the person ahead of them on the trail. They need to share a GPS pin when someone gets turned around. They do not need a gateway, a network server account, or a cloud dashboard. Meshtastic solves the problem without requiring any of that. Pair a Beacon over Bluetooth, share a channel key with your group, and the mesh is running before you've left the trailhead parking lot.

That's not a knock on LoRaWAN — it's an excellent protocol for what it does, and if you're managing 200 soil sensors across an orchard you should probably use it. But OffGrid Beacon is for communication between people, and for that, a decentralized mesh with no infrastructure dependency is the right answer. The OffGrid Beacon 2 ships pre-flashed with Meshtastic, ready to join any Meshtastic mesh in range, including nodes your group built themselves.