From the Neutral Zone to the Neutral Waters: Building a Mesh-Based Collision Avoidance System for Small Boats
If you’re of a certain generation, you remember the Star Trek: The Next Generation episode “Redemption II.” Commander Data — the Enterprise’s android officer — is given his first starship command, the USS Sutherland. His mission: anchor a tachyon detection grid stretched across dozens of Federation starships, each ship sharing sensor data across the network to detect Romulan vessels slipping through the blockade under cloak. No single ship could see far enough alone. Together, they created something no individual sensor could — a picture of the invisible.
I watched that episode and didn’t know it then, but I was watching the concept of wireless mesh networking play out on a starship bridge.
Act I: From Science Fiction to Prototype
Fast forward about fifteen years. I found myself working with Locustworld’s AODV (Ad-hoc On-Demand Distance Vector) wireless mesh system — one of the early real-world implementations of exactly the idea Data had deployed in the neutral zone. What I learned quickly was the core promise of mesh: you don’t just extend range, you increase bandwidth and resilience as you add nodes. Every device that joins the mesh isn’t just a consumer of the network — it’s also a relay, a contributor, a force multiplier. The network gets smarter and stronger the more participants it has. That’s not how WiFi or cellular works. That’s something different.
That experience planted a seed.
Act II: WiFi That Can See You
Less than five years ago, I came across a research paper that genuinely stopped me cold.
The paper demonstrated that WiFi signals alone — with no camera, no radar, no dedicated sensor — can detect people and infer their physical state. Not just “someone is in the room.” The system could determine whether a person was walking, sitting, standing, or bending over — purely by analysing how their body absorbed, reflected, and distorted the radio waves passing through the space around them.
Think about what that means for a moment. The invisible electromagnetic environment around your boat is already full of signal. Every WiFi access point, every device pinging the network, is casting a radio shadow on everything it touches. The right processing layer can read those shadows.
This is sometimes called WiFi sensing or passive radar, and it has moved rapidly from academic papers to commercial applications in the years since. It doesn’t require line-of-sight. It doesn’t require the target to carry any device. It works in the dark, in fog, in rain.
For a boat operator trying to detect a kayaker in the water at night, that is a significant thing.
Act III: LoRa and the Long Reach
Meanwhile, a parallel technology thread was developing. LoRa (Long Range) radio — a low-power, low-bandwidth radio modulation technique — began finding its way into open-source projects. The most relevant for our purposes is Meshtastic, an open-source firmware that turns cheap LoRa hardware (nodes costing $30–$80) into a self-healing mesh network requiring no SIM card, no subscription, and no internet infrastructure. Messages and GPS positions hop between nodes across ranges of 2–10 km depending on antenna height and terrain.
For offshore and coastal sailors, this fills a genuine gap. AIS covers vessels with transponders. VHF covers voice. But the hazards that sink small boats — kayakers, paddleboards, floating debris, persons in water — have no AIS signature, no radar return, and no VHF radio. They are invisible to every conventional navigation aid aboard your boat.
LoRa mesh doesn’t solve that alone. But it is a communications backbone that could carry hazard alerts between equipped vessels — the beginnings of a cooperative sensor network.
Act IV: Putting It Together — The WiBoat Concept
So here is where I find myself now, staring at these three threads — mesh networking, WiFi sensing, and LoRa — and asking whether they can be woven together into something useful for the average recreational boater.
The concept I’m developing — working name WiBoat — is a standalone system that attaches to d3kOS (the marine operating system built on OpenPlotter and Signal K) and fuses multiple sensor layers to detect what conventional instruments miss:
Sensor Layer 1 — WiFi Proximity Sensing Passive analysis of WiFi signal distortion to detect nearby physical objects and persons. No camera. No active transmission. Works in any visibility condition.
Sensor Layer 2 — Camera / Computer Vision Optical detection for daylight and low-light conditions. Object classification — boat, kayak, person in water, debris.
Sensor Layer 3 — AIS The existing standard. Covers vessels with transponders — commercial ships, larger recreational boats. Does not cover the hazards that matter most at close range.
Sensor Layer 4 — LoRa Mesh (Meshtastic) The cooperative layer. If your boat detects a hazard, it can broadcast an anonymised alert to all equipped boats in the mesh. Vessels beyond your sensor range can receive advance warning before they are close enough to detect the hazard themselves.
This is the tachyon grid. Each boat is a node. The collective picture is better than any individual sensor.
The Standards Your System Needs to Respect
This is where vision meets regulation, and it’s worth being clear-eyed about the framework any collision avoidance system operates within.
COLREGS (COLlision REGulations) — the International Regulations for Preventing Collisions at Sea — are the foundation. Rule 5 requires every vessel to maintain a proper lookout “by sight and hearing as well as by all available means appropriate in the prevailing circumstances.” A sensor fusion system directly supports this obligation; it doesn’t replace the human watch.
Rule 7 requires vessels to use all available means to determine if a risk of collision exists, explicitly including radar if fitted. A WiFi/LoRa sensing layer fits naturally within this framework as an additional available means.
Rule 8 requires any action taken to avoid collision to be positive, made in ample time, and result in passing at a safe distance — which is exactly the design goal of early hazard detection.
On the data side, Signal K (the open marine data standard WiBoat is built on) and NMEA 2000 define how navigation data flows between instruments. Injecting WiBoat contacts into Signal K means they appear automatically in chart plotters like AvNav and OpenCPN alongside AIS targets — no separate display required.
For the LoRa layer, Industry Canada RSS-247 (for 915 MHz operation in Canada) governs the radio hardware. Meshtastic nodes operate as licence-exempt devices within these power limits. No ship station licence is required for the mesh layer, though operators with amateur licences can take advantage of additional capabilities.
The honest gap in the current standards landscape is that there is no formal standard for cooperative small-vessel hazard sharing over LoRa mesh. AIS has IEC 61993. Radar has IEC 62388. The mesh layer we’re describing is operating in advance of the standards, which is both the challenge and the opportunity.
Act V: Back to the Roots — and Commander Data
Here is the part that excites me most.
The individual boat capability is genuinely useful. But the real power emerges when multiple boats participate. Each additional equipped vessel in an anchorage, a race fleet, or a cruising area extends the sensor reach of every other vessel. A hazard detected by one boat — a kayaker invisible to radar, a person in the water — propagates through the mesh to every boat within range before they are close enough to be at risk.
This is not theoretical. It is the same principle Data used in the neutral zone: not one ship with a perfect sensor, but many ships each contributing imperfect but overlapping sensor coverage, collectively building a picture none could build alone.
And since we’re invoking Commander Data — an AI lifeform who used computational analysis to solve a problem his human colleagues had dismissed as impossible — it seems fitting that the analysis layer of this system should also be AI-driven. Not to replace the helmsman’s judgment, but to process the fused sensor data in real time: correlating WiFi signatures with camera detections, estimating bearing and closing speed, flagging contacts that exceed a collision risk threshold, and surfacing that information to the navigator in plain language.
The helmsman drives the boat. The AI watches the shadows.
Or, if you prefer the Star Trek framing: you handle the helm. Data handles the detection grid. And together, we keep the Romulans out of the neutral zone.
This is an active development project. If you’re running d3kOS / OpenPlotter and want to follow along or contribute, watch this space. I’ll be posting build notes, hardware specs, and code as the project develops.
Leave a Reply