Blog

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.

MeshRoute is no longer just a protocol proposal. It is working firmware, a simulator, and a growing body of tests—and it is time to start showing the work while it is still being shaped.

I have spent much of this year building quietly: implementing the protocol, creating deterministic simulation scenarios, putting firmware on real LoRa boards, and fixing the uncomfortable edge cases that appear when an elegant design meets timing, radio behavior, and constrained hardware. This blog is where that process becomes public.

The problem I wanted to explore

LoRa offers extraordinary range from small, inexpensive radios, but it does so with very little shared airtime. In Europe, deployments often operate inside duty-cycle limits that can be as low as one percent. That makes every transmission a resource decision.

Flood-based mesh designs are attractive because they are simple and resilient in small networks: a node repeats what it hears and the message spreads. The difficulty appears as density grows. More neighbors produce more repetitions, more contention, and more pressure on the same narrow radio channel. The network consumes its scarce resource fastest when the topology becomes busiest.

MeshRoute starts from the opposite conviction: airtime is precious, so a mesh should learn where traffic needs to go and send it along a deliberate path. That choice introduces its own costs. Routes must be learned, refreshed, and repaired. A routed network can accept more latency in exchange for fewer unnecessary transmissions. MeshRoute is an attempt to make that trade honestly and measure the result.

A useful network can be small

Scale matters, but I do not think usefulness should require a city-wide community of nodes. A hiking group, field crew, event team, or search group may have only a handful of radios. Four radios should already be a complete network.

That is why MeshRoute treats teams and mobile identities as first-class protocol concepts. A team has its own identity space and encrypted communication. A roaming member keeps a stable cryptographic identity while the fixed network tracks which home node can currently reach it. When the member moves, the attachment point can change without forcing the person behind the radio to become a different identity.

The same protocol also supports layered meshes connected through gateways. Local networks can use their own radio parameters and routing state instead of turning every participant into part of one enormous flood domain.

The simulator came first

MeshRoute began with a simulator because routing algorithms are easy to admire in a diagram and hard to trust on a radio. Real systems include asymmetric links, changing signal quality, radio turnaround time, channel contention, sleeping or failed nodes, and independent timing. If those effects are absent, a simulation can prove the behavior of a world that does not exist.

The development process therefore uses deterministic simulation scenarios alongside native tests and hardware checks. Important scenarios act as regression gates: delivery behavior, failure handling, team separation, mobile registration, cross-layer traffic, and other protocol properties must remain measurable after a change. When the model becomes more realistic and exposes a defect, the right response is to fix the protocol or the test—not to hide the result.

Where the project stands

The core protocol and firmware are working and are approaching a first public release. Deliberate routing, team communication, mobile registration, and gateway mechanisms are implemented. Firmware is being exercised on test hardware, and a companion iPhone application is under development.

It is also honestly pre-release. Interfaces and wire details can still change. Hardware validation is ongoing. Installation and onboarding are not yet ready for someone who simply wants to flash a board and trust the result. MeshRoute has not been deployed beyond test hardware and should not yet be treated as a safety-critical emergency system.

What I will publish here

The plan is to write about the parts of the project that can be checked rather than merely announced: the airtime mathematics behind routing instead of flooding, simulator realism that uncovered protocol bugs, one-way radio links, turnaround timing, roaming team identity, layered networks, cryptography under a small frame budget, and the testing discipline needed to change a mesh protocol without losing track of what changed.

Some posts will describe successes. The more useful ones may describe an assumption that failed, the measurement that exposed it, and the change that survived afterward. Each technical article should carry a receipt: source, a repeatable simulation, or concrete numbers.

The source and current documentation are already available on GitHub. The first release is still ahead; this blog will document the path to it in public.