Connected safety · IoT · Emergency response
Fall Detection System with GPS
A fall detector was not the product. The product was the complete chain from uncertain motion to a person accepting responsibility and resolving the incident.
Every product visual is labelled by provenance, so original work is never confused with a portfolio-created explanation.
A genuine working document, wireframe, screenshot or output that can be shown publicly.
A recreated product view grounded in the original work, using synthetic or anonymised information.
A simplified model created for this portfolio to explain system behaviour, workflow or product logic.
The safety problem beyond an emergency button
A conventional emergency button fails when the person cannot press it—and a detected fall still does not prove that help is coming.
Connected safety · IoT · Embedded systems · GPS · Emergency response · Android / iOS
The system had to recognise a potentially serious event, distinguish it from everyday movement, communicate through several technical links, locate the person, notify more than one caregiver and make responsibility visible. The product problem therefore crossed sensing, embedded hardware, connectivity, mobile software and human coordination.
The most serious incident can remove the user from the workflow.
A manual SOS button remained useful, but the product could not depend on the person being conscious, mobile or able to reach it.
Normal movement can resemble a fall—and a real fall can be missed.
The product needed a reversible verification path, a cancellation route for false alarms and a test method that compared falls with everyday activity.
Sensing, RF, location and cellular delivery could fail independently.
The complete experience depended on multiple devices and communication links. Each degraded condition needed to be visible rather than silently interpreted as safety.
Notification delivery does not establish responsibility.
With several caregivers, the system had to show who had acknowledged the incident, when escalation was required and when the event had actually reached closure.
The connected product system
The wearable was one component in a chain that ended with coordinated human action.
The architecture separated sensing, embedded decision logic, local communication, location, outbound alerts and caregiver coordination. Each component had a defined responsibility, but the user experienced them as one promise of safety.
Accelerometer and gyroscope observe movement and orientation
Embedded processing evaluates a suspected fall or manual SOS
The wearable transmits the event to the local base station
The powered hub coordinates event, status and outbound communication
Location context and SIM/SMS delivery support remote response
Android and iOS experiences make acknowledgement and action visible
Design for detection uncertainty
A movement algorithm needed an alternate trigger, a verification state and a safe route back.
Fall detection was not treated as a binary truth. The system combined inertial signals with manual input and represented uncertainty explicitly before starting the emergency workflow.
Everyday movement remains below the event threshold
Motion pattern enters a verification window
The user indicates a false alarm and monitoring resumes
Automatic logic or manual input starts the incident workflow
Use automatic detection alongside manual SOS—and make false alarms reversible.
Automatic detection covered the situation in which the user could not act. Manual SOS covered emergencies that did not look like a fall. A cancellation path acknowledged that false positives were inevitable in a movement-based system and prevented the algorithm from becoming an unquestioned authority.
Turn an alert into accountable response
The system had to know whether somebody had actually taken responsibility.
A safety workflow could not end at notification delivery. Acknowledgement, ownership, location, escalation and closure were separate product states because each answered a different operational question.
Track acknowledgement, not only notification delivery.
An outbound SMS or app alert only proves that the system attempted communication. The incident needed a separate acknowledgement state showing that a caregiver had accepted responsibility, followed by response, escalation and closure states.
Use multiple caregivers without creating ambiguous ownership.
A caregiver network reduced dependence on one emergency contact, but it introduced a coordination risk: everyone could assume somebody else was responding. The product therefore needed one visible responder, shared incident status and escalation when nobody accepted the alert.
Automatic event or manual SOS
False-alarm window closes or SOS bypasses it
Caregiver network receives incident context
One caregiver accepts responsibility
Available location context supports response
Help is actively being coordinated
No response or medical need triggers the next path
The incident is closed with an explicit outcome
Detection created an incident. Only an explicit outcome closed it.
Suspected fall
Allow cancellation and return to monitoringConnectivity degraded
Expose the missing link rather than imply deliveryLocation degraded
Continue the incident while showing location uncertaintyResponse unowned
Escalate instead of treating notification as completionPrototype validation through controlled contrast
The detection logic was refined by comparing controlled falls with ordinary movement.
The prototype work used a mannequin to reproduce falls from different positions and recorded routine daily motion to understand false-positive patterns. The signals were compared, the decision logic was adjusted and the scenarios were repeated. This was prototype engineering validation—not clinical efficacy testing.
- Forward / backward events
- Side and seated transitions
- Different impact and resting positions
- Walking and sitting
- Bending and lying down
- Routine transitions and device motion
Product ownership across connected hardware and applications
I treated the wearable, embedded logic, base station, localisation, communication and caregiver apps as one safety product.
My scope covered user and caregiver discovery, product architecture, incident-state design, hardware and embedded-system coordination, GPS and communication requirements, Android and iOS application oversight, failure scenarios, validation planning and end-to-end prototype delivery. The central PM task was to keep every technical component aligned to the human outcome: a vulnerable person receiving coordinated help.
Customer and caregiver discovery around high-risk incident scenarios
End-to-end product architecture across wearable, base station, GPS/SIM and apps
Automatic and manual triggering, false-alarm and incident-state logic
Caregiver acknowledgement, ownership, escalation and closure workflows
Cross-functional oversight of embedded hardware and Android/iOS delivery
Prototype test scenarios using controlled falls and everyday movement
Evidence-bounded outcomes
Delivered work
What the prototype programme made explicit and testable.
Completed user and caregiver discovery around falls, remote family support and emergency-response uncertainty.
Developed the product-system architecture connecting sensing, embedded hardware, RF, GPS, cellular communication and caregiver applications.
Defined automatic and manual triggering, cancellation, acknowledgement, ownership, escalation and resolution logic.
Moved the concept into connected-device prototype and application-development work.
Established a repeatable prototype-validation method using controlled falls and everyday movement recordings.
The work reached customer discovery, detailed product-system design, connected-device prototyping and application-development work. This case does not claim commercial deployment, medical-device approval, clinical efficacy or population-level fall-detection accuracy.
Public diagrams are date-neutral portfolio reconstructions based on surviving project knowledge and documented product behaviour. They do not reproduce a production medical interface or imply regulatory approval.
What the work changed in how I think
A safety product is complete only when uncertainty, responsibility and recovery are designed end to end.
Detection is not resolution.
The user problem continues after the algorithm fires. Location, responsibility, response and closure belong in the same product model.
False positives are a product problem.
Thresholds matter, but so do cancellation, user trust, caregiver fatigue and the way uncertainty is communicated.
Redundancy needs ownership.
Multiple caregivers improve resilience only when one person can visibly accept responsibility and escalation remains explicit.
Safety systems must design degraded states.
RF, GPS, cellular delivery and human response can fail independently; the interface must show what is known and what is not.