This is Part 3 of a series on SAR and EMA mesh radio SOPs, built on field guidance from Kenny Cornett at Appalachiastan Technologies (AT-Labs). Part 1 covered the four rules for deploying LoRa mesh in the first place. Part 2 covered how that position data becomes a common operating picture. This one gets into the argument every mesh community eventually has: Meshtastic, MeshCore, or Reticulum — which one should your operation actually run?
Catch up on Part 1 — Four Rules for Deploying LoRa Mesh in Emergency Management and Part 2 — A Common Operating Picture is Worth a Thousand Words if you haven't already.
If you found this helpful or interesting, consider picking up one of the ultra-rugged radios made by Appalachiastan Technologies on our store — browse the AT-Labs radio lineup.
Are you part of a government or volunteer SAR or EMA organization? You can apply for grant funding through our Funding Reach portal.
Welcome to the LoRa Wars
Spend twenty minutes in a Meshtastic Discord or a MeshCore thread and you'll find yourself in the middle of the LoRa Wars — people arguing about which platform is "better" the way people argue about trucks. Someone posts a range test. Someone else posts a counter-test from different terrain. A thread that started as a question about network capacity turns into a debate about whose firmware update broke fewer things last quarter, or which community feels more legitimate.
None of that is bad faith. People who build and maintain open source radio firmware in their spare time care about the platforms they've put years into, and that's part of why any of this exists to begin with. But if you're the person deciding what your team deploys, that conversation is the wrong one to be having. "Better" isn't a property of a mesh platform sitting on a shelf. It's a property of the fit between a platform's architecture and what you're asking it to do.
Rule 1 from Part 1 said it in shorthand: match the tool to the scope. This post is the long version — what these three platforms actually are, architecturally, and why the operational question decides the platform, not a forum consensus or a personal favorite.
Meshtastic: Built for the Incident, Not the Region
Meshtastic is the platform most people have already touched, even without realizing it's one of three options. It's the most widely deployed LoRa mesh software in the world by a wide margin, with more cumulative field hours behind it than MeshCore and Reticulum combined. If you've heard of LoRa mesh at all, you probably heard about it through Meshtastic first.
The architecture underneath is flood routing. Every node that receives a packet rebroadcasts it to every other node within range, up to a configured hop limit. There's no routing table to build and no topology to plan ahead of time. A new radio joins the mesh and starts participating immediately. That simplicity is an operational advantage at incident scale — a defined team, a bounded area, personnel and infrastructure nodes coming online in real time as people arrive on scene.
The same architecture becomes a problem as the mesh grows. Every node rebroadcasting every packet means the network works against itself as node count and geographic footprint increase: channel utilization climbs, latency increases, and eventually the mesh becomes a source of interference with itself. That's not a bug waiting on a patch. It's what flood routing does at scale, by design. Meshtastic is the right platform for a single incident with a defined team. It's the wrong platform for a statewide network, and no firmware update changes that math.
MeshCore: Built for the Region
MeshCore takes a more structured approach to routing. Instead of every node rebroadcasting everything, it routes traffic deliberately, which lets it scale across a larger geographic footprint without the self-congestion problem that limits Meshtastic. That's what makes it popular in the hobbyist community - predictable reliability. That's also what makes it the right fit for county-to-county coordination, EOC-to-EOC links, and statewide awareness — exactly the kind of network flood routing would drown before it covered the ground.
MeshCore's adoption has grown fast, and the platform is field-trustworthy at this point. What it isn't is plug-and-play. Structured routing means someone has to plan the network: node placement matters, channel design matters, and the mesh needs an owner making deliberate decisions about how it's configured, not just people who show up and power on. Regional MeshCore networks — TennMesh is the example that comes up most — are the product of real volunteer investment in that planning, not casual hobbyist infrastructure. Trade the setup friction for coverage that actually holds together at range, and it's a fair trade. Skip the planning and expect Meshtastic-level simplicity, and you're gonna have a bad time.
Reticulum: The Ceiling
Reticulum is the most architecturally ambitious of the three. It's transport-agnostic — capable of running over LoRa, TCP/IP, HF, and serial links simultaneously, treating all of them as paths in one unified network instead of separate systems that need bridging. It's encrypted and authenticated at the protocol level on every hop, not as a plugin added afterward. And it's built from the ground up for wide-area operation in a way neither Meshtastic nor MeshCore fully attempts.
That ambition comes with a cost: deployment complexity. Reticulum takes more technical depth to stand up and maintain than the other two, and its specific track record in emergency management LoRa deployments is the least documented of the three. For an agency or AUXCOMM team with that expertise on staff, Reticulum is the ceiling of what this hardware class can do — the most flexible, most capable option for a genuinely wide-area, multi-transport network. For a team without that expertise, it's worth understanding as a capability, not something to reach for on the strength of a forum post.
One Thing All Three Have in Common
All three platforms are open source projects built by volunteer communities, and that cuts both ways. It's why they exist, why hardware support is broad, and why no single company's roadmap decides your future. It also means development moves at the uneven pace of volunteer work — bursts of progress, stretches of consolidation — instead of a fixed release schedule. An update that adds a feature can occasionally cost you one you were relying on. That's a fair tradeoff for a hobbyist project. For an operational tool where position data has to be right, it's a planning problem.
EMA's Don't Have to Pick Just One
A mature LoRa mesh deployment can run more than one of these platforms at the same time. Incident-scale Meshtastic and a regional MeshCore or Reticulum backbone aren't competing choices — they're complementary layers, one covering the individual field operator, the other covering coordination between EOCs and staging areas. Making those layers talk to each other is what bridge tools are for.
Open source bridge tools already exist for passing a message or a position report from a Meshtastic mesh onto a MeshCore or Reticulum backbone, and back. That's what makes a layered deployment operationally real instead of a nice idea on a whiteboard: an incident team running Meshtastic reports up through a regional MeshCore network without anyone re-keying data by hand. Bridge tooling is open source too, so the same development-velocity caveat above applies to it — plan for it, don't assume it, and revalidate after updates the same way you would the core platforms.
Why This Matters for What's on the Shelf
RM-1 and RM-2 aren't locked to one platform. RM-1 and RM-2 run Meshtastic, MeshCore, or Reticulum today — the same radio, reflashed to match the role it's filling. That means the platform decision isn't a hardware purchase decision. A department can run MeshCore for regional accountability, where infrastructure is predictable, and reflash the radios to Meshtastic for an incident that is outside that coverage range. And if they're autistic, they can run Reticulum. It's their choice.
That flexibility is the whole point: buy the hardware that's ready for any mission, then choose the firmware for a specific mission. Don't commit fully to MeshCore because of what some influencer told you on YouTube, and don't stan Meshtastic radios because that's what your buddy's team runs. Use what's best suited for the job.
Wrapping Up
None of these platforms is universally right, and none of them is universally wrong. Meshtastic is the right call at incident scale because its simplicity is an asset when a mesh has to stand up in minutes with a team that just arrived. MeshCore is the right call when the mission is regional and someone owns the network design. Reticulum is the right call when the mission needs a wide-area, multi-transport backbone and the team has the technical depth to run it.
Pick based on what the operation actually requires. The forum debates can keep going without you.
Coming Up Next
This series continues with a closer look at what LoRa mesh actually is and isn't underneath the marketing language, then a deeper dive on matching tactical versus strategic deployment — including how elevation and airborne nodes change the coverage math, and where delay-tolerant networking earns its place in a PACE plan.
Working through the full series? Here's where to find the rest:
- Part 1 — Four Rules for Deploying LoRa Mesh in Emergency Management
- Part 2 — A Common Operating Picture is Worth a Thousand Words
Found this useful? Follow us on Instagram, Facebook, and X — sharing these guides goes a long way.
