Live data from Hacker News

OpenPlotter

openmarine.net

41–50 of 72 posts

Re: OpenPlotter

#41
post #39

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). http://signalk.org/ Has an excellent community of developers and hardware components.

As a "sailor in tech", "web standards" do not belong anywhere near an ocean going vessel.

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.

Re: OpenPlotter

#42
post #41
post #39

Earlier quoted context omitted.

As a "sailor in tech", "web standards" do not belong anywhere near an ocean going vessel.

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.

Re: OpenPlotter

#43
post #39

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). http://signalk.org/ Has an excellent community of developers and hardware components.

As a "sailor in tech", "web standards" do not belong anywhere near an ocean going vessel.

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 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.

Re: OpenPlotter

#44
post #37
post #27

Earlier quoted context omitted.

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.

Power is also a concern (at least for sailboats). While there are certainly other 12v computers, that is one of the pluses for rPi in this.

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.

Seco: https://edge.seco.com/usa/ and Variscite: https://www.variscite.com/products/system-on-module-som/?cpu... are two of the vendors I've worked with and had great experiences with.

Re: OpenPlotter

#45
post #29

Earlier quoted context omitted.

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/…

Why are the color palettes used in these maps always so ugly? And they're not even color blind proof either!

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.

Re: OpenPlotter

#46
post #4

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…

you and I built very similar devices. Mine is on a 34ft sailboat. It has held up tremendously with zero issues for 4+ years and many miles.

the best part? it cost very little. Worried about redundancy? Build two, keep the SD cards backed up. Problem solved.

cheers.

Re: OpenPlotter

#47
post #29

Earlier quoted context omitted.

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/…

Why are the color palettes used in these maps always so ugly? And they're not even color blind proof either!

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.

Re: OpenPlotter

#48
post #33

Earlier quoted context omitted.

I'm confused why does this mean no one can Carplay-ify the plotter/charting world for boats?

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.

Re: OpenPlotter

#49
post #39

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). http://signalk.org/ Has an excellent community of developers and hardware components.

As a "sailor in tech", "web standards" do not belong anywhere near an ocean going vessel.

"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.

Re: OpenPlotter

#50

Earlier quoted context omitted.

Having been a yacht captain turned programmer: 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…

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…

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).
Post reply on HN