Signal K Implementation

[Patg]

Originally Posted by bdbcat

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?

This sounds practicable, but I don't like the idea too much. More and more plugins will probably need want to work with signalk data in the future. Multiplexing those connections seems a better solution IMHO.

I think Signal K will really evolve in being the successor for NMEA0183 for external applications connected to the boat network. NMEA0183 was fairly easy to parse and filter, the same applies to JSON-based SK messages.

It is not really practicable to parse N2K Fastpacket Canbus messages in a mobile iphone/android app. The encodings of the N2K PGNs are still non-disclosure, so SignalK is the way to go and it also removes a lot of the limitations of NMEA0183.

Even the NMEA consortium has somehow accepted this fact and officially supports SignalK through certified N2K-gateways.
http://www.nmea.org/Assets/nmea%20signal%20k%20recognition.pdf

I talked to some engineering guys of B&G and they told me it might be possible to see an SK gateway in their Zeus MFDs or H5000 cpus in the future. (in addition to their NMEA0183 translation). There are already commercial solutions available like iKommunikate. (and of course quote a lot of homebrew solutions like RP with PICAN2, Actisense NGT, ..)

But a step by step approach is probably a good idea. Getting the basic 'RMC' data in the core is a first good step. A next one could be to support alarms and notifications or AIS (in the core). The passing of unparsed SK messages to the plugins is actually already in the codebase (as described in the last post), so this is probably enough to start with.

Thanks

Patrick

[Patg]

Finally had the time to read the SignalK thread..

I didn't want to start the discussion all over again... !! A pragmatic approach is probably the best thing to get things started and break out of endless discussions. Software can always change and evolve.

[transmitterdan]

OpenCPN core is not the best place to parse each and every SignalK message. Would be perhaps a good idea to think of a plugin or maybe some external multiplexer program running as a service. It could then allow plugins to subscribe to just the data it wants.

There are lots of ways to do it. But burdening the core of OpenCPN to know about every single message type is not really optimal I think. One idea would be to have a standalone mux program that has a parser driven by a file containing the info on how to parse SignalK. Then updates could be much faster and simpler by just updating the parser description. Plugins could connect over IP to the mux.

[teppokurki]

Originally Posted by transmitterdan

Would be perhaps a good idea to think of a plugin or maybe some external multiplexer program running as a service. It could then allow plugins to subscribe to just the data it wants.

I don't quite follow you. SK server is an external multiplexer running as a service that allows you to subscribe to just the data you want.

(To be precise: it will, once I've added subscription support to its tcp service. I'll get back to this.)

One idea would be to have a standalone mux program that has a parser driven by a file containing the info on how to parse SignalK. Then updates could be much faster and simpler by just updating the parser description. Plugins could connect over IP to the mux.

What would that output over IP? Signal K deltas are already essentially key-value pairs. When we add a new "well known path", a new string key, the JSON structure does not change, only the keys / paths in the payloads.

[bdbcat]

re:
"(To be precise: it will, once I've added subscription support to its tcp service. I'll get back to this.)"


I'm confused. Is this not implemented now? If not, how is the current OCPN server access working at all?


Dave

[teppokurki]

Default policy, ”all data for thsi vessel”.

[verkerkbr]

Originally Posted by 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 .

OpenPlotter beta 2 works great on a Raspberry. But it can be used for other Linux systems to install the SignalK server.

It can be done with the same server setup as OpenCPN. Replace the opencpn/opencpn with openplotter/openplotter in the ppa sentence.

Then you get a message about the key. This can be done with the same keyserver as OpenCPN.

This works perfect with a 64 bits Mint Tricia.

However with my 32 bits system there where some problems with the nodejs version. Looking at the server settings the version was 10. After replacing the 10 with 8 and after updating the server settings the problem is solved.

Then you can install the SignalK server also on a 32 bits Linux Buster version with the installed OpenPlotter settings.

Bram

[Georgiamarie]

Do you guys have an English version of this topic

[conachair]

One thought, signalk is without doubt a very big game changer in networked data onboard boats. But it really hasn't got a foothold deep into the community.

I think one way to get right in there centre field would be for someone to write an opencpn plugin, so it could be run from opencpn without having to jump through the hoops of installing. Not hard hoops but for the multitude of non techies they are massive burning hoops of fire.

Is that even possible? It would almost certainly push signalk to the front if it were.

[transmitterdan]

Signal K is accepted by OpenCPN in next release as far as I know. It is in alpha test now for the bravehearts amongst us.

[verkerkbr]

See Image.

Raspberry 4 with 2 GB is now running with 64 bits, Kernel version 4.19.99-V8+

OpenGL, SignalK server en direct input of SignalK in OpenCPN.

Works just as fast as my other systems.


Bram

[conachair]

Originally Posted by transmitterdan

Signal K is accepted by OpenCPN in next release as far as I know. It is in alpha test now for the bravehearts amongst us.

Don't think i was very clear, I meant that for signalk to get really popular, having a signalk server available as an opencpn plugin would help lots. No idea if it's even possible though. Maybe one day

[transmitterdan]

Originally Posted by conachair

Don't think i was very clear, I meant that for signalk to get really popular, having a signalk server available as an opencpn plugin would help lots. No idea if it's even possible though. Maybe one day

I think there is already a SignalK server available. OpenCPN doesn’t seem like a good place to put a server. O consumes data but doesn’t generate very much data. That’s why O will be able to subscribe to a signalk server.

[verkerkbr]

Originally Posted by conachair

Don't think i was very clear, I meant that for signalk to get really popular, having a signalk server available as an opencpn plugin would help lots. No idea if it's even possible though. Maybe one day

Hi C.,

this is not a good idea. SignalK can be used for a lot of other tasks. Like engine data, rpm, temperature cooling system, fuel tank level, as seen in my image the processor temp.

The conversion of NMEA2K to SignalK and use this in OpenCPN.

OpenCPN is a navigation system and to be used for a lot of other data.

SignalK has a great potential for marine data and is now gaining ground.

SignalK data input direct in OpenCPN is a logical step in the adaptation of SignalK.

Regards,

Bram

[conachair]

Originally Posted by verkerkbr

Hi C.,

this is not a good idea. SignalK can be used for a lot of other tasks. Like engine data, rpm, temperature cooling system, fuel tank level, as seen in my image the processor temp.

The conversion of NMEA2K to SignalK and use this in OpenCPN.

Been using SigK 24/7 since the very start so know all this

But also that no one much is using it outside the much more techy type cruisers/sailors. For the other countless thousands probably running windows getting SigK installed is just way to involved, say there was a Opencpn plugin like the openplotter V2 installers which does all the work then suddenly SigK is actually a realistic option for many thousands on Win as it's another mouse click in familiar territory. Or some sort of easy windows installer, WSL is a burning chasm to far to leap over for most as is loading node etc (which didn't work on my W10)