Inspiration

During natural disasters such as floods, earthquakes, landslides, cyclones, and building collapses, normal communication infrastructure such as mobile towers and internet connectivity may become unavailable or unreliable. In such situations, victims may not be able to contact rescue teams even when they urgently need help.

The main inspiration behind our project was to develop a low-cost and reliable emergency communication system that can work without depending on cellular networks at the disaster location.

Our idea was to use LoRa communication to create a network where an SOS message generated by a victim's device can travel through multiple relay nodes until it reaches a base station. The system also captures the victim's location using GPS, allowing rescue operators to identify where assistance is required.

We wanted to combine this hardware communication system with a web-based rescue management platform. Once an emergency message reaches the base station, it is transferred to the backend, stored in the database, and displayed to rescue operators through the web dashboard.

The main goal of our project is to provide an alternative communication method during emergencies when conventional communication networks fail.

What It Does

Our project, Low-Cost Emergency Communication Network for Disaster Zones Using LoRa Mesh, provides emergency communication and rescue management in areas where cellular connectivity may not be available.

The system consists of a victim node, relay nodes, a base station, backend services, a database, and a web dashboard.

The victim node is built using an ESP32, SX1278 LoRa module, NEO-6M GPS module, and an SOS button. When a person is in danger, they can press the SOS button. The ESP32 collects the emergency information, including the device ID, SOS ID, latitude, longitude, emergency message, and hop count. This information is converted into a packet and transmitted using LoRa.

If the victim is far away from the base station, the SOS packet can travel through multiple LoRa relay nodes. Each relay node receives the packet, checks whether it has already processed the packet, and forwards it further if it is a new packet.

The communication flow is:

Victim Node → Relay Node → Relay Node → Base Station

The GPS module provides the geographical location of the victim. The latitude and longitude are included in the SOS packet so that the rescue operator can identify the approximate location of the emergency.

The base station receives the LoRa packet and transfers the information to the computer through serial communication. The backend then processes the received information.

Our backend is developed using Java Spring Boot and follows a microservices architecture. Different services are responsible for authentication, users, workers, teams, rescue operations, relay information, and API gateway functionality.

MySQL is used as the database to store information such as users, workers, teams, SOS records, rescue assignments, relay information, locations, and rescue statuses.

The web application provides different interfaces for users, workers, rescue operators, and administrators. Rescue operators can view active SOS alerts, check victim information and location, assign rescue teams, and update the rescue status.

The complete system flow is:

Victim → LoRa Mesh → Base Station → Serial Communication → Spring Boot Backend → MySQL Database → Web Dashboard

How We Built It

We divided the project into hardware, communication, backend, database, and frontend components.

First, we developed the victim node using an ESP32, LoRa module, GPS module, and SOS button. The ESP32 reads the GPS coordinates and creates an emergency packet when the SOS button is pressed.

We then implemented LoRa communication between the devices. LoRa was selected because it provides long-range communication with relatively low power requirements and does not require a cellular network at the device level.

We designed an emergency packet containing important information such as Packet ID, Source ID, Latitude, Longitude, Message, and Hop Count. The Packet ID helps identify unique messages, while the Hop Count helps control how many relay nodes the packet can travel through.

Next, we developed the relay nodes. When a relay node receives a packet, it checks whether the packet has already been processed. If it is a new packet, the relay forwards it to the next available node. This allows the emergency message to travel through multiple nodes.

We then developed the base station using an ESP32 and LoRa module. The base station receives the emergency packet from the LoRa network and sends the information to the computer using serial communication.

For the backend, we used Java Spring Boot. The backend provides REST APIs for communication between the frontend and database. We separated the backend into multiple microservices such as API Gateway, Authentication Service, User Service, Worker Service, Team Service, Rescue Service, and Relay Service.

MySQL is used for storing application data. Spring Data JPA and Hibernate are used to communicate between the Spring Boot services and the MySQL database.

Finally, we developed the web dashboard and connected it with the backend APIs. The dashboard allows administrators to manage workers and teams, while rescue operators can monitor SOS alerts, assign rescue teams, update rescue status, and view rescue history.

Challenges We Ran Into

One of the biggest challenges was establishing reliable communication between multiple LoRa devices without depending on cellular networks.

We had to configure and test different LoRa communication parameters and make sure that the transmitter and receiver were configured correctly.

Another challenge was implementing multi-hop communication. When multiple relay nodes are used, the same packet can potentially be forwarded repeatedly. To prevent this, we implemented packet identification and duplicate checking.

Integrating the ESP32 with the LoRa and GPS modules was also challenging because the device had to handle GPS data, LoRa communication, SOS button input, and packet processing.

Serial communication between the base station and the backend was another important challenge. We had to understand how the base station sends the received LoRa data through the serial port and how the software can read and process that information.

On the software side, implementing a microservices architecture introduced additional complexity. Each service has its own configuration, port, database, APIs, and dependencies. We also had to manage communication between different services.

Database design was another challenge because the system contains multiple relationships between users, workers, teams, SOS records, and rescue assignments.

We also faced challenges while integrating the frontend with multiple backend APIs and making sure that changes in the backend were correctly reflected on the dashboard.

Managing the SOS lifecycle was particularly important. An SOS can move through different stages such as PENDING, ACCEPTED, and COMPLETED, and the system needs to maintain the correct status throughout the rescue process.

Accomplishments That We're Proud Of

One of our biggest accomplishments is that we developed an end-to-end emergency communication and rescue management system instead of creating only a hardware prototype.

The complete system connects the physical emergency device with the LoRa mesh network, base station, backend, database, and web dashboard.

We successfully designed a system where an SOS can be triggered from a physical device and the emergency information can travel through multiple LoRa relay nodes before reaching the base station.

We also integrated GPS so that the emergency packet can contain the location of the victim.

Another accomplishment is the implementation of a microservices-based backend using Spring Boot. The backend manages different parts of the application through separate services.

We also developed a rescue management workflow where rescue operators can view SOS alerts, assign teams, and update rescue statuses.

The web dashboard provides centralized monitoring of emergency situations, making it easier for rescue operators to manage multiple SOS requests.

We are also proud of using affordable and commonly available components such as ESP32 and LoRa modules to develop the prototype.

What We Learned

This project helped us understand how hardware and software can be combined to build a real-world system.

We learned how ESP32 devices communicate with LoRa modules and how emergency data can be transmitted over a wireless network.

We gained practical knowledge about LoRa communication, GPS integration, serial communication, packet structures, relay nodes, and multi-hop communication.

On the software side, we learned how to develop REST APIs using Java Spring Boot and how the different backend layers work together.

We learned about Controllers, Services, Repositories, Entities, DTOs, JPA, Hibernate, REST APIs, and microservices.

We also learned how to design relational databases using MySQL and how to maintain relationships between different entities.

Another important learning was debugging. During development, we faced problems related to hardware communication, LoRa configuration, ESP32 programming, serial communication, backend services, database connections, APIs, and frontend integration.

Solving these problems taught us how to identify the source of an issue systematically and test each part of the system separately.

We also learned the importance of teamwork, version control, documentation, API design, testing, and communication while developing a large project.

What's Next for Low-Cost Network for Disaster Zones

Our current project provides the foundation for a larger disaster communication and rescue management platform.

In the future, we plan to expand the LoRa mesh network by deploying more relay nodes to cover larger disaster-affected areas.

We can also implement more advanced routing algorithms that dynamically select suitable relay nodes based on factors such as signal strength, distance, battery level, and network availability.

Multiple base stations can be introduced so that if one base station becomes unavailable, another base station can continue receiving emergency messages.

The GPS functionality can also be improved to provide continuous location tracking instead of sending only the location captured when the SOS is triggered.

A dedicated mobile application for rescue teams can be developed so that rescue workers can receive emergency alerts and navigate toward the victim's location.

Artificial intelligence can also be integrated into the system to analyze emergency messages and help prioritize cases based on factors such as emergency type, severity, location, number of people affected, and waiting time.

The system can also be improved with offline-first functionality so that important rescue operations can continue even when internet connectivity to the central server is temporarily unavailable.

Solar-powered relay nodes can be developed for long-duration disaster operations. This would allow relay nodes to operate for extended periods without frequent manual charging.

Additional environmental sensors can also be integrated into the system to monitor parameters such as temperature, humidity, smoke, gas, and water levels.

Our long-term vision is to develop a low-cost, scalable, and reliable emergency communication network that can assist rescue teams in disaster-prone and remote areas where conventional communication infrastructure is unavailable or damaged.