Signal K

[motu42]

Originally Posted by Axel_G

At 200 msg/sec and 500ns per message it is only 100µs/s (Micro, not Milli) for parsing. Or 0.01%.

oops - yes, 500ns was an arbitrary guess. I started with 1ms. then 'halved' it to 500ns Should have been 0.5ms. But you see the compounding effect when you have high volumes of messages, or you parse low volumes many times.

[motu42]

"I'm not convinced today that a Signal K Server is the panacea."


There is no such thing as 'Signal K Server'. I think you are referring to the node server implementation, which has no official (separate) name, so its usually referred to as 'Signalk', or 'Signalk Server'


One thing that has hindered Signalk immensely is the confusion that causes between the protocol (the json messages), the data model (the keys) and the implementations.

The protocol and the data model are the language. Its a replacement for NMEA0183, or N2K. But like them, it does nothing with out a device or implementation.


You dont need to use the node server, (or artemis), or any other implementation. As bdbcat points out, you can build your own as an opencpn plugin, or stand-alone C++, or mix and match with devices like iKommunicate.

But I think you point out an important requirement to the solution - it must install at least as easily as the current opencpn

Thats not actually difficult, just a task on the list of TODO's

[motu42]

Originally Posted by bdbcat

motu42 (or anyone)....


I have not actually worked with N2K and SK, so my practical experience is minimal.
Please describe an environment that might generate 1500 messages/second in real life.


Thanks
Dave

Probably not a level you will see in a typical cruising vessel today. In the future (assume an openCPN version with social features) a significant additional volume will come from off-vessel, weather, location of mates, race data, etc, and from additional measurable sources (aka electric system).


But by then RPi's and laptops will be faster too, so maybe thats offset?

[Axel_G]

Originally Posted by motu42

oops - yes, 500ns was an arbitrary guess. I started with 1ms. then 'halved' it to 500ns Should have been 0.5ms. But you see the compounding effect when you have high volumes of messages, or you parse low volumes many times.

Actually I think 500ns is much closer to reality. A Raspberry Pi is running at >1GHz which means it can do approx. one operation per ns. Actually even more than that as it is running faster than 1 GHz and it can do operations in parallel.



A comparison of four bytes or four chars takes only one operation in 32 Bit mode, then you either leave the loop or go on with the comparison. However you need some fetching to do first, if you're unlucky you have a caching problem. So 500 ns would probably be good for a comparison of 200 bytes (or maybe one Signal-K frame). It may be a little more that that but not a factor of 1000. So in any case we are talking microseconds. Handling 1000 Signal-K messages per second make up only 1% of the Raspberry CPU throughput of one core.



So the point I am trying to make is that compared to all the other stuff the CPU has to do it does not really matter if it has to compare a 200 Byte signal-K message, a 40 Byte NMEA message or a 100 Byte whatever intermediate format. The CPU load is later on the display part. So the CPU load should probably not be a reason to go for one way or the other.



But from a users point of view whatever information is not available as an intermediate coding coded in OpenCPN cannot be handled or displayed. With Signal-K at least some information can be taken from the frame and displayed.


I had exactly that problem trying to display battery data. In the end I ended up inventing new NMEA codes for my battery module and adapting dashbord to show that.

[Tehani]

Originally Posted by stevead

Making for a complex network configuration that 'Joe Boater' may have difficulty configuring.

Which Signal K Server implementation? An expensive iKommunicate box ? An inexpensive RaspberryPi running OpenPlotter which non Windows/Mac users may find difficult ?


Or Signal K Server running on Windows (Node JS etc) and only able to connect to NMEA 2000 networks with an Actisense NGT-1 ? And what of our poor Mac user base?

I love the idea of Signal K schema & JSON to communicate between display devices. However I'm not convinced today that a Signal K Server is the panacea.

From reading this thread there are a lot of developers implementing technology for technology's sake and not fully understanding our user's needs.

As always Steve, I completely agree. I was going to say that, but the difference of meridian hour has made you answer before ...
Motu42, I think you have to reflect on the equipment compatibility of current and future users. For example, today, anyone can put a GPS dongle directly on the PC / Rasp. That is economical and simple and it is not advisable to force any other device (SignalK or whatever) in between.
In your next intervention you "curled the curl" with the autopilots. I see that you insist again on putting an IKommunicate between Ocpn and the pilot.
We can see logical analyzer screenshots over N2k. When all the instrumentation, pilot and GPS work on that bus, I assure you that the traffic is intense. Some GPS packages are gigantic, and that is only the beginning, because when we use a GNSS receiver, the volume of data on all satellite constellations is huge.
The problem I see is that N2k has a hardware message priority mechanism, typical of CAN bus; that way, even if there is an overload, single packet messages with high cadence and priority are not delayed at all (and we talk about 1-2 mS). Can something like this be done with what is being proposed here?, I do not know. Communication with the pilot must be done in real time, and this is an obligation for Ocpn if it is the intermediary of HDG, AWA, AWS, COG, SOG and Attitude. Less critical is XTE and BRG.

Teppo, We are insisting on a key point, and I think Dave has shown it: Ocpn can't leave NMEA0183. You cannot leave your users abandoned. SignalK can be a good system for exchanging data with third-party networks, and with the restrictions I have commented, but nothing more.

José Luis.

[Tehani]

Some more things:
It is possible for someone to say that N2k goes only to 250kbs and that an ethernet network goes to 100Mbs or more. Of course, surely radar images, virtual desktops and much more can be superimposed at that speed.
I only tell you that I am a friend of simplicity, and I think that Ocpn users are too.
Well, I think that so fantastic forces us to put ethernet routers on the ship. You have to look for cheap routers, with low consumption, at 12v and that are also IP65... I believe that, but if someone could draw the entire network here, I would greatly appreciate it.

J.L.

[rgleason]

Guys, you all come from different experiences, knowledge and perspectives. You all have an interest in Opencpn and far more programming experience that I have.

The idea is to keep an open mind, learn and contribute your knowledge and experience that is relevant so we find a good way forward. It is perfectly ok to state your concerns, just respect each other please.

There may be two (or multiple) approaches that fit within the development framework chosen, and still address the communication problem. Fast effective software (main app + plugins) to reduce cpu load and offloading programmed hardware devices can coexist. This thread is intended to inform the way forward.

Thank you All!

[sailwing]

Hi everyone, just a quick question, how do I set sampling frequency for something like a temperature sensor in Signal K?

[motu42]

Originally Posted by sailwing

Hi everyone, just a quick question, how do I set sampling frequency for something like a temperature sensor in Signal K?

The sensor sends data at whatever frequency its configured to. Depending on the sensor you may be able to configure this via signalk. Signalk K receives all the sensor messages into a time-series db.



You can subscribe to the signalk server at whatever frequency you want data, it will average real values over that time period and send them.

[kev_rm]

video and autopilot response times are total edge cases in the ecosystem of boat telemetry. of course you would not use JSON for that. Also, for the record, OpenCPN is not a flagship of modern development. It's 93% legacy frameworks.

What else is interesting is there's no discussion about the value of something being OPEN vs closed and reverse engineered.

[motu42]

Originally Posted by Tehani

Motu42, I think you have to reflect on the equipment compatibility of current and future users. For example, today, anyone can put a GPS dongle directly on the PC / Rasp. That is economical and simple and it is not advisable to force any other device (SignalK or whatever) in between.

Signalk, and complex networks onboard are not an all or nothing thing for Signalk/OpenCpn. You could embed a Signalk as a plugin in OpenCPN, and support both signalk and current methods. Or you could use separate servers and a small onboard network.

I use a USB GPS. I just plug it into my RPi or laptop, and its found and used by signalk, just the same as opencpn does. Same for my iCompass and wind instruments (which are on usb/serial)

In your next intervention you "curled the curl" with the autopilots. I see that you insist again on putting an IKommunicate between Ocpn and the pilot.

I'm not insisting on using an IKommunicate or any other N2K gateway. Its just an easy and robust solution. You can just attach the autopilot NMEA0183 to the PC/RPi as you do now, and an embedded Signalk will send the data out.

How does OpenCPN currently deal with N2K autopilots?

....
The problem I see is that N2k has a hardware message priority mechanism, ... Communication with the pilot must be done in real time, and this is an obligation for Ocpn if it is the intermediary of HDG, AWA, AWS, COG, SOG and Attitude. Less critical is XTE and BRG.
...
José Luis.

Signal K is just as efficient as OpenCPN at this (assuming similar hardware), I dont see why there would be any practical difference?

[motu42]

Any discussion of this kind gets very complex quickly as each participant vocalises their views, from user to deep tech. (me included). So I want to summarize the main benefits of signalk to opencpn again.

1) An open-source language for data transfer, easily extendable by any-one, avoiding the restrictions of NMEA0183, and removing dependency on it.

2) Compatibility with the internet, send and receive off-board data as easily as on-board data. Opens up data sharing and social use cases.
3) Provides a solution to multi-user OpenCPN chartplotters and web browser solutions, and scalability options for power users.

4) Provides better integration with NMEA2000 (N2K), and OneNet if it ever arrives :-)
5) Offloads the work in maintaining NMEA* data integration, and provides a simple data model to work with in OpenCPN.


I see a few must-haves:
1) Maintain compatibility with current users and devices.
2) At least as easy to install and use
3) At least as performant


Sure there will be problems, compromises, and sweat to make it work, but thats software.



Do you see these benefits as positive ?
Have I missed any must-haves?

Are there any blockers Ive missed ?


I guess at a high level I'm trying to gauge the mood on this integration?

[conachair]

Originally Posted by sailwing

Hi everyone, just a quick question, how do I set sampling frequency for something like a temperature sensor in Signal K?

Probably the ideal temperature sensors are ds18b20. Get the temperature as often as you want, can't remember top speed but more than any of us will ever need. Set up either through node red or there's an app which I haven't used.
Pyssel: SignalK, measuring temperature
I use an esp32 and send signalk from various sensors over wifi.

[conachair]

Originally Posted by motu42

The sensor sends data at whatever frequency its configured to. Depending on the sensor you may be able to configure this via signalk. Signalk K receives all the sensor messages into a time-series db.



You can subscribe to the signalk server at whatever frequency you want data, it will average real values over that time period and send them.

All wrong im afraid. 1 wire temperature sensors wait until you ask before sending data, you can't tell them to send once a second or whatever.
SigK server turns the data into sigK and sends it out, you *can* save it to a database as well with wn app which is great to spot subtle trends in temperature.
Never heard of subscribing to a web socket feed at a certain 'frequency'.

[motu42]

Originally Posted by conachair

All wrong im afraid. 1 wire temperature sensors wait until you ask before sending data, you can't tell them to send once a second or whatever.
SigK server turns the data into sigK and sends it out, you *can* save it to a database as well with wn app which is great to spot subtle trends in temperature.
Never heard of subscribing to a web socket feed at a certain 'frequency'.

This particular query is better dealt with at signalk.org, its not about actually opencpn/signalk integration


And I beg your pardon but I wrote the Artemis server, worked on the design of signalk from day 1. I assure you it does subscriptions over websockets and almost every other transport too. See https://signalk.org/specification/1...._protocol.html


Furthermore there is nothing in the original query about a 1-wire sensor, just a temperature sensor. I assumed it was a smart sensor that sent periodic pings.