Other LoRa Mesh Systems Beyond Meshtastic

Meshtastic and MeshCore are not the only projects that send data through multi-hop LoRa radio networks. Reticulum can use LoRa as one of several network transports, MeshCom serves an amateur-radio-oriented messaging network, and LoRaMesher gives developers a library for building their own embedded mesh applications. There are also older demonstrations and abandoned products that still appear in search results.

This survey separates usable, maintained projects from experiments and historical software. The list is deliberately short. A repository that once demonstrated three LoRa boards relaying packets is not necessarily a supported communications system today.

The LoRa mesh landscape

This article covers peer-to-peer and multi-hop systems that use LoRa radio modulation. In a multi-hop network, a packet can travel through one or more intermediate radios before reaching its destination. It does not cover LoRaWAN, which normally uses a star-of-stars architecture in which end devices communicate with gateways and a network server. LoRa and LoRaWAN are related, but they are not synonyms; the official LoRaWAN explanation distinguishes the LoRa physical radio technique from the LoRaWAN networking protocol built above it. The Things Network: What are LoRa and LoRaWAN?

MeshCore is also not repeated in detail here because it has its own guide. See MeshCore: companions, repeaters, and room servers.

Project	Primary purpose	Architecture	Typical hardware	Status in July 2026	Meshtastic radio interoperability
Reticulum with RNode	General-purpose, encrypted networking over many possible media	Cryptographic identities, automatic path discovery and optional transport nodes	Computer or phone plus an RNode-compatible LoRa radio	Active and well maintained	No
LoRaMesher	A C++ library for developers building embedded LoRa mesh applications	TDMA-based distance-vector routing	ESP32-class boards with supported LoRa transceivers	Active, but a development library rather than a ready-made consumer messenger	No
MeshCom 4.0	Text, positions and telemetry for amateur-radio communities	LoRa mesh with optional gateways and APRS/HAMNET integration	ESP32/LoRa boards and RAK WisBlock hardware	Active, with a comparatively small and regionally concentrated community	No
Ripple	Closed-group messaging, pagers and sensors	Custom LoRa mesh firmware	Selected Arduino-compatible ESP32/LoRa boards	Legacy; useful historically, but not recommended for a new deployment	No
Pycom Pymesh	Experimental IPv6-style mesh on Pycom LoRa boards	OpenThread adapted to LoRa	Pycom LoPy/LoPy4 hardware	Archived and unsupported	No

LoRa is the radio layer, not the mesh protocol

LoRa is a physical-layer modulation technique based on chirp spread spectrum. In plain language, it defines how a radio turns bits into a resilient, narrow-band radio signal and how another radio recovers those bits. It does not define user identities, addresses, message encryption, duplicate suppression, acknowledgements or routes through several nodes. The Things Network’s LoRa explanation describes this physical-layer role.

A mesh protocol adds those higher-level rules. Two projects may use the same SX1262 radio chip and the same nominal frequency but still interpret every received packet differently. A useful analogy is that two people can speak at the same volume on the same telephone line while using different languages.

Frequency is only one radio parameter. For a LoRa receiver even to demodulate a transmission, both ends generally need matching settings such as bandwidth, spreading factor and coding rate. Software may additionally choose a LoRa sync word—a short value used to distinguish one family of packets from another. Once the radio bytes are recovered, the systems must still agree on packet framing, addressing, checksums, encryption and routing. That full agreement normally exists only between devices running the same protocol and compatible versions.

Reticulum with LoRa and RNode

Reticulum, principally developed by Mark Qvist with community contributions, is a cryptography-based networking stack rather than a LoRa-only messenger. It is designed for high-latency, low-bandwidth links and can move traffic over LoRa, packet radio, serial links, local networks or internet transports. The official manual describes Reticulum as message-oriented and suitable for direct links as well as complex multi-hop networks. Reticulum: Understanding Reticulum

For LoRa, Reticulum commonly uses an RNode. RNode is open-source firmware that turns supported microcontroller-and-radio hardware into a configurable communications interface for a computer or mobile device. Users select the frequency, bandwidth, spreading factor, coding rate and transmit power appropriate to their hardware and local regulations; Reticulum does not have one worldwide LoRa frequency. The official interface guide provides configuration fields for all of these parameters and warns users to comply with the radio rules in their own country. Reticulum RNode LoRa interface

Reticulum learns network paths automatically. Selected, usually stationary systems can become transport nodes and forward traffic for others, but the documentation warns that making every device a transport node can reduce performance and reliability. Links use cryptographic identities and encrypted traffic; Reticulum can also bridge different media, such as carrying a path from LoRa into a TCP-connected segment. Reticulum: Building Networks

The hardware model is therefore different from a typical all-in-one Meshtastic handset. A common Reticulum station consists of RNode-compatible LoRa hardware connected by USB, Bluetooth or another supported link to a device running Reticulum and an application such as Sideband or NomadNet. The RNode firmware supports multiple commercial and do-it-yourself boards, but the user must confirm that a particular build target supports the radio and band required for the deployment. RNode Firmware repository

Reticulum is clearly active. Its repository publishes frequent releases, maintains a detailed manual and has thousands of GitHub stars, active discussions and several applications built above the stack. The scale is still much smaller than mainstream internet networking, but it is not a proof-of-concept repository. Reticulum releases and Reticulum discussions

Can it communicate with Meshtastic? No, not natively. Reticulum’s packet format, addressing, cryptography, path discovery and RNode interface are different from Meshtastic’s protocol. Reflashing a board may let the same physical hardware run one system or the other, but one LoRa radio cannot decode and participate in both networks merely because their frequencies match.

LoRaMesher

LoRaMesher is an MIT-licensed C++ library maintained by Joan Miquel Solé and contributors. It is aimed at developers who want mesh packet delivery inside an embedded application, not at beginners seeking a finished phone-connected messaging product.

The current 1.x design combines time-division multiple access (TDMA)—nodes transmit during assigned time slots—with a distance-vector routing protocol, in which nodes maintain information about how far destinations are through their neighbours. A network manager coordinates slot allocation and routing updates, while the protocol includes discovery, joining and recovery states. The repository documents the wire protocol and warns users migrating from the earlier 0.0.x series that version 1.0 is a complete rewrite. LoRaMesher repository and protocol overview

LoRaMesher uses RadioLib for access to the radio and FreeRTOS for embedded scheduling. Official project material lists testing with SX1262, SX1268, SX1276, SX1278 and SX1280 transceivers, typically paired with an ESP32 microcontroller. Those chips cover different possible frequency ranges, so a developer must select a board, antenna and legal operating frequency for the intended country. LoRaMesher software documentation

The project is active: its repository was updated in July 2026, has several hundred stars and dozens of forks, and the work was presented at FOSDEM 2025 and described in a 2026 SoftwareX paper. This is meaningful activity for a research/developer library, but it should not be compared directly with the user population of Meshtastic’s mobile apps. LoRaMesher GitHub organisation and FOSDEM 2025 presentation

Can it communicate with Meshtastic? No. LoRaMesher defines its own scheduling, routing and packet protocol. A developer could theoretically build an application-level gateway that receives data from both systems and translates selected content, but that would be a custom bridge, not radio interoperability.

MeshCom 4.0

MeshCom 4.0 is developed through the Institute of Citizen Science for Space & Wireless Communication (ICSSW) and contributors. It is primarily an amateur-radio project for exchanging text, position, telemetry and control data. Nodes can form local LoRa meshes, while gateways can connect separated radio areas through HAMNET or the internet. The project also uses amateur-radio callsign-style identities and integrates with APRS-related services. MeshCom Firmware

The published firmware supports ESP32/LoRa modules, RAK WisBlock boards and several other targets. Its repository documents region-labelled frequencies and LoRa parameters, but some entries—such as one 433.175 MHz value labelled for the United States—must not be treated as automatic legal authorisation. Amateur-radio privileges, licence requirements, encryption rules, permitted sub-bands and power limits vary by country. Users must check their national regulator and band plan before transmitting. MeshCom frequency and hardware documentation

MeshCom is active, with current firmware, documentation, mobile applications and a groups.io community. Its strongest visible adoption is in German-speaking and Central European amateur-radio circles, so a prospective user should first check whether local nodes or gateways exist. MeshCom community group

Can it communicate with Meshtastic? No. Its packet structure, addressing, routing conventions and network services are distinct. It may run on some of the same generic ESP32/LoRa boards after reflashing, but shared hardware is not a shared protocol.

Ripple: an important predecessor, now a legacy project

Ripple was created by Scott Powell as custom Arduino firmware for closed LoRa networks involving sensors, dedicated pagers or Android companion devices. Its repository describes several device roles and purpose-built applications rather than a single universal chat client.

Ripple matters historically because its developer later created MeshCore. In January 2025, Powell publicly announced that the new protocol then called MeshCore would supersede the direction of his earlier work. Ripple Radios: Some Big News

The original Ripple repository remains available, but its visible code and support activity are old compared with MeshCore’s current development. It is reasonable for an experienced developer to study or revive it, but new users should treat it as legacy software rather than an actively supported alternative.

Can it communicate with Meshtastic? No. Ripple uses its own firmware and protocol. It is also not wire-compatible with MeshCore simply because the same developer worked on both.

Experimental and discontinued projects

Pycom Pymesh

Pycom’s Pymesh adapted OpenThread concepts to LoRa and exposed IPv6-style mesh functions on LoPy-family boards. The surviving documentation explains router, child and border-router concepts and notes that some OpenThread functions were never implemented. Pycom Pymesh documentation

Pycom archived its libraries repository in September 2024, making it read-only. Pymesh should therefore be classified as discontinued experimental software, not as a current alternative for a new community network. Archived Pycom libraries

Small demonstrations and research implementations

Projects such as nootropic design’s LoRa Mesh Networking demonstration show how Arduino-compatible radios can relay packets and report topology to a web application. They remain useful teaching material, but the repository describes a demonstration rather than a maintained general-purpose network with current releases, applications and a deployment community.

Academic simulators, thesis code and one-off Hackaday builds are also valuable evidence that many routing approaches can run over LoRa. They should not be listed beside maintained user ecosystems unless the code, supported hardware and present development status can be verified.

Why LibreMesh and BACmesh are not in the inventory

LibreMesh is active and legitimate, but its official description identifies it as a framework for creating OpenWrt firmware for wireless mesh routers. Its documented mesh packages target Wi-Fi technologies such as 802.11s, not LoRa radios. LibreMesh may coexist with a LoRa gateway on the same wider community network, but it is not itself an OpenWrt-based LoRa mesh system. LibreMesh package selection

No current official repository or documentation for a LoRa peer-to-peer project named “BACmesh” could be verified during research for this article. Search results often mix similarly named building-automation, Bluetooth, academic and abandoned projects. Until an identifiable maintainer and authoritative source exist, listing BACmesh would create a project that readers cannot reliably inspect or install.

Why most LoRa mesh systems do not talk to each other

Different radio parameters: frequency, bandwidth, spreading factor, coding rate, preamble and sync-word choices may differ.
Different packet formats: each system places addresses, message types, hop information and checksums in different byte positions.
Different routing: controlled flooding, discovered paths, distance vectors, scheduled slots and dedicated repeaters make different forwarding decisions.
Different identity and encryption: a valid identity or encrypted payload in one system is meaningless to another.
Different applications: even if a bridge extracts plain text, it must decide how to translate channels, contacts, acknowledgements, positions and telemetry.

A dual-system gateway is possible in principle. It normally needs two radios or carefully scheduled use of one radio, software stacks for both networks and an application that explicitly translates permitted data. Such a gateway does not make ordinary nodes interoperable, and it can introduce privacy, security, regulatory and network-loop problems.

Which project should you investigate?

Choose Meshtastic when you want the largest beginner-oriented ecosystem, supported phone applications and easy access to ready-made hardware.
Investigate MeshCore when its companion, repeater and room-server model matches the network you want to build.
Investigate Reticulum when you need a general encrypted network stack that can join LoRa, Wi-Fi, packet radio and wired or internet transports.
Use LoRaMesher when you are developing your own embedded application and want a routing library rather than a finished messaging ecosystem.
Consider MeshCom when you are a licensed amateur-radio operator and an active MeshCom community exists in your region.

Before buying hardware, check the local community, supported firmware targets and legal radio band. A board sold as “868 MHz” or “915 MHz” is not universally interchangeable, and permission to use a frequency depends on the country and service under which you transmit.