Documentation
Onboarding
Getting Started
Power & Battery
Hardware & Components
Build & Assembly
Radio & RF Design
Frequencies & Regulations
Firmware & Software
USB & Connectivity
GPS & Navigation
Morse & Communication
Modes & Operation
Field Operations & Rescue
Building Effectively
Build Variants
Project & Reference
Docs Build Variants Multi-Beacon Network

Multi-Beacon Network

Edit on GitHub

Deploying several beacons as a coordinated network: channel planning, interference avoidance, and what each beacon should transmit.

Multi-Beacon Network

One beacon is a signal. Several beacons in a valley are a network, with all the coordination problems that come with it. This page is the planning for a beacon network that does not step on itself.

The core problem

Two beacons on the same channel in the same area collide: their bursts overlap, and receivers hear neither. The solution is planning, because the firmware has no collision avoidance by design (see Firmware TX Scheduler).

Channel planning

BeaconsPlan
1 - 2Same channel is fine if intervals differ
3 - 5Different channels, 25 kHz apart minimum
5+A proper frequency plan (see Frequency Planning Examples)

Interval staggering

Even on the same channel, two beacons with different sleep intervals (10 s and 11 s) drift apart over time and rarely collide. The firmware supports per-beacon intervals precisely for this trick. Combined with repeat counts, staggering makes the collision window small.

What each beacon transmits

BeaconPayload
Each oneIts own identity (name/callsign)
Each oneIts own coordinates
OptionalA group identifier in the message base

The identity field is what turns a pile of beeps into a network: receivers can attribute each burst to a person. See Config Payload Format.

Verification

Deploy the network, then walk the area with a receiver or SDR and log which bursts arrive. A network that works on paper but collides in practice is a planning failure caught at the wrong time; the Outdoor Testing page has the procedure.