Under active development. Breaking changes expected. APIs, installers, and UI may shift between releases.
One drone. Multiple ground nodes. One stream.
Usable today. Early access — some pieces run behind a feature flag and APIs may shift between releases.
THE PROBLEM
One node has one line of sight.
A single ground station covers the RF bubble its antennas see. A ridge, a building, a treeline, and that coverage ends. Two relays cover both sides and the receiver combines the fragments into one clean stream.
THREE ROLES
One codebase. One config key.
Set the ground-station role to direct, relay, or receiver. The agent enables the right services and disables the wrong ones. No separate firmware.
Default
direct
ground-station receive service
- ✓A single node catches the drone on its own RTL8812EU.
- ✓Serves every pilot-facing client: HDMI, WiFi AP, USB, Android.
- ✓The cloud relay bridge runs here too. No mesh traffic.
Field placed
relay
wfb relay service
- ✓Catches the drone on its own RTL8812EU.
- ✓Forwards raw WFB-ng fragments over the mesh to the receiver.
- ✓Headless. No client services, no HDMI kiosk.
Hub
receiver
wfb receiver service
- ✓Collects fragments from every relay over the mesh carrier.
- ✓Runs WFB-ng Reed-Solomon FEC on the combined stream.
- ✓Serves the clean stream to all clients and advertises mDNS.
SELF-HEALING MESH
batman-adv does the routing.
Every relay and receiver carries a second RTL8812EU adapter running an 802.11s mesh on 5 GHz. The first adapter catches the drone. The second carries the fragments between nodes.
batman-adv is a Linux kernel mesh routing protocol. It advertises OGMv2 packets every second, detects a dead neighbor in three to five seconds, and re-routes around the failure with no operator action. Mesh identifiers are scoped per deployment so two sites on the same channel do not cross-contaminate.
The same agent binary runs the mesh carrier. No separate daemon, no custom routing code, no second service to keep in sync. When the role manager sets the role to relay or receiver, it enables the mesh carrier. When the role flips back to direct, it disables it.
CLOUD GATEWAY ELECTION
Any node with an uplink becomes the gateway.
Nodes with Ethernet, a WiFi client link, or a cellular modem advertise themselves as gateways. The receiver watches the mesh quality metric and picks the strongest path, then re-picks on failure.
A relay on a rooftop might have a cellular uplink. A relay in a valley might not. Both advertise themselves as possible gateways. The receiver watches the mesh quality metric and picks the strongest gateway. If the rooftop relay loses signal mid-flight, the receiver switches to the backup gateway in seconds. The cloud bridge stays up.
This is how a distributed deployment stays connected to the cloud relay or a self-hosted MQTT broker without requiring every node to carry its own cellular modem.
RECEIVER PROMOTION
If the hub dies, promote a relay.
Any relay can be promoted to receiver with one click in the Mission Control Hardware tab, or from the setup webapp for field work. No reboot to change role.
COVERAGE MATH
How many nodes do you need.
Coverage depends on antenna gain, terrain, and flight altitude. These numbers are planning guides, not contracts.
| Nominal range | Obstructed | |
|---|---|---|
| 1 node, 2 dBi rubber duck | 1 to 3 km | 0.5 to 1.5 km |
| 1 node, 5 dBi omni | 3 to 8 km | 1.5 to 4 km |
| 1 node, 8 to 12 dBi panel | 10 to 20 km | 5 to 10 km |
| 2 nodes overlapped, 5 dBi each | 12 to 18 km corridor | 6 to 10 km corridor |
| 3 nodes, 5 dBi each | 20 to 26 km corridor | 10 to 15 km corridor |
1 node, 2 dBi rubber duck
1 node, 5 dBi omni
1 node, 8 to 12 dBi panel
2 nodes overlapped, 5 dBi each
3 nodes, 5 dBi each
FIELD TAP-TO-PAIR
No laptop in the field.
A second node joins the mesh using only the OLED and four buttons. A Curve25519 key exchange runs over the air and the invite bundle is sealed with ChaCha20-Poly1305, scoped to the mesh.
┌──────────────────────────┐ │ [receiver] │ │ │ │ Accepting relay │ │ 60s remaining │ │ │ │ Pending: 1 │ │ Accepted: 0 │ │ │ │ B1 accept B4 deny │ └──────────────────────────┘
┌──────────────────────────┐ │ [relay joining] │ │ │ │ Scanning for mesh.. │ │ │ │ Found: │ │ ados-gs-a4b2 -52 │ │ ados-gs-1f0c -78 │ │ │ │ B1 join B4 cancel │ └──────────────────────────┘
On the receiver, open the pairing window. On the incoming relay, pick Join mesh. The relay discovers the receiver, the key exchange runs, the receiver seals an invite bundle, the relay decrypts, and the mesh comes up. The whole flow targets under 120 seconds from power-on to a live mesh, with no computer in the field.
Physical UI walkthroughVALIDATED SCENARIOS
Twelve test scenarios.
Distributed receive is feature-complete. Every scenario below has a reproducible test procedure, and field validation on a two-node rig is in progress.
Single-hop relay and receiver over the mesh carrier
Two-relay FEC repair through an obstruction
Two-hop mesh relay routing
Receiver promotion in under ten seconds
Self-healing on a relay drop
Cloud gateway on a relay with a cellular uplink
Gateway failover to a backup node
Partition tolerance and a clean re-merge
Field tap-to-pair with the OLED, no laptop
Three-node field deployment with auto-accept
Decommission and re-pair to a new deployment
Multi-site RF coexistence
One mesh. Many nodes. One clean stream.
Full setup walkthroughs, CLI reference, and mesh troubleshooting live in the public docs.
Distributed RX docs