SignalK development ?

[conachair]

Originally Posted by blu3534

Thanks for your reply! - I meant, SignalK on top of NMEA 2000. As practically all devices are or will be NMEA 2000 you need a converter, e.g. iKommunicate, for data access. What good is it when you have a "modern 'web friendly' format which can be shared, processed and displayed on the latest web apps, mobile devices and cloud servers." when ~95 % of the relevant data comes from proprietary NMEA 2000?

That's not actually the case. At the moment the majority of large boat manufacturers sensor data will be nmea0183 and/or nmea 2k but already it's simple to add cheap robust non nmea based sensors to signalk - really opening up boat monitoring both local and web based. Barometer, temperature, voltage can be done simply and for very little outlay also easily sent to the main server (raspberry pi running openplotter being way ahead of the game right now) over wifi with a esp8266. Still very much in the "maker" field but software is around making the set up menu driven. NMEA2k is just too limited and was never forward thinking enough to cover the wealth of data types possible now. It's already ancient.


Also the more forward thinking manufacturers like victron are seeing the potential of open source and embracing the community so already signalk apps exist to control and monitor victron devices with more in the pipeline.

The only reason NMEA is so ubiquitous is because they largely have a monopoly on data sharing/comms between marine devices. Hopefully at some point manufacturers will see the market in designing in signalk as well as nmea and get the ball rolling away from the stranglehold nmea have. Let's hope so , NMEA just aren't up to the task.

[merrimac]

Originally Posted by blu3534

You probably mean Canboat? Canboat is GPL3 and thus, unfortunately, forget it: no sane (commercial) device manufacture will ever touch such source.

Which was precisely my intention.

Originally Posted by blu3534

No developer that potentially is interested in a (liberal) NMEA 2000 protocol re-implementation attempt can look at Canboat.

Yes you can, you just need to abide the GPL.

Originally Posted by blu3534

I am not aware that Canboat did reverse engineer a meaningfull subset of PGNs. Is there a comprehensive database anywhere?

I reverse engineered all NMEA PGNs, from scratch. Most work was done in 2009-2010. I used only open available sources and an Actisense NGT-1 with CANBoat evolving and interpreting the bus content. Later other people started contributing, but by that time I had 99% of PGNs covered. The current database is even bigger than that of the NMEA because I also cover proprietary PGNs from various manufacturers.

The 'real' definition is a .h file: https://github.com/canboat/canboat/b...analyzer/pgn.h
but the code contains a generated XML file: https://github.com/canboat/canboat/b...lyzer/pgns.xml
and a generated JSON file: https://github.com/canboat/canboat/b...yzer/pgns.json
These files can be included in other projects. OpenSkipper is one example.

Now in 2018, with Signal K present, I think there is no reason why the open source world should use NMEA 2000 or a clone thereof. Just go directly past start, do not pay 2000$, and implement Signal K instead.

[teppokurki]

Originally Posted by blu3534

Thanks for your reply! - I meant, SignalK on top of NMEA 2000. As practically all devices are or will be NMEA 2000 you need a converter, e.g. iKommunicate, for data access. What good is it when you have a "modern 'web friendly' format which can be shared, processed and displayed on the latest web apps, mobile devices and cloud servers." when ~95 % of the relevant data comes from proprietary NMEA 2000?

For a certified connection to NMEA2000 you need a certified device. In addition to iK there's also NGT-1 and open source software for the conversion to SK. DIY CAN solutions exist.

Originally Posted by blu3534

For the "modern web friendly" top layer, SignalK is probably fine. But it won't change anything on the foundations, right? Do you forever want to forget about a more rigorous 'open boat approach'?

To me the best way to advance the 'open boat approach' is to provide a solution that is open and free and make it interoperable with the current mainstream system.

What would you have done? Forego compatibility with NMEA, build everything from scratch and wave the Jolly Roger? Do you think that would have yielded something usable, like what we have with SK in OpenPlotter? Even OpenCPN is fundamentally NMEA0183 driven.

Originally Posted by blu3534

(For a more fundamental approach I suppose JSON schemas would need to evolve into something else. Don't want to complain about the specification (certainly a lot of hard work went into it and it is done well!), but still, it seems difficult to get an overview from e.g. https://github.com/SignalK/specifica...r/gitbook-docs, and https://github.com/SignalK/specifica...as/vessel.json really is not easy to read.

I totally agree, JSON Schema is not for the faint of heart. But did you not find the path from signalk.org to documentation and to Appendix A, the vessel keys reference? Appendix A: Keys Reference (Vessel) · Signal K Documentation ? Most of the time you don't need the JSON schema at all.

Originally Posted by blu3534

Wouldn't protobuf etc. be able to represent the scheme more clearly?)

While Signal K schema is important to have a shared meaning for the data keys you can make use of the basic SK model without it. In fact SK server is mostly ignorant of the schema and you can extend the schema by just adding your own keys. Others will not understand the meaning of your keys, but they will be able to receive, store and display your data. This makes Signal K inherently more extensible, riding on JSON's loose structure

I fear something like Protobuf would lead to NMEA2000 v2: a system where you must have intimate knowledge of the message data structures to make use of them. See my related post.