Emergency Communications

Using LoRa mesh for emergency preparedness, disaster response, and off-grid comms.

📖 Start Here — Emergency Communications Guide

This book covers using LoRa mesh for emergency preparedness and disaster response - from personal go-bags to neighborhood networks, ARES/RACES integration, and active disaster operations.

⚠️ Read this first — what mesh can and cannot do. LoRa mesh (Meshtastic and MeshCore) is a supplemental, best-effort communications layer. It is not guaranteed to deliver messages — there is no end-to-end delivery guarantee, the shared half-duplex channel can saturate under load, and coverage depends on powered relay nodes being in range and surviving the event. It is never a substitute for 911, NWS/official alerts, or licensed amateur/voice nets. A mesh ACK or green checkmark is a best-effort radio acknowledgment, not proof a human received or will act on your message.

For any life-threatening emergency, use 911 or voice radio with confirmed receipt first; use mesh as a fallback when those are unavailable. The guidance in this book assumes mesh runs in parallel with primary systems, not in place of them — always keep a confirmed-receipt backup for anything life-critical.

🚀 Quick Start by Role

📚 What's In This Book

Emergency Preparedness Basics

Disaster Scenarios

ARES, RACES, and Served Agency Integration

Winlink and Digital Integration

Training and Exercises

Family Emergency Preparedness

Practical guides for households — no license or technical background required. Plan, configure, and use mesh to keep your family connected when cell service fails.

Family Emergency Preparedness

Setting Up a Family Mesh Network Before Disaster Strikes

Most emergency communications guides are written for trained responders or amateur radio operators. This guide is for families — no amateur license required, no technical background assumed.

⚠️ Read this first — mesh is a supplement, not a lifeline. LoRa mesh (Meshtastic and MeshCore) is best-effort: messages may not get through. There is no guaranteed delivery, coverage depends on nodes being in range and powered, and a delivered/ACK indicator is only a best-effort radio acknowledgment — not proof a person received or will act on your message. It is NOT a replacement for 911, NWS/official alerts, or licensed voice radio. For any life-threatening emergency, use 911 or voice first; use your family mesh as a fallback when those are unavailable, and always have a non-radio backup plan (a meeting place and an out-of-area contact).

No amateur license is required because these devices operate on the 915 MHz ISM band under FCC Part 15 — but use only FCC-certified hardware on the default US/Canada preset, and do not modify the frequency or power beyond the certified configuration.

What You Need

You need at least two nodes to communicate at all — one for you and one for each person you need to reach. Each node is a self-contained device that communicates directly with other nodes without any cellular or internet infrastructure — but only when the two nodes are within radio range of each other or of a relaying node.

Minimum kit per family member

For a family of four, four nodes. You don't need one for every household member — prioritize whoever is most likely to be separated from the group (commuters, college students, elderly relatives in another home).

Realistic Range Expectations

LoRa range varies significantly with terrain and environment. The figures below are approximate, observed values and vary widely — always test your own coverage. Plan conservatively:

If your family lives within direct radio range, node-to-node messaging usually works well — but LoRa mesh is best-effort with no guaranteed delivery, and obstacles can cut range to under a mile in cities, so "a few miles" may not connect in a dense area. Larger separations require intermediate nodes to relay messages. Always have a non-radio backup plan, and test your actual coverage before you need it.

Setting Up a Private Family Channel

MeshCore supports encrypted private channels. Set up a dedicated family channel before a disaster — do not rely on the default public channel for family communications. (Encryption is permitted here because the network operates under Part 15 on the ISM band; encryption would be prohibited if these messages were sent on amateur radio frequencies.)

  1. In the MeshCore app, create a new channel with a name your family will recognize (your last name, "HOME", or a short codeword).
  2. Set a channel key/password and share the channel to each family member's app in person ahead of time — use the channel QR code or share link, and do not send the link by text message or email.
  3. All family nodes must use the same channel name and key to communicate privately. Verify every device shows the same channel name before you finish, then send a test message on it.
  4. Keep the default public channel enabled as a secondary — it lets you communicate with neighbors and community responders.

Test Before You Need It

Equipment you have never tested will fail you in an emergency. Run a family mesh drill at least once:

  1. Configure all devices together. Verify each node appears on every other node's list.
  2. Send a test message from each node to each other node. Confirm receipt both ways.
  3. Test at realistic distances — walk or drive to where family members would actually be (workplace, school, a neighbor's house) and verify the link holds.
  4. Test on battery — disconnect from USB and confirm each node runs for its expected battery life.
  5. Update firmware if you are comfortable doing so before storing nodes — but only with the device plugged in and following the official flashing guide, because an interrupted update can disable (brick) the node. Outdated firmware is a common silent failure point, but a working older version is far better than a bricked node; if you are not comfortable, have someone experienced help.

Storage and Readiness

Family Emergency Preparedness

Your Family Communication Plan

Having mesh hardware is only half the plan. The other half is knowing what to communicate, when, and how. A simple, agreed-upon procedure keeps messages short, actionable, and interpretable under stress.

Designate a Mesh Coordinator

Choose one person — usually whoever is most comfortable with the technology — as the family's mesh coordinator. Their role during an event:

Name a backup coordinator in case the primary is the one who is unreachable.

Important: the coordinator cannot confirm a message was delivered unless the recipient explicitly replies. Mesh delivery is best-effort with no guarantee. Treat no reply as a failed contact and fall back to the contingency plan immediately — do not assume the message got through, and do not treat the coordinator or the mesh as a reliable dispatch layer for life-safety decisions.

Check-In Schedule

Agree on a check-in schedule before any emergency — not during one. A predictable schedule reduces unnecessary worry and keeps the channel clear:

The Status Message Format

LoRa packets are small. Keep messages short. Agree on a standard format everyone can remember under stress:

NAME / STATUS / LOCATION / NEEDS

Examples:

Agreed status codes

Remember mesh delivery is best-effort — sending an EMERGENCY message does not guarantee anyone received it. Always attempt 911/voice for a life-threatening situation and treat the mesh message as a supplement, confirmed only when someone replies.

Write these codes on a small card and tape it to the back of each node so anyone can use it without training.

Rally Points

Agree on two physical meeting locations before any emergency — do not rely on mesh to communicate them during one:

Both locations must be known to every family member from memory. Walk or drive to them at least once so everyone knows the route.

If a Device Fails

Plan for at least one node failing. Options to build in advance:

Family Emergency Preparedness

Off-Grid Repeat: Turning Your Companion into an Emergency Relay

MeshCore companions don't repeat packets by default — that's intentional, and unlike a Meshtastic client a MeshCore companion will not relay traffic on its own. Repeating is left to dedicated infrastructure nodes to keep routing clean. But in a small ad-hoc situation where no repeater infrastructure exists — a campsite, a festival, or a neighborhood cut off in a disaster — Off-Grid Repeat lets you stand up a temporary local mesh from gear you already own: a single toggle in the MeshCore app turns a companion device into a temporary relay. The MeshCore developers describe this feature as being for ad-hoc, temporary meshes (camping, festivals), not as a way to extend an existing mesh or as standing emergency infrastructure — MeshCore "does not work well with dynamic repeaters." Treat it as a gap-filler you reach for when you have nothing better, and move to a dedicated always-on repeater as soon as you can.

This is a fragile, temporary stopgap. A phone-tethered relay depends on the phone staying powered, foregrounded, and BLE-connected within about 10 meters of the board, and mesh delivery is best-effort with no guarantee that any message arrives. Do not rely on a phone-based relay as life-safety infrastructure. It is not a replacement for 911, NWS alerts, or licensed voice nets — use those first for anything life-threatening, and use mesh only as a fallback when they are unavailable.

No extra hardware. No laptop. One setting change on your phone — provided your board already runs feature-capable firmware. If it doesn't, a one-time firmware update is needed first (see Requirements).

Requirements

The Frequency Requirement — Read This First

Off-Grid Repeat only works on one of three dedicated Off-Grid preset frequencies. It cannot be enabled on the standard USA/Canada preset (910.525 MHz) or any other regional frequency. The app will block the save and show a warning if you try. These preset center frequencies are firmware-defined values (as documented in the MeshCore project as of mid-2026) and could change in a future firmware release — confirm the actual values in your app rather than memorizing a number, so your whole group stays on a matching frequency.

The three Off-Grid presets are:

For families and neighborhoods in the US and Canada: agree on Off-Grid 918 MHz before a disaster happens. Every person who wants to participate in the off-grid mesh needs to switch to the same preset. Everyone who wants to communicate but doesn't need to relay can also switch to 918 MHz without enabling repeat.

⚠ Warning — switching to an Off-Grid preset cuts you off from the regional mesh. Moving to an Off-Grid preset (918 MHz) takes you off the normal USA/Canada mesh (910.525 MHz). While you are on an Off-Grid preset you cannot reach anyone on the standard regional mesh — including community repeaters, Mesh America infrastructure, and responders. A family that switches to 918 MHz "before a disaster" and forgets can be silently cut off from the wider mesh during the actual event without understanding why. Only switch when you specifically need the off-grid self-relay, make sure your whole group switches together, and switch back together when the emergency is over. This is a real trade-off: you gain a self-forming local mesh, you lose contact with anyone who hasn't switched.

How to Enable Off-Grid Repeat

  1. Open MeshCore Open and connect to your companion device.
  2. Go to Settings → Node Settings → Radio Settings. (The exact menu path is app-version dependent — these labels reflect MeshCore Open as of mid-2026; if your version differs, look for the Radio Settings section.)
  3. Tap Choose Preset and select Off-Grid 918 MHz (US/Canada).
  4. Scroll down to Enable Repeat Mode and toggle it on. (The toggle is named "Enable Repeat Mode"; its exact placement may vary by app version.)
  5. Tap the checkmark to save. The settings are written to the LoRa board.

The toggle only appears once the board is running feature-capable firmware (see Requirements). If it's not visible, update the firmware first.

Disaster Deployment Setup

Once repeat mode is enabled, the device becomes a relay for all nearby nodes on the same Off-Grid frequency. To get the most out of it during an emergency:

Practical Family Setup

A straightforward temporary disaster deployment for a household:

  1. Designate one device in the household as the off-grid relay — a spare companion that isn't someone's primary phone. A dedicated spare is better than a phone someone needs to use.
  2. Before any emergency: switch that device to Off-Grid 918 MHz, enable repeat, test that it relays messages from your other family nodes.
  3. During an emergency: plug it in near a high window and leave it running. It relays for your family and for any neighbor who has also switched to Off-Grid 918 MHz. Remember this is a temporary gap-filler, not a substitute for a dedicated repeater — and that delivery is best-effort, so confirm anything important rather than assuming it got through.
  4. Your family's other devices switch to Off-Grid 918 MHz to communicate — they don't need to enable repeat, just use the same frequency.

Off-Grid Repeat vs. a Dedicated Repeater Node

Off-Grid RepeatDedicated Repeater
Free — uses hardware you already ownRequires a separate LoRa board (typically ~$30–60 as of 2026; price varies by board and vendor)
Ready in 30 secondsRequires flashing and setup
Drains phone battery, needs power sourceLow draw — can run for an extended period on a small battery or solar when correctly sized (estimate; depends on battery/solar sizing and traffic)
Phone must stay on and BLE-connectedAlways-on, fully independent
Mobile — moves with the personFixed, consistent coverage
Emergency and temporary usePermanent infrastructure

Off-Grid Repeat is a gap-filler, not a replacement. This is the most important thing to understand about the feature. If you're building out a home or neighborhood mesh for long-term use, dedicated repeater nodes are the right answer. Off-Grid Repeat is what you use when you don't have that infrastructure yet — or when you're somewhere that infrastructure can't follow you. It is intended for small, temporary, ad-hoc groups, not as backbone or emergency-relay infrastructure, and delivery over it remains best-effort.

Turning It Off

When the emergency is over, switch back to the standard regional preset (USA/Canada Recommended) and disable repeat. There's no reason to stay on Off-Grid frequencies when your normal mesh infrastructure is available — it would isolate you from the broader regional mesh.

Family Emergency Preparedness

When Cell Service Fails — Common Scenarios

Cell networks fail in predictable ways during disasters. Understanding when and how they fail helps you plan for when mesh becomes your primary communication path.

Mesh is a supplement, not a lifeline. LoRa mesh is best-effort with no guaranteed delivery: messages may silently fail to arrive, the shared radio channel can saturate under heavy load, and coverage depends on powered relay nodes being in range. It is NOT a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice first; use mesh as a fallback when those are unavailable.

Power Outage

What happens to cell service: Cell sites are required to have at least 8 hours of battery backup (24 hours at switching sites), and many add generators. In an extended blackout without refueling, battery-only sites can go silent within hours, and broader coverage degrades over the following day or two.

What mesh does: Nodes run entirely on their own batteries — no grid required. A fully charged T-Echo or similar device runs roughly 12–48 hours depending on message volume and screen-on time (treat this as an estimate; actual runtime depends on the device and how it is used). Depending on the device and screen use, a 10,000 mAh bank can extend a node's runtime to several days.

Practical steps:

Wildfire Evacuation

What happens to cell service: Towers in or near fire zones are destroyed or de-energized. A mass evacuation can spike demand and congest remaining towers, making calls and data slow or unreliable, sometimes within minutes of an evacuation order.

What mesh does: LoRa mesh has no central tower to overload, so it is more resilient than cellular under mass demand. But the radio channel is shared and half-duplex; heavy local traffic still causes collisions and delays, so keep messages short and infrequent.

Practical steps:

Earthquake

What happens to cell service: Physical tower damage, severed fiber backhaul, and simultaneous call attempts make cell networks unreliable in the hours following a major earthquake. Call failure rates can be very high near the epicenter of a major quake.

What mesh does: No central infrastructure to fail. If your node is intact and powered, it communicates with any nearby node — even if every cell tower in the region is down.

Practical steps:

Hurricane and Severe Weather

What happens to cell service: Tower damage, flooding, and grid failure cumulatively degrade coverage. Service is often worst in the 12–48 hours after a direct hit.

What mesh does: Nodes deployed before the storm can operate through and after it.

Practical steps:

What Mesh Cannot Do

Honest limitations — important to understand before you depend on mesh in an emergency:

Family Emergency Preparedness

Extending Your Network to the Neighborhood

A two-node family setup is a solid start. Adding even one or two neighbors with nodes transforms a household link into a neighborhood communications network — more range, more redundancy, more shared situational awareness.

Why the Neighborhood Unit Matters

In a significant disaster, the household is rarely the right unit for coordination. Knowing that the road south is blocked, that a neighbor needs help, or that the water is safe to drink is the kind of local intelligence that neither cell broadcasts nor emergency radio provides for hours or days after an event. Mesh fills that gap at the neighborhood level. Keep in mind that mesh is best-effort and supplemental — it is not a replacement for 911 or official alerts.

The Impact of One Elevated Node

A single node at elevation — a rooftop, a tall fence post, a second-story window — dramatically expands coverage:

If you can get one household in your immediate area to permanently host an elevated repeater node, everyone with a device in range benefits.

Starting a Neighborhood Mesh Group

This doesn't require a formal organization — just a few neighbors with nodes and a shared channel. A practical starting approach:

  1. Find two or three interested neighbors. A neighborhood Nextdoor post, HOA meeting, or block party conversation is enough. Frame it as "emergency preparedness" — most people respond positively.
  2. Set up a shared neighborhood channel with a simple name (your street name, neighborhood name) and distribute the key in person. This channel is separate from your private family channel.
  3. Agree on basic channel norms: What goes on the neighborhood channel? Keep it focused — infrastructure status, road conditions, resource sharing (generator fuel, water), wellness checks. Not general chat.
  4. Map your coverage. Have each household send a test message and note who receives it directly. Gaps in coverage reveal where an elevated or repeater node would help most.

Connecting to Broader Networks

Your neighborhood mesh doesn't operate in isolation during a major event:

Next Steps

Emergency Preparedness

Emergency Preparedness

Why LoRa Mesh for Emergency Comms

Why LoRa Mesh for Emergency Communications

Mesh is a supplement, not a lifeline. LoRa mesh (Meshtastic and MeshCore) is best-effort: messages may not get through, the shared half-duplex channel can saturate under load, and coverage depends on powered relay nodes being in range. It is NOT a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice first; use mesh as a fallback when those are unavailable.

LoRa mesh networks provide a low-power, infrastructure-light, best-effort (no guaranteed delivery) text and data communications platform that complements — never replaces — existing emergency communications systems.

Key Advantages in Emergencies

Use Cases

What LoRa Mesh Is Not

LoRa mesh is a complement to, not a replacement for, traditional emergency communications:

Integration with ARES/RACES

Amateur Radio Emergency Service (ARES) and Radio Amateur Civil Emergency Service (RACES) are established frameworks for emergency communications. LoRa mesh can operate alongside these systems - handling neighborhood-level text coordination while licensed amateur radio handles regional and state-level coordination. See Mesh and Amateur Radio (ARES/RACES) for integration guidance.

Emergency Preparedness

Building a Go-Bag Node Kit

Building a Go-Bag Node Kit

A go-bag node kit is a self-contained, portable LoRa mesh capability you can deploy quickly in an emergency without depending on fixed infrastructure. The goal is a kit you can grab and go, with everything needed to establish mesh communications from any location.

Mesh is a supplement, not a lifeline. LoRa mesh is best-effort: messages are not guaranteed to be delivered and there is no reliable end-to-end acknowledgment under load or marginal RF. Do not rely on a go-bag mesh node as your only life-safety communications path - keep a confirmed-receipt backup (voice radio, cell, satellite messenger) and treat mesh as supplemental.

Core Components

ComponentRecommended OptionNotes
LoRa Node Heltec V3 or T-Deck Plus T-Deck Plus has a built-in keyboard and screen for standalone operation without a phone; Heltec V3 requires companion app on phone
External Antenna Fiberglass omni, 3 - 5 dBi Significant range improvement over stock PCB antenna; choose one with SMA connector matching your node. A 3-5 dBi antenna stays within the 6 dBi allowance of FCC Part 15.247, so no conducted-power reduction is required at 1 W.
Power Bank 10,000+ mAh A 10,000 mAh bank can run a Heltec V3 for a day or more depending on duty cycle and screen use; larger capacity is preferred for extended deployments. Note that some power banks auto-shut-off at the low current a node draws - test yours and use one with a low-power/trickle mode if available.
Antenna Jumper / Adapter Match your node's connector Identify your node's antenna connector before buying: many boards (including Heltec V3 and T-Deck Plus) already present an SMA jack and need no jumper, while WisBlock and bare LoRa modules use a U.FL/IPEX port and need a U.FL-to-SMA pigtail (15-30 cm) to reach an external SMA antenna.
USB-C Cable (spare) Short, braided For charging/data; carry at least one spare

Optional Additions

Kit Preparation

Configure the device before an emergency. A go-bag kit with unconfigured or default-password hardware is useless under stress. Before packing the kit:

  1. Flash and configure the node with the correct channel/preset for your local network. This is the step that determines whether the kit works at all: every node you want to talk to must use the identical regional preset, frequency, and channel. See the Meshtastic app guide for flashing firmware and selecting the preset and channel, then confirm with a live test (below) before packing.
  2. If your node runs room-server / repeater firmware (an advanced feature most personal go-bag users will not use), change its default admin and guest passwords. If you're only using a personal node with the phone app, you can skip this step.
  3. Test connectivity with known nodes in your area
  4. Label the device with your callsign or contact info
  5. Export and store a config backup
Emergency Preparedness

Pre-Deployment Checklist

Pre-Deployment Checklist

The single most important rule for emergency mesh communications: configure and test your equipment before you need it. A device configured under stress, in the dark, during an emergency will have errors. Do this work now.

Hardware Preparation

Connectivity Testing

Infrastructure

Team Preparation

Realistic Range Expectations

These are best-case, line-of-sight estimates, not guarantees. Handheld and indoor use will be much shorter. Always confirm your real range by testing before you rely on it.

ScenarioTypical Range
Urban direct (street level)~1 - 3 km typical; up to ~5 km in favorable line-of-sight conditions
Suburban rooftop-to-rooftop5 - 15 km with clear line of sight / rooftop elevation
Rural / hilltop-to-hilltop20 - 50+ km (50+ km requires elevated, clear-LOS endpoints with near-ideal Fresnel-zone clearance)
With mesh hops through repeatersExtends coverage, but each hop adds latency and consumes shared airtime, and Meshtastic caps routing at 7 hops — it is not unlimited.

Integration with Existing Systems

Integration with Existing Systems

Mesh and Amateur Radio (ARES/RACES)

Mesh and Amateur Radio (ARES/RACES)

LoRa mesh and traditional amateur radio serve complementary roles in emergency communications. Understanding how they fit together helps you deploy each where it is most effective.

What ARES and RACES Are

ARES (Amateur Radio Emergency Service) is an ARRL program where licensed amateur radio operators provide emergency communications for served agencies (Red Cross, hospitals, government agencies). RACES (Radio Amateur Civil Emergency Service) is authorized under 47 CFR §97.407, sponsored by FEMA, and activated only by the responsible state or local emergency-management (civil-defense) authority.

Both programs have established protocols, training requirements, and communication plans. They operate on licensed amateur radio frequencies with trained operators. Note: the LoRa mesh described on this page operates on the 915 MHz ISM band under FCC Part 15, not on the amateur frequencies used by ARES and RACES. Default-encrypted Meshtastic traffic cannot lawfully be moved onto amateur bands — 47 CFR §97.113(a)(4) prohibits messages encoded to obscure their meaning — so mesh does not simply join the amateur allocation.

Where Mesh Fits In

CapabilityAmateur RadioLoRa Mesh
Voice communicationsYes - primary strengthNo - text/data only
License requiredYes - FCC license requiredNo, when operated under Part 15 on the 915 MHz ISM band — using FCC-certified equipment at up to 1 W (30 dBm) conducted, on a non-interference, must-accept-interference basis*
Served agenciesHospitals, Red Cross, EOCNeighborhoods, community groups
Long-range linksHF (worldwide), VHF/UHF regionalLoRa: up to ~20 - 50+ km only in ideal hilltop-to-hilltop line of sight; typically far less (often <5 km) between handhelds in real terrain†
Text messagingWinlink, APRS, packetNative; all nodes capable
Deployment cost$100 - $1,000+ per station$20 - $60 per node
Deployment speedRequires trained operatorAny community member, once the network and presets are pre-configured

*915 MHz mesh is unlicensed under Part 15 (1 W conducted, EIRP-capped, FCC-certified equipment). Running mesh on amateur bands instead requires a license and caps spread spectrum at 10 W PEP with no encryption.
†The 20–50+ km figure is a best-case clear-line-of-sight hilltop-to-hilltop direct link, not typical operational coverage; all delivery is best-effort. Treat these as ceilings, not planning numbers — see Realistic Range and Coverage Expectations.

Practical Integration Model

A realistic combined deployment:

For Amateur Radio Operators

If you hold an amateur radio license, consider:

Integration with Existing Systems

Realistic Range and Coverage Expectations

Realistic Range and Coverage Expectations

Understanding realistic range helps you plan deployments, set expectations with community members, and know when a link will or won't work. The figures below are drawn from real-world community mesh experience and represent best-case, line-of-sight (LOS) conditions with good antenna placement. They are not guarantees — actual range varies widely with terrain, foliage, and node placement. For planning purposes, use the conservative "Planning Conservatively" figures lower on this page, not the upper end of the tables below.

The ranges below assume reasonable line-of-sight clearance. They are best-case figures; obstructions, foliage, and ground-level placement will pull the low end down further.

EnvironmentTypical Range (LOS, best case)Limiting Factor
Urban (street level) 1 - 3 km typical (up to ~5 km with favorable LOS) Buildings blocking line of sight; multipath interference. Dense cores often closer to ~1-2 km.
Suburban (rooftop-to-rooftop) 5 - 15 km (requires clear LOS between elevated antennas) House heights, trees; rooftop placement and clear LOS dramatically improve range
Rural (ground level) 5 - 15 km (with reasonable clearance) Terrain, vegetation; dense vegetation or rolling terrain can reduce the low end well below 5 km
Rural (hilltop-to-hilltop) 20 - 50+ km (ideal case only) Primarily limited by earth curvature and Fresnel zone clearance. The 50+ km figure is a rare ideal-case top end requiring full clear LOS and Fresnel clearance — plan below it routinely.
Flat terrain (North Dakota, Great Plains) 15 - 30+ km even at modest height (estimate) Minimal obstructions; earth curvature/Fresnel clearance, not obstructions, dominate over open flat ground

With Mesh Hops

Each repeater hop extends coverage. In ideal hilltop-to-hilltop conditions, a chain of three repeaters spaced ~30 km apart can reach ~90+ km — but only if each link has clear line of sight and Fresnel clearance, which is a best case rather than a typical result. Note also that Meshtastic caps routing at a maximum of 7 hops (default 3). The mesh topology means messages can route around failed nodes only when an alternative path with adequate RF connectivity exists.

Key Factors Affecting Range

Planning Conservatively

For emergency planning, use these conservative estimates rather than the best-case table figures above:

Actual coverage may be better, but plan for the conservative case. Use MeshMapper wardriving to measure actual coverage once deployed - real measurements beat estimates every time.

Use Coverage Planning Tools

Before deploying, model your site with the tools below. Tool availability as of mid-2026; some are community- or region-specific and may move or go offline — verify each link resolves before relying on it.

Disaster Scenarios

Disaster Scenarios

Wildfire Communications

Wildfires create some of the most challenging communication environments: rapidly changing conditions, disrupted infrastructure, and urgent coordination needs across large areas. LoRa mesh is increasingly used for both community alerting and field operations.

Mesh is a supplement, not a lifeline. LoRa mesh is a best-effort system: messages may silently fail to arrive, there is no guaranteed delivery, the shared channel can saturate under load, and coverage depends on the mesh's own nodes surviving, staying powered, and remaining in range. In a wildfire, fire can destroy the very nodes you depend on. Never rely on mesh as the sole life-safety channel. For any life-threatening situation use 911 and official alerts (Wireless Emergency Alerts, EAS, NOAA Weather Radio, local responders) first; use mesh only as a supplementary or fallback channel when those are unavailable.

Why mesh works during wildfires

Community alerting use case

A community mesh network with established repeater infrastructure can be activated as a grassroots alerting layer during a wildfire:

Field operations use case

For organized response teams (volunteer fire, SAR, CERT):

Minimum viable field kit

Operating procedure

  1. Deploy hilltop relay node(s) at the highest accessible points overlooking the operational area
  2. Net control establishes the operations channel and verifies all teams are visible in contacts
  3. Field teams broadcast GPS position updates at roughly 5-minute intervals. The position interval is configurable, but the firmware may automatically lengthen it on busy or congested meshes, so a fixed 5-minute cadence may not hold under load; frequent position broadcasts also increase airtime and battery use.
  4. All significant events are logged as messages (not just voice) for accountability records
  5. Net control maintains a position board (GPS positions from all team nodes on map view)

Specific challenges and mitigations

ChallengeMitigation
Smoke reduces solar panel outputHeavy wildfire smoke can cut solar charging for a week or more. Size battery for several days of autonomy (for example 5 days) appropriate to your load, latitude, and worst-case smoke/overcast duration, with margin - do not assume solar will keep nodes running through a major fire on a fixed buffer.
Fire destroys repeater nodesDocument all site coordinates; prioritize replaceable hardware (RAK4631 over specialized boards)
Rapid terrain changes (burn areas)Have portable relay nodes ready to deploy at new high points as conditions change
Crew unfamiliarity with mesh devicesTrain before deployment; include device setup in team training exercises

A note on smoke and RF range

Smoke particulate has negligible effect on 915 MHz LoRa propagation, so RF range is largely unaffected by smoke itself. But fire can still destroy nodes and antennas, and heat can disturb propagation - so don't treat the link as guaranteed even when smoke is heavy. Range loss in a fire comes from damaged or destroyed infrastructure, not from the smoke attenuating the signal.

Disaster Scenarios

Earthquake Response

Major earthquakes cause cascading infrastructure failures within minutes: power out, cell towers down, roads blocked. A pre-deployed mesh network can provide a best-effort communication layer (no guaranteed delivery) that requires no external infrastructure but depends on surviving local nodes and their power. It supplements — and does not replace — 911, official alerts, and other backups.

The critical first 72 hours

FEMA advises individuals to be self-sufficient for at least 72 hours after a disaster (FEMA B-526); this window is when an independent mesh can be especially useful:

Infrastructure resilience by node type

Node typeExpected resilienceKey vulnerability
Ground-level portable (T-Echo, T1000-E)High - battery-powered, no infrastructure dependencyBattery depletion: runtime ranges from roughly a day (active GPS use) to a week or more (low-power, GPS off), depending heavily on configuration — plan to recharge
Building rooftop (solar)High if solar intact and antenna survived shakingAntenna damage from building movement; chimney/parapet collapse
Hilltop (solar, remote)Very high - rarely near structural damageSnow/debris on panel; equipment theft in post-disaster chaos
Building-powered (mains only)Low - loses power immediatelyGrid outage (add UPS for short-term backup)

Note: small portable nodes relying only on their internal battery (e.g., the T1000-E's 700 mAh cell) may last only ~12–48 hours in active use; multi-day endurance requires a low duty cycle, GPS off, or an external battery bank. Size for the duty cycle you actually expect.

Neighborhood resilience net design

A "neighborhood net" approach that works well for earthquake-prone communities:

  1. One "net anchor" per neighborhood: A solar-powered repeater on the highest accessible residential rooftop. Size the battery and panel for your target autonomy (for example, a 7-day-autonomy design goal) using an actual power-budget calculation for your latitude and load — treat multi-day autonomy as a sizing target, not a guaranteed spec.
  2. Block captains with personal nodes: Each block captain has a device pre-configured for the neighborhood channel. 5 - 10 devices within range of the anchor.
  3. Welfare check protocol: Pre-established check-in schedule (e.g., every 8 hours). Any block captain who misses check-in triggers a welfare check by neighbors.
  4. Resource messaging format: Simple standard format: "[LOCATION] STATUS: [OK/NEED HELP] INJURIES: [none/n] DAMAGE: [minor/moderate/severe]"
  5. Community coordination center connection: The neighborhood net connects to a city-wide mesh via the anchor repeater - aggregate status flows up to emergency operations.

Pre-event preparedness steps

Disaster Scenarios

Flood and Severe Weather Response

Floods, hurricanes, tornadoes, and severe winter storms each create different communication challenges. This page covers how mesh networks support response operations across severe weather scenarios.

Mesh is a supplement, not a lifeline. LoRa mesh is best-effort: messages may not get through, and there is no guaranteed delivery. It is not a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice first; use mesh as a fallback when those are unavailable.

Flood-specific considerations

Equipment waterproofing

Water is the primary hardware risk in flood scenarios. All field equipment should be in IP65+ rated enclosures or waterproof cases during flood response. For personal nodes:

Elevated deployment

Flood scenarios require nodes to be deployed well above the anticipated flood level. Ground-level repeaters in flood zones should be identified and planned for relocation to higher sites during flood events. Maintain a pre-planned list of above-flood-level backup sites for your mesh repeaters.

Hurricane/tropical storm preparation

Before a storm:

  1. Secure or remove antenna masts from exposed locations - in high wind an unsecured mast or vertical can become a projectile or bend the SMA connector (the "5 dBi fiberglass vertical at 100 mph" figure is illustrative, not a measured spec)
  2. Verify all solar-powered nodes have full battery charge before the storm
  3. Activate the community mesh "storm watch" channel if your network has one
  4. Distribute personal nodes to participants who don't have them
  5. Confirm that key participants know the channel name and PSK without needing to look it up

During a storm:

Winter storm and extended power outage

Multi-day ice storms and blizzards create extended power outages with dangerous conditions that prevent physical access. Key preparations:

Net operating procedures for severe weather

Welfare check format

STATUS REPORT
Node: [NODE-NAME or callsign]
Location: [neighborhood or cross street]
Status: [OK / NEED-ASSIST / EMERGENCY]
Injuries: [none / n minor / n serious]
Power: [on / out]
Notes: [any relevant info]

Priority message tags

Pre-establish a priority system for your community net:

All participants should know that [EMERGENCY] messages trigger immediate net control response and that they should not use the tag for non-life-safety situations. Remember that mesh is best-effort: sending an [EMERGENCY] message does not guarantee it was delivered or seen. For any true life-safety emergency, attempt 911/voice first, and require an explicit acknowledgment before assuming a mesh [EMERGENCY] message was received.

Integration with Official Systems

Integration with Official Systems

Working with ARES, CERT, and Emergency Management

The most effective community mesh deployments are integrated with existing emergency communication structures - Amateur Radio Emergency Service (ARES), Community Emergency Response Teams (CERT), and local emergency management agencies. This page covers how to make those integrations work.

Understanding the existing structure

ARES (Amateur Radio Emergency Service)

ARES is the ARRL's organized volunteer program connecting licensed amateur radio operators with emergency communication needs. ARES groups typically operate at the county or served-agency level. Key contacts: ARRL Section Manager, Emergency Coordinator (EC), and Net Manager.

Mesh relationship: Many ARES operators are interested in LoRa mesh as a complementary technology. It fills gaps that VHF/UHF radio cannot (group text, GPS tracking, message logging). One foundational distinction to keep clear with partners: the LoRa mesh layer here operates on the 915 MHz ISM band under FCC Part 15 (no license required), while ARES/RACES voice operates under Part 97 (amateur license required). Keep encrypted mesh traffic off amateur frequencies - 47 CFR §97.113(a)(4) prohibits messages encoded to obscure their meaning on amateur bands. A strong relationship with local ARES puts your mesh infrastructure in front of the people who already train for emergency communication.

CERT (Community Emergency Response Team)

CERT programs train community members in basic disaster response skills (first aid, light search and rescue, fire safety) and organize them as neighborhood response assets. CERT teams operate at the neighborhood or block level - exactly the scale where mesh radio is most useful.

Mesh relationship: A mesh network that equips each CERT team leader gives them a supplemental text and position capability, including during the early phase of disaster response before professional responders arrive. Be clear about what it is: mesh is unlicensed and best-effort, it is not guaranteed to deliver, and it must not be the sole means of summoning help. CERT teams should retain whatever primary communications (cell, FRS/GMRS, runner, amateur radio) their authority having jurisdiction (AHJ) specifies. Within those limits, CERT and mesh are a natural operational fit.

Local Emergency Management (OEM/LEPC)

Local emergency management agencies coordinate preparedness and response at the city and county level. They maintain Emergency Operations Centers (EOCs) that become the coordination hub during disasters.

Mesh relationship: EOC integration is a longer-term goal. Most EOCs start by observing mesh capabilities in exercises before formally adopting the technology. A well-demonstrated mesh network with clear procedures becomes a credible EOC resource.

First steps for integration

  1. Contact your local ARES Emergency Coordinator. Introduce the mesh network, demonstrate its capabilities, and offer to participate in ARES-sponsored exercises with mesh alongside traditional radio.
  2. Attend CERT training. CERT graduation puts you in direct contact with team leaders and the sponsoring fire department or emergency management agency. Offer to demo mesh at the graduation exercise.
  3. Contact local emergency management. Most counties have a website listing the Emergency Manager or OEM director. A brief email introducing your mesh community and offering to participate in preparedness planning events opens the door.
Formalize with an agreement. Before deploying nodes into official operations or onto agency property, execute a written MOU that addresses limitation of liability, insurance/indemnification, equipment ownership, and non-reliance - including an explicit statement that mesh is supplemental and non-guaranteed. As a 501(c)(3), documenting these terms protects both Mesh America and the served agency.

Exercise integration

The most effective way to demonstrate mesh value is through exercises where it can be directly compared with existing methods. Propose a tabletop or functional exercise where:

Emergency managers respond to demonstrated capability, not technical descriptions. One well-run exercise does more than months of email correspondence.

ICS compatibility

Emergency response in the US uses the Incident Command System (ICS). Mesh deployments serving ICS operations should align with ICS terminology and procedures:

What not to do

Integration with Official Systems

Go-Bag and Field Kit Setup

A mesh communications go-bag is a pre-configured kit that can be grabbed and deployed within minutes. For emergency communicators, this preparation is as important as the hardware itself.

Individual go-bag (personal responder)

Minimum kit for a personal mesh communicator:

ItemPurposeNotes
T-Echo or T1000-EPersonal mesh nodePre-configured with correct channel & preset; fully charged
USB charging cable (device-specific)Field rechargeTape/label with device name; easy to grab wrong cable
10,000 mAh power bankExtended operation without gridCan provide several additional days to over a week of T-Echo runtime depending on usage and power settings (GPS, TX rate, and screen use draw significantly more). This is an estimate, not a bench-tested figure.
Printed config cardQuick referenceChannel name, PSK, preset, net control contact
Spare SMA antennaBackup if stock antenna damaged915 MHz, 2 - 3 dBi, same connector type as device. Verify SMA vs RP-SMA polarity (commonly mismatched) and check u.FL on some boards; see the Meshtastic antenna docs (meshtastic.org/docs/hardware/antennas/).

Net control go-bag

Expanded kit for net control operators or team leaders:

ItemPurpose
T-Deck Plus (running MeshOS)Primary net control station; standalone, no phone needed; QWERTY keyboard; map view. Note: MeshOS is MeshCore firmware (not Meshtastic), so this station serves a MeshCore network.
OR: Raspberry Pi Zero 2W + RAK4631 USBRoom server + radio gateway; provides message persistence and network visibility
5W foldable solar panel + MPPT charge controllerRecharge power bank and devices from any outdoor location
~240 Wh lithium-ion portable power station (e.g., Jackery Explorer 240), or a separate LiFePO4 bank/stationPowers Pi room server for several hours; recharges via solar. Note: the Jackery Explorer 240 is a ~240 Wh lithium-ion (NMC) power station - not a 12,000 mAh LiFePO4 power bank; do not conflate chemistries, and use watt-hours (Wh) for power stations.
Laptop (optional)Python API access, MQTT monitoring, additional visibility
Printed participant rosterAll mesh participants, device names, and contact info
Printed frequency/channel cardConfig for all channels in use; can hand to new arrivals

Portable repeater kit

A portable repeater that can be deployed at any elevated location within 30 minutes:

ItemNotes
RAK4631 WisBlock (configured as repeater) in IP65 casePre-flashed with repeater firmware; USA/Canada preset; flood advertisements
5 - 10W foldable solar panel with cigarette lighter connectorMount using clamps or hook-and-loop straps
LiFePO4 18650 cells (4×, in battery holder)~3 day autonomy at 6 mA; LiFePO4 chosen for temperature range. Specify whether the 4 cells are wired in series (~12.8 V nominal) or parallel (~3.2 V) and confirm the resulting pack voltage matches the target node's input voltage range. Never charge any lithium cell, including LiFePO4, below 0 °C (32 °F) - discharge is fine to roughly -20 °C, but charging below freezing damages the cells (a BMS blocks cold charging, it does not enable it).
5 dBi fiberglass antenna with 30cm LMR-200 pigtailGenerally better range than a stock rubber-duck (gain and LMR-200 loss vary; check the antenna datasheet). Note: under FCC Part 15 (47 CFR §15.247(b)(4)), antenna gain above 6 dBi requires a dB-for-dB reduction in conducted power; this 5 dBi antenna is under that threshold, but do not swap in a higher-gain antenna without reducing conducted power.
Pole mount clamp (adjustable)Mounts to chain-link fence, sign post, vehicle roof rack, or trekking pole
All contained in a clear 12" × 8" zip-lock bagWaterproof; visible inventory check without opening

A note on runtime figures: Device endurance numbers across the emergency-communications pages are estimates that depend heavily on whether the device is idle vs. active, screen on/off, GPS on/off, and TX rate. Treat any runtime figure not bench-tested as an estimate to verify with your own hardware and settings; compute conservatively from average current draw and pack watt-hours rather than relying on a single optimistic number.

Battery storage between deployments

For longevity, store lithium nodes and power banks at roughly 40-60% state of charge rather than full - sitting at 100% accelerates calendar aging of the cells. Note that a LiFePO4 pack at 12.8 V is at roughly mid-charge; a full 4S LiFePO4 pack rests at about 13.4-13.6 V, so "100% = 12.8 V" is incorrect. Top everything up to full only when you arm the kit before a forecast event or activation (see the pre-event checklist below).

Pre-event deployment checklist

Run this checklist before any exercise or real deployment. (For long-term storage, keep batteries at ~40-60% - see the battery storage note above - and top up to full only at this pre-deployment step, not continuously.)

ARES, RACES, and Served Agency Integration

Integrating LoRa mesh with amateur radio emergency service organizations and their served agencies.

ARES, RACES, and Served Agency Integration

Mesh Networking in Amateur Radio Emergency Service (ARES)

Operational Note: This page may be consulted during active emergency operations. Regulatory points on this page cite the specific FCC rule (47 CFR Part 15 or Part 97); verify against the current eCFR text and your local ARES group policies before deployment.

What Is ARES?

The Amateur Radio Emergency Service (ARES) is a program of the American Radio Relay League (ARRL) that organizes licensed amateur radio operators to provide emergency communication support to government agencies, relief organizations, and other served agencies when normal communications infrastructure fails or is overloaded. The ARRL ARES field organization has four levels: national (ARRL HQ), section (Section Emergency Coordinator, SEC), district (District Emergency Coordinator, DEC), and local (Emergency Coordinator, EC, managing groups at the county or city level). Note that an ARRL "Section" is an administrative region, not necessarily a single state.

ARES members hold FCC amateur radio licenses (Technician, General, or Extra class) and participate in regular nets, exercises, and deployments. ARES groups typically operate on designated VHF/UHF repeater frequencies for voice communications and may also operate HF stations for long-range traffic handling. The National Traffic System (NTS) provides formal written message traffic capability via radiogram.

How LoRa Mesh Complements VHF/UHF ARES Operations

Traditional ARES operations are voice-centric: operators check into nets, relay verbal messages, and pass formal radiograms by voice or digital modes like Winlink. LoRa mesh (particularly Meshtastic) adds a complementary data layer that addresses specific gaps in traditional ARES capabilities:

Capability Traditional ARES (VHF/UHF Voice) LoRa Mesh Addition
Short text messaging Voice relay only; requires operator attention Asynchronous best-effort relay - intermediate nodes rebroadcast in real time; no operator attention needed. This is not guaranteed store-and-forward (Meshtastic's optional store-and-forward module is limited), so a message with no live path at send time is generally lost, not held.
Position reporting Verbal position reports; APRS on separate system Automatic GPS position sharing on mesh; visible to all nodes
Net congestion Single voice channel; traffic serialized Parallel data channel; does not compete for voice net time
Message logging Manual logging by net control Automatic message log on all receiving nodes
No-license users Not applicable (licensed only) On 915 MHz under Part 15 (unlicensed ISM), non-licensed served-agency staff may use the mesh. This is a separate legal regime from Part 97 amateur operation - it is not amateur radio and confers no amateur privileges.
Infrastructure requirement Repeater or simplex range No fixed infrastructure required to self-form, but coverage depends on powered relay nodes being in range

LoRa Mesh as a Supplemental Data Layer

In ARES deployments, LoRa mesh is most valuable as a supplemental data layer running alongside, not replacing, the primary voice net. LoRa mesh is best-effort with no guaranteed delivery, so it supplements but never replaces the voice net for time-critical or life-safety traffic. Common use cases include:

How to Introduce Mesh to Your Local ARES Group

  1. Start with the EC (Emergency Coordinator). Schedule a 15-minute briefing. Lead with the problem mesh solves: "We can't track field operator positions without using net time." Avoid jargon. Bring a working demo node.
  2. Run a small demo at a regular meeting. Set up two or three Meshtastic nodes in the room. Demonstrate position sharing on a phone screen. Let skeptical operators handle the hardware.
  3. Propose a parallel track at the next exercise. Ask permission to run mesh alongside the normal voice exercise - not as a replacement. Offer to provide equipment for participants who want to try it.
  4. Document results. After the exercise, provide a written after-action report comparing mesh message delivery vs. voice net efficiency. Numbers matter: "Mesh delivered 23 position updates automatically while voice net handled 8 formal messages."
  5. Propose group endorsement. After successful exercises, request the EC formally endorse mesh as an ARES supplemental tool and add mesh node operation to the local ARES training curriculum.

FCC Part 15 vs. Part 97: Regulatory Considerations for ARES

Critical Regulatory Distinction

Meshtastic devices operating in the 915 MHz ISM band (US) operate under FCC Part 15 - the same rules as Wi-Fi and Bluetooth. Part 15 operation:

Part 97 (Amateur Radio) allows licensed amateurs to operate in the 33 cm (902 - 928 MHz) band. However, for spread-spectrum (SS) emissions - which LoRa is - 47 CFR 97.313(j) caps transmitter output at 10 W PEP. The 1.5 kW general Part 97 ceiling does not apply to LoRa/SS and must never be cited in this context. Part 97 operation also prohibits:

Meshtastic encrypts by default using AES256-CTR. (The default public channel uses a publicly known PSK, so default traffic is not actually confidential despite being encrypted.) Because Part 97 prohibits messages encoded to obscure meaning, default-encrypted Meshtastic cannot lawfully transmit on amateur (Part 97) frequencies. There is no Part 97 "mode" for encrypted traffic. To operate on amateur frequencies you must disable message encryption entirely. If you need encryption, keep the network on the 915 MHz ISM band under Part 15, where there is no license requirement and no encryption prohibition.

Practical guidance: Run ARES mesh on 915 MHz under Part 15 at Part 15 power levels. Amateur (Part 97) transmissions may not be encrypted to obscure meaning (47 CFR 97.113(a)(4)) - no Section Manager, local coordinator, or other authority can waive this FCC rule, and there is no jurisdiction in which a ham may encrypt amateur traffic. A mesh-to-Winlink or mesh-to-APRS bridge is lawful only if a licensed amateur keys the amateur leg and the content is plaintext (decrypted at the gateway). For questions about lawful operation, consult the FCC rules (47 CFR Part 97) directly and, if needed, an attorney or the ARRL regulatory information service.

Getting ARES Group Endorsement for Mesh Infrastructure

Formal ARES group endorsement provides several benefits: shared deployment of pre-positioned nodes, group funding or donations for equipment, and integration into official exercise planning. To pursue endorsement:

  1. Write a one-page proposal for the EC describing: (a) the problem mesh solves, (b) equipment required and cost, (c) regulatory compliance (Part 15), (d) maintenance plan, (e) training requirements.
  2. Present the proposal at a group meeting and invite questions.
  3. Offer a formal training session covering Meshtastic setup, channel configuration, and emergency protocols.
  4. Request inclusion in the group's Standard Operating Procedures (SOPs) as "Supplemental Mesh Data Layer."
  5. Coordinate with the Section Emergency Coordinator (SEC) if seeking section-level endorsement or cross-group interoperability.

Quick Reference: ARES + Mesh Checklist

ARES, RACES, and Served Agency Integration

Integrating with Served Agencies

Operational Note: This page provides guidance for ARES operators and mesh advocates working with served agencies including Red Cross, hospitals, EOCs, and fire/EMS. Establish relationships before an emergency - these conversations are far harder during an active event.
Reliability disclaimer: Mesh is a supplemental, best-effort system with no guaranteed delivery — messages can silently fail to arrive. No served agency should rely on it as a primary, sole, or life-safety communications channel. All guidance below assumes mesh runs in parallel with the agency's established primary systems at all times, never in place of them.

Understanding Served Agency Communication Requirements

Served agencies have specific, often rigid communication requirements driven by their own SOPs, legal obligations, and incident command structures. Understanding these requirements is essential before proposing mesh integration.

Red Cross / American Red Cross

Hospitals

Emergency Operations Center (EOC)

Fire and EMS

Mesh in the ICS Communications Hierarchy

The Incident Command System (ICS) defines a strict communications structure. Mesh fits into this structure as a supplemental tactical channel, not a command channel.

ICS Traffic Type Primary Channel Mesh Role
Command (incident command decisions) Voice (P25, VHF/UHF) NOT appropriate for mesh - use designated voice channels
Tactical (field team coordination) Voice (simplex or repeater) Supplemental: short status messages, position updates
Logistics (resource requests, supply) Voice or Winlink email Supplemental: structured request messages via mesh
Situation Awareness (mapping, tracking) Manual boards, GIS Primary supplement: GPS position sharing is a natural mesh strength
Public Information Designated PIOs only NOT appropriate - no public-facing mesh traffic
Warning: Never use mesh as a primary command channel during active incidents. Mesh has variable latency (seconds to minutes), no guaranteed delivery, and no acknowledgment in basic operation. Life-safety commands must use primary voice channels with confirmed receipt.

What Served Agencies Actually Need

When pitching mesh to served agency coordinators, focus on what they actually want - not the technology:

How to Pitch Mesh to an OES or EOC Coordinator

The Three-Minute Pitch

  1. Open with their problem: "During the [local event] last year, your shelter coordinators couldn't reach EOC for 4 hours because the repeater was down. LoRa mesh works without repeaters or cell service."
  2. Show one capability: Hand them a Meshtastic device. Send a message from across the room. Show the position on the map. "This runs on battery for around 3 days depending on configuration."
  3. Make the ask small: "I'm not asking you to replace anything. I'm asking to run this in parallel at your next exercise so you can see how it works."

Be honest about limits in the pitch: mesh is provided as a supplemental, best-effort capability with no warranty of availability or fitness for any purpose. The served agency remains solely responsible for verifying suitability and must not rely on mesh as a primary or life-safety path. Any installation on agency property should be governed by a written agreement (see below).

Common Objections and Responses

Objection Response
"We already have radios." "Absolutely - and mesh doesn't replace them. It adds a text and position data layer so your voice channels stay clear for important calls."
"What if it breaks?" "Mesh is decentralized and can route around a failed node when alternate RF paths exist. In a sparse mesh there can still be effective single points of failure - for example a sole bridging relay - so we keep your existing radio systems as the primary comms and treat mesh as a supplement."
"Our staff can't learn new technology during a disaster." "The basic interface is a phone app most people can learn in 5 minutes. We train before the disaster, not during it. We can include it in your next tabletop exercise."
"Is it secure/encrypted?" "Meshtastic uses AES-256 channel encryption. Note that the default public channel uses a publicly-known key, so it is not confidential out of the box. For served agency use over Part 15, we configure a private channel with a strong, custom key shared only with authorized nodes."
"Who maintains it?" "The ARES group maintains the infrastructure nodes. Each served agency location needs a low-cost device; where it runs unattended on solar power, the solar must be sized to local sunlight and the node's duty cycle, and we follow Meshtastic's guidance against placing private channel keys on unattended nodes (physical key-extraction risk)."
"We don't have budget." "A complete node costs roughly $30 - 80. The ARES group can supply and help maintain pre-positioned nodes - but mesh is provided as a supplemental, best-effort capability with no warranty of availability or fitness, and any installation on your facilities should be covered by a written agreement that allocates maintenance responsibility and liability (see below)."

Training and Exercise Requirements

The milestones below build familiarity with mesh as a supplemental channel. Mesh is best-effort with no guaranteed delivery; no served agency should rely on it as a primary, sole, or life-safety channel even after completing this training:

  1. Initial orientation (30 - 60 min): Demonstrate mesh hardware, install Meshtastic app on agency-designated device, configure pre-set channel, send and receive test messages.
  2. Tabletop exercise integration: Include mesh message traffic in a tabletop exercise scenario. Evaluate whether served agency staff can successfully send and receive mesh messages during a simulated event.
  3. Field exercise: Deploy mesh nodes at served agency locations during a full field exercise. Test coverage, message delivery, and integration with EOC display systems.
  4. SOP integration: Served agency communications SOP should reference mesh as a supplemental channel, identify who is responsible for the node at each location, and document how to initiate mesh use during an activation.
  5. Written agreement / MOU: Before installing nodes on agency property, put a written agreement (MOU) in place that allocates maintenance responsibility and includes limitation-of-liability, indemnification, insurance, and non-reliance clauses (the agency acknowledges mesh is supplemental and best-effort and that it will not rely on it as a primary or life-safety channel). Installation on third-party property requires the owner's authorization, and any AC/mains, grounding (NEC 810), or mast/tower work should be done by a qualified professional following local code.
  6. Annual verification: Test each served agency node annually. Replace batteries, update firmware, verify channel configuration is current.

Served Agency Integration Checklist

ARES, RACES, and Served Agency Integration

Running a Mesh-Enabled EMCOMM Exercise

Planning Note: This page is a planning and evaluation guide for emergency communications exercises that incorporate LoRa mesh alongside traditional voice operations. Use this as a template and adapt to your local group's capabilities, geography, and served agency relationships. Note that the voice-net portion of a combined exercise typically operates under FCC Part 97 (amateur radio) and requires licensed operators with call-sign identification (47 CFR 97.119), while the LoRa mesh portion operates unlicensed under Part 15. Mesh delivery is best-effort with no delivery guarantee; the exercise should validate, not assume, that life-safety traffic gets through.

Why Combined Voice + Mesh Exercises?

Training separately on voice and mesh produces operators who can use each system independently. Combined exercises reveal how the systems interact, where they complement each other, and - critically - where operators might accidentally rely on mesh when they should use voice or vice versa. Combined exercises also let you measure mesh performance in realistic field conditions before relying on it in an actual emergency.

Scenario Design

Scenario Elements That Benefit from Mesh

Sample Scenario: Earthquake Response, Day 1

SCENARIO: 6.2 magnitude earthquake, 0730 local time.
Infrastructure status: Cell towers out, internet out, primary repeater unknown (simulate partial coverage).
ARES activation: County EC activates all available operators.
Objectives: - Establish EOC comms link (primary: voice on simplex; supplemental: mesh) - Assess four pre-designated shelter sites (teams of 2 per site) - Report shelter status (capacity, occupancy, needs) every 30 minutes - Track all field team positions continuously - Pass a minimum of 10 formal ICS-213 messages via mesh

Inject at T+60 min: Primary simplex frequency congested; shift mesh position reporting
to free up voice channel for priority traffic.

Inject at T+90 min: Shelter #3 reports mass casualty event; all traffic deprioritized
except medical coordination. Because mesh is best-effort, the MCI report and the
medical-coordination traffic that follows are life-safety messages and the
life-safety channel is voice with confirmed receipt - mesh is supplementary only.

Inject at T+95 min (mesh failure test): The Shelter #3 MCI report sent over mesh is
NOT acknowledged within 2 minutes. Evaluate whether the operator detects the
non-delivery and escalates to voice. The exercise must validate the confirmed-receipt
voice fallback for life-safety traffic, not assume the mesh delivers it.

Pre-Positioning Infrastructure

Infrastructure Checklist (T-7 days before exercise)

Assigning Mesh Roles to Participants

Role Responsibilities Equipment
Mesh Coordinator (EOC) Monitors mesh map at EOC; logs all mesh message traffic; escalates time-sensitive messages to voice net control; manages mesh channel discipline Laptop running Meshtastic web client with map view; dedicated EOC mesh node with antenna
Field Team Leader (per team) Sends periodic status reports via mesh; monitors team position on Meshtastic app; escalates voice if mesh delivery fails Meshtastic handheld node; phone running Meshtastic app (BLE connected)
Relay Node Monitor Checks relay node status periodically; adjusts or repositions if coverage is inadequate; troubleshoots connectivity issues Laptop or phone with access to relay node; spare node and hardware
Served Agency Liaison (if applicable) Operates mesh node at served agency location; sends structured status reports; reports mesh problems to field team leader Pre-configured Meshtastic node; phone or tablet with Meshtastic app
Exercise Evaluator Records all mesh message delivery data (sent time, received time, recipient); tracks voice net traffic for comparison; notes any mesh failures or anomalies Log sheet or tablet; Meshtastic client with message log visible

Evaluating Performance: Key Metrics

Message Delivery Rate

The primary mesh performance metric is the percentage of sent messages that were received by the intended recipient within an acceptable latency window. Calculate separately for:

Latency Measurement

Record the timestamp when each message is sent and the timestamp when it is confirmed received at the destination. Meshtastic's message log provides send time; the receiving node's log provides receive time. The figures below are suggested local benchmarks, not standards - they are not sourced from a published specification. LoRa airtime and therefore latency depend heavily on the modem preset (spreading factor / bandwidth) and on load, so tie any benchmark to a stated preset. The values below assume a fast/medium preset and a lightly loaded mesh; long-range (high spreading factor) presets and congestion legitimately increase latency:

Hop Count Suggested Target (light load) Investigate If
Direct (0 hops) < 2 seconds > 5 seconds
1 hop < 5 seconds > 15 seconds
2 - 3 hops < 15 seconds > 30 seconds
4 - 7 hops (max) < 30 seconds > 60 seconds

These targets apply to a lightly loaded mesh. Under disaster-level traffic, airtime saturation and retries can push latency far higher and reduce delivery. Treat the table as best-case illustrative benchmarks tied to your stated preset - not pass/fail standards. A slow message has not necessarily failed (it may still arrive), and a fast one is not proof of delivery, so confirm critical messages explicitly rather than inferring delivery from expected latency. When scoring an exercise, do not flag a normal long-range or congested link as "failing" just because it exceeds these numbers.

Net Efficiency Comparison

Record the number of voice net transmissions consumed for position reports and status updates before mesh was deployed vs. after. A well-integrated mesh can meaningfully reduce voice net traffic for routine status/position reporting by offloading it from the voice channel - but the actual reduction depends entirely on your traffic mix, operators, and coverage. Measure it for your own group from this exercise rather than relying on a generic percentage; any figure you cite should come from your own documented after-action data.

Post-Exercise Debrief Template

Exercise After-Action Report: Mesh Component

Exercise Name: ___________________________

Date: __________ Duration: __________

Participants: __________ Mesh Nodes Deployed: __________

Quantitative Metrics

Qualitative Assessment

Corrective Actions

#Issue IdentifiedCorrective ActionOwnerDue Date
1
2
3

Recommendations for Next Exercise

Winlink and Internet Bridging

Using Winlink alongside LoRa mesh, and building bridges from mesh to internet services.

Winlink and Internet Bridging

Winlink and LoRa Mesh: Complementary Systems

Legal note on bridging mesh to Winlink/amateur radio. Default-encrypted Meshtastic/MeshCore traffic cannot lawfully be transmitted on amateur (Part 97) frequencies. A mesh→Winlink (or mesh→APRS) bridge is lawful only if a licensed amateur keys the amateur leg and the content is plaintext (decrypted at the gateway) — 47 CFR §97.113(a)(4) prohibits messages encoded to obscure their meaning on amateur bands, and the operator must ID per §97.119. The LoRa mesh itself runs unlicensed under Part 15; only the Winlink/amateur side carries the licensing and plaintext requirements.

What Is Winlink?

Winlink operates on HF (shortwave), VHF, and UHF frequencies. Common access modes include:

Winlink's killer feature is its role in the Winlink 2000 network: a constellation of volunteer-operated Radio Message Servers (RMS) that store and forward messages globally. A message sent via Winlink from a field site in a disaster area can be received as a normal email by a Red Cross logistics manager anywhere in the world with an internet connection - even if the field site has no internet, no cell service, and no land lines. The sender needs an HF radio, a Winlink-capable TNC/modem, a computer running Winlink client software (e.g., Winlink Express), and a valid amateur license.

Winlink's Role in EMCOMM for Formal Message Traffic

What LoRa Mesh Does That Winlink Doesn't

Capability LoRa Mesh (Meshtastic) Winlink
Real-time position sharing Yes - automatic, continuous GPS broadcast No - would require manual Winlink message with position
Low-latency short messaging Often within ~15 seconds for direct/low-hop links, no operator setup — but latency varies with hops/congestion and delivery is best-effort (not guaranteed); multi-hop or congested conditions can take a minute or more No - Winlink sessions take 30 seconds to several minutes to complete
Group messaging (broadcast) Yes - channel-wide broadcast to all nodes No - Winlink is point-to-point or point-to-RMS
Zero infrastructure required Yes - ad-hoc mesh, no servers Partial - Winlink Peer-to-Peer (P2P) works without RMS, but is limited
Non-licensed user access Yes - no license required when using FCC-certified equipment within Part 15.247 limits (1 W conducted, must accept interference) No - requires amateur radio license or special authorization
Low hardware cost $30 - 80 per node $150 - 1000+ for radio + TNC/modem

Why Serious EMCOMM Operators Want Both

The decision between Winlink and mesh is a false choice. They operate on different timescales, serve different traffic types, and complement each other in a well-designed EMCOMM capability stack:

EMCOMM Capability Stack Example

Traffic TypeBest ToolRationale
Continuous position tracking of 10 field teams LoRa Mesh Automatic, zero operator overhead, real-time
"Team B is moving to grid 4-7" (tactical) LoRa Mesh or Voice Short text fits a mesh message; voice for immediate confirmation
ICS-213 resource request to state EOC Winlink Structured form, needs email delivery to agency staff
Shelter status report (needs agency record) Winlink Creates archival email record; attachments possible
Mass casualty alert (immediate, local) Voice + LoRa Mesh broadcast Voice for immediate acknowledgment; mesh broadcast for record
Coordination with non-radio agency (ARC HQ) Winlink Email delivery to non-amateur recipients via Winlink network
Winlink and Internet Bridging

Building a Meshtastic-to-Internet Bridge

Technical Level: This page assumes basic familiarity with Python, MQTT, and Raspberry Pi or similar Linux-based hardware. Example code is illustrative and provided as a starting point. Test and harden it for your own deployment; a single bridge node is a single point of failure and should not be relied on as the sole path for life-safety information.

Architecture Overview

A Meshtastic-to-internet bridge connects your local mesh network to internet services - EOC dashboards, email, Slack, webhooks, or databases - so that mesh messages and position data are visible to personnel who are not on the mesh network.

The standard bridge architecture is:

Meshtastic Nodes
 |
 | (LoRa radio)
 |
Gateway Node (USB or WiFi connected)
 |
 | (Meshtastic Python library or MQTT)
 |
Bridge Software (Python)
 |
 |-- MQTT broker (local or cloud)
 |-- Webhook (Discord, Slack, custom EOC dashboard)
 |-- Email relay (SMTP)
 |-- Database (InfluxDB, PostgreSQL)
 |-- Map server (Meshtastic map, custom Leaflet map)

Two Bridge Approaches

ApproachHow It WorksBest For
Meshtastic Python API Python script connects to a Meshtastic node via USB serial or BLE/TCP; receives all mesh traffic directly in Python objects Simple setups; direct serial/USB connection to gateway node; most reliable
MQTT Bridge Meshtastic node publishes to an MQTT broker (built-in firmware feature); Python script subscribes to MQTT topics; decodes protobuf messages Multiple subscribers; distributed systems; cloud-connected deployments

Hardware for a Pi-Based Mesh Gateway

Python Bridge: Meshtastic API Approach

This is the simplest and most reliable bridge. The meshtastic Python library handles serial communication and message decoding. API identifiers used below (the meshtastic.serial_interface.SerialInterface call, the pub.subscribe(..., "meshtastic.receive") pattern, the TEXT_MESSAGE_APP/POSITION_APP portnums, and the latitudeI/longitudeI integer fields scaled by 1e7) follow the Meshtastic Python library and protobufs - see github.com/meshtastic/python. The serial device path /dev/ttyUSB0 is a Linux convention and varies by OS and adapter (e.g. ttyACM0 on some boards, COMx on Windows). 

#!/usr/bin/env python3
"""
Meshtastic-to-Webhook Bridge
Forwards mesh text messages and position updates to a webhook endpoint.
Suitable for EOC dashboard integration.

Requirements: pip install meshtastic requests
"""

import meshtastic
import meshtastic.serial_interface
from pubsub import pub
import requests
import json
import logging
import time
from datetime import datetime, timezone

# Configuration - edit these for your deployment
SERIAL_PORT = "/dev/ttyUSB0" # Serial port of gateway Meshtastic node
WEBHOOK_URL = "https://your-eoc-dashboard.example.com/api/mesh" # EOC webhook
SLACK_WEBHOOK = "https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK" # optional Slack
LOG_FILE = "/var/log/mesh_bridge.log"
FORWARD_POSITIONS = True # Set False to suppress position spam
POSITION_INTERVAL_SEC = 60 # Don't forward same node position more often than this

logging.basicConfig(
 level=logging.INFO,
 format="%(asctime)s %(levelname)s %(message)s",
 handlers=[
 logging.FileHandler(LOG_FILE),
 logging.StreamHandler()
 ]
)
log = logging.getLogger("mesh_bridge")

# Rate limiting: track last position forward time per node
last_position_sent = {}

def on_receive(packet, interface):
 """Called when any Meshtastic packet is received."""
 try:
 decoded = packet.get("decoded", {})
 portnum = decoded.get("portnum", "")
 from_id = packet.get("fromId", "unknown")
 to_id = packet.get("toId", "^all")
 rx_time = datetime.now(timezone.utc).isoformat()

 if portnum == "TEXT_MESSAGE_APP":
 # Text message received
 text = decoded.get("text", "")
 log.info(f"MSG from {from_id} to {to_id}: {text}")
 payload = {
 "type": "message",
 "from": from_id,
 "to": to_id,
 "text": text,
 "timestamp": rx_time
 }
 forward_to_webhook(payload)
 forward_to_slack(f"[MESH] *{from_id}* → *{to_id}*: {text}")

 elif portnum == "POSITION_APP" and FORWARD_POSITIONS:
 position = decoded.get("position", {})
 lat = position.get("latitudeI", 0) / 1e7
 lon = position.get("longitudeI", 0) / 1e7
 alt = position.get("altitude", 0)

 # Rate limit: only forward position if enough time has passed
 now = time.time()
 if from_id in last_position_sent:
 if now - last_position_sent[from_id] < POSITION_INTERVAL_SEC:
 return
 last_position_sent[from_id] = now

 log.info(f"POS from {from_id}: {lat:.5f}, {lon:.5f}, alt {alt}m")
 payload = {
 "type": "position",
 "from": from_id,
 "lat": lat,
 "lon": lon,
 "alt": alt,
 "timestamp": rx_time
 }
 forward_to_webhook(payload)

 elif portnum == "NODEINFO_APP":
 # Node info (name, hardware, etc.)
 user = decoded.get("user", {})
 log.info(f"NODEINFO from {from_id}: {user.get('longName', '')}")

 except Exception as e:
 log.error(f"Error processing packet: {e}", exc_info=True)

def forward_to_webhook(payload):
 """POST payload as JSON to configured webhook."""
 try:
 resp = requests.post(
 WEBHOOK_URL,
 json=payload,
 headers={"Content-Type": "application/json"},
 timeout=10
 )
 if resp.status_code not in (200, 201, 202, 204):
 log.warning(f"Webhook returned {resp.status_code}: {resp.text[:200]}")
 except requests.RequestException as e:
 log.error(f"Webhook delivery failed: {e}")

def forward_to_slack(text):
 """Send a formatted message to Slack channel."""
 if not SLACK_WEBHOOK:
 return
 try:
 requests.post(
 SLACK_WEBHOOK,
 json={"text": text},
 timeout=10
 )
 except Exception as e:
 log.error(f"Slack delivery failed: {e}")

def on_connection(interface, topic=pub.AUTO_TOPIC):
 log.info("Connected to Meshtastic node.")

def main():
 log.info(f"Starting mesh bridge on {SERIAL_PORT}")
 pub.subscribe(on_receive, "meshtastic.receive")
 pub.subscribe(on_connection, "meshtastic.connection.established")

 interface = meshtastic.serial_interface.SerialInterface(SERIAL_PORT)
 log.info("Bridge running. Press Ctrl+C to stop.")
 try:
 while True:
 time.sleep(1)
 except KeyboardInterrupt:
 log.info("Shutting down bridge.")
 finally:
 interface.close()

if __name__ == "__main__":
 main()

Python Bridge: MQTT Approach

For deployments where the Meshtastic node is not directly connected to the bridge server, or where multiple subscribers are needed, the MQTT approach is preferred. First configure the Meshtastic node to publish to your MQTT broker (Settings → MQTT in Meshtastic app or CLI), then use this bridge. The JSON topic form msh/REGION/2/json/CHANNEL/USERID (wildcarded below as msh/+/2/json/#) follows the Meshtastic MQTT module documentation; the exact topic structure has changed across 2.x firmware releases, so verify it against the current Meshtastic MQTT docs for your firmware version. Note also that Meshtastic's MQTT/JSON uplink is unencrypted by default - messages published to the broker are sent in clear JSON unless you have explicitly configured channel encryption and disabled the JSON output, so treat the broker and any subscriber as having full visibility of mesh traffic: 

#!/usr/bin/env python3
"""
Meshtastic MQTT Bridge
Subscribes to Meshtastic MQTT topics and forwards to webhook/email.

Requirements: pip install paho-mqtt requests meshtastic
"""

import paho.mqtt.client as mqtt
from meshtastic.mesh_pb2 import MeshPacket
from meshtastic.portnums_pb2 import PortNum
from meshtastic.mesh_pb2 import Data
from google.protobuf.json_format import MessageToDict
import requests
import logging
import json
import time
from datetime import datetime, timezone

# Configuration
MQTT_BROKER = "localhost" # MQTT broker host (can be local Mosquitto or cloud)
MQTT_PORT = 1883
MQTT_TOPIC = "msh/+/2/json/#" # Meshtastic JSON topic, form msh/REGION/2/json/CHANNEL/USERID (firmware 2.x)
MQTT_USER = "" # MQTT username if required
MQTT_PASS = "" # MQTT password if required
WEBHOOK_URL = "https://your-eoc-dashboard.example.com/api/mesh"

logging.basicConfig(level=logging.INFO)
log = logging.getLogger("mqtt_bridge")

def on_connect(client, userdata, flags, rc):
 if rc == 0:
 log.info("Connected to MQTT broker.")
 client.subscribe(MQTT_TOPIC)
 log.info(f"Subscribed to {MQTT_TOPIC}")
 else:
 log.error(f"MQTT connection failed: rc={rc}")

def on_message(client, userdata, msg):
 try:
 payload = json.loads(msg.payload.decode("utf-8"))
 topic = msg.topic
 log.debug(f"MQTT [{topic}]: {payload}")

 # Meshtastic JSON format (firmware 2.x)
 ptype = payload.get("type", "")
 from_id = payload.get("from", "")

 if ptype == "sendtext":
 text = payload.get("payload", {}).get("text", "")
 log.info(f"MSG from {from_id}: {text}")
 forward({"type": "message", "from": from_id, "text": text,
 "timestamp": datetime.now(timezone.utc).isoformat()})

 elif ptype == "position":
 pos = payload.get("payload", {})
 lat = pos.get("latitude_i", 0) / 1e7
 lon = pos.get("longitude_i", 0) / 1e7
 log.info(f"POS from {from_id}: {lat:.5f}, {lon:.5f}")
 forward({"type": "position", "from": from_id, "lat": lat, "lon": lon,
 "timestamp": datetime.now(timezone.utc).isoformat()})

 except Exception as e:
 log.error(f"Error: {e}", exc_info=True)

def forward(data):
 try:
 requests.post(WEBHOOK_URL, json=data, timeout=10)
 except Exception as e:
 log.error(f"Webhook error: {e}")

client = mqtt.Client()
if MQTT_USER:
 client.username_pw_set(MQTT_USER, MQTT_PASS)
client.on_connect = on_connect
client.on_message = on_message
client.connect(MQTT_BROKER, MQTT_PORT, 60)
client.loop_forever()

Use Cases: Pushing Mesh Messages to an EOC Dashboard

The webhook endpoint above can feed any EOC visualization system. Common deployments include:

Security Considerations for Public-Facing Bridges

Security Requirements Before Public Deployment

Systemd Service for Automatic Bridge Startup

Save the following as /etc/systemd/system/mesh-bridge.service:

[Unit]
Description=Meshtastic-to-Internet Bridge
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=pi
WorkingDirectory=/opt/mesh-bridge
ExecStart=/usr/bin/python3 /opt/mesh-bridge/bridge.py
Restart=on-failure
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Enable with: sudo systemctl enable mesh-bridge && sudo systemctl start mesh-bridge

Disaster Preparedness Planning

Pre-positioning infrastructure, operating during active disasters, and building neighborhood resilience.

Disaster Preparedness Planning

Pre-Positioning Mesh Infrastructure for Disasters

Core Principle: Infrastructure that survives a disaster is infinitely more valuable than infrastructure deployed after one. Pre-position before the threat window, not during it.
Mesh is a supplement, not a lifeline. LoRa mesh (Meshtastic) is best-effort with no guaranteed delivery: messages may silently fail to arrive, links degrade with terrain, obstruction, and congestion, and a user's device must be within radio range of a surviving, powered node. Pre-positioning improves the odds but does not guarantee a message gets through. It is NOT a replacement for 911, NWS alerts, or licensed voice nets. Validate coverage by testing — do not assume it.

Cache and Deploy vs. Pre-Position: The Critical Distinction

There are two philosophies for emergency mesh infrastructure:

ApproachHow It WorksWhen It FailsBest For
Cache and Deploy Nodes stored in a cache (car, emergency kit, warehouse); deployed by personnel after disaster occurs When roads are impassable, personnel are unavailable, or the deployment window is too short (earthquake, tornado) Slower-onset disasters (flood, pandemic); go-bag/field kit deployments; ARES activations
Pre-Positioned Infrastructure Nodes permanently installed at key sites before any disaster; running continuously on solar power When the site itself is physically destroyed or solar+battery is exhausted — and, barring hardware/firmware faults, lightning damage, water ingress, antenna/coax failure, RF congestion, or loss of relaying neighbor nodes. Mesh is best-effort with no guaranteed delivery. Earthquake, hurricane, wildfire, any disaster with a sudden onset or infrastructure destruction phase

For serious EMCOMM capability, pre-positioned infrastructure is the goal. Pre-positioned solar nodes can survive the disaster alongside the buildings they're mounted on and be available without on-the-spot deployment. They are not a guarantee, however: a node can be physically powered yet still fail to deliver a message. A user's device must be within radio range of a surviving node, mesh delivery is best-effort and not guaranteed, and coverage should be validated by testing, not assumed.

Identifying Key Pre-Position Sites

Not all sites are equally valuable for pre-positioning. Priority sites have these characteristics:

Priority Pre-Position Site Types

Site TypeValueAccess Notes
Emergency Operations Center (EOC) Highest - command and control hub for all emergency operations; must be on the mesh Requires coordination with county/city OES; often receptive to ARES/amateur support
Fire stations Very high - elevated, structurally reinforced, staffed 24/7, diesel generator backup Fire department liaison; node on roof or upper exterior; coordinate with fire chief
Water towers Very high - where present, water towers are often among the highest accessible points and offer wide line of sight Public utility coordination; typically requires a formal agreement; excellent relay sites
Hospitals High - critical served agency; will be operationally critical during any mass casualty event Hospital facilities/communications department; often have ham radio infrastructure already
Schools designated as shelters High - will become population centers during displacement events School district facilities department; often easier access than city buildings
Amateur radio repeater sites High - already at elevated locations with existing antenna infrastructure; often solar-powered Repeater trustee; ARES can often coordinate directly. Note: a mesh node co-located at an amateur repeater site still operates under FCC Part 15 — it must not cause harmful interference to the licensed repeater and must accept interference from it. Do not combine the mesh onto amateur-licensed transmit equipment; sharing antennas/feedlines must respect each service's rules.
Community/recreation centers Medium - potential shelter and community gathering sites Parks and Recreation department; typically accessible

Hardening Pre-Positioned Nodes for Disasters

Installation safety and authorization. Lightning protection, grounding/bonding, rooftop and tower mounting, mast/wind loading, and any mains/AC electrical work must comply with the National Electrical Code and local codes and should be performed or inspected by qualified, licensed professionals. This guidance is informational only and is not a substitute for professional installation — improper work can cause fire, electrocution, or falling-object injury. Work on third-party property (hospitals, fire stations, water towers, schools) requires the property owner's written authorization before any installation.

Power System: LiFePO4, Not LiPo

Strongly prefer LiFePO4 (lithium iron phosphate) batteries for pre-positioned nodes. LiPo (lithium polymer) and standard lithium-ion batteries used in consumer devices pose thermal runaway risk, especially in high-temperature environments (rooftop enclosures in summer). LiFePO4:

Recommended: 12V LiFePO4 battery (20 - 40Ah) with a solar charge controller designed for LiFePO4 chemistry (MPPT preferred; Renogy Wanderer Li or Victron SmartSolar are well-proven options). At 40Ah, a node drawing ~100mA can run on the order of ~10-13 days without any solar input after accounting for usable capacity (~80%) and conversion losses. Treat this as an estimate, derate further for cold and battery aging, and do not plan to the theoretical maximum.

Enclosure: IP66 (NEMA 4X) or Better for All External Installations

Antenna Mounts: Wind-Rated

Lightning Protection

Inventory Management: Know Where Every Node Is

During an emergency activation, you need to know immediately: which nodes are deployed, where, what their power status is, and who is responsible for each one. Without an inventory system, critical nodes will be forgotten, batteries will die unnoticed, and coverage gaps will appear at the worst time.

Node Inventory Template

Node IDLong NameLocationGPS Coords Power TypeBattery CapacityInstalled Date Last InspectedCustodianNotes
!ab12cd34RELAY-EOC-1County EOC Roof 34.052°N, 118.243°WSolar/LiFePO440Ah 2024-03-152025-01-10John Smith W6XXX MPPT controller; checked OK
!ef56gh78RELAY-FIRESTN-3Fire Station 3 Roof 34.061°N, 118.251°WSolar/LiFePO420Ah 2024-05-022025-01-10Jane Doe KD6YYY Battery replaced 2025-01; check seal

Pre-Positioning Checklist

Disaster Preparedness Planning

Mesh Communications During Active Disasters

If you are reading this during an active emergency: Jump to the Quick Start section below. Full context follows.

Mesh is a supplement, not a lifeline. LoRa mesh (Meshtastic & MeshCore) is best-effort with NO guaranteed delivery: messages can silently fail to arrive, there is no end-to-end delivery guarantee, the shared half-duplex channel saturates under heavy load, and coverage depends on powered relay nodes being in range. It is NOT a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice first; use mesh as a fallback when those are unavailable. Any immediate life-threat (MAYDAY/FLASH/EMERGENCY-class) traffic must always be attempted on voice/911 as the primary path — never routed over mesh alone.

Quick Start: Mesh Operations During Active Disaster

  1. Power on all go-bag/mobile nodes. Allow up to several minutes for a cold GPS lock — longer under obstructions or after storage. Warm starts are faster, but do not assume a fix in 60 seconds.
  2. Verify channel configuration. All nodes must be on the same channel with the same key.
  3. Designate a Mesh Coordinator at EOC. One person monitors mesh traffic; all others operate.
  4. Send a CHECK-IN message from each active node: "CHECKIN [NODE NAME] [LOCATION] [STATUS]"
  5. Reserve voice for life-safety traffic; route routine status/position updates on mesh. Remember mesh delivery is best-effort and not guaranteed — any time-critical or life-safety traffic needs a confirmed-receipt path or voice/911 backup, never mesh alone.
  6. Log all mesh traffic. Screenshot or print message logs every 30 minutes.
  7. Check battery levels on all nodes every 2 hours. Recharge before depletion.

Infrastructure Failure Sequence During Major Disasters

Understanding what typically fails in what order helps you plan which communications systems to rely on at each phase of a disaster. This is a typical sequence only — the order and timing vary widely by hazard and locale, and should not be treated as a hard rule:

Time After EventWhat Typically FailsWhat Still Works
0 - 15 min Grid power (local); some cell towers (congestion); landlines (cable damage) Cell (may already be congested — do not assume availability in the first minutes of a major event); internet via battery-backed routers; mesh (pre-positioned nodes); battery-backed repeaters; HF radio
15 - 60 min Cell towers (battery exhaustion in high-call-volume events — backup duration varies widely, often a few hours; 15–60 min applies to worst-case high-load sites); some internet (routing failures) Mesh (pre-positioned solar nodes); battery-backed repeaters; Winlink HF; satellite (Starlink)
1 - 6 hours Cell network (extended outage); most commercial internet; repeaters (battery exhaustion if not refueled) Mesh (solar nodes with LiFePO4 — running on battery at night); HF radio; satellite; generator-powered systems
6 - 72 hours Generator-powered systems (fuel exhaustion); some repeater sites (refueling issues) Solar mesh nodes (as long as panels get usable sun — note smoke, heavy cloud, and snow can suppress charging for days; size battery accordingly); hand-charged systems; HF radio
72+ hours Most unsupported infrastructure Well-designed solar mesh nodes; manually recharged systems; satellite

Message Prioritization: Life-Safety First

Life-safety traffic over best-effort mesh — read first. LoRa mesh is best-effort: FLASH/EMERGENCY traffic is NOT guaranteed delivered or acknowledged, and may be dropped or sit unread with the sender never knowing. A true MAYDAY/life-safety alert must be attempted on voice and/or 911 as the primary path; a mesh FLASH is a supplement, not the primary alert. A mesh ACK or green checkmark is a best-effort radio acknowledgment only — it is NOT proof that a human received or will act on the message. Senders should require explicit confirmed receipt and re-send/escalate (via voice/911) if none arrives within a set time.

All mesh message traffic should be evaluated against this priority hierarchy. The Mesh Coordinator at the EOC is responsible for escalating high-priority mesh traffic to the incident commander — but escalation over mesh is supplementary to, never a substitute for, voice/911 on life-threatening traffic.

Mesh Message Priority Hierarchy

PriorityTraffic TypeExampleAction Required
FLASH Life safety - immediate threat to life "MAYDAY SHELTER4 FIRE IN BUILDING EVACUATING NOW" (sent as a supplemental record — the primary MAYDAY must go out on voice/911) Attempt voice/911 first as the primary path. Mesh is best-effort: a FLASH may not be delivered and the sender cannot assume it was received. Mesh Coordinator relays any received FLASH to the incident commander via voice immediately; require an explicit acknowledgment and re-send/escalate if none is received within a set time. Do not rely on mesh as the sole path.
URGENT Medical emergency; immediate resource need "URGENT SHELTER4 CARDIAC PATIENT NEEDS ALS NOW" Relay to IC within 2 minutes. Log and timestamp. For an immediate life-threat, back up on voice/911.
PRIORITY Significant situation change; safety-relevant "PRIORITY ROAD12 BRIDGE OUT NORTHBOUND IMPASSABLE" Log, brief IC at next opportunity. Note on situational map.
ROUTINE Status updates, resource counts, position "ROUTINE SHELTER4 CENSUS 47 OCCUPANTS NEEDS: WATER" Log. Include in next situation report cycle.

Training requirement: All mesh operators must know the priority hierarchy before an activation. Because mesh is best-effort and depends on a single Mesh Coordinator noticing the traffic, a FLASH message that sits unread in a mesh log because the Mesh Coordinator is unavailable defeats the purpose — which is exactly why life-threat traffic must always also go out on voice/911 and never rely on mesh alone.

The Mesh Coordinator Role at the EOC

In any activation with more than three mesh nodes, designate a dedicated Mesh Coordinator at the EOC. This is a full-time position during active operations; it cannot be effectively combined with net control or other communication roles in high-tempo situations.

Mesh Coordinator Responsibilities

Mesh Coordinator Equipment at EOC

Operating Mesh During Specific Disaster Types

Hurricane

Wildfire

Earthquake

Coordination with Public Information Officers (PIOs)

Warning: Mesh message content is not authorized for public release without PIO review. Mesh operators do not speak for the incident command. All public information must be cleared through the designated PIO. Mesh operators should not post mesh message content to personal social media accounts during an active incident.

Logging Mesh Traffic for After-Action Review

All mesh traffic during an activation should be preserved for the after-action review (AAR). This serves multiple purposes: legal documentation, performance evaluation, and training improvement.

Disaster Preparedness Planning

Building Neighborhood Disaster Preparedness Networks

Target Audience: CERT team leaders, neighborhood emergency preparedness group organizers, block captains, and city OES liaisons. No amateur radio license is required for the core mesh network described here: it operates on the 915 MHz ISM band under FCC Part 15, which requires no amateur license when using FCC-certified equipment within Part 15.247 limits (1 W / 30 dBm conducted max, must accept interference and cause no harmful interference).
Mesh is a supplement, not a lifeline. LoRa mesh is best-effort with no guaranteed delivery - messages may silently fail to arrive, the shared channel saturates under load, and coverage exists only where a path of powered, in-range nodes is available. It is not a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice first and keep a non-mesh backup; treat mesh as a fallback.

Why Neighborhoods Are the Right Unit for Mesh Networks

The first 72 hours after a major disaster are the most critical for community survival - and they are precisely when official emergency services are most overwhelmed and least available. FEMA and Ready.gov recommend being prepared to be self-sufficient for at least 72 hours (and current guidance often recommends longer - several days to two weeks; see ready.gov). A neighborhood-scale mesh network provides:

CERT Teams and Neighborhood Preparedness Groups as Mesh Early Adopters

Community Emergency Response Teams (CERT) - FEMA-trained volunteer groups that provide immediate disaster response at the neighborhood level - are natural mesh early adopters. CERT teams:

How to approach your local CERT team: Contact the CERT coordinator through your city's OES or Fire Department (CERT programs are usually run by Fire). Offer a free 30-minute demonstration. Propose providing 2 - 3 Meshtastic nodes for CERT team use. Ask to be included in the next CERT exercise.

The Block Captain Model

The most scalable neighborhood mesh model assigns one mesh node to each block captain - a neighbor who has volunteered to be the communication point for their immediate block. The block captain:

The number of block captains needed depends heavily on terrain, antenna height, building density, and node placement - there is no fixed node count that guarantees whole-neighborhood coverage. Rather than assuming a flat figure (e.g., 8-12) gives adequate coverage for all occupied blocks, plan your node count from an on-site walk test / range survey (see below). Block captain nodes can also relay for neighbors who have their own Meshtastic devices (phones running the app, personal nodes, etc.).

Coverage Mapping for Your Neighborhood

Before committing to node placement, map your coverage. Two approaches:

Walk Test Method

  1. Place one node at the proposed location of the primary relay (highest point accessible: roof, upper floor).
  2. Walk the entire neighborhood with a second node (phone running Meshtastic).
  3. Send test messages every 100 meters. Mark locations where messages fail to deliver on a map.
  4. Identify coverage gaps. Add relay nodes at elevated points within the gap areas.
  5. Repeat walk test after adding relays.

Coverage Prediction Method

  1. Use a radio propagation prediction tool (HeyWhatsThat, RadioMobile, or SPLAT!) to model 915 MHz coverage from each proposed node location.
  2. Input antenna height and terrain data, and compute the LoRa link budget rather than assuming a fixed number. Link budget = TX power (dBm, up to +30 dBm conducted under Part 15.247) + TX antenna gain + RX antenna gain - RX sensitivity (dBm). Note that RX sensitivity is spreading-factor-dependent (roughly -120 to -148 dBm; see the Semtech SX1262 datasheet), so a single "~140 dB" figure is only a rough placeholder, not a "medium-range Meshtastic" constant.
  3. Overlay coverage predictions on a neighborhood map to identify gaps before physical deployment.
  4. Verify predictions with a walk test after deployment.

Integrating with City OES

City Office of Emergency Services (OES) departments vary widely in their receptiveness to amateur mesh technology. Approach strategically:

  1. Start with the CERT liaison. If your city has a CERT program, the CERT coordinator is your best entry point. They already work with volunteers and understand non-professional capabilities.
  2. Request to participate in city exercises. Most OES departments hold annual exercises. Request observer/participant status and demonstrate mesh alongside official comms.
  3. Offer to complement, not compete. Never suggest mesh replaces city radio systems. Position it as "last-mile neighborhood comms" that fills a gap city systems don't cover.
  4. Provide documentation. After exercises, provide written reports showing mesh performance and how it integrated with official operations.
  5. Pursue MOU/Letter of Support. A formal letter of support from the OES director significantly increases the group's credibility when recruiting block captains and securing sites. Any MOU should be reviewed by counsel and should allocate liability and insurance, and explicitly state that the mesh network is supplemental, volunteer-run, and best-effort - not a guaranteed or primary emergency service.

Equipment Storage and Rotation Plans

A neighborhood mesh program is only as good as its equipment. Establish a storage and rotation plan to ensure equipment is operational when needed:

ItemStorage LocationMaintenance IntervalResponsible Party
Block captain nodes (personal) Block captain's home (kept on a USB charger for readiness) Monthly charge check; annual firmware update Block captain (self)
Pre-positioned relay nodes (elevated) Installed at site (solar powered) Annual physical inspection; firmware update; battery test Designated node custodian
Reserve/loaner nodes (cache) Neighborhood emergency supply cache or CERT storage Quarterly charge cycle; annual inspection CERT coordinator or neighborhood team leader
Phone batteries / USB power banks Stored with reserve nodes Quarterly discharge/recharge cycle to maintain capacity CERT coordinator

Battery longevity note: keeping a node permanently at 100% on a USB charger ages its internal lithium battery over time. Continuous float charging is acceptable for readiness, but plan to replace internal cells periodically and do not assume the battery will hold full capacity after years of float charging. For nodes kept in a cache rather than powered, store the internal lithium battery at roughly 40-60% state of charge and top up to full only before deployment.

Equipment Rotation Policy

Annual Testing Exercise Plan

An annual exercise keeps skills sharp, identifies equipment problems before a real disaster, and provides a regular community engagement opportunity. Template:

Annual Neighborhood Mesh Exercise: 2-Hour Format

TimeActivityObjective
T+0:00 Exercise kickoff; "simulated earthquake" announced; all participants power on nodes Verify all nodes come online and have GPS lock
T+0:10 All block captains send check-in message with simulated damage report Verify message delivery from all locations; identify coverage gaps
T+0:20 Neighborhood coordinator sends resource request messages to each captain Test bidirectional communication; verify message latency
T+0:40 Inject: "One pre-positioned relay node is offline" - identify and diagnose Practice troubleshooting; identify backup coverage path
T+0:60 Simulated mass casualty: FLASH message sent; all captains relay to households. Because mesh is best-effort with no delivery guarantee, any FLASH/life-safety message must be confirmed received (reply or voice) - the exercise should test detection of non-delivery, not assume the broadcast reached every household. Test priority message handling; verify Mesh Coordinator response; test detection of non-delivery
T+1:20 Equipment inspection: check battery levels, antenna condition, enclosure seals Identify maintenance needs before next exercise
T+1:40 Debrief: what worked, what didn't, action items for next year Continuous improvement; document corrective actions
T+2:00 Exercise close; data collection forms collected Document message delivery rates, latency, and participation count

Neighborhood Preparedness Network Checklist

ARES and RACES Integration

ARES and RACES Integration

Integrating LoRa Mesh with ARES/RACES

Overview

The Amateur Radio Emergency Service (ARES) and the Radio Amateur Civil Emergency Service (RACES) are the two primary organized frameworks through which licensed amateur radio operators support public safety and emergency management in the United States. LoRa mesh networks built on the Meshtastic platform are not a replacement for these established systems, but a powerful digital complement that fills capability gaps that voice HF and VHF radio alone cannot address.

Mesh is a supplement, not a lifeline. LoRa mesh is best-effort with no guaranteed delivery: messages can silently fail to arrive, the shared half-duplex channel saturates under load, and coverage depends on powered relay nodes being in range. It is not a replacement for 911, NWS alerts, or licensed amateur/voice nets. Assign assured-delivery and life-safety traffic to voice with confirmed receipt (or Winlink for a record copy); use mesh for supplemental status, position, and welfare data.

ARRL ARES Structure

ARES is organized and administered by the American Radio Relay League (ARRL). It has four organizational levels - national, section, district, and local - and interfaces with / operates under ICS during activations rather than literally mirroring ICS/NIMS at every tier:

ARES groups typically maintain readiness on 2-meter FM simplex and repeater frequencies, HF voice and digital (Winlink/JS8Call), and increasingly on data mesh platforms. Training follows ARRL-published curricula and may align with FEMA IS-700/IS-100/IS-200 requirements set by served agencies.

RACES - Municipal Affiliation

RACES is authorized under 47 CFR §97.407 and operates only at the direction of the responsible civil-defense / emergency-management official - during emergencies and during authorized drills and tests. Routine RACES training drills and tests are expressly permitted (limited to a total of 1 hour per week without a declared emergency, with longer drills only by approval of the responsible official). Unlike ARES, which can operate at any time, RACES operation requires:

Many operators hold dual ARES/RACES enrollment, enabling them to transition from ARES pre-activation operations to RACES operations upon a formal activation.

How LoRa Mesh Fits Alongside HF/VHF Infrastructure

LoRa mesh on the 915 MHz ISM band (or 868 MHz in Region 1) operates independently of the amateur radio allocations used by HF/VHF operators. While 902-928 MHz is a shared band, this unlicensed Part 15 operation is independent of Part 97 amateur authority, creating a clean separation of roles:

CapabilityHF/VHF VoiceLoRa Mesh
Long-distance voice relayExcellent (HF)Not applicable
Structured digital forms (ICS213)Commonly via Winlink or other digital forms tools (FLMSG), or relayed by voice using formal message-handling proceduresPlain-text only; ICS form data must be manually condensed into ~230-character messages (no native structured-form transport)
Position tracking (blue force)Via APRS (separate system)Native GPS position sharing
Welfare traffic (check-ins)Voice net, slowAsynchronous text, fast (best-effort)
License requiredYes (Technician+)No, IF operated under Part 15 (FCC-certified equipment, 1 W / 30 dBm conducted max, must accept interference and cause no harmful interference). Default-encrypted Meshtastic cannot lawfully move to amateur frequencies.
Deployed infrastructure neededRepeaters, linked systemsSelf-forming ad-hoc mesh

Mesh nodes are useful for low-bandwidth supplemental data: ICS form text, GPS tracks, welfare check-ins, and resource status messages. Note that mesh transport is best-effort with no guaranteed delivery and very limited store-and-forward; assign assured-delivery traffic (formal ICS forms needing a record) to Winlink/voice and use mesh for supplemental, confirm-when-it-matters data. Voice radio remains superior for command coordination, situational awareness broadcasts, and long-haul links.

Under FCC Part 15, the 915 MHz limit is on conducted transmitter output power - up to 1 W (30 dBm) for frequency-hopping/digital systems per 47 CFR §15.247 - with separate provisions governing antenna gain and EIRP (antennas above 6 dBi require a dB-for-dB reduction in conducted power). "1 W EIRP" is not the correct phrasing for the limit.

Digital Data Transport Use Cases

MOU Considerations with Served Agencies

A Memorandum of Understanding (MOU) between an ARES group and a served agency (hospital, Red Cross chapter, VOAD, county OES) should address LoRa mesh explicitly if it is part of the deployed communications plan. Key provisions to negotiate:

ARES and RACES Integration

ICS/NIMS Terminology for Mesh Operators

Why Mesh Operators Must Know ICS

When a LoRa mesh network is activated in support of a formal emergency response, it operates within the National Incident Management System (NIMS) framework and is subject to Incident Command System (ICS) discipline. Mesh operators who arrive at an EOC or a field operations post without basic ICS literacy create coordination friction. This page provides the essential vocabulary and structural concepts every mesh operator should understand before deployment.

Key ICS Forms

FormNameMesh Relevance
ICS 201Incident BriefingRead-only for most operators; contains current situation, resources assigned, and initial incident map. Mesh operators should receive this at check-in.
ICS 205Incident Radio Communications PlanLists all assigned frequencies, channels, and modes for an operational period. Mesh channel selection must not conflict with assignments listed here. The ICS 205 is built (in part) from the pre-incident resource availability data on the ICS 217A.
ICS 213General MessageThe standard form for written messages between ICS positions. Frequently relayed over mesh or Winlink. Fields: To, From, Subject, Date/Time, Message, Reply.
ICS 214Activity LogA chronological log kept by each ICS position. This is the form for real-time, time-stamped status: mesh operators maintaining a node should keep an ICS 214 documenting activation time, channel changes, node counts, and any outages. Live node status belongs here (or on an incident status board), not on the ICS 217A.
ICS 217ACommunications Resource Availability WorksheetA pre-incident planning worksheet that inventories communications resources (radios, mesh nodes, repeaters) that could be available, by type, quantity, and capability. It feeds the ICS 205 — it is not a live, real-time status log. Use it to declare what mesh resources your group can bring; track their live operational status on the ICS 214 or a status board.

Net Control Station (NCS) Role

In a traditional voice net, the Net Control Station directs traffic, grants permission to transmit, and maintains net discipline. On a LoRa mesh there is no protocol-level NCS — the peer-to-peer architecture has no central station granting permission to transmit. That does not mean nodes transmit with no constraints, however: Meshtastic uses managed flood routing with listen-before-transmit (CSMA-style) channel access, and shared airtime and duty-cycle limits mean undisciplined traffic still congests the mesh. Human net discipline therefore remains necessary, and a mesh operator should be designated as the logical NCS responsible for:

Tactical Call Signs

NIMS requires the use of plain language and tactical identifiers — not codes or personal call signs — during multi-agency operations. Mesh node names should follow the tactical naming convention established in the Incident Action Plan (IAP). Examples:

Note on station identification: NIMS tactical identifiers are used for coordination, but any transmission on amateur (Part 97) frequencies must still include the operator's FCC-assigned call sign at least every 10 minutes and at the end of communications (47 CFR §97.119). Tactical names supplement, not replace, FCC station ID on any amateur-band leg. Mesh-only traffic on the unlicensed Part 15 915 MHz band has no FCC call-sign requirement.

Avoid using personal amateur radio call signs as node names on an ICS-integrated mesh - doing so mixes amateur radio identity with ICS tactical identity and can cause confusion in logs. This naming advice applies to the Part 15 mesh layer only; it does not waive the §97.119 call-sign ID requirement on any amateur-frequency link the operator also uses.

Radio Discipline on Mesh

Although mesh is asynchronous, operators should observe the following discipline to maintain operational effectiveness:

Mapping Mesh Nodes to ICS Resources

Under NIMS, all resources are typed and tracked. Mesh nodes fall under the Communications Unit (COMU) — led by the Communications Unit Leader (COML) — within the Logistics Section (Service Branch). The COML is responsible for all communications equipment. Mesh operators should:

NIMS Typing for Communications Resources

FEMA has published NIMS resource typing definitions for communications assets (the Operational Communications resource typing). LoRa mesh nodes do not yet have a dedicated NIMS type definition, so groups should document their resources under the closest applicable communications category — or as a clearly labeled local convention if no published type fits. (The label "Communications Unit - Data" used in some local plans is a convention, not a verified FEMA resource-type name; confirm against the current FEMA resource typing library before citing it formally.) Key attributes to document include throughput in bps, maximum hop count, battery endurance in hours, and whether the node supports a gateway or internet bridge function.

EOC Connectivity

An EOC typically operates as the hub of the mesh topology. Recommended EOC mesh configuration:

ARES and RACES Integration

Go Kit Building for Mesh Nodes

Introduction

A well-built mesh go kit allows rapid deployment of a fully functional LoRa mesh node in any environment - whether that is a shelter parking lot, a hilltop relay position, or the back of a command vehicle. This page covers case selection, power systems, antenna options, node hardware, and a pre-deployment checklist.

Case Selection

Weatherproofing is the first priority. The two most common case families are:

For a single-node portable kit, a mid-size case (Apache 3800 or Pelican 1450) is sufficient. For a multi-node relay kit with a larger battery, the Apache 4800 or Pelican 1510 provides adequate volume.

Power Systems

Battery Chemistry Comparison

ParameterLiFePO4SLA (AGM)
Energy densityHigher (lighter for same Ah)Lower (heavy)
Cycle life2,000+ cycles300-500 cycles
Self-discharge~3% per month~5% per month
Cold weather performanceCan discharge to about -20C, but must NOT be charged below 0C (32F) unless the pack has dedicated low-temperature charging support; a BMS usually disables charging when too cold (it blocks cold charging, it does not enable it)Degrades below 0C
Cost per WhHigher upfront, lower lifetimeLow upfront
Recommended usePrimary portable kitBase-station backup

A 10 Ah, 12 V LiFePO4 battery stores 120 Wh nominal (total) capacity; at 80% depth of discharge about 96 Wh is usable. This is adequate for most single-node 12-hour deployments.

Charge Controller

If solar charging is desired, a 10-20W solar panel is sufficient for a single-node kit. Use a charge controller that is explicitly LiFePO4-compatible (correct voltage setpoints), since LiFePO4 uses a different charge curve than SLA — the older Renogy Wanderer's lithium support varies by model and firmware, so verify before relying on it. Note that a 10A controller is far larger than a 10-20W panel needs; a small lithium-aware MPPT controller may charge more efficiently for the cost. Do not use a generic PWM controller without confirming its LiFePO4 voltage support.

Power Budget Calculation

Before deployment, calculate the required battery capacity. Where possible, work the budget in watt-hours (Wh), not raw mAh, to avoid mixing voltage domains (a node runs at ~3.7-5 V while a "12 V" pack is at 12 V):

  1. Measure or look up the current draw of the node hardware at full transmit and receive. These are approximate and depend heavily on configuration (light sleep, GPS state, screen); confirm against a meter or the Espressif/Semtech datasheets for your build. Typical ranges:
    • T-Beam v1.1 (ESP32 + SX1276 + GPS, GPS on, no light sleep): approximately 120 mA average (idle/receive), 200 mA peak (transmit) — lower with light sleep enabled
    • RAK4631 (nRF52840 + SX1262): a few mA average with light sleep (~200 uA in deep sleep), higher in continuous receive; ~100+ mA peak during transmit. Actual average depends on sleep configuration.
  2. Add loads for any accessories: OLED display ~30 mA; USB hub ~50 mA; Raspberry Pi companion ~400 mA.
  3. Calculate: mAh required = total_mA x hours divided by efficiency_factor. Use 0.85 for a new LiFePO4 pack. To compare against a 12 V pack, convert the node load to Wh and compare to the battery's Wh rather than comparing mAh figures across different voltages.
  4. Example: T-Beam (150 mA avg) + OLED (30 mA) = 180 mA x 12 h / 0.85 = 2,541 mAh minimum at the node's ~5 V rail (roughly 13 Wh). Note that a "5 Ah 12 V" battery is about 60 Wh, so it carries well over 2x margin in energy terms — but do not read the 2,541 mAh and 5 Ah figures as a direct ratio, because they are at different voltages. Always compare in watt-hours.

Antenna Options

Antenna TypeGainBest Use
Stub/whip (stock)2-3 dBiPortable, handheld, omnidirectional coverage
Mag-mount whip (915 MHz)3-5 dBiVehicle rooftop, rapid deploy, omnidirectional
Yagi (3-6 element)8-13 dBiPoint-to-point relay link, fixed direction
Fiberglass vertical (1/2 wave)5-6 dBiElevated fixed relay node, omnidirectional

Part 15 power note: Under 47 CFR §15.247, antenna gain above 6 dBi requires a dB-for-dB reduction in conducted transmitter power below the 1 W (30 dBm) maximum to keep EIRP within the limit. With an 8-13 dBi Yagi you must reduce transmitter output accordingly (e.g., a 13 dBi antenna requires roughly a 7 dB power reduction from 30 dBm). Pairing a 13 dBi Yagi with a full 1 W node would exceed the lawful EIRP — verify your configuration stays within the limit.

For most go kits, a 5 dBi mag-mount whip on a metal ground plane (cookie sheet, vehicle roof) provides a practical balance of gain and omnidirectional coverage. Include SMA adapters and short coax pigtails in the kit.

Node Hardware Selection

Pre-Deployment Checklist

Deployment and Operations

Deployment and Operations

Deploying Mesh Networks in Disaster Scenarios

Overview

Deploying a LoRa mesh network during an active disaster differs significantly from a planned exercise. Speed, improvisation, and integration with an active ICS structure are paramount. This page walks through the complete deployment sequence from pre-event staging through live operations.

Mesh is a supplement, not a lifeline. LoRa mesh (Meshtastic/MeshCore) is best-effort with no guaranteed delivery: messages can silently fail to arrive, the shared half-duplex channel saturates under heavy load, and coverage depends on powered relay nodes being in range. It is not a replacement for 911, NWS alerts, or licensed amateur/voice nets. For any life-threatening emergency, use 911/voice with confirmed receipt first; use mesh as a fallback when those are unavailable, and treat mesh status/position as supplementary.

Pre-Event Staging

The most effective disaster mesh deployments begin well before the event. Pre-staging includes:

Rapid Deployment Sequence

  1. Receive activation order from COML or ARES EC. Confirm assigned tactical node name, channel plan, and check-in frequency and interval.
  2. Travel to assigned position with go kit. Log departure time in ICS 214.
  3. Conduct site survey: Identify best antenna elevation point. Note any obstructions (buildings, terrain, foliage).
  4. Deploy antenna: Elevate to maximum practical height. Secure coax and weatherproof connections.
  5. Power up node: Allow 2-5 minutes for GPS cold fix. Confirm node name and channel in Meshtastic app.
  6. Test connectivity: Send a check-in message to EOC-MAIN. A green checkmark in Meshtastic confirms a protocol ACK for a direct message (best-effort, not a guaranteed end-to-end delivery and not proof a human read it). For anything life-safety, confirm with a human reply before relying on it.
  7. Report to COML: Via voice radio or mesh message - node name, location (GPS coordinates or address), battery level, estimated endurance, node count visible.
  8. Begin ICS 214 log: Record activation time, location, initial node count, and all subsequent events.

Antenna Elevation Strategies

In disaster environments, traditional antenna mounting points may be unavailable or unsafe. Practical options:

Frequency Coordination with Served Agency

Confirm that your LoRa channel center frequency does not conflict with LoRaWAN sensors already deployed by the served agency (e.g., flood sensors on 915.2 MHz). The Meshtastic default US channel preset should be checked against the agency sensor inventory. Document the agreed channel in ICS 205.

Mesh Topology for Disaster Environments

Meshtastic always uses managed flood routing - it does not offer selectable star/mesh/chain routing modes. The patterns below describe how you physically place nodes to approximate these shapes; the protocol underneath is the same flood-based mesh in every case.

Placement patternDescriptionWhen to Use
Star (hub-and-spoke)Field nodes are placed within direct range of one well-elevated central relay, so most traffic reaches the hub in a single hop.Open flat terrain; EOC has excellent elevation; small node count (fewer than 10).
Mesh (distributed)Nodes are spread so each is in range of several neighbors; the flood routing relays messages through multiple nodes to reach the destination.Urban rubble; blocked line-of-sight; large geographic area; many nodes.
Chain (linear relay)Nodes placed in a line to extend range along a corridor (road, valley, ridge), each within range of the next.Evacuation corridor monitoring; search teams moving along a defined route.

Key insight: In obstructed environments, additional well-placed relay nodes can extend coverage through obstructions where a direct link cannot - but each extra hop adds latency and consumes shared airtime, so add relays deliberately rather than maximizing hop count. Do not over-rely on this for search-and-rescue: RF into rubble or below grade is highly unreliable, so a relayed link to a hard-to-reach receiver may or may not get through and must not be treated as a dependable way to reach a trapped or buried person. Each hop re-transmits at the node's normal certified Part 15 power (maximum 1 W / 30 dBm conducted under 47 CFR §15.247) - there is no emergency exception allowing higher power on unlicensed ISM equipment. Meshtastic's default hop limit is 3 (maximum 7); raising the hop limit increases airtime and congestion. Do not reduce the maximum hop count below 3 in disaster deployments.

Interface with ICS Structure

The mesh network is a resource managed by the Communications Unit within the Logistics Section (Service Branch), led by the Communications Unit Leader (COML). In most ICS deployments, significant operational changes (channel reassignment, node redeployment, shutdown) should be coordinated with and authorized by the COML. Field mesh operators report to the COML, not directly to Operations. When Operations Section needs to reach a field team via mesh, the request flows: Operations Chief to COML to mesh operator to field node. This chain maintains ICS unity of command and ensures communications changes are coordinated.

Deployment and Operations

Net Control Operations for Mesh Networks

Mesh vs. Voice Net Control: A Fundamental Difference

In a traditional amateur radio voice net, the Net Control Station (NCS) is the technical and operational hub of all communications - every transmission must be directed through or acknowledged by NCS. LoRa mesh networks operate on a fundamentally different principle: they are peer-to-peer systems with no central controller. Nodes contend for a shared, half-duplex channel (listen-before-talk, with airtime and duty-cycle limits), so they do not transmit arbitrarily at any time; the mesh routes messages on a best-effort basis without a central controller.

Despite this, the operational role of a net control function remains valuable and is recommended for any mesh network supporting an ICS activation. The difference is that mesh net control is a human coordination role, not a technical gatekeeping role.

Responsibilities of Mesh Net Control

Structured Check-In Procedure

At the start of each operational period (operational periods in ICS are typically 12 to 24 hours), mesh net control should conduct a structured check-in:

  1. Net control sends a broadcast message to all nodes: [OPPERIOD-2 CHECK-IN] All nodes reply with status. EOC-MAIN standing by.
  2. Each node replies with a short status message: SHELTER-A: ONLINE, 85% battery, 4 nodes visible, 12 persons checked in.
  3. Net control logs each reply in the ICS 214 activity log, noting time of receipt and node status.
  4. Nodes that do not reply within 5 minutes (a configurable local threshold, not a fixed standard) are flagged as missing. Net control attempts contact via voice radio before recording the node offline on the ICS 214 activity log or incident status board. (Note: the ICS 217A is a pre-incident Communications Resource Availability Worksheet that feeds the ICS 205 comms plan - it is not a live node-status log, so do not record real-time outages there.)

Tracking Node Count and Coverage

Meshtastic provides a node list in the app showing all nodes heard (directly or via mesh). Net control should maintain a separate paper or spreadsheet log that includes:

Node NameOperatorLocationLast HeardBattery %Status
EOC-MAINW6XYZCity EOC RooftopContinuousAC PowerONLINE
SHELTER-AKD9ABCFranklin HS Gym14:3278%ONLINE
DIV-B-RELAYN7DEFOak Ave Water Tower14:2862%ONLINE
SEARCH-1KG5GHIMobile (Grid 4)14:0545%MONITOR

Handling Message Relay Requests

Although the mesh automatically routes messages, operators at field positions may request manual relay assistance when:

Net control should acknowledge all relay requests and provide confirmation to the originating node when a reply is received from the intended party. Absent a reply, assume the message did not arrive and escalate to voice.

Escalation to Voice Radio

Mesh net control must be prepared to escalate to voice radio immediately when:

The voice radio escalation path should be pre-coordinated: establish the tactical frequency and call sign of the COML before the operational period begins, and ensure mesh net control has a radio capable of reaching EOC. Note that if the escalation path is an amateur (Part 97) frequency, only licensed amateurs may transmit on it, with call-sign identification every 10 minutes and at the end of communication per 47 CFR 97.119. Ensure the designated escalation operator is licensed, or use a license-appropriate service (GMRS with its own license, FRS, or business radio) suited to the users.

Log Keeping

Net control must maintain a continuous ICS 214 activity log throughout the operational period. Minimum entries:

Mesh operations themselves are managed by the Communications Unit (COML) in the Logistics Section. At the end of each operational period, the completed ICS 214 is - like all unit logs - forwarded to the Documentation Unit in the Planning Section for inclusion in the incident file. (Forwarding logs to Planning's Documentation Unit does not make mesh a Planning-Section function; operational control remains with the COML in Logistics.)

Deployment and Operations

Integration with Winlink and APRS

The Complementary Stack

No single communications technology is sufficient for all emergency communications scenarios. The most resilient deployments combine multiple systems that complement each other's strengths. The three-layer stack of LoRa mesh plus Winlink plus APRS provides digital messaging, store-and-forward email, and position tracking - covering the primary data needs of an ICS-integrated emergency communications response.

Hardware Required for a VHF/VARA FM Gateway

Configuration Steps (VARA FM)

  1. Install VARA FM modem software and configure audio levels to the transceiver.
  2. Install Winlink Express. Configure station call sign, grid square, and VARA FM as the primary radio mode.
  3. Enable RMS Relay mode in Winlink Express to accept connections from client stations.
  4. Register the gateway with the Winlink network (requires licensed callsign and internet access at least once for initial registration).
  5. Test by connecting with a second station using Pat or Winlink Express in client mode.

ICS 213 forms composed in Winlink Express are transmitted as structured email attachments. Served agencies with standard email can receive these forms without any special software.

APRS as a Parallel Position Tracking Layer

Automatic Packet Reporting System (APRS) operates on 144.390 MHz (North America) and provides real-time position reporting, weather data, and short messaging via a nationwide network of digipeaters and I-gates (internet gateways). APRS operates under Part 97 and requires an amateur radio license to transmit: a mesh-to-APRS position bridge must be operated by a licensed amateur, and unlicensed users may not transmit on 144.390 MHz. APRS complements Meshtastic mesh in the following ways:

FeatureMeshtastic MeshAPRS
Position trackingYes (GPS, within mesh coverage)Yes (GPS, nationwide via digipeaters)
Text messagingYes (multi-hop; payload encrypted, but the default channel uses the public AQ== key — meaningful confidentiality requires setting a custom key)Limited (unencrypted, short messages)
Internet connectivity requiredNo (self-contained mesh)No for local; yes for APRS-IS
License requiredNo (ISM band)Yes (Technician or higher)
Nationwide coverageOnly where mesh nodes existYes (existing infrastructure)
Typical range per hop2-15 km10-100 km via digipeater

Note: Mesh text/position transport is best-effort with no guaranteed delivery. Where a message must be confirmed delivered or archived, use Winlink rather than mesh.

A field operator equipped with both a Meshtastic device and a VHF APRS tracker (e.g., Mobilinkd TNC with a handheld radio, or a Kenwood TH-D74) provides redundant position visibility: the EOC can track them on the local mesh map AND on aprs.fi via APRS-IS.

When all three systems are operational, the complementary roles are:

Tools and Software

ToolPlatformPurpose
Meshtastic appiOS / Android / WebMesh node control, messaging, map view
Winlink ExpressWindowsWinlink client and gateway software; ICS form templates included
Pat WinlinkLinux / macOS / Windows / Raspberry PiOpen-source Winlink client; CLI and web UI; ideal for headless gateway builds
DirewolfLinux / WindowsSoftware TNC for APRS and Winlink Packet; runs on Raspberry Pi
YAAC / APRSdroidJava (desktop) / AndroidAPRS client for tracking and messaging
atak-forwarderAndroid (ATAK plugin)Forwards Meshtastic positions into ATAK/WinTAK for ICS TAK server integration

Practical Integration Workflow

  1. Pre-event: Configure all mesh nodes on the agreed channel. Pre-load ICS 213 message templates on devices used by served agency liaisons.
  2. At EOC: Stand up Winlink gateway on VHF. Confirm Pat or Winlink Express can reach a CMS. Test ICS 213 form delivery to served agency email.
  3. At EOC: Enable APRS I-gate (via Direwolf and VHF radio) to provide internet-visible position tracking for all APRS-equipped operators.
  4. Operations: Field operators use Meshtastic for local comms. When a message must reach a served agency email (hospital, county OES), it is forwarded to the EOC mesh node and injected into Winlink for delivery. The EOC gateway must hand plaintext (decrypted) content to a licensed amateur's Winlink station — encrypted mesh traffic cannot be transmitted over amateur Winlink (47 CFR §97.113(a)(4)).
  5. Position tracking: EOC staff monitor both the Meshtastic map (local) and aprs.fi (wide area) to maintain situational awareness of all resources.

Training and Exercises

Training and Exercises

Running a Mesh Communications Exercise

Running a Mesh Communications Exercise

Exercises are the primary mechanism by which emergency communications groups validate their capabilities before they are needed in an actual incident. A well-designed mesh communications exercise will surface coverage gaps, equipment failures, procedural ambiguities, and operator skill deficiencies in a controlled environment where mistakes have no real-world consequences.

HSEEP Framework Basics

The Homeland Security Exercise and Evaluation Program (HSEEP) provides a standardised methodology for designing, conducting, and evaluating exercises. Key HSEEP concepts relevant to mesh communications exercises include:

Designing a Realistic Scenario

Effective mesh communications exercises are anchored in plausible local hazard scenarios. Three scenarios that work well for most communities:

Facilitator Guide Structure

A mesh communications exercise facilitator guide should include: exercise overview and objectives; scenario narrative with inject schedule (pre-scripted events delivered to players at designated times to drive exercise activity); expected player actions for each inject; evaluator guidance (what to observe, how to score); and facilitated hot wash guidance (structured discussion immediately after the exercise to capture initial observations before memory fades).

Common After-Action Findings

Common issues anticipated in mesh communications exercises — based on general emergency-communications experience rather than a specific published study — include:

Training and Exercises

Training New Operators on Mesh Equipment

Training New Operators on Mesh Equipment

A mesh network is only as capable as the operators who deploy and use it. A structured training programme ensures that operators at all levels can perform their expected functions reliably under the stress of an actual emergency - not just in the familiar environment of their home or club meeting.

Operator Competency Levels

A three-level competency framework gives training coordinators a clear structure and gives operators a defined progression path. This Level 1/2/3 framework is this book's own construct (referenced from the companion page "Running a Mesh Communications Exercise"), not an external standard:

Level 1: Basic User

A Level 1 operator can independently power on a node, connect to it via the Meshtastic app on a smartphone, send and receive text messages, and verify that their node appears on the network map. This level is appropriate for neighbourhood participants who will carry a node during an incident but are not responsible for network infrastructure. Expected training time: 60-90 minutes in a group setting, followed by self-directed practice at home.

Level 1 competency checklist:

Level 2: Configured Operator

A Level 2 operator can configure node settings (channel name, PSK, transmit power, GPS interval), change channels in response to a security compromise or coordination need, assist a Level 1 operator with connectivity problems, and interpret basic RSSI and SNR readings to assess link quality. This level is appropriate for neighbourhood zone leaders and ARES/RACES members who are part of the communications plan. Expected training time: 4-6 hours total, including hands-on configuration exercises. When adjusting transmit power, operators must keep the node within FCC Part 15.247 limits (max 1 W / 30 dBm conducted) and account for antenna gain above 6 dBi requiring a dB-for-dB power reduction; never exceed the device's certified output.

Level 2 competency checklist (in addition to Level 1):

Level 3: Infrastructure Operator

A Level 3 operator can plan and deploy a mesh network for a defined area, select and mount infrastructure node hardware (antenna selection, weatherproofing, power supply), troubleshoot RF issues (interference, path loss, multipath), and train Level 1 and Level 2 operators. This level is appropriate for team leaders, club technical officers, and EMCOMM coordinators. Expected training time: 10-20 hours of structured training plus documented field deployment experience.

Running a Mesh Familiarisation Session in 90 Minutes

A 90-minute session can introduce complete beginners to the basics, but expect some participants — especially genuinely non-technical people — to need follow-up help, particularly with Bluetooth pairing and app setup, before they can operate reliably under stress. Plan self-paced practice and a refresher rather than treating one session as full Level 1 competency. Suggested schedule:

  1. 0-15 min: Introduction to LoRa and mesh networking (what it is, why it matters for emergency communications, how it differs from cellular and WiFi).
  2. 15-35 min: Hardware overview: show and pass around nodes, explain the indicator LEDs, demonstrate pairing with a smartphone.
  3. 35-65 min: Hands-on practice: each participant pairs their smartphone to a node, sends a message, and locates their node on the map. Facilitator circulates to assist.
  4. 65-80 min: Scenario walk-through: facilitator narrates a simple scenario (power outage, neighbourhood check-in) and participants practice the check-in procedure.
  5. 80-90 min: Q&A, resource distribution (quick-reference card, link to Meshtastic documentation), and next steps (how to get a node, Level 2 training dates).

In-Person vs. Self-Paced Training

In-person training is strongly preferred for Levels 1 and 2, because the most common failure modes (Bluetooth pairing issues, incorrect channel configuration) are easiest to diagnose and correct when a knowledgeable facilitator is physically present. Self-paced video training works well as a supplement for operators who miss a session or need to review a specific procedure. Several ARRL and Meshtastic community members have published tutorial videos suitable for self-paced Level 1 and Level 2 training. Level 3 training requires field experience that cannot be replicated in a self-paced format.

Maintaining Operator Readiness

Skills degrade without practice. Scheduling quarterly mesh nets (structured on-air sessions where operators check in, pass practice traffic, and report node status) keeps all operator levels engaged and surfaces equipment problems before they matter in a real incident. Pairing quarterly nets with the exercises described in the companion page "Running a Mesh Communications Exercise" (which uses the Level 1/2/3 framework defined on this page) provides a complete readiness maintenance programme.