Element I

Summary of background research and project validation.

Our background research in Element A indicated a staggering prevalence of intimate partner violence, with 1 in 3 women and 1 in 10 men experiencing physical or sexual violence in their lifetime. Furthermore, the digital age has introduced new emerging problems; 1 in 10 teens report the use of technology for stalking or surveillance. Traditional tools like LifeAlert—which are limited by a 1,000-foot console tether—or smartphone apps are insufficient. These tools are either too visible or reliant on devices frequently monitored by abusers. The validation for this project was further reinforced through a market research survey of over 50 respondents. The data revealed a significant demand for this technology, with 66.7% of participants stating they could see themselves or others using a discreet safety device in domestic abuse situations, and a staggering 91.1% identifying its utility for general safety, such as walking alone at night. From a health and legal perspective, the project seeks to mitigate the long-term psychological effects of abuse—where survivors are three times more likely to meet PTSD criteria—by bridging the gap between crisis onset and medical intervention. By providing a secure method for verifiable evidence collection and immediate signaling, Project Aegis empowers victims to exercise their right to communicate with authorities safely.

Core Design Requirements

Following an extensive prototyping phase, we have identified four critical design requirements that serve as the benchmarks for system success. These requirements were subjected to a formal peer review by a professional engineer, ensuring that the testing protocols provide objective, unbiased, and statistically significant data. The four facets of this texting phase are:

• 1. Achieving a high-reliability GPS fix within critical time constraints to ensure an emergency response

• 2. Validating cloud security rules and API key rotation to prevent unauthorized data access to our website's database

• 3. Ensuring near-instantaneous haptic, vibrational confirmation for the user while maintaining a discreet profile.

• 4. Confirming the end-to-end propagation of emergency alerts across the LTE-M cellular network.

Overview of Testing Procedures

To rigorously validate these requirements, we implemented a series of standardized tests. Each procedure was refined based on expert feedback to eliminate observer bias

• 1. We are testing the Time to First Fix (TTFF) and Horizontal Dilution of Precision (HDOP) when the GPS "cold-starts." This ensures the device transitions from a "Cold" state to a "Search and Lock" state within 90 seconds, providing coordinates accurate to within 5 meters.

• 2. Penetration & Database Security Testing: To ensure victim data remains impenetrable, we are safeguarding from abusers attempting to tamper with the database. This involves using revoked API keys and malformed data packets to confirm that the Firebase security rules successfully return 403 Forbidden errors, preventing abusers from tampering with or accessing shared contact information.

• 3. We are measuring the millisecond latency between a hardware interrupt and the Linear Resonant Actuator (LRA) reaching its resonant frequency. Additionally, we are measuring the noise of the vibration in decibels to confirm the device remains audible only to the wearer, fulfilling the design requirement for total discretion.

• 4. We are quantifying the propagation delay across the SIM7080G LTE-M link. We are monitoring the RSSI (Signal Strength) and timing the delta from the hardware trigger to the physical reception of an SMS on a target device, ensuring a clickable, accurate Google Maps URL is delivered in under 30 seconds.

 Domestic abuse victims often face significant barriers when seeking help. Even if they have some mobility,  71% of victims' report that abusers monitor their communication, restrict their movements, and/or manipulate them in a manner that prevents them from reaching out in an indiscreet manner. Current safety tools are either too visible, inflexible, or too dependent on established infrastructure or law enforcement, leaving victims without discreet, reliable, and comfortable ways to signal for help. 

Purpose: 

The primary objective of this testing phase is to quantify the operational readiness of the Adafruit GPS architecture by measuring the Time to First Fix (TTFF) and the resulting geospatial precision. In a life-safety context, 'near-accurate' data is insufficient; therefore, this test validates the system’s ability to achieve a 3D fix within a cold-start window of less than 90 seconds. By benchmarking the device against high-precision control coordinates, we establish a verifiable Horizontal Dilution of Precision (HDOP). Ensuring a consistent sub-5-meter margin of error is critical for emergency responders, as it transforms raw satellite telemetry into an actionable, high-fidelity rescue coordinate. 

Pass/Fail Criteria: 

• Valid GPS fix achieved in <90 seconds 

• Accuracy margin of error of <5 meters compared to a control coordinate. 

Materials: 

• WeMos D1 Mini ESP32

• Adafruit Ultimate GPS Breakout

• LiPo Battery

•  Computer

• Arduino Serial Monitor

Initial Conditions: 

• Outdoor environment with clear line-of-sight. 

• No previous satellite data is cached in the GPS

• GPS and serial monitor set on a table

Safety Hazards: 

• Lithium batteries can become volatile if left in direct sunlight

• Proximity to high-voltage lines can cause electromagnetic signals to interfere

• The computer itself that is registering serial data can interfere with the GPS's signal

Control:

• Test occurs in 15-minute intervals and in the early morning

• Test site is at least 50 feet away from power transformers

• The computer is set at least 2 feet away from the GPS

Procedure:

• Power on the device

• Start timer

• Monitor serial output once satellites are in view

• Record time to catch a signal

• Record GPS Precision

Our test of the operational readiness of the GPS Adafruit architecture proved to be an outstanding success. We achieved all of our design criteria to consider this test passed; the average amount of satellites in view across 10 "cold-starts" was 5.4 as opposed to the intended 4. The time to first satellite fix was well below what we considered to be usable in high-risk situations, from less than to 90 seconds to an average of 35.8 seconds to first satellite fix. Our GPS precision, too, was within a desirable range, with an average margin of error of 1.484 meters, passing our target benchmark of < 2 seconds by over half a second.

Purpose: 

Project Aegis employs a hardened cloud integration strategy utilizing RESTful API protocols to bridge the gap between physical hardware and the Google Firebase environment. This testing cycle serves as a formal Penetration and Validation Audit; it confirms that the database successfully ingests valid location packets while simultaneously enforcing Server-Side Security Rules. By challenging the system with unauthenticated 'Mock' injections and malformed data—such as invalid phone number strings—we verify that the database is encrypted and secure. Furthermore, this phase validates the efficacy of our Credential Rotation Protocol, ensuring that even if an API key were compromised, the underlying contact architecture remains impenetrable to potential abusers.

Pass/Fail Criteria: 

• Valid packet (contact information) appears in the database within 5 seconds of trigger; "Mock" packet from an unauthorized source receives a 403 Forbidden error.

Materials:

• ESP32 Serial Number

• Firebase Database Console

• Contact information

• projectaegisportal.com website configuration interface

Initial Conditions: 

• Database is in "Listen" mode while it is also set to require authorization. 

Safety Hazards:

• Hard-coding API keys in public repositories or unencrypted code poses a risk to user privacy

Control:

• Encode a secret API key that hackers do not have access to

Procedure:

• Open the Firebase Console, Postman API tester, GitHub repository, and projectaegisportal.com website

• Test if information is registered in the database in less than 5 seconds

• Test if the database will only accept approved devices

• Test if the database will only accept valid phone numbers

• Test if the API key in the GitHub repository can be used to access the database; if it can, then the database can be breached 

Test results for data privacy and connection across website and databases proved an outstanding success. Inaccurate information in any way provided the accurate error and denied input into the database. Additionally, any ways to access and view information on the database was encrypted, permission was denied, and any information on GitHub that was exposed led to an additional "sign-in" wall. Every single one of our criteria was met, and all backends to access our database were solved and prevented. 

Purpose: 

To minimize user uncertainty during high-stress encounters, the interface must provide instantaneous, non-visual confirmation of system status. This procedure evaluates the mechanical efficacy and interrupt latency of the DRV2605L Haptic Driver and the Linear Resonant Actuator (LRA). By physical button engagement, we measure the system's ability to provide tactile feedback within a 500ms window. This testing ensures that the haptic 'handshake' is both discreet—maintaining a low acoustic signature for user safety—and unmistakable in its tactile resonance, confirming that the SOS sequence has been successfully initiated without requiring the user to look at the device.

Pass/Fail Criteria: 

• The linear resonant actuator must achieve its resonant frequency within 500 milliseconds of pushing a button. The tactile output must be discernible via the human touch while maintaining a noise floor below 40dB to ensure discretion.

Materials:

• WeMos D1 Mini ESP32

• DRV2605L Haptic Motor Driver

• 10mm Linear Resonant Actuator

• Tactile Push Button

• Decibel Meter Sound Level

Initial Conditions: 

• Device is turned on

• Timer is on standby

• Device is on a table in a quiet room

Safety Hazards:

• Mechanical wire fatigue

• Sound levels in the room are interfering with the decibel monitor app

Control:

• Inspect haptic lead wires for strain relief at the solder point

• Run test in an isolated environment

Procedure:

• Push the SOS button

• Measure the time until the LRA vibrates

• Measure how loud (in decibels) the LRA is.

• Rate the vibration strength on a scale of 1-10

• Trigger three different patterns and see if the serial monitor registers them

  • Triple-tap: Emergency SOS triggered

  • Double-Tap: Haptic Status Check:

  • 5 Second Hold: ESP32 in sleep mode

Testing our project, results of the haptic motor driver and linear resonant actuator working in combination with the tactile push button remain inconclusive. Thus, the tactile push button failed this test. What we learned from this aspect of testing is that the pinout of the tactile push button includes two pins that are connected together adjacently. What we believe went wrong and the reason confirmation could not be sent to our serial monitor was that GPIO15 (the pin the button was connected to) may have not been a safe pin for the WeMos D1 Mini ESP32. We intend to, with more resources, test our hypothesis with a breadboard. However, this would use extra materials currently not at our disposal. 

Purpose: 

• The final validation stage examines the telecommunications integrity of the SIM7080G LTE-M uplink, which serves as the critical 'Physical-to-Digital' bridge. This test quantifies the end-to-end Latency of the emergency broadcast, measuring the time elapsed from a local hardware trigger to the successful propagation of a high-priority SMS across the cellular network. By evaluating the Uplink Budget under varied signal strengths (RSSI), we ensure the system can maintain connectivity in signal-marginal environments. The goal is to verify that a sanitized, clickable Google Maps URL is delivered to emergency contacts within 30 seconds, providing an immediate and reliable lifeline that transcends the limitations of localized hardware.

Pass/Fail Criteria:

• SMS must be received by the target mobile device within 30 seconds. The link must be "clickable" and resolve to the correct coordinates captured from Test #1.

Materials:

• SIM7080G Module

• LTE-M High-Gain Antenna

• Active SIM Hologram Card

• Target Mobile Phone

• Stopwatch

Initial Conditions: 

• Verify the cellular module is registered on the network

• 3.7V Lipo battery full

Safety Hazards:

• Peak current surge, which is >500mAh could lead to brownouts. 

Control:

• Utilize a high-discharge LiPo battery (800mAh); monitor for "brown-out" resets on the ESP32 during the transmission window

Procedure:

• Trigger SOS by pressing the tactile button

• Log the AT command response on the serial monitor

• Start the timer when button is pressed and end it when an SMS message with a Google Maps URL appears on the target phone

Testing of the SIM7080G module's signal quality, latency, and response has turned out inconclusive. Thus, test #4 of cellular propogation has failed. We believe the problem to be the lack of output able to be provided from an 800mAh battery due to how high-draw of a module the SIM7080G is in combination with the ESP32 and GPS all working simultaneously. For instance, although our calculations about draw seemed to be correct, our expert in software engineering also informed us that modern ESP32 boards "brown-out" and reset devices when they are at too low of a voltage, which happens naturally as a battery is powered. However, due to time constraints, we cannot get a higher-rated, 3.7V LiPo battery; perhaps at least 1000mAh.

Overall, we designed prototype proved to work moderately well, performing with flying colors 2 out of 4 of our pass/fail tests. The specific design criteria that were met were GPS precision, GPS boot-up time, and number of satellites caught by our GPS. Additionally, information on our database was encrypted, entirely protected by backend ways, and the website communicated perfectly with our database. However, the device was unable to send an electric signal to our haptic motor driver as well as send a SMS message with a Google Maps URL embedded. In truth, this reveals plenty of the shortcomings of our project, but also leaves room for optimism; all the software components were working virtually perfectly, and all issues seemed to be on the hardware aspect and the inability to acquire the resources to reiterate this prototype in a way that passes all the tests, due to the expensive nature of acquiring more batteries and development boards to test, as well as our time constraints. The viable solution is proven in the software, and must be iterated more times in the future to make entirely viable. At this time, testing the durability of our product as well as water-proofing it is secondary to the overall efficacy of the device. Above all, we look forward to the next stage in our engineering process: presenting our project to a broad audience and receiving external feedback in Element J.