Stage 5 In Progress — Repeater & Client Firmware

LoRa mesh that scales
from 5 nodes to 500

A from-scratch LoRa mesh protocol and firmware platform built to stay reliable as networks grow — with no infrastructure required.

Read the Docs View on GitHub

Why another mesh?

Flood-based meshes are simple and need no coordination, but channel load grows as N²·ToA/T — on default long-range LoRa settings the channel saturates at roughly 5–11 nodes at one message per node per minute.

Placing a relay on a hilltop makes things worse: it gathers more mutually-hidden transmitters into one collision domain, and carrier-sensing can’t help because a node can’t sense a signal it can’t hear. These are the failure modes Loomwave is built around.

Three-layer approach

Each layer chosen against an explicit airtime and overhead budget.

MAC

Hybrid CSMA / TDMA

Rate-capped CSMA discovery plus a TDMA data plane. TDMA solves the hidden-node problem by construction — no GPS required. Degrades gracefully to flood behavior without a coordinator.

Routing

Infrastructure-aggregated distance-vector

Flooded control is O(N²) at scale. Aggregating through infrastructure nodes makes it O(N): scheduled unicast registration with link-state only among infrastructure nodes.

Security

Per-packet AEAD

Authenticated encryption on every packet with a derived nonce and truncated tag (~16 bytes overhead). Replay protection with no synchronized clocks required.

Node roles

Separate optimized firmware per role — not one binary.

Role	Hardware	Function
CLIENT	ESP32 / nRF52 Heltec, T-Beam, RAK4631…	User endpoint via BLE/USB. Sleeps aggressively. Relays only if configured.
REPEATER	Same hardware class	Always-on relay with neighbor table and routing. Optimized for solar/battery field deployment.
INFRA	Linux SBC	Full routing with link-state. Time and slot authority. Persistent store-and-forward. Optional MQTT/IP bridge.

Roadmap

✓

Stage 1 — Analysis
Complete

Seven analysis documents with quantified airtime budgets, validated against a real ~842-node Meshtastic network in North Georgia.
✓

Stage 2 — Simulation
Complete — 2026-06-08

SimPy discrete-event model: 8 tagged results, 65 tests validating TDMA delivery (99%), O(N) INFRA-aggregated routing, adaptive modulation, and coordinator-free fallback.
✓

Stage 3 — Protocol Specification
Complete — 2026-06-10

Five RFC-normative specification documents covering the full protocol stack.
✓

Stage 4 — INFRA firmware (Linux SBC)
Complete — 2026-06-11

Secured multi-client dual-cell Loomwave network running on bench. TDMA slot jitter ±1 ms against a 3 ms guard interval. Validated in the field: Drive Test 1 (95% in-session delivery over a 34-min suburban route, 4 dead-zone recoveries) and Backbone B1.4 (INFRA↔INFRA adjacency over real RF, 46 GPS positions forwarded cross-cell at −59..−63 dBm).
5

Stage 5 — Repeater & Client firmware (ESP32 / nRF52840)
In progress

XiaoGator-Plus v0.9 first join 2026-06-12: XIAO nRF52840 + E22-900M30S (1 W) + L76KB GPS. TOFU key exchange, signed beacon, sealed REGISTER → slot 0. RAK4631 and Heltec V3 ports follow.
6

Stage 6 — Android app

News & Updates

A record of milestones as the project moves from analysis through to working firmware.

Date	Milestone
2026-06-13	Case studies published — production captures from live metro Meshtastic and MeshCore networks analyzed. Meshtastic: 19,049 packets over 77.8 h from 312 nodes across 37 MQTT gateways. MeshCore: 19,697 packets over 79.8 h from three PYMC repeater vantages. Quantifies what each protocol does well and where structural limits lie. Meshtastic case study → — MeshCore case study →
2026-06-12	Stage 5 begins — XiaoGator-Plus v0.9 — first client join on new hardware. XIAO nRF52840 + E22-900M30S (1 W) + L76KB GPS. TOFU + signed beacon, sealed REGISTER → slot 0.
2026-06-11	Backbone B1.4 — first INFRA↔INFRA backbone over real RF — bench SX1262 to mid-tower (Nebra Mesh HAT, 60 ft AGL). Adjacency held the full 400 s run; 46 client GPS position reports forwarded cross-cell at −59…−63 dBm. A client position report traveled: client → cell coordinator → backbone → second coordinator, with independent AEAD on each hop.
2026-06-11	Drive Test 1 — first fielded Loomwave cell — tower (CM3 + Nebra Mesh HAT, 30 dBm EIRP, 60 ft AGL) + T114 in a truck cab. 34-min suburban loop: 149 position reports, 95% in-session delivery, 4 dead-zone recoveries with TOFU re-join each time. Full protocol stack survived contact with the field.
2026-06-11	Stage 4 complete — secured multi-client dual-cell Loomwave network running on bench hardware. TDMA slot jitter ±1 ms against a 3 ms guard interval. Checkpoint C signed off.
2026-06-10	Checkpoint C — Stage 3 spec reviewed and signed off; Stage 4 INFRA firmware authorized.
2026-06-09–10	Stage 3 complete — five RFC-normative protocol specification documents covering the full stack.
2026-06-09	Checkpoint B — simulation results validated; design confirmed; specification work authorized.
2026-06-08	Stage 2 complete — 8 tagged simulation results, 65 tests. Key findings: flood collapse reproduced, TDMA achieves 99% delivery, O(N) INFRA-aggregated routing validated, adaptive modulation and coordinator-free fallback confirmed.
2026-06-08	Checkpoint A — Stage 1 analysis reviewed and signed off; simulation stage authorized.
2026-06-04	Stage 1 complete — seven analysis documents with quantified airtime budgets. N²·ToA/T collapse model validated against a real 842-node Meshtastic network in North Georgia.

Case Studies

Production data from real, healthy LoRa mesh networks — analyzed to understand what current protocols do well, where they hit structural limits, and what that means for the Loomwave design.

Meshtastic

North Georgia metro, June 2026

19,049 packets · 77.8 h continuous · 312 nodes · 37 MQTT gateways. What a well-run Meshtastic network looks like on the air — and what no amount of tuning can fix without a protocol change.

Download PDF

MeshCore

Atlanta repeater network, June 2026

19,697 packets · up to 79.8 h · three PYMC repeater vantages. Source-routed unicast and LBT fix several Meshtastic failure modes — and reveal where the next structural wall stands.

Download PDF

Node operators wanted — Meshtastic & MeshCore

The Stage 1 analysis is grounded in data from a real ~842-node network in North Georgia, pulled from the Meshview and Malla public APIs. Those sources give breadth. A direct connection to a live node gives depth — and some things that public aggregators structurally cannot provide:

Packet loss

Measured, not modeled

Public loggers only record packets that decoded and uplinked — collisions, CRC errors, and dropped packets are invisible (survivorship bias). A node’s own counters (num_packets_rx_bad, num_rx_dupe, channel_utilization) are the only source of real loss data.

Propagation

Clean SNR/RSSI samples

Position, antenna, role, and firmware are all known exactly, so every reception is an unambiguous propagation sample with no guesswork about the receiver’s location or config — unlike a position-join from a third-party log.

Protocol behavior

Why, not just what

The node exposes the decisions it made: route type, duplicate suppression, drop reasons, per-packet airtime. Aggregated logs show what moved. The node shows why it forwarded, dropped, or deferred — which validates the protocol design directly.

Connecting to a Meshtastic node and a MeshCore node in the same area produces a controlled head-to-head comparison in one RF environment — impossible from separate public tools alone.

How to share — lowest-trust options first

Run the capture script yourself and share the CSV. A short, inspectable Python script logs heard-packet metadata and your node’s own loss counters to a zip archive. You run it locally on your Pi; we never connect to your node at all. Node IDs can be hashed with --anonymize.
Point us at your Malla or Meshview instance. These are purpose-built read-only dashboards. The per-gateway SNR/RSSI data we need is already exposed via their HTTP APIs — many operators already run one.
Tailscale with a scoped ACL (recommended for direct access). Define a tag that allows our collector to reach exactly one IP and one port, with ephemeral auto-cleanup and one-click revocation. Your node never touches the public internet. A few minutes of setup buys the tightest control of any option here.
SSH tunnel or single-IP firewall rule. Bind meshtasticd to localhost and expose it only via your SSH credentials — fully auditable, time-boxed to a window you choose, revocable instantly.

We only ever subscribe to heard-packet metadata and telemetry counters. We never send messages, change configuration, or record message content — only payload byte-length and packet type. Access is read-only, on your terms, revocable anytime.

operator_capture.py

Self-contained Python script. Runs on the Pi hosting meshtasticd. Connects only to 127.0.0.1 — nothing is exposed to the network. Produces a single .zip archive to share. One short file you can read before running anything.

Download script

To get involved or ask questions: github.com/Loomwave