Here's the HTML-formatted response:
```html
Man Overboard Safety System for Seastead
A Cheap, Open-Source Man Overboard (MOB) System
How Many People Die from Man Overboard Each Year?
Exact global numbers are hard to pin down because MOB events are logged differently across jurisdictions, but here are the commonly cited figures:
- United States (recreational boating): The U.S. Coast Guard typically reports 150–200 deaths per year where falls overboard are the primary cause. Falls overboard are consistently the #1 or #2 cause of recreational boating fatalities, responsible for roughly 20–25% of all boating deaths.
- Commercial fishing (US): Roughly 10–30 deaths per year, with MOB being the leading cause of fishing fatalities.
- Cruise ships: About 15–25 MOB events per year industry-wide, with survival rates around 17–25%.
- Global estimate: When you add recreational, commercial fishing, cargo crew, and passenger vessels worldwide, the total is commonly estimated in the range of several thousand deaths per year — one frequently cited figure from the maritime industry is that ~1,000+ seafarers alone are lost overboard each decade, plus many more recreational boaters globally.
- The often-quoted "survival rate" varies: in cold water, mortality can exceed 50%; in warm water with a PFD and quick recovery, survival rates are much higher.
So yes — this is a real problem affecting hundreds to thousands of lives per year, and a cheap software solution could meaningfully reduce it.
Your System Design — Review
Your design is well thought out. Let me address each part:
Phone-based "heartbeat" check-in
This is a very sound approach. Key strengths:
- Leverages hardware everyone already carries.
- 2.4 GHz RF (Wi-Fi/BT) is indeed heavily attenuated by water — signal drops by tens of dB in the first few cm of submersion. This gives you a near-instant "submerged" detection even without accelerometer triggers.
- Your proposed 3 s alarm / 6 s auto-stop timing is reasonable — fast enough to matter, slow enough to tolerate normal packet loss.
- Recording GPS at the base station (not the phone) saves phone battery.
Zero-G / fall detection as optional feature
Correct — continuous high-rate accelerometer sampling drains battery noticeably. But iOS and Android both have low-power motion coprocessors (Apple's Motion Coprocessor, Android's Sensor Hub) that can run fall-detection heuristics with minimal main-CPU wakeups. Apple Watch already does this commercially. On a phone it's feasible with maybe 5–15% extra daily battery drain.
Can you prevent the OS from sleeping the app?
Yes, but with caveats:
- iOS: Apps cannot simply "never sleep." However, a "Bluetooth LE peripheral" background mode, location background mode, or audio background mode can keep the app running indefinitely. The cleanest trick for safety apps is to register as a BLE peripheral or use significant-location updates. Users may also need to disable "Background App Refresh" overrides and battery optimization for that app.
- Android: Foreground services with a persistent notification can run indefinitely. The user must also add the app to the "not optimized" battery allowlist (Settings → Battery → App standby exceptions). On aggressive OEMs (Xiaomi, Huawei, OnePlus) this can be tricky — dontkillmyapp.com documents the quirks per manufacturer.
Battery impact
| Mode | Approximate extra daily drain |
|---|
| BLE heartbeat every 1 s, no GPS on phone | 2–5% |
| Wi-Fi heartbeat every 1 s (as fallback) | 8–15% |
| Add continuous accelerometer via sensor hub | +3–8% |
| Add continuous accelerometer via main CPU | +20–40% (bad — avoid) |
Verdict: most phones will easily make it through a full day on one charge with the BLE-first design. Your fallback-to-Wi-Fi plan is correct.
Door sensor without phone nearby
Good optional add-on. A $5 ESP32 with a reed switch + BLE scanner can detect "door opened" and "no registered phone within X meters" and raise an alert. Very cheap to add.
What about phone going dead?
Yes — treat "missed check-ins for > N seconds" and "phone reported low battery" as separate states. The app should nag at 30% and warn the base station at 15%. The base station should escalate to a non-emergency alert (not a crash-stop) if a phone goes offline while the user is known to be inside.
Can AI Write This Today?
Yes, absolutely. This is well within what Claude Code, Cursor, or similar tools can produce. A working prototype is probably 1–2 weekends of effort with AI assistance.
Recommended tooling
- Cross-platform app:
Flutter (Dart) or React Native. Flutter is probably the better choice — excellent BLE libraries (flutter_blue_plus), good background execution support, one codebase for iOS and Android.
- Alternative:
Expo / React Native if you prefer JavaScript.
- Server:
Node.js or Python (FastAPI) on a Raspberry Pi, or any existing onboard computer. A Pi 4 at $50 is plenty.
- Transport: MQTT over Wi-Fi for heartbeats (lightweight, loss-tolerant), BLE advertising as the primary "proof of life" channel.
- Alarm: Simple GPIO-driven siren + screen notification + interface to the boat's autopilot (NMEA 2000 / SignalK) for the auto-stop feature.
"Hello World" for a Flutter app today is literally flutter create myapp && flutter run. With an AI pair-programmer, you can go from zero to a functioning heartbeat prototype in a few hours.
Would Existing Yachts Have a Computer to Run This?
Many already do:
- Yachts with SignalK servers (often on a Raspberry Pi) — increasingly common.
- Boats with Garmin, Raymarine, or B&G chartplotters — these are closed systems, but a companion Pi can sit alongside.
- Starlink-equipped yachts almost always have a Wi-Fi router and often a small NAS or mini-PC.
For boats without any computer, a $50–$100 Raspberry Pi + siren + small touchscreen would be a complete solution. The software being free/open-source means the total cost to add MOB protection to any boat is under $150.
Has This Been Done Before?
Yes — there are several commercial and a few open-source efforts. Important to know, so you don't reinvent everything:
Commercial products
- OLAS (Exposure Marine): Probably the closest commercial analog. BLE tags worn by crew; when a tag goes out of range, the app alarms and records GPS. A "kill cord" version cuts engines automatically. Works with phone app or dedicated base. ~$100–200 per tag.
- Sea-Tags / MOB+: BLE man-overboard tags that trigger DSC distress calls through the VHF.
- ACR OLAS Guardian / CrewWatcher: Similar BLE-tag-plus-app products.
- AIS MOB beacons (e.g., Ocean Signal MOB1): Not phone-based — these are dedicated PLBs that activate on water contact and broadcast AIS position. Excellent but $300+/person.
Open-source / DIY
- SignalK community has several plugins for MOB handling and AIS MOB integration.
- OpenCPN (open-source chartplotter) has MOB plugins.
- A few hobbyist GitHub projects exist for ESP32-based MOB tags, but no widely adopted phone-app open-source standard exists.
Gap / opportunity: There does not appear to be a well-maintained, free, open-source, phone-based MOB system that integrates with open marine platforms like SignalK. Your project would fill a real niche.
Things to Be Careful About
- False alarms kill trust. The #1 reason existing systems get turned off. Tune the timing carefully, allow a "going below decks" mode, and make silencing easy but logged.
- RF dead zones on the boat. Metal masts, engine rooms, and the galley can block BLE/Wi-Fi. Test with real hardware; plan for multiple BLE access points / Wi-Fi APs.
- OS battery killers. iOS and aggressive Android OEMs will sleep background apps. Bake a "health check" into the app so the base station knows if a phone is misconfigured.
- Phone waterproofing. Modern phones are IP68 but only for brief immersion. Good news: you only need the signal to drop — the phone doesn't need to survive.
- Auto-stop safety. Automatically stopping and reversing a vessel can itself be dangerous (propeller strike risk if the person is near the boat). Consider: alarm first, stop only, and require human confirmation before reversing. Your 3 s alarm / 6 s stop timing is fine; be more cautious about automated reversing.
- Single point of failure. If the base station crashes, everyone is unprotected silently. Add a watchdog and a "heartbeat to the heartbeat" — e.g., one phone also monitors whether the base is alive.
- Clock skew. Phones and base must agree on time to within ~1 s. Use NTP.
- Privacy / logging. Record positions locally; don't ship them to a cloud unless the user opts in.
- Cold water. Even a 30-second recovery is tight in <10 °C water. Your seastead operating area matters.
- Regulatory: Don't market it as a replacement for SOLAS-mandated equipment (PLBs, AIS MOB). It's a supplement.
Summary
- MOB kills hundreds in the US alone and likely thousands globally per year — real problem.
- Your design (BLE-first heartbeat, Wi-Fi fallback, base-station GPS logging, staged alarm→stop response) is sound.
- Battery impact can be kept to <~5% per day with BLE heartbeats.
- Both iOS and Android can be configured to keep the app alive, with some per-platform effort.
- AI coding tools (Claude Code, Cursor) make the initial build a weekend-scale project — Flutter + a Raspberry Pi MQTT server is a good stack.
- Commercial analogs exist (OLAS, CrewWatcher) but no strong open-source phone-based offering — room for a real contribution.
- Watch out for false alarms, RF dead zones, OS battery optimizations, and the safety of automated stop/reverse behaviors.
This is very much worth doing, and worth doing before the seastead is built — it's a standalone gift to the boating community.
```