In what cases is SignalK needed?

[Tehani]

Originally Posted by mgrouch

Is there something open and as complete as SensESP but for STM32?

STM32 and Esp32 are both comparable MCUs but ESP32 has open source platform SensESP specifically oriented for boating needs.

Here are project repositories with the Arduino IDE, if that's more familiar to you:
https://github.com/stm32duino

SensESP, Hat Labs is also running out of stock:
https://hatlabs.fi/product-category/...v=04c19fa1e772

[boatmon0]

I "need" signalk because I "need" to track temperature on a couple of heat exchangers that my boat did not come equipped to track. The boat already had a nmea 183 buss and two N2K networks. Seems like the industry is a mess. So I got rid of the extra N2K network, and now I can monitor my stuff with a tablet, or old phone. Sensor technology is changing rapidly with Signalk, now I use ESP32 sensors which are cheap powerful and reliable.


The big problem with our major suppliers of marine electronics is that the products have built a whole industry to support and install them. That industry likes things to be hard to install, they can charge more. Signalk at least tries to make it straight forward.


My Thoughts
Eugene

[bergius]

Originally Posted by boatmon0

I "need" signalk because I "need" to track temperature on a couple of heat exchangers that my boat did not come equipped to track. The boat already had a nmea 183 buss and two N2K networks. Seems like the industry is a mess.

Kind of the same situation on our boat. We have some NMEA0183 devices, a NMEA2000 bus for the modern stuff, as well as a pretty extensive Victron electrical setup and a Teltonika Internet setup (for boat office). Signal K is where all of this comes together, and data from one of these can be sent to another, or maybe run first through some business rules.

Is that mission critical? Probably not. But I have a very good idea of the current and past state of all boat systems in a single place. And with the integration between Signal K and Grafana, I get nice explorable visualisations of all of it.

I’m also using it for adding some “smarts” to the boat. Small conveniences, mostly. Like automatically setting my B&G Triton2 instruments to day/night mode (and correct brightness) based on the day cycle.

[teppokurki]

Originally Posted by Tehani

SignalK:

{
  "vessels": {
    "urn:mrn:signalk:uuid:705f5f1a-efaf-44aa-9cb8-a0fd6305567c": {
      "navigation": {
        "position": {
          "value": {
            "altitude": 0.0,
            "latitude": 37.81479,
            "longitude": -122.44880152
          },
          "source": {
            "label": "ttyUSB0",
            "type": "NMEA0183",
            "talker": "GP",
            "sentence": "PRMC"
          },
          "timestamp": "2017-05-16T05:15:50.007Z"
        }
      }
    }
  }
}

This in "Delta" or compressed. All ASCII, total message length: 524 bytes, and if we read, there are 113 bytes before we see any significant data.

Is this reasonable?

Some corrections:
- this is not a delta message, it is the full representation
- a sensor can and probably should omit the vessel context (the sensor does not need to know the id of the vessel it is on), source and timestamp
- no need to send altitude

{
  "updates": [
    {
      "values": [
        {
          "path": "navigation.position",
          "value": {
            "latitude": 37.81479,
            "longitude": -122.44880152
          }
        }
      ]
    }
  ]
}

Nevertheless I think the criticism for bloat is warranted. If you want to build a low power, low BoM cost device you are resource constrained.

If your resource budget is tight and it is a "dumb" sensor (no SK server discovery, authentication support or configuration over http) that just produces some data you don't need a full blown json library, you can get pretty far with just some string concatenation.

But even minimal delta has two levels of extra braces. What if we add a new "lean delta" format to SK and keep just the innermost array?

[
  {
    "path": "navigation.position",
    "value": {
      "latitude": 37.81479,
      "longitude": -122.44880152
    }
  }
]

making it essentially key value pairs, with CR message terminator for serial, TCP and like media. How would this work for your application? I know it is still a little verbose, but the code changes needed would be minimal, it would work well with SK 1.0 and we could still keep human readability AND the flexibility and ubiquitousness of JSON.

Something that has been missing from this conversation is that in addition to the paths documented in the spec Signal K allows extension of the data model: a sensor can send metadata for the data it produces. I can build say a jacuzzi temperature sensor and have it send units and human oriented description for the data. All generic SK software would be able to deal with that: display it, convert the values to the unit that user prefers, define ranges/zones for acceptable values and have notifications raised based on those, write it to a db and graph it. All without changes to the SK handling software.

Afaik this is not possible with any of the existing NMEA mechanisms. OneNet I have very little information on, because it is, as you know, closed.

I am the first to acknowledge that Signal K is not perfect, but I think we should work together to improve it.

[goboatingnow]

If you simply add custom PGNs to NMEA2000, you can transfer any custom data you like

For the “ amateur “ inventor it’s easier to implement basic NMEA 2000 sensors as CAN interfaces are widely available and there is sufficient protocol information out there in the public arena.

In my case for slow speed sensing , current shunts, device monitoring , charging control I use a custom LIN interface , very simple to code and implement on low cost microcontrollers

[teppokurki]

Originally Posted by Tehani

Please, at this point I think it is necessary to rigorously explain when it is essential for an OpenCPN user to use SignalK

I think this is a good question.

So why would I use Signal K and not just O? After all people have been using just O very successfully. So clearly it is not needed for the core O functionality.

Some areas where using SK with O has clear benefits:

(1) Universal access to data

If you route all your data directly to O you are limited to what O does. It is plenty capable, but there are things that it can not do, like
- access to all the data from any modernish connected device onboard (web interface)
- programmatic access to all the data, from any programming language
- support for flexible, device agnostic remote access to all the data
- support for non-NMEA data and data sources
- extensible data model with dynamic metadata
(- easy plugin and webapp development and deployment with SK server)

If you combine SK with O you get all that.

The drawback is increase in complexity, resulting in trouble that people sometimes experience figuring out what goes where. With great power comes great or at least increased complexity.....

And if you are using SK in one part of the system it makes sense to support the richer SK data model natively.

(2) Universal data model

First season I wrote code for NMEA0183 data. Following season I bought some N2K equipment, and realised I need to rewrite relevant parts, because the first season implementation was so tightly coupled to NMEA0183. Some time later I added non NMEA sensors, but by that time I was using SK and adding new data was a breeze.

I am not familiar with OpenCPN internals, so correct me if I am wrong in saying that OpenCPN is like that, at least to an extent.

Signal K could be used as a universal data model inside O, not just for getting data in and out. And I am not talking about JSON here, just using the "names" and metadata from the SK spec and the metadata extension mechanism.

A universal data model allows also using generic tools such as InfluxDb and Grafana and other time series database and graphing and monitoring tools to be used, widening the set of software tools at your disposal. Another notable addition to your toolbox is Node-RED, that can be used to create complex logic flow that combine different inputs and drive outputs, directly or via Signal K.

I apologise for not having actually used Engine Dashboard, but why does O need a dashboard for a specific area like that and not a universal dashboard where you can combine any data that you want?

It seems Eng Dashboard has explicit support for three different flavors of NMEA and Signal K. It has an internal data model that it uses to dispatch updates from the different source types. This data model is hard coded, heavily inspired by NMEA 2000 structures (not unlike SK in some places). Afai can tell there is no way to show say some arbitrary value, say alternator power or genset amps.

The bigger obstacle is that all this is internal to one plugin that handles just a subset of onboard data.

So O and its plugin ecosystem could be more flexible and extensible using a shared, universal data model. SK or not, but I think it makes sense to pool the open source efforts and not go separate ways.

==============================

Circling back to your arguments later in the thread: if you are creating a sensor board that outputs well defined data that is covered by NMEA Signal K provides very little if any added value. This is not where SK shines.

[teppokurki]

And in any case, to use SignalK it is also necessary to use an external hardware device (We save nothing).

This is not correct. You can run SK and O on the same computer - this is what OpenPlotter is. Or maybe I am missing your exact point here?

[Tehani]

Thank you very much Teppo.

I think you have been explicit enough that the followers of this thread can draw their own conclusions. At least I was able to do it.

[stevead]

I apologise for not having actually used Engine Dashboard, but why does O need a dashboard for a specific area like that and not a universal dashboard where you can combine any data that you want?
...
It seems Eng Dashboard has explicit support for three different flavors of NMEA and Signal K. It has an internal data model that it uses to dispatch updates from the different source types. This data model is hard coded, heavily inspired by NMEA 2000 structures (not unlike SK in some places). Afai can tell there is no way to show say some arbitrary value, say alternator power or genset amps

No apology necessary.

As one dives into the inner workings of OpenCPN one finds that many quirks (aka annoyances) are historical in nature. Same goes for the engine dashboard, which was a quick & dirty bastardization of the existing dashboard to display engine related data. It's initial release coincided with the release of a version of the TwoCan plugin that introduced support for the NMEA 2000 engine & tank level PGN's and conversion to NMEA 183 XDR and RPM sentences. The latest release added support for NMEA 183 v4.11 standard transducer names and SignalK JSON messages. It doesn't really have a data model, for example engine rpm's received either from a NMEA 183 RPM sentence or SignalK propulsion message are parsed and used to move the needle on a RPM gauge.

The existing OpenCPN built-in dashboard is a plugin that runs inside OpenCPN, is tightly coupled to OpenCPN, receives NMEA 183 sentences from an OpenCPN plugin API or SignalK JSON messages from an internal OpenCPN messaging framework and was originally designed to display vessel data such as depth, speed, wind angle & speed, position etc.

The engine dashboard which for expediency uses the same codebase, plugin API's and UI elements as the original dashboard, was simply modified to parse different NMEA sentences and display engine related data such as RPM, oil pressure, temperature, battery voltage and tank levels using the same dashboard gauges, albeit repurposed.

Yes it would be great to have rewritten the "dashboard" codebase to present a modern UI and to provide a generic metadata/dictionary driven universal dashboard but one's time is limited and the pragmatic difference is that it took a few day's coding to release the original engine dashboard whereas I think it would take at least six months to architect a new universal dashboard.

However I think this discussion of the engine dashboard is a distraction from the original topic.

[teppokurki]

Yeah, I can certainly relate to "one's time is limited"!

Originally Posted by stevead

However I think this discussion of the engine dashboard is a distraction from the original topic.

The original topic was "in what cases is Signal K needed" and dashboards /presenting onboard information is one area where it would be useful.

[teppokurki]

Originally Posted by goboatingnow

If you simply add custom PGNs to NMEA2000, you can transfer any custom data you like

Sure, but there is no mechanism how my device would be able to understand what your device is sending. If you squint your eyes there is little difference between a custom PGN message and encrypted data

One issue that is holding us back as a community is that one off, custom solutions "that work on my boat" are way, way easier to build and require less work than something that a lot of people with varying degrees of IT savviness can use.

[Tehani]

Originally Posted by goboatingnow

...In my case for slow speed sensing , current shunts, device monitoring , charging control I use a custom LIN interface , very simple to code and implement on low cost microcontrollers

This is very interesting. I am seeing that the LIN bus is electrically compatible with Seatalk 1. It is half duplex, it also uses the same dominant/recessive bit technique and the currents (pullups) are of the same order.

Thank you for mentioning it.

[MrGod2U]

Originally Posted by Tehani

Please, at this point I think it is necessary to rigorously explain when it is essential for an OpenCPN user to use SignalK, because there are already many people stuck.

"Can be used" is not enough, because as far as OpenCPN is concerned, a conventional gateway is enough in the cases I know of: NMEA2000 <-> NMEA0183, and Seatalk <-> NMEA0183. And in any case, to use SignalK it is also necessary to use an external hardware device (We save nothing).

I don't know the precise answer, so I wish someone expert would kindly explain it in simple words.

I should point out that it is not my intention to go against SignalK, on the contrary, I think these guys are doing excellent documentation on NMEA2000.

Thanks
Jose Luis

I know this is an old post but I've found what seems to be a fairly reliable anemometer (wind speed / direction) designed for marine environments. It doesn't use any of the common communication protocols so instead I bought $7 circuit board with a computer chip on it, connected the wire leads to a few of the pins on the circuit board and viola! I have wind speed and direction into open cpn via signalk.

And, as an added bonus, that $7 chip (ESP WROOM32) sends its data wireless to the Pi running opencpn.

So, for under $200 I have a wind sensor unit that I can afford to break, and when it does I need only to 3d print the new parts or spend $7 on a new module.

It good! And, it'll be connecting to my autopilot, and tank sensors, and pitch/heel to make for more efficient autopilot, all of this thanks to signalk for a fraction of retail

[bdbcat]

MrG....


More info on the sensor, please? Link?


Thanks
Dave

[MrGod2U]

Originally Posted by bdbcat

MrG....


More info on the sensor, please? Link?


Thanks
Dave

It's made by PeetBro's in the US. You can select Standard or Marine Grade.