A smartphone-based crew monitoring system that costs nothing, installs in minutes, and could save hundreds of lives every year.
The numbers are stark. Falling overboard is one of the deadliest accidents in recreational boating, with fatality rates that haven't improved significantly in decades.
Deaths per year in the US from falling overboard on recreational vessels. It is consistently the #1 or #2 cause of boating fatalities.
Of all MOB incidents on family yachts, roughly half result in death. The rate is even worse at night or in cold water, approaching 80%+ in some studies.
In cold water (under 59°F / 15°C), incapacitation from cold shock can occur in 2–5 minutes. In rough seas, a person can disappear from view in as little as 15 seconds.
The seastead design inherently reduces MOB risk compared to traditional yachts.
Three widely-spaced buoyancy legs with a 35-foot beam provide platform-like stability. No heeling, no sudden rolls. The chance of being thrown off by boat motion is dramatically reduced.
No sails to trim, no sheets to adjust. All controls are inside the enclosed living area. You never need to go on deck in rough weather to handle lines or sails.
Six RIM drive thrusters can stop the seastead quickly and maneuver it precisely back to the last known position. No tacking or gybing — just thrust in any direction.
Use the smartphone already in everyone's pocket as a crew presence beacon. Zero additional hardware for the crew. Open-source software that any yacht can install.
The app on each crew phone sends a short "heartbeat" message to the base station every 1 second via Bluetooth LE (primary) or Wi-Fi (fallback). The base station records location from the boat's GPS — phones don't need GPS enabled.
Water is essentially opaque to 2.4 GHz radio. The moment a phone submerges even an inch, Bluetooth and Wi-Fi signals are completely blocked. The base station detects the missing heartbeat.
One missed packet is ignored (network noise). Two missed packets (2 seconds) triggers a retry. Three missed packets (3 seconds) sounds the MOB alarm. Six missed packets (6 seconds) initiates automatic stop and return to the GPS position recorded at the time of signal loss.
The seastead returns to the exact GPS coordinates where the signal was lost. Ladders on all three legs allow the person in the water to climb back aboard — even a solo operator can self-rescue once the vessel returns.
The phone's accelerometer can detect a free-fall event (zero G) before the person even hits the water. This gives the earliest possible alarm — the system knows someone is falling, not just that they've gone missing.
A Bluetooth beacon on the exterior door detects if someone opens it without a phone in their pocket. The system sounds a reminder: "You're going outside without your phone — your MOB protection is inactive."
This is the elegant part. You don't need to detect submersion with sensors. At 2.4 GHz, water attenuates radio signals by roughly 100+ dB per meter. Even a few inches of water between the phone and air blocks the signal completely.
The moment a phone goes under, the signal doesn't weaken — it vanishes. This makes submersion detection essentially binary and near-instantaneous. No false "slow drift away" alarms. No ambiguous signal strength interpretation.
The three biggest technical questions: Will it kill the phone battery? Will the OS kill the app? Will the signal be reliable?
BLE advertising at 1-second intervals is extremely efficient. A modern phone can do this for 30+ hours on a single charge.
Wi-Fi polling every second is much heavier. The app should only fall back to Wi-Fi when BLE is unavailable.
High-frequency accelerometer sampling (100+ Hz) is power-hungry. Keep this OFF by default.
iOS is the harder platform. Apple aggressively puts background apps to sleep to save battery. However, there are established workarounds:
Android is easier but has manufacturer-specific issues:
Don'tKillMyApp exist to handle this.
Answer to your question: Yes, there are ways to prevent the OS from sleeping the app. On Android it's straightforward (foreground service). On iOS it requires using BLE background modes properly. The app setup wizard should walk users through the necessary settings. This is a solved problem — apps like Navionics, MarineTraffic, and various fitness apps already do it successfully.
| Factor | Bluetooth LE | Wi-Fi |
|---|---|---|
| Range on boat | 10–30m (enough for 35ft beam) | 30–100m (full coverage) |
| Battery drain | Very low (~1–3%/hr) | Medium (~5–15%/hr) |
| Water blocking | Instant (good for detection) | Instant (good for detection) |
| Background support | Good (native BLE) | Problematic (OS restrictions) |
| Packet loss rate | Higher (noisy 2.4 GHz) | Lower (managed connection) |
| Implementation | BLE peripheral mode | UDP broadcast or TCP |
Recommendation: Use BLE as primary and Wi-Fi as fallback, exactly as you suggested. The base station should be a BLE central device (like a Raspberry Pi with BLE) that listens for phone advertisements. If BLE signal is lost, the phone app should try Wi-Fi. However, given that BLE range on a 35-foot beam vessel should be more than adequate, the Wi-Fi fallback may rarely be needed.
Several commercial MOB systems exist, but they all have limitations that a phone-based system could overcome.
Each crew member wears a small BLE fob. A base station on the boat monitors signals. If a fob goes out of range or is submerged, it triggers an alarm. Connects to chart plotters via NMEA 2000.
Similar concept to CrewWatcher but from Raymarine. Uses proprietary 868/916 MHz protocol (not BLE). Each tag is a small pendant. Range is about 30 feet. Triggers alarm on Raymarine MFD.
These are serious rescue devices that broadcast an AIS MOB signal on VHF frequencies. They also activate automatically on water contact. Any AIS receiver within ~2–5 miles picks up the signal. Some also have GPS and DSC.
Several projects have attempted phone-based MOB detection, though none have achieved wide adoption:
No existing system combines all of these advantages:
The gap between "idea" and "working prototype" has never been smaller. Here's a realistic development plan using AI coding tools.
Key libraries: react-native-ble-plx (BLE), @react-native-community/netinfo (Wi-Fi), react-native-background-actions (background execution), react-native-sensitive-info (secure storage)
Hardware: Raspberry Pi 4 + USB BLE dongle + GPS hat ≈ $75 total. Or a laptop with BLE already built in. Connects to boat's NMEA 2000 network via Actisense gateway for chart plotter integration.
Using Cursor or Claude Code: Expo React Native app that sends BLE advertisements. Python server that listens and logs presence. Alarm when heartbeat stops. This is the "Hello World" of the system — achievable in hours, not days.
Add graduated timeout (1s miss → retry → 3s alarm → 6s action). Wi-Fi fallback. Packet loss tolerance. This is the critical safety logic and should be tested thoroughly.
Base station records GPS position every second. On MOB alarm, output waypoint to autopilot or thruster control. For your seastead, this integrates with the RIM drive control system.
Walk users through OS-specific background execution settings. Battery monitoring. Optional door BLE beacon integration. Zero-G sensor as opt-in. UI for managing crew devices.
Real-world testing on boats. False alarm rate measurement. Range testing with BLE. Safety certification if it will be marketed as a safety device (this is a long pole but not needed for personal use).
Your question about whether family yachts already have computers that could run this is important. The answer is mixed:
A safety system that fails is worse than no safety system — it creates false confidence. These are the issues you must get right.
This is the #1 killer of safety systems. If the alarm goes off falsely more than a few times, people will disable it. Then it's useless.
This is the fundamental weakness of any phone-based system. The best MOB detection in the world doesn't help if the phone is sitting on the chart table.
Based on all the considerations above, here's our recommended minimum viable system.
Central server + BLE central + GPS hat. Mounted inside the living area. Connected to 12V power. Runs Python server software.
One at each leg/point of the triangle. Connected via Wi-Fi to the Pi. Provides full coverage and triple-redundancy for signal loss detection. ~$5 each.
BLE peripheral mode, 1-second heartbeat, battery level reporting. Background execution with foreground service (Android) / BLE background mode (iOS). Free and open source.
Loud siren + flashing light (GPIO from Pi). Optional: integration with RIM drive controller for auto-stop and return.
$15 BLE beacon on exterior door frame. Phone detects proximity when door opens. Warns if phone is left inside.
Total cost: Raspberry Pi 4 ($55) + GPS hat ($25) + 3× ESP32 ($15) + siren ($10) + optional door beacon ($15) = ~$120 total, unlimited crew
The deadliest MOB scenario is the unnoticed fall — especially at night, especially single-handed. Current solutions cost hundreds per person and require wearing a dedicated device that people forget. A free phone app + $120 base station that works on any yacht, that people will actually use because it's already in their pocket, could be the most impactful marine safety innovation in decades. The key is making it reliable enough that people trust it, and simple enough that they actually use it.
In the US, the Coast Guard reports roughly 150–250 boating fatalities per year where "falling overboard" was the primary cause. Globally, it's likely 500–1,000+ annually across recreational and commercial fishing. On family cruising yachts specifically, the number is smaller (perhaps 20–50 globally) but the fatality rate per incident is shockingly high — around 40–60% — because the fall is often unwitnessed and the person isn't found in time.
Yes, with BLE-only mode. BLE advertising at 1-second intervals costs roughly 1–3% battery per hour, similar to having an Apple Watch connected. A phone at 80% charge would last 20–30 hours. Wi-Fi mode is heavier (5–15%/hr) and would need a midday top-up. Zero-G accelerometer mode should be off by default. The app should show a battery impact estimate and warn at 20%.
Yes. On Android, the app runs as a foreground service with a persistent notification — the OS won't kill it. On iOS, the app uses BLE background mode (peripheral/advertising) which iOS allows to continue. Both platforms have settings the user can adjust. The app's setup wizard should guide them through it. This is a solved problem — Navionics, Strava, and many other apps already maintain background execution reliably.
Yes, the core functionality is straightforward. Claude Code or Cursor could absolutely write a working "phone sends BLE heartbeat, server detects loss, sounds alarm" prototype in a few hours. The phone app is the harder part — background BLE on iOS requires careful native module configuration that AI tools might get 80% right. The server is easy (Python + Bleak + FastAPI). The hard parts aren't the code — they're the edge cases: false alarm handling, BLE reliability, battery optimization, and cross-platform background execution. Plan 2–4 weeks for a reliable beta, not a weekend.
Phone app: Cursor or Claude Code → React Native (Expo) with TypeScript. Key libraries: react-native-ble-plx, react-native-background-actions, expo-router.
Server: Cursor → Python with bleak (BLE), fastapi (API), gpsd (GPS), gpiozero (alarm output).
ESP32 receivers: PlatformIO + Arduino framework, programmed in C++. Very simple — scan for BLE advertisements from registered phone MACs, forward signal strength to Pi over Wi-Fi/MQTT.
Night and day. You remember the pain of Java ME — signing certificates, device fragmentation, J2ME emulators, deployment nightmares. Modern development with Expo + React Native is: npx create-expo-app mob-app, write code, scan QR code with your phone, and it's running. AI tools like Cursor can generate the entire app structure and you just iterate. Deploying to app stores is still a bit painful (Apple review process) but the "Hello World" to "working prototype" path is maybe 30 minutes now instead of 3 days.
Partially, yes — but never as a complete, free, open-source package. CrewWatcher is the closest commercial product but it requires proprietary hardware ($200–400). Various GitHub projects exist but are hobbyist quality. No one has shipped the "just install this free app on your phone and this free software on a Pi" version. That gap is real and valuable. The closest spiritual ancestor is probably the AIS MOB standard itself — it started as a grassroots effort to make man-overboard detection affordable and interoperable. Your project could do the same for the phone-based approach.
The core idea — phone heartbeat → signal loss detection → alarm → auto-return — is sound. The technology exists. The code is within reach of AI-assisted development. What's needed is careful attention to false alarms, battery management, and real-world testing. An open-source project could start saving lives within a year.