In what cases is SignalK needed?

[SCarns]

Originally Posted by CarCode

But in your other post you write it always crashes...
See:

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

I didn't write that OpenCPN always crashes. I wrote that,since I updated the OpenDraw and Squiddio plugins, it crashes on exit. That has happened within the past couple of weeks and, as I pointed out on that thread, has determined that there is indeed an error, which I have no doubts will get fixed.

Isn't that part of this process? Identifying issues to help make it better?

sc

[Tehani]

Originally Posted by nohal

I still do not completely understand what your problem actually is.

I go back to the beginning.
It did not expose a problem, but a question. Being a bit more precise:

In which cases does OpenCPN need SignalK?
Please.

[nohal]

Originally Posted by Tehani

I go back to the beginning.
It did not expose a problem, but a question. Being a bit more precise:

In which cases does OpenCPN need SignalK?
Please.

OpenCPN does never need SignalK, it works just fine without it.
SignalK is one of the many possible ways to implement a set of use cases where OpenCPN and diverse external systems are interested in interacting with each other.
It has advantages, like being open, extendable, pretty well defined, easily implementable on a wide variety of platforms and backed by an active developer community. And also it's own drawbacks, like possibly being more resource demanding than some of the other available solutions for the same set of use cases, which certainly is more important for some of the other systems that might be interested in the interaction than for OpenCPN though.

[mgrouch]

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

I think SensESP can communicate SignalK.

https://github.com/SignalK/SensESP

[bergius]

Originally Posted by Tehani

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).

SensESP seems like a nice way to integrate Signal K with microcontrollers: https://github.com/SignalK/SensESP

I haven’t played with it yet, but I’m planning to integrate some legacy instruments that way over the summer.

[Tehani]

Originally Posted by bergius

SensESP seems like a nice way to integrate Signal K with microcontrollers: https://github.com/SignalK/SensESP

I haven’t played with it yet, but I’m planning to integrate some legacy instruments that way over the summer.

Well. Now think about what physical medium Signalk will send from sensors, GPS, AP, etc:
Ethernet, WiFi?, RS485? CAN bus? (I discard RS422 for its need to multiplex later).
The first two have good bandwidth to send SignalK without using FlatBuffers, but a WiFi device consumes a lot of power and some are wary of its reliability, and Ethernet needs special (expensive) routers and connectors for the marine environment. The others, which are cheaper and easier to implement, I think would require FlatBuffers for reliable speeds. I don't go into details about bus control.

It is necessary to assess the cost and reliability of the cables and connectors according to the bitrate that we are going to use (I insist: we are talking about a marine environment). And also the consumption and cost of the bus drivers in the implementation.

Some examples:
We have seen implementations of wireless wind sensors. These are powered by small solar panels. In these cases, data compression is the maximum possible, since the transmission time must be minimal to preserve the battery.
An N2k speed and temperature sensor can consume less than 20mA at 12v. Have you seen how much an ESP32 consumes even without activating WiFi? Take a look at this interesting article:
https://diyi0t.com/reduce-the-esp32-power-consumption/

This is not a game for amateurs, what we are trying to do is define an Open standard with the necessary requirements for use in a marine environment, that is as cheap and reliable as possible, with low consumption, and also that is easy to install, because Not all users are DIY lovers.

I am sure that a solution that pays attention to these requirements will be the only thing that will allow a long life for SignalK, or an equivalent.

[nohal]

I really miss your point in jumping between OSI layers 1 through 7 and blaming layer 7 stuff for not addressing layers 1 and 2, but still will once more try to answer:

There are plenty of proven technologies for low OSI layers already available and already used even by NMEA, be it RS485 for NMEA 0183, CANBus for NMEA2000 or Ethernet for NMEA OneNet, so I think any discussion about that is pointless as you have plenty to choose from.

Ethernet does not need any special routers for marine environment (I have taken a few apart and inside they were the same cheap stuff as any other unmanaged Ethernet switch out there) all it needs is waterproof housing, exactly as any other technology you use on the physical layer in a marine environment. Why are they "expensive"? I really don't know (and don't care), why iPhones and Samsung Galaxys are?

Whenever you choose an unsuitable technology for a task, you may sure try to use that as an example of that technology "not being usable", but please don't expect everybody to agree with you in such a case.
A wind sensor implemented with an oversized uC and using WiFi for transfer of the trivial data it produces, while at the same time lacks the means to power it, certainly falls into this category for me.
Using an ESP32 in something that just measures speed and temp and has to handle a few data messages (that in case you were really resource constrained would better be hardcoded without using any frameworks to construct or decode them) is exactly the same case.

Non-"DIY lovers" probably don't need SignalK or any such thing at all and looking at them they, to me, seem reasonably happy using the proprietary communication protocols and certified cabling like the ones defined by the NMEA standards and delivered by the NMEA members with paid access to those standards. Also I don't see them complaining about the way these parties make them evolve, so can you please explain why they would (or should) be interested in a different standard replacing the currently available options at all?

Also please try to understand OpenCPN is a software package running on "high power" devices that nowadays usually by default only have a subset of Ethernet, Wi-fi, Bluetooth and USB connectivity, so that is where we primarily receive our data and that is what we are interested in, for physical and link layer discussions, especially related to SignalK transfer, you might probably have better luck in the SignalK community.

[Tehani]

Originally Posted by nohal

There are plenty of proven technologies for low OSI layers already available and already used even by NMEA, be it RS485 for NMEA 0183, CANBus for NMEA2000 or Ethernet for NMEA OneNet, so I think any discussion about that is pointless as you have plenty to choose from.

I think you understand me, but you don't want to admit it.

Whenever you choose an unsuitable technology for a task, you may sure try to use that as an example of that technology "not being usable", but please don't expect everybody to agree with you in such a case.

That is why I would like to reach an agreement on the way forward. At no time have I said that I want to impose something.

Non-"DIY lovers" probably don't need SignalK or any such thing at all and looking at them they, to me,...

Well this is an opinion. However, I think it is possible to develop standard and Open hardware (in the style of Pypilot, or even with dedicated PCBs) for the rest of the elements on board. OpenCPN would gain popularity even among users who are not fond of experiments.

Also please try to understand OpenCPN is a software package running on "high power" devices that nowadays usually by default only have a subset of Ethernet, Wi-fi, Bluetooth and USB connectivity, so that is where we primarily receive our data and that is what we are interested in,

Those "High power" devices are already starting to get hotter than expected.

for physical and link layer discussions, especially related to SignalK transfer, you might probably have better luck in the SignalK community.

It seems to me that in the SignalK community they always start from the base of a hardware based on a proprietary standard (NMEA0183 and NMEA2000) always using a gateway, and I don't see that there is talk of a native SignalK from basic devices. I would say that this is indeed imposing restrictions.
Since that is not the idea I am proposing, it is possible that it will break their schemes and they will not take it into account. Actually I'm listening to you: As you say: "Feel free" to use something else without restrictions.

But let's do it with some technical criteria and with consensus.

[nohal]

Technical criteria from our side is very simple: We want an open protocol delivered over anything reasonably supportable on a computer or phone, that means Ethernet (Wired or wireless) or serial (Physical, or virtual over USB or Bluetooth). SignalK already provides exactly that for us.

Did I miss any of our requirements?

What are yours? Why you can't use some already existing protocol/standard? And how can we help you?

I just out of curiosity implemented a POC solution for SignalK schema compatible data transfer over protocol buffers (over anything on OSI layers 1-5). The message equal to your earlier example with GPS position was 137 bytes, after lightly (using a common dictionary replacing the full string paths with numerical ID) optimizing the protocol, the size was further reduced to 64 bytes. All that maintaining the full flexibility of the universal SignalK schema. Honestly it did not exactly convince me that we need to immediately start to create some other solution. And if it did, there already is highly optimized industry standard named NMEA2000, so I would probably not be wasting my time and used just that.

And BTW, PyPilot uses SignalK, so it is probably not a good example against it, it actually is quite a good example that your statement "they always start from the base of a hardware based on a proprietary standard (NMEA0183 and NMEA2000) always using a gateway" is a total nonsense.

[emilecantin]

Originally Posted by Tehani

It seems to me that in the SignalK community they always start from the base of a hardware based on a proprietary standard (NMEA0183 and NMEA2000) always using a gateway, and I don't see that there is talk of a native SignalK from basic devices.

That's where the community starts because that's where the current market is. A lot of people developing / using SK aren't starting from scratch, they have a boat with some electronics on board. Any new system will be much easier to adopt if it interoperates with existing standards, which is why you see that emphasis in the community.

That's not to say there isn't hope of more native SK, but it's commonly understood that it'll take time before we see a boat using only SK. Progress is happening, though: somebody already linked SensESP which is a good option for DIY devices, and there is at least 2 chart-plotting options with native support (one of which is the subject of this very forum).

So, if you have only SensESP devices aboard, and are using OpenCPN for navigation I guess you can have a 100% SK boat.

Originally Posted by Tehani

I think you understand me, but you don't want to admit it.

I think it's you who doesn't understand his point. SignalK is really just a data format. What wires (or non-wires) carry it is really no its concern. As long at the bytes make it to the SK server, it will parse them and integrate them in the main data model. This can happen over serial (UART pins on a Pi), USB-serial, wifi, ZigBee, ethernet, laser / smoke signals, even Bluetooth. Heck, it could even work on a RFC1149 network.

Use whatever transport method suits you. Wifi is ubiquitous, easy / cheap to integrate, and doesn't need weatherproof cables. That makes it an obvious choice, but not the only one. If power is a concern, perhaps Bluetooth (or even BLE) would be a better option.

If you want to communicate directly with OpenCPN, you'll need to limit yourself to the physical interfaces available on the computer running OpenCPN, though.

Originally Posted by Tehani

An N2k speed and temperature sensor can consume less than 20mA at 12v. Have you seen how much an ESP32 consumes even without activating WiFi? Take a look at this interesting article:
https://diyi0t.com/reduce-the-esp32-power-consumption/

The N2k sensor you quote is consuming 240mW (12V x 20mA). Remember that the ESP32 operates at 3.3V, so even the 51mA "reference" consumption from your article translates to only 168mW. Add to that the sleeping abilities of the ESP32, and you can make something that's pretty low-power. I agree it's not the best chip from that perspective, though. However, it's among the cheapest and well-known ones in this area.



All in all, I'm not sure why you hate SK this much. Don't use it if it doesn't suit your needs. If your chip is too underpowered to support it, use another one. It's not 1969 anymore, processing power shouldn't be a limit.

[Tehani]

Originally Posted by Tehani

An N2k speed and temperature sensor can consume less than 20mA at 12v.

Sorry I said that without looking. Here you have the real data: 60mW. 5mA at 12v.

Emilecantin, if you add to those 168mW, the losses in the switching power supply (12v -> 3.3v), and a little consumption of the sensors and drivers, the final result can be perfectly almost 200mW.
The consumption of a wind vane/anemometer would be similar.

I'm not against the SignalK concept, I'm just saying that I find JSON too heavy to fit into this type of product.

So, I think you have already solved my doubts. Thank you very much.

[250224]

Originally Posted by nohal

Non-"DIY lovers" probably don't need SignalK or any such thing at all and looking at them they, to me, seem reasonably happy using the proprietary communication protocols and certified cabling like the ones defined by the NMEA standards and delivered by the NMEA members with paid access to those standards.

With NMEA2000(R) you have the specification down to the bits <--> with SignalK there are .json files but not something like e.g. https://jmap.io/spec-calendars.html which (for me) makes a real specification. Maybe I must eat my words later, but SignalK seems wishy-washy, fatal for both DIY and non-DIY lovers when you need a dependable standard.

After my post I googled a bit (forum, github) and came across a statement by Sean:

"I am beginning to realize that signalk is not about making a concise standard as I would prefer, but more like a soup where any available ingredient is added" [https://github.com/SignalK/specification/pull/624 and https://github.com/SignalK/specifica...ull/624/files]. -- This whole issue is strange. It seems that for this steering part (https://github.com/SignalK/specifica.../steering.json -- do you call such a snippet a specification?) there was no real discussion what should go into the spec (it came from a raymarine user), the spec-snippet is purely theoretical ("Lets be honest: no one is using this standard for anything yet"), the current state was unworkable for Sean, where is the "process" (discussion) when modifying properties (see e.g. https://github.com/SignalK/specifica...1b2f0d4c97b58f), it seems quite arbitrarily? -- This makes me wary. Are the other parts in the same situation as this steering part?

Stepping a bit back and checking the timeline (https://github.com/SignalK/specifica...s/contributors), it seems that SignalK is dead. A nice project. But it failed. The aim for an open-source NMEA alternative remains. (As mentioned: maybe I must eat my words and sit in the corner But this is my current assumption).

On the other side, SensESP looks great. Still, the SailorHat they sell is not exclusive SignalK but supports NMEA2000 and the CAN bus (https://hatlabs.fi/product/sailor-ha...v=cd32106bcb6d).

[Tehani]

Originally Posted by emilecantin

All in all, I'm not sure why you hate SK this much. Don't use it if it doesn't suit your needs. If your chip is too underpowered to support it, use another one. It's not 1969 anymore, processing power shouldn't be a limit.

True, power is not a limit. The limit is that either they are not available on the market, or their price has multiplied. And the price of the rest of the components has also increased considerably.

We will see how the ESP32 evolves. At the moment it is still cheap, but we are dependent as in almost everything else, they manufacture it in China...

[Tehani]

Originally Posted by blu3534

https://github.com/SignalK/specifica.../steering.json

I didn't know that. What a disaster!!!

[nohal]

Originally Posted by blu3534

With NMEA2000(R) you have the specification down to the bits <--> with SignalK there are .json files but not something like e.g. https://jmap.io/spec-calendars.html which (for me) makes a real specification. Maybe I must eat my words later, but SignalK seems wishy-washy, fatal for both DIY and non-DIY lovers when you need a dependable standard.

I don't see much difference between your link and https://signalk.org/specification/1....elsBranch.html, but at the other hand I read the schema JSON instead anyway as it is faster and provides the exact information with all the details.

After my post I googled a bit (forum, github) and came across a statement by Sean:

"I am beginning to realize that signalk is not about making a concise standard as I would prefer, but more like a soup where any available ingredient is added" [https://github.com/SignalK/specification/pull/624 and https://github.com/SignalK/specifica...ull/624/files]. -- This whole issue is strange. It seems that for this steering part (https://github.com/SignalK/specifica.../steering.json -- do you call such a snippet a specification?) there was no real discussion what should go into the spec (it came from a raymarine user), the spec-snippet is purely theoretical ("Lets be honest: no one is using this standard for anything yet"), the current state was unworkable for Sean, where is the "process" (discussion) when modifying properties (see e.g. https://github.com/SignalK/specifica...1b2f0d4c97b58f), it seems quite arbitrarily? -- This makes me wary. Are the other parts in the same situation as this steering part?

How exactly do you imagine a more "professional" workflow in the new volunteer powered open source project that has to replace SignalK? What do you expect can be done better to convince the NMEA cartel members to start implementing this new open protocol after spending decades protecting that cartel and it's "secrets" from everybody?

Stepping a bit back and checking the timeline (https://github.com/SignalK/specifica...s/contributors), it seems that SignalK is dead. A nice project. But it failed. The aim for an open-source NMEA alternative remains. (As mentioned: maybe I must eat my words and sit in the corner But this is my current assumption).

I see commits to SignalK specs and software every day, but maybe we have different perception of "dead".

Don't take me wrong, I do not think SignalK is perfect and the only possible solution, but reading your posts I really don't have a feeling that besides the FUD you are offering any solutions or alternatives to be considred, so we unfortunately still have no better option at hand.

Looking for example at NMEA0183, don't you have a feeling it is like soup where any available ingredient is added? I certianly do.