When builders dive into decentralized sub-1GHz messaging, the discussion often centers on unconstrained flood meshes. In a small town with a dozen nodes, flood routing works well. But as node counts climb into the hundreds, uncoordinated rebroadcasts quickly saturate available airtime, creating packet storms that drown out weak signals.
MeshCore takes a different architectural path. Rather than treating every battery-powered handheld as an active relay, MeshCore organizes its network around clear, functional node roles: Companions, dedicated Repeaters, and asynchronous Room Servers.
Understanding this separation of concerns is essential for designing high-reliability community meshes that conserve battery on handheld nodes while maintaining high packet delivery rates across expansive terrain.
01 · The Three Roles: Companions, Repeaters, and Room Servers
In MeshCore, nodes are not identical peers running identical workloads. The system divides responsibilities based on hardware capability and physical installation:
[ Handheld Companion ] │ (Direct or 1-Hop) ▼ [ Hilltop Repeater ] ◄──────► [ Hilltop Repeater ] │ │ ▼ ▼[ Handheld Companion ] [ Room Server (BBS) ]- Companion Node: The user-facing edge device. A Companion connects to a phone or PC over Bluetooth, serial, or Wi-Fi. It is designed to be carried in a pocket or backpack, prioritizing battery sleep states. In standard deployment models, Companions do not repeat transit traffic for third parties by default, preventing a handheld in a basement from wasting battery attempting to relay packets it barely heard.
- Repeater Node: A fixed, autonomous station installed at a high-elevation site (a rooftop, tower, or mountain peak) powered by solar or mains electricity. Repeaters listen continuously for transit packets and rebroadcast them across line-of-sight backbone paths.
- Room Server: A specialized node acting as a persistent local bulletin board or group mailbox. When users are offline or out of radio range, messages posted to a Room are stored on the server. When a client node re-enters coverage, it queries the Room Server to fetch missed messages asynchronously.
02 · Routing Mechanics: Flood Discovery vs. Explicit Path Relaying
MeshCore balances broadcast discovery with deterministic path routing:
Discovery & Broadcasts
When a node broadcasts public channel traffic or seeks a new contact, it uses a bounded flood mechanism with duplicate packet suppression. Packets carry unique sequence identifiers, and nodes maintain a short-term memory of seen packets to prevent infinite loops.
Deterministic Multi-Hop Direct Messaging
Unlike naive flood networks that echo every private text message across every node in hearing range, MeshCore supports explicit multi-hop direct routing:
- A direct message can carry a designated relay path through specific repeaters.
- Intermediate repeaters inspect the packet header, match their node address in the path vector, decrement the remaining hops, and forward the frame.
- This deterministic pathing drastically cuts overall RF duty cycle, keeping the channel quiet for other users.
While early project FAQs noted that Companions never repeat, released companion firmware (v1.17+) includes an optional user preference allowing mobile nodes to act as ad-hoc repeaters when desired. In dense networks, however, leaving Companion repeating disabled remains best practice to avoid redundant transmissions at ground level.
03 · Wire Protocol & Cryptography: AES-128 and HMAC Integrity
MeshCore implements its own cryptographic envelope tailored for low-bandwidth 8-bit and 32-bit microcontrollers:
- Channel Encryption: Group communications use symmetric AES-128 encryption. All members of a channel share the pre-configured channel key.
- Message Integrity: The protocol uses an Encrypt-then-MAC construction with HMAC-SHA256, truncated to a compact Message Authentication Code (MAC) in the payload header to save precious byte overhead on air.
- Direct Peer Keys: 1-to-1 conversations establish a shared secret via public-key exchange routines, ensuring that only the sender and recipient can decrypt the payload.
- Room Server Trust Model: A Room Server is a trusted endpoint for that room. Because the server must store, index, and distribute messages to multiple subscribers, messages posted to a room are decrypted and processed by the Room Server software. Encryption to a room protects the packet in transit over the air, but the server operator can view room content.
| Message Type | Encryption Scheme | Integrity Mechanism | Wire Overhead |
|---|---|---|---|
| Broadcast / Discovery | Plaintext or Channel Key | Truncated HMAC / CRC | Minimal (~6–10 bytes) |
| Group Channel | AES-128 (Shared Key) | HMAC-SHA256 (Truncated) | Compact (~12–16 bytes) |
| Direct Peer Message | AES-128 (Derived Secret) | HMAC-SHA256 | Moderate (~16–20 bytes) |
| Room Server Post | Encrypted to Room Key | Server MAC verification | Structured (~20–28 bytes) |
04 · Airtime Economics: Benchmarking Mesh Flooding vs. Role-Based Routing
The primary constraint of sub-1GHz communications is channel capacity. Consider what happens when twenty active users share a single LoRa channel:
Scenario: 20 Active Handheld Nodes, 1 Message Every 2 Minutes----------------------------------------------------------------------Uncontrolled Flooding: 20 nodes x 3 hops = 60 RF transmissions per cycle. At 500 ms per transmission = 30 seconds of continuous channel occupancy! Channel duty cycle = 25%. Packet collision probability > 40%.
MeshCore Role-Based Model: 20 handheld Companions do not repeat. 2 hilltop Repeaters handle transit = 40 RF transmissions per cycle. Deterministic direct paths reduce repeat count to 1 or 2 hops max. Channel duty cycle < 10%. Packet collision probability < 12%.By decoupling user clients from transit infrastructure, MeshCore preserves channel bandwidth for actual data rather than self-inflicted packet collision cascades.
05 · FCC Part 15 Compliance and Power Ceilings
In the United States, MeshCore operates across the 902–928 MHz ISM band under 47 CFR Part 15:
- Single Frequency Channels: Like other peer-to-peer LoRa firmware, MeshCore typically tunes to a fixed channel bandwidth (125 kHz or 250 kHz). Because it does not continuously hop across 50 discrete frequencies, it does not operate as a Frequency Hopping Spread Spectrum (FHSS) system under §15.247(a)(1)(i).
- Digital Modulation Rules: A 125 kHz or 250 kHz signal does not meet the 500 kHz minimum 6 dB bandwidth required for the standalone 1-Watt digital modulation shortcut (§15.247(a)(2)).
- Repeater Station Power: When setting up a rooftop or solar repeater station, ensure your transceiver module operates within its certified conducted power limits (commonly +14 to +22 dBm). If you install an antenna with gain exceeding 6 dBi (such as an 8 dBi omnidirectional collinear), you must derate your transmitter’s conducted output to ensure total EIRP stays within lawful boundaries.
06 · Field Deployment Recommendations
- Elevation Over Power: A 100 mW (+20 dBm) repeater on a 30-foot mast with clear Fresnel zone clearance will outperform a 1 Watt (+30 dBm) node stuck inside an attic window every single time.
- Isolate Room Servers: If you run a Room Server, connect it to a high-capacity repeater via a reliable direct RF path or local Ethernet bridge to keep synchronization queries from clogging remote simplex links.
- Battery Management for Repeaters: A standard SX1262 listening continuously draws roughly 5–8 mA. Combined with an ESP32 or nRF52 microcontroller, budget at least 15–25 mA continuous standby draw. A 10W solar panel and a 3000 mAh LiFePO4 cell provide reliable year-round operation in most climates.