Student Innovation-Disaster management includes ideas related to risk mitigation, Planning and management before, after or during a disaster.

Smart India Hackathon (SIH) Solution Dossier

Problem Statement ID: SIH26223
Category: Hardware
Theme: Disaster Management

1. Executive Snapshot

One-Paragraph Summary

Problem statement SIH26223, under the AICTE MIC-Student Innovation vertical, addresses the critical need for innovative hardware-driven solutions for disaster management spanning pre-disaster risk mitigation and planning, in-disaster real-time response, and post-disaster relief management [PS]. In India, severe natural hazards—such as floods, landslides, cyclones, and cloudbursts—frequently cause catastrophic loss of life and infrastructure due to the failure of conventional grid power and cellular communication networks during extreme events [KNOWN]. To bridge this vulnerability, we propose "ResiliNet-IoT": a solar-powered, dual-frequency (865–867 MHz LoRaWAN / ESP-NOW Mesh) hardware node network integrated with edge AI anomaly detection, offline-first GIS mapping, and C-DOT Common Alerting Protocol (CAP) compliance [INFERENCE]. The system provides autonomous early warning thresholds, offline peer-to-peer SOS emergency messaging when cellular towers collapse, and real-time situational awareness dashboards for first responders [INFERENCE]. Designed for a 4–6 student team, the hackathon MVP combines physical hardware sensor pods, a local gateway node, a mobile emergency mesh application, and simulated multi-hazard telemetry [ASSUMPTION].

Metadata Table

2. Problem Deconstruction

The official problem statement text is broad and open-ended [PS]. To build an actionable, high-impact hardware-software ecosystem, we deconstruct the statement into atomic requirements across the three phases of disaster management:

• Requirement A (Scope & Vertical): The solution must be a physical Hardware innovation under the Disaster Management domain [PS].

  • Interpretation: Software-only apps or web dashboards do not fulfill the primary category requirement. The submission must include custom microcontrollers, sensors, communication modules, power backup, or mechanical enclosures [INFERENCE].
  • Implementation Implication: The team must design, fabricate, and demonstrate functional micro-controller based hardware pods (e.g., ESP32/STM32 + LoRa + sensor array) alongside software dashboards [ASSUMPTION].
  • Confidence Tag: [PS]

• Requirement B (Pre-Disaster - Risk Mitigation & Planning): The solution must support risk mitigation and pre-disaster planning [PS].

  • Interpretation: Hardware must continuously monitor environmental indicators (e.g., water level, soil tilt/moisture, rain intensity, seismic vibrations) and trigger early warnings before structural or environmental breach [INFERENCE].
  • Implementation Implication: Integrate multi-sensor arrays (ultrasonic/radar distance, IMU accelerometer, rain gauge, barometric pressure) with threshold-based and ML-based anomaly prediction on edge microcontrollers [INFERENCE].
  • Confidence Tag: [INFERENCE]

• Requirement C (During-Disaster - Real-Time Response & Management): The solution must operate during an ongoing disaster [PS].

  • Interpretation: Primary communication channels (4G/5G, fiber backhaul, power grid) often collapse during severe disasters [KNOWN]. Hardware must maintain off-grid communication and local alarm capability without relying on active internet or power utilities [INFERENCE].
  • Implementation Implication: Embed long-range low-power RF communication (LoRa 865–867 MHz license-exempt band in India / ESP-NOW) into hardware nodes to form an autonomous, decentralized mesh network [RESEARCHED].
  • Confidence Tag: [INFERENCE]

• Requirement D (Post-Disaster - Relief & Assessment): The solution must assist in post-disaster recovery and management [PS].

  • Interpretation: Rescue workers and authorities need localization of trapped victims, damage heatmaps, and resource delivery tracking [INFERENCE].
  • Implementation Implication: Hardware nodes act as emergency location beacons; mobile apps query local LoRa mesh nodes to route offline SOS requests and GPS tags directly to rescue teams [INFERENCE].
  • Confidence Tag: [INFERENCE]

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

• Geography & Terrain: India’s high-risk regions range from hilly Himalayan terrains (landslide/cloudburst prone) to coastal belts (cyclone/storm surge prone) and river basins (flood prone) [KNOWN]. Hardware enclosures must resist high humidity, heavy rain, and extreme temperature variations [INFERENCE].
• Connectivity Interruption: During Category 3+ cyclones or severe floods, cellular base transceiver stations (BTS) suffer physical damage, power loss, or backhaul fiber cuts [KNOWN]. The hardware MUST NOT depend on continuous 4G/5G/WiFi cloud connections [INFERENCE].
• Power Supply: Grid power outages during natural calamities last anywhere from 12 hours to 10 days [KNOWN]. Hardware nodes must be self-sustaining using solar panels and low-self-discharge LiFePO4 batteries [INFERENCE].
• Regulatory & RF Spectrum: In India, wireless equipment in the 865–867 MHz band is license-exempt under Wireless Planning & Coordination (WPC) guidelines, provided Effective Isotropic Radiated Power (EIRP) stays within 1 Watt (30 dBm) [RESEARCHED].
• Digital Literacy & Language: Local village populations require simple visual (flashing red/yellow LEDs) and high-decibel acoustic (siren/buzzer) warnings alongside multi-lingual text/voice alerts (supporting local languages) [INFERENCE].
• Hardware Availability & Cost: Equipment must be buildable using readily available components in India (e.g., SX1276/SX1262 LoRa modules, ESP32 microcontrollers, standard industrial sensors) to ensure affordability for mass deployment by local bodies [ASSUMPTION].

6. Research Questions

1. How does the Indian C-DOT CAP (Common Alerting Protocol) engine ingest third-party early warning telemetry for national integration via SACHET? [RESEARCHED]
2. What is the achievable LoRa transmission range under non-line-of-sight (NLOS) conditions in dense forest/mountainous terrains without repeater nodes? [RESEARCHED]
3. What are the power consumption profiles of ESP32 in deep sleep vs. active LoRa transmission cycles, and what solar panel wattage guarantees 24/7 uptime? [INFERENCE]
4. What are the specific WPC (Wireless Planning & Coordination) power limits for sub-GHz RF hardware in India? [RESEARCHED]
5. How can false positive early warnings be minimized when relying on low-cost MEMS sensors at the edge? [INFERENCE]

7. Data Requirements & Sources

Data Categorization

• A. Explicitly Mentioned: None (broad PS) [PS].
• B. Required by Inference: Live sensor readings (water, vibration, tilt), node health/battery status, GPS coordinates, CAP XML alert payloads [INFERENCE].
• C. Must be Collected: Sensor calibration baseline values, hardware RSSI/SNR signal strength maps [INFERENCE].
• D. Synthetically Generated: High-volume flood scenario sensor streams for dashboard stress testing during demo [ASSUMPTION].
• E. Data Needing Validation: Exact API endpoints for official NDMA SACHET ingestion for non-government entities [NEEDS VALIDATION].

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: High-Cost Cellular / Satellite Fixed IoT Gateway Network

• Mechanism: Deploy high-spec sensor stations equipped with 4G/5G modems and satellite backup (IRNSS/NavIC or Iridium) directly uploading data to AWS/GCP cloud platforms [INFERENCE].
• Pros: High bandwidth, easy cloud integration, standard RESTful architecture [INFERENCE].
• Cons: Expensive hardware per node (>₹50,000); total failure during extended cellular outage if satellite module is omitted due to cost; high operational expenditure [INFERENCE].
• Hackathon Feasibility: Low (Requires expensive satellite hardware modems and active cellular SIM subscriptions) [INFERENCE].

Approach 2: Solar-Powered LoRaWAN / LoRa Mesh Sensor Array + Off-Grid WiFi SOS Gateway (Selected Core)

• Mechanism: Deploy distributed sub-GHz (865–867 MHz) LoRa sensor nodes running on solar + battery power. Nodes evaluate micro-environmental data locally (TinyML edge rule evaluation). If thresholds are crossed, nodes send multi-hop RF alerts across the mesh to a master Gateway node. The Gateway node broadcasts local sirens/flashing lights AND spins up a local WiFi SoftAP where nearby trapped citizens can log in via mobile browser (Captive Portal) to post distress requests and GPS locations without internet [INFERENCE].
• Pros: 100% off-grid capability, low component cost (~₹2,500–₹4,000 per node), license-free RF spectrum in India, multi-hop mesh resiliency, extremely low power draw [RESEARCHED].
• Cons: Low data bandwidth (restricted to short sensor readings and text payloads; no high-res video) [KNOWN].
• Hackathon Feasibility: Very High (Can be built and physically demonstrated using ESP32 + SX1276 modules) [INFERENCE].

Approach 3: Autonomous Swarm UAV Drone Reconnaissance Network

• Mechanism: Deploy custom autonomous quadcopter drones equipped with computer vision cameras and thermal imaging to search disaster zones and relay communication [INFERENCE].
• Pros: Excellent spatial coverage, airborne aerial mapping, thermal body detection [RESEARCHED].
• Cons: Flight time limited to 20–30 minutes per battery; highly vulnerable to heavy storm winds and severe rain; expensive flight controllers and airframes [KNOWN].
• Hackathon Feasibility: Medium-Low (Hardware assembly and indoors flight demo in hackathon venue is risky and limited) [INFERENCE].

10. Recommended Approach & Why

Recommended Architecture: Hybrid System (Approach 2 Core + Approach 3 Drone Relay Simulation)

We select Approach 2 as the foundational backbone, augmented with an optional tethered/deployable mobile relay capability [INFERENCE].

+-----------------------------------------------------------------------+
|                         RESILINET-IOT SYSTEM                          |
|                                                                       |
|  +-------------------+       865 MHz LoRa Mesh     +---------------+  |
|  | Multi-Sensor Pod  |---------------------------->| Master Gateway|  |
|  | (Ultrasonic, IMU, |                             | Node          |  |
|  |  Rain, Temp/Hum)  |<----------------------------| (ESP32 +      |  |
|  +-------------------+      2-Way RF Alert/Ack     |  SX1276)      |  |
|           |                                        +---------------+  |
|           | Local Acoustic                                 |          |
|           v Warning Alarm                                  | Local    |
|    (( High Siren ))                                        v WiFi AP  |
|                                                     +--------------+  |
|                                                     | Citizen SOS  |  |
|                                                     | Captive Portal|  |
|                                                     +--------------+  |
|                                                            |          |
|                                                4G/Ethernet | (When    |
|                                                or LoRa-Sat | available|
|                                                            v          |
|                                                     +--------------+  |
|                                                     | C-DOT CAP    |  |
|                                                     | Command Center| 
|                                                     +--------------+  |
+-----------------------------------------------------------------------+

Why Alternatives Were Rejected

1. Pure Cellular System (Approach 1): Rejected because natural calamities in India consistently destroy cellular towers and power infrastructure, rendering cellular-only devices useless during the exact hours emergency communication is needed most [KNOWN].
2. Pure Drone System (Approach 3): Rejected as a primary backbone because extreme weather (monsoon winds >50 km/h, torrential rain) grounds drones, and short battery life limits continuous 24/7 monitoring capability required for pre-disaster early warning [INFERENCE].

11. Technical Architecture

Layered Architecture Diagram

=================================================================================
                            RESILINET TECHNICAL ARCHITECTURE
=================================================================================

[LAYER 1: SENSING & PHYSICAL HARDWARE]
  +---------------------------------------------------------------------------+
  | - Water Level Sensor (Ultrasonic JSN-SR04T Waterproof)                    |
  | - Landslide/Seismic Sensor (MPU6050 6-Axis Accelerometer / Gyroscope)      |
  | - Rainfall & Weather (Tipping Bucket / Capacitive Rain Sensor, BME280)    |
  | - Power Management (LiFePO4 3.2V 6000mAh + TP4056/CN3791 Solar MPPT + 5V Solar)|
  +---------------------------------------------------------------------------+
                                      |
                                 (UART / I2C / ADC)
                                      v
[LAYER 2: EDGE EMBEDDED COMPUTING & LOCAL ALARM]
  +---------------------------------------------------------------------------+
  | Controller: ESP32 dual-core 240MHz microcontroller                        |
  | - Edge Logic: Threshold validation + Sensor fusion rules                   |
  | - Local Actuators: High-decibel piezo siren (110dB) + High-intensity LED  |
  +---------------------------------------------------------------------------+
                                      |
                           (SPI Interface to SX1276)
                                      v
[LAYER 3: OFF-GRID RF MESH COMMUNICATION LAYER]
  +---------------------------------------------------------------------------+
  | - Frequency Band: 865 - 867 MHz (India License-Exempt)                    |
  | - Protocol: LoRa Mesh (RadioLib / RadioHead multi-hop routing)            |
  | - Payload: Compact Binary Protocol Buffer / Custom Bit-Packed Struct      |
  +---------------------------------------------------------------------------+
                                      |
                             (Long Range RF Link up to 10km)
                                      v
[LAYER 4: MASTER GATEWAY & LOCAL SOS BRIDGE]
  +---------------------------------------------------------------------------+
  | Master Gateway (ESP32-S3 / Raspberry Pi Zero 2W)                          |
  | - SoftAP Captive Portal: Citizens connect to WiFi SSID "EMERGENCY_SOS"    |
  | - WebServer: Serves lightweight offline HTML/JS rescue distress form      |
  | - Buffer: SQLite / LittleFS local queue for offline messages              |
  +---------------------------------------------------------------------------+
                                      |
                    (Backhaul: GSM/4G, Ethernet, or USB Serial)
                                      v
[LAYER 5: CENTRAL COMMAND & DISASTER MANAGEMENT PLATFORM]
  +---------------------------------------------------------------------------+
  | Backend: Node.js / Python FastAPI application                             |
  | Database: PostgreSQL + PostGIS (Spatial GIS storage)                      |
  | AI Layer: Random Forest / Isolation Forest for multi-sensor anomaly scoring|
  | Integration Engine: C-DOT CAP XML v1.2 Generator                          |
  +---------------------------------------------------------------------------+
                                      |
                                      v
[LAYER 6: USER INTERFACES & DASHBOARDS]
  +---------------------------------------------------------------------------+
  | - DDMA Command Center Dashboard (React.js + Leaflet.js GIS map)          |
  | - First Responder Mobile PWA (Offline cached maps + SOS queue view)       |
  | - Citizen Emergency SOS Web App (Captive Portal UI)                       |
  ===========================================================================

Data Flow Narrative

1. Sensing & Edge Check: Every 10 seconds, the ESP32 microcontroller wakes from light sleep, powers on sensors, and reads environmental parameters (water level distance, tilt acceleration, rainfall accumulation) [INFERENCE].
2. Edge Evaluation: The microcontroller checks values against baseline safety windows. If an anomalous surge is detected (e.g., water level rising > 5cm/min or tilt angle changing > 15 degrees), the edge node instantly triggers its local piezo siren and optical strobe light [INFERENCE].
3. Mesh Transmission: The node serializes the sensor data into a compact 24-byte binary packet containing [Node_ID, Timestamp, Battery_Volts, Sensor_Flags, Water_Level, Tilt_Angle] and broadcasts it via its SX1276 LoRa transceiver at 865.5 MHz [INFERENCE].
4. Multi-Hop Routing: Intermediate LoRa pods receive the packet, check the hop count, and re-transmit if necessary to reach the Master Gateway node located up to several kilometers away [INFERENCE].
5. Offline SOS Ingestion: Concurrently, at the Gateway node, trapped citizens in the immediate area connect their mobile phones to the hardware node's broadcast WiFi network ("EMERGENCY_SOS"). The gateway automatically serves an offline captive portal allowing citizens to submit their name, number of people trapped, medical urgency, and auto-captured GPS coordinates. The gateway injects these distress packets directly into the LoRa mesh queue [INFERENCE].
6. Central System Upload & CAP Dispatch: Whenever internet connectivity (cellular/satellite/WAN) is restored at the Gateway, all buffered sensor telemetry and citizen SOS packets synchronize with the Central Command Cloud Platform. The platform updates the PostGIS map display and formats critical warnings into standardized C-DOT CAP XML alerts for broadcast to regional emergency response teams [RESEARCHED].

12. Technology Stack

13. AI/ML Justification

Proposed AI Component 1: Edge-Based Multi-Sensor Landslide & Flood Anomaly Detection

• 1. Purpose: Detect multi-parameter anomaly patterns (e.g., simultaneous soil moisture saturation + micro-vibration + heavy rain) that precede landslides or flash floods, reducing false alarms from isolated sensor spikes [INFERENCE].
• 2. Model Type: Lightweight Decision Tree / Random Forest Quantized C-Code (generated via Edge Impulse or MicroTVM) executing directly on ESP32 microcontrollers [INFERENCE].
• 3. Input: Rolling 1-minute window of 4 sensor features: [soil_moisture_%, vibration_rms_g, tilt_angle_deg, rainfall_rate_mm_hr] [INFERENCE].
• 4. Output: Risk Score (0–100%) and Alert Class (NORMAL, WATCH, WARNING, CRITICAL) [INFERENCE].
• 5. Data Required: Synthetic and historical sensor log datasets representing steady state vs. slope failure / rapid inundation [ASSUMPTION].
• 6. Why AI is Preferable: Simple fixed threshold rules fail when a single sensor degrades or experiences noise. Machine learning evaluates feature interactions simultaneously [INFERENCE].
• 7. Evaluation Metric: Precision (>95%) and Recall (>98%) on validated hazard datasets; zero false negatives on critical slope shifts [INFERENCE].
• 8. Failure Mode: If edge AI model execution fails, system automatically falls back to deterministic hard-coded safety threshold checks [INFERENCE].
• 9. Human Oversight: Automated alerts sent to DDMA control room require human operator confirmation before issuing mass evacuation sirens [INFERENCE].

Explicit Exclusion of AI

• Deterministic Safety Triggers MUST NOT Use AI: Absolute flash flood water level thresholds (e.g., "Water height > 3.0 meters above bridge deck") MUST trigger immediate local sirens using hard-coded IF-ELSE rules. Relying on an AI model for critical threshold triggers introduces unacceptable non-deterministic failure risks [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Database Schema (PostGIS Spatial Model)

-- Nodes Table
CREATE TABLE sensor_nodes (
    node_id VARCHAR(32) PRIMARY KEY,
    hardware_version VARCHAR(16),
    location GEOMETRY(Point, 4326),
    installation_date TIMESTAMP,
    battery_level_volts NUMERIC(3, 2),
    status VARCHAR(16) -- 'ACTIVE', 'OFFLINE', 'MAINTENANCE'
);

-- Telemetry Logs
CREATE TABLE node_telemetry (
    telemetry_id BIGSERIAL PRIMARY KEY,
    node_id VARCHAR(32) REFERENCES sensor_nodes(node_id),
    recorded_at TIMESTAMP NOT NULL,
    water_level_cm NUMERIC(6, 2),
    tilt_x NUMERIC(5, 2),
    tilt_y NUMERIC(5, 2),
    rainfall_mm NUMERIC(5, 2),
    battery_v NUMERIC(3, 2),
    raw_rssi INT,
    raw_snr NUMERIC(4, 1)
);

-- Offline Citizen SOS Messages
CREATE TABLE citizen_sos (
    sos_id VARCHAR(64) PRIMARY KEY,
    gateway_id VARCHAR(32),
    citizen_name VARCHAR(100),
    contact_phone VARCHAR(15),
    trapped_count INT,
    medical_emergency BOOLEAN,
    user_location GEOMETRY(Point, 4326),
    message_text TEXT,
    created_at TIMESTAMP,
    synced_to_cloud BOOLEAN DEFAULT FALSE
);

Offline Synchronization Strategy

1. Store-and-Forward Queue: When internet/cellular backhaul is down at the Master Gateway, incoming mesh messages and citizen SOS records are written directly to local non-volatile LittleFS flash storage or SQLite on the Gateway node [INFERENCE].
2. Backhaul Polling & Ping: A background daemon on the Gateway pings cloud health endpoints every 30 seconds [INFERENCE].
3. Chunked Payload Sync: Upon establishing a valid HTTP/MQTT connection, the Gateway transmits buffered JSON payloads in compressed batches of 50 records [INFERENCE].
4. Conflict Handling: SOS distress records use UUID primary keys generated at the edge timestamp level. Cloud ingestion uses ON CONFLICT DO NOTHING to prevent duplicate record creation during erratic network retries [INFERENCE].
5. Bandwidth Optimization: Sensor values are packed into binary bitfields (e.g., 2 bytes for water level, 1 byte for temperature) rather than bulky JSON strings during LoRa RF transmission [INFERENCE].

15. Security, Privacy & Governance

• Personal Data Protection: Citizen SOS submissions contain sensitive Personally Identifiable Information (PII) including phone numbers and precise location coordinates [INFERENCE]. PII is stored locally in encrypted SQLite databases (AES-128) and transmitted over HTTPS/TLS 1.3 to central cloud servers [INFERENCE].
• RF Payload Encryption: LoRa mesh packets carry a 128-bit AES pre-shared key (PSK) embedded in node firmware to prevent unauthorized signal injection, spoofing, or rogue panic broadcasts [INFERENCE].
• Regulatory & RF Compliance: Operating on 865–867 MHz in India strictly complies with the WPC gazette notification for low-power wireless equipment [RESEARCHED]. Transmitters are limited to max 30 dBm EIRP with duty cycles under 1% for standard telemetry [RESEARCHED].
• Device Authentication: Gateway and sensor nodes authenticate with backend servers using hardware-unique cryptographic tokens (X.509 certificates or HMAC-SHA256 signatures) [INFERENCE].
• Governance & Disaster Management Integration: System outputs are designed as decision support tools for official District Disaster Management Authorities (DDMA). Autonomous sirens are limited to localized warning zones; wide-area public alerts must be vetted by authorized emergency managers [INFERENCE].

16. MVP Scope (Hackathon Build)

In Scope (Must Build for Demo)

• Hardware Pod 1 (Sensor Node): ESP32 + SX1276 LoRa + Waterproof Ultrasonic Sensor + MPU6050 Accelerometer + Piezo Siren + status LEDs powered by rechargeable battery [ASSUMPTION].
• Hardware Pod 2 (Relay Node / Sensor Node 2): ESP32 + SX1276 LoRa demonstrating multi-hop message repeating across the room [ASSUMPTION].
• Hardware Pod 3 (Master Gateway Node): ESP32-S3 + LoRa transceiver + active WiFi SoftAP hosting offline SOS Web Application Captive Portal [ASSUMPTION].
• Citizen SOS Mobile Web App: Lightweight web app accessible via smartphone WiFi connection to Gateway node, allowing distress submission and GPS capture without cellular internet [ASSUMPTION].
• Command Center Web Portal: React/Leaflet dashboard displaying real-time map with sensor node markers, telemetry graphs, live alert notifications, and incoming citizen SOS locations [ASSUMPTION].
• C-DOT CAP Alert Generator: Automated backend function generating valid ITU-T X.1303 CAP XML alert files upon hazard trigger [ASSUMPTION].

Described Only / Out of Scope (Production Only)

• Mass industrial IP67 injection-molded outdoor enclosures [INFERENCE].
• Commercial satellite modems (e.g., Skylo/Iridium) integrated into gateway nodes [INFERENCE].
• Direct API integration with live production servers of NDMA SACHET / C-DOT (simulated locally via mock REST endpoints) [INFERENCE].
• Custom silicon PCB layout mass manufacturing (hand-soldered perfboard / custom 2-layer prototype PCB used for hackathon) [ASSUMPTION].

17. Live Demo Simulation Plan

To present a compelling, failure-proof live demonstration before SIH judges without relying on external weather or active natural disasters:

1. Water Inundation Simulation:

   • Setup: Place the waterproof ultrasonic sensor above a water container [ASSUMPTION].
   • Action: Slowly pour water into the container.
   • Live Result: Observe the distance reading decrease on the local OLED screen, trigger the local hardware pod siren, send a LoRa mesh packet to Node 2, and update the GIS dashboard in real-time [ASSUMPTION].

2. Landslide / Slope Instability Simulation:

   • Setup: Mount Hardware Node 2 on a tiltable physical wooden slope model [ASSUMPTION].
   • Action: Tilt the board beyond 20 degrees rapidly.
   • Live Result: MPU6050 registers accelerometer surge; red warning LED flashes; "LANDSLIDE WARNING" flag populates on the central GIS map [ASSUMPTION].

3. Complete Cellular Network Failure & Citizen SOS Simulation:

   • Setup: Turn off all mobile data and WiFi internet on judge/team smartphones [ASSUMPTION].
   • Action: Connect phone to ESP32 Gateway SSID ("EMERGENCY_SOS_NET"). Open browser.
   • Live Result: Captive portal automatically pops up. Submit distress form ("2 people trapped, medical assistance required"). Form submits successfully over local WiFi-to-LoRa link, showing up instantly on the offline local gateway display and command dashboard [ASSUMPTION].

4. CAP XML Alert Export:

   • Action: Click "Export C-DOT CAP Alert" on dashboard.
   • Live Result: Displays fully formatted, valid XML payload adhering to national disaster warning standards [ASSUMPTION].

18. Implementation Roadmap

Target Deadline: 30 September 2026 [PS]

================================================================================
                       IMPLEMENTATION ROADMAP TO SIH 2026
================================================================================

PHASE 1: Hardware Component Procurement & Embedded Firmware (Weeks 1 - 3)
  - Procure ESP32, SX1276 LoRa modules, JSN-SR04T, MPU6050, solar panels, LiFePO4 batteries.
  - Develop SPI LoRa driver and RadioLib point-to-point communication scripts.
  - Implement low-power deep sleep cycles and battery ADC monitoring routines.

PHASE 2: Mesh Protocol & Edge Logic Integration (Weeks 4 - 6)
  - Implement multi-hop LoRa mesh routing protocol (packet deduplication, hop count).
  - Code edge threshold checks and TinyML anomaly detection model using Edge Impulse.
  - Wire physical actuators (piezo sirens, strobe LEDs, OLED displays).

PHASE 3: Offline Gateway & Captive Portal Development (Weeks 7 - 9)
  - Program ESP32-S3 Master Gateway SoftAP and DNS redirection for captive portal.
  - Develop lightweight offline HTML/JS SOS submission interface.
  - Implement SQLite local storage buffer on Gateway.

PHASE 4: Central Command Web Portal & GIS Engine (Weeks 10 - 12)
  - Build Node.js/FastAPI backend with PostgreSQL + PostGIS database.
  - Build React.js + Leaflet.js dashboard displaying node status and hazard overlays.
  - Implement C-DOT CAP v1.2 XML generation engine.

PHASE 5: Enclosure Assembly, Stress Testing & Demo Optimization (Weeks 13 - 14)
  - 3D print protective weatherproof enclosures for hardware pods.
  - Perform range testing (LOS and NLOS indoor/outdoor trials).
  - Dry-run live simulation presentation ahead of final SIH evaluation on 30 Sept 2026.
================================================================================

19. Testing & Validation Plan

• Functional Testing:
  • Verify sensor data accuracy (ultrasonic water distance ±0.5 cm, tilt angle ±1°).
  • Verify 100% packet reception across 3-hop LoRa mesh network at 500m distance [ASSUMPTION].
• Performance & Range Testing:
  • Measure LoRa RF link range in urban environment (target: >1.5 km NLOS) and open field (target: >5 km LOS) [INFERENCE].
  • Power consumption profiling using USB power monitor: Deep sleep current < 20 µA; Active RF Tx < 120 mA [INFERENCE].
• False Positive / False Negative Validation:
  • Expose sensor nodes to artificial vibrations (e.g., passing footsteps) to verify edge filtering prevents false landslide alarms [INFERENCE].
  • Simulate sensor disconnects to ensure system reports SENSOR_FAULT rather than zero-reading flood false alarms [INFERENCE].
• Offline & Synchronization Testing:
  • Disconnect Gateway internet connection for 2 hours; generate 100 citizen SOS requests; reconnect internet and verify 100% sync integrity without duplicate records [ASSUMPTION].
• Usability Testing:
  • Test Citizen SOS Captive Portal on iOS and Android devices to guarantee seamless layout rendering without internet connection [ASSUMPTION].

20. Risk Register

21. Cost & Scalability

Hackathon Prototype Cost (3 Hardware Pods + Gateway)

• ESP32 Microcontrollers (3 units @ ₹350) = ₹1,050
• SX1276 LoRa Modules 865 MHz (3 units @ ₹450) = ₹1,350
• Waterproof Ultrasonic Sensors JSN-SR04T (2 units @ ₹350) = ₹700
• MPU6050 Accelerometers & BME280 Sensors = ₹500
• LiFePO4 Batteries & Solar Charge Controllers = ₹1,200
• Piezo Sirens, LEDs, OLED Displays, Switches = ₹400
• Custom 3D Printed Enclosures & Cables = ₹800
• Total Hackathon Prototype Cost: ~₹6,000 INR [ASSUMPTION]

Production System Cost (Per Village Deployment Unit)

• Industrial Weatherproof Sensor Pod (IP67, Solar, High-gain Antenna, Sensor Array) = ₹4,500 – ₹7,000 per node [INFERENCE].
• Master Gateway Station (Dual LoRa + 4G/Satellite + Solar Array + High Siren) = ₹12,000 – ₹18,000 per station [INFERENCE].
• Scalability Comparison: Traditional government hydrological stations cost >₹5,000,000; ResiliNet offers a 90% cost reduction, enabling dense deployment across rural Gram Panchayats [INFERENCE].

22. Differentiation

23. Future Scope

1. Drone-Assisted Mobile Mesh Gateways: Equipping small quadcopters with LoRa relay modules to fly over impassable flood zones and dynamically harvest SOS queues from isolated ground pods [INFERENCE].
2. Direct Satellite NTN Interfacing: Integrating 3GPP Release 17 Narrowband Non-Terrestrial Network (NB-NTN) satellite connectivity into Gateway nodes for direct space-to-ground backhaul in remote Himalayan or oceanic zones [RESEARCHED].
3. Acoustic Victim Localization: Adding MEMS microphone arrays to hardware pods to process acoustic distress signals (whistles, calls for help) using edge audio classification models [INFERENCE].

24. Assumptions & Open Items Log

Consolidated Assumptions

• [ASSUMPTION] The hackathon venue allows demonstration of sub-GHz 865 MHz RF equipment and local WiFi SoftAP creation.
• [ASSUMPTION] Prototype component procurement can be completed via Indian electronic vendors within 1–2 weeks.
• [ASSUMPTION] Synthetic sensor datasets accurately mimic the slope failure characteristics of Himalayan soils and river inundation rates.
• [ASSUMPTION] A 4–6 student team can allocate roles into 2 Embedded Hardware/Firmware Engineers, 1 Full-Stack GIS Developer, 1 Mobile/UX Developer, and 1 AI/Domain Researcher.

Consolidated Items Needing Validation

• [NEEDS VALIDATION] Official C-DOT / NDMA API access policies for direct third-party CAP alert ingestion into live SACHET servers.
• [NEEDS VALIDATION] Specific WPC certification requirements for mass commercial production of custom ESP32 + SX1276 PCB boards in India.

Final Recommendation

The team should proceed with building ResiliNet-IoT, focusing on a hybrid hardware architecture combining solar-powered LoRa mesh sensor pods, an off-grid WiFi SOS Captive Portal Gateway, and a PostGIS command center dashboard [INFERENCE].

Recommended Stack

• Hardware: ESP32 / ESP32-S3, Semtech SX1276 LoRa (865–867 MHz), JSN-SR04T Ultrasonic, MPU6050 IMU, Solar + LiFePO4.
• Firmware: C++ / Arduino Framework / RadioLib / Edge Impulse TinyML.
• Backend & GIS: Python FastAPI, PostgreSQL + PostGIS, Node.js.
• Frontend: React.js, Leaflet.js, Offline PWA.

Biggest Dependency

Availability and reliability of 865–867 MHz LoRa transceivers (SX1276 / SX1262) and waterproof transducers for physical hardware fabrication [INFERENCE].

Biggest Risk

RF signal blockage or packet loss in dense indoor demonstration environments during live judging [INFERENCE].

Biggest Technical Challenge

Implementing robust, multi-hop LoRa mesh packet routing with low latency while maintaining sub-10mA power consumption on battery nodes [INFERENCE].

First 5 Actions

1. Purchase Core Hardware: Order 3x ESP32 development boards, 3x SX1276 LoRa modules, 2x JSN-SR04T sensors, and 2x MPU6050 IMUs from local vendors [ASSUMPTION].
2. Establish Point-to-Point LoRa Link: Flash basic RadioLib ping-pong firmware to verify 865 MHz RF packet exchange between two nodes [INFERENCE].
3. Build Offline WiFi Captive Portal: Program ESP32-S3 SoftAP DNS redirection to serve a local offline HTML form without internet [INFERENCE].
4. Set Up PostGIS & Leaflet GIS Web App: Initialize local PostgreSQL spatial database and display real-time sensor node markers on an interactive Leaflet map [INFERENCE].
5. Conduct Range & Water Simulation Test: Perform physical water container testing to validate ultrasonic sensor calibration and alert triggering [INFERENCE].

Validation Before Coding

Verify that local LoRa transmission in the 865–867 MHz band operates cleanly without interference in the team's build location, and confirm that mobile phones (iOS & Android) smoothly auto-trigger the ESP32 WiFi captive portal page [INFERENCE].

Buildability Score /100

92 / 100
(Highly feasible for a dedicated 4–6 student team using low-cost, off-the-shelf microcontrollers, open-source mesh libraries, and standard web/GIS technology stacks) [INFERENCE].

Confidence

High (0.88)
(Grounded in verified WPC spectrum regulations, established C-DOT CAP standards, proven LoRaWAN capabilities, and actual SIH hardware category guidelines) [INFERENCE].

Research Sources

1. SACHET - National Disaster Alert Portal (NDMA & C-DOT)

   • URL: https://sachet.ndma.gov.in/ [RESEARCHED]
   • Source Type: Official Government Portal
   • Claim Supported: C-DOT CAP Integrated Alert System operates across India using Common Alerting Protocol for geotargeted mobile alerts [RESEARCHED].
   • Reliability: Official Government Source (10/10)

2. PIB Release: Launch of Mobile-Based Disaster Communication Systems

   • URL: https://www.pib.gov.in/PressReleasePage.aspx?PRID=2257102 [RESEARCHED]
   • Source Type: Official Press Information Bureau Release
   • Claim Supported: DoT and NDMA Cell Broadcast technology delivers real-time emergency alerts across 36 States/UTs in multiple Indian languages [RESEARCHED].
   • Reliability: Official Government Source (10/10)

3. CEEW Report: How Early Warning Systems in India Build Disaster Preparedness

   • URL: https://www.ceew.in/publications/how-can-india-strengthen-climate-disaster-preparedness-with-multi-hazard-effective-early-warning-systems [RESEARCHED]
   • Source Type: Policy & Research Report
   • Claim Supported: Highlights the necessity of IoT sensors, micro-level community alerts, and last-mile information dissemination in India [RESEARCHED].
   • Reliability: Reputable Research Institute (9/10)

4. National Institute of Disaster Management (NIDM): LoRa Technology in Disaster Management

   • URL: https://nidm.gov.in/PDF/TrgReports/2023/June/Report_23June2023cg.pdf [RESEARCHED]
   • Source Type: Government Academic/Training Report
   • Claim Supported: Confirms LoRa LPWAN technology as a cost-effective, low-power off-grid communication backbone when conventional cellular networks fail during disasters in India [RESEARCHED].
   • Reliability: Official Government Institution (10/10)

5. IJRASET: LoRa & IoT Based Automatic Disaster Monitoring and Alert System

   • URL: https://www.ijraset.com/research-paper/lora-and-iot-based-automatic-disaster-monitoring [RESEARCHED]
   • Source Type: Academic Peer-Reviewed Paper
   • Claim Supported: Validates dual-path communication (online cloud + offline LoRa/GSM) for multi-hazard monitoring nodes [RESEARCHED].
   • Reliability: Academic Publication (8/10)