Width: 3 panels × 10 in = 30 in (2.5 ft). Fits easily.
Center Void
Width: ~7.7 - 3.0 (legs) - 2.5 (walls) = 2.2 ft
Length: 44.6 ft
Volume: ~2000 cu ft. Ample for beams, flooring, thrusters, dinghy, batteries, mooring gear.
Key Engineering Notes:
Weight Budget: 62,000 lbs max. Target displacement 27,500 lbs. Structure + Battery (25% disp ≈ 6,875 lbs) + Outfitting must stay < 34,500 lbs lightship. Very achievable for aluminum/steel/composite.
Leg Draft: 14.5 ft total span, 50% submerged = 7.25 ft draft. Freeboard to floor = 7 ft (wall) + 1 ft (walkway offset) = 8 ft above WL. Good clearance.
RIM Drives: 6 × 1.5 ft dia. Fixed orientation + differential thrust is robust. Ensure thrust line aligns with Leg Center of Lateral Resistance (CLR) to minimize yaw moments during turns.
Heave Plates: Bolt-on is smart for shipping. Verify they don't interfere with RIM drive suction/flow at 2 ft up from bottom.
Mooring Screws: Helical anchors + tension legs work well in low tidal ranges (Caribbean). Ensure the "pull down 3 ft" stroke accounts for wave setup/surge, not just astronomical tide.
2. Man Overboard (MOB) Statistics & Risk Context
Global Fatality Data
Accurate global statistics are notoriously difficult because reporting standards vary (USCG, MAIB, BEAmer, recreational vs commercial). However, consensus estimates are:
Metric
Estimate
Source Context
US Recreational Boating Deaths (Annual)
~600–700
USCG Recreational Boating Statistics
US MOB Specific Fatalities
~150–200/year
~25-30% of total deaths. "Falls Overboard" is consistently #1 or #2 cause of death.
US MOB Events (Total)
~400–600 reported/year
Many non-fatal or unreported.
Fatality Rate (Given MOB Event)
30% – 50%
Your "nearly 50%" figure is accurate for unwitnessed or cold water scenarios. Witnessed, warm water, PFD worn drops to <10%.
Global Estimate (Commercial + Rec)
~1,000+ deaths/year
IMO / ILO estimates suggest vast underreporting in developing nations.
Why Your Seastead Reduces Baseline Risk
Stability: SWATH-like waterplane area (3 × foil chords) + wide beam (44 ft triangle) = extreme initial stability (GM). Roll angles < 2-3 deg in moderate seas.
Freeboard & Barriers: 7 ft walls + 3 ft walkway + railing = ~10 ft vertical barrier. Very hard to fall accidentally.
No Sail Handling: Eliminates #1 cause of MOB on yachts (working on foredeck/mast in rough weather).
Station Keeping: Dynamic Positioning (DP) via 6 thrusters holds position better than anchoring.
NOMINAL: Phone sends heartbeat (BLE preferred, WiFi fallback) every 1s. Server receives >95%. RSSI logged for rough proximity.
DEGRADED (Missed 1-2 beats): Server pings phone explicitly (BLE L2CAP ping or WiFi UDP). Phone replies immediately. No alarm.
ALARM (3s - 5s no contact): Audible/Visual alarm on Bridge/Phones. "Crew [Name] Signal Lost".
CONFIRMED MOB (6s - 10s + IMU Zero-G event):Auto-Stop Engaged. Thrusters: Zero forward, hold position (DP). Log GPS/Time of last RX.
RETURN MODE: Auto-navigate to "Last Known Position" (LKP) + Drift Model (current/wind). Activate MOB light/strobe on relevant leg.
RECOVERY: Manual override required to resume voyage.
4. Critical Technical Challenges & Physics
A. The "Water Curtain" Physics (2.4 GHz)
You are 100% correct: 2.4 GHz (WiFi/BLE) attenuation in seawater is ~100-150 dB/m. A phone submerging 0.1m (screen down) loses >10 dB instantly. At 0.5m depth, signal is gone (-80 to -90 dBm noise floor). Submersion = Instant Link Loss. This is a fantastic physical trigger—no software timeout needed for the "wet" detection.
B. The "False Alarm" Problem (The Killer Metric)
If the system alarms falsely once per week, the crew will disable it. You need < 1 false alarm per month (ideally per season).
Constraint: Requires accelerometer @ 50-100Hz. Major Battery Drain. (See Section 6).
Recommendation: Make this Opt-In / "High Risk Mode" (e.g., night watch, rough weather, solo). Default: Heartbeat only.
D. Positioning Accuracy (Where did they fall?)
GPS on Phone: Only works if phone has sky view (on deck). Below deck = no GPS.
Server Side: Seastead has GPS (cm-level RTK ideally). Log vessel position + heading + speed @ 1Hz.
LKP Calculation:LKP = Vessel_GPS_Position + (Vessel_Heading_Vector * Offset_To_Gate). If phone has GPS, average last 3 fixes.
Drift Model: Essential. Seastead drifts differently than a person in water (windage). Use onboard Wind/Current sensors or Starlink weather API.
5. Mobile OS Constraints: The "Background Execution" Wall
This is the single hardest part of the project. You cannot simply "run an app in the background forever" on modern iOS/Android.
Android (Easier, but Fragmented)
Mechanism:Foreground Service with FOREGROUND_SERVICE_TYPE_CONNECTED_DEVICE (BLE) or LOCATION (WiFi/GPS).
UI Requirement: Persistent Notification ("Virtual Lifeline Active - Tap to return"). Cannot be dismissed.
Doze Mode / App Standby: Foreground Service exempts you if user doesn't "Force Stop" or "Restrict Battery".
BLE Scanning/Advertising: Works well in Foreground Service. Android 12+ requires BLUETOOTH_CONNECT/BLUETOOTH_SCAN runtime permissions.
iOS (Much Harder, Strict)
No True Background Daemon: Apps are suspended seconds after backgrounding.
Allowed Background Modes:
CoreBluetooth Central/Peripheral: App can stay alive *only* if actively connected to a BLE peripheral (or advertising as one). Best Path: Seastead Mesh Nodes act as BLE Peripherals (GATT Server). Phone = Central. Maintains active connection = App stays alive.
Location Updates: "Always" permission + allowsBackgroundLocationUpdates. High battery drain. Apple rejects apps using this *only* for proximity if no user-facing map feature exists.
Background App Refresh: Opportunistic, ~minutes interval. Useless for 1s heartbeat.
State Restoration: If OS kills app (memory pressure), application(_:willFinishLaunchingWithOptions:) restores Bluetooth Central Manager. Must handle reconnection logic flawlessly.
"Never Sleep" Setting: Does not exist for 3rd party apps. User *cannot* force iOS to keep your app running. You must use the approved Background Modes.
Critical Architecture Decision: DO NOT use WiFi (UDP/TCP) as the primary keep-alive on iOS. WiFi radio powers down aggressively. USE BLE (Bluetooth Low Energy) GATT Connection.
Hardware Beacon Fallback: $10-20 nRF52840 dongle on lifejacket/PFD. 1 year coin cell. Zero phone battery impact. Highly Recommended for Non-Swimmers/Children/Solo.
7. Existing Solutions & Prior Art
You are entering a crowded space. Differentiation is key.
Product / System
Tech
Pros
Cons / Gap
OLAS (Exposure Lights)
BLE Tag + Phone App
Dedicated hardware tag (CR2477, 1yr). Loud alarm. Simple.
Tag only. No phone IMU. No auto-stop/return (no thruster interface). Range ~30m.
MOB+ / Kannad / SeaTags
AIS / DSC / 121.5 MHz / BLE
Sends AIS MOB message to ALL nearby ships + DSC distress. Satellite (Globalstar/Iridium) options.
Expensive ($300-$800). Requires external antenna. Hardware tag only. No "phone in pocket" convenience.
Apple Watch / Garmin / Pixel Watch
Fall Detection + LTE/Phone
Built-in IMU fall detection. Auto-dials EMS. Works globally (LTE models).
Requires watch ($300+). LTE subscription. Designed for EMS, not "Stop *this* boat". No vessel integration.
Raymarine / B&G / Simrad MOB
Proprietary RF (433/868/915 MHz) + MFD
Integrated into Chartplotter. Marks waypoint. Steers autopilot to waypoint (Return).
Requires specific brand ecosystem. Tags proprietary. No phone app. High power RF better range but bigger tags.
Standardized data bus. Python/Node/JS plugins. Runs on Pi. Perfect for your Server.
No standard "Phone MOB Client" plugin exists yet. You would write this.
Your Unique Value Proposition (UVP)
Software-Only (BYOD): Zero hardware cost for crew (uses phone).
Vessel Native Integration: Direct Thruster/DP Control (Stop/Return) — *Commercial systems only do "Mark Waypoint".*
Mesh Network Architecture: Solves the "Metal Hull Faraday Cage" problem better than single-point base stations.
Open Source / Open Data: Signal K standard. No vendor lock-in.
8. Development Feasibility with Modern AI Tools
Can Cursor / Claude Code / Copilot build this?
Yes, 80-90% of the boilerplate and logic. The remaining 10-20% (OS background quirks, BLE GATT state machines, Signal K integration) requires expert debugging.
Recommended Tech Stack (AI-Friendly)
Mobile App (Cross-Platform)
Flutter (Dart) — Best single codebase for iOS/Android BLE. flutter_blue_plus / flutter_reactive_ble plugins are mature.
React Native — react-native-ble-plx. Large JS ecosystem, AI writes TS well.
Native (Swift/Kotlin) — Only if you hit Flutter/RN background limits. AI writes Swift/Kotlin excellently now.
Seastead Server (Edge)
Signal K Server (Node.js) on Raspberry Pi CM4 / Jetson / Intel NUC.
Custom Plugin (TypeScript/JS): Handles BLE Mesh (via noble / bleno or bluez DBus), MOB State Machine, Thruster API.
Python (FastAPI) alternative if heavy ML (drift prediction) needed.
Firmware: Zephyr RTOS or ESP-IDF (C). AI writes C well for simple GATT servers.
Role: GATT Peripheral (Advertise "Seastead_Node_1"). Pipe RSSI/Connection events to Server via UART/WiFi/Thread.
Thruster Interface
Signal K steering/autopilot or propulsion/thruster/* paths.
Your RIM drives likely take CANopen / EtherCAT / Serial. Need a small gateway (Pi Pico / ESP32) to translate Signal K → Drive Protocol.
AI Prompting Strategy (Cursor / Claude Code)
# Example Prompt for Cursor Composer (Ctrl+I)
"Create a Flutter app 'VirtualLifeline' targeting iOS/Android.
Target SDK: Flutter 3.22+, Dart 3.4+.
Core Requirement: Maintain a persistent BLE GATT connection to a peripheral
with Service UUID 'seastead-mob-service' in the BACKGROUND indefinitely.
Files to generate:
1. `pubspec.yaml` with: flutter_reactive_ble, permission_handler,
android_foreground_service, background_fetch, workmanager.
2. `ios/Runner/Info.plist` keys: UIBackgroundModes (bluetooth-central, location),
NSBluetoothAlwaysUsageDescription, NSLocationAlwaysAndWhenInUseUsageDescription.
3. `android/app/src/main/AndroidManifest.xml`:
Foreground Service type 'connectedDevice', BLUETOOTH_CONNECT/SCAN permissions.
4. `lib/ble/ble_manager.dart`: Singleton managing connection state machine:
- Scan -> Connect -> Discover Services -> Enable Notifications (Heartbeat Char).
- On Disconnect: Immediate Reconnect + Exponential Backoff.
- Exposes Stream (Nominal, Degraded, Alarm, ConfirmedMOB).
5. `lib/ui/main_screen.dart`:
- Start/Stop Service Button.
- Shows RSSI, Battery %, Connection State.
- 'High Risk Mode' Toggle (enables Accelerometer 50Hz stream).
6. `lib/services/foreground_service.dart`:
- Android: startForeground with Notification Channel 'MOB_MONITORING'.
- iOS: Relies on Bluetooth Central Background Mode (no notification needed).
7. Unit tests for State Machine logic (mock BLE)."
Where AI Will Struggle (Human Required)
iOS Background Bluetooth Debugging: App works on Simulator/Dev build, dies 3 mins after TestFlight/App Store install. Entitlements/Provisioning profile issues. Requires physical device + Console.app logs.
BLE Mesh Routing: Phone connects to Node A. Walks to Node B. Handover logic (disconnect A -> connect B) without triggering MOB alarm.
Thruster Safety Logic: "Auto-Stop" code must be formally verified / fail-safe (watchdog). If Server crashes, thrusters must NOT ramp to 100%.
9. Recommendations & Implementation Roadmap
Phase 0: Safety First (Week 1-2) — Hardware Beacons
Don't wait for software. Buy 10x nRF52840 Dongles (MakerDiary / Adafruit) or M5Stack Atom Lite + Base. Flash standard eddystone / ibeacon or custom GATT firmware. Hand out to crew TODAY. Integrate detection into existing Chartplotter (Raymarine/B&G/Garmin support generic BLE MOB tags now) or a simple Pi + Signal K script. This saves lives *now*.
Phase 1: The "Virtual Lifeline" MVP (Month 1-2)
Server: Signal K on Raspberry Pi 5. Plugin: signalk-mob-ble.
Nodes: 4x ESP32-C3 (Powered by Ship 12V/24V via USB-C PD). Firmware: GATT Server advertising "Seastead_Node_[1-4]". UART/TCP to Pi.
App (Flutter): Foreground Service + BLE Central. Heartbeat 1s. Alarm at 5s loss. Logs GPS/Time to Server.
Integration: Signal K → Your Thruster Gateway (CAN/Serial) → "MOB Stop" Command.
Phase 2: Hardening & UX (Month 3-4)
iOS App Store Deployment (TestFlight → Production). Handle "Location Always" permission rationale for Apple Review ("Maritime Safety").
Drift Model Integration (NMEA 0183 MWV/VDM + GPS → Predicted Person Position).
Phase 3: Community & Open Source (Month 6+)
Publish Flutter App (Apache 2.0 / MIT).
Publish Signal K Plugin (npm).
Publish ESP32 Firmware (PlatformIO).
Document "Seastead MOB Standard" for other builders.
Critical "Gotcha" Checklist for Your Seastead Build
RF Shadowing: Your 3 Legs + Central Triangle create complex multipath. Place Mesh Nodes: 1x Bow (Center), 1x Port Aft, 1x Stbd Aft, 1x Mast Top (if any) / High Point. Test with VNA / Spectrum Analyzer.
Power for Nodes: Run Cat6 (PoE+) or 12V/24V DC to node locations during build. Retrofitting wiring in foam-cored composite is miserable.
Thruster "MOB Stop" Logic: Implement in Thruster Firmware (Watchdog). Signal K sends "MOB_ACTIVE=true" @ 10Hz. If message stops > 0.5s → Thrusters revert to "Station Keep" or "Stop" autonomously. Do not rely on Pi/Server uptime for safety stop.
Legal/Liability: Add EULA: "Aid to navigation, not substitute for watchkeeping. Not USCG/IMO certified."