Command and Control From Out of Range
Reaching a home station from the field when there's no RF path. Direct LoRa failed because the local mesh is sparse, so the command gateway was bridged to MQTT and answered over the internet, on an encrypted channel, with no infrastructure in between.
Overview
The station runs a command gateway on the mesh: send a short text on a private channel and it answers. Weather, grid, a situation report, a repeater lookup, or a question routed to an assistant. It works well within RF range.
The question this session set out to answer: what happens when you drive out of range? Can you still reach the station?
Short version: not over local RF. The mesh around here is too sparse. But bridging the gateway to MQTT closed the gap, and a command sent from a parking lot came back answered over the internet, on the same encrypted channel, with no middle infrastructure.
Background
Two radios went to the field: a Meshtastic node (T-Beam) and a MeshCore node (T-Deck). The home station carries the other end of both meshes plus the command gateway, on a single Pi.
The assumption going in was that local repeaters would relay a message home. That assumption did not survive contact with the data.
Build / Process
Direct RF, first. From the driveway, MeshCore reached the station and a command came back. That was expected, since there’s a MeshCore repeater near the QTH. A couple of miles out, both meshes went quiet. The station heard nothing.
The station’s own node database told the story plainly. The nearest Meshtastic node it has ever heard with a position is about 27 miles away. Everything closer is the station’s own hardware. On the band in use there is no local relay between the field and home. The distance from the test spot to the station was under two miles, a distance LoRa should cover easily with a decent antenna.
MQTT, second. The home node has no network of its own, so it runs MQTT in client-proxy mode: the firmware hands outbound packets to the connected computer, which relays them to a broker, and inbound broker traffic comes back the same way. Only the private command channel is bridged, and it stays encrypted end to end, so the broker only ever carries ciphertext.
In the field, the Meshtastic node has no internet either, but the phone does. With MQTT client proxy enabled in the app, the phone became the uplink. Root topic and channel matched on both ends.
Results
From a parking lot, out of any RF path to home, a command went out on the private channel. It reached the station over the broker, the gateway processed it, and the reply came back to the handheld over the internet, end to end, with no RF between the operator and the station.
Getting there took real debugging. The reply didn’t come back on the first attempt: the station transmitted it over RF but didn’t publish it to the broker. Two causes, both on the station side. Meshtastic only uplinks packets that carry an “ok to MQTT” flag, and the gateway’s replies weren’t setting it. And the relay code wasn’t accepting an argument the library passes when the radio asks to publish, so those publishes were being silently rejected. With both fixed, the round trip closed.
One smaller correction fell out of the same session. Asking the station for the operator’s grid returned the wrong square near home. A hardcoded home-grid fallback didn’t match what the coordinates actually compute to, and a cross-check against RepeaterBook caught it. Fixed to the correct grid.
Lessons
- Antenna beats infrastructure. Out of range at under two miles from your own station is an antenna and siting problem, not a missing-repeater problem. No amount of distant infrastructure fixes a station that can’t hear.
- Know your actual coverage. The node database is ground truth. “There are repeaters around here” is a hope. “The nearest node I’ve heard is 27 miles out” is a fact. Check before you rely on it.
- A repeater relays encrypted traffic fine, if it’s on your settings. The channel key rides below routing, so a repeater forwards ciphertext without holding the key. What it does need is matching RF parameters. Same hardware on a different preset is a different, invisible network.
- MQTT is the honest answer for out-of-range command and control, as long as the field end has a path to a broker: a bridged node in range, or a phone on cell. Pure off-grid still falls back to RF.
- Encrypted doesn’t mean private metadata. Content on the broker is ciphertext. The fact that a channel is active, and when, is not. Bridge the private command channel, not the public one.