MeshRoute is a working communication protocol and firmware built on LoRa technology, approaching its first public release.
The core idea is to create a fully decentralized and scalable network that treats radio resources as scarce, valuable, and worth protecting. MeshRoute aims to minimize unnecessary transmissions while keeping communication practical in real-world, dense deployments.
📖 New here? How MeshRoute works → — a short, diagram-led walkthrough of how a message actually travels.
📖 Do you want to start from details? Frame details → — the on-wire byte layout of every frame; the behaviour behind them lives in Protocol →.
🛠️ Working on the code? Architecture → — the source-module map: where everything lives and how the pieces fit.
MeshRoute was born out of frustration with the way existing LoRa mesh solutions struggle as interest and network density grow.
Projects such as MeshCore and Meshtastic are impressive and valuable, but in dense deployments their limits become visible quickly: they consume available airtime, put heavy pressure on duty cycle limits, which in Europe are often restricted to 1%, and expose the practical inefficiency of flood-based routing.
MeshRoute takes a different direction. Instead of relying on flooding, it focuses on deliberate routing and adapts protocol parameters to observed network conditions, including link quality between individual nodes and automatic spreading factor selection.
This is a trade-off: the protocol aims to use spectrum more carefully, improve message delivery efficiency, reduce unnecessary network load, and avoid collisions, sometimes at the cost of higher latency. For dense and realistic deployments, this trade-off is intentional.
MeshRoute is a young but working protocol and tool built around this idea — implemented, simulated against physics-realistic radio models, and tested on real hardware. I believe it is a promising direction for creating an efficient, reliable, and practical communication medium for enthusiasts, amateur radio operators, experimenters, early adopters, and people looking for resilient emergency communication.
The main weakness of many existing LoRa mesh solutions is the lack of deliberate routing. Flood-based communication is simple and robust at small scale, but in dense networks it quickly overuses shared airtime and overloads individual nodes.
MeshRoute takes a different approach: it builds and maintains routing knowledge, but does so lazily and carefully. This matters because LoRa networks operate under severe bandwidth limits, and nodes cannot be assumed to be permanently available. Devices may go offline, move, lose power, change link quality, or join the network later.
The protocol is therefore designed around a lightweight, self-adapting routing table. Routes are learned gradually, refreshed only when useful, and adjusted as physical conditions change, such as SNR degradation, duty-cycle pressure, node disappearance, or topology changes.
MeshRoute splits the network into layers. A local layer can contain up to roughly 250 nodes and operates with its own control spreading factor and one or more data spreading factors. Control traffic and data traffic can therefore be tuned separately, allowing the network to balance reach, airtime cost, and reliability.
Layers can be connected through gateways. A gateway participate in two layers and forward traffic between them according to an explicitly defined layer path. This makes it possible to scale beyond a single local mesh without turning the entire network into one large flood domain.
Inside a single layer, communication can use a node’s short local ID, short public-key hash, or full public identity depending on context. Across layers, messages are addressed using the destination public identity together with a defined path through gateway-connected layers.
MeshRoute treats small groups as first-class citizens of the network. A team is an encrypted overlay with its own identity space: members discover each other, self-assign team identities with distributed conflict resolution (including mediation for members that cannot hear each other directly), and exchange end-to-end encrypted direct messages and team channels — with no infrastructure at all. Four radios in the field are a complete, working network.
Team members can also be mobile nodes: a roaming device keeps a stable cryptographic identity while the network tracks which fixed node currently "homes" it. Walk out of one anchor's range and into another's, and your registration follows you — messages addressed to you are delivered through whichever home currently hears you, and the switch happens automatically based on measured link quality. A team can mix both worlds: some members homed onto a fixed network, others fully off-grid, all still reachable within the team.
This combination — encrypted teams plus roaming identity — is designed for the small-crew situations where LoRa mesh shines: hiking groups, search-and-rescue teams, event operations, and anywhere a handful of people need dependable comms with zero infrastructure.
There has been a significant progress since starting the project beginning of the year - which, btw. started by building LoRa simulator to build a right environment for testing algorithms.
Nowadays the core components are working and I'm at the stage of fixing functionality - through tests on a real hardware. That will continue for next 2 months, before creating first release.
On top - a simple iPhone application - to interact with node is being created - it will be released along with the first official release.
My name is Stanislaw Kozicki, and I am the author of the MeshRoute protocol and implementation.
During development I use automated tools to support implementation, analysis, and iteration. To be clear, the protocol design and engineering decisions are reviewed by me at every step. I have over 25 years of software development experience, and MeshRoute is developed with that level of scrutiny and care.