In what cases is SignalK needed?

[muttnik]

Originally Posted by emilecantin

SignalK isn't optimized for your use-case (hardcore embedded low-power usage), it's optimized for ease of developing other software around it.

Indeed: this is the bottom line.

https://www.youtube.com/watch?v=siPxyOxeQBc

7 or 8 years ago I was having the discussion about constrained devices on the signal k google group. Writing a complete json parser in c is a lot more hassle than decoding a known binary format. Using a pre-written json library adds bloat to your C code and then implies portability issues when someone wants to compile it for some wierd router running a netbsd variant. But signal K wasn't written by or for C coders working with constrained devices: it was written by and for people developing in high level languages which all have json support trivially available on devices and 802.11 networks which aren't tightly resource constrained. And that represents the majority of people writing and using open source sailing programs.

[Tehani]

Originally Posted by nohal

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

I don't see it that way. NMEA0183 has evolved by adding certain fields at the end of some sentences that already existed. So an older device can still read them.

And it is normal that other sentences are added according to the news: AIS, DSC, etc. All of this is documented and tied to a version number. Increased accuracy in some fields may have been a problem for devices with poor software, but this is not attributable to NMEA.

It's also reasonably human-readable, and while I prefer binary format, I think it's pretty compact and easy to sync.

[nohal]

Originally Posted by Tehani

I don't see it that way. NMEA0183 has evolved by adding certain fields at the end of some sentences that already existed. So an older device can still read them.

And it is normal that other sentences are added according to the news: AIS, DSC, etc. All of this is documented and tied to a version number. Increased accuracy in some fields may have been a problem for devices with poor software, but this is not attributable to NMEA.

Where can I access some freely available documentation for this open format? The only official source I am aware of, https://www.nmea.org/content/standar..._0183_standard, does somehow want me to pay 2000 - 7500 USD for the documentation of the standard.
Or do you refer to the fruits of decades of reverse engineering performed by the world-wide community that resulted in the existence of https://gpsd.gitlab.io/gpsd/NMEA.html? Reading the very first page there does seem like the authors are not exatly excited about the standard.

I think I don't see any difference in the evolution process of SignalK, stuff is also being added to it as required and documentaion improved over time. Or do I miss something?

It's also reasonably human-readable, and while I prefer binary format, I think it's pretty compact and easy to sync.

Yes, it is somewhat human readable.

I am happy that you are happy with NMEA0183 and wish you luck using it. But other people are certainly not, some of them even did something to address their problems with it by creating SignalK.
For my needs, SignalK (or anything else ofering similar feature set) has the potential to address many of the problems NMEA0183 causes to me and I so far do not have any new problems caused by it's design.

I will gladly personally implement your extensions to the NME0183 protocol (need thereof you keep suggesting) as soon as they get included to the standard. Or in case they make sense for OpenCPN even if they will be in the $Pxxx vendor specific domain.

[mgrouch]

Originally Posted by Tehani

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

Ethernet, USB, or WiFi. Just as many marine data multiplexers.

[mgrouch]

Originally Posted by Tehani

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.

SensESP for ESP32 and documented sensors IS such open hardware platform.

PyPilot is running on lower power Pi with multiuser Linux OS.

If you want something in between
you can use OpenWrt router hardware.
It will use less power than pi. It will not have graphics chip. It will still be Linux. Just OpenWrt Linux.

So there are 3 options at least for hardware platforms:

1. MCU like Esp32 which you program on bare bones APIs. There is no multiuser OS.

2. OpenWrt supporting hardware. Multiuser Linux OS. No graphics card at all. Low power usage.

3. Low power pi. Like pi zero. Multiuser Linux OS. video card.

4. Android devices. Like the ones for cars. No true free OS. But you can use Android OS.

[Tehani]

Originally Posted by nohal

Where can I access some freely available documentation for this open format?

https://www.plaisance-pratique.com/I...NMEA0183-2.pdf

The complete manual is very interesting, but what you ask for is starting on page 138:
https://www.u-blox.com/sites/default...X-13003221.pdf

I will gladly personally implement your extensions to the NME0183 protocol (need thereof you keep suggesting) as soon as they get included to the standard. Or in case they make sense for OpenCPN even if they will be in the $Pxxx vendor specific domain.

Read the XDR sentence in the first link. I think it would be nice if OpenCPN were to adapt to the standard nomenclature of sensors and units.
You will also find the sentence RPM. Its implementation in O would be welcomed by many users.

[Tehani]

Originally Posted by mgrouch

SensESP for ESP32 and documented sensors IS such open hardware platform.

PyPilot is running on lower power Pi with multiuser Linux OS.

If you want something in between
you can use OpenWrt router hardware.
It will use less power than pi. It will not have graphics chip. It will still be Linux. Just OpenWrt Linux.

So there are 3 options at least for hardware platforms:

1. MCU like Esp32 which you program on bare bones APIs. There is no multiuser OS.

2. OpenWrt supporting hardware. Multiuser Linux OS. No graphics card at all. Low power usage.

3. Low power pi. Like pi zero. Multiuser Linux OS. video card.

4. Android devices. Like the ones for cars. No true free OS. But you can use Android OS.

There are other worlds, I recommend you to explore in the ARM Cortex-M communities, and IDE environments AC6, Keil, IAR, Atollic TrueSTUDIO, etc.
Example: https://community.st.com/s/
You will see the power they offer for professional software debugging.

You can also take a look at this:
https://www.freertos.org/
(An adaptation is used for the OS of ESP32)

And countless other things...
For example, you can look at Bluetooth BLE with embedded ultra-low power MCUs from STMicroelectronics and Microchip, and their software support.

All of this is being used by the manufacturers Raymarine, Garmin, Simrad, etc, etc.

[nohal]

Originally Posted by Tehani

https://www.plaisance-pratique.com/I...NMEA0183-2.pdf

The complete manual is very interesting, but what you ask for is starting on page 138:
https://www.u-blox.com/sites/default...X-13003221.pdf

So a leaked copy of 20 years old version of the documentation of the standard from an obscure source (Just reading it might actually imply that a person could never ever contribute any NMEA0183 related code to OpenCPN again without risking legal consequences) and a manual for a product implementing a fraction of it is that good documentation? Really?

Read the XDR sentence in the first link. I think it would be nice if OpenCPN were to adapt to the standard nomenclature of sensors and units.
You will also find the sentence RPM. Its implementation in O would be welcomed by many users.

Oh, XDR, I love that sentence. Notorious example of what is completely broken on NMEA0183. Will you answer all those upset users of older but perfectyl working commercial products using it that will stop working with OpenCPN as we replace the current implementation with the latest "standard nomenclature" of sensors and units until we iron all the non standard cases once again, please?

RPM, sure, we do not use or show any engine or shaft info, so why not start with revolutions and propeller pitch? Just curious, how many boats with sensors providing this sentence and using OpenCPN have you already seen?

And what should we actually do with the data we harvest from those 2 sentences? Create new dashboard instruments? Which instruments (XDR can transfer pretty much anything and there may be multiple rotating elements reported using RPM)?
Will we realize that what you actually ask for is a reimplementation of OpenCPN's dashboard plugin, which does not support such generic stuff?
We probably will.
Will we be willing to base such a reimplementation on NMEA0183?
We probably won't.
Why?
Because it is too limited itself and does not cover the multiple same/similar sensors use case well in the vast majority of sentences (except XDR, RPM and a few others), while pretty much any sensor can actually be present multiple times in a system.

[mgrouch]

Originally Posted by Tehani

There are other worlds, I recommend you to explore in the ARM Cortex-M communities, and IDE environments AC6, Keil, IAR, Atollic TrueSTUDIO, etc.
Example: https://community.st.com/s/
You will see the power they offer for professional software debugging.

Any open source reusable libraries available created in those IDEs?
Boating related

Thanks

[Tehani]

Originally Posted by mgrouch

Any open source reusable libraries available created in those IDEs?
Boating related

Thanks

Yes of course.
Since there are a lot of entries, I prefer to tell you the google search method, for example, type:
github stm32 nmea
github stm32 nmea2000

Also, just type STM32 and the name of the sensor you're interested in, even outside of github.

You can find very cheap PCBs and an STLink clone to download and debug your projects:

https://www.aliexpress.com/item/3278...&pdp_ext_f=%7B %22sku_id%22%3A%2212000018152015466%22%7D&pdp_pi=-1%3B6.19%3B-1%3B1.47%40salePrice%3BEUR%3Bsearch-mainSearch

[stevead]

Wow, this thread is becoming one of those never ending debates....

RPM, sure, we do not use or show any engine or shaft info, so why not start with revolutions and propeller pitch? Just curious, how many boats with sensors providing this sentence and using OpenCPN have you already seen?
...
...

And what should we actually do with the data we harvest from those 2 sentences? Create new dashboard instruments? Which instruments (XDR can transfer pretty much anything and there may be multiple rotating elements reported using RPM)?

Just a point of clarification.
The Engine Dashboard displays, as its name implies, engine related data such as RPM, engine temperature, hours, oil pressure, alternator & battery voltages, and tank levels.

Over 4000 downloads so there may be a few users. As developers we need to keep in mind that it is not only yachtsmen who use OpenCPN but also power boaters.

Agree that in the past the XDR sentence was a dogs breakfast, but with V4.11 of the NMEA 183 standard it is now quite well defined and many of the gateway vendors such as Actisense, Shipmodul etc. have adopted these standard transducer names.

[nohal]

Originally Posted by stevead

Wow, this thread is becoming one of those never ending debates....

Just a point of clarification.
The Engine Dashboard displays, as its name implies, engine related data such as RPM, engine temperature, hours, oil pressure, alternator & battery voltages, and tank levels.

Over 4000 downloads so there may be a few users. As developers we need to keep in mind that it is not only yachtsmen who use OpenCPN but also power boaters.

Thanks for the clarification, so OpenCPN does already support RPM sentence and we can directly tick part of the request as implemented

[stevead]

Hi Pavel,

I'm having a quiet chuckle....

Not only does the Engine Dashboard support the "soup" of NMEA 183 sentences: RPM, RSA, XDR (incl v4.11 transducer names), but it also supports SignalK !

Does that tick enough boxes for you ?

OK, I'll admit it lacks the visual appeal of some of the other dashboards.

[nohal]

Originally Posted by stevead

Does that tick enough boxes for you ?

For me certainly, my own boat has no sensors I could connect to at all

[mgrouch]

Originally Posted by Tehani

Yes of course.

Since there are a lot of entries, I prefer to tell you the google search method, for example, type:

github stm32 nmea

github stm32 nmea2000



Also, just type STM32 and the name of the sensor you're interested in, even outside of github.



You can find very cheap PCBs and an STLink clone to download and debug your projects:



https://www.aliexpress.com/item/3278...&pdp_ext_f=%7B %22sku_id%22%3A%2212000018152015466%22%7D&pdp_pi=-1%3B6.19%3B-1%3B1.47%40salePrice%3BEUR%3Bsearch-mainSearch

Is there something open and as complete as SensESP but for STM32?

STM32 and Esp32 are both comparable MCUs but ESP32 has open source platform SensESP specifically oriented for boating needs.