ResQMesh is an emergency communication system that combines a mobile application with decentralized LoRa-based mesh-network nodes to support the transmission of distress information when conventional communication services are unavailable or unreliable. The system allows users to send distress alerts, GPS coordinates, text messages, and voice messages through nearby ResQMesh nodes. These nodes communicate with one another through LoRa and can relay emergency information across the mesh network until it reaches rescuers or disaster-response personnel. Once a rescue team is assigned, ResQMesh uses openrouteservice to show responders and civilians the road route between them.
How ResQMesh Works
Each ResQMesh node consists of an Orange Pi running the ResQMesh node software, a LoRa transceiver, a GPS module, local storage, and a Wi-Fi adapter configured as a local hotspot. The node hosts a local API that allows nearby civilian and rescuer mobile devices to communicate directly with the node over Wi-Fi without requiring an internet connection.
In the app’s Mesh Mode, a user connects their phone to a nearby node’s hotspot and signs in. The application can then send distress alerts, GPS coordinates, text messages, and voice messages to the connected node. Relevant information is stored locally and transmitted as compact packets through LoRa to other reachable ResQMesh nodes.
ResQMesh is designed to support three main groups involved in emergency communication and response: civilians, rescuers, and disaster-response administrators.Civilians use the app to send distress alerts and messages. Rescuers view active incidents, communicate with affected users, monitor their assignments, and see rescue routes when online routing is available. Administrators, including staff of the City Disaster Risk Reduction and Management Office (CDRRMO), use a monitoring interface to review alerts, assign responders, and track mesh nodes and incidents.
The Role of openrouteservice
openrouteservice calculates these rescue routes. When an administrator assigns a rescue team to an incident, the ResQMesh backend sends the team leader’s latest coordinates and the civilian’s distress coordinates to the openrouteservice driving-car Directions service.
The returned route information provides route geometry for displaying the emergency-response route on the map, estimated travel distance, and estimated travel duration. ResQMesh converts the returned duration into a user-friendly estimated travel time in minutes.
After a route is calculated, the resulting information is stored as a route snapshot associated with the rescue deployment. The stored route can then be made available to the rescuer’s Active Map in the mobile application, the civilian’s live rescue-route view, the administrator’s Mesh Node Map, and connected ResQMesh nodes through synchronization.
A previously calculated route can be reused while it remains sufficiently recent and while the responder or destination has not moved beyond the configured update threshold. This reduces unnecessary routing requests while keeping the displayed emergency route relevant.
On the administrator’s map, ResQMesh draws these routes on a MapTiler base map together with mesh nodes, distress locations, and responder positions.
Operating During Disrupted Connectivity
During an internet outage, distress alerts, messages, status changes, and rescue assignments keep moving through the mesh, because phones reach nodes over local Wi-Fi and nodes reach each other over LoRa. Nodes also keep the most recently synchronized openrouteservice route, so users can still view it offline. A new route requires a connection to openrouteservice and is calculated once internet access returns.
Current Status and Potential Impact
Information Technology students at Bukidnon State University are developing ResQMesh in Valencia City, Bukidnon, Philippines, as a capstone research project.
The project is focused on prototype development, integration, testing, and evaluation. The system is being tested under controlled simulated disaster conditions to evaluate its functionality, durability, reliability, communication performance, usability, and accessibility.
The potential impact of the system lies in providing an additional communication option during emergencies rather than replacing existing cellular, radio, or disaster-response infrastructure. The system may also support improved situational awareness by bringing together distress locations, responder positions, mesh-node information, emergency messages, and openrouteservice routes within the same platform.
