In what cases is SignalK needed?

[wholybee]

Originally Posted by MrGod2U

I know this is an old post but I've found what seems to be a fairly reliable anemometer (wind speed / direction) designed for marine environments. It doesn't use any of the common communication protocols so instead I bought $7 circuit board with a computer chip on it, connected the wire leads to a few of the pins on the circuit board and viola! I have wind speed and direction into open cpn via signalk.

And, as an added bonus, that $7 chip (ESP WROOM32) sends its data wireless to the Pi running opencpn.

So, for under $200 I have a wind sensor unit that I can afford to break, and when it does I need only to 3d print the new parts or spend $7 on a new module.

It good! And, it'll be connecting to my autopilot, and tank sensors, and pitch/heel to make for more efficient autopilot, all of this thanks to signalk for a fraction of retail

To answer the original question, because some people like to build or hack their own stuff, and SignalK is more conducive to that.

It's worth pointing out that there's a NMEA2000 library for the esp32 and NMEA0183 could be done on an esp via serial or wifi. So even building your own device with the exact parts you bought, SignalK is not needed, it's just the route that you chose.

I see only 2 reasons to use SignalK.

1) To build a central server to serve boat data when some of the data you need is not supported by NMEA0183. For example, some autopilot functions (setting autopilot mode) are not available in 0183, but are available in N2K. OpenCPN does not yet support N2K via Ethernet, but does support SignalK. That need will go away as soon as OpenCPN supports N2K over Ethernet. And as is, the autopilot support in SignalK is fragmented and difficult to follow, so there are many support threads from people struggling with it.
If you don't need the rare/few functions only available in N2K, then a wireless NMEA-WIFI gateway is a much better option.

2) To unify all of the ships data unto a single datastream/platform. The would include functions that have nothing to do with navigation and are not supported in OpenCPN. Engine data is probably the main thing here, but it could be anything.

IMHO, the only reason SignalK is popular, especially in the rpi crowd, is because openplotter includes it already configured. So it is the default choice. In general, I think SignalK is a dead end. It was originally intended as a replacement for N2K, which is almost 25 years old and due for an upgrade. OpenCPN is the only navigation software that supports it. And no commercial products ever will. NMEA promotes Onenet, which is an advancement of NMEA2000 with Ethernet support. I am not aware of anyone using that either, but it is the more logical choice for manufacturers to make.

[Tehani]

Originally Posted by MrGod2U

It's made by PeetBro's in the US. You can select Standard or Marine Grade.

I have analyzed the manuals of these weather stations, and I see that the serial data output is of little use for sailing navigation objectives.
There are two reasons, or rather three:
- The output resolution is 1.44 degrees, because the maximum value is 255 for a 360 degree angle. This is not very consistent with what they advertise about the good precision of the mechanical part of the vane.
- The serial output goes at a very low speed (2400 baud), and contains a lot of useless data for us. This has the consequence that the refresh rate is very slow. For a weather station it may be enough. Seeing all this, it is possible that we can take the analog values from the Hall potentiometer, and from the impulses to do the A/D conversions ourselves, but I have not found documentation on those analog outputs from the transducer.
It will be easy to obtain them if we buy a unit. Thus we can use a 12-bit A/D that is available in most current uCs. (with 12 bits we would obtain a resolution of 0.08789 degrees, and it gives us time for good oversampling, obtaining medians and averaging).

[nohal]

Is there any potentiometer or hall sensor at all? Reading https://www.peetbros.com/shop/category.aspx?catid=35 it seems they are using two reed switches and calculate the angle based on time between the level switches of the two, so higher A/D conversion accuracy won't help and actually is not needed at all as there is simply only high or low signal.

[Tehani]

Originally Posted by nohal

Is there any potentiometer or hall sensor at all? Reading https://www.peetbros.com/shop/category.aspx?catid=35 it seems they are using two reed switches and calculate the angle based on time between the level switches of the two, so higher A/D conversion accuracy won't help and actually is not needed at all as there is simply only high or low signal.

Yes, that's what the manual says, and in that case the reading can be done with a hardware timer, but I see two problems:
- This system requires that there be an impulse of minimum duration, which implies a dead zone that will surely be more than one degree.
- When the wind speed is low, the angle capture is very slow, and when it is high the precision is lower.
The old resolver systems were replaced by Hall potentiometers with good results. Both provide absolute position data without significant delays, with constant precision and without friction.
My opinion is that this two-reed system is enough for a weather station, but no more.