Has an excellent community of developers and hardware components.
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.
If you have a specific concern, explain it, instead of just exuding judgment.
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.
Simply firing up cli for troubleshooting and debugging of any kind should not be "expected behavior" at sea.
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.
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.
- 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.