Signal K Implementation

[bcn]

Originally Posted by bdbcat

bcn...


re: Crash on MacOS.
Tried here on Mojave 10.14.5. Normal install and startup. No crash.
Maybe the problem is some legacy plugins causing trouble? Disable manually in config file to test.


Dave

Tested with the conf file disabled. Virgin set-up.
Mine is Catalina, latest updates.

[bcn]

Next trial:
disable all plug-ins from 5.0
- all built-in as well.
Close 5.0, go for 522





Then 5.0.522 will start.
Options| plug-ins - the big + and "update" will provoke the "zero divide"

[bdbcat]

bcn...
No crashes here.


Try:
1. Enable one legacy plugin at a time, find the offender.
2. Crash on big "+" catalog update is probably not the same signature as the initial crash. Please post crash dump as before.


Thanks
Dave

[pinguino]

I was really happy to see for the first time the entry for Signal K among the possible OpenCpn connections. It was already taking too long. It's true that it wasn't absolutely essential since Signal k also pours the data in NMEA 0183 format but it's a coherent step with the future of sailing using free software.

Now, at home, I have built the Rpi version and installed it. Since here I only have Signal K data from a pressure and temperature sensor opencpn has not reacted to them since the dashboard, as I read before, is not yet connected to the Signal k data stream. But it has automatically discovered the existence of the Signal K server and connected to it.

The next step has been to send GPS data from a smartphone in binary format to the Signal K server and see if OpenCpn was positioned correctly and indeed it was. And even I have seen that some of the GPS data like the position and the time of GPS were shown in the dashboard although others like the number of satellites and the signal status of these did not appear unless I introduced the NMEA 0183 stream.

When I am on board, having a real installation on the boat working completely I will be able to give more details about the operation of this new implementation.

By the way, I suppose that when steering an autopilot it would be necessary to be able to convert the appropriate signals to NMEA 0183 format since the vast majority of autopilots do not understand Signal K, don't you think?

If someone approaches for the first time to the world of Signal K and wants to install it easily in any debian system (Ubuntu, Mint, etc) (x86, AMD64, arm) can use the application openplotter-settings, install it and then install the module corresponding to Signal K. It is a simple and fast method that creates a shortcut on the desktop to access the server. Later we can uninstall everything if we are not interested easily and leave our system as it was without major problems.

P.D.

I forgot to mention that although the connection is detected and it works correctly, the port that opencpn detects for signal K is not what I expected it to be. However the truth is that it works well. Just as a curiosity.

[Sailoog]

Here short instructions to install OpenPlotter 2 in any Linux based on Debian or download fully working images or NOOBS files for Raspberry Pi 3 or 4:


OpenPlotter 2 roadmap


@pinguino


localhost 8375 is an undocumented Signal K data output. Currently OpenPlotter only shows you the official and expected connections. This new connection will be added to OpenPlotter when SK inputs are officially added to OpenCPN .

[bcn]

Originally Posted by bdbcat

bcn...
No crashes here.


Try:
1. Enable one legacy plugin at a time, find the offender.
2. Crash on big "+" catalog update is probably not the same signature as the initial crash. Please post crash dump as before.


Thanks
Dave

Dave...


results and additional comments at Github
https://github.com/OpenCPN/OpenCPN/issues/1562


Hubert

[verkerkbr]

Hi Dave,

very good to have the signalK input allready made possible in OpenCPN in such a short time. This opens a new world for applications coming from NMEA2000 and from SignalK itself.

Small windows with the state of of the fuel tanks, engine revs, engine temperatures etc. etc.

Tried the setup on an Xenial Linux system with the SignalK server on the RPI. This
works very well. See image.

NMEA183 Debug of course not working. How about a debug for SignalK ? There was one in the former OpenPlotter version. Must be simple to implement.

Tried also to send SignalK data back from an OpenCPN applicatier with RMB (course and distance waypoint).

But that I have not (yet) working. Does it work sending back SignalK data from OpenCPN ?

I spoke to nmea people at the Mets marine trade show and said they also working on a newer version of nmea183 with more extensions.

Thanks for all your efforts.

Regards,


Bram

[pinguino]

Originally Posted by Sailoog

localhost 8375 is an undocumented Signal K data output. Currently OpenPlotter only shows you the official and expected connections. This new connection will be added to OpenPlotter when SK inputs are officially added to OpenCPN .

That's good to know.

[Hakan]

My conclusions if I got it right.
In OCPN connections we have a very good multiplexer that can distribute around any network. That way we get data also for the Dashboard.
Once we need input to the network from others than NMEA 0183 on serials or (w)lan O has a problem.
Signal-K can help a lot here. Not less when start to fiddle with different NMEA2000 sources, K-plex or any RPi-HAT.

To get data into O from Signal-K and also feed Dashboard we can connect direct to Signal-K server by TCP and the dedicated port. I've set my SK on a RPi4 to output to TCP 10110 and so my RPi3 and Win10 can connect to that, instead of Signal-K data type, and Dashboard is happy.
Håkan

[bdbcat]

Hakan, et al...


There are lots of ways SignalK can be used. Here is one, allowing simple support of a third-party dashboard displaying SignalK data, with OCPN happily following along.



http://www.cruisersforum.com/forums/...ml#post3043990


Many more "plug and play" configurations are possible, allowing some very useful arrangements.


Part of our interest in Signal K is to do our part in proliferation of this extensible, open-source data transmission standard. I would like to see it reach critical mass, and become THE standard for data interchange, or at least be a technically and functionally credible peer to NMEA0183 and N2K. So we do our part...


Dave

[Canne]

Originally Posted by bdbcat

...There are lots of ways SignalK can be used. Here is one, allowing simple support of a third-party dashboard displaying SignalK data, with OCPN happily following along...

Thanks, Dave, very useful implementation for a plug-in instrument like this!

[Patg]

Happy New Year to everyone !

Thanks Dave for this big step forward to integrate SignalK support in OpenCPN.

I dived a bit into the source code to find out how easy it would be to implement SK support in the dashboard. I implemented a simple sample SignalK instrument which can be bound to a certain path and displays a single value (based on DashboardInstrument_Single). Just a little proof of concept.

Getting the data through the plugin manager is already present in the code, passed through the multiplexer and then through SendMessageToAllPlugins. Just needed to handle message of type 'SignalK' in the handler already processing WMM_VARIATION_BOAT.

Unfortunately the JSON data is sent as a string and must be parsed again in the plugin, it would be nice to have an additional json based message passing method.

I think the next step is to use more features of the SK server. There is nothing wrong with using the TCP data stream for updates instead of the websocket, but maybe it would be good to use the HTTP API initially to get the urls and versions and the initial data set of the vessel. The available paths should then be stored in memory along with the meta-data. The plugins should somehow have a method to access this meta-data to select datasets they want updates for. This could then be turned into a subscribe message on the sk-connection or just to filter the updates sent to the plugin/instrument.

A lot of work ahead... Anyway, exciting to see SK support in OpenCPN !

Patrick

Originally Posted by bdbcat

..
Part of our interest in Signal K is to do our part in proliferation of this extensible, open-source data transmission standard. I would like to see it reach critical mass, and become THE standard for data interchange, or at least be a technically and functionally credible peer to NMEA0183 and N2K. So we do our part...

Dave

[bdbcat]

Patg...


Thanks for reading the code.
Regarding Dashboard:
I have no plans to use the core multiplexer to send arbitrary SK messages through the plugin interface. My reasons are:
1. The entire universe of SK message values is huge, and contains information of no use to the core. Maintaining a catalog of this, and exposing at the plugin API, would be a real burden to the core.
2. We cannot anticipate where SK is going, and what data types may appear in the future. Decoupling the general SK stream from the core seems wise, for maintenance reasons. After all, the core really cares only about what is the equivalent of an NMEA0183 RMC message, and that is enough.


I prefer an implementation in which the dashboard subscribes directly to the server for what it wants. Of course this means that the dashboard will need to have its own wxSocket client, independent from the core. And its own JSON parser.
I realize that this is a lot of code to add to the Dashboard. On the other hand, it is mostly copy/paste operation to extract an SK handler from the core codebase. Once it is done , it can become boiler-plate for other plugin authors, as needed.


Comments?


Thanks
Dave

[conachair]

Originally Posted by bdbcat

I realize that this is a lot of code to add to the Dashboard. On the other hand, it is mostly copy/paste operation to extract an SK handler from the core codebase. Once it is done , it can become boiler-plate for other plugin authors, as needed.


Comments?

A dashboard which can display a webpage would be one road to view all the sigK data, influxdb charts etc. The KIP app does a good job at dashboard creation, as does chronograf for database viewing, if a KIP/chronograf/grafana page were viewable inside opencpn then that would negate the need for some wet finger pressing on a tablet
Kip can do it already, link to a web address.

[teppokurki]

Originally Posted by bdbcat

I realize that this is a lot of code to add to the Dashboard. On the other hand, it is mostly copy/paste operation to extract an SK handler from the core codebase. Once it is done , it can become boiler-plate for other plugin authors, as needed.

This sounds awfully much like an opencpn-signalk-client library.

Copy/paste will lead to recopying and different levels of support in different plugins as the best practices evolve.

If I knew C++ I'd be happy to help, but can contribute only SK expertise. Like "don't forget to account for multiple sources for the same path, for example position".