LoRa makes long-range, low-power communication possible with small and affordable radios. It also imposes a hard discipline: airtime is scarce. Every transmission occupies a shared channel, and a design that works well with a handful of nodes can become noisy and inefficient as the network grows.
MeshRoute starts from that constraint. It is a decentralized communication protocol and firmware project built to move useful messages without asking every radio to repeat everything it hears. The goal is not to promise instant delivery under every condition. The goal is to make careful, explainable decisions about how the network spends its limited radio budget.
Why another approach to LoRa mesh?
Flood-based routing is attractive because it is simple: a node receives a message, repeats it, and lets the message spread through the network. At small scale this can be robust and effective. In a dense network, however, those repetitions consume airtime, increase contention, create more opportunities for collisions, and push nodes toward regulatory duty-cycle limits.
MeshRoute takes a different path. It builds routing knowledge and tries to send traffic along a deliberate route. That introduces a trade-off. Learning, refreshing, and repairing a route may add latency, especially when a node disappears or radio conditions change. In return, the network avoids turning every ordinary message into a network-wide event.
Routes that adapt to radio conditions
A LoRa link is not a fixed cable. Signal quality changes, links may be asymmetric, devices move, batteries run out, and nodes can appear long after the network has started. MeshRoute therefore maintains lightweight routing knowledge that is learned gradually and refreshed when it is useful.
The protocol can respond to measured link quality, node disappearance, topology changes, duty-cycle pressure, and the choice of spreading factor. Control traffic and data traffic do not have to use exactly the same radio settings. The intention is to balance reach, airtime cost, and reliability instead of applying one configuration to every situation.
Layers instead of one giant flood domain
A MeshRoute network can be divided into local layers. A layer can contain roughly 250 nodes and maintains its own routing state and radio parameters. Inside a layer, short local identifiers keep ordinary traffic compact.
Gateways can participate in two layers and forward traffic between them along an explicit layer path. This provides a route toward larger networks without forcing every local transmission through every participant. For cross-layer communication, the destination’s public identity travels with the defined gateway path, so the short local address does not have to pretend to be globally unique.
Teams are encrypted networks inside the network
MeshRoute is designed to become useful before a whole town adopts it. A small group can form a team: an encrypted overlay with its own identity space, direct messages, and shared channels. Four radios in the field can already be a complete network—there is no server, account provider, mobile tower, or central coordinator required for them to communicate.
Team members discover one another and assign short team-local identities. Conflicts are resolved in a distributed way, including the awkward case where two members cannot hear each other directly but another teammate can hear both. Those team identities remain separate from the fixed-node identity space. That separation is important: a number that means “member 3” inside one team must never accidentally refer to “node 3” in the surrounding network.
Messages within a team can be sent directly to one member or posted to a team channel. The content is protected end to end, while the routing layer still has enough information to move the packet. In other words, relay nodes can help carry a conversation without becoming participants in it.
A person can move without becoming a new identity
A team member may also be a roaming mobile node. The mobile keeps a stable cryptographic identity while the surrounding network tracks which fixed node currently acts as its home. If the person moves out of one anchor’s range and toward another, registration can follow the better link. Messages addressed to that person are then routed through the home that can currently reach them.
This lets a team mix different roles: fixed infrastructure nodes, members attached through a home node, and radios operating entirely off-grid. The identity belongs to the person or device, not to the temporary attachment point.
How the concept is being tested
MeshRoute is already a working protocol and firmware, but it is still pre-release software. Development began with a deterministic LoRa simulator so routing decisions could be exercised against repeatable radio conditions. The project now combines simulation scenarios, native automated tests, board builds, and tests on real hardware.
The difficult cases matter most: disappearing nodes, one-way links, rerouting, mobile registration, separated teams, and traffic that crosses layers. A simulation result is useful only if it exposes the assumptions behind the protocol, and a hardware result is useful only if it can be turned into a reproducible fix or a clearly documented limitation.
The first public release is still ahead. Hardware validation, edge-case work, release packaging, and the iPhone companion are all in progress. Until that work is complete, MeshRoute should be treated as an engineering project on test hardware—not yet as a safety-critical emergency system.
You can follow the current project status, read the source and development history on GitHub, or continue with the next development-log entry about the two client interfaces being built for MeshRoute.
Leave a Reply