Contents
- Executive Summary
- Introduction: The Warning That Never Came
- Origins: Hurricane Sandy and the Lesson of Reactive Response
- The Global Early Warning Crisis
- The SafeGround Solution
- Technical Architecture
- SENTINEL: Proof of Concept
- Alignment with EW4All
- Open Source Philosophy
- Pilot Programme: Pissouri, Cyprus
- Implementation Pathway
- Call to Collaboration
- References & Further Reading
1. Executive Summary
SafeGround is an open-source, infrastructure-independent early warning system designed to function in the complete absence of cellular networks, power grids, and internet connectivity — precisely the conditions created by the disasters it is designed to warn against.
Built on LoRa (Long Range) mesh networking technology, SafeGround deploys self-healing community mesh networks that relay structured emergency alerts across distances of up to 15 kilometres per hop, without any dependency on commercial telecommunications infrastructure. The system is explicitly aligned with the United Nations Early Warnings for All (EW4All) initiative and its 2027 mandate for universal multi-hazard early warning coverage.
The project originates from lived experience of the 2012 Hurricane Sandy response, through the work of EdgeKnowledge and the Friendship Train Foundation, and was refined through the GBREX platform before being relaunched and fully specified in response to the UN EW4All mandate of 2022.
SafeGround is currently in active development, with a proof-of-concept device (SENTINEL) under construction and a candidate pilot deployment site identified in Pissouri, Cyprus. The project is open to pilot partnerships, technical contributors, research collaborators, and funders.
2. Introduction: The Warning That Never Came
On 29 October 2012, Hurricane Sandy made landfall near Brigantine, New Jersey. The storm had been forecast days in advance. Evacuation orders had been issued. And yet, in the communities hardest hit — lower-income coastal areas, densely populated urban margins, rural zones on the outer edges of cellular coverage — the warnings did not reliably reach the people most at risk, in time to act.
The failure was not meteorological. The forecasts were accurate. The failure was infrastructural: the cellular networks, internet connections, and power grids through which most final-mile alerts were delivered had already degraded — or would within hours — under the storm's advance effects. The warning system that worked for administrators and emergency managers did not reach the last mile.
Sandy is not unusual. It is a pattern. Post-event analysis of virtually every major disaster of the last three decades reveals the same finding: warning systems fail their most critical function — final-mile delivery — precisely because they depend on the infrastructure the disaster has already impaired.
This white paper describes a system designed from first principles to eliminate that dependency.
3. Origins: Hurricane Sandy and the Lesson of Reactive Response
3.1 EdgeKnowledge and the Pre-Storm Mobilisation
In the days before Sandy, a rapid-response network was convened through EdgeKnowledge, an apolitical philanthropic think tank. The network brought together disaster response specialists with field experience from Katrina (2005), the Haiti earthquake (2010), the Japan earthquake and tsunami (2011), and the 2004 Indian Ocean tsunami. The Friendship Train Foundation — a humanitarian mobilisation network — supported this effort, enabling rapid cross-organisational coordination.
This pre-storm assembly was productive. It produced coordination frameworks, resource mapping, and response plans. But it could not produce the one thing that would prove most critical in the aftermath: a communications system that would survive the storm itself.
3.2 The Post-Sandy Response
In the immediate aftermath of Sandy, with cellular infrastructure damaged across the affected region, the response team turned to long-range radios. The radios worked. They worked because they had no dependency on the infrastructure Sandy had damaged. The lesson was immediate and obvious: the system that survives a disaster is the system that was built independently of what the disaster destroys.
The post-Sandy work produced a replicable disaster resource centre model, instantiated as the Sea Bright Resource Center in partnership with the Monmouth County Long-Term Recovery Group (MCLTRG) and with engagement from FEMA. This provided a template for community-anchored post-disaster coordination — but it was reactive, not proactive. The system had been built after the storm. The next chapter was to build it before.
3.3 GBREX — Technology as Infrastructure
GBREX, the next platform in this lineage, extended the post-Sandy lessons into a technical platform for post-disaster zone operations. As Technology Lead, the work encompassed encrypted peer-to-peer data transfer for medical records, case management, and micro-economic tools running on mesh-networked hardware. GBREX demonstrated at small scale that mesh networking — designed for adversarial conditions from the ground up — could provide the communications backbone that commercial infrastructure could not sustain under disaster conditions.
3.4 The EW4All Catalyst
In November 2022, the United Nations Secretary-General announced the Early Warnings for All initiative at COP27, committing to universal multi-hazard early warning coverage for every person on Earth by the end of 2027. This mandate provided the policy framework and urgency that transformed an ongoing research and development effort into a deployable system. SafeGround is the direct response to that mandate.
4. The Global Early Warning Crisis
4.1 Scale of the Gap
According to the World Meteorological Organization's Global Status of Multi-Hazard Early Warning Systems (2024), approximately 3.5 billion people — nearly half the world's population — lack access to adequate multi-hazard early warning systems. The distribution of this gap is not random: it is concentrated in low- and middle-income countries, remote and rural communities, and disaster-prone regions with the least existing telecommunications infrastructure.
Over 90% of disaster-related deaths occur in these under-served communities. A 24-hour warning can reduce disaster-related mortality by up to 30%. The economic case is equally clear: every $1 invested in early warning systems saves an estimated $10 or more in disaster response costs (WMO, 2023).
4.2 Why Existing Systems Fail
The fundamental failure mode of existing early warning systems is infrastructure dependency. The final mile of virtually every national early warning system relies on one or more of the following: cellular SMS broadcast; push notification via smartphone; sirens on grid power; internet-connected dashboards for local emergency managers. All of these share a common vulnerability: they depend on infrastructure that is among the first to fail in a major disaster.
This is not a marginal problem. Cellular towers fail due to power loss, physical damage, and network congestion. Power grids fail due to flooding, wind damage, and fuel supply disruption. Internet connectivity fails in all the same ways. The very conditions that create the urgency for a warning are the conditions under which the warning infrastructure collapses.
4.3 The Last-Mile Problem
Even in countries with functional national early warning systems, "functional" often means functional at the national or regional hub level. The last mile — the connection from regional emergency management to individual households in rural areas, low-income communities, and areas with limited cellular coverage — is frequently absent or unreliable.
SafeGround is designed with the last-mile problem as its primary design constraint. The system is not an additional layer on top of existing national systems: it is a self-sufficient alternative that can function entirely without them.
5. The SafeGround Solution
5.1 Core Principle
SafeGround is built on a single non-negotiable constraint: the system must function in the complete absence of cellular networks, power grids, and internet connectivity. Every design decision flows from this constraint. Any component or dependency that could fail under disaster conditions must be eliminated or made redundant.
5.2 LoRa Technology
SafeGround uses LoRa (Long Range) radio technology — a low-power wide-area network radio modulation technique operating on unlicensed spectrum bands. LoRa transmissions can achieve line-of-sight ranges of 5–15 kilometres on battery power, and 2–5 kilometres in typical mixed urban/rural terrain. LoRa nodes require no SIM card, no cellular subscription, no internet connection, and can operate on battery or solar power indefinitely.
In mesh configuration, each LoRa node acts as both a receiver and a relay. An alert generated at an Admin Hub propagates across the mesh through successive relay hops, reaching every connected node regardless of distance from the source — provided the node graph is connected. The mesh self-heals around node failures: if a node goes offline, the routing algorithm automatically finds alternative paths.
5.3 Community Ownership
SafeGround is explicitly designed to be community-owned and community-maintained. Hardware costs for a Tier 1 user node (the basic receive-and-relay unit) are below £50 at component cost. Tier 2 contributor nodes are in the £150–250 range. The Admin Hub — which provides the AI intelligence layer and LoRaWAN gateway — is below £500 in hardware cost. A complete community deployment of 30 nodes for a village of 2,000 people is achievable below £20,000 in hardware costs, with no recurring subscription or licence fees.
6. Technical Architecture
6.1 Three-Tier Mesh Architecture
SafeGround deploys a three-tier node hierarchy. Each tier is designed to function independently when connectivity to higher tiers is unavailable, while enhancing system capability when the full mesh is operational.
Tier 1 — User Node
| Component | Specification |
|---|---|
| Hardware | LILYGO T-Beam v1.1 |
| Microcontroller | ESP32-WROOM |
| LoRa module | SX1276, 868 MHz |
| Range (LOS) | Up to 5 km |
| Power | 18650 Li-ion battery, optional USB-C charge |
| Display | 0.96″ OLED |
| GPS | NEO-6M (for location registration) |
| Function | Receive alerts, display GREEN/AMBER/RED status, relay to adjacent nodes, acknowledge receipt |
Tier 2 — Contributor Node
| Component | Specification |
|---|---|
| Hardware | LILYGO T-Beam Supreme |
| Microcontroller | ESP32-S3 |
| LoRa module | SX1262, EU868 |
| GPS | u-blox M10 |
| Range (LOS) | Up to 15 km |
| Power | Solar panel + LiFePO4 battery (7-day autonomy in low-sun conditions) |
| Function | Mesh relay, bridge between User Node clusters and Admin Hub, optional sensor aggregation |
Tier 3 — Admin Hub
| Component | Specification |
|---|---|
| Compute | Raspberry Pi 4 (4GB) |
| LoRaWAN gateway | RAK2287 HAT (SX1302 concentrator) |
| AI intelligence | Claude API (Anthropic) via Python agent |
| Seismic sensor | ADXL345 (via Spark Core dedicated MCU) |
| Environmental | BME680 (temperature, humidity, pressure, VOC) |
| Uplink | Primary: Ethernet/WiFi; Failover: Starlink satellite; Emergency: LoRa-only mesh |
| Display | 7″ touchscreen e-ink (primary status) or HDMI monitor |
| Function | Generate, sign, and broadcast CAP v1.2 alerts; AI threat assessment; post-event SitRep routing |
6.2 Communications Protocol
Radio Specification
SafeGround operates on the EU868 MHz frequency band (867–869 MHz) under ETSI EN 300 220 regulations. EU868 imposes a maximum 1% duty cycle on most sub-bands, limiting each node's transmission to a maximum of 36 seconds per hour in the most commonly used 125 kHz bandwidth configuration. This constraint is the primary driver of the custom TDMA MAC layer.
TDMA MAC Protocol
SafeGround uses a custom Time Division Multiple Access (TDMA) protocol rather than the ALOHA-based random access protocol used by consumer mesh solutions such as Meshtastic. Each node is assigned a transmission slot within a defined frame period, calibrated to the number of active nodes and the EU868 duty cycle limits. This allows deterministic, duty-cycle-compliant mesh operation at deployments of 30–200 nodes — the range at which ALOHA-based approaches produce unacceptable collision rates and duty cycle violations.
Alert Encoding
All SafeGround alerts conform to Common Alerting Protocol (CAP) v1.2, the international standard for emergency alerts adopted by WMO and UNDRR. Because a full CAP XML message is several kilobytes — far too large for LoRa's typical 250-byte payload limit — SafeGround implements a custom hexadecimal encoding layer that compresses essential CAP fields (event type, severity, certainty, urgency, area, instruction, and expiry) into a 128–200 byte binary payload. The Admin Hub expands incoming compressed alerts to full CAP v1.2 format for downstream system integration.
Encryption
All messages on the SafeGround mesh are encrypted using XChaCha20-Poly1305 — a 256-bit symmetric stream cipher with 192-bit extended nonces, providing authenticated encryption with forward secrecy properties. The extended nonce size (compared to standard ChaCha20) eliminates practical nonce-reuse attack risk even in high-volume multi-node deployments. Key exchange uses X25519 Elliptic Curve Diffie-Hellman, with node identity tied to Ed25519 signatures for message authentication.
6.3 Tactical Integration
SafeGround nodes register with the Admin Hub as ATAK (Android Team Awareness Kit) data sources, providing real-time mesh topology overlays and alert status information to responder devices running ATAK. Cursor-on-Target (CoT) XML packets are generated by the Admin Hub and forwarded over any available data connection (including LoRa serial bridge for offline ATAK integration).
All node location data and alert area references include What3Words three-word address encoding alongside standard GPS coordinates, enabling precise location communication by non-technical users without requiring coordinate literacy.
6.4 Post-Event Communications
The SafeGround mesh provides not only pre-event warning but post-event communications infrastructure through two standardised message types:
- SitRep (Situation Report): Structured reporting of casualty status, infrastructure damage assessment, and population status from affected communities to the Admin Hub. SitRep templates are stored on User Nodes and can be completed and transmitted without internet connectivity.
- Resource Request: Standardised requests for specific resources (medical, water, shelter, rescue) from communities to response coordination. Conforms to NIEM Emergency Data Exchange Language (EDXL) Resource Messaging.
These post-event message types transform the SafeGround infrastructure from a warning broadcast system into a full bidirectional disaster communications backbone — active before, during, and after the disaster event.
7. SENTINEL: Proof of Concept
SENTINEL is a single-device proof-of-concept that collapses the full SafeGround three-tier architecture into one portable unit. It is designed for deployment in a domestic or small-community setting — a research residence, a community centre, or a civil defence post — and is currently under active development for deployment in Pissouri, Cyprus.
7.1 Hardware
- Primary node: LILYGO T-Beam Supreme (ESP32-S3 + SX1262 LoRa + u-blox M10 GPS)
- Hub compute: Raspberry Pi 4 (4GB) with RAK2287 LoRaWAN concentrator HAT
- Seismic: ADXL345 3-axis accelerometer via dedicated Spark Core MCU (isolated from Pi power rail)
- Environmental: BME680 (barometric pressure trending, temperature, humidity, VOC index)
- Display: Waveshare 7.5″ e-ink display (primary status dashboard, readable in all light conditions)
- Power: Primary mains UPS with 8-hour LiFePO4 battery backup; GO mode on separate 20,000 mAh power bank
7.2 Operating Modes
SENTINEL operates in three modes, with automatic transitions triggered by threat assessment:
- HOME: Static continuous monitoring. Seismic and barometric data polled every 60 seconds. AI threat assessment generated every 15 minutes. GREEN / AMBER / RED status displayed on e-ink. No alerts broadcast unless threshold crossed.
- ALERT: Triggered when any threshold is exceeded: seismic magnitude >3.5 (local, USGS/EMSC confirmed), barometric drop >8 hPa / 3 hours, Copernicus EFFIS fire risk elevation, or EMSC regional event >5.0. Broadcasts CAP-encoded alert to mesh; email notification; push notification (Pushover). Logs event with full sensor record.
- GO: Portable mode. Main Pi hub on battery. T-Beam Supreme operating as handheld mesh communicator and GPS beacon. e-ink display shows last known threat assessment, GPS position, and What3Words address. Mesh continues operating without hub compute layer.
7.3 Intelligence Layer
The SENTINEL intelligence layer is a Python Claude agent running on the Raspberry Pi 4, using the Anthropic SDK with tool_use for structured data retrieval. The agent implements the following tool chain:
- get_seismic_data: Polls USGS Earthquake Hazards Program and EMSC for events within configurable radius and magnitude threshold
- get_weather_data: Retrieves Cyprus Meteorological Service forecasts and Open-Meteo barometric time series
- get_fire_risk: Polls Copernicus Emergency Management Service EFFIS for fire weather index and active fire detections
- assess_threat: Synthesises all available data into a structured GREEN / AMBER / RED assessment with structured reasoning and confidence indicators
The agent runs on a 15-minute cycle in HOME mode, and continuously in ALERT mode. All assessments are logged with full provenance for post-event analysis and system improvement.
8. Alignment with EW4All
The United Nations Early Warnings for All initiative is built around four pillars that together constitute a functional multi-hazard early warning system. SafeGround addresses all four:
- Pillar 1 — Disaster Risk Knowledge: The AI intelligence layer provides continuous multi-source hazard monitoring, generating structured risk assessments that can inform community preparedness action independently of national systems.
- Pillar 2 — Observation, Monitoring & Forecasting: SENTINEL's seismic, barometric, and environmental sensors provide local observational data, complemented by integration with international monitoring networks (USGS, EMSC, Copernicus, national meteorological services).
- Pillar 3 — Warning Dissemination & Communication: This is SafeGround's primary technical contribution. The LoRa mesh bypasses every dependency on cellular, internet, and grid infrastructure that causes conventional dissemination systems to fail under disaster conditions. CAP v1.2 conformance ensures interoperability with national warning systems where they exist.
- Pillar 4 — Preparedness & Response: Post-event SitRep and Resource Request messaging, ATAK integration for responder situational awareness, and a community-deployable model designed for long-term self-sufficiency.
9. Open Source Philosophy
SafeGround is an open source project under the MIT Licence. Every component of the system — firmware, protocol implementation, AI agent code, hardware schematics, and deployment documentation — is published openly and made available for adaptation, improvement, and deployment without restriction.
This is not merely a licensing decision. It is a strategic choice grounded in the nature of the problem. The early warning gap is global in scale. No single organisation can close it. The only viable path to universal coverage by 2027 — or at any point in the realistic future — is a shared standard that can be deployed by NGOs, local governments, community groups, and civil society organisations worldwide, without commercial barriers, proprietary lock-in, or ongoing licence costs.
SafeGround's hardware is specified using commercially available, globally-sourced components. The software runs on commodity hardware. The protocols are open standards. The goal is not to become a product company. The goal is to become a standard — the way TCP/IP is a standard, not a product.
10. Pilot Programme: Pissouri, Cyprus
10.1 Site Selection Rationale
Pissouri, a coastal village of approximately 2,000 residents in the Limassol district of Cyprus, has been identified as a strong candidate for the first SafeGround pilot deployment. The site combines multiple factors that make it an ideal proof-of-concept environment:
- Multi-hazard exposure: Pissouri sits on the African-Eurasian tectonic plate boundary, experiencing routine seismic activity. The 2012 Pissouri landslide event displaced 24 families and left over 150 homes at ongoing risk. The 2021 Arakapas wildfire complex — which destroyed 55,000 hectares across the Troodos region — extended to areas within 20 km of Pissouri. Flash flood risk is present in the seasonal stream channels (wadis) that cross the village.
- Infrastructure characteristics: Zero existing LoRa infrastructure. Cellular coverage is functional under normal conditions but has historically degraded during major events. Starlink satellite coverage is available for Admin Hub uplink failover.
- Geopolitical context: Cyprus is an EU member state with access to Copernicus Earth observation services, a functioning civil defence organisation, and existing relationships with the University of Cyprus research community.
- Research access: An existing SENTINEL development unit is being established at a Pissouri residence, providing a live seismic and environmental monitoring dataset from which to build the community deployment case.
10.2 Proposed Deployment Specification
| Parameter | Value |
|---|---|
| Total nodes | 30 (candidate proposal) |
| Admin Hub (T3) | 1 — hilltop behind village (highest elevation) |
| Contributor Nodes (T2) | 3 — village centre, bay road, western cliff area |
| User Nodes (T1) | 26 — residential and community distribution |
| Sensor integration | 20 ground movement sensors (inclinometers), 5 rainfall sensors, seismic |
| Admin Hub uplink | Ethernet primary; Starlink satellite failover |
| Estimated coverage | Full village + 2 km coastal perimeter |
| Hardware cost (est.) | £15,000–20,000 at component cost |
11. Implementation Pathway
Phase 0 — SENTINEL PoC (Current)
Single-device proof of concept. Hardware assembly, firmware development, AI agent development and testing. Seismic and environmental monitoring baseline establishment in Pissouri. Validation of the three-mode operating model. Target completion: mid-2026.
Phase 1 — First Pilot Deployment
30-node deployment at first confirmed pilot site. Full three-tier architecture. Protocol validation under real-world conditions. Community engagement and maintenance training. Post-event communications drill. Documentation of deployment process for replication guide. Target: late 2026 / early 2027.
Phase 2 — Replication and Scaling
Publication of open deployment guide and hardware reference designs. Expansion to additional pilot sites. Engagement with national emergency management authorities for CAP integration. Contribution of operational data to the WMO EW4All monitoring framework. Target: 2027.
Phase 3 — Open Standard
SafeGround protocols submitted to relevant standardisation bodies (ETSI, WMO CAP standards group). Community of practice established for ongoing development and peer deployment support. Target: post-2027.
12. Call to Collaboration
SafeGround is an open project. It cannot be completed by a small team working alone, and it should not be. The scale of the problem — 3.5 billion people without adequate early warning coverage, and a 2027 deadline that is now visible — demands a collaborative response.
We are actively seeking:
- Pilot site partners — communities, municipalities, and NGOs in disaster-prone regions with limited existing early warning infrastructure
- Technical contributors — embedded systems engineers, LoRa protocol developers, AI/ML researchers, cybersecurity specialists, and web engineers
- Research partners — academic and applied researchers in disaster risk management, public health, community resilience, and communications systems
- Funders — grant funders, philanthropic organisations, and impact investors aligned with UN SDGs 11 and 13 and the EW4All mandate
- Government and civil defence partners — emergency management agencies and local authorities seeking last-mile coverage extensions for existing systems
All enquiries can be submitted via the partnership form at safegroundews.com/get-involved or the contact page.
13. References & Further Reading
UN and International Organisations
- World Meteorological Organization. (2024). Global Status of Multi-Hazard Early Warning Systems. WMO.
- World Meteorological Organization. (2023). Early Warnings for All: Theory of Change and Logic Model. WMO.
- United Nations Office for Disaster Risk Reduction. (2024). Early Warnings for All: Programmatic Framework for Country-Level Implementation. UNDRR.
- International Telecommunication Union. (2023). Digital Transformation and Early Warning Systems for Saving Lives. ITU.
- United Nations General Assembly. (2023). Resolution A/RES/78/210 — Strengthening Early Warning Systems.
LoRa Technology and Mesh Networking
- Adelantado, F. et al. (2017). Understanding the limits of LoRaWAN. IEEE Communications Magazine, 55(9), 34–40.
- Sciullo, L. et al. (2020). Design and performance evaluation of a LoRa-based emergency communication system (LOCATE). Computer Networks, 174, 107234.
- Baumgärtner, L. et al. (2018). LoRa meets DTN: An experimental evaluation for emergency communication systems. Proc. 15th ISCRAM Conference.
- LoRa Alliance. (2020). LoRaWAN Security White Paper. LoRa Alliance.
Disaster Communications and Post-Sandy Response
- FEMA. (2013). Hurricane Sandy FEMA After-Action Report. FEMA.
- Monmouth County Long-Term Recovery Group. (2013). Long-Term Recovery Planning Framework: Monmouth County, NJ.
- Blake, E.S. et al. (2013). Tropical Cyclone Report: Hurricane Sandy. National Hurricane Center, NOAA.
Pissouri and Cyprus Hazard Context
- Cyprus Geological Survey Department. (2023). Pissouri Landslide Monitoring Report. Ministry of Agriculture, Cyprus.
- Copernicus Emergency Management Service. (2021). Arakapas-Limassol Wildfire Assessment. EU CEMS.
- Cyprus Meteorological Service. (2024). Seismic Activity Bulletin: Eastern Mediterranean.
SafeGround Early Warning System · White Paper v1.0 · April 2026
Released under MIT Licence · Open Access
safegroundews.com
GitHub: github.com/FranKiernan/safeground-ews