# 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.