# 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
- **Individual prepper / first responder:** [Building a Go-Bag Node Kit](/books/emergency-communications/page/building-a-go-bag-node-kit)
- **ARES/RACES ham operator:** [Mesh Networking in ARES](/books/emergency-communications/page/mesh-networking-in-amateur-radio-emergency-service-ares)
- **Neighborhood / community organizer:** [Building Neighborhood Disaster Preparedness Networks](/books/emergency-communications/page/building-neighborhood-disaster-preparedness-networks)
- **Emergency manager:** [Integrating with Served Agencies](/books/emergency-communications/page/integrating-with-served-agencies)
## π What's In This Book
### Emergency Preparedness Basics
- [Why LoRa Mesh for Emergency Comms](/books/emergency-communications/page/why-lora-mesh-for-emergency-comms)
- [Building a Go-Bag Node Kit](/books/emergency-communications/page/building-a-go-bag-node-kit)
- [Pre-Deployment Checklist](/books/emergency-communications/page/pre-deployment-checklist)
- [Pre-Positioning Mesh Infrastructure for Disasters](/books/emergency-communications/page/pre-positioning-mesh-infrastructure-for-disasters)
### Disaster Scenarios
- [Wildfire Communications](/books/emergency-communications/page/wildfire-communications)
- [Earthquake Response](/books/emergency-communications/page/earthquake-response)
- [Flood and Severe Weather Response](/books/emergency-communications/page/flood-and-severe-weather-response)
- [Mesh Communications During Active Disasters](/books/emergency-communications/page/mesh-communications-during-active-disasters)
- [Deploying Mesh Networks in Disaster Scenarios](/books/emergency-communications/page/deploying-mesh-networks-in-disaster-scenarios)
### ARES, RACES, and Served Agency Integration
- [Mesh Networking in ARES](/books/emergency-communications/page/mesh-networking-in-amateur-radio-emergency-service-ares)
- [Integrating with Served Agencies](/books/emergency-communications/page/integrating-with-served-agencies)
- [ICS/NIMS Terminology for Mesh Operators](/books/emergency-communications/page/icsnims-terminology-for-mesh-operators)
- [Go Kit Building for Mesh Nodes](/books/emergency-communications/page/go-kit-building-for-mesh-nodes)
- [Net Control Operations for Mesh Networks](/books/emergency-communications/page/net-control-operations-for-mesh-networks)
### Winlink and Digital Integration
- [Winlink and LoRa Mesh: Complementary Systems](/books/emergency-communications/page/winlink-and-lora-mesh-complementary-systems)
- [Integration with Winlink and APRS](/books/emergency-communications/page/integration-with-winlink-and-aprs)
- [Building a Meshtastic-to-Internet Bridge](/books/emergency-communications/page/building-a-meshtastic-to-internet-bridge)
### Training and Exercises
- [Running a Mesh-Enabled EMCOMM Exercise](/books/emergency-communications/page/running-a-mesh-enabled-emcomm-exercise)
- [Running a Mesh Communications Exercise](/books/emergency-communications/page/running-a-mesh-communications-exercise)
- [Training New Operators on Mesh Equipment](/books/emergency-communications/page/training-new-operators-on-mesh-equipment)
## β‘οΈ Related Books
- [Starting a Community Mesh](/books/starting-a-community-mesh) - Building the network before the disaster
- [DIY Build Guides](/books/diy-build-guides) - Go-bag node hardware builds
- [Getting Started](/books/getting-started) - Ham radio licensing for emcomm operators
# 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.
# 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
- **One MeshCore-compatible LoRa node flashed with MeshCore firmware** β T-Echo, Heltec T114, or similar. Make sure the device's firmware matches the app you'll use (the MeshCore app for MeshCore firmware). See the [Getting Started](/books/getting-started) guide for current recommendations.
- **A USB charging cable** and a small battery bank. Runtime depends on the device and settings: a 10,000 mAh bank can run a low-power nRF52 node (T-Echo, T114) for a week or more, while a power-hungry ESP32 node with a screen may only last a few days.
- **A phone or tablet** with the MeshCore app installed to send and read messages.
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:
- **Dense urban/suburban (buildings, trees):** roughly 0.5β1.5 miles between handhelds at ground level (approximate, observed)
- **Suburban with one node elevated** (rooftop, second-floor window): roughly 1β3 miles (approximate, observed)
- **Open terrain** (parks, fields, rural): 3β10+ miles *with clear line of sight*
- **Elevated repeater node** (hilltop, tall building): can cover an entire neighborhood or small town, depending on height, antenna, and terrain β not guaranteed
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
- For long-term storage, store lithium cells at roughly 40β60% state of charge (not full) β prolonged storage at 100% accelerates battery aging. Recharge to full 24β48 hours before you expect to deploy. Check every 2β3 months and top up if a cell has self-discharged below this range.
- Keep a charging cable and battery bank with each node. Label each device with the owner's name.
- Consider a 5β10W folding solar panel for extended operations beyond 2β3 days.
- Write your family channel name on a card stored with the node β not the key/password, but the name, so whoever picks it up knows which channel to join.
# 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:
- Initiating scheduled check-ins and logging responses
- Relaying messages if a family member is out of direct range
- Deciding when to escalate (move to rally point, contact outside help)
- Keeping a written log of who has checked in and their status
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:
- **Routine event (power outage, approaching storm):** Check in every 2β4 hours, or immediately if your situation changes.
- **Active emergency (evacuation, earthquake aftermath):** Check in as soon as you reach safety, then every 1β2 hours.
- **Missed check-in:** Coordinator makes two contact attempts 15 minutes apart. If no response, activates the pre-agreed contingency (go to rally point, contact a relay neighbor).
## 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:
- `MOM / OK / HOME / NONE`
- `JAKE / OK / WORK / NONE`
- `DAD / OK-MOVING / HWY 12 NORTH / NONE`
- `SARAH / NEEDS HELP / 3RD AND MAIN / WATER`
### Agreed status codes
- **OK** β Safe, no immediate needs
- **OK-MOVING** β Safe, currently evacuating or in transit
- **NEEDS HELP** β Needs assistance, not life-threatening
- **EMERGENCY** β Immediate life-threatening situation (also attempt 911)
- **ALL CLEAR** β Arrived at rally point or final destination
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:
- **Primary rally point:** Close to home β a neighbor's house, a street corner, a nearby park. Used when you need to leave your immediate area but can stay in the neighborhood.
- **Secondary rally point:** Further away β a relative's house, a community center, a town outside your immediate area. Used when the primary area is unsafe or inaccessible.
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:
- **Designate a relay neighbor** β a nearby neighbor with a mesh node helps extend coverage: their powered node automatically relays messages between your family's nodes that are in range of it. Understand the limit, though β a neighbor's node cannot recover a message from a node that is dead, destroyed, or completely out of range. Treat it as extra coverage, not a guaranteed human backup.
- **Keep a written backup plan** β channel name, rally points, check-in schedule, and coordinator contact info on a waterproof card stored in each go-bag. If mesh fails entirely, fall back to this plan.
- **Know the secondary rally point by memory** β the plan must work with zero technology.
# 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
- **Feature-capable firmware** on the companion LoRa board. The Off-Grid / Repeat feature tracks specific recent MeshCore builds β roughly companion firmware ~v1.13 and app ~v1.40 or later; check the official MeshCore release notes for the current versions. (There is no MeshCore "firmware v9" β that is not how MeshCore is versioned.) If the toggle described below isn't visible in your app, the board needs a one-time firmware update. The canonical tool for this is the official MeshCore flasher at [flasher.meshcore.io](https://flasher.meshcore.io). Mesh America also offers its own device configurator at [apps.meshamerica.com](https://apps.meshamerica.com) β note that this is Mesh America's own tool, **not** the official MeshCore flasher. Whichever you use, do not interrupt a flash in progress: interrupting it can leave the device unusable.
- **MeshCore Open** β a free, open-source *community* client (by zjs81 / meshcoreopen.org), available for Android, iOS, and desktop. It is a third-party client, not an official first-party MeshCore app; on iOS it may be available via build-from-source or the web rather than a store binary.
- All devices that want to communicate with each other must be on the **same Off-Grid preset frequency** β decide this before you need it (see below).
## 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:
- **Off-Grid 918 MHz** β US and Canada. 918.0 MHz falls within the US/Canada 902β928 MHz ISM band (FCC Part 15, license-free), so unlicensed use is generally permitted with certified equipment β but it can suffer local interference (for example from smart meters) that may make it unusable in some areas, and it is intended for ad-hoc temporary meshes. Test it where you plan to use it before relying on it.
- **Off-Grid 869 MHz** β EU ISM band
- **Off-Grid 433 MHz** β offers longer range at a lower data rate, but 433 MHz allocations and power limits vary significantly by country and overlap amateur (70 cm) and short-range-device bands. Check your local regulations before using it; it is not freely available for this use everywhere.
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:
- **Place it at elevation.** A second-floor window, a rooftop, the top of a fence β every meter of height extends range. The companion's antenna is the limiting factor, not the software.
- **Keep the phone plugged in.** Off-Grid Repeat drains the battery noticeably faster than normal operation because the radio stays in continuous receive mode and retransmits every packet. Wall power is best; a battery bank is the minimum for extended use.
- **Keep the app in the foreground.** On Android, the app must stay active or battery optimization will kill the BLE connection and stop repeating. Disable battery optimization for MeshCore Open in Android settings if you plan to use this. On iOS, Apple's Core Bluetooth background-execution limits mean background BLE behavior may limit reliability for extended sessions β keep the app foregrounded.
- **Keep BLE range in mind β and understand this is fragile.** The phone maintains a BLE connection to the LoRa board. Don't walk the phone more than about 10 meters from the board β if BLE drops, repeating stops, often silently. Because the relay depends on the app staying open, BLE staying connected within ~10 m, and battery optimization being off, a phone-based relay can fail without warning. For anything you actually need to depend on, use a dedicated repeater node, not a phone.
## 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 Repeat | Dedicated Repeater |
|---|
| Free β uses hardware you already own | Requires a separate LoRa board (typically ~$30β60 as of 2026; price varies by board and vendor) |
| Ready in 30 seconds | Requires flashing and setup |
| Drains phone battery, needs power source | Low 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-connected | Always-on, fully independent |
| Mobile β moves with the person | Fixed, consistent coverage |
| Emergency and temporary use | Permanent 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.
# 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:**
- When power goes out, turn your node on and send an immediate check-in on your family channel.
- Reduce check-in frequency to conserve battery if the outage is expected to last more than a day.
- Place a node in a high window to maximize range to nearby family members β even a second-floor window makes a meaningful difference.
## 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:**
- Turn your node on as soon as you hear an evacuation order β before you start packing.
- Nodes still transmit from a moving vehicle, but range is short and MeshCore works best with fixed repeaters; do not rely on staying connected to other evacuees while driving.
- Send your evacuation route and destination to your coordinator before you get too far from other nodes.
- **Limitation:** If family members take different evacuation routes and no intermediate nodes exist, direct contact may fail. Fall back to your pre-agreed secondary rally point.
## 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:**
- Keep nodes charged and somewhere accessible β not at the bottom of a bag in a closet. A bedside table or desk drawer is ideal.
- After the shaking stops, do a rapid safety check before sending your first message so your status report is accurate.
- Nodes in damaged or collapsed structures won't communicate. If a family member in a vulnerable building goes silent, treat it as a welfare check situation.
- Monitor the public channel β neighbors will be sharing road conditions, shelter locations, and damage reports that official sources won't have for hours.
## 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:**
- **Pre-position before the storm:** Place a node at a high, sheltered location (a second-floor interior windowsill, under a covered porch overhang) before landfall. This extends coverage regardless of whether you shelter in place or evacuate.
- Seal nodes in a zip-lock bag β common consumer node enclosures carry no IP water rating and are not designed for rain exposure.
- If evacuating, take all nodes with you. A node left in a flooded home is a lost node.
## What Mesh Cannot Do
Honest limitations β important to understand before you depend on mesh in an emergency:
- **No voice.** MeshCore is text and data only. You cannot make a phone call.
- **No photos or images.** The bandwidth is far too low. It carries short text and small data like position, not media.
- **Not a substitute for 911.** Always attempt to reach emergency services first in a life-threatening situation, even if you expect congestion. A mesh acknowledgment is a best-effort radio confirmation, not proof a human received or will act on your message.
- **Range is finite.** Without repeater infrastructure, two handhelds may not communicate across a large city. Know your actual range from pre-disaster testing.
- **Battery-dependent.** A dead node cannot send or receive. Battery discipline is critical.
- **Not instant.** Message delivery takes seconds to minutes depending on hop count and mesh load β not suitable for split-second coordination.
# 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:
- A well-sited rooftop node can reach a mile or more in favorable line-of-sight conditions, sometimes much farther, but real range varies widely with terrain, antenna, and obstructions β handheld-to-rooftop links in built-up suburbs are often well under a mile. Test in your own area rather than assuming a fixed figure.
- In Meshtastic, an ordinary powered node generally helps relay for others by default. In MeshCore this is **not** true β ordinary powered client nodes do not relay for others; only dedicated repeater nodes (or a Companion with Off-Grid/Client Repeat explicitly enabled) forward traffic. Check which firmware your neighborhood is running before assuming any node extends coverage.
- A properly sized solar node on a sunny roof can run for long periods unattended, but not "indefinitely with no maintenance" β reliability depends on panel and battery sizing, season and weather, and batteries age and occasionally need service.
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:
- **The public channel** (default unencrypted channel) is your interface to the wider community mesh. Monitor it for situational awareness from people and groups you haven't coordinated with in advance.
- **ARES/RACES operators** in your area may deploy mesh nodes as part of organized emergency communications. These mesh nodes operate under Part 15 on the 915 MHz ISM band, the same as yours. If those operators bridge traffic to amateur radio, that leg requires a licensed operator and plaintext (no encryption) per 47 CFR 97.113(a)(4) β the 915 MHz mesh itself is not amateur radio.
- **Mesh America community nodes** in your area operate as always-on repeaters. Check the coverage map to see if your neighborhood is within range β if so, and if your device uses the same regional preset/frequency and channel, your handhelds can connect through them.
- **Keep channels separated by purpose:** private family channel for family, neighborhood channel for local coordination, public channel for broader awareness. Don't mix them.
## Next Steps
- [Set up your first family nodes](/books/emergency-communications/page/setting-up-a-family-mesh-network-before-disaster-strikes)
- [Build a go-bag node kit](/books/emergency-communications/page/building-a-go-bag-node-kit) for field deployment
- [Connect with ARES/RACES](/books/emergency-communications/page/mesh-networking-in-amateur-radio-emergency-service-ares) operators in your area
- [Detailed neighborhood network planning guide](/books/emergency-communications/page/building-neighborhood-disaster-preparedness-networks)
# 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
- **No external infrastructure required at the radio layer:** Nodes talk directly without cell towers, internet, or grid power β though useful neighborhood coverage normally relies on pre-placed elevated repeaters, and each node still needs its own power.
- **No amateur license required:** 915 MHz ISM band operation is legal for anyone in the US using FCC-certified Part 15 equipment, subject to the 1 W (30 dBm) conducted power limit and the EIRP cap β no amateur radio license needed. This enables rapid community-wide deployment.
- **Long range:** LoRa achieves multi-kilometer range at low power β far beyond Bluetooth or Wi-Fi β though range depends heavily on line of sight and antenna height (a transmitting node is typically powered by an 18650 or LiPo cell, not a coin cell).
- **Text and data:** Provides messaging when voice radio is saturated, inaudible, or unavailable
- **Mesh redundancy:** Messages can route around failed nodes when an alternate path exists (subject to the hop limit β default 3, max 7 on Meshtastic β and node density). This is self-healing, not guaranteed multipath.
- **Low cost:** Nodes are $20 - $60 each, enabling community-wide deployment at minimal cost
### Use Cases
- **Neighborhood coordination** during extended power outages
- **Family/group location tracking** over long distances without cell service
- **Relay messaging** across disaster zones where infrastructure is down, where surviving relay nodes or pre-placed repeaters bridge the gap (without surviving relays in range, the mesh does not span the zone)
- **Sensor monitoring** - water levels, temperature, structural sensors with LoRa mesh backhaul
### What LoRa Mesh Is Not
LoRa mesh is a complement to, not a replacement for, traditional emergency communications:
- **Not guaranteed delivery:** Mesh is best-effort. Messages can be delayed or lost with no acknowledgment in basic operation; never rely on it for life-safety traffic that must be confirmed received.
- **No voice:** Text/data only - voice communications still require traditional radio
- **Limited bandwidth:** Not suitable for transferring large files or images in real time
- **Range limits:** Urban environments with buildings and terrain obstacles reduce range substantially vs. hilltop-to-hilltop links
### 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)](https://wiki.meshamerica.com/books/emergency-communications/page/mesh-and-amateur-radio-aresraces)* for integration guidance.
# 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
| Component | Recommended Option | Notes |
|---|
| **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
- **Magnetic antenna mount:** For vehicle deployment - place antenna on roof for dramatic range improvement
- **Waterproof case:** Pelican 1150 or similar; protect electronics in wet conditions
- **Small tripod or mast:** Elevate antenna 2 - 3 meters above ground when vehicle deployment isn't available
- **Solar panel:** 10 - 20W panel + small charge controller for extended field deployment when sun is available. Solar is not guaranteed power - smoke, overcast, snow, and short winter days can zero out a small panel for days, so size the battery for the worst expected no-sun period.
- **Printed QR code:** Link to your local network's channel settings for quick onboarding of others
### 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](https://wiki.meshamerica.com/books/hardware-guide/page/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
# 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
- β Flash current firmware from [flasher.meshcore.io](https://flasher.meshcore.io) (MeshCore) or the Meshtastic flasher
- β Set node name to something identifiable (your callsign or neighborhood)
- β Set GPS coordinates (lat/lon)
- β Change all default passwords on room-server firmware before deployment. Some MeshCore room-server/repeater builds ship with well-known defaults (commonly admin: "password", guest: "hello"), but these are firmware-specific β consult your firmware's documentation for its actual default credentials rather than assuming a specific pair. **CHANGE THESE before any deployment:** anyone within RF range who knows the defaults can otherwise take over the node.
- β Apply the correct regional radio preset (a US/Canada preset for most North American MeshCore networks). The preset name and parameters are firmware-version dependent β match the current MeshCore preset for your region and confirm it stays within the legal 902β928 MHz band plan.
- β Attach and secure external antenna
- β Verify the node appears on a network map (map.meshcore.dev or meshmap.net)
### Connectivity Testing
- β Confirm channel/preset matches your local network
- β Test two-way communication with at least one other known node
- β Test from multiple locations (indoors, outdoors, vehicle)
- β Confirm room server (if deployed) accepts messages from client nodes
- β Verify MQTT gateway (if present) is publishing to broker
### Infrastructure
- β Consider a permanent rooftop or elevated repeater for neighborhood coverage - install before an emergency while conditions are normal
- β Ensure permanent repeaters have reliable power (ideally with UPS or battery backup)
- β Document all node locations, hardware, and configurations in a shared document accessible to your emergency team
### Team Preparation
- β Train all team members on the companion app before deployment
- β Establish and communicate channel names and passwords to all participants in advance
- β Assign a "mesh coordinator" role responsible for network status during an event
- β Export config backup and store separately from the device
### 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.
| Scenario | Typical Range |
|---|
| Urban direct (street level) | ~1 - 3 km typical; up to ~5 km in favorable line-of-sight conditions |
| Suburban rooftop-to-rooftop | 5 - 15 km with clear line of sight / rooftop elevation |
| Rural / hilltop-to-hilltop | 20 - 50+ km (50+ km requires elevated, clear-LOS endpoints with near-ideal Fresnel-zone clearance) |
| With mesh hops through repeaters | Extends 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
# 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
| Capability | Amateur Radio | LoRa Mesh |
|---|
| Voice communications | Yes - primary strength | No - text/data only |
| License required | Yes - FCC license required | No, 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 agencies | Hospitals, Red Cross, EOC | Neighborhoods, community groups |
| Long-range links | HF (worldwide), VHF/UHF regional | LoRa: 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 messaging | Winlink, APRS, packet | Native; all nodes capable |
| Deployment cost | $100 - $1,000+ per station | $20 - $60 per node |
| Deployment speed | Requires trained operator | Any 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:
- **Neighborhood layer (LoRa mesh):** Blocks to ~1-3 miles, more with elevated repeaters - coordination among neighbors, location sharing, welfare checks. No amateur license required when operated under Part 15 (FCC-certified equipment, 1 W conducted, EIRP-capped); any resident can deploy a node.
- **Regional layer (VHF/UHF amateur):** Repeater-linked coverage across a county or metro area. Requires licensed operators; handles voice coordination between neighborhoods and EOC.
- **State/national layer (HF amateur):** Winlink gateways and HF nets for long-distance traffic when regional infrastructure is compromised.
### For Amateur Radio Operators
If you hold an amateur radio license, consider:
- Deploying LoRa mesh alongside your existing radio setup to provide text/data capability for neighbors who don't have radio licenses. **Keep LoRa mesh on unlicensed Part 15 (902-928 MHz) frequencies. Do NOT run encrypted Meshtastic/MeshCore traffic on amateur bands** β 47 CFR Β§97.113(a)(4) prohibits messages encoded to obscure their meaning, and unlicensed neighbors may not transmit on amateur spectrum at all.
- Using LoRa mesh for neighborhood coordination while using your radio for ARES/RACES served agency traffic
- Advocating for LoRa mesh within your ARES group as a force multiplier for neighborhood-level coverage
# 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.
### Direct Link Range (No Repeaters)
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.
| Environment | Typical 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
- **Antenna height:** The single most impactful variable. As a rule of thumb, going from ground level to a 10-meter rooftop can roughly double or triple range by clearing Fresnel-zone obstructions.
- **Antenna gain:** A 5 dBi external antenna vs. a PCB trace antenna provides a significant range improvement (often roughly 2-3x in line-of-sight conditions; the exact gain is nonlinear and environment-dependent).
- **Spreading factor:** Higher SF (e.g., SF12 vs. SF7) adds roughly 15-18 dB of link budget β a meaningful range gain whose multiplier depends on terrain (free-space ~3x; less in obstructed paths) β while drastically cutting data rate and multiplying time-on-air (roughly 20x+ from SF7 to SF12). Treat the range gain as significant but environment-dependent, not a fixed multiple.
- **Terrain:** Line-of-sight clearance is critical. As an illustrative example, even a small hill between two nodes can collapse range dramatically (e.g., from ~20 km to ~2 km) through knife-edge diffraction loss.
- **Vegetation:** Dense forest canopy attenuates 915 MHz signals significantly. Summer foliage can reduce range compared to winter.
- **Buildings:** Each wall the signal passes through attenuates the signal. Inside-to-inside through multiple walls can reduce range to under 1 km.
### Planning Conservatively
For emergency planning, use these conservative estimates rather than the best-case table figures above:
- Inside a building: assume 300 - 500 m reliable range
- Outside in urban area: assume 1 - 2 km reliable range
- Rooftop with external antenna: assume 5 - 10 km reliable range (with clear LOS)
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.
- [heywhatsthat.com](https://heywhatsthat.com) - radio horizon from a specific location
- [nodakmesh.org/tools/node-planner](https://nodakmesh.org/tools/node-planner) - topo + satellite with live node visibility (region-specific community tool; verify it is still maintained)
- [radiomobile.pe1mew.nl](https://radiomobile.pe1mew.nl) - advanced RF propagation modeling
# 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
- **Independence from cell towers and the grid:** Cell towers near fire zones are often the first infrastructure to fail - whether from power loss, fire damage, or overload as residents attempt to reach family. Mesh operates independently of cellular networks and the grid - but only where its own nodes survive, have power, and remain in range, and delivery is best-effort. Fire can destroy the nodes you depend on, so plan redundant nodes and a non-mesh backup for evacuation-critical traffic.
- **Mobile coverage:** Portable nodes in vehicles, on firefighters, or at incident command posts create a mesh network that moves with the response operation.
- **Position tracking:** GPS-enabled nodes let incident command see crew positions as supplemental situational awareness without a dedicated tracking system. Note that mesh GPS positions can be delayed by minutes (or missing entirely) due to range, hops, and congestion, and a node in a coverage hole won't report at all - so do not rely on mesh GPS as a primary life-safety crew-tracking system.
- **Resilient backbone:** Solar-powered repeaters on hilltops with adequately sized batteries can continue operating during extended power outages, provided the site survives the fire and smoke does not starve the panels of light.
## Community alerting use case
A community mesh network with established repeater infrastructure can be activated as a grassroots alerting layer during a wildfire:
- Road conditions and evacuation route updates can be carried over the mesh - but mesh delivery is not guaranteed, so it must supplement, never replace, official alerts (Wireless Emergency Alerts, EAS, NOAA Weather Radio, local responders) for any evacuation instruction
- Nodes in affected neighborhoods can provide "eyes on the ground" status reports
- Air quality readings from BME680-equipped sensor nodes provide hyperlocal data
- Resource availability (shelters open/full, fuel, supplies) can be distributed across the mesh
## Field operations use case
For organized response teams (volunteer fire, SAR, CERT):
### Minimum viable field kit
- Net control operator with T-Deck Plus (MeshOS) or laptop + Pi room server
- 1 - 2 hilltop or elevated relay nodes (portable solar)
- Personal nodes for each field team (T-Echo or T1000-E, pocketable)
### 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
| Challenge | Mitigation |
|---|
| Smoke reduces solar panel output | Heavy 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 nodes | Document 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 devices | Train 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.
# 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:
- Cell service restoration varies widely (hours to weeks depending on damage and region); plan as if it will be unavailable or degraded for at least the first 72 hours
- Landlines may be out for days to weeks in heavily damaged areas
- Internet is intermittent; most social media platforms are unreliable in the first hours due to server load
- A pre-deployed mesh network with solar power and no internet dependency can help provide communications through this window on a best-effort basis (no guaranteed delivery); it should supplement, not replace, official channels and other backups
## Infrastructure resilience by node type
| Node type | Expected resilience | Key vulnerability |
|---|
| Ground-level portable (T-Echo, T1000-E) | High - battery-powered, no infrastructure dependency | Battery 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 shaking | Antenna damage from building movement; chimney/parapet collapse |
| Hilltop (solar, remote) | Very high - rarely near structural damage | Snow/debris on panel; equipment theft in post-disaster chaos |
| Building-powered (mains only) | Low - loses power immediately | Grid 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
- Deploy solar-powered anchor repeaters *before* an earthquake, not during response
- Distribute personal nodes to all neighborhood net participants
- Conduct quarterly check-in tests to verify devices are charged and configured
- Store node charging cables in emergency kits alongside device
- Document the channel/preset configuration in printed form, stored with the device - don't rely on memory under stress
- Coordinate with local CERT or ARES team so mesh participants know how to integrate with larger response structure
# 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:
- T1000-E: IP65-rated (per Seeed) - resists splashing and spray, but keep it out of standing water and immersion; IP65 is not rated for sustained submersion
- T-Echo: Not rated; put in a small zip-lock bag or simple waterproof case during rain operations
- Heltec V3/V4: Not rated; laptop bag or waterproof case required
### 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:
- Minimize transmissions to reduce battery drain on nodes that may not see sun for days
- Use standard welfare check format to efficiently survey neighborhood status
- At 915 MHz, rain has negligible direct effect on the signal - rain attenuation only becomes significant in microwave bands above roughly 5-10 GHz (ITU-R P.838). Range loss in storms is dominated by wet foliage, higher humidity, and lower antenna positions, not the rain itself.
## 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:
- **Battery sizing:** Solar panels under snow produce no power. Ensure battery autonomy covers the longest expected outage without sun. As a planning example, in northern latitudes this can be 5 - 10 days during winter storms; size from your actual load and local insolation rather than treating that range as a fixed figure.
- **Panel tilt:** A steep panel angle (60 - 70Β° from horizontal) helps snow slide off and improves low winter-sun capture when panels are clear. Optimal winter tilt is roughly your latitude plus 15Β°.
- **Cold battery performance:** LiFePO4 capacity drops in the cold (about 60% of its 15Β°C capacity near -20Β°C). More importantly, **never charge any lithium battery, including LiFePO4, below 0Β°C (32Β°F)** - sub-freezing charging causes lithium plating and permanent damage. A BMS that blocks cold charging protects the pack; it does not enable charging below freezing. Use a self-heating battery or a low-temperature charge cutoff, and size the pack 20 - 30% larger for mild cold, up to ~40-50% larger near -20Β°C.
- **Personal node operation:** Keep personal nodes in warm pockets - battery capacity drops sharply in cold. Charge from vehicle power banks if grid is out (and not while the battery is below freezing).
## 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:
- **\[ROUTINE\]:** General updates, non-urgent status
- **\[PRIORITY\]:** Important but not life-threatening (road closed, shelter open)
- **\[EMERGENCY\]:** Immediate life-safety issue requiring response
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
# 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:
- Mesh nodes are distributed among CERT teams
- Teams use mesh for status reporting during a simulated disaster scenario
- Net control demonstrates the GPS position board (where is every team right now?)
- Compare time-to-update for mesh vs. voice radio vs. runner
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:
- **Net Control maps to the Communications Unit Leader (COML) role within the Logistics Section (Service Branch)** per FEMA NIMS 509; the Communications Unit sits under Logistics, not Planning.
- **Channel naming:** Use ICS-aligned channel naming if possible (e.g., "IC-TAC1", "LOGISTICS-1") rather than geographic names
- **Message format:** ICS 213 General Message Form format for formal communications (from, to, message, date/time, signature)
- **Check-in/check-out:** Track mesh node operators on an ICS 214 Activity Log
## What not to do
- Don't present mesh as a replacement for ham radio, CERT radios, or existing systems. It's a complement, not a replacement.
- Don't overstate capabilities. Know the coverage gaps in your mesh and be honest about them with partners.
- Don't deploy in a real emergency before deploying in exercises. The first time field operators use any communication system should not be during an actual emergency.
- Don't let the technology drive the relationship. Build the relationship with emergency management first; the technology adoption follows from trust.
# 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:
| Item | Purpose | Notes |
|---|
| T-Echo or T1000-E | Personal mesh node | Pre-configured with correct channel & preset; fully charged |
| USB charging cable (device-specific) | Field recharge | Tape/label with device name; easy to grab wrong cable |
| 10,000 mAh power bank | Extended operation without grid | Can 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 card | Quick reference | Channel name, PSK, preset, net control contact |
| Spare SMA antenna | Backup if stock antenna damaged | 915 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:
| Item | Purpose |
|---|
| 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 USB | Room server + radio gateway; provides message persistence and network visibility |
| 5W foldable solar panel + MPPT charge controller | Recharge 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/station | Powers 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 roster | All mesh participants, device names, and contact info |
| Printed frequency/channel card | Config 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:
| Item | Notes |
|---|
| RAK4631 WisBlock (configured as repeater) in IP65 case | Pre-flashed with repeater firmware; USA/Canada preset; flood advertisements |
| 5 - 10W foldable solar panel with cigarette lighter connector | Mount 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 pigtail | Generally 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 bag | Waterproof; 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.)
- □ Top up all devices to full before deployment
- □ Top up power banks to full before deployment
- □ Solar panel functional (brief outdoor test)
- □ All devices verified on correct channel and preset
- □ Device names are current (verify in app)
- □ Printed config cards included and current
- □ Contact list current (who has which device)
- □ Portable repeater tested (connect, verify advertisement)
- □ Go-bag weight and bulk acceptable for intended deployment
# ARES, RACES, and Served Agency Integration
Integrating LoRa mesh with amateur radio emergency service organizations and their served agencies.
# 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:
- **Position tracking:** Each ARES operator with a Meshtastic node automatically broadcasts GPS position. A Meshtastic client running on a laptop at net control can display all operator positions on a map without consuming voice net time for position reports.
- **Short message traffic:** Operators in the field can send short status messages ("shelter at Lincoln School now at 47 occupants") without requiring net control to be available to receive a voice transmission.
- **Pre-positioned relay nodes:** ARES groups can deploy solar-powered mesh relay nodes at elevated sites (hilltops, water towers, repeater sites) to extend mesh coverage across the operating area.
- **Served agency liaison:** A mesh node at the served agency (Red Cross shelter, hospital, EOC), with the entire mesh segment running under Part 15 on 915 MHz ISM, allows served-agency staff to text ARES operators without a ham license. Both the licensed amateurs and the unlicensed staff are operating that mesh under Part 15; the amateur license is irrelevant to the 915 MHz mesh and grants no extra power or encryption privileges there. There is no regulatory mechanism for a Part 15 device to feed traffic into Part 97 amateur operation across the same RF link.
## 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](https://wiki.meshamerica.com/books/getting-started/page/the-915-mhz-ism-band) (US) operate under **FCC Part 15** - the same rules as Wi-Fi and Bluetooth. Part 15 operation:
- Requires **no license** to operate (with the conditions below)
- Limits conducted output power to **1 W (30 dBm) at the antenna port - not EIRP** (47 CFR 15.247). EIRP may be higher with antenna gain up to 6 dBi (about 36 dBm / 4 W EIRP); beyond 6 dBi the conducted power must be reduced dB-for-dB (47 CFR 15.247(b)(4)). Note this when using high-gain 8-13 dBi Yagis in go-kits.
- Prohibits causing harmful interference to licensed services
- Requires accepting interference from other Part 15 devices
- Does **not** allow power increases beyond Part 15 limits, even by licensed amateurs
**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**:
- Messages encoded for the purpose of obscuring their meaning, i.e. content encryption (47 CFR 97.113(a)(4))
- Commercial use or pecuniary interest
- Communications in which the licensee has a pecuniary interest
**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
- β EC briefed and supports mesh integration
- β At least one mesh exercise conducted alongside voice net
- β After-action report documenting mesh performance documented
- β Channel plan documented and distributed to all mesh operators
- β Part 15 power compliance verified on all deployed nodes
- β Encryption policy documented: mesh runs unencrypted on any Part 97 leg; encryption only on the Part 15 ISM mesh
- β Mesh roles assigned in ARES activation plan (mesh coordinator, relay node operators)
- β At least two operators trained on mesh node setup and troubleshooting
- β Mesh node inventory maintained with deployment locations
- β Mesh SOP incorporated into ARES local plan
# 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
- Needs: shelter population counts, resource requests (cots, meals, water), staff check-ins
- Message traffic: typically short, structured (ICS-213 equivalent), not conversational
- Key concern: accountability - messages must be logged (note mesh delivery is best-effort, so logging cannot assume a message was delivered)
- Staffing: mix of trained volunteers and paid staff; not all are technically sophisticated
- Integration point: mesh node at each shelter feeding position/status to EOC
### Hospitals
- Needs: patient counts by severity (START triage), resource status (available beds, O2, blood), evacuation coordination
- Message traffic: mesh is unencrypted by default and best-effort - never transmit protected health information (PHI), including any individually identifiable patient data, over mesh
- Key concern: HIPAA obligations rest with the hospital (the covered entity) and its business associates, **not** with volunteer mesh operators relaying traffic. Following this page does not make a volunteer's mesh use "HIPAA-compliant." Defer entirely to the hospital's own communications and privacy policies on what, if anything, may be transmitted; this page does not constitute HIPAA compliance guidance.
- Integration point: hospital HAM radio operator or communications officer; mesh for non-PHI status only
### Emergency Operations Center (EOC)
- Needs: comprehensive situational awareness; resource tracking; inter-agency coordination
- Message traffic: high volume, multi-agency, documented
- Key concern: integration with existing systems (WebEOC, ICS forms, CAD)
- Integration point: MQTT bridge connecting mesh to EOC dashboard; mesh coordinator assigned at EOC
### Fire and EMS
- Needs: incident position, resource status, casualty counts, scene perimeter
- Message traffic: tactical and time-critical; concise
- Key concern: interoperability with CAD and dispatch; not adding cognitive load to incident commanders
- Integration point: mesh as supplemental position tracking, not primary tactical comms
## 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:
- **Short status messages:** "Is the shelter at Lincoln School open and how many people are there?" Mesh can deliver roughly a 230-character answer (~228-237 byte payload; fewer characters if Unicode/emoji are used) without consuming repeater air time. Delivery is best-effort, so confirm anything critical.
- **Position data:** "Where are my teams right now?" Meshtastic's automatic GPS position broadcast answers this continuously without any operator action.
- **No additional training burden:** Served agency staff should be able to use mesh with minimal training. A Meshtastic node with a preconfigured channel and a simple phone app meets this bar.
- **Continues to function without infrastructure:** Mesh keeps working without cellular, internet, or repeaters - but coverage and delivery depend on node density and line of sight, and delivery is best-effort (not guaranteed). Treat this as a useful fallback, not a guarantee of communication.
## 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](https://wiki.meshamerica.com/books/hardware-guide/page/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
- β Met with served agency communications officer or OES coordinator
- β Demonstrated mesh capability during non-emergency visit
- β Identified served agency mesh liaison (person responsible for the node)
- β Written agreement / MOU in place with liability, indemnification, insurance, and non-reliance clauses; property-owner authorization obtained for any installation
- β Installed and configured mesh node at served agency location (AC/grounding/mast work by a qualified professional per local code)
- β Trained served agency liaison on basic operation (send/receive messages, check battery)
- β Conducted tabletop or field exercise with mesh integration
- β Documented served agency location in ARES mesh node inventory
- β Integrated mesh into served agency communication SOP as a supplemental (not primary) channel
- β Annual maintenance schedule established
- β Backup/spare node available if primary fails
# 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
- Multiple geographically dispersed field teams that need to track each other's positions
- Served agency location (shelter, hospital, EOC staging area) that needs to report resource status periodically
- Net control station that needs to track field team positions without consuming voice net time for position reports
- A simulated infrastructure failure (repeater "goes down" at a pre-planned time mid-exercise) to test mesh as a fallback
### Sample Scenario: [Earthquake Response](https://wiki.meshamerica.com/books/emergency-communications/page/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)
- β Identify all exercise areas and map expected operating locations
- β Identify elevated relay sites within exercise area (hilltops, buildings, repeater sites)
- β Deploy solar relay nodes at 1 - 3 elevated sites at least 24 hours before exercise
- β Verify relay node solar charging is functioning (check battery voltage)
- β Test message delivery from all expected field team operating areas to EOC node
- β Configure all nodes with exercise channel (separate from operational channel)
- β Assign node names following naming convention (e.g., RELAY-HILLTOP-1, FIELD-TEAM-A)
- β Verify all field team nodes have GPS lock in outdoor test
- β Brief all participants on channel configuration before exercise day
- β Assign backup power (charged batteries or power banks) to all deployed nodes
## 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](https://wiki.meshamerica.com/books/hardware-guide/page/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:
- Direct node-to-node (single hop) delivery rate
- Multi-hop delivery rate (messages relayed through 2+ hops)
- Delivery rate under different field conditions (urban, rural, elevated)
### 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
- Total mesh messages sent: \_\_\_\_\_\_\_\_\_\_
- Total mesh messages received at intended destination: \_\_\_\_\_\_\_\_\_\_
- Message delivery rate: \_\_\_\_\_\_\_\_\_\_%
- Average delivery latency (single hop): \_\_\_\_\_\_\_\_\_\_ sec
- Average delivery latency (multi-hop): \_\_\_\_\_\_\_\_\_\_ sec
- Voice net transmissions for position/status BEFORE mesh: \_\_\_\_\_\_\_\_\_\_
- Voice net transmissions for position/status WITH mesh: \_\_\_\_\_\_\_\_\_\_
- Voice net efficiency improvement: \_\_\_\_\_\_\_\_\_\_%
- Infrastructure node failures or outages: \_\_\_\_\_\_\_\_\_\_
#### Qualitative Assessment
- What worked well with mesh integration?
- What failed or caused confusion?
- Were there coverage gaps? Where?
- Did any operators misuse mesh (sent life-safety traffic that should have been voice)?
- Did the operator detect the simulated mesh non-delivery of life-safety traffic and escalate to voice?
- Was the Mesh Coordinator role effectively staffed?
- Were served agency liaisons able to use mesh without difficulty?
#### Corrective Actions
| \# | Issue Identified | Corrective Action | Owner | Due Date |
|---|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
#### Recommendations for Next Exercise
- Additional relay nodes needed at: \_\_\_\_\_\_\_\_\_\_
- Training improvements needed: \_\_\_\_\_\_\_\_\_\_
- Equipment changes recommended: \_\_\_\_\_\_\_\_\_\_
- SOP changes recommended: \_\_\_\_\_\_\_\_\_\_
**Key Message:** Winlink and LoRa mesh serve different but complementary roles in emergency communications. Serious EMCOMM operators use both - choose the right tool for each message type.
**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** (formally the Winlink Global Radio Email system, also known as Winlink 2000 or WL2K) is a worldwide radio messaging system that provides email capability over amateur radio and government HF radio networks. Winlink allows licensed amateur radio operators and authorized agencies to send and receive email-formatted messages via radio, completely independent of the internet - although it also supports internet-connected gateways (Radio Message Servers, or RMS) when internet is available.
Winlink operates on HF (shortwave), VHF, and UHF frequencies. Common access modes include:
- **Packet radio (AX.25):** VHF/UHF packet at 1200 or 9600 baud (traditional AX.25)
- **VARA FM:** a separate sound-card protocol for VHF/UHF (not AX.25 packet) β both are distinct Winlink access modes operated under Part 97
- **VARA HF / PACTOR:** HF digital modes for long-range communication without internet gateways
- **Winlink telnet:** Internet-connected mode when internet is available
- **ARDOP:** Open-source HF mode for Winlink operation
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](https://wiki.meshamerica.com/books/meshtastic-repeaters/page/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
Winlink excels at **formal, structured message traffic** - the kind that needs to be sent, received, archived, and acted upon by agencies that use email as their normal communication medium:
- **ICS forms:** Winlink supports transmission of standard ICS forms (ICS-213 general message, ICS-214 activity log, ICS-309 communications log, etc.) in a format that can be decoded and displayed at the receiving end without specialized software.
- **File attachments:** Winlink can carry binary file attachments (images, spreadsheets, maps) over radio - a capability mesh does not have.
- **Email to/from the internet:** Winlink messages addressed to normal email addresses are delivered when any RMS in the network has internet connectivity. This is essential for coordinating with agencies that aren't radio-equipped.
- **Global reach via Winlink network:** HF-connected Winlink can span thousands of miles. An operator in a disaster zone can exchange messages with a national-level EOC or agency headquarters regardless of local infrastructure status.
- **Message store-and-forward:** If the destination RMS is temporarily unavailable, messages are stored and delivered when connectivity is restored.
## 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 |
## What Winlink Does That Mesh Doesn't
| Capability | Winlink | LoRa Mesh (Meshtastic) |
| Email with internet delivery | Yes - messages delivered to any email address via Winlink network | No - mesh is local; requires a bridge for internet delivery |
| File attachments | Yes - binary attachments supported | No binary file attachments; payloads limited to ~228-237 bytes (text and structured app messages such as position/telemetry) |
| ICS form transmission | Yes - structured form data preserved end-to-end | No - would require manual encoding into short (~228-237 byte) messages |
| Global reach via HF | Yes - HF radio covers thousands of miles | No - LoRa 915 MHz single-hop range is typically a few km in terrain to tens of km with line of sight; total mesh reach extends via multi-hop relaying but remains regional, not global |
| Message store-and-forward reliability | Yes - Winlink stores messages until delivered | Partial - Meshtastic retries but does not guarantee delivery indefinitely |
## 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 Type | Best Tool | Rationale |
|---|
| 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 |
**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
| Approach | How It Works | Best 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
- **Raspberry Pi 4 or Pi Zero 2W** - runs bridge software, MQTT broker, and web interface
- **Meshtastic node connected via USB serial** - T-Beam or similar with USB-C; connected to Pi USB port; acts as the radio gateway
- **Internet uplink:** Ethernet (preferred for reliability), USB LTE modem (backup), or satellite terminal (Starlink Mini for major deployments)
- **Power:** 12V LiFePO4 battery with solar charge controller; Pi and Meshtastic node powered from same battery via 5V regulators
- **Enclosure:** NEMA 4X box (water ingress roughly equivalent to IP66); keep the Pi on a DIN-rail mount inside
## 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](https://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](https://wiki.meshamerica.com/books/hardware-guide/page/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](https://meshtastic.org/docs/configuration/module/mqtt/) 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:
- **Grafana + InfluxDB:** Time-series position and message data displayed on live dashboards with map panels. Node positions update periodically (typically on the node's position interval, often minutes), not continuously - treat the displayed position as last-known, not live, especially under heavy mesh load.
- **Custom Leaflet.js map:** A simple HTML/JavaScript page that receives webhook POSTs and updates node positions on an OpenStreetMap background. Can run on a Pi with no internet dependency.
- **Discord or Slack channel:** Mesh messages forwarded to a comms channel used by EOC staff. Provides visibility without requiring EOC staff to use Meshtastic directly.
- **ATAK (Android Team Awareness Kit):** Position data from mesh can be converted to CoT (Cursor on Target) XML and fed to ATAK via UDP, displaying mesh nodes on tactical maps alongside other ATAK data sources.
## Security Considerations for Public-Facing Bridges
### Security Requirements Before Public Deployment
- **Authentication:** Protect your webhook endpoint with API key authentication. Unauthenticated public webhooks are routinely discovered and abused (see the OWASP API Security Top 10), so never expose one without authentication.
- **TLS/HTTPS only:** All webhook traffic must use HTTPS. Never use HTTP for a production bridge carrying operational traffic (see OWASP Transport Layer Security guidance).
- **MQTT authentication:** Configure MQTT broker with username/password and TLS. Default Mosquitto is unauthenticated and open to the local network.
- **No PII over public bridges:** Never bridge personally identifiable information or sensitive medical details (which may be HIPAA-protected when handled by a covered entity such as a hospital on the net) over a public-facing webhook. Aggregate counts only. Note that HIPAA binds covered entities and their business associates - not volunteer mesh operators relaying traffic - so this is a data-minimization practice, not a way to make a volunteer's mesh use "HIPAA-compliant."
- **Firewall:** The Pi running the bridge should expose only necessary ports. MQTT (1883) should be firewall-blocked from WAN; use TLS MQTT (8883) with authentication if WAN access is needed.
- **Log retention:** All bridged messages should be logged with timestamps for post-incident review. Retain logs per your records policy (at least 30-90 days); consult counsel for incidents that may involve legal proceedings.
- **Physical security:** Gateway hardware at a served agency should be physically secured. USB access to the gateway node allows direct serial access to the mesh network.
## 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.
# 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:
| Approach | How It Works | When It Fails | Best 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:
- **High elevation or roof access** - extends radio range significantly
- **Likely to survive a regional disaster** - reinforced concrete buildings; fire stations are built to survive fires; hospitals have redundant power; water towers are physically resilient
- **Will be operationally active during a disaster** - someone will be there to notice if the node has a problem; the building has power for recharging if solar fails
- **Geographic distribution** - provides coverage across the operational area, not clustered in one location
### Priority Pre-Position Site Types
| Site Type | Value | Access 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:
- Has a much higher thermal-runaway threshold and resists thermal runaway under abuse conditions
- Tolerates partial state of charge better than LiPo
- Lasts 2,000 - 4,000+ charge cycles vs. 300 - 500 for LiPo
- Tolerates a wide operating window: LiFePO4 can **discharge** from about -20Β°C to +60Β°C, but must **NOT be CHARGED below 0Β°C (32Β°F)** β charging a cold lithium cell, including LiFePO4, permanently damages it. For cold-climate solar installs, use a BMS with a low-temperature charge cutoff or a self-heating battery (a BMS blocks cold charging; it does not enable it).
- Appropriate for permanent outdoor installation
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
- Use NEMA 4X (IP66) or better enclosures for all exterior nodes. NEMA 4X protects against hose-directed water (roughly IP66), not prolonged immersion (IP67) β for rain and water jets, IP66/NEMA 4X is the target; only specify IP67 if the enclosure will genuinely be submerged.
- Cable glands (IP68 rated) for all antenna and power connections through the enclosure wall
- Desiccant packs inside enclosure; replace annually
- Avoid vented enclosures in coastal or humid climates; sealed is safer
- For rooftop installations: steel or fiberglass enclosure preferred over ABS plastic (UV resistance)
### Antenna Mounts: Wind-Rated
- Use mounts rated for your site's design wind load. As a rule of thumb, allow margin above the highest sustained wind on record for your area (e.g. ~20%), but for any permanent or tall install defer to TIA-222 (Structural Standard for Antenna Supporting Structures and Antennas) wind-load design or your local building-code wind maps rather than a flat percentage.
- Stainless steel hardware for all mounting hardware (not zinc-plated; it corrodes faster than the antenna)
- J-pole or mast mounts with two attachment points minimum
- Guy wires for masts that extend well above their mount β roughly 3 feet is a common rule of thumb, but actual guying need depends on mast diameter, material, wind load, and antenna size; defer to the mast manufacturer's specs or TIA-222 guying guidance.
- Annual inspection: check all mounting hardware, antenna condition, and coax connections
### Lightning Protection
- All antenna coax must pass through an inline lightning arrestor before entering the enclosure (Polyphaser IS-50NX or equivalent)
- Lightning arrestor must be bonded to a solid earth ground (ground rod or structural ground) in accordance with NEC Article 810 and local code; have grounding/bonding performed or inspected by a qualified professional.
- In areas with high lightning incidence: consider a standalone suppressor at the Meshtastic node's antenna port as additional protection
- Disconnect protocol: if a major lightning storm is forecast and the node is safely accessible beforehand, disconnect the antenna cable at the node side to protect the radio. **Never service a rooftop node during an active storm** β disconnect only when it is safe to access the node well ahead of the storm.
## 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 ID | Long Name | Location | GPS Coords | Power Type | Battery Capacity | Installed Date | Last Inspected | Custodian | Notes |
| !ab12cd34 | RELAY-EOC-1 | County EOC Roof | 34.052Β°N, 118.243Β°W | Solar/LiFePO4 | 40Ah | 2024-03-15 | 2025-01-10 | John Smith W6XXX | MPPT controller; checked OK |
| !ef56gh78 | RELAY-FIRESTN-3 | Fire Station 3 Roof | 34.061Β°N, 118.251Β°W | Solar/LiFePO4 | 20Ah | 2024-05-02 | 2025-01-10 | Jane Doe KD6YYY | Battery replaced 2025-01; check seal |
## Pre-Positioning Checklist
- β All pre-position sites identified and written agreements in place with site owners. Site agreements should address liability, insurance/indemnification, who maintains the equipment, access, and removal/restoration obligations; have counsel review agreements for installations on third-party property.
- β Node inventory spreadsheet current with all installed nodes
- β All nodes using LiFePO4 batteries (no LiPo in outdoor installations)
- β All exterior enclosures IP66+ (NEMA 4X) rated with sealed cable glands
- β Lightning arrestors installed and bonded to earth ground on all antenna runs (per NEC and local code; professionally installed or inspected)
- β Antenna mounts rated for local design wind speed (per TIA-222 / local code)
- β Solar panels oriented and angled correctly for maximum winter sun
- β Annual inspection schedule in calendar; last inspection date recorded for each node
- β Coverage map updated showing all pre-positioned node locations and expected coverage
- β Each node has a named custodian responsible for maintenance
- β All nodes on a tested, known-good firmware version compatible across the fleet (do not blindly chase the latest release on hard-to-reach nodes)
- β Channel configuration consistent across all pre-positioned nodes
- β Go-bag reserve nodes stored separately for cache-and-deploy if pre-positioned nodes are damaged
# Mesh Communications During Active Disasters
**If you are reading this during an active emergency:** Jump to the [Quick Start](#bkmrk-quick-start%3A-mesh-op) 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 Event | What Typically Fails | What 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
| Priority | Traffic Type | Example | Action 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.
**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.
- **Meshtastic message logs:** The [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) and web client maintain a local message log. Export or screenshot the complete log at the end of each operational period.
- **Bridge logs:** If running a mesh-to-internet bridge, the bridge log captures all traffic with timestamps automatically. Preserve these files.
- **Paper log backup:** The Mesh Coordinator should maintain a paper log of FLASH and URGENT traffic as a backup. Paper survives power failures and software crashes.
- **Retention:** Retain mesh logs for at least 90 days post-incident, or per your served agency's policy or local records-retention law, whichever is longer (and longer still if the incident results in legal proceedings). The default retention figure is kept consistent with the mesh-to-internet bridge guidance; set the actual period from the served agency or applicable records law rather than an arbitrary number.
# 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:
- **Hyperlocal situational awareness:** Who needs help on your block? Who has medical training? Which houses are damaged? Mesh can carry this communication when phones are down - but only where a path of powered, in-range nodes exists, and delivery is best-effort with no guarantee.
- **Resource coordination:** "I have a generator and can share power." "We need insulin in the refrigerator on Elm Street kept cold." Short mesh messages coordinate resources without driving through blocked streets. *Privacy note: mesh messages are typically broadcast and may be unencrypted. Avoid broadcasting sensitive personal or medical details and specific vulnerable-person locations on open channels; use direct messages or a private channel and exercise basic privacy judgment.*
- **Connection to official emergency services:** A mesh node at the neighborhood EOC staging area, connected to the official mesh network, bridges the neighborhood to city-level response.
- **Community resilience:** Neighbors who have trained together and have communication tools recover faster and experience less psychological distress during disasters.
## 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:
- Already train for disasters; mesh is a natural addition to their toolkit
- Have an organizational structure that can absorb mesh training
- Have a relationship with city OES that provides legitimacy for mesh integration
- Are geographically distributed across the community - ideal for mesh coverage
**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:
- Maintains a Meshtastic node (typically a small, low-cost device like a WisBlock Meshtastic kit)
- Knows how to send and receive messages on the neighborhood channel
- Serves as the communication relay for neighbors who don't have mesh nodes
- Reports to a neighborhood zone leader (who reports to city OES)
- Checks in during exercises and activations
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:
| Item | Storage Location | Maintenance Interval | Responsible 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
- LiFePO4 batteries: inspect annually. Many LiFePO4 packs last 8-10+ years, but for life-safety standby consider replacement at 5-7 years or when capacity drops below 80% (check the cell/pack datasheet).
- LiPo/Li-ion power banks: replace after 2 - 3 years or if capacity has dropped below 80%
- Meshtastic nodes: firmware-update annually; replace hardware after 5 - 7 years or if hardware fails
- Coaxial cable: inspect annually; replace any cable with cracked jacket or corroded connectors
- Antenna mounts: inspect annually; replace if corrosion is visible on structural hardware
## 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
| Time | Activity | Objective |
|---|
| 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 |
| Capability | HF/VHF Voice | LoRa Mesh |
|---|
| Long-distance voice relay | Excellent (HF) | Not applicable |
| Structured digital forms (ICS213) | Commonly via Winlink or other digital forms tools (FLMSG), or relayed by voice using formal message-handling procedures | Plain-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, slow | Asynchronous text, fast (best-effort) |
| License required | Yes (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 needed | Repeaters, linked systems | Self-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
- **ICS Forms**: ICS 213 general messages and ICS 214 activity logs can be sent as plain-text messages (manually entered, or via external tooling - there is no built-in ICS-form module) over mesh hops toward an EOC node for printing or forwarding via Winlink. Mesh delivery is best-effort and not guaranteed, so a form sent this way is not assured to arrive; use Winlink/voice when a record copy must be delivered.
- **Position Tracking**: Meshtastic built-in GPS position sharing provides a blue-force track of all mesh-equipped operators, visible on the map view of the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) or on third-party integrations such as a TAK server via atak-forwarder. Note atak-forwarder is a third-party project; verify it is still maintained and compatible with your current Meshtastic firmware before relying on it (as of this writing).
- **Welfare Traffic**: Mass-casualty or shelter-in-place events generate high welfare check-in volume. Mesh text messages allow operators to report status without consuming voice net time - on a best-effort basis.
## 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:
- Which frequency channel preset will be used and how frequency coordination is handled if the served agency operates nearby LoRa sensors.
- Who owns and maintains the fixed relay nodes installed at agency facilities such as a node on the EOC rooftop.
- Data handling: are mesh messages logged, and if so, where? Who has access to those logs?
- Activation triggers: under what conditions does the mesh network activate, and who issues the activation order?
- Training requirements: which agency staff will be issued Meshtastic devices, and what minimum proficiency is required?
- Liability and risk allocation: limitation of liability, mutual indemnification, insurance/coverage expectations, and an explicit clause stating that mesh is a supplemental, best-effort capability with no guaranteed delivery and is not to be relied upon as a primary or life-safety channel. Have counsel review any MOU before signing.
# 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
## 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:
- Monitoring mesh traffic and flagging missed check-ins.
- Coordinating channel changes if interference is detected.
- Serving as the interface between the mesh network and the ICS Communications Unit Leader (COML). A human mesh coordinator interfacing with the COML is recommended practice; see the FEMA NIMS 509 COML job aid.
- Maintaining the live node-status log on the ICS 214 (the pre-incident resource list is the ICS 217A).
## 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:
- `EOC-MAIN` - Primary EOC mesh node
- `SHELTER-A` - Node at Shelter Alpha
- `DIV-BRAVO-1` - First field node in Division Bravo
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:
- **Identify yourself**: Begin each sent message with your tactical identifier even though Meshtastic shows the sender node name. This reinforces ICS message format habits. (Note: this is a readability convention, not security β typing your name does not cryptographically authenticate you and does not prevent spoofing.)
- **Time-stamp critical messages**: ICS 213 format requires a date-time group. Include it in mesh messages that will be transcribed to paper forms.
- **No unnecessary traffic**: Mesh bandwidth is limited. Test messages and chatter consume airtime. Use a separate channel or Meshtastic admin channel for testing.
- **Acknowledge receipt**: Meshtastic provides delivery acknowledgment for direct ("reliable") messages β but *not* for broadcast/channel messages β and an ACK can be a best-effort relay acknowledgment rather than proof a human read or acted on the message. Always require an explicit human reply such as RCVD/WILCO for ICS 213 messages requiring action.
## 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:
- Check in their nodes with the COML on arrival, declaring their resources using the pre-incident ICS 217A availability data.
- Report node status changes (battery level, coverage gaps, node failures) to the COML, and log them in real time on the ICS 214.
- Not change mesh channels or configurations without COML authorization.
## 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:
- At least two redundant nodes (primary and backup) on separate power circuits.
- One node configured as a MQTT gateway (if internet connectivity is available) to provide mesh traffic visibility on a remote dashboard. If you bridge mesh traffic off-site via MQTT, secure and restrict it (authentication/TLS), avoid carrying personal or sensitive data off-site, and follow the served agency's data-handling rules.
- Node antenna elevated to rooftop or mast level to maximize coverage.
- ICS 214 activity log maintained for each node, updated at each operational period change. (An operational period is the timeframe set for executing a given set of objectives β usually 12 to 24 hours.)
# 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](https://wiki.meshamerica.com/books/emergency-communications/page/pre-deployment-checklist).
## Case Selection
Weatherproofing is the first priority. The two most common case families are:
- **Pelican cases** (e.g., 1510 carry-on, 1450 mid-size): High-quality latches, pressure equalization valve, pick-and-pluck foam. Manufacturer-rated waterproof (Pelican rates the Protector line IP67 with the purge valve closed β check the current spec). More expensive but very durable.
- **Apache cases** (Harbor Freight): A good budget alternative that costs substantially less than Pelican. Harbor Freight markets Apache cases as IP67-rated as well (verify the current manufacturer spec). They are similar but not identical β latch durability and warranty differ. Pre-cut foam available; customizable with aftermarket inserts. Treat any price comparison as approximate and check current pricing.
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
| Parameter | LiFePO4 | SLA (AGM) |
|---|
| Energy density | Higher (lighter for same Ah) | Lower (heavy) |
| Cycle life | 2,000+ cycles | 300-500 cycles |
| Self-discharge | ~3% per month | ~5% per month |
| Cold weather performance | Can 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 Wh | Higher upfront, lower lifetime | Low upfront |
| Recommended use | Primary portable kit | Base-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 Type | Gain | Best Use |
|---|
| Stub/whip (stock) | 2-3 dBi | Portable, handheld, omnidirectional coverage |
| Mag-mount whip (915 MHz) | 3-5 dBi | Vehicle rooftop, rapid deploy, omnidirectional |
| Yagi (3-6 element) | 8-13 dBi | Point-to-point relay link, fixed direction |
| Fiberglass vertical (1/2 wave) | 5-6 dBi | Elevated 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
- **LILYGO T-Beam v1.1 or v1.2**: Integrated ESP32, SX1276/SX1262, GPS, and 18650 battery holder. Best for portable handheld use. Available with 868/915/923 MHz variants.
- **RAK4631 (WisBlock)**: nRF52840 + SX1262 modular system. Excellent power efficiency, compact. Requires WisBlock Base Board. Best for compact fixed relay builds. GPS available as an add-on module.
- **Heltec LoRa32 v3**: ESP32-S3 + SX1262 + integrated OLED. Good budget option for fixed relay nodes.
## Pre-Deployment Checklist
- \[ \] Node firmware updated to latest stable Meshtastic release
- \[ \] Node name set to tactical identifier per IAP (e.g., SHELTER-B)
- \[ \] Channel/PSK configured to match operational channel plan
- \[ \] GPS fix confirmed (cold start may take 2-5 minutes outdoors)
- \[ \] Battery charged and voltage verified. Note: 12.8V is the *nominal* voltage of a 4S LiFePO4 pack, not the fully-charged figure β a fully charged 4S LiFePO4 pack rests near 13.3-13.6V (and reads ~14.2-14.6V during or just after charging). Do not treat 12.8V as 100% state of charge, or you will under-charge the pack.
- \[ \] Antenna SMA connector torqued finger-tight plus 1/8 turn (do not over-torque)
- \[ \] Coax and antenna tested for continuity (SWR check if meter available)
- \[ \] Spare 18650 cells or USB power bank included
- \[ \] [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app) (iOS/Android) or web client tested and connected via BLE/WiFi
- \[ \] Deployment contact list (COML name, frequency, mesh channel, check-in interval) printed and laminated
- \[ \] ICS 214 form (blank) included for activity logging
- \[ \] Case latches and pressure valve inspected; foam dry
# 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:
- **Fixed relay nodes at key sites**: EOC, hospitals, Red Cross shelters, CERT caches, and strategic high-elevation points (water towers, fire stations) should have permanently installed relay nodes maintained on standby power.
- **Go kit pre-positioning**: Portable node kits stored at ARES/RACES deployment caches, pre-configured with the operational channel and node names.
- **Firmware and configuration freeze**: Two weeks before a forecast event (hurricane, wildfire season), freeze firmware versions and push final channel configurations. Do not update during an active event.
- **Battery maintenance**: Store lithium cells (including LiFePO4) at approximately 40-60% state of charge during standby to limit calendar aging; top up to full only in the 24-48 hours before expected deployment. Never charge any lithium chemistry, including LiFePO4, below 0 Β°C (32 Β°F).
## 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](https://wiki.meshamerica.com/books/hardware-guide/page/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:
- **Vehicle rooftop**: Magnetic mount antenna on a metal vehicle roof is fast to deploy and provides 2-4 meters of elevation above grade. Most effective in flat terrain or when working in a parking lot staging area.
- **Temporary mast**: A 3-6 meter telescoping fiberglass push-up mast (e.g., MFJ-1910 or equivalent) with a ground stake can be deployed in under 5 minutes by one person. Provides significant elevation advantage.
- **Existing structure attachment**: In urban rubble environments, attaching a whip antenna to any surviving elevated structure (fence post, utility pole stub, intact second-floor window frame) can provide 3-6 meters of elevation with minimal equipment.
- **Balloon lift**: For extended fixed relay in flat terrain, a helium balloon can lift a lightweight node and antenna to 10-30 meters. Requires tether management and calm wind conditions. Tethered/moored balloons may be subject to FAA rules (14 CFR Part 101), including height, marking, and notification requirements, and pose hazards near power lines and aircraft - check FAA requirements and local conditions before deploying.
## 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 pattern | Description | When 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.
# 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
- **Node inventory management**: Maintain a current list of all active nodes (name, operator, location, battery endurance). Update at each operational period change and whenever a node is added or goes offline.
- **Coverage verification**: Confirm that all assigned positions have mesh connectivity, either directly or via relayed path. Nodes that cannot reach any other node are isolated and may need repositioning.
- **Channel discipline**: Monitor for excessive traffic (bulk test messages, repeated retransmissions) that degrades bandwidth for others. Coordinate with the COML to address violations.
- **Liaison to COML**: Translate mesh network status into ICS-compatible status reports for inclusion in the Incident Action Plan.
- **Escalation to voice radio**: When mesh connectivity fails between critical nodes, escalate to the voice radio net for the affected link. This is recommended SOP precisely because LoRa mesh is best-effort with no guaranteed delivery - do not wait for the mesh to self-heal if the message is time-sensitive.
## 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 Name | Operator | Location | Last Heard | Battery % | Status |
|---|
| EOC-MAIN | W6XYZ | City EOC Rooftop | Continuous | AC Power | ONLINE |
| SHELTER-A | KD9ABC | Franklin HS Gym | 14:32 | 78% | ONLINE |
| DIV-B-RELAY | N7DEF | Oak Ave Water Tower | 14:28 | 62% | ONLINE |
| SEARCH-1 | KG5GHI | Mobile (Grid 4) | 14:05 | 45% | MONITOR |
## Handling Message Relay Requests
Although the mesh automatically routes messages, operators at field positions may request manual relay assistance when:
- A message requires positive confirmation of delivery. The mesh delivers best-effort; Meshtastic does show an ACK/Delivered status per message, but those ACKs are not guaranteed, so a human relay provides positive confirmation when delivery is critical.
- The message contains sensitive information not suitable for broadcast (use the DM/direct message channel in Meshtastic).
- An ICS 213 form needs to be transcribed to paper at the EOC.
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:
- A node has been offline for more than 10 minutes without explanation.
- A critical message (MCI report, EOC request, shelter closure) has not been acknowledged within 5 minutes.
- The mesh channel appears to be experiencing congestion or RF interference (excessive retransmissions, failed acknowledgments).
- Any node reports battery below 20% without a relief operator on the way.
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:
- Activation and deactivation times for each node.
- All check-in responses and any non-responding nodes.
- Channel changes, configuration updates, or firmware actions taken.
- All message relay confirmations for ICS 213 traffic.
- Battery status at each check-in interval.
- All voice radio escalations and outcomes.
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.)
# 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.
## Winlink Overview
Winlink is a worldwide radio email system that allows licensed amateur operators (and, under certain authorizations, non-amateur stations) to send and receive email messages via radio. Amateur-band Winlink requires an amateur radio license; separate Winlink networks exist for MARS and authorized government/EmComm stations operating under their own licensing (e.g., Part 80/government allocations) β these are not open to unlicensed users on amateur frequencies. Key components:
- **Winlink Common Message Server (CMS)**: The cloud-based message store operated by the Winlink Development Team. Messages are held until retrieved by the recipient.
- **Radio Message Server (RMS)**: A gateway station (typically a licensed operator's station with a TNC and radio) that provides radio access to the CMS. RMS gateways exist on HF (Pactor, VARA HF, ARDOP, Robust Packet) and VHF/UHF (Packet, VARA FM). Note: LoRa is not an official Winlink RMS access mode β third-party experiments bridge LoRa mesh to Winlink, but there is no LoRa RMS mode in Winlink's supported-mode list.
- **Client software**: Winlink Express (Windows) or Pat Winlink (cross-platform, open source) are used by operators to compose messages and connect to RMS gateways.
## Building a Winlink Gateway for ICS Form Delivery
A Winlink RMS gateway co-located with a mesh EOC node creates a powerful hybrid: field operators compose ICS 213 messages on a mesh-connected device, and those messages are forwarded to the EOC node which relays them into the Winlink system for delivery to served agency email addresses.
> **β οΈ Legal boundary β plaintext only, licensed operator.** Winlink rides licensed amateur RF, where 47 CFR Β§97.113(a)(4) prohibits transmitting messages encoded to obscure their meaning. Meshtastic payloads are AES-256 encrypted by default, so the gateway must present **plaintext (decrypted) content** on the amateur Winlink leg, and a **licensed amateur** must operate that leg. Encrypted Meshtastic payloads cannot lawfully be transmitted on amateur frequencies.
### Hardware Required for a VHF/VARA FM Gateway
- VHF FM transceiver (e.g., Icom IC-7100, Kenwood TM-D710)
- Sound card interface or VARA FM modem (e.g., Digirig Mobile)
- Windows PC or Raspberry Pi running Winlink Express or Pat
- Internet connection to CMS (for a full gateway); or peer-to-peer mode for offline operation
### 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:
| Feature | Meshtastic Mesh | APRS |
|---|
| Position tracking | Yes (GPS, within mesh coverage) | Yes (GPS, nationwide via digipeaters) |
| Text messaging | Yes (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 required | No (self-contained mesh) | No for local; yes for APRS-IS |
| License required | No (ISM band) | Yes (Technician or higher) |
| Nationwide coverage | Only where mesh nodes exist | Yes (existing infrastructure) |
| Typical range per hop | 2-15 km | 10-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.
## Mesh + Winlink + APRS: The Complete Stack
When all three systems are operational, the complementary roles are:
- **LoRa Mesh (Meshtastic)**: Short-range text messaging (payload encrypted, but the default channel uses the public AQ== key β set a custom key for real confidentiality), welfare check-ins, ICS 213 relay within the incident area, GPS position sharing among mesh-equipped operators.
- **Winlink**: Store-and-forward email delivery for ICS forms to served agency recipients, long-haul message delivery via HF when VHF infrastructure is unavailable, formal record of messages (timestamped, archived).
- **APRS**: Nationwide position tracking for mobile operators outside mesh coverage, real-time map display on aprs.fi for remote coordination, weather object broadcasting.
## Tools and Software
## 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
# 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:
- **Exercise types:** Tabletop exercises (TTX) involve discussion of scenarios around a table with no equipment deployment; functional exercises (FE) are operations-based exercises that test functions and decision-making using a system of simulators and exercise injects, with no movement or actual "boots on the ground" field deployment of personnel (in a mesh context this typically means activating and operating equipment from fixed positions rather than deploying teams to the field); full-scale exercises deploy people and equipment to simulate an actual incident response. For mesh communications, starting with a TTX to validate procedures, then a functional exercise to validate equipment, is a recommended progression before attempting a full-scale exercise.
- **Objectives:** HSEEP requires that exercises have specific, measurable objectives tied to core capabilities. Frame objectives as things to *measure* rather than reliability levels to assume β for example, "measure what fraction of welfare-check messages originating from designated neighbourhood nodes reach the EOC within 10 minutes" (set the target from your own baseline data, and expect best-effort mesh delivery rates to vary widely with load and terrain rather than assuming a high fixed percentage), or "network operator can reconfigure channel settings within 5 minutes of a security compromise notification."
- **After-Action Report (AAR):** HSEEP-compliant exercises produce an AAR that documents exercise objectives, observed strengths, areas for improvement, and a corrective action plan with assigned owners and target completion dates.
### Designing a Realistic Scenario
Effective mesh communications exercises are anchored in plausible local hazard scenarios. Three scenarios that work well for most communities:
- **Extended power outage (3-7 days):** For this exercise, assume cellular towers are on generator backup and that local cell sites begin failing after roughly 24-48 hours β but treat this as a scenario assumption, not a fact: actual battery/generator endurance varies widely by carrier and site (often only a few hours on battery alone, longer with generators and refuelling). Internet is intermittent or unavailable. The exercise tests whether the mesh can carry welfare traffic and coordinate resource distribution without internet or cellular infrastructure.
- **Wildfire evacuation:** Multiple zones are under evacuation orders. Road closures and smoke limit travel. The exercise tests whether the mesh can relay evacuation status, shelter capacity, and resource requests between field teams, the EOC, and reception centres.
- **Earthquake with infrastructure damage:** Multiple buildings are damaged. A simulated percentage of nodes are offline (to represent destroyed or inaccessible nodes). The exercise tests whether the remaining nodes can keep traffic flowing around the gaps β note that Meshtastic reroutes via managed flood rebroadcast only where an alternate in-range node exists; it does not compute repaired routes like a routed network, so "self-healing" only works if another node is within RF range of the gap β and whether operators can identify and document coverage holes.
### 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:
- **Coverage gaps in specific neighbourhoods:** Often correlate with terrain features (hills, valleys, dense tree canopy) not fully accounted for in the network design. Corrective action typically involves adding a node on an elevated structure in the gap area.
- **Operators needing more training:** Operators who can turn on and send a message but have not practised configuration tasks can be expected to struggle when asked to change channels or assist a neighbour with an equipment problem. (The Level 1/2/3 operator tiering used elsewhere in this library is our own framework, not an external standard.)
- **Procedural gaps:** Absence of documented check-in procedures (who checks in with whom, at what interval, using what format) leads to confusion about network status. Writing and distributing a one-page standard operating procedure for check-ins is a common corrective action.
# 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](https://wiki.meshamerica.com/books/hardware-guide/page/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:
- Powers on node and confirms LED status
- Connects smartphone to node via Bluetooth
- Sends a test message to the group channel
- Confirms message was received by at least one other node. A successful test confirms the link worked at that moment; mesh delivery is best-effort and not guaranteed, so re-test periodically and do not assume a one-time success means the link is reliable.
- Locates their own node on the map view
- Can describe what to do if the node battery dies (recharge procedure)
#### 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):
- Changes node name and role settings
- Configures a new channel with a specified PSK
- Adjusts transmit power and GPS reporting interval. **Never set transmit power above the legal limit for your region/band.** In the US 915 MHz ISM band, stay within FCC Part 15 limits (1 W / 30 dBm conducted, EIRP-capped); do not exceed the device's certified output. Ham-mode operation is separate and governed by Part 97.
- Reads and interprets RSSI/SNR values for two active links
- Assists a Level 1 operator who cannot connect via Bluetooth
- Documents node configuration in the deployment log
#### 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](https://wiki.meshamerica.com/books/getting-started/page/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](https://wiki.meshamerica.com/books/emergency-communications/page/running-a-mesh-communications-exercise)" (which uses the Level 1/2/3 framework defined on this page) provides a complete readiness maintenance programme.