Signal K

[bcn]

Originally Posted by rgleason

I don't think n2k direct to a PC is possible today without using a manuf black box. I believe the openplotter effort has many possibilities, but does not have full n2k to PC capability at this moment. ---Need all the manuf codes and have to be a member for the documentation. Correct me if I am wrong please.

Wrong Rick: Kees has already reverse engineered a good part of the N2K sentences. See CANboat. And the OpenPlotter box brings the access to the CAN/N2K network.
N2K --> SK integration is work in progress at OpenPlotter.

[rgleason]

Glad to hear that, but aren't their many diff manf with different numbers? I believe the list of translation would be considered incomplete if some of the main manf were missing... but thats quite an accomplishment nevertheless by Kees. How does he do all this plus radar?

[teppokurki]

Originally Posted by nohal

Wherever the core now depends on an NMEA sentence, replace it with a protocol agnostic data structure fed from any protocol specific input connector.

Revisiting this issue, that I just discovered: My initial start towards what has come to be Signal K was on my own boat with data from NMEA0183 and N2K.

I cobbled something together, then tried it on data from other boats with different equipment setup, and quickly realised that we need a shared vocabulary, so that the apps do not all need to do the mappings.

To me all the JSON, REST, WebSocket, full and delta stuff is auxiliary, necessary evil and the real beef is in the keys specification. The list is not perfect, but as far as I am aware it is the only candidate for an open source, shared data model in this area.

Appendix: Keys Reference · Signal K Documentation

It would be absolutely wonderful if OpenCpn would embrace and extend this model!

See also https://github.com/SignalK/specification/issues/206

[teppokurki]

Originally Posted by muttnik

Whenever I ask "Where was that stated? I didn't see it on the Signal K google group?" The answer is usually "It was discussed on Slack.." so I won't ask :-)

We have clearly done a poor job of communicating if you feel this way. Sorry about that. With the limited time available for working on Signal K I personally have strived to actively respond to queries & work on moving practical things forward, at the expense of broadcasting of what is happening.

But we do have tried to be a good open source project in pushing the more than idle discussions to Github issues, where the discussion is more structured and can be tied to actual work on the specification and implementations.

So the best place to follow & contribute is the specification in Github: https://github.com/SignalK/specification/issues

If you feel some issue or another is not being addressed properly or you feel you can contribute why not poke around there.

Personally I'll try to do a better job of following Cruisers' Forum, taking after OpenPlotter people.

[merrimac]

Originally Posted by teppokurki

Revisiting this issue, that I just discovered: My initial start towards what has come to be Signal K was on my own boat with data from NMEA0183 and N2K.

I cobbled something together, then tried it on data from other boats with different equipment setup, and quickly realised that we need a shared vocabulary, so that the apps do not all need to do the mappings.

To me all the JSON, REST, WebSocket, full and delta stuff is auxiliary, necessary evil and the real beef is in the keys specification. The list is not perfect, but as far as I am aware it is the only candidate for an open source, shared data model in this area.

Appendix: Keys Reference · Signal K Documentation

It would be absolutely wonderful if OpenCpn would embrace and extend this model!

See also https://github.com/SignalK/specification/issues/206

Yeah, I agree. OpenCPN internally wouldn't need to convert JSON into C++ objects. A key/value concept would probably more useful and simple, e.g.

key=/vessels/244060807/navigation/position/longitude value=33.101

. Plugins could specify a regex to define what keys they are interested in, for instance. Also just copy everything from

/vessels/{ownid}/

to

/self/

.

[merrimac]

Originally Posted by rgleason

Glad to hear that, but aren't their many diff manf with different numbers? I believe the list of translation would be considered incomplete if some of the main manf were missing...

CANboat has 95% of all standard PGNs covered in some fashion. All "standard" ones are 100%. What's left to do is add company-specific ones and flesh out the recent media control PGNs. Donations (=PGN data) happily accepted.

but thats quite an accomplishment nevertheless by Kees. How does he do all this plus radar?

Like computers do multi-tasking: one thing at a time. Most of the N2K reverse engineering was done in 2009-2012, with sporadic flare-ups since then. Radar plugin stuff is more recent, 2014+.

[rgleason]

Thanks Kees and Teppokurki. Sorry if I got the goals, actors and projects switched.

Canboat = 95-100% of PGNs is great.
Signal K = Potential common regex for plugins which might help with messaging. Perhaps something added to the plugin api and communication that Jon G.has extended for Open-draw, watchdog and weather_routing?

[muttnik]

Originally Posted by teppokurki

If you feel some issue or another is not being addressed properly or you feel you can contribute why not poke around there.

Note that this is a resurrected thread and my views on a lot of things have changed in a year. Notably I now better know how to drive github, have recognised that the old school concept of "IoT" has been replaced in the eyes of most manufacturers with a central server model similar to the SignalK concept, and as a necessity for a different project joined slack and have posted a few times on the Signal K channels (not, I think, to any great effect).

I wasn't aware that github was being used for more than the reference implementations: I'll check that out. On the slack side, it has seemed to be the primary discussion location. I'm not sure that's ideal given that it's not indexed by search engines, you need to sign up (albeit signup is free-as-in-beer) and, as I understand it, the discussions disappear after a certain time.

Originally Posted by teppokurki

Personally I'll try to do a better job of following Cruisers' Forum, taking after OpenPlotter people.

You personally do a great job promoting Signal K on this forum and others, suggesting ways it can be part of a solution and encouraging people to get involved. If you're suggesting a Signal K thread on cruisersforum like sailoog's openplotter thread (although that may not be what you're suggesting), with the google group, slack and github already active I'm not sure that another hub for discussion is a good plan.

[rgleason]

Please use this thread for general and programming discussion about integrating SignalK with Opencpn.

There is an initial effort by [balp] to begin to integrate a SignalK server into Opencpn here, and bdbcat asked on Feb 1, 2019 "Any chance of significant progress on this for O5 initial Beta and release?" There seemed to be healthy interest in helping with this task from the general opensource programming community, but it is really unfortunate that nothing has happened since. Also other programmers are asking if there is any overall plan and timeline for SignalK?

Also there are several plugins which provide links to SignalK or use it.
Dashboard-Tactics by Petri [Canne] and Thomas [tom-r]
Dashboard-Engine by Steve [stevead]
TwoCan by Steve [stevead] primarily Nmea2000
Pypilot by Sean [boatalexandra] uses a subset of signalK

There is some discussion about SignalK starting with this post in Dashboard
and there is more discussion under the RPI threads about signalK and node Red.

There is another effort on github using signalK which should be of interest by Lance Berc called Polarize

I am certain that the plugins and users would benefit from this functionality, and hope that a revived team effort by interested opensource programmers can bring this project to fruition and completion in a healthy collaboration.

[conachair]

There's an excellent signalk app called KIP, one option as well as displaying signalk data in various dials it can also display an embedded webpage - if there was a opencpn plugin which could do the same then for guessing for most of us that's plenty. Having the option to be able to view signalk dashboards & influxdb dashboards would be just great

[bdbcat]

All....


Marketing hat on, what does it mean to say that "OpenCPN support Signal K"?



From a developer's standpoint, SK is very fragmented. All sorts of bits and pieces arranged in some "magic" fashion on the workbench, which in some environments occasionally produces great stuff. Drill down a bit, and we quickly get lost in philosophical discussions about "best" architecture, 10 year roadmaps, etc.



To make real progress, let us look at this from a user's perspective.
Can someone show screenshots of compelling UX from any source on generally available hardware (i.e. Win10 laptop) to start to focus our efforts?


Dave

[Moo]

Originally Posted by bdbcat

All....


Marketing hat on, what does it mean to say that "OpenCPN support Signal K"?



From a developer's standpoint, SK is very fragmented. All sorts of bits and pieces arranged in some "magic" fashion on the workbench, which in some environments occasionally produces great stuff. Drill down a bit, and we quickly get lost in philosophical discussions about "best" architecture, 10 year roadmaps, etc.



To make real progress, let us look at this from a user's perspective.
Can someone show screenshots of compelling UX from any source on generally available hardware (i.e. Win10 laptop) to start to focus our efforts?


Dave

Rather than have OCPN directly interface to the moving target of SignalK my opinion is that moving the data held in tracks, routes, marks, etc to a database would be of more use. Then NMEA data could be written to the same database making it trivial to use any of the external dashboards to display the data.

The database could be SQL but that is considered somewhat cumbersome these days. Influxdb is good for time series data but has issues in the way that that it subsampled (depending on what you want to display). Mongo could be a good choice.

[rgleason]

Would it be possible to have an OpenCPN signalK server running on any platform (not just RPI) alongside OpenCPN as an "assistant", providing services:

1. Gateway for translation of common closed protocols:

A. Nmea 0183 translation to/from SignalK (augmenting O's Nmea to translate)
B. Nmea 2000 translation to/from SignalK (using CANbus)
C. Seatalk 1 translation to/from SignalK (Seatalk 1 to Nmea0183 is available)

2. For example: Use Dashboard-Tactics and Dashboard-Engine data and calcs. Use the SignalK data with established analytical calculations special instruments.

3. Flexible display of instrument and historic data. Ability to reconfigure and create styles, etc. Ability to create graphic elements that respond to the data.

Integration of the SignalK data with the OpenCPN interface?
This is really a question. OpenCPN already handles the majority of data via Nmea0183. Should that Nmea0183 interface be completely rewritten to use SignalK?

I think one of the benefits would be to use the SignalK Server to translate Nmea2000 from instruments in newer chartplotter systems into SignalK and then Nmea0183, to be used by OpenCPN, as a first step. And then back to Nmea2000.

Then as the advantages become clearer, perhaps use the signalK server data directly in OpenCPN, with Nmea0183, Nmea2000, Seatalk1 becoming additional modules.

Or should everyone just build an RPI with a SignalK server?

[bdbcat]

Rick/Moo....


...and we immediately go back into jargon filled architecture without any obvious user benefit. Eyes glaze over....



We need some eye candy here.


Dave

[Moo]

Originally Posted by bdbcat

Rick/Moo....


...and we immediately go back into jargon filled architecture without any obvious user benefit. Eyes glaze over....



We need some eye candy here.


Dave

A database based routes tracks and marks system would have significant user benefits over the tedious and sluggish list system currently employed. The users would have a much speedier and flexible interface that would look exactly the same and no need for any jargon whatsoever.

What do you want eye candy for? and why do you think you need signal K to produce that?

Rick - signal K has nothing to do with Raspberry Pi