In what cases is SignalK needed?

[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

[bdbcat]

Jose...
From my perspective, the answer goes something like this:



1. NMEA 0183 is difficult to expand, and not network-friendly. Currently suffering from "add-on-itis".

2. NMEA2K is closed source, full of vendor-specific secret sauce.
3. SignalK is attempting, as one goal, to promulgate an open-source alternative to NMEA2K.
4. By implementing in sK OCPN, we help that process, by enabling real-world use of the code. We are materially helping to drive out inevitable bugs by seeing use on a variety of configurations. This we consider as our "contribution" to the sK effort.



Who needs sK on a reasonably complex OCPN installation? No one. But we (devs) sure appreciate those who do, and report results (and problems).


My 2 cents.
Dave

[SCarns]

I'll jump in on this:

You are correct that you don't NEED signalk. I didn't need it for a long time and was perfectly happy running on OpenCPN and my YachtDevices interface to my N2K network. My old boat had all 0183 stuff and OpenCPN was still my primary navigation software. It worked perfect on its own for me for a long time.

What got me going on SK as an end user (not a dev) was the fact that it integrated most of my existing boat data into one system. Battery monitor, solar charger, temperature guages, some fans/pumps with relays and other systems management are all parts I assembled myself into a system of boat management I can operate and navigate with while siting on deck with my iPad in hand has really changed the way I look at boat data. With the addition of some simple plugins, that data expands into WAY more data than I ever imagined. I have to admit, I secretly love showing the massive amounts of SK data on my phone to other sailors and watch their head explode!

Unlike most, I'm no longer beholden to the Raymarines and Garmins of the world. I even went so far as to build my own sensor for my holding tank, which has really helped improve life aboad, as I can actually plan pump-outs now, rather than waiting for the toilet to shut off once it senses a full tank, finding out too late when you need it most.

There are lots of other ways to solve these problems, of course. But for the price of a Raspberry Pi and some free software that speaks MANY marine navigation languages, is flexible, and (so far) forever expandable, SK is hard to beat. It is not for everyone, but I've really enjoyed my SK journey.

[flightlead404]

Originally Posted by SCarns

I even went so far as to build my own sensor for my holding tank...

deets or links? Its on my project list for the summer to do this for holding and fresh, possibly fuel.

[Tehani]

Dave, SCarns, thank you very much for your clear answers.

The problem I see is that, at the moment, there is no hardware that communicates natively in SignalK (Except Sean's Pypilot).

And I think that if this hardware (sensors, pilots, GPS, AIS...) one day begins to be seen in a generalized way, it would impose the use of SignalK in the same way that current manufacturers do with their proprietary PGNs. I think that the hardware conditions more by its own physical nature (It must be manufactured).
I am speaking from the point of view of a normal user, not a developer or a DIY nautical enthusiast.

However, I understand that NMEA cannot act against someone who develops hardware and software using reverse engineering, that is, analyzing and replicating the sentences and PGN used in commercial devices. That is true?
They did not invent the CAN bus, nor RS422 nor WiFi networks, not even J1939, which is the father of NMEA2000. Microcontrollers and bus drivers are not manufactured by NMEA and are available to everyone.

And meanwhile, one more "language" is added to this Tower of Babel...

[CarCode]

[QUOTE=SCarns;3594630... and OpenCPN was still my primary navigation software. It worked perfect on its own for me for a long time.
[/QUOTE]
But in your other post you write it always crashes...
See:

https://www.cruisersforum.com/forums...ml#post3594643

[verkerkbr]

there is navigation software like OpenCPN.

And you need data communication and transfer from one input to another sometimes with different data rates and different formats.

What is more logical to have marine data server running for all the incoming data and outgoing data, can be NMEA183 in different baud rates, NMEA2000 input and output with the help of a canbus adapter.

Canboat translates the digital signals from NMEA2000 to SK.

You even can input Seatalk 1 data in SignalK.

You like to have a multiplexer of all this data.

With two connections to OpenCPN in the SK format and one for transmitting route and waypoint data back to the signalK server.

I don't think it is a good idea to use the chart plotter with all these data streams at different baud rates.

It is not only for navigation data but it also can be used for other data.

And you can use MX Tommy Kip application as an instruments dashboard.

All in HTML format and can be used in every browser and can be transferred also via internet to remote places.


Bram

[Tehani]

Couldn't they have used any other support than json objects?

This makes development in embedded systems very difficult, with microcontrollers lacking RAM and FLASH. It definitely doesn't seem like a good solution to me to create small devices with sensors that speak SignalK directly to a network. (SignalK server node).

Look at the devices from AIRMAR, Maretron, Garmin, etc, etc: Inside a small block of resin they put depth, wind, GPS, etc, etc, sensors that speak and interact on the CAN bus. And all this with minimal energy consumption.
It would have been possible to use that extended CAN bus (29 bit identifier), with its security, priority and routing features, with a different structure than NMEA2000, if you want, simpler.

Currently, SignalK takes data from other networks and protocols to turn it into json damn strings. But from what I've said, I see it very unlikely that the day will come when a small sensor chip will run java, and thus be totally independent of NMEA and manufacturers.
I have found c code to generate and read json, but it also takes a lot of overload. At the moment, I'm convinced that a small device has better things to do than waste time processing json.

And if someone wants to communicate with the afterlife: Anything can be encapsulated in a TCP or UDP packet, not just json...

Sorry to be rude, I'm just trying to develop something in my domain for an open system like SignalK and running into these issues.
It is possible (hopefully) that I am wrong. If so, please state your reasons.

J.L.

[bdbcat]

JL...
Seriously, now.
I really would like to see some metrics that show that processing JSON is too much to ask of any modern microcontroller. Yes, I know that you (and I, too ) look at the JSON c code, and say "Wow, that looks heavy...".

But really, now, for a useful sensor processing 1Hz, or even 10Hz data streams, is it really too heavy to lift?
Are not the advantages of a fully portable, structured, extensible, open source protocol worth that lift?



Dave

[stevead]

SignalK is attempting, as one goal, to promulgate an open-source alternative to NMEA2K

Noble.

Other than hobbyists building their own hardware and software and a few vendors such as Victron and IKommunicate, I am not aware of any announcements from the major marine equipment vendors such as Ublox, Airmar, Maretron, Actisense, Garmin, Navico (Simrad, B&G, Lowrance), Raymarine, Furuno, Icom, Standard Horizon etc. regarding support for SignalK.

The planned successor to NMEA 2000 is OneNet, essentially the NMEA 2000 binary protocol carried over IPv6 and Ethernet. I expect that the vendors heavily invested in NMEA2000 will naturally adopt OneNet over time.

Another problem is the current SignalK Server implementation and its integration with existing NMEA 2000 networks, Great on Linux (including Raspberry Pi), but limited on Windows & Mac as only Actisense NGT-1 adapters are supported.

[Tehani]

Originally Posted by bdbcat

Are not the advantages of a fully portable, structured, extensible, open source protocol worth that lift?

The idea is good, but I think the implementation is not.

For something that should be silly, check out what we have:

https://json-c.github.io/json-c/json...object_8h.html

This separates the two worlds, and in this case makes it difficult for the data structure to be shared between a simple on-board data network (including autopilot), and the internet.
In fact, this concept together with many other developers in high-level languages, cause the need to constantly increase the power of the CPU. I think they are too tainted with the use of libraries. They lack the culture of saving, but it is easy to program like this.

I am using a uC with little RAM memory (less than 32Kb), FLASH (128Kb) and with a clock at a sad 72Mhz, and I communicate simultaneously (full bidirectional) in NMEA2000, Seatalk, 3 NMEA0183 by cable, USB, WiFi with two I2C sensors and with a SPI radio for remote control. All this in addition to calculating true wind, set and drift, declination, distances for the alarm system with AIS and Radar, and more. Just the json implementation requires me to have more than 125Kb of RAM and more than 350Kb of FLASH. Does not fit.

Now, those uCs have multiplied their price by 12 in the few places where they can be found. That is why I am developing a system with a cheaper substitute, with less capacity and slower. Regardless, it will be able to do the same as its brother, because I don't use the comforts of high-level designers.

According to Steve, OneNet is something like the vision I have for data communication. The NMEA2000 primitive frames are encapsulated within appropriate containers for higher level transport. It is the same thing that is happening now when we transmit NMEA0183 frames over WiFi. Why complicate life using a structure where less than 5% is useful data, and also in text format?

Not to mention the necessary hardware. I can't imagine those json packets circulating through an RS485, CAN bus or something simple and cheap. I agree that Ethernet is used to transmit the data volume of a radome, but for heading I consider it excessive.

Instead, it seems that "it is necessary to kill flies with cannon fire..."

[Tehani]

The way I see it, a SignalK concept without json would be wonderful...

[CarCode]

The way I see it, SignalK is something for sandbox gamers.

[nohal]

Originally Posted by Tehani

Just the json implementation requires me to have more than 125Kb of RAM and more than 350Kb of FLASH. Does not fit.

What implementation that is? Looking at https://github.com/markert/ArduinoJsonParser it seems it's memory requrements are 1-2 orders of magnitude lower.

I woud be interested in understanding how you plan to fit the OneNet encryption and PKI based authentication into the same uC.

[goboatingnow]

Would it be possible to add can communication to signal K. ( or LIN )