2.1. Traditional emergency response systems

1. 1. Traditional systems relying on phone calls face limitations when individuals are incapacitated or unable to dial phone numbers to make calls.

2. 2. There is a possibility that the people around the victim are not helping because of fear or are just ignoring it, also known as the Bystander effect (Larsson et al., Reference Larsson, Mártensson and Alexanderson2002; Fischer et al., Reference Fischer, Krueger, Greitemeyer, Vogrincic, Kastenmuller, Frey, Heene, Wicher and Kainbacher2011).

3. 3. Some researchers propose traffic emergency response systems using data mining and the IoTs for quick and accurate control (Liu and Wang, Reference Liu and Wang2019).

2.2. GPS-based location systems

Several solutions use GPS technology to determine the location of an accident (Pham et al., Reference Pham, Drieberg and Nguyen2013; Abhiram et al., Reference Abhiram, Basha, Balakrishnan and Sowjanya2023). However, these systems have major drawbacks as direct lines of sight to satellites are frequently obstructed, leading to a weak or lost GPS fix. This is critically common in scenarios such as:

1. 1. Under tunnels and underpasses, there is complete signal loss, rendering GPS navigation useless until the vehicle exits;

2. 2. Overpasses and closely spaced high-rise buildings create a ‘roof’ that blocks some portion of the sky, limiting the number of satellites the receiver can ‘see’. Signals bounce off buildings, creating a longer path to the receiver and distorting the calculated position;

3. 3. Heavy tree canopies, especially when wet, can attenuate and scatter the relatively weak GPS signals;

4. 4. Inside indoor parking garages, GPS signals cannot penetrate the multiple layers of concrete and steel, making location tracking impossible;

5. 5. Underground or semi-underground roadways, similar to tunnels, completely isolate the vehicle from satellite signals.

2.3. Mobile health (mHealth) applications

Mobile health applications provide features such as storing medical information and sharing location data (Philip et al., Reference Philip, Abdelrazek, Barnett, Bonti and Grundy2023). These solutions often depend on user input, which can be difficult in emergencies, especially when individuals cannot interact with their devices.

2.4. Hospital navigation systems

Some systems lack real-time accident data, leading to delays in emergency response. This can result in misdirection to hospitals that are not equipped for specific medical needs. Ambulances may struggle to quickly locate accident sites. Not knowing details about the victims, such as age, blood type or allergies, makes effective emergency response more difficult. Survey findings show how important communication is during emergencies. Clear communication of accident site details and victim needs is essential. The survey results stress the crucial nature of communication in emergencies. We cannot overlook the need for efficient communication of accident site details and victim requirements (Rachel, Reference O’Hara, Johnson, Hirst, Weyman, Shaw, Mortimer, Newman, Storey, Turner, Mason, Quinn, Shewan and Siriwardena2014).

3.1. Automated identification and medical history retrieval

By using the esp8266 hardware and connecting to smart phone hotspots, the device can automatically identify individuals inside the vehicle and retrieve their medical history stored on a dedicated website (Figure 1). This eliminates the need for manual input during the critical moments following an accident. Before purchasing a vehicle, all family members need to register themselves with the device by sharing their mobile SSID, password and medical records unique ID. To obtain a unique ID, one should register on a common website like an Electronic Health Record (EHR) (Luthfi et al., Reference Luthfi, Karna and Mayasari2019; Philip et al., Reference Philip, Abdelrazek, Barnett, Bonti and Grundy2023). Later, this device can be modified by adding a camera to recognise the family member, which also increases the device’s cost.

Figure 1.

Identification of members sitting inside the vehicle using esp8266.

3.2. GPS free location determination

The use of a Geo-location API offers a GPS-free method for pinpointing the vehicle’s location. This addresses the limitations of traditional GPS systems, ensuring accurate location data even in challenging environments. According to a previous study (Pahlavan et al., Reference Pahlavan, Li and Makela2002), Geo-location is based on a positioning algorithm that estimates a mobile terminal’s (MT) location coordinates by analysing metrics reported by location sensing devices.

The GPS-free approach aims to address the limitations of consumer-grade GPS in city areas. Although GPS works, it struggles in ‘urban canyons’. These areas have signal reflections and obstructions, which result in a longer Time To First Fix (TTFF) and location inaccuracies that can exceed 20 m. For emergency response, this delay and imprecision are critical drawbacks. A dedicated GPS module and its antenna represent a single point of failure. They are vulnerable to physical damage (for example, antenna detachment or crushing), electromagnetic interference from damaged vehicle electronics or require a slow cold start if vehicle power is lost. Our system strategically bypasses these issues, as this device uses the dense urban infrastructure of Wi-Fi access points and cell towers, which are not susceptible to satellite line-of-sight problems. This results in a faster, more reliable and often more accurate location fix precisely in the dense urban settings where the majority of vehicular accidents occur, making it a more affordable choice than a conventional GPS module for this application.

3.3. Realtime hospital information retrieval

Realtime retrieval of the names, directions and contact details of the three closest hospitals is made possible by the integration of two Excel sheets, one for hospital details and the other for accident data storage. The device easily connects with the Google Places API to fetch nearby hospitals from current coordinates, improving emergency services responsiveness and giving hospitals access to needed information.

3.4. Automated communication

The ability of the device to start HTTPs requests, along with the communication facilities of the sep8226, simplifies the communication process. The automatic generation of email alerts to the hospitals as well as the family members ensures availability of relevant information, including the accident victim’s medical history, thus making the job of the first responders and doctors relatively easier.

It is built upon the esp8266 hardware, and employing an integrated approach to location determination and communication represents an advancement in emergency response systems. This paper will further detail the design, implementation and evaluation of the device.

4.1. Hardware components and connectivity

• • Esp8266 integration. The heart of our device lies in the esp8266, a versatile and cost-effective Wi-Fi module. This hardware component serves as the central hub for data processing and communication. It connects to smart phones by intelligently detecting and linking to their hotspots, allowing interaction without the need for user intervention by using the family’s smart phone SSID and password.

The complete pseudo code to demonstrate the esp8266 integration to identify the family member and medical history retrieval from their unique identifier is shown in Algorithm I.

Algorithm I.

Member identification and medical history retrieval

Algorithm I Long description

The pseudocode begins with input variables for family members’ smart phone Wi-Fi credentials and registered medical history unique IDs. It then defines the output as identified members and their health details. The code includes a loop that iterates through each family member, attempting to connect to their Wi-Fi. If successful, it sets the member’s status to 1 and retrieves their information. If not, it sets the status to 0. The loop ends, and the code returns the identified number of members present and their health details.

4.2. Geo-location method using nearby cell towers or apps

1. 1. Location determination. To pinpoint the vehicle’s location without relying on a conventional GPS module like neo-6 m (Luthfi et al., Reference Luthfi, Karna and Mayasari2019), our device employs a Geo-location method based on nearby cell towers or Access Points (APs). By using an API designed for this purpose, the device communicates with the surrounding cellular infrastructure and uses the Google Geo-location API to fetch the current location, as shown in Algorithm II. This approach ensures reliable location data even in areas where GPS signals may be obstructed.

2. 2. It is important to distinguish the ‘GPS-free’ nature of the device’s hardware from its use of cloud-based navigation services. The device itself lacks a GPS receiver. Instead, it transmits identifiers of nearby Wi-Fi access points and cell towers to the Google Geolocation API, which performs the triangulation on its servers and returns the coordinates. These coordinates are then used by the Google Maps and Places APIs, which are digital map and routing services, not GPS hardware, to generate road level directions to the nearest hospitals. This approach makes use of cloud infrastructure for complex geospatial computation that would be infeasible on the low-cost ESP8266 module or Tensilica L106 core microchip.

Algorithm II.

Current location detection using Geo-location API

Algorithm II Long description

An algorithm for determining location using cell towers and an API. The algorithm begins by setting the system time using NTP for synchronization. It then iterates up to three times to check if the internet is connected. If connected, it uses the Google Geo-location API to get the current location coordinates and calculates the accuracy in meters. The algorithm returns the current location map link and accuracy.

4.3. Excel sheet’s structure and purpose

1. 1. Hospital details sheet as a database (S1). One spreadsheet is dedicated to storing hospital details, including names and contact information, like emails and phone numbers, which cannot be accessed publicly by anyone. This structured database serves as a quick reference for the device during an emergency, ensuring that the three nearest hospitals can be contacted in an emergency, as shown in Figure 3.

2. 2. Accident data sheet (S2). Another Excel sheet is designed to capture and store accident information, such as date, time, location map and directions to the three nearest hospitals, as shown in Figure 4. This sheet acts as a dynamic repository that facilitates real-time communication with emergency responders, medical facilities, family members and victims.

The complete pseudo code to demonstrate the spreadsheet communication between Hospital details sheet S1 and Accident data sheet S2 is shown in Algorithm III.

Figure 3.

Hospital details sheet: storing hospital contact details.

Figure 4.

Accident data sheet: storing live accident location and directions to nearby hospitals with their contact details obtained from hospital details sheet.

Algorithm III.

Spreadsheet communication with each other to fetch and store contact details

Algorithm III Long description

The pseudocode begins with input parameters for spreadsheet IDs and current location values. The main function, get_nearby_hospitals_emails, logs parameters, checks for missing values, and sets results accordingly. It writes timestamps, locations, and fetches nearby hospitals using the Google Geo-Places API. For each hospital, it writes direction links and contact details. The function find_Nearby_Hospitals uses an API to find hospitals within a radius, sorts them by ratings, and returns a list. Errors are handled with appropriate messages.

4.4. HTTPS requests for information retrieval and storage

1. 1. Hospital information retrieval. When an accident occurs, the device initiates an HTTPS request to the Excel sheet storing accident data. This sheet then triggers an HTTPS request to the Google places API, fetching the names, directions and contact details of the three nearest hospitals based on the accident location. Here, accident location and directions to the three nearest hospitals are shown in Figure 5. The obtained information is saved in the Excel sheet for reference.

2. 2. Accident data storage. Subsequently, the esp8266 sends an HTTPS request to the same Excel sheet storing accident data, facilitating the storage of updated accident details, including date, time and location. The availability of this information is very useful for coordinating emergency response as well as proper medical treatment.

3. 3. The calculation of the distance between the accident coordinates and the hospital coordinates uses the Haversine formula (Yunardi et al., Reference Yunardi, Magdalena and Febima2024). This formula finds the great circle distance between two points on a sphere based on their longitudes and latitudes.

Figure 5.

Showing accident location and directions to three nearest hospitals.

4.5. Automated email alert process

1. 1. When an accident occurs, the esp8266 sends an email alert to the nearby hospitals as well as the listed family members. This device uses the SMTP protocol to generate the email for safe and secure communication (Sureswaran et al., Reference Sureswaran, Bazar, Abouabdalla, Manasrah and El-Taj2009).

2. 2. Email content. The email includes important information such as the names and unique URLs of family members, the victim’s medical history, the link to the Excel sheet with accident details and the exact location of the incident. This comprehensive email ensures that both family members and medical facilities receive detailed information immediately without any acknowledgement. Algorithm IV represents the pseudo code for the approach presented above.

Algorithm IV.

Email Alert to all family members and 3 nearby hospitals

Algorithm IV Long description

The image contains annotated text detailing an email alert system. The input section lists parameters such as SMTP host name, port, author’s email, password, sender’s name, email subject, recipients, and message details. The output section provides a function called send_Mailto_Member with steps to send an email alert. Key elements include setting flags, checking counts, refreshing networks, and handling SMTP connections. The function includes error handling and ensures emails are sent to hospitals and family members. The text is structured with clear labels and steps for sending email alerts in case of emergencies.

Figure 4 shows that the accident time is 12:10:21 PM on 11/27/2023 and the email alert received time in Figure 6 is 12:10 PM, which signifies the response time of the device.

Figure 6.

Email alert received at 12:10 PM with all required members’ details and links.

5.1. Hardware implementation

Figure 9 shows the assembled prototype of the proposed device. Key components visible include the following.

1. 1. Manual Trigger Switch. Used in this prototype to simulate an accident event for testing and validation purposes.

2. 2. ESP8266 Microcontroller (ESP 12F Module). The core processing and communication unit of the system.

3. 3. Status LED. Provides visual feedback on the device’s operational state.

4. 4. C-type Charging and Protection Circuit (TP4056). Manages the charging and safety of the integrated 3.7 V Li-Ion battery, allowing for standalone operation.

Figure 7.

High-level flow chart of device working and contents of email alert.

Figure 8.

Detailed flow chart of device working.

Figure 9.

Prototype hardware images.

Note: In a production vehicle, the manual switch would be replaced by an automated trigger integrated with the vehicle’s sensors (for example, airbag control unit or an internal accelerometer) and the external charging port would be superseded by direct power integration from the vehicle’s electrical system. This prototype validates the core logic and communication chain.

As detailed in Table 6, the device is highly power efficient. Its quiescent current in sleep mode is minimal (∼70 µA), allowing for extended standby periods of over two years on a single charge. During an active accident response sequence, which we have measured to take approximately 90 s, the average current draw is 80 mA. This results in a very low energy consumption of only approximately 3.33 mAh per accident event.

Table 6.

Prototype electrical specifications and battery life estimation.

Table 6 Long description

The table has 10 rows and 3 columns. The columns are labeled Parameter, Specification/measurement, and Notes/calculation. The rows detail various specifications and measurements for a prototype device, including the microcontroller type, power supply, battery capacity, charging circuit, current draw in sleep and active modes, peak current during Wi-Fi transmission, single operation duration, energy per operation, estimated operations per full charge, and estimated standby time. Each row provides specific values and calculations related to the device’s power efficiency and battery life.

This high efficiency leads to high reliability. After a full charge, the device can theoretically carry out over 450 complete accident response cycles. This significant operational buffer is well beyond any realistic scenario. It ensures the device stays functional even if the vehicle’s main battery gets disconnected and the device has to rely only on its internal power for multiple triggering events or a long time between charges. Further, Table 7 illustrates the optimised hardware profile for vehicular integration real-world power management.

Table 7.

Optimised hardware profile for vehicular integration real world power management.

Table 7 Long description

A table with six rows and four columns comparing prototype specifications and optimized production versions for vehicular integration. The columns are labeled Parameter, Prototype specification, Optimised production version, and Benefit of optimisation. The parameters include Core component, Additional components, Form factor, Power source, Integration, Estimated BOM cost, Google cloud cost, and Key advantage. Each row provides specific details for each parameter, highlighting the benefits of optimization such as reduced size, cost, and improved integration.

For mass production and seamless vehicle integration, the hardware can be optimised both in size and cost. The prototype’s ESP8266 module can be replaced by the core ESP8266 SoC itself, soldered directly onto a custom designed PCB. This, along with miniature surface mount components and a smaller backup battery, allows the entire system to be shrunk to an estimated 2 × 1 cm footprint, which is a 75% size reduction. This optimisation dramatically reduces the Bill of Materials (BOM) cost. While the prototype costs approximately $8, the production version is estimated at just $2–4 in volume manufacturing, making it one of the most cost-effective accident response solutions proposed. This combination of minimal form factor and radical cost reduction is for widespread automotive adoption

Figure 7 shows the device working in steps by representing it in a flow chart, and Figures 9, 10, 11 and 12 show the result of each respective step shown on the serial monitor of Arduino IDE. In Figure 7 step 1, Figure 9 shows the names of identified members present inside the vehicle. In Figure 7 step 2, Figure 11 shows about the current location via Geo-location API cloud service and uploads all the details to the accident data sheet by communicating further with the spreadsheet, as demonstrated in Algorithm III. In Figure 7 step 3, Figure 13 shows that the email has been sent to all the family members and hospitals using the smtp protocol. The testing and simulation phases generated a dataset comprising different accident scenarios, each with unique parameters, such as location, time and medical history. This dataset will be instrumental in further refining the device’s algorithms, optimising its performance and validating it in a real-world condition. In Figure 12, the device shows its error recovery process, if it fails to fetch or upload details to a spreadsheet, then it will retry it, which improves its error response. The device barely takes 30 s to store the data in a spreadsheet and send an email to all the family members registered with the vehicle and the 3 nearest hospitals, which reduces the response time.

Figure 10.

Serial monitor showing member identification present in vehicle.

Figure 11.

Serial monitor showing the current location and uploading all the details to accident datasheet (S2).

Figure 12.

Serial monitor error handling of the device.

Figure 13.

Serial monitor sending email alert.

5.2. Field testing and performance validation

To evaluate the real world working of the proposed system, field testing was conducted across four major Indian cities of Jammu, Ahmedabad, Mumbai and Pune representing diverse geographical and urban environments. The device was subjected to different challenging scenarios to assess its performance under different conditions.

Test environments included the following.

1. 1. Urban Dense Areas. High-rise buildings and dense residential societies in Mumbai and Pune

2. 2. Mixed Terrains. Varied topography in Jammu including hilly regions.

3. 3. Network Challenged Zones. Underground parking facilities, multi-level basements and areas with poor cellular coverage.

4. 4. Complex Infrastructure. Locations under bridges, tunnels and densely populated market areas.

5. 5. Standard Conditions. Open areas with clear network connectivity for baseline performance measurement.

6. 6. Rainy Weather. Tested in cloudy weather under heavy rain that degrades the satellite visibility.

The system demonstrated consistent performance across all test locations, with the following average metrics.

1. 1. Person Detection Phase: maximum time is 7 s for each person in the family if no member detected and the minimum time to scan if all the persons are present is less than 4 s (each member via Wi-Fi hotspot scanning). If two persons available out of 4 registered members, then the time observed is 25.2 ± 3.6 s.

2. 2. Location Acquisition: 3.2 ± 1.4 s (using Google Geolocation API) with 3 Retries adding 2 extra seconds delay to reconnect to NTP.

3. 3. Accident Logging and Hospital Integration: 26.3 ± 9.3 s (combined spreadsheet logging and hospital contact and route retrieval).

4. 4. No Hospital found Scenario: 6 s for failed response + 3 Retries with +5 Km Radius up to 15 Km Radius. Total time 6 + 6 + 6 ± 3 for no hospital detected in all 3 retries.

5. 5. Communication Phase: 20.6 ± 11.2 s (SMTP email delivery to multiple recipients) with 3 retries with adding 2 extra seconds delay to reconnect to NTP. 97% of success achieved on email delivery. With 3 retries, each retry takes an additional 15 s.

Key Observations from Multi City Testing.

1. 1. In urban areas, where the density of traffic is high, it was observed that the GPS-free location performed better than the GPS method in all types of circumstances with faster location tracking and accuracy within 2–3 m, particularly when heavy rain conditions in the city.

2. 2. A decline in the performance of the system was observed in the areas where network connectivity was not consistent. The GPS-free location system performed satisfactorily under all conditions; however, the accuracy was limited to 15–20 m, which was acceptable.

3. 3. It was also observed that the time to acquire the exact location was lower in the case of urban areas (2.4–17.8 s), where the network signals and availability of network was better, as compared with suburban and rural settings, where the network signal availability was weak and spotty (11.2–40.5 s).

4. 4. It was observed that the GPS-free location system performed consistently, maintaining a success rate of approximately 96% when tested over 40+ test scenarios spanning four cities. The failure scenarios included complete network blackout situations (underground parking without any connectivity and under a train tunnel).

The results of the field tests performed over the four cities indicate clearly that the proposed system performs consistently and displays reliable emergency response capabilities over diverse scenarios in real-world conditions, with a response time better than 2 mins in connected environments and in challenging urban scenarios where traditional GPS-based systems often fail.

5.3. Limitations and challenges for real-world deployment

Even as the proposed system performs well and shows high performance in various test scenarios over diverse field environments, which are however controlled scenarios, there exist limitations and challenges which need to be considered before widespread real-world deployment can be considered, out of which the critical ones are mentioned below.

1. 1. The overall performance of the proposed system is dependent upon the availability of a stable internet connection with access to Google Cloud APIs (Geolocation, Places, Sheets, SMTP). In areas with no cellular coverage or during periods of network outage, the ability of the system to perform reliably is affected adversely.

2. 2. The prototype under test uses a manual trigger to indicate an accident scenario; however, in real-life situation, the prototype needs to be upgraded to connect to the vehicle’s internal network. For example, CAN bus integration can enable access to accident detection signals from accelerometers or airbag sensors etc. The real challenge of integration with the vehicles’ internal network lies in the diversity of this system for different automobile manufacturers.

3. 3. The current prototype uses HTTPS for security which is not sufficient to ensure the security of the data, even as it handles sensitive personal health information and location data. The proposed system will need to be upgraded to include end-to-end encryption of medical records while ensuring compliance with the relevant laws of the land including India’s Digital Personal Data Protection Act.

4. 4. The efficacy of the device depends upon the accuracy of the medical records of the persons as well as the database of the hospitals. In the case where this information is not updated on a regular basis, a reduction in the usefulness of the proposed system is likely.

5. 5. The identification of the persons travelling in the vehicle has been linked to their phones, i.e. connectivity of their smartphones over Wi-Fi/Bluetooth; however, it would be better if these could be linked to their biometrics as in the case of damage to the phone in a severe accident/not turning on the Wi-Fi/Bluetooth, or the phone being switched off, could lead to false negatives in the identification of occupants.

6. 6. When an accident occurs, the proposed system sends alerts to the hospital with all the requisite information; however, the system cannot ensure a prompt response from the hospital, unless the hospital has established the procedures for a quick and adequate response to the alerts.

An upgrade to the proposed system, while addressing the limitations mentioned above, will significantly improve the capabilities and efficacy of the system. Some of these limitations will require a technical response, while in some cases, a systemic response will be required, e.g. integration with insurance, hospitals, etc.