Your idea is directionally good: a local “crew presence” system using phones or small wireless beacons could detect a possible man-overboard event quickly, sound an alarm, mark the vessel position, and help the vessel stop or return. It is especially attractive for your seastead because the structure should be more stable than a normal yacht, does not require people to go outside to handle sails, and can potentially stop using electric thrusters.
However, for a life-safety system, ordinary phones should be treated as a useful extra layer, not the only layer. Phones have operating-system restrictions, battery issues, waterproofing issues, RF blind spots, and user-behavior problems. A robust system would ideally combine:
There is no single global database that cleanly answers “family yacht man-overboard deaths per year.” The statistics are split among recreational boating, commercial fishing, sailing, racing, ferries, cruise ships, and national reporting systems. Also, many reports categorize the accident as “fall overboard,” “drowning,” “capsizing,” “fall on vessel,” or “unknown.”
For the United States, the U.S. Coast Guard recreational boating statistics are a useful reference. In recent years, total U.S. recreational boating deaths have usually been in the several-hundred-per-year range. “Falls overboard” are commonly one of the leading accident types and are often responsible for roughly 150 to 180 deaths per year in U.S. recreational boating. That includes all recreational vessel types, not only family sailing yachts.
Worldwide, the number is certainly higher, but because reporting is inconsistent, a careful answer would be: hundreds per year globally at minimum, and likely more if small-craft, commercial, and unreported cases are included.
The basic concept would be:
That is a very reasonable architecture. A practical timing model might be:
| Time since last valid check-in | System response |
|---|---|
| 0 to 2 seconds | Normal. Ignore one missed packet. |
| 3 seconds | Local warning: “Crew tag missing.” Log GPS, camera snapshots, heading, speed, wind, and thruster state. |
| 5 to 6 seconds | Full MOB alarm. Stop vessel if safe. Mark MOB location. Notify crew. Turn on exterior lights and cameras. |
| 6+ seconds | Hold station or execute a carefully designed recovery maneuver. Avoid backing directly over the person. |
Your observation is mostly correct: 2.4 GHz radio signals used by Bluetooth and Wi-Fi are strongly attenuated by water. If a phone or beacon is submerged, the signal will usually disappear almost immediately.
This is a useful property. But there are edge cases:
So wireless dropout is useful, but the system needs filtering, multiple receivers if possible, and a false-alarm management strategy.
A phone-only system is attractive because people already own phones. But for a safety system, a dedicated wearable beacon is much more reliable.
| Feature | Phone app | Dedicated BLE MOB tag |
|---|---|---|
| Cost | Very low if people already have phones. | Additional hardware cost, often tens to hundreds of dollars per person. |
| Battery life | Variable; depends on OS, Wi-Fi/BLE use, screen, GPS, and other apps. | Can last weeks, months, or years depending on design. |
| Waterproofing | Modern phones are water resistant but not ideal as life-safety beacons. | Can be designed to be waterproof and worn on a lifejacket. |
| Operating-system restrictions | Significant, especially on iOS background operation. | No phone OS restrictions if the tag simply advertises BLE. |
| User behavior | People forget phones, leave them charging, silence them, or put them in bags. | Can be clipped to PFD, wrist, belt, or harness. |
| Reliability | Good as a supplementary layer. | Better as the primary local MOB detector. |
A strong open-source project could support both:
Battery impact depends heavily on the method used.
| Method | Likely battery impact | Comments |
|---|---|---|
| BLE advertising/check-in every 1 second | Low to moderate | Usually acceptable for a day, but iOS background behavior may limit how aggressively this can be done. |
| BLE connection with periodic heartbeat | Low to moderate | Often the best phone-based option if the OS permits reliable background operation. |
| Wi-Fi heartbeat every 1 second | Moderate | May be acceptable, but can prevent the phone from sleeping deeply. More drain than BLE. |
| Continuous GPS on the phone | High | Probably unnecessary because the vessel computer can record vessel GPS. Avoid if possible. |
| Continuous accelerometer/gyroscope monitoring | Low to moderate on some phones, but unreliable in background | Motion coprocessors are efficient, but app access in the background is restricted. Also, fall detection from a phone in a pocket is not always reliable. |
| Screen kept on / app forced foreground | High | Not desirable for normal use. |
If the app uses BLE efficiently and does not use continuous GPS, most modern phones should still make it through a day on one charge, especially if they start with a healthy battery. But if the app uses frequent Wi-Fi, continuous sensors, or fights the operating system to stay alive, the battery impact can become noticeable.
A practical target would be:
On Android, it is possible to improve reliability by using:
However, Android phone manufacturers vary widely. Some aggressively kill background apps unless the user changes settings. So Android can work, but setup instructions need to be very clear.
On iOS, there is no simple universal “never put this app to sleep” setting. Apple allows some background modes, including Bluetooth-related modes, but background behavior is still controlled by iOS. You can build an app that uses CoreBluetooth background capabilities, but you cannot assume it will behave exactly like a foreground app sending a message every second forever.
This is one of the biggest reasons a dedicated BLE tag is attractive. The phone can be a display/configuration device, while the tag does the simple reliable transmitting.
The idea of sending a “zero-G event” before the phone hits the water is clever, but it may not be reliable enough as the main trigger.
Issues include:
A better approach is to treat motion detection as an optional early-warning layer, not the main safety mechanism.
Some would, many would not.
Modern yachts may have:
But most chartplotters do not allow arbitrary third-party server code to run directly on them. A more realistic open-source setup would use:
The cheapest practical hardware package could be:
So the software could be free/open-source, but a reliable installation would still usually need some hardware.
AI coding tools such as Claude Code, Cursor, GitHub Copilot, ChatGPT, and similar tools can absolutely help build a prototype. They are now very good at generating:
But there is a big difference between “prototype works at the desk” and “life-safety marine system works reliably in spray, sun, vibration, poor RF conditions, low battery, OS updates, and panicked human use.”
AI can make it much easier to get started, but the project would still need:
The phone app could be built in:
For a serious safety-related app, native Swift and Kotlin may be more reliable than a cross-platform framework, especially for Bluetooth and background operation. But Flutter or React Native may be faster for an early prototype.
The vessel computer could run:
Python is probably the easiest for open-source contributors and Raspberry Pi use. Go or Rust may be better for a hardened final service.
Useful integrations:
A robust system should not panic on one missed packet. It should use a state machine.
CONNECTED
- receiving regular heartbeats
SUSPECT
- missed heartbeats for 2-3 seconds
- increase scan rate
- ask device to respond
- log exact time and vessel GPS
ALARM
- missing for 5-6 seconds
- sound loud alarm
- mark MOB position
- stop vessel if safe
- alert all crew devices
RECOVERY
- lights/cameras on
- display bearing/range to MOB mark
- deploy flotation if available
- hold station or execute rescue maneuver
RESET
- requires human confirmation
- logs event for later analysis
The system should also have a “dock mode” or “maintenance mode” so it does not alarm constantly when people walk away from the vessel.
Yes, people have already built systems with similar goals. Examples include:
| Product / category | Description |
|---|---|
| ACR OLAS / Exposure OLAS | Uses wearable tags and receivers/apps to detect when a crew member is separated from the vessel. Some versions can trigger alarms and engine kill functions. |
| Fell Marine MOB+ | Wireless engine kill switch system. Common on powerboats. If the wearer falls away, the engine can be stopped. |
| Sea-Tags | Wristband/app-style MOB alarm concept using a smartphone connection. |
| Raymarine LifeTag | Older wireless crew-overboard alert system integrated with Raymarine equipment. |
| CrewWatcher | Bluetooth-based crew overboard alarm system associated with smartphone use. |
| AIS MOB beacons | Devices such as Ocean Signal rescueME MOB1, ACR AISLink, McMurdo/Kannad devices, and similar units transmit an AIS MOB target that nearby vessels can see. |
| DSC MOB / PLB devices | Some personal beacons can send distress messages by DSC, AIS, satellite, or combinations thereof. |
| Apple Watch / smart watches | Can provide fall detection and emergency calling in some situations, but they are not a complete marine MOB system by themselves. |
The existence of these systems is encouraging. It means the concept is valid. But it also shows that the hard part is not merely writing the app; the hard part is making it reliable and easy enough that people actually use it every time.
Yes. This could be a very worthwhile open-source marine safety project. The best open-source version might not try to replace commercial AIS/PLB devices. Instead, it could provide a cheap local layer of protection:
The first prototype could be simple:
That is very achievable with modern tools and AI assistance.
Your concept is valuable and practical, but the safest version should not rely only on phones. Phones are excellent as an additional layer and user interface, but dedicated waterproof wearable BLE tags are likely better for the core detection function.
A simple open-source MOB alarm using BLE, Wi-Fi, a Raspberry Pi, and vessel GPS could be built now, before the seastead exists. It could help ordinary yachts too, especially if it integrates with existing tools like Signal K and OpenCPN. AI coding tools can greatly reduce the pain of getting started, but extensive real-world testing is essential before trusting it as a life-safety system.
```