01
Frequency plan
144.390 MHz
APRS
Packet radio weather + position · Direwolf + RTL-SDR RX · requires separate dongle or time-sharing
162.400–550 MHz
NOAA WX
NOAA weather broadcast · rtl_fm · recommended separate dongle from rtl_433
433.050–434.790
ISM 433
Local consumer wx stations · rtl_433 auto-decode · primary RTL-SDR use case
863–870 MHz
LoRa EU
EU LoRa band (EU863-870) — substitute for 915 where applicable range corrected from 868.0–868.6
902–928 MHz
LoRa 915 US
Primary mesh backbone — Node A · Node B · Heltec V3 drone relay · hub gateway · US ISM no-licence
1090 MHz
ADS-B
Aircraft transponder RX · dump1090 · situational awareness when drone is flying
2.400–2.483 GHz
Wi-Fi / BT / DJI
DJI OcuSync control link (Mini 2 SE) · Meshtastic BT config · hub LAN · Heltec BT
5.725–5.850 GHz
Wi-Fi / DJI alt
Hub LAN throughput · DJI O3 alt band (Mini 3) · not LoRa
RTL-SDR v3 Blog: 500 kHz – 1.75 GHz receive. Covers 433, 868/915 (RX only — not for mesh TX), NOAA, APRS, ADS-B. One dongle = one frequency at a time. For concurrent multi-band monitoring, use 2–3 dongles on separate USB buses with unique PPM offsets. Each dongle is ~$30–35.
02
Protocol reference
| Protocol | Band / layer | Role in this system | Phase | Status |
|---|---|---|---|---|
| Meshtastic | LoRa 915 MHz | Edge transport — sensor telemetry every 5–15 min. Self-healing flood mesh. Max 256-byte payload per packet. | Phase 0 | Core backbone |
| Reticulum (RNS) | Hub routing | Transport-agnostic network layer. Runs over LoRa, Wi-Fi, or any SDR. Scales without protocol rewrite. Runs alongside Meshtastic on hub, not on nodes. | Phase 0 | Hub-only — adopt |
| Mosquitto MQTT | Internal bus | All streams enter via MQTT — sensors, API data, RTL-SDR decoded packets, drone telemetry. Single ingestion point for InfluxDB and Node-RED. | Phase 0 | Required |
| InfluxDB line proto | Time-series | High-frequency tagged sensor data. Node, location, and source tags on all measurements. Grafana queries directly via Flux. | Phase 0 | Primary store |
| rtl_433 | 433 MHz RX | Auto-decodes 200+ consumer sensor protocols → JSON → MQTT. Regional 433 MHz wx stations, soil probes, rain gauges. No transmit. | Phase 0 | Adopt |
| Direwolf | APRS 144.390 | Software TNC for APRS decode via RTL-SDR. Regional wx beacon packets, position reports. Separate dongle recommended. | Phase 0 | Adopt (2nd dongle) |
| MAVLink | DJI telemetry | DJI Mini telemetry via Dronelink or DJI app. Position, altitude, battery, mode. Logged via Android app, optionally bridged to Pi #1 MQTT over Wi-Fi. | Phase 0 | Built into DJI |
| TDMA / scheduled TX | LoRa MAC | Reduces packet collisions under high node density. Not needed at 2 nodes — Meshtastic flood routing is sufficient. Add when node count exceeds ~10. | Phase 2 | Future |
| BATMAN-adv | Layer 2 mesh | Superseded by Reticulum for mixed-media LoRa+Wi-Fi mesh. RNS is purpose-built for unreliable low-bandwidth links. | — | Deferred |
| AREDN | Ham 2.4/5 GHz | High-bandwidth Wi-Fi-based mesh on amateur radio allocations. Requires Technician+ licence. Relevant for video relay and large data links at field scale. | Phase 3 | Licensed use |
| SDR MIMO / wideband | Multi-channel | Not applicable to Phase 0 hardware. Requires LimeSDR Mini 2 or USRP class. See Future/Bandwidth tab for roadmap. | Phase 2+ | Future hardware |
03
LoRa link budget
| Frequency | 915 MHz (US) / 868 MHz (EU) |
| Wavelength λ | 0.327 m at 915 MHz |
| Tx power (SenseCAP P1-Pro) | +20 dBm = 100 mW (max ISM US) |
| Tx antenna gain | +3 dBi external whip |
| Rx antenna gain | +3 dBi external whip |
| Rx sensitivity SF12 BW125 | −137 dBm (typical SX1276/SX1262) |
| Free-space path loss @ 50 m | ≈ 66 dB (20·log₁₀(4πd/λ)) |
| House wall attenuation | 10–25 dB · wood frame + brick vary widely measure in situ |
| Vegetation loss | 3–15 dB additional depending on density |
| Link margin @ 50 m + 1 wall | >50 dB — robust at SF12 |
| Estimated open-field range LOS | 2–5 km at SF12 (flat terrain, no obstructions) |
| Expected obstructed range | 50–250 m reliable — external antenna essential |
External antenna is mandatory. A house wall adds 10–25 dB of loss. An onboard PCB trace antenna on a standard Meshtastic node (typically 0–2 dBi) at this attenuation level will produce marginal or failed links between Node A and Node B. A 3 dBi whip on a 1–2 m mast outside the enclosure clears this budget with >50 dB margin at SF12.
Current as of April 2026. The LoRa mesh landscape has split into three active camps with incompatible packet formats — you cannot mix them. Choose one for a deployment. All three run on the same hardware (Heltec V3, LilyGo T-Beam, RAK WisBlock, SenseCAP). Reflashing is the only cost to switch.
01
The three main protocols
MESHTASTIC
Ad-hoc flood mesh · everyone relays · easy to join
| Routing model | Managed flood (broadcast) + next-hop routing (unicast, v2.6+) |
| Node roles | Client · Router · Repeater · Router_Late |
| Max hops | 7 (default 3) |
| Node limit | ~100 before memory saturation on standard hardware |
| Telemetry | Auto-pushes T/RH/baro, GPS, battery every interval. v2.7.15 made LoRa telemetry opt-in, reducing noise. |
| Channel utilisation | Higher than MeshCore by default — busy networks congest |
| Delivery confirm | Ambiguous — cloud+checkmark icon, not guaranteed ACK |
| Encryption | AES-256-CTR · per-channel PSK |
| Licence | GPL v3 · CLA required for contributions |
| Community size | Largest — thousands of deployed nodes globally |
| Apps | Official Android/iOS · web client · strong ecosystem |
| MQTT bridge | Yes — native, well-documented, used in this build |
| Sensor telemetry | BME280 auto-detected · TSL2591/VEML6075/MH-Z19C need custom firmware or external script |
| Best for | Ad-hoc mobile groups · hiking · disaster comms · easy entry |
MESHCORE
Role-based · repeaters only relay · quieter by design
| Routing model | Flood for discovery → learns direct path → subsequent messages unicast |
| Node roles | Companion (client) · Repeater · Room Server — companions do NOT relay |
| Max hops | 64 — city-scale backbone possible |
| Node limit | No fixed limit — repeaters scale independently of clients |
| Telemetry | Pushes rarely · pull-on-demand model · much lower airtime than Meshtastic |
| Channel utilisation | Lower — quieter mesh, fewer rebroadcasts |
| Delivery confirm | Definite ACK — yes/no confirmed delivery with retry feedback |
| Room server | Store-and-forward BBS — clients retrieve missed messages on reconnect |
| Encryption | End-to-end encrypted · path hashing in v2 roadmap |
| Licence | MIT · app has $7.99 optional premium (or 10s wait) |
| Community size | Smaller but growing fast — fewer deployed nodes in most regions |
| Apps | Android/iOS · Chrome web client · T-Deck native app |
| MQTT bridge | Less documented than Meshtastic — verify before adopting |
| Sensor telemetry | Not its primary use case — IoT integration possible but less tooling |
| Best for | Planned fixed infrastructure · city mesh · reliable delivery required |
RETICULUM (RNS)
Transport-agnostic network stack · not a mesh firmware
| Routing model | Source-routed · cryptographic identities · path announcement and discovery |
| Node roles | Any device running rnsd — no fixed roles · bridges transport types |
| Max hops | No hard limit |
| Transports | LoRa · Wi-Fi · Ethernet · TCP/IP · I2P · packet radio · serial · AX.25 · anything ≥5 bps with 500-byte MTU |
| Identity model | Identity is a cryptographic keypair — not bound to radio hardware. Persist across devices. |
| Encryption | Per-packet forward secrecy · strongest of the three |
| Telemetry / sensor | Sideband app has distributed telemetry system built in · LXMF protocol handles reliable delivery |
| MQTT bridge | rnsd runs as daemon on Pi #1 · bridges LoRa nodes to any IP network including MQTT |
| Apps | Sideband (Android/iOS/Linux/macOS/Win) · MeshChat (web UI) · NomadNet |
| Licence | MIT |
| Community size | Smaller than Meshtastic · fast-growing among technical users |
| Setup complexity | Highest — requires understanding of cryptographic identities, rnode flashing, rnsd config |
| Best for | Multi-transport backbones · privacy-first · research deployments · this build's hub routing layer |
02
Decision matrix
| Requirement | Best choice | Reason |
|---|---|---|
| Easiest to set up and join | Meshtastic | Flash firmware, power on, it works. No role planning needed. Largest community for help. |
| Sensor telemetry with MQTT pipeline | Meshtastic | Native MQTT bridge, well-documented, used in this Phase 0 build. Telemetry module auto-detects common sensors. |
| Large fixed network (city / district scale) | MeshCore | 64-hop support, structured repeater placement, quieter airtime, confirmed delivery. Doesn't collapse under density. |
| Confirmed message delivery | MeshCore | Definite ACK per message. Meshtastic's delivery confirmation is ambiguous. |
| Multi-transport backbone (LoRa + Wi-Fi + Ethernet) | Reticulum | Transport-agnostic by design. The only protocol that bridges LoRa to IP natively without a custom gateway. |
| Privacy / security priority | Reticulum | Per-packet forward secrecy. Identity not tied to hardware. Strongest encryption model of the three. |
| Hub-side mesh routing daemon | Reticulum | rnsd runs on Pi #1 alongside MQTT broker. Bridges LoRa nodes to the IP stack transparently. |
| Joining an existing regional network | Meshtastic | Largest deployed node count. Most likely to find existing coverage in urban areas. |
| Battery / solar power priority for nodes | MeshCore | Companions don't rebroadcast — significantly lower TX duty cycle than Meshtastic clients. |
| Drone relay payload (this build) | Meshtastic | Heltec V3 with Meshtastic firmware is the community-standard drone relay payload. Community-documented mounts. |
| Phase 0 testbed — start tomorrow | Meshtastic | Fastest path from hardware to MQTT data. Best tooling for sensor pipeline. Largest community for debugging. |
| Phase 2+ field scale | MeshCore or hybrid | MeshCore repeaters as backbone, Meshtastic for edge sensors, Reticulum on hub. Not yet a tested combination. |
These protocols cannot talk to each other. Meshtastic, MeshCore, and Reticulum use incompatible packet formats, different routing protocols, and different channel structures. A Meshtastic node and a MeshCore node on the same frequency will not decode each other's traffic. There is currently no bridge between Meshtastic and MeshCore at the radio layer. Reticulum runs at a different layer entirely and can be used alongside either as a hub-side routing daemon — but it does not translate between them. Choose one for the edge nodes and stick to it.
03
Routing architecture
Meshtastic — managed flood + next-hop (v2.6+)
Broadcast messages use managed flood routing — every node that hears a packet waits a calculated backoff delay, then rebroadcasts once. Duplicate detection suppresses redundant copies. This is resilient and self-organising but generates significant airtime overhead on dense networks.
Direct (unicast) messages use next-hop routing since firmware v2.6. First delivery floods to discover path. On successful ACK, the source node remembers the best next hop and uses it for subsequent messages. Falls back to flood if conditions change. This significantly reduces airtime for repeated one-to-one exchanges.
On a network with many nodes all pushing position updates, telemetry pings, and node advertisements, the flood layer can saturate. Meshtastic v2.7.15 made LoRa telemetry opt-in to reduce this. Still the dominant congestion source on busy meshes.
MeshCore — flood discovery → learned unicast
Companions (clients) do not relay for anyone. Only Repeaters forward traffic. This fundamentally changes the airtime equation — a busy area with 50 companions and 3 repeaters generates the traffic of 3 nodes forwarding, not 50.
First message floods to discover a repeater path to the destination. Once a successful path is confirmed (real ACK), the path is learned and all subsequent messages take the direct route through the known repeater chain. No flooding needed after path discovery.
This means MeshCore requires intentional repeater placement to work. On a blank field with no repeaters deployed, two companions in LoRa range will communicate directly but nothing extends beyond. The network has to be built, not discovered.
Reticulum — source routing with cryptographic path announcement
Reticulum is not a mesh firmware in the same sense. It is a network stack that runs as a daemon (rnsd) on a host and uses whatever physical interfaces are available — LoRa via rnode firmware, Wi-Fi, Ethernet, TCP/IP, etc. Each interface is a "link" to Reticulum regardless of its underlying transport.
Routing uses path announcements: nodes periodically announce their address and reachability. Other nodes propagate these announcements, building distributed routing tables. When a packet is sent, the sender knows the next hop toward the destination. No flooding of data packets — only announcements propagate widely.
In this build, rnsd runs on Pi #1. It receives LoRa traffic from the Meshtastic MQTT bridge and routes it across the LAN to Pi #2 and any other RNS-capable services. At Phase 2+, rnsd on an elevated node with a LoRa rnode interface becomes a transparent bridge between field LoRa nodes and the IP backbone — without any protocol rewrite required.
04
Sensor telemetry — what actually matters for this build
| Capability | Meshtastic | MeshCore | Reticulum |
|---|---|---|---|
| MQTT bridge (to InfluxDB pipeline) | Native, well-documented, used in Phase 0 | Possible but less tooling | rnsd daemon bridges to any IP service |
| BME280 auto-detect | Yes — telemetry module I²C scan | Not a primary feature | N/A — runs on Pi, not node MCU |
| Custom sensors (MH-Z19C, TSL2591) | Requires custom firmware or external Pi script | Requires custom firmware | Node runs Python — full sensor control |
| Publish interval control | Configurable per module | Pull-on-demand model | Full programmable control |
| Payload size limit | 256 bytes per LoRa packet | Similar LoRa constraint | 500-byte MTU on LoRa links |
| Store-and-forward for offline nodes | Limited | Room Server handles this | LXMF handles delivery retry |
| Drone relay payload (Heltec V3) | Community-standard — documented mounts | Can run MeshCore Repeater firmware | Requires rnode firmware + rnsd on Pi |
05
Other protocols in the ecosystem
| Protocol | Type | What it does | Relevance to this build |
|---|---|---|---|
| LoRaWAN | Star topology LPWAN | Sensors report upward to centralised gateways and cloud servers. Not a mesh. Used in Helium, TTN, industrial IoT. Highly efficient for one-way sensor telemetry at scale. | Phase 2+ option for high-density soil sensor grids. Not Phase 0. Cloud-first by default. |
| AREDN | Ham mesh 2.4/5 GHz | Amateur radio emergency data network. Wi-Fi-like bandwidth on ham allocations. Requires Technician+ licence. Supports IP services, video, VoIP over mesh links. | Phase 3 video relay and high-bandwidth backhaul. Not Phase 0–1. Licence required. |
| ClusterDuck Protocol (CDP) | LoRa mesh · hierarchical | Duck/Mama/Papa node hierarchy. Designed for disaster zone drop-in deployment. Focuses on reliable upward path from field to coordinator. Slower development pace in 2025–2026. | Not relevant for this build. More messaging-focused than sensor-pipeline focused. |
| GoTenna Mesh | Proprietary LoRa mesh | Closest behavioural replacement to Meshtastic. Encrypted, works without infrastructure. More expensive ($200+/device), proprietary, shorter range per hop. | Proprietary — no MQTT, no open pipeline. Reject. |
| Wi-Fi Halow (802.11ah) | Sub-GHz Wi-Fi | 900 MHz Wi-Fi variant. Up to 1 km range, ~8 Mbps throughput. Bridges the gap between LoRa bandwidth and standard Wi-Fi. Hardware becoming available 2025–2026. | Watch for Phase 2 — could replace LoRa for hub backhaul while retaining IP compatibility. Not yet mature. |
| Bitchat | BT/Wi-Fi mesh · phone | Smartphone Bluetooth/Wi-Fi mesh. No dedicated radio hardware. Dense indoor environments, protests, events. Short range. | Different regime entirely — not relevant to outdoor ecological sensing. |
| APRS (via RTL-SDR) | AX.25 packet radio | Established amateur radio position and weather reporting network. Receive via Direwolf + RTL-SDR. CWOP feeds Davis and DIY stations into a global public database. | Already in this build as regional data ingest layer. RX only — no licence required. |
06
This build's protocol position
Phase 0 edge nodes: Meshtastic. Fastest to MQTT pipeline, best sensor telemetry tooling, community-documented Heltec V3 drone relay mount. The incompatibility with MeshCore is acceptable at Phase 0 scale — 2 nodes and 1 drone do not stress Meshtastic's airtime model. Upgrade evaluation makes sense at Phase 1+ when node count exceeds 10.
Hub routing layer: Reticulum. rnsd runs alongside Mosquitto and InfluxDB on Pi #1. It is not replacing Meshtastic — it is a parallel transport layer that bridges LoRa traffic to the IP stack and prepares the hub for multi-transport operation at Phase 2+. At 2 nodes it adds minimal overhead but pays dividends when the network grows.
MeshCore is worth a parallel experiment. Flash a spare Heltec V3 with MeshCore Repeater firmware and compare airtime, delivery confirmation, and power consumption against the Meshtastic nodes over the same period. The same hardware, the same deployment — side-by-side evidence for the Phase 1 protocol decision. Both protocols can coexist on separate devices in the same physical space; they simply cannot communicate with each other.
Phase 0 is a deliberately low-bandwidth system. LoRa at 915 MHz SF10 delivers ~980 bps raw, ~70 bytes usable payload per packet. This is adequate for periodic sensor telemetry but cannot carry imagery, audio, high-rate time series, or video. The sections below lay out the bandwidth upgrade path as node count and data requirements grow.
01
Bandwidth ladder — phase by phase
Phase 0 · now
~1 kbps
Phase 1 · SDR overlay
~5 kbps
Phase 1 · Wi-Fi mesh
~100 Mbps
Phase 2 · LimeSDR
~10 Mbps
Phase 2 · AREDN ham
~150 Mbps
Phase 3 · USRP MIMO
~100 Mbps+
Phase 3 · 5G / mmWave
Gbps
The bandwidth ladder above shows maximum theoretical rates. Real-world conditions (range, interference, SNR, protocol overhead) reduce these significantly. LoRa at SF10/BW125 averages ~500–800 bytes/s useful throughput in typical outdoor deployments. Wi-Fi mesh nodes degrade rapidly with range and obstructions — reliable Wi-Fi mesh requires careful AP placement and 5 GHz backhaul.
02
High-bandwidth future — multiplexed SDR
Phase 2 — LimeSDR Mini 2 + OFDM
| Hardware | LimeSDR Mini 2 · 10 MHz–3.5 GHz · full-duplex |
| Waveform | Custom OFDM via GNU Radio · gr-ofdm |
| Practical BW | 5–30 MHz instantaneous bandwidth |
| Useful throughput | ~5–30 Mbps at practical SNR |
| Use case | Drone video relay · bulk imagery transfer · real-time NDVI streaming |
| Power draw | ~3–5 W — requires active cooling on Pi |
| Licence | Licence-free ISM or Part 97 amateur depending on band and power |
| Software | GNU Radio · gr-lora · SoapySDR · Pothos |
Phase 3 — USRP B205mini-i + MIMO
| Hardware | USRP B205mini-i · 70 MHz–6 GHz · 2×2 MIMO |
| Clock | GPS-disciplined GPSDO · TDOA positioning |
| Instantaneous BW | Up to 56 MHz per channel |
| MIMO streams | 2 × simultaneous TX/RX · spatial multiplexing |
| Useful throughput | ~50–100 Mbps at short range |
| Use case | Multi-drone swarm coordination · real-time sensor fusion · TDOA RF ranging for node location |
| Power draw | ~5–10 W · requires dedicated compute (Jetson or x86) |
| Cost | ~$1,200–1,800 · research/professional tier |
MIMO and multiplexing — when it matters: Phase 0 has 2 nodes and 1 drone. Even at SF7 (highest LoRa rate), the entire sensor payload from both nodes fits in under 200 bytes per cycle — MIMO is not relevant. MIMO becomes relevant when you have 10+ mobile platforms (drone swarms) that need simultaneous high-bandwidth coordination, or when you need real-time video relay from multiple drones with sub-100 ms latency for collision avoidance. Phase 0 → 1 → 2 builds the data model and topology that makes Phase 3 MIMO design decisions informed rather than speculative.
03
SDR upgrade path
| Hardware | Mode | Freq range | BW | Role | Phase |
|---|---|---|---|---|---|
| RTL-SDR v3 | RX only | 500 kHz – 1.75 GHz | 2.4 MHz | Passive: NOAA · APRS · 433 · ADS-B | Phase 0 |
| HackRF One | TX/RX · half-duplex | 1 MHz – 6 GHz | 20 MHz | Experimental waveforms · custom PHY · spectrum survey | Phase 1 |
| LimeSDR Mini 2 | TX/RX · full-duplex | 10 MHz – 3.5 GHz | 30 MHz | OFDM backbone · drone video relay · repeater node | Phase 2 |
| USRP B205mini-i | TX/RX · 2×2 MIMO | 70 MHz – 6 GHz | 56 MHz/ch | GPS-disciplined timing · MIMO · multi-drone | Phase 2–3 |
| PlutoSDR (ADALM) | TX/RX · full-duplex | 325 MHz – 3.8 GHz | 20 MHz | Compact · drone-mountable · MIMO with 2× units | Phase 2 |
| RFSoC (Xilinx ZU48DR) | TX/RX · 8×8 MIMO | DC – 6 GHz | 1 GHz+ | Massive MIMO · real-time beamforming · mmWave research | Phase 3+ research |