This is Part 1 of a new series on SAR and EMA mesh radio SOPs, built on field guidance from Kenny Cornett at Appalachiastan Technologies (AT-Labs). Future parts will go deeper on platform selection, common operating picture integration, and network planning — this one starts with the four rules that should shape every deployment decision.

The Gap Was Visibility, Not Capability

Early in Kenny's career in emergency response, a responder was lost during a water rescue operation. He got separated from his team under conditions that were chaotic but not unusual for that kind of work. It took days to find him. When he was located, he had survivable injuries — he'd made it to dry land. But by the time he was found, the outcome was already decided.

The team had trained people, functional equipment, and a working incident command structure. What they didn't have was visibility. Nobody knew where he was.

That's the reason the RM-1 and RM-2 exist, and it's the reason this series exists. LoRa mesh is a genuinely useful tool for personnel accountability in the field — but it's also a tool that gets misapplied often enough that it's worth stating some ground rules before the next deployment conversation goes any further.

What LoRa Mesh Is — and Isn't

Quick framing before the rules, for anyone who needs it: LoRa mesh trades bandwidth for range and power efficiency. A LoRa radio at 915 MHz can reliably cover several miles on a small battery with zero supporting infrastructure — no cell towers, no repeaters. That makes it valuable when the infrastructure you'd normally rely on is gone, degraded, or was never there.

What it doesn't do is carry voice in any practical sense. It's not a replacement for VHF, UHF, P25, or DMR. It moves small packets — position reports, short text, limited telemetry — and it does that slowly by design. LoRa mesh is an augmentation layer, not a replacement layer. It fills gaps your existing comms infrastructure leaves open. It doesn't displace it.

But when lives are on the line, you can't afford not to fill those gaps, and LoRa Mesh does that extremely well.

With that baseline set, here are the four rules.

Rule 1: Match the Tool to the Scope

Meshtastic is the right platform for incident-scale operations. It's proven, widely deployed, simple to stand up, and its flood-routing architecture — every node rebroadcasts to every node in range — is an asset at the scale of a single incident with a defined team. Portable RM devices go on personnel. Infrastructure nodes go on apparatus light towers, fire towers, or anywhere elevation can be gained quickly. Both serve the same incident mesh.

PLI — position location information — is the primary data type at incident scale. Text messaging is secondary. Keep that priority clear and the mesh performs. Lose track of it and the channel fills with traffic it was never sized to carry.

MeshCore and Reticulum are the right platforms for regional and EOC-scale operations. Their structured routing handles geographic scale and sustained traffic in ways flood routing can't — but they require deliberate network planning, not the plug-and-play simplicity Meshtastic offers.

Using Meshtastic where MeshCore belongs produces a congested, unreliable regional network. Using MeshCore where Meshtastic belongs introduces complexity into an environment that needs simplicity under pressure. The operational scope determines the platform — not the other way around.

Rule 2: Respect the Community Mesh 

All three LoRa mesh platforms grew out of open source community projects, and that matters operationally: robust, volunteer-built mesh networks already exist across most of the country. The Meshtastic community mesh covers most populated areas. Regional MeshCore networks like TennMesh span entire states.

That resource comes with a responsibility. For routine operations — a standard incident response, a county exercise, a normal SAR callout — agency traffic should not run on the community mesh. A dozen RM devices transmitting PLI on the default channel will degrade the mesh for everyone else on it. Stand up your own channel instead — more on how to make that quick and painless in a future guide.

For catastrophic disasters, the calculus changes. When Hurricane Helene hit, the community mesh was already running while agency infrastructure was still standing up or had failed outright. In those first hours, the community mesh wasn't a resource to protect from agency use — it was the resource that was actually available, and using it deliberately bought time while more robust infrastructure came online.

The principle isn't binary — it's situational. In routine operations, protect the community mesh by staying off it. In catastrophic events, leverage it deliberately while building something more capable. Know which situation you're in before you key up.

Rule 3: Know Where This Lives in Your PACE Plan 

Every comms plan runs on PACE — Primary, Alternate, Contingency, Emergency. Where LoRa mesh sits in that framework isn't fixed. For most agencies in most environments, it belongs in the Contingency or Emergency tier — the tool you reach for when traditional radio isn't cutting through and cellular is gone.

But some agencies operate in environments where that calculus is inverted before the incident even starts. River canyons, dense vegetation, remote wilderness — places where traditional radio fails predictably and cellular was never an option. Teams that work these environments regularly often find LoRa mesh belongs in the Primary slot, not as a last resort but as an honest read of what actually works where they operate. If that's your AO, say so in the plan. Acknowledge it before the incident, not during it.

Elevation is the single biggest variable in how well any of this performs — a node at altitude sees terrain a ground-level node can't and extends range dramatically. That's not limited to towers and hilltops anymore. A small UAS with a node attached can re-establish mesh connectivity across terrain that would take hours to cover on foot, in minutes. Build that into the PACE plan explicitly instead of discovering it as an improvisation under pressure.

Rule 4: Don't Displace Traditional Radio

LoRa mesh isn't a replacement for P25, DMR, VHF, or UHF, or the interoperability infrastructure agencies depend on for life-safety voice coordination. Those systems exist for good reasons.

What LoRa mesh does is fill the gaps those systems leave — personnel accountability when someone's separated or incapacitated, text coordination when voice channels are saturated, persistent PLI beyond repeater coverage — on a battery that lasts days, with no supporting infrastructure required. That complements traditional radio. It doesn't compete with it.

The moment LoRa mesh gets positioned as a voice replacement in an operational plan, it will fail to meet that expectation — and the legitimate capabilities it does offer get dismissed along with it. Keep it in its lane. In the right environment, it's the most useful lane on the road.

Wrapping Up

None of these rules are complicated on their own. Match the platform to the scale of the operation. Don't burn out the volunteer networks other people depend on. Be honest about where mesh actually sits in your PACE plan instead of where the template says it should. And don't ask it to do a traditional radio's job.

Where teams get into trouble is skipping past these before the deployment conversation, not during it — building the network, then discovering the platform doesn't fit the scale, or the channel's clogged because it's carrying traffic it was never sized for.

Coming Up Next

This series continues with a closer look at platform selection — Meshtastic, MeshCore, and Reticulum, and how to know which one your operation actually needs. After that, we'll cover how LoRa mesh integrates (and doesn't) with ATAK, CalTopo, and ESRI, plus the AT-Labs tools built to remove the manual work from provisioning and network planning.

Found this useful? Follow us on Instagram, Facebook, and X — sharing these guides goes a long way.