Anyone running Meshtastic on their boat? Looking for real-world experience

[Skipper Don]

Hi all,
I'm working on an open-source marine safety project — a short-range collision avoidance system built around a Raspberry Pi that fuses several sensor layers: WiFi-based proximity sensing, camera, AIS, and LoRa mesh radio. The goal is to detect the hazards conventional instruments miss — kayaks, paddleboards, deadheads, persons in water — things with no radar return and no AIS transponder.
For the mesh radio layer I'm planning to use a Heltec V3 node running Meshtastic firmware (915 MHz for Canada). The idea is cooperative hazard sharing: if your boat detects something at close range, it broadcasts an anonymised alert over the LoRa mesh so other equipped boats in the area can see it on their chart plotters, even before they're close enough to detect it themselves.
Before I build further I'd love to hear from anyone already running Meshtastic on their boat. Specifically:

1. Real-world range — what are you actually getting? I understand line-of-sight is everything on the water. Are you seeing the often-quoted 5–10 km in practice, or is it more like 1–2 km between vessels at low freeboard? Does antenna height make a meaningful difference at mast vs. deck level?

2. Reliability in a marine environment Salt air, vibration, water ingress — what hardware have you found holds up? Any recommendations on weatherproofing nodes for a permanent install?

3. Integration with chart plotters and navigation software Has anyone got Meshtastic vessels showing up in their chart plotter as trackable contacts? I'm particularly interested in the signalk-meshtastic plugin path — does it work reliably in practice, or are there gotchas?

4. The update rate problem One thing I'm designing around is that LoRa mesh position updates are slow (~60 seconds between fixes). I'm treating LoRa contacts as long-range awareness only — not suitable for CPA/TCPA calculation. Is that how others are using it, or have you found ways to push faster updates?

5. Mixed fleets — non-Meshtastic boats For the cooperative picture to work, other boats need nodes too. How have you found adoption among other cruisers? Is there a critical mass in any cruising areas yet?

Not looking to replace VHF or AIS — this is purely a supplementary layer for the hazards neither covers. Curious what the practical experience looks like before I commit to the hardware spec.

 

[fallguy]

First time I heard of it, so not a user, but offshore hazards are a real concern.

My only comment as a mariner is so many hazards are dynamic and so often vessels far apart that sharing dynamic hazards is very different than sharing fixed hazards. The location of a moving kayak 40 seconds ago can change from the edge of the riverbank to the middle of the channel.

I would be very careful in dev to try and differentiate the two; otherwise you are sharing errant data and that could become causal; especially at the aforementioned update rate. A target known to be moving should be identified differently, imo.

Not only changing, but perhaps the kayak on the riverbank was leaving. Now you are showing a hazard no longer there that was in a different location before; so technically there is no hazard at all, but will the system show one? This is a lot like driving on the interstate and the annoying ‘parked car’ still there question that pops on your screen. As a boat captain, I don’t want to have to tell the system, nope, the kayak is gone.

Anyhow, hope I’ve at least offered some humor. Good luck.

 

[Skipper Don]

fallguy, you've put your finger on exactly the hardest problem in this whole design — and it's one I've been wrestling with. You're absolutely right that sharing a stale position for a dynamic target isn't just useless, it could actively mislead another skipper.

The way I'm approaching it is a time-to-live (TTL) decay model. Every contact broadcast over the mesh carries a timestamp and a target-type flag (moving vs. stationary). On the receiving end, moving contacts start fading on the display within ~90 seconds of the last update and disappear entirely after 3–4 minutes — much like how AIS targets ghost out when you lose the signal. Stationary hazards (deadheads, mooring buoys, debris fields) get a longer TTL but are flagged differently so the skipper knows the distinction.

The update rate problem you're implicitly describing is real: LoRa mesh at 60-second intervals is genuinely too slow for CPA/TCPA math on a fast-moving kayak. My design intent is that mesh contacts are early-awareness prompts — 'something was here recently, eyes up' — not precision collision avoidance targets. The close-range camera and WiFi sensing layers handle the actual geometry once a vessel is inside ~500m.

Your 'parked car' analogy is spot on and I'm going to steal it for the project documentation if you don't mind — it's a perfect way to describe the stale-contact problem to other contributors.

 

[fallguy]

The way that car mapping software work is it asks of the ‘hazard’ is still there.

The irony is that the act of clearing the hazard at speeds of 75mph is more hazardous than the parked car.

After the novelty of ‘helping’ update the system wears off, it is just a headache.

In boating one day, I looked down at my phone to find the name of the lock I was coming up on. I was traveling at 16kts and click on my iphone map and zoomed in on the lock. In that amount of time, I got disoriented enough and headed to the wrong side of the channel buoy and took my boat into the shallow and hit sand. Fortunately, no harm, but I could have taken out the gear and I hit sand. Point is, I’m not updating your software for you, not taking the risk. What I would like more would be prior tracks. This, of course, presents other risks, but knowing the path of most prior vessels doesn’t highlight the hazards, but highlights the road, if you will.

This is especially true for the most common haz. Shallow water.. In many places here, the shallows are 10” deep and boats have the tracks and know where to go, but yesterday, I did not. Had to push the boat for several hundred yards through 5” of water. Ugh..

 

[Skipper Don]

That is an incredibly valuable cautionary tale, fallguy, and it highlights a critical design commandment for this project: zero user-interactivity.
The future of marine situational awareness cannot rely on a skipper staring at a screen to manually report or clear hazards. Distraction is an accident vector in itself. Instead, this system is being engineered for fully passive telemetry generation.
Here is how the automated architecture addresses your points:

• Machine-to-Machine (M2M) Automation: The system acts as a decentralized sensor network. If Boat A’s computer vision layer detects a kayak, it logs and broadcasts that data automatically. No human input is required to report it, and no human input is required to clear it.
• Algorithmic Decay over Manual Interaction: Rather than asking a skipper if a hazard is "still there," the edge-computing layer on the receiving boat handles the cleanup. It continuously calculates probability clouds based on the target’s last known velocity and time-elapsed, naturally fading the target out as the data loses confidence.
• Dynamic Track Mapping: Your point about "highlighting the road" is exactly where the secondary phase of this project is heading. Because Meshtastic nodes can passively relay anonymised telemetry, we can build localized, crowdsourced "heatmaps" of safe passage tracks in real-time, effectively charting dynamic sandbars and safe channels based on recent fleet behavior.

The ultimate goal is a silent, automated safety envelope that runs in the background of your existing chart plotter—giving you the predictive data you need without ever asking you to take your eyes off the water.