Meshtastic Off-Grid Messaging: Flood Routing, Airtime Budgets & FCC Limits

Meshtastic has become the go-to project for off-grid communication. Whether you are backpacking outside cell coverage, building neighborhood emergency networks, or tinkering with solar nodes on your roof, the appeal is obvious: an affordable ESP32 or nRF52 board, an SX1262 LoRa transceiver, and a phone connected over Bluetooth.

Within ten minutes of flashing firmware, you can send encrypted text messages miles across town without cellular towers, satellite subscriptions, or internet backhaul.

Behind the friendly phone app, however, lies a complex distributed packet routing engine operating in a crowded, shared slice of RF spectrum. To design nodes that do not collapse local channels or violate federal emissions standards, builders need to understand how managed flood routing works, what the default encryption keys actually protect, and the critical difference between a network hop and an FCC frequency hop.

01 · The Routing Mechanics: Managed Flood vs. Next-Hop Direct Messages

Unlike LoRaWAN’s star-of-stars topology where endpoints only talk to centralized gateways, Meshtastic is a true ad-hoc mesh. Any node can act as a client, a repeater, or a router.

Broadcasts & Managed Flooding

Public channel messages and telemetry broadcasts rely on managed flooding. When Node A transmits a broadcast:

1. Every neighboring node that hears the packet inspects the packet header.
2. If the node has already processed this packet ID, it drops the frame silently.
3. If the packet is new and the hop_limit is greater than zero, the node decrements the hop_limit by one.
4. Instead of retransmitting immediately (which would cause massive RF packet collisions), the node computes a randomized backoff delay based on receiver Signal-to-Noise Ratio (SNR). Nodes with weaker reception delay longer, giving nodes with pristine line-of-sight the opportunity to rebroadcast first.
5. If a node hears another neighbor rebroadcast the same packet during its backoff delay, it suppresses its own transmission.

Next-Hop Direct Routing (v2.6+)

In older firmware, 1-to-1 direct messages (DMs) flooded the entire network just like public broadcasts. If you sent a private text to a friend two streets over, every node within three hops retransmitted it.

Starting in Meshtastic firmware v2.6, the protocol incorporates next-hop routing for direct messages:

• When two nodes exchange direct traffic, intermediate nodes monitor the path and cache the reverse route.
• Subsequent direct messages travel unicast along the discovered multi-hop path rather than echoing across the entire community.
• If a cached route fails due to node movement or battery exhaustion, the firmware falls back to flood discovery.

02 · RF Frequencies vs. Virtual Channels

One of the most common points of confusion on the workbench is the distinction between an RF frequency slot and a Meshtastic channel.

In the United States (US915), Meshtastic divides the 902–928 MHz band into numbered frequency slots spaced across the band. The default slot for the North American public mesh is Slot 20, centered at 906.875 MHz with a bandwidth of 250 kHz and a spreading factor of SF11 (the LongFast modem preset).

Physical Layer: 906.875 MHz (Slot 20) @ 250 kHz BW, SF11 (LongFast)
   │
   ├── Primary Channel (Index 0): "LongFast" (Public Key: AQ==)
   ├── Secondary Channel 1: "LocalOps" (AES-256 Key: SecretGroupA)
   └── Secondary Channel 2: "HomeSensors" (AES-256 Key: SecretGroupB)

You can configure up to eight distinct “channels” on a single Meshtastic node. However, all eight channels share the exact same physical RF frequency slot and airtime.

When you create a private channel named “TeamAlpha” with a custom 256-bit AES key, your radio does not tune to a new frequency. It broadcasts on 906.875 MHz alongside everyone else. The payload is encrypted with your custom AES key, but other nodes on the frequency still receive the raw packet, decrement the hop limit, and repeat it across the mesh—they simply cannot decrypt the payload bytes.

03 · Direct Message Security: X25519 & AES-CCM

While group channels use pre-shared symmetric AES keys, Meshtastic direct messaging (1-to-1 DMs) implements asymmetric cryptography:

1. Curve25519 / X25519 Key Agreement: Each node generates a persistent public/private keypair. When nodes discover each other on the mesh, they broadcast their public keys in NodeInfo packets.
2. Authenticated Encryption with Associated Data (AEAD): Direct messages are encrypted using AES-CCM with an ephemeral key derived from the shared secret.
3. Payload Authentication: AES-CCM provides both confidentiality and authentication, verifying that the packet was not modified in flight.

However, a node name (e.g., “!4f2a9c10” or “Summit-Repeater”) is not an identity certificate. If an attacker injects a rogue node advertising the same name, the protocol does not warn you unless you have manually verified the contact’s public key fingerprint out-of-band.

04 · Airtime Physics: Why High Hop Limits Kill Dense Meshes

LoRa sensitivity comes at the cost of airtime. Consider the transmission time of a typical 40-byte Meshtastic text message across common modem presets:

Notice that a single text message on the default LongFast preset occupies the channel for over half a second (550 ms).

If that message is repeated across three hops (hop_limit = 3), the same 40-byte packet ties up the shared RF channel for 1.65 seconds across neighboring nodes. If ten people in a metropolitan area send messages at the same time while multiple nodes broadcast telemetry every 60 seconds, the channel duty cycle hits 100%, packets collide, and delivery rates collapse.

Best Practice for Node Density:

• Keep hop_limit set to 3 or lower. Setting hop_limit = 7 does not turn your node into a global repeater; it turns it into an RF jammer for your neighbors.
• Increase telemetry broadcast intervals. Node position, battery voltage, and environment metrics should be reported every 15–30 minutes, not every 60 seconds.

05 · FCC Part 15 Realities: The “Hop” Trap

Operating Meshtastic in the United States is governed by 47 CFR Part 15. A pervasive misconception in online forums is that Meshtastic is “frequency hopping spread spectrum” (FHSS) and therefore entitled to 1 Watt (+30 dBm) conducted power under FCC §15.247.

A network hop is not an FCC frequency hop.

1. Fixed Frequency Operation: When your Meshtastic node forwards a packet, it retransmits on the exact same frequency (e.g., 906.875 MHz). It does not hop pseudorandomly across 50 discrete channels as required by 47 CFR §15.247(a)(1)(i).
2. The Bandwidth Rule: Standard Meshtastic presets use 250 kHz or 125 kHz bandwidth. Because the measured 6 dB bandwidth is below 500 kHz, it does not qualify for the 1-Watt digital modulation shortcut under §15.247(a)(2).
3. Legal Power Ceilings: For fixed single-channel operation in the 902–928 MHz band without frequency hopping, equipment authorizations typically cap conducted power well below 1 Watt (often between +14 dBm and +22 dBm depending on module certification and power spectral density tests).
4. Antenna Limits (§15.204): Adding high-gain omnidirectional fiberglass antennas (such as 8 dBi) increases effective radiated power. If your transmitter is already operating near certified limits, you must reduce conducted power to prevent exceeding EIRP limits.

06 · Field Checklist: Building a Reliable Meshtastic Node

• Tune Antenna to 915 MHz: Measure return loss with a NanoVNA. Cheap rubber duck antennas included with development boards are often tuned to 433 MHz or 868 MHz, resulting in an SWR > 3:1 and fried PA transistors.
• Lower Telemetry Intervals: Set node telemetry broadcasts (telemetry_interval) to at least 900 seconds (15 minutes).
• Cap Hop Limits: Restrict client nodes to hop_limit = 2 or 3. Reserve higher limits strictly for isolated mountain-top repeaters.
• Use Router Role Sparingly: Configure the ROUTER role only on nodes with permanent solar power and commanding line-of-sight elevation. Running multiple routers within hearing distance creates duplicate rebroadcast storms.
• Segregate Traffic with Channels: Keep chatter off the primary LongFast channel by sharing private AES-256 group QR codes with your local team.