Signal K is an open source server / data format for marine electronics, often paired with OpenPlotter for building custom nav and monitoring systems with web standards (JSON, Websockets and HTTP).
"web standards" have extremely optimized ubiquitous implementations with extensive tooling. I strongly disagree with you. CANbus on boats isn't exactly bullet proof, people mess up their N2K networks all the time by just starring at it wrong.
All these gizmos are not safety critical. Anemometer? Wind on your face. Depth? Plenty of people go around with broken ones. SOW paddle? They're always clogged. Wind angle? Wind on your face, check telltale, check sails, check wind index. Particularly the BLE stuff are things that are nice to haves and a pain to physically wire (masthead instruments).
The only "safety critical" thing in this tech is the chart plotter (and GPS), and weather reports. Marine chartplotters are glorified consumer grade computers, and this OpenPlotter thing with OpenCPN is 1000% more reliable and not actively trying to kill you with proprietary licensing crap. Your phone is a great chartplotter and plenty of people cross oceans using nothing more than an iPad.
I wouldn't use HTTP/json for any path that needs to close a control loop at hundreds of Hz, but to loosely couple a bunch of systems in a plant? No problem.
If you have a specific concern, explain it, instead of just exuding judgment.
Parent comment is likely more evoking a bit of a https://xkcd.com/2030/ response, aka humour.
SignalK is neat. As you note not all protocols are suitable for all use cases, but marine sensor networks where most signals are in the realm of 1-10Hz it definitely has its place.
If anything needs to run a server to communicate with anything else, especially if wireless is involved (which often is the case with more modern forms of radar, gps etc. because of ease of wiring and installation) is a recipe for disaster if you're relying on interfacing with existing instruments for navigation.
Simply firing up cli for troubleshooting and debugging of any kind should not be "expected behavior" at sea.
> If anything needs to run a server to communicate with anything else,
What's a server? Do you have servers in a NMEA2k environment?
> Simply firing up cli for troubleshooting and debugging of any kind should not be "expected behavior" at sea.
No one said that arcane troubleshooting and debugging should be needed after integration of a system. I mean, NMEA2K certainly never makes one fiddle around and play with things aimlessly to make stuff work /s
> especially if wireless is involved
Most common way wireless is involved here is to get the information off-boat or to a tablet for convenient review of trends.
It’s your labeling that put “web standards” into one bucket. I assure you many of those web standards are far more secure and well tested for not only failure cases but also adversaries than what exists in marine systems.
You know... I've been working in an interesting combined AgTech and Aviation (drones, but big ones) for a while now and using JSON over Websockets for IPC is one of the best decisions we've made. We don't use it for everything, mind you, there's lower-level protocols that we use to talk to embedded hardware devices, but when we can we do. And while it's a draft standard, we basically riffed on a variant of this for most of it: https://datatracker.ietf.org/doc/html/draft-inadarei-api-hea...
The reason I love it so much is that it's just so straightforward to make server or client that can talk to it. All of our embedded Linux systems are written in C++ right now and they have absolutely no problem publishing and consuming messages in our standard format. One of the original driving factors for this is that we do have some web-based and Electron-based UIs and any protocol that we made that wasn't HTTP-based or Websocket-based would require them to do twice as much work: first, connecting to whatever service from a "backend" server and implementing whatever protocol it needed, and second exposing that backend service to the frontend over a Websocket (generally... since it needed live updates). By standardizing on our in-flight services just exposing everything as Websockets natively we pretty much eliminated a whole tier of complicated logic. The frontends have a single generic piece of code that has standardized reconnect/timeout/etc logic in it, and the backends just have to #include <WSServer.h> and instantiate an object to be able to publish to listeners.
I definitely didn't start there. And I 100% understand where your opinion comes from... from so many different angles a lot of the "modern" web systems shouldn't come within a mile of a safety critical system. Websockets though? They're great! And while JSON isn't necessarily the most efficient encoding, it sure does make debugging easy. We run everything on a closed network that usually doesn't have an Internet connection, so we don't run TLS in between the ground and air systems. If we need to figure out what's going on and an interface is acting up, we can just tcpdump it and have human-readable traffic to inspect.
The flight critical stuff is isolated from all of this and spits out a serial telemetry feed (Mavlink). We do send that directly to the ground station over a dedicated radio, but we also have an airborne service that cooks that into Websockets and in many cases the Websocket-over-very-special-WiFi connection has been more robust than the 915MHz serial link.
And it's not as if existing protocols like NMEA are all that good either.
Thanks for sharing that! Very interesting. There is even less margin for error in air compared to at sea. At least you can still float if the power goes out and at that point a sewing machine is all you need for most critical problems past that point.
We've actually leaned in pretty hard on using "standard" protocols as much as we can:
- We have a flight planning module that takes multiple polygons as input and returns a (large) list of waypoints for covering the regions that the polygons cover. When I was trying to work out the request/response format I decided to use GeoJSON with some extra properties added. You submit the GeoJSON boundaries with a POST request, the planner does a bunch of computational geometry and graph algorithms, and returns back a GeoJSON. If you want to, you can just load the flight plan up in QGIS or ArcGIS or whatever and inspect it directly.
- We also accumulate quite a bit of geospatial data that we need to post-process. We used SQLite with the Spatialite extension to store that. Same story as the flight plans... you can really easily load it into QGIS or Geopandas or whatever you want and do your analysis
- We need to stream video down to the ground station and ended up using RTSP, h.264, and GStreamer to do that. You can connect to the video feed using our ground station software if you want, but you can also just connect to it using VLC. And internally this meant that if we wanted to do hardware-accelerated encoding it was just a matter of changing the GStreamer pipeline. Or... if I get my way over the next month or so, we'll be adding a HUD with extra telemetry right into the video feed, again using GStreamer plugins.
My engineering sense says RPi isn’t a good choice here, there’s a lot of potential failures that could happen, from a corrupted sd card, to overheating, harsh environment, among others, an industrial mini PC with proper protection and resources as well would be far better.
I keep my rpi in a pelican case that I modified to include an opening port for the NMEA connection. It gets all its power/data from the single connection which has a mechanical connection as well.
I have over 5000 nautical miles logged (thanks to a very nifty influxdb integration as part of open plotter) using this set up since ~2021, and so far it’s held up better than I could have guessed. I keep a spare pi and sds on board but have never actually needed them. My use case is long distance races, mostly in sub tropics/temperate areas, and I’ve had limited exposure to really hot air temp (say 90F and up in the tropics which is where I could see SDs starting to fail)
Signal K server is platform agnostic and runs on Linux, MacOS and Windows. Also available on Victron’s Venus devices, if you want off the shelf rugged hardware.
The pi foundation supports this in the compute module, which has an emmc variant. However that requires that you make a supporting PCB. (Or buy one from someone else)
If you are buying loads of them they will also customise the pi for you (although I think that's contracted out)
As I said in the other comment, there are already industrial PCs equipped with GPIO, and some models even include an integrated screen
SBCs are good in conditions where reliability is not the primary concern - scenarios where frequent restarts are needed, change sd card, room temperature etc.), but in a boat? I don’t know anything about marine conditions but having a malfunctioning in SD cards and overheating is not uncommon in robotics and especially in drones (where it’s harder to use full fledged PC), few times actually the SD card died midair, no crashes thankfully.
I agree that a proper ruggedized industrial PC would fit better (and cost only a few hundyed more). If their software could work on it, or could be adapted / ported, that would be a great choice.
But I suspect that what they have now is mostly married to Pi.
I've worked extensively with NXP's IMX6 hardware installed on carrier boards from a few different vendors. If you're looking for something bulletproof for long-term installation, I'd definitely recommend looking through their product lines.
There are multiple sources of industrial-strength RPi-based systems for different environments. Including railway-certified devices, industrial controls, etc.
Often coupled with RPi "hat" interface used to attach isolated industrial I/O (24V/analog/4-20mA, etc) or other interfaces.
That depends on a lot of variables: what kind of IOs you are looking for? Do you need them isolated (DIO vs GPIO), Does it need DIN rail? Integrated screen? What connectivity is needed (wifi, cellular)? Or resources (ram, cpu, etc.)? What’s the power delivery requirements?
So there’s a lot of factors that only you can answer given you know the application, but since you are looking for dust proof, then you should look for fanless AND ventless one, and one that’s vibration resistant (obviously with an SSD), and most of them can survive high temperatures, but personally I would even add it in a panel to provide extra protection, with a fan and proper ventilation just in case.
I did try some of them, like onlogic (1) and arestech (2) among others, and don’t restrict yourself to the brands, some Chinese (mostly cheaper) ones are good enough for the job like GigaIPC (3) and others too.
> My engineering sense says RPi isn’t a good choice here, there’s a lot of potential failures that could happen
Amen to that.
I blame the YouTube influencers posting all the RPi content that would make you believe you can run the world on RPi. Some of the shit they post is truly dumb ... Ceph clusters on RPi ? Rather you than me !!!
I once experimented with Pi's just for a fun unimportant home-server project. I got sick and tired of all the dumb failure modes, even when I expressly went out and bought high quality industrial SD cards, went above and beyond to minimise SD card IO etc. And that was just the SD card issues.... Never again.
This was precisely my experience too, and as someone who's got a plural of decades farting around with low level Linux, this was not a fun experience. I wonder how many people got jazzed about, then turned off of Linux because of such experiences?
Just anecdote, but I haven’t had SD card issues in 6-8 years, and my RPi usage has gone up a lot. That includes a setup with very read/write-heavy process that ran for 2+ years without issues. It filled up the SD card every 45 days, and only had reliability problems when I forgot to transfer data and it filled up the card.
That was just a decent consumer-grade SD card.
I’m not sure your experience happens to most people, at least not recently.
HN crowd maybe doesn't appreciate it, but the marine sensor networking world, route plotting, and related tasks are an atrocious cesspool of overpriced, weirdly incompatible proprietary solutions.
Regular people save literally tens of thousands of dollars per install by going open source in this space, and end up with superior toolkits.
I won't say we ended up with anything superior, but we definitely benefited on cost as you mention! We have an intro writeup of our experience using OpenPlotter and a Raspberry Pi-based setup here.
Something also not often realized is that many, many sailboats are actually quite old (20, 30, 50 years!) and so are their on-board electronics. Any chance to update wiring, instruments, diagram out on-board electronics, etc. is probably a really good opportunity for nav system and overall boat maintenance.
In the US Commercial Tug & Barge market, Rose Point Navigation (out of Redmond, WA) has a near 100% saturation of the navigation software market. Why does nobody disrupt them? The overlap between experts in software and experts in vessel navigation is pretty low. Take a look at the technical specifications of their platform here and see if you can crack that out in a weekend:
https://www.rosepoint.com/rose-point-ecs/
In recreational vessels, our needs are more basic, but even us geeks may be more prone to shell out $500 - $2000 to Garmin or Raymarine for a hardened chart plotter MFD that "just works", is waterproof, and robust at least in the nav function. I got a "deal" on a Raymarine Axiom Pro which has both touchscreen and a keypad mode for when the rain interferes with the display, has nav, ais, radar, sonar display, engine gauges, and tons of other features, it is running some version of Android. It's really good honestly. When the wind is howling and the waves are high, it's not necessarily a good time to do some hacking and bug hunting on the nav platform. I do plenty hacking on my boat in the sensor integration world, but that's another story...
Because the colours are standardised and embed important information. These are tools, not aesthetic objects. A lot of the palette is preserved from paper charts where they need to be readable under red light when underway at night.
For a masterpiece of technical documentation dig up a copy of admiralty chart 5011 for a dive into the colours and symbology used.
It's an international standard so all professionals that read the maps never have to guess what the colors mean. In commercial vessels, you need to follow the Solas standards. This also means that you need certified hardware and software for the chart plotters.
People get pretty far with tablet apps these days (literally), and there is a good market for the development of the apps. Hardware integration is always the challenge.
See 59-north for examples of offshore sailing schools who seem to have found a good mix of modern and reliable
And for anyone wondering about an opportunity to shake up the market just estimate TAM and you'll see quickly why boat stuff is priced at such a premium.
The number of people using things like Open plotter is even smaller, but still greatly appreciated by all!
Mostly sailors are very conservative and the technology has to be bulletproof.
The saying goes that Murphy was an optimistic sailor.
Plotters are a marriage of RADAR and paper charts. The technical integrations are really no trouble for the average system administrator. The problem comes about with the challenges of the environment and the uniqueness of every installation. The market is also small. I think the estimate is around 10,000 yachts actively moving around the world.
Another issue is that there are very few makers or the technology.
I think it's a great area for development because it is immature and in the middle of technical upheaval that nobody really knows what how great a plotter could be.
Making CarPlay for boats would not be so hard, but making Waze for recreational boats might be. But if you have ideas on that and are sure you can avoid directing people into deadly obstacles, considering all sea and weather conditions, in all kinds of boats, give it a go!
All commercial plotters have autorouting. There is automatic wind routing for sailing in OpenCPN (as a plugin). I'm not sure that adding it to a phone with carplay is a viable option. If you have a display to show it on, it's probably a display for a plotter with all the functionality, including map updates over the internet.
Thou for entertainment it's an other side, that would be useful.
I had one on my last boat (though in a space that was primarily air conditioned all the time. Had another on my balcony running a Marine Traffic AIS station for 6 years that was ‘weatherproofed’ with an unsealed ziploc bag. No issues.
I have always wondered why, in the world of millionaires and billionaires and yachts, why plotters like these have such ancient ugly 80s graphics. There are literally decades of UI enhancements, both functional and cosmetic, that could modernize these things. Im talking about the elite of the elite who will spare no expense at bespoke designed watches, monogram clothes, cars, etc. So it always just boggles my mind why this class of software languishes is in mediocrity.
and you would think there would be thousands of developers eager to work on something like this. Being able to actually test ride boats, and live a more adventuous lifestyle while putting their engineering skills to practice.
We would have something purpose made from raymarine/garmin/whoever hard-mounted to the steering station networked into the various sensors onboard. There would be at least one redundant display elsewhere (out of the weather in the case of boats steered from deck). We would never go for something on a raspi. Some boats will have the sensor canbus hooked into a computer to use additional software. The purpose made displays are all sleek touchscreen systems that look more like a Tesla interface than this raspi thing.
As far as UI and graphics: They are modeled on what actual paper charts look like (which is standardized, and what mariners are trained to use). These are systems designed as a safety tool first, and iterating through the latest design fads every 2-3 years to make things pretty is unsafe. I want my chart-plotters and tools to be near universal in symbology and interface, and that is what they have done.
1. Never in a million years would I suggest this Raspberry Pi project being the answer to the ugly that is nautical software.
2. Even the big fancy screens in fancy yachts have god awful UI.
3. I am not talking about meaningless fad designs. Google
Maps decades ago made road maps intuitive and beautiful at the same time.
By comparison, the vast majority of those chart plotters look like ancient Windows95 graphics. It's disingenuous to suggest that's as good as it can get. Google could have easily just scanned a bunch of awful old school highway maps and called it a day if that was true.
On commercial vessels, the colors have to follow the Solars standards. To make sure there are no misunderstandings in the charts. Many, software for no-comersical ships have much more fancy displays in random colors. Including 3d views of your route with sonar overlays. Satellite maps, but the clarity of the standard colors, or colors close to them as used by are much clearer in my view. For an overview of what Navionics, Garmin's chart brand, gives (https://www.navionics.com/fin/charts/features/garmin).
Those chart graphics (colors, symbology, everything) are an industry and legal standard, even if you don’t think they are aesthetically pleasing or intuitive. Any trained mariner can get onboard and understand the information regardless of brand. They aren’t meant to be intuitive and beautiful, they are meant to match extensive training and expectations of professionals. They are meant to be the digital evolution of a product with centuries of development. Nothing about nautical charts is a mistake. By comparison googles maps are extremely faddish, the look of their maps has changed quite a bit since launch their launch 19 years ago.
As far as the UI outside of the charts, that works the same as any iDevice or app.
The fact that I can think back over my work history and not remember the brand of the instruments and displays I’ve used is a feature not a bug.
> I have always wondered why, in the world of millionaires and billionaires and yachts, why plotters like these have such ancient ugly 80s graphics.
First because on a billionaire's yacht, there is a crew of 20 doing various jobs, 3 of whom do shifts on the bridge. So if you want to know where you are, you just pick up the phone to the bridge and bark at whatever poor sucker is on duty (or you bark at the person serving you drinks who then relays it up the ranks).
Second, on a billionaires yacht they already have large fancy displays with less ugly graphics.
Finally I would hazard a guess that (at least some of) the software "languishes in mediocrity" due to the safety certifications.
In that class of boat, the owner is not the one operating it. Many times they literally wouldn’t even know how to start the engines much less interact with the ships systems.
Even in that class of boat the owner will typically have a coxswain on his beck and call whenever he fancies going on a jolly.
Some people have chauffeurs, others have a boat and coxswain ... sometimes the coxswain doubles up as chauffeur if the owner isn't quite rich enough to employ more than one person.
Then you'll see MFDs from Garmin, Raymarine, etc.
I had Raymarine Axiom's on my last boat and they were pretty modern. You could display charts, radar, sonor, engine data, all mixed and matched on various layouts. I could even watch Netflix at the helm if I wanted.
Personally, looking at the modern B&G devices[1], I find their UI pretty slick. Also super nice to get all needed information by just glancing at the display
http://signalk.org/
Has an excellent community of developers and hardware components.