Meshtastic: decentralized communication with low-power devices

Many of us enjoy uninterrupted access to mobile networks. However, in remote areas or during emergencies, that connectivity may not always be available. For such scenarios, Meshtastic offers a decentralized wireless mesh network with open-source firmware that runs on affordable, low-power devices. At FOSDEM 2025, the Meshtastic project was represented by one of its core developers, Thomas Göttgens, who gave a talk, "Meshtastic - off-grid communication for everyone", in the Radio developer room (devroom).

In the introduction, the devroom organizer made the disclaimer that Meshtastic relies on proprietary and patented technology, referring to the LoRa communication technology developed by Semtech. "But it is cool", he added. Göttgens then started his talk by emphasizing that the project is fully open source, except for the radio chips that use the proprietary and patented technology.

LoRa, an abbreviation for "Long Range", is a wireless communication protocol in the unlicensed radio spectrum, enabling long-range transmissions with low power consumption at slow data rates. Depending on the configuration, the maximum data rate can reach 21.88Kbps, including protocol overhead, thereby making the effective net data transfer rate even lower. Nonetheless, this bandwidth is more than enough to send text messages, location information, or sensor data to nearby users, which is precisely what Meshtastic offers.

Meshtastic implements a mesh network architecture layered over point-to-point LoRa connections. The nodes (devices) connect either directly or through intermediary nodes that rebroadcast messages to extend communication reach. By default, Meshtastic nodes send their messages with a maximum hop count of three. With each retransmission, this hop count is decreased by one. When a node receives a message with a hop count of zero, the node will not rebroadcast it.

So why would you use Meshtastic? Göttgens provided some examples, such as camping trips or festivals, "like Burning Man", where mobile-network coverage can be unreliable, allowing users to stay connected. Moreover, in disasters where mobile networks are down, Meshtastic enables users to establish their own local mesh network.

Device roles

Each Meshtastic node can have one of several roles. Initially, Göttgens explained, there were only two roles: Client and Router. In Meshtastic 2.0, additional roles for specific situations were introduced. For instance, there are now roles for clients that don't rebroadcast messages and for clients that don't even announce their existence. The Tracker role optimizes the device for location sharing, the Router extends network coverage by relaying messages, and the Repeater acts as a Router while remaining invisible to other nodes.

Göttgens gave special attention to the Router role, noting past and continued misuse. A Router always rebroadcasts packets, while a Client only rebroadcasts packets if it has not heard another node do so. To maximize coverage, a Router should be placed in an "exposed position". Göttgens emphasized: "Please, a Router is not something you put on your rooftop. An exposed position would be a radio tower, a mountain top, or a tall building — and by tall I mean at least twenty stories." Placing a Router on a rooftop contrary to this advice won't improve coverage. By rebroadcasting messages from this non-optimal position, Göttgens explained, "it will eat a hop", thereby decreasing coverage.

So, how far can Meshtastic communicate? Göttgens showed a range record of 331km, established between mountain tops in Northern Italy and Slovenia. Of course, this is an ideal scenario with optimal location for two sensitive antennas; even then, receiving a message takes several seconds. For personal range testing, Göttgens suggested the Meshtastic Site Planner, where a node's coverage can be simulated after choosing a location and entering information such as the node's antenna gain and height. Then the map will show where there are gaps in coverage and which locations are ideal to place Routers for improving coverage.

Encrypted communication

Meshtastic messages are encrypted with an AES-128 default key that is baked into the firmware. This publicly known key "is only used for discovery". The key can be changed to create a private network. Meshtastic supports encryption up to AES-256. Additionally, eight encryption keys can be programmed into a Meshtastic device for communication with different user groups. For direct messages between individuals, users can set up public and private keys. This requires a key exchange first, which is done automatically during the first communication. If a node's key changes in subsequent communications, the Meshtastic app indicates this in red as a warning.

Licensed ham radio operators can enable a special ham mode in the Meshtastic firmware and set their call sign in the app. This mode allows up to 10W of transmit power, depending on the license class and country, as well as higher-gain antennas for improved coverage. However, ham mode disables encryption, as it is typically prohibited by law for ham radio. This also means that direct messages are no longer encrypted. Additionally, ham-mode nodes won't forward encrypted packets to avoid accidentally routing traffic for unlicensed users. In practice, this means that such nodes don't join the default mesh. The firmware will also publicly broadcast the user's call sign every ten minutes, as legally mandated.

Commodity hardware

Getting started with Meshtastic shouldn't cost that much. In practice, any microcontroller with a LoRa chip can serve as a Meshtastic node. According to Göttgens, the cheapest option is the XIAO ESP32S3 & Wio-SX1262 Kit, priced at $9.90. This thumb-sized development board features an ESP32S3 microcontroller paired with a daughter board that has an SX1262 LoRa chip. On the pricier side, Göttgens highlighted the WisMesh Pocket V2 and the Lilygo T-Echo, both equipped with a power-efficient Nordic nRF52840 microcontroller and a display. Another notable device is Seeed Studio's SenseCAP Card Tracker T1000-E for Meshtastic, which includes a GPS, temperature sensor, and accelerometer within a package the size of a credit card, which lasts a day or two on a single battery charge.

Meshtastic's web site provides a list of supported devices, as well as instructions for flashing the firmware onto a device. Once completed, you can pair a device over Bluetooth, WiFi, or USB serial to a phone running the Meshtastic app (available for Android and iOS). There's also a web client for controlling a node over Bluetooth from a computer.

Standalone hardware solutions also exist, allowing devices to send and receive messages without having to pair them to a mobile phone. A third option are single-board computers, such as the Raspberry Pi and the OpenWrt One router. Meshtastic runs as a daemon on those devices (as well as on any Linux system), with a LoRa radio connected via SPI or USB.

Development

The Meshtastic project has an organization on GitHub with almost a hundred repositories; the firmware repository is the most popular one. Göttgens invited everyone to join the project's Discord server for help. Building the Meshtastic firmware requires the PlatformIO development environment, commonly used in Microsoft's Visual Studio Code or its open-source distribution VSCodium. PlatformIO can also be used from the command line.

The firmware is based on the Arduino software stack, supporting multiple microcontroller boards across various architectures via its hardware abstraction layer. Additionally, the Meshtastic project ported the Arduino API to Linux through the Portduino project, enabling Meshtastic to run as a daemon on Linux. Meshtastic uses Protocol Buffers for message serialization, as well as for storing the node's configuration.

Audience questions

Göttgens got a lot of questions after his talk. The first one concerned the expiration date of the LoRa patents, which Göttgens couldn't answer. He did mention that the protocol has been reverse-engineered and implemented in a GNU Radio module, gr-lora_sdr. With this module, users can send and receive Meshtastic packets using software-defined radio (SDR), but Göttgens called this "not as good as the Semtech radios, as SDR is always inferior to a real radio hardware chip."

Another question was about the difference between Meshtastic and other LoRa-based networks. "Most networks use LoRaWAN, which is a layer above the LoRa network with a hub-and-spokes architecture", Göttgens explained. Thus, sensors in LoRaWAN networks such as The Things Network or Helium transmit data to centralized access points. Meshtastic, on the other hand, establishes a peer-to-peer network on top of the LoRa physical network layer.

When asked whether Meshtastic handles mobile and fixed nodes differently, Göttgens said that the protocol assumes mobile nodes. The nodes don't build a routing table, because, Göttgens explained, "Meshtastic just doesn't have the bandwidth to exchange routing tables". He added that the developers did try to implement routing tables, but this didn't result in better performance than the current approach.

Regarding scalability, Göttgens clarified that the default settings don't scale well, as they are optimized for range. "As soon as a local community grows beyond 30 to 40 nodes, you should switch your settings." Göttgens gave an example about what's possible: "We created special firmware for DEF CON, and we had 800 nodes on the network there, communicating without any problems."

Using Meshtastic

Inspired by Göttgens's talk, I bought two of Seeed Studio's aforementioned card trackers to experiment with the technology. With its default settings, Meshtastic's mobile app allows chatting with nearby users on the public channel with the built-in encryption key. Initially, I didn't detect any other Meshtastic nodes around, until on the second day I received a few playful messages, like "Hi from the Sky 👋😀🛫", presumably from a Meshtastic enthusiast aboard a plane.

The firmware is composed of modules to expand the device's functionality. One such module is Telemetry to send sensor data. If a compatible sensor is connected to an I²C bus on the device, the Meshtastic firmware with the Telemetry module enabled automatically detects it at startup. The node then periodically sends the sensor data to the network, where other nodes can pick it up and process it. In his presentation, Göttgens showed some Grafana dashboards with telemetry information (e.g. temperature, humidity, battery voltage). Data can also be extracted by bridging the mesh network to MQTT, a lightweight publish/subscribe messaging transport protocol. Using this, Meshtastic devices can be integrated into various home-automation systems like Node-RED and Home Assistant, which I'll certainly explore.

To test how useful Meshtastic would be for me, I enabled the Range Test module in both of my card trackers. I left one at home sending a packet every 30 seconds, while driving around in my car with the other one paired to my Android phone. After the trip, I downloaded a CSV file from the app with all of the GPS coordinates from the tracker and imported the file into uMap to visualize the data. In the rural area where I live, I measured a range of around 1km (with uMap's measure distances tool), which isn't bad considering I used the internal antennas inside my car. I've already ordered other Meshtastic devices with external antennas to see how far they'll go.

[While I was unable to attend FOSDEM in person, I watched the live-stream of the talk.]