Meshtastic is an open source project that provides a decentralised means of communication, based on LoRa radio modulation in ISM bands, to carry short messages, GNSS1 positions and telemetry without relying on cellular, Wi-Fi or Internet infrastructure. Its appeal lies in its range, very low energy consumption and ease of use, with a so-called ‘mesh’ architecture ‘. This article describes the underlying technology, the network mechanisms actually implemented, the limitations and precautions for use, and positions Meshtastic against other systems. We explicitly include important nuances regarding mesh ’routing », fault tolerance, security, IP gateways and actual performance, in order to provide a technically rigorous and honest overview.
Infrastructure you can take with you
Meshtastic has two objectives: to maintain useful communication capabilities where traditional connectivity is lacking, and to do so with energy efficiency that allows for several days or weeks of battery life. In the daily life of a hiker, a team in a disaster zone, a makers’ workshop or a technician on an isolated site, the ability to broadcast short messages and position coordinates, without a subscription or the deployment of expensive gateways, creates local resilience. This resilience, however, should not be idealised: it depends on traffic parsimony, topology and radio settings, and does not translate into deterministic delivery guarantees.
Radio technology: LoRa, parameters and trade-offs
The radio backbone is LoRa (Long Range) modulation, a form of chirp spread spectrum (CSS)2 that encodes information in frequency sweeps. Robustness properties emerge from trade-offs between the Spreading Factor (SF)3, bandwidth (BW) and Coding Rate (CR)4. Increasing the SF improves processing gain and receiver sensitivity, at the cost of reduced throughput and longer transmission times; reducing the BW increases sensitivity but further reduces speed; choosing a higher CR enhances error correction at the expense of useful throughput.
The link budget is typically summarised as Lb≈Ptx+Gt+Gr−Lfs−Lm, where :
- Ptx is the transmitted power,
- Gt and Gr are the antenna gains,
- Lfs is the free space loss
- and Lm is the additional margins and losses.
Typical receiver sensitivities of −130 dBm, or even lower depending on SF/BW, combined with legal power levels of around 14 to 20 dBm in the ISM bands, allow for links of several kilometres with good radio visibility. However, it is crucial to anchor these figures in the reality on the ground: in dense urban areas, the practical range can fall below one kilometre depending on RF pollution, antenna height and the multipath environment, whereas tens of kilometres are possible in open rural areas with correctly positioned antennas and optimised parameters.
Network architecture: opportunistic broadcasting rather than sophisticated mesh routing
The popular literature readily refers to ‘mesh networks’; it is worth clarifying what this actually means in this context. Meshtastic does not implement sophisticated dynamic routing such as AODV5, BATMAN 6or OLSR7. It operates on the basis of controlled broadcasting (‘store-and-forward best effort’: opportunistic broadcasting with temporary queuing) with TTL8, packet deduplication and opportunistic relaying by nodes within range, on a mainly half-duplex radio medium with very low throughput. However, it does introduce message priorities, node roles (client, router, repeater) and simple heuristics (hop limit, rebroadcast delays), which places it between naive flooding and structured routing. Certain fixed devices, ideally placed at height and with a sustainable power supply, effectively act as a backbone, in the sense that they are more likely to relay messages, but the protocol does not formalise them as hierarchical routers or give them any special status. This approach favours simplicity and statistical resilience: message delivery is more likely in a dense mesh with diversified paths, but is not guaranteed and does not benefit from systematic end-to-end ACKs. Under high load, the limiting factor becomes collision and airtime saturation, not a lack of routing ‘intelligence’; hence the importance of keeping messages short, controlling the transmission rate and avoiding channel flooding.
Meshtastic does not calculate routes. When a node transmits a message, all nodes within range receive it and can retransmit it once according to their role and configuration, as long as the TTL has not expired. This simple mechanism (opportunistic broadcasting) creates a form of statistical ‘mesh’: multiple possible paths, no guarantees, but a high probability of delivery if the topology is favourable. Radio collisions, limited range and duty cycle impose severe constraints, making traffic parsimony essential. Fixed nodes at height play a key role: without being formal routers, they increase the probability that messages will find a viable path.
What Meshtastic is not
- It is not a mesh network in the IP sense: no dynamic routing, no routing tables, no optimised paths.
- It is not a real-time system: latency is opportunistic and not guaranteed.
- It is not a high-capacity network: throughput is very low and airtime is limited by regulations.
- It is not a military-grade secure system: content is encrypted, but radio metadata remains visible.
- It is not a replacement for LoRaWAN: no network server, no A/B/C classes, no QoS.
- It is not a digital walkie-talkie: no voice, no duplex, no reserved channel.
Meshtastic node roles: what they are… and what they are not
- Client: portable node, can send/receive, relays according to configuration.
- Router: fixed node, relays more actively, but does not calculate any routes.
- Repeater: relays everything, without a user interface. → These roles influence behaviour, but do not define a hierarchical topology.
Security: functional application encryption, observable metadata
The project implements AES 9encryption at the application level to protect message content. Historically, deployments have used AES-CTR10; recent versions and certain configurations introduce AES-GCM11, which adds data authentication in addition to confidentiality. It should be noted that AES-CTR remains historically and still frequently used in existing deployments, and that AES-GCM is neither universal nor systematically enabled. The key management model remains deliberately simple (even rudimentary): no PKI12, no automated exchange, and no forward secrecy. Confidentiality applies to content, but radio metadata (observable traffic, timings, exchange density, presence and placement of nodes) remains visible to a passive observer of ISM bands. For sensitive uses, pragmatic security hygiene is required: segmentation by channels and keys, periodic rotation, physical protection of devices. It would be inaccurate to describe this security as ‘military grade’.
Security is functional, adapted to a frugal consumer network, and does not target adversaries with advanced interception capabilities.
Hardware: frugal microcontrollers, LoRa transceivers and carefully designed antennas
Meshtastic nodes are generally based on a low-power microcontroller, very often an ESP32 to benefit from Bluetooth and easy configuration via USB, combined with a LoRa transceiver from the Semtech SX127x/SX126x family.
However, the ESP32 is not the most frugal option available: platforms such as nRF52 or RP2040 can offer lower power consumption in certain scenarios.
Integrated boards such as the T-Beam (ESP32, LoRa, GNSS), Heltec modules with OLED screens, or modular RAK WisBlock systems cover uses ranging from portable terminals to fixed relays powered by solar panels.
The choice and installation of the antenna are crucial: a model correctly tuned to the local band (433 MHz, 868 MHz in Europe, 915 MHz in North America), a sufficient ground plane and an appropriate elevation increase the range much more substantially than marginal increases in power within regulatory limits.
Regulatory framework: ISM, duty cycle and coexistence
Meshtastic typically operates in ISM bands, with constraints that vary by jurisdiction. In Europe, the band around 868 MHz imposes EIRP limits and duty cycles per sub-band, which restricts the fraction of time a node can transmit, while the 433 MHz band, although available, has different rules (lower power, distinct duty cycle).
The architecture must therefore incorporate parsimony: short messages, controlled cadence, deduplication, and multiplication of well-placed relay nodes rather than increased pressure on the same channel. Compliance with these rules is not only a legal obligation, but also a condition for coexistence with other systems that share the same frequencies.
IP integrations: useful extensions, heterogeneous ecosystem and side effects
There are IP gateways and community integrations (e.g. via MQTT13) that allow Meshtastic messages to be collected or broadcast to external services. It is important to note that these functions are extensions, not a fundamental native mode of the system. They can compromise isolation and frugality if poorly designed, introducing larger flows, dependencies on third-party services, or additional attack vectors. The ecosystem is rich but heterogeneous, with community components that vary in stability and quality; their use must be evaluated on a case-by-case basis, keeping in mind the original ‘bring your own infrastructure’ model.
Common misconceptions
- “Meshtastic covers an entire city if you put in a lot of nodes.”
→ False: duty cycle and collisions severely limit useful density.- “It’s a true mesh, so messages always find a path.”
→ No: delivery is probabilistic, not guaranteed.- “You can send long messages like on WhatsApp.”
→ No: messages are short, and long ones are fragmented, which increases losses.- ‘Encryption makes traffic invisible.’
→ The content is protected, but the presence, frequency and position of nodes remain observable.- ‘A solar relay is enough to cover tens of kilometres.’
→ Only if the antenna is well positioned, high up and in an unobstructed environment.
Performance and limitations: orders of magnitude and context dependency
Useful data rates are modest, ranging from hundreds of bits to a few kilobits per second depending on the SF/BW/CR combination, message length and retransmission policy. Latency is variable and generally non-deterministic, reflecting opportunistic relays, collisions and the absence of end-to-end ACKs. Range deserves an honest presentation: in dense urban areas, basements or narrow streets, it can be less than 1 km despite optimised settings; in open rural areas, at height and with suitably sized antennas, tens of kilometres are achievable. Performance depends heavily on topology, terrain profile, antenna altitude, polarisation, RF pollution and regulatory constraints (duty cycle). Energy consumption benefits from microcontroller standby modes and low transmission power, enabling autonomous deployments with batteries and solar panels, provided that seasonal variability and battery wear are taken into account.
Positioning relative to other technologies
Compared to LoRaWAN, which defines a centralised architecture with gateways and a network server for security and service class management, Meshtastic remains peer-to-peer, messaging-oriented and lightweight telemetry, without central orchestration. Compared to professional networks such as TETRA or digital/analogue PMRs, it offers a low barrier to entry and often superior energy autonomy, but does not provide guaranteed quality of service, controlled latency or the regulatory guarantees of dedicated systems. In amateur radio, APRS14 is a historical parallel for the exchange of positions and short messages, with specific licensing requirements and rules that distinguish it from consumer uses in ISM; moreover, the encryption used by Meshtastic is not compatible with the spirit of amateur radio bands.
LoRaWAN ≠ meshtastic network
- LoRaWAN is based on a star architecture: nodes only communicate with gateways.
- There is no relay between nodes, no routing, no opportunistic broadcasting: nodes (sensors) communicate with nearby gateways (via LoRa), which then relay the data to a network server via the Internet (WiFi, cellular, etc.).
- Meshtastic uses LoRa, but not LoRaWAN: it is an independent peer-to-peer protocol.
Deployment methodology: practical rigour and field iterations
A serious deployment benefits from following a field engineering approach: site survey, antenna elevation, choice of consistent polarisation, adjustment of SF/BW/CR parameters to local conditions, and documentation of the key policy. Measurement campaigns (mapped RSSI, delivery rates, observed latencies, cumulative airtime) allow for iteration on the placement of relays. Disciplined traffic shaping is essential to prevent node and message density from eroding the benefits of opportunistic broadcasting.
Conclusion: distributed resilience, with clarity on its conditions
Meshtastic offers local communication capabilities that combine range, energy efficiency and simplicity, freeing itself from traditional infrastructure. Its ‘mesh’ is real in spirit (nodes relay and increase the probability of delivery) but modest in its sophistication, based on broadcasting, TTL and deduplication rather than advanced dynamic routing. Its fault tolerance is statistical, without guarantee, and requires traffic parsimony as well as a favourable topology. Its security is functional, protecting message content with AES (CTR yesterday, GCM in recent configurations), but leaving radio metadata observable and relying on no PKI or forward secrecy. Its IP gateways are useful but non-standardised extensions, to be used with discernment so as not to betray its original frugality. Finally, its performance is highly dependent on the context: while impressive ranges are possible, they should not be extrapolated to all environments. Taken with this technical lucidity, Meshtastic is an elegant and robust way to provide a connectivity net where connectivity is lacking, and fertile ground for experimenting with distributed resilience on a daily basis.
References
Technical references and documentation Meshtastic
Meshtastic Project. (2025). Encryption overview: AES‑CTR and AES‑GCM implementation details. Meshtastic. https://meshtastic.org/docs/overview/encryption/ [meshtastic.org]
Meshtastic Project. (2025). Mesh broadcast algorithm and node roles. Meshtastic. https://meshtastic.org/docs/overview/mesh-algo/ [meshtastic.org], [deepwiki.com]
Academic articles on LoRa and opportunistic routing
Rösler, S., Zubow, A., & Dressler, F. (2023). Opportunistic routing in LoRa-based wireless mesh networks. Proceedings of IEEE/ACM, [PDF]. https://www.ccs-labs.org/bib/roesler2023opportunistic/roesler2023opportunistic.pdf [ccs-labs.org], [ieeexplore.ieee.org]
Udugampola, N. L., Ai, X., Li, B., Gong, H., & Seneviratne, A. (2025). A position- and energy-aware routing strategy for subterranean LoRa mesh networks. arXiv. https://doi.org/10.48550/arXiv.2510.03714 [arxiv.org]
Performance studies and LoRa propagation
Villarim, M. R., Holanda de Luna, J. V., Medeiros, D. F., Pereira, R. I. S., Souza, C. P., & Baiocchi, O. (2020). An evaluation of LoRa communication range in urban and forest areas: A case study in Brazil and Portugal. Annals of Telecommunications, 75(333–351). https://doi.org/10.1007/s12243-020-00789-w [link.springer.com]
Mena, R., Ramos, M., Urquiza, L., & Vega‑Sánchez, J. D. (2024). Comprehensive evaluation of LoRaWAN technology in urban and rural environments of Quito. Engineering Proceedings, 77(1), 28. https://doi.org/10.3390/engproc2024077028 [mdpi.com]
Obiri, N. M., & Shikunzi, H. (2023). Long-Range Wide Area Network (LoRa-WAN) connectivity and range evaluation in a rural setting. International Journal of Computer Applications, 185(3), 61–67. https://doi.org/10.5120/ijca2023922699 [ijcaonline.org]
Security and encryption
Messina, F., Santoro, C., & Santoro, F. F. (2024). Enhancing security and trust in Internet of Things through Meshtastic protocol utilising low-range technology. Electronics, 13(6), 1055. https://doi.org/10.3390/electronics13061055 [mdpi.com]
Microcontrollers and power consumption
Marius Wanscher. (2022, 13 April). Why is ESP32 BLE so power hungry? Electrical Engineering Stack Exchange. https://electronics.stackexchange.com/questions/615765/why-is-esp32-ble-so-power-hungry [electronic…change.com]
Flare Compare. (2021, 15 July). ESP32 vs. Nordic nRF52: Which microcontroller has better BLE functionality. FlareCompare. https://flarecompare.com/Microcontrollers/ESP32%20vs.%20Nordic%20nRF52… [flarecompare.com]
ISM band regulations
The Things Network. (2024). Regional limitations of RF use in LoRaWAN (EU consensus). https://www.thethingsnetwork.org/docs/lorawan/regional-limitations-of-rf-use
- GNSS (Global Navigation Satellite System)
Generic term referring to all satellite positioning systems, including GPS (United States), Galileo (Europe), GLONASS (Russia) and BeiDou (China). A GNSS receiver can use one or more of these constellations to determine its position, speed and time with high accuracy. ↩︎ - Chirp Spread Spectrum (CSS)
A modulation technique in which information is encoded in signals whose frequency gradually sweeps across a given band (‘chirps’). This approach improves robustness to interference and enables long-range communications at very low data rates, such as those used by LoRa. ↩︎ - Spreading Factor (SF)
A LoRa parameter that determines the duration of the chirp and the amount of signal spreading. A high SF increases sensitivity and range, but reduces data rate and increases transmission time. ↩︎ - Coding Rate (CR)
Coding ratio used for error correction in LoRa. A higher CR adds more redundancy, improving robustness against radio noise but decreasing the useful data rate. ↩︎ - AODV (Ad hoc On-Demand Distance Vector)
A dynamic routing protocol for ad hoc mesh networks. It establishes routes only when necessary, broadcasting route requests and building optimised paths to the destination. ↩︎ - BATMAN (Better Approach To Mobile Ad hoc Networking)
A distributed mesh routing protocol where each node does not seek to know the complete route, but only the ‘best next hop’ to each destination, improving resilience in mobile networks. ↩︎ - OLSR (Optimised Link State Routing)
A proactive routing protocol for mesh networks, based on the periodic exchange of link state information. It uses multipoint relays (MPRs) to reduce the number of transmissions required. ↩︎ - TTL (Time To Live)
A hop counter embedded in a network packet. With each retransmission, the TTL is decremented; when it reaches zero, the packet is no longer relayed. This limits propagation and prevents infinite loops. ↩︎ - AES (Advanced Encryption Standard)
A widely used symmetric encryption algorithm for protecting data. It is based on 128-bit blocks and 128-, 192- or 256-bit keys, offering a good compromise between security and performance. ↩︎ - AES-CTR (AES Counter Mode)
AES encryption mode where a counter is encrypted to produce a pseudo-random stream, which is then combined with the data. It ensures confidentiality but does not include authentication, which requires precautions to be taken. ↩︎ - AES-GCM (AES Galois/Counter Mode)
AES mode combining counter mode encryption and integrated data authentication. It guarantees both confidentiality and integrity, and is now widely recommended for secure communications. ↩︎ - PKI (Public Key Infrastructure)
A set of mechanisms for managing public keys and digital certificates. A PKI provides guarantees of identity, integrity and authenticity, but requires a centralised infrastructure. ↩︎ - MQTT (Message Queuing Telemetry Transport)
A lightweight messaging protocol designed for machine-to-machine (M2M) communications and the Internet of Things. It is based on a publish/subscribe model via a central server called a broker, which allows low-power or low-bandwidth devices to exchange data reliably. MQTT is optimised for unstable or constrained networks, thanks to low protocol overhead and configurable quality of service (QoS) levels. ↩︎ - APRS (Automatic Packet Reporting System)
An amateur radio system for exchanging positions, short messages and telemetry via digital transmissions. It relies on relays and digipeaters, and requires an amateur radio licence; encryption is prohibited ↩︎