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.
Leave a Reply