Man Overboard Smartphone Detection System

1. The MOB Problem by the Numbers

In many family yachts, if a person falls overboard there is nearly a 50% chance it results in death. This staggering statistic arises from several compounding factors:

Turning radius & time: A sailboat under sail can take many minutes to turn around and return to the MOB location — especially if short-handed.
Visual search difficulty: A person's head in the water is incredibly hard to spot amid waves, especially in anything above calm seas. The effective visual detection range can shrink to under 100 feet in moderate chop.
Cold water shock: Even in relatively warm water (60–70°F / 15–21°C), incapacitation can occur in under 30 minutes. In colder waters, survival time may be measured in single-digit minutes.
Delayed alarm: If nobody witnesses the fall, the alarm may not be raised for minutes or even hours — by which time the vessel is miles away.

~50%

Fatality rate for MOB events on family yachts

200+

Annual MOB deaths in US waters alone (recreational)

~600

Total US boating fatalities per year (USCG 2023)

<2 min

Critical window for recovery in cold water

⚠️ The Core Insight: The single biggest factor in MOB survival is time to detection. Shaving even 30 seconds off the alarm time dramatically increases survival probability. The proposed smartphone system aims to reduce detection time to under 3–6 seconds.

2. Why the Seastead Is Inherently Safer

The seastead design (large triangular truss living area atop three NACA 0030 foil-shaped legs) offers several intrinsic safety advantages over conventional monohull sailboats or power cruisers:

Factor	Conventional Yacht	Seastead
Stability	Rolls & pitches significantly; deck movement is constant	Small waterline area + wide trimaran stance = very soft ride; minimal deck movement
Need to go outside	Sail adjustments, line handling, anchoring require frequent deck movement	Enclosed living area; no sails to tend; minimal outside exposure required
Stopping ability	Long stopping distance under sail; even under power, significant momentum	6 RIM drive thrusters (1.5 ft diameter) on three legs enable rapid stopping & reversing
Fall height	Deck typically 3–5 ft above water; lifelines may be low	Living area ~7 ft above water on truss structure; enclosed with glass
Recovery	Often requires deploying a ladder, lifting sling, or crew assistance	Built-in ladders on top half of each leg; swim-to-ladder recovery possible even solo
Dinghy obstruction	Dinghy often on davits aft; can complicate MOB recovery	14 ft RIB shielded behind living area when underway; two aft decks provide recovery platforms

✅ Key Takeaway: The seastead's design already reduces MOB probability significantly. The smartphone system addresses the remaining risk — and does so at near-zero hardware cost.

3. The Smartphone MOB Detection System — How It Works

The core idea is remarkably simple: every person on board already carries a smartphone. These phones have Bluetooth, WiFi, accelerometers, and GPS. An app running in the background maintains a continuous "heartbeat" connection to a base station computer on the vessel. If the heartbeat stops — because the person (and their phone) went overboard and the signal was instantly blocked by water — the system escalates through a rapid sequence of alarms and automated responses.

3.1 Heartbeat Protocol

Phone app sends a tiny heartbeat packet every 1 second via Bluetooth Low Energy (BLE) to the base station.
If BLE is out of range (vessel too large, antenna placement issues), the app falls back to WiFi (UDP heartbeat on the local network).
Each heartbeat includes: device ID, timestamp, battery level, and a sequence number.
The base station logs GPS position every second independently — phones don't need to constantly query GPS (saving significant battery).

3.2 The "Water Blocks 2.4 GHz" Phenomenon

💡 The Brilliant Physics: Water is highly opaque to 2.4 GHz frequencies (the band used by both Bluetooth and WiFi). The moment a phone submerges — even just a few inches — the signal is instantly and completely blocked. You don't have to wait for the device to float out of range. Submersion itself triggers the break. This is a far more reliable trigger than range-based disconnection, which can vary with antenna orientation and interference.

3.3 Escalation Timeline

T+0s — Person falls overboard. Phone submerges. 2.4 GHz signal instantly blocked.

T+1s — Base station misses first expected heartbeat.

T+2s — Second missed heartbeat. Base station attempts active ping to phone (WiFi + BLE).

T+3s — Third missed heartbeat. Audible alarm sounds on vessel. Crew alerted.

T+4–6s — Base station commands thrusters to full stop / reverse. Vessel begins returning to last known GPS position.

T+6s — If still no heartbeat, full MOB protocol engages: automated mayday/DSC call, MOB waypoint set on chartplotter, strobe lights activated (if equipped), and continuous audible alarm.

3.4 Optional: Accelerometer-Based "Zero-G" Detection

The phone's built-in accelerometer can detect the moment of free-fall when a person goes overboard. A "zero-G event" message can be sent before the phone even hits the water, recording the exact time and GPS location of the fall. However:

Constant accelerometer polling significantly drains battery (potentially reducing phone life by 30–50% over a day).
This feature should be off by default and optionally enabled for high-risk situations (night passages, rough weather, solo operation).
Modern phones (iPhone 14+, recent Android flagships) have low-power always-on motion coprocessors that mitigate this drain — but not all devices support this.

3.5 Handling False Alarms Gracefully

A system that cries wolf will be disabled or ignored. The design must be robust against common failure modes:

Scenario	System Response
Single packet loss	Ignored. Base station waits for 3 consecutive misses before escalating.
Phone temporarily out of BLE range (e.g., far end of vessel)	App auto-falls-back to WiFi. If both fail, active ping initiated before alarm.
Phone battery dies	App sends "low battery" warning at 5%. If phone dies, alarm triggers — this is acceptable as the user should have charged their phone. App enforces charging discipline via notifications.
User goes below deck (signal attenuation)	Base station learns "safe zones" where signal is weaker. Multiple antenna nodes (mesh) can be deployed on larger vessels.
App put to sleep by OS	User must whitelist the app (disable battery optimization). App provides clear onboarding instructions for iOS & Android.

4. Technical Considerations & Battery Life Analysis

4.1 Bluetooth vs. WiFi — Power Consumption

Radio	Typical Range	Power per Ping	Idle Current	Suitable for
BLE (Bluetooth Low Energy)	30–100 ft (10–30 m) open air	~0.01–0.05 mAh per advertisement	~1–3 mA	Primary heartbeat; excellent battery life
WiFi (2.4 GHz)	150–300 ft (45–90 m) with good AP	~1–5 mAh per transmission	~10–50 mA active	Fallback when BLE out of range; higher drain
GPS (phone)	N/A (satellite)	~30–50 mA continuous	N/A	Only when actively needed; base station handles position logging

4.2 Estimated Daily Battery Impact

With BLE heartbeat at 1 Hz and the app properly optimized (using platform-native background services):

BLE-only mode: ~3–6% additional battery drain per day — barely noticeable on a modern smartphone.
BLE + occasional WiFi fallback: ~5–10% additional drain per day — most phones still make it through a full day on one charge.
With accelerometer always-on: ~20–35% additional drain — noticeable; recommended only for high-risk scenarios.

For comparison, streaming 30 minutes of video uses far more battery than this app would in an entire day of heartbeat-only operation.

4.3 Preventing the OS from Killing the App

Both iOS and Android aggressively manage background apps to save battery. The app must guide users through:

Android: Disable "Battery Optimization" for the app (Settings → Apps → MOB Guard → Battery → Unrestricted). Use a persistent foreground service notification.
iOS: Enable "Background App Refresh." Use Core Bluetooth state preservation. The app can display a Live Activity or use critical alerts entitlement for higher priority.
Both: The app should periodically (every 5 minutes) perform a self-check and alert the user if background operation has been restricted.

Yes, users can absolutely set "never put this app to sleep" — it's a standard setting on both platforms, though the exact path varies by manufacturer (Samsung, Xiaomi, etc. have additional steps).

4.4 Optional: Door Sensor Hardware

An optional magnetic door sensor on exterior doors can detect when someone exits without a phone nearby. If a door opens and no recognized phone is within 10 feet, an alarm sounds. This is extra hardware but provides defense-in-depth for forgetful users. Cost: ~$15–30 for a Zigbee/Z-Wave door sensor integrated with the base station.

5. Can AI Build This? Development Feasibility

The short answer: Yes, absolutely. This is well within the capabilities of current AI coding tools. The system consists of two straightforward components:

5.1 What Needs to Be Built

Component	Technology	Complexity	AI Can Handle?
Mobile App (iOS + Android)	React Native / Flutter / or native Swift + Kotlin	Medium	✅ Yes
Base Station Server	Python (Flask/FastAPI) or Node.js; runs on Raspberry Pi or onboard computer	Low–Medium	✅ Yes
BLE Heartbeat Protocol	Platform BLE APIs; simple advertisement/listener pattern	Low	✅ Yes
Dashboard UI	Web-based (React/Vue) showing all connected devices on a vessel map	Low	✅ Yes
NMEA 2000 / Signal K Integration	For auto-stop, MOB waypoint, and thruster control	Medium	⚠️ Partial

5.2 Recommended AI Tools

Claude Code / Cursor / GitHub Copilot: Can generate the vast majority of the app and server code. Claude Code in particular excels at multi-file project generation with good architecture.
React Native + Expo: Cross-platform mobile framework. AI tools are very proficient with React Native — it's one of the most common frameworks in training data.
FastAPI (Python): For the base station server. AI tools can generate a fully functional REST API + WebSocket server for real-time heartbeat monitoring in minutes.
Platform-specific BLE libraries: react-native-ble-plx or flutter_blue_plus — both well-documented and AI-familiar.

                // Pseudocode: Heartbeat listener on base station (Python)

                import asyncio, time

                from collections import defaultdict

                last_heartbeat = defaultdict(lambda: time.time())

                MOB_THRESHOLD = 3.0  # seconds

                async def check_heartbeats():

                    while True:

                        now = time.time()

                        for device_id, last in last_heartbeat.items():

                            if now - last > MOB_THRESHOLD:

                                trigger_mob_alarm(device_id, last)

                        await asyncio.sleep(0.5)

5.3 How Hard Is It to Get Started Now?

Compared to the "very painful" Java phone app days, the landscape has transformed completely:

With Expo (React Native), you can go from zero to a running app on both iOS and Android in under 30 minutes — AI can scaffold the entire project with one prompt.
The BLE heartbeat logic is ~200 lines of code total. The server is ~300 lines. The whole system (app + server + basic dashboard) is under 2,000 lines — a weekend project with AI assistance.
A developer with moderate experience and AI tools could produce a working prototype in 2–4 days and a polished v1.0 in 2–3 weeks.

✅ Bottom Line: This is an ideal AI-assisted project. The scope is small, the technologies are mainstream, and the core logic is simple. AI tools like Cursor or Claude Code can write 80–90% of the code. A human developer is needed primarily for integration testing, Bluetooth edge cases, and the NMEA/Signal K marine electronics integration.

6. Existing MOB Detection Systems — Comparison

Several commercial systems already exist. The proposed smartphone approach is not entirely novel, but the open-source, zero-hardware-cost, water-signal-blocking-trigger combination is distinctive:

System	Type	Hardware Required	Cost	Detection Method	Auto-Stop	Open Source
ACR OLAS	Bluetooth tag + phone app	Dedicated OLAS tag or phone	$150–300	BLE signal loss	⚠️ Optional	✗
Fell Marine MOB+	Bluetooth kill switch	Wearable fob + base unit	$200–400	BLE signal loss; engine cut	✅ Yes	✗
SafeTrx (RYA)	Phone app + cloud	Smartphone only	Free	GPS track; manual check-in	✗	✗
Apple Watch	Wearable	Apple Watch ($400+)	$400+	Fall detection + water lock	✗	✗
Ocean Signal MOB1	AIS/DSC beacon	Dedicated beacon device	$300–400	Manual activation or auto-inflate	✗	✗
Garmin inReach	Satellite messenger	Dedicated device + subscription	$300 + $15/mo	Manual SOS; satellite tracking	✗	✗
🆕 Proposed System	Phone app + base station	Smartphone (already owned)	$0	BLE/WiFi heartbeat + water signal block	✅ Yes (with integration)	✅ Yes

6.1 What's Different About the Proposed System?

Zero additional hardware cost — leverages phones everyone already carries.
Open source — community-auditable, customizable, no vendor lock-in.
Water-as-trigger physics — instant signal block on submersion is more reliable than range-based disconnection.
Seastead integration — designed to command RIM drive thrusters for automated stop-and-return.
Yacht-universal — any vessel with a computer (Raspberry Pi, laptop, or chartplotter server) can run the base station.

7. Issues, Edge Cases & What to Be Careful About

No safety system is foolproof. Here are the critical considerations when deploying a phone-based MOB system:

7.1 False Alarm Management

The "cry wolf" problem: If the system false-alarms more than once or twice, users will disable it. The 3-second grace period and active re-ping are essential.
Testing mode: The app should include a "test MOB" button that runs the full sequence so users can verify it works without real emergencies.
Geofenced suppression: The base station can learn that certain areas (e.g., far end of a dock, inside a marina building) have poor signal and suppress alarms in those zones.

7.2 Phone Reliability

Not all phones are waterproof: While most modern phones have IP68 ratings, older or budget phones may not survive submersion. The signal will still cut off (triggering the alarm), but the phone itself may be lost. This is acceptable — the alarm is the primary goal; phone recovery is secondary.
Phone in a waterproof pouch: Ironically, a phone in a waterproof pouch may delay the water-block trigger if the pouch is sealed. However, BLE range through a pouch + water is still severely attenuated, and the signal will likely drop within 1–2 seconds of submersion.
Battery death: The app must aggressively warn users at 10% and 5% battery. The base station should announce "low battery on [user]'s phone" audibly.

7.3 Privacy Considerations

The base station logs GPS position every second — this is vessel position, not individual tracking. It only needs to know which phones are connected, not where each phone is relative to the vessel.
No data needs to leave the vessel (no cloud dependency). The system should function fully offline.
If Starlink is available, optional cloud backup of MOB events could be useful for post-incident analysis, but this should be opt-in.

7.4 Environmental Edge Cases

Heavy rain / spray: Water on the phone's antenna can attenuate BLE signal. However, rain alone won't fully block 2.4 GHz — the signal degradation is gradual, not instant, so the system can distinguish between attenuation (signal weakens over seconds) and submersion (instant cutoff).
Person below deck: If someone goes inside a metal-hulled vessel or far below deck, signal may drop. The base station should have multiple BLE/WiFi nodes (mesh) covering all areas where people might be.
Crew sleeping: The system should have a "sleeping on board" mode where the alarm threshold is relaxed (e.g., 30 seconds instead of 3) to avoid waking everyone for a phone that drifted out of range.

7.5 Legal & Liability

Open-source software comes with no warranty. A clear disclaimer must state that this is a supplemental safety aid, not a replacement for proper watchkeeping and life jackets.
Integration with vessel propulsion (auto-stop) carries additional liability. This should be a user-enabled opt-in feature with explicit acknowledgment of risks.

⚠️ Key Design Principle: The system should never silence a real alarm in an attempt to reduce false alarms. It's better to have one false alarm per month than to miss a real MOB event. Design the escalation so that false alarms are annoying but not dangerous — and real alarms are impossible to ignore.

8. Can Existing Yachts Use This Today?

Yes. The majority of family yachts already have:

A computer on board — even a cheap Raspberry Pi 4 ($50) is more than sufficient to run the base station server.
WiFi — most cruising yachts have a WiFi router (often connected to Starlink). Even without internet, the local network functions for heartbeat communication.
Smartphones — every crew member has one.

For yachts without integrated autopilot/thruster control, the base station can still:

Sound a loud audible alarm (via ship's speakers or a dedicated piezoelectric alarm).
Set a MOB waypoint on any connected chartplotter (via NMEA 0183/2000 or Signal K).
Send a notification to all other phones on board with the MOB location.
Optionally trigger a DSC distress call via a connected VHF radio.

For the seastead specifically, the integration goes further — the base station can directly command the RIM drive thrusters for automated stop-and-return, making it viable even for solo operation.

🎯 The Vision: A free, open-source app that any yacht owner can download. The base station software runs on a $50 Raspberry Pi. Total cost: $0–50. Lives saved: potentially dozens per year if widely adopted. This could be built now, before the seastead is even constructed — and it would already make existing yachting dramatically safer.

9. Summary & Next Steps

Aspect	Assessment
Problem severity	~50% MOB fatality rate on family yachts; 200+ deaths/year in US alone
Proposed solution	Smartphone app with BLE/WiFi heartbeat + water-signal-block detection
Hardware cost	$0 (uses existing phones); optional $50 Raspberry Pi base station
Development effort	~2–4 weeks with AI assistance for a polished v1.0
Battery impact	~3–10% additional daily drain (acceptable for most users)
False alarm risk	Manageable with 3-second grace period, active re-ping, and geofencing
Existing alternatives	Several commercial systems exist ($150–400); none are open-source or zero-cost
Seastead integration	Auto-stop + return via RIM drive thrusters; built-in leg ladders for solo recovery
Adoptability	Any yacht with WiFi and a basic computer can run this today

Recommended Next Steps

Spec out the protocol: Define the exact BLE advertisement format, heartbeat interval, and escalation logic in a formal spec document.
Scaffold with AI: Use Cursor or Claude Code to generate the React Native app skeleton + FastAPI server in a single session.
Test the water-block physics: Submerge a phone running a BLE beacon in a bucket of saltwater; measure signal cutoff time with a BLE scanner. Validate the core premise.
Build a Raspberry Pi test rig: Deploy the base station on a Pi with a USB BLE dongle and test with 2–4 phones in a simulated vessel environment.
Open-source release: Publish on GitHub with clear documentation. The marine community is highly collaborative — this could gain traction quickly.
Seastead integration testing: Once the seastead is built, integrate with the RIM drive thruster controllers for full auto-stop-and-return functionality.

🔗 Final Thought: This is a rare opportunity where the right solution costs almost nothing, leverages devices already in every pocket, and can be built rapidly with modern AI tools. The open-source model means it can be audited for safety, improved by the community, and adopted worldwide. There's no reason to wait — the prototype could be running within weeks, saving lives long before the seastead touches water.