Man-Overboard Fatality Statistics
Exact global figures are difficult to standardize due to varying reporting standards, but authoritative maritime safety bodies agree on the following:
- USCG Data (Recreational Boating): ~300–400 recorded MOB-related fatalities annually in US waters alone.
- RNLI & RNIB (UK/EU): ~150–250 recorded MOB deaths per year, with survival dropping below 20% if recovery exceeds 30 minutes in cold water.
- Global Cruise & Offshore Industry: Estimated 1,000–2,000 passenger/crew MOB incidents yearly; fatality rates range 60–85% for unassisted falls, heavily dependent on water temperature, visibility, and vessel speed.
- The ~50% mortality figure you cited aligns closely with mid-latitude recreational sailing when the person falls at night or in seas >3 ft.
Key takeaway: Rapid alert (<60 sec), immediate vessel maneuver, and clear location tagging are the primary determinants of survival.
Smartphone-Based Detection: Technical Reality Check
Your core concept is sound and aligns with modern "personal safety beacon" logic, but mobile OS constraints and marine physics require specific adaptations.
1. Background Execution & "Never Sleep" Settings
Both iOS and Android aggressively limit background apps to preserve battery. True "never sleep" is intentionally disabled by default:
- iOS: Requires
CLLocationManagersignificant changes or region monitoring. True periodic execution requires a foreground service or significant location updates. - Android: Can run a
Foreground Servicewith a persistent notification. Battery optimization (Doze/AppStandby) must be explicitly exempted in settings. - Workaround: The app must request explicit user permission for continuous background location + network access, and display a small persistent indicator on modern phones.
2. Battery Impact & Check-In Frequency
Polling GPS + network + accelerometer every second will drain ~25–40% additional battery daily. This is unsustainable for long days onboard.
- Use Bluetooth Low Energy (BLE) for proximity (1–3 sec advertising interval). ~5% battery/day when stationary.
- Adaptive polling: 1-sec checks only when outside the cabin or near rails; 15–30 sec checks otherwise.
- Hardware offload: A cheap BLE moisture/pressure tag on the belt/lanyard reduces phone sensor polling entirely.
3. Water & RF Physics
2.4 GHz signals attenuate rapidly in water, but signal loss ≠ instant submersion trigger in real-world use:
- Phone RF performance drops in wet pockets, behind carbon/metal railings, or inside Faraday-cage structures (like certain yacht cabins).
- Fresh vs. saltwater changes attenuation rates. Salt blocks faster.
- Best practice: Combine signal drop with barometric pressure/GPS altitude shift + accelerometer tumble detection. A standalone BLE beacon with a moisture-contact switch is far more reliable than a pocketed phone.
4. "Zero-G" Detection Before Impact
In theory, free-fall triggers ~0g on accelerometer. In practice, wind drag, clothing friction, arm flailing, or snagging on railings create noisy, non-zero-G signatures. It's usable as a secondary trigger, but not a primary one.
Commercial & Open-Source Precedents
Several systems already implement variations of your idea:
| System | Approach | Strengths | Limitations |
|---|---|---|---|
| LifeTag SmartLifeBuoy | Wearable BLE + AIS + pressure sensor | Waterproof, instant submersion trigger, integrates with chartplotters | $400+ per tag, proprietary ecosystem |
| Ocean Signal MOB1 | AIS-SART + DSC + strobe | Regulatory-compliant, long range | Large form factor, manual activation preferred |
| MOB Alert / iNavX / FindMy-style marine trackers | Phone app + local network + cloud | Low cost, leverages existing hardware | False alarms, OS background limits, signal loss ambiguity |
| Apple/Android Personal Safety APIs | Accelerometer + gyroscope + fall detection | Built-in, low power, highly tuned | Not optimized for marine environments, no auto-water verification |
Can Existing Yachts Run This for Free?
- Compute: Most modern yachts already run a Raspberry Pi, Linux box, or chartplotter NMEA gateway. Adding a lightweight MQTT/WebSocket server (~50–150 MB RAM) is trivial.
- Signal K / OpenPlotter: Open-source marine data servers that accept WebSocket clients. Your server app can plug directly into existing marine bus architecture.
- Autopilot/Thruster Integration: Do not implement automated fast-stop/reverse without hardware failsafes. Most yachts require manual NMEA 0183/2000 routing or a physical relay interface. An alarm + waypoint drop is safer and universally deployable.
Raspberry Pi + OpenSignalK Server + Mosquitto MQTT + Simple Node.js/Python WebSocket Gateway + Web Dashboard
AI-Assisted Development: Now vs. Then
You're correct: what took weeks of painful Java/Xcode setup in 2010 can now be scaffolded in days.
Will AI Write This?
- Yes for scaffolding: Claude, Cursor, and Copilot can generate cross-platform UI, BLE scanning, background service templates, MQTT/WebSocket servers, and dashboard fronts rapidly.
- No for marine certification: AI won't handle edge-case testing, OS update breakage, battery regression, or NMEA autosteer integration. Those require iterative field testing and safety audits.
Recommended Toolchain
| Component | Recommended Stack | Why |
|---|---|---|
| Mobile App | Flutter or React Native + native BLE/Location plugins | Single codebase, strong background support, easy AI scaffolding |
| Local Server | Python FastAPI or Node.js + MQTT (Mosquitto) | Low resource, WebSocket push, easy Signal K integration |
| Protocols | BLE 5.x (advertising packets), MQTT QoS 1, WebSockets | Reliable low-power, drop-resilient, real-time |
| Dashboard | Web-based (React/Vue) running on Pi | Accessible from any onboard tablet/phone |
With AI assistance, a functional alpha (check-in, alarm, waypoint drop) can ship in 5–10 dev days. Hardened marine release: 2–3 months of sea trials + false-positive tuning.
Critical Implementation Safeguards
To prevent false alarms, battery death triggers, or panic-induced system failure, implement these rules:
- Multi-Trigger Validation: Alarm fires only when ≥2 conditions align: loss of BLE/WiFi + accelerometer tumble/impact + timeout >X seconds.
- Grace Periods: 3 sec warning tone on phone, 6 sec vessel alarm with manual cancel from cabin/console. Prevents pocket-bounce or Wi-Fi handoff false positives.
- Battery Awareness: Push critical notifications at 20% and 10%. If phone dies, don't trigger MOB; require explicit "I forgot my phone" override.
- Water Contact Fallback: Add $15 BLE moisture/contact tags clipped to life jackets. They trigger instantly on immersion and require zero phone background polling.
- Autopilot Safety: Do NOT command thruster reverse automatically. Instead, drop AIS-SART style waypoint, sound alarm, and suggest pre-programmed "MOB Turn" to helmsperson.
- Open-Source Liability: Clearly label as "supplementary safety tool, not certified marine lifesaving apparatus." Add disclaimers and avoid autonomous hardware control without failsafes.
Recommended Path Forward
- Paper Prototype: Map BLE scan intervals, battery trade-offs, false-positive filters, and cabin/rail RF zones on your seastead layout.
- Week 1-2 (AI + Dev): Use Cursor/Flutter to build background service, 2-sec BLE heartbeat, timeout logic, and local WebSocket alarm dashboard. Run on a Raspberry Pi.
- Week 3-4 (Hardware Add-on): Prototype a $12 BLE moisture+pressure tag to clip onto PFDs. Test submersion vs. pocket splash vs. rain.
- Week 5-8 (Sea Trials): Deploy on existing vessel. Measure false alarms, battery at 24h, RF dead zones. Tune thresholds. Integrate with OpenSignalK for AIS waypoint drop.
- Release: Publish as open-source supplementary safety tool. Provide install scripts, Signal K plugin, and mobile binaries. Document limitations clearly.
This can absolutely launch before your seastead is built. It will save lives, validate your safety architecture, and attract marine community adoption.