SignalK development ?

[seandepagnier]

Originally Posted by barnakiel

Doh.

Then any application that supports Signal K can display data that does not exist. GREAT!

Where are Signal K wind sensors? Depth sensors? Signal K gps? Signal K AIS?

Actual stand alone wind sensors don't benefit from signalk. I have developed my own board which takes a davis vantage anenometer (available on amazon for $115) and adds barometric and temperature sensors. The result it output over usb on nmea0183. This works well and I see no reason to use signalk instead as it's only more bloated and doesn't have checksum field, there would be no advantage to using signalk here.

My autopilot server which can monitor any number of serial ports, and tcp connections relays nmea0183, and converts to signalk, so that the signalk scope can plot it.

The imu which provides gyros compass, accel etc, supports much more than nmea0183 offers, it uses only signalk.

see my screenshots.

And I insist on open hardware sensors. I am not going to write free apps for sensors that cost hundreds of bucks. I am not the sensor man free workforce.

If I had enough time with a 3d printer I could build wind sensors that cost < $10.

I have an idea to build waterspeed and water temp sensors for very cheap (around $10 or less) using a thermistor and heated thermistor, but I have not the money to buy these basic parts at the moment.

"...
Q: How is Signal K signal formed (electrically), where can I find the standards and sample code and sample data streams?

A: Your question is ill formed and has already been answered in another part of the forum.

It is ill-formed because signalk is a data protocol and has nothing to with with electrical signals.

[rgleason]

Dear Sean,
I am very happy you have created wind instrument data from a davis vantage anenometer. Very impressive. Rick

[sbender]

Originally Posted by barnakiel

Doh.

Then any application that supports Signal K can display data that does not exist.

I missed this before. The "Doh" is great. I have 72 different data points coming through SignalK today on my boat. All being charted and recorded via influxdb and grafana. So, yeah...data.

[NahanniV]

Originally Posted by boat_alexandra

...
My autopilot server which can monitor any number of serial ports, and tcp connections relays nmea0183, and converts to signalk, so that the signalk scope can plot it.

The imu which provides gyros compass, accel etc, supports much more than nmea0183 offers, it uses only signalk.

see my screenshots.
If I had enough time with a 3d printer I could build wind sensors that cost < $10.

I have an idea to build waterspeed and water temp sensors for very cheap (around $10 or less) using a thermistor and heated thermistor, but I have not the money to buy these basic parts at the moment.
It is ill-formed because signalk is a data protocol and has nothing to with with electrical signals.

I'm interested to read more about your autopilot development.

[barnakiel]

Originally Posted by ludo42

You have some hardware projects like:
- https://hackaday.io/project/11055-kbox

I think a pull request is in with some code to even manage an open source auto pilot!

- https://github.com/sarfata/kbox-firmware

Good job there and I like their hardware choices. Still, this is people playing with signals.

Look at the Kbox: it accepts N183, N2K, and ST. It does not even accept SK (Sic!!!) (Or does it?)

BECAUSE THERE ARE NO SK SENSORS.

I see zero need for SK while N183 or N2K ST can be deployed to do the same jobs while we can use any ST, N2K or N182 sensor at the same time. No need for re-writing things in coders' Esperanto.

Or do we prefer to inter-code between four standards rather than three?

I am not a basher. I think the Kbox initiative is very good. I think SK initiative is just to foggy and detached. Does not imply it will not be the thing tomorrow.

?

Reading on. Thanks for the tread. Good education here now.

b.

[barnakiel]

Originally Posted by teppokurki

(...)


If the fact that you can connect to the demo servers from all over the globe concurrently fits your definition of multipoint then yes. Same thing in a local network. If not please elaborate on what you mean by multipoint, maybe I can provide a more precise answer.

@ teppokurki

Mate,

I mean multipoint in the multitalker / multilistener sense. Below I expand on it.

Example:

a) take your K device - say a K capable plotter device with a single K in/out physical port.

b) take even more K devices - say 4 different boat SK sensors and one extra K plotter repeater - an active one (active=can both read and write to other net'ed devices).

Skip the part that the sensors barely exist yet.

Q: Can all these sensors talk at once and receive replies thru just one K plotter K port?

Think N2K like. Multitalker and multilistener capable.

Let me know. standing by,
b.

[barnakiel]

Originally Posted by sbender

I missed this before. The "Doh" is great. I have 72 different data points coming through SignalK today on my boat. All being charted and recorded via influxdb and grafana. So, yeah...data.

Data from remote sensors or remote servers or what?

What 72 types of boat sensors do you have onboard? PLS list the K sensors you have in your boat.

My boat has 4 sensors (depth, speed, gps, wind) none of them is K.

Boats I used work on and for have up to 20 sensors and networked devices. None of them, this far, a K sensor.

What 72 types of sensors are you reading onboard. PLS list some.

And how are they relevant to an averager boater?

If you are in a land based meteo station, PLS skip my question. ;-)

Love,
b.

PS I will read thru this thread again later. I cannot see the sensors (ban the temp, pressure etc mentioned by one poster). I cannot see how the signal avoids being just a rewrite of the other protocols. I cannot see the electrical properties of the hardware platform - not everything onboard can be read thru the wireless nearly all boats carry wired sensors mostly and these wires must be plugged into something. We cannot skip the electric part and wait for a miracle to happen. It will not happen, people will opt for off the shelp n183 N2K and other proprietary stuff. Me too.

[sbender]

Originally Posted by barnakiel

Data from remote sensors or remote servers or what?

What 72 types of boat sensors do you have onboard? PLS list the K sensors you have in your boat.

My boat has 4 sensors (depth, speed, gps, wind) none of them is K.

Boats I used work on and for have up to 20 sensors and networked devices. None of them, this far, a K sensor.

What 72 types of sensors are you reading onboard. PLS list some.

And how are they relevant to an averager boater?

If you are in a land based meteo station, PLS skip my question. ;-)

Love,
b.

PS I will read thru this thread again later. I cannot see the sensors (ban the temp, pressure etc mentioned by one poster). I cannot see how the signal avoids being just a rewrite of the other protocols. I cannot see the electrical properties of the hardware platform - not everything onboard can be read thru the wireless nearly all boats carry wired sensors mostly and these wires must be plugged into something. We cannot skip the electric part and wait for a miracle to happen. It will not happen, people will opt for off the shelp n183 N2K and other proprietary stuff. Me too.

"electrical.batteries.0.voltage.value";
"electrical.batteries.1.voltage.value";
"electrical.chargers.victron.batteryVoltage.value" ;
"electrical.chargers.victron.current.value";
"electrical.chargers.victron.daySequenceNumber.val ue";
"electrical.chargers.victron.error.value";
"electrical.chargers.victron.firmwareVersion.value ";
"electrical.chargers.victron.load.value";
"electrical.chargers.victron.loadCurrent.value ";
"electrical.chargers.victron.maximumPowerToday.val ue";
"electrical.chargers.victron.maximumPowerYesterday .value";
"electrical.chargers.victron.mode.value";
"electrical.chargers.victron.modeValue.value";
"electrical.chargers.victron.panelPower.value" ;
"electrical.chargers.victron.panelVoltage.valu e";
"electrical.chargers.victron.productId.value";
"electrical.chargers.victron.serialNumber.valu e";
"electrical.chargers.victron.yieldToday.value" ;
"electrical.chargers.victron.yieldTotal.value" ;
"electrical.chargers.victron.yieldYesterday.value" ;
"environment.current.drift";
"environment.current.setTrue";
"environment.depth.belowSurface.value";
"environment.depth.belowTransducer.value";
"environment.depth.surfaceToTransducer.value";
"environment.inside.engineRoom.temperature.val ue";
"environment.inside.temperature.value";
"environment.outside.humidity.value";
"environment.wind.angleApparent.value";
"environment.wind.speedApparent.value";
"navigation.attitude.pitch";
"navigation.attitude.roll";
"navigation.attitude.yaw";
"navigation.courseGreatCircle.bearingTrackTrue.val ue";
"navigation.courseGreatCircle.nextPoint.position.l atitude";
"navigation.courseGreatCircle.nextPoint.position.l ongitude";
"navigation.courseOverGroundTrue.value";
"navigation.datetime.value";
"navigation.gnss.geoidalSeparation.value";
"navigation.gnss.horizontalDilution.value";
"navigation.gnss.integrity.value";
"navigation.gnss.methodQuality.value";
"navigation.gnss.satellites.value";
"navigation.gnss.type.value";
"navigation.headingMagnetic.value";
"navigation.headingTrue.value";
"navigation.log.value";
"navigation.magneticVariation.value";
"navigation.position.latitude";
"navigation.position.longitude";
"navigation.rateOfTurn.value";
"navigation.speedOverGround.value";
"navigation.trip.log.value";
"propulsion.port.alternatorVoltage.value";
"propulsion.port.oilPressure.value";
"propulsion.port.revolutions.value";
"propulsion.port.runTime.value";
"propulsion.port.temperature.value";
"propulsion.starboard.revolutions.value";
"steering.autopilot.state.value";
"steering.autopilot.target.headingMagnetic.val ue";
"steering.rudderAngle.value";
"tanks.fuel.0.capacity.value";
"tanks.fuel.0.currentLevel.value";

[barnakiel]

Originally Posted by sbender

"electrical.batteries.0.voltage.value";
"electrical.batteries.1.voltage.value";

(...)

+OK.

Why not display this data in native instruments?

Why do a native to SK translation and back?

SK just piggybacks the other systems and just adds more hardware in between the sensors and the end user/display.

I will make a post with images from Signal K Specification · Signal K Documentation to show where I think the whole thing falls short.

Thanks for your response. Now I understand better our wildly varied needs.

b.

[barnakiel]

I am posting two images that I grabbed from:

Signal K Specification · Signal K Documentation

I have modified the originals and my comments are in red ink.

I hope this does not violate any copyrights. If I am wrong, PLS ping our admins and ask for image removal. Thanks.

I cannot see why we need SK. I see a N2K a much better option.

Can we truly NOT use our own N2K solutions? will I get sued if I deploy a N2K plotter (homebrew) on my boat or build a N2K wind sensor and share the hardware at no fee with another sailor?

Images attached. I see no point in a N2K device (in some scenarios - two devices - the gate and a server). I can see plenty of use for a cheap open source (both open soft and hardware) N2K to wifi, N2K to N183 bridges. Unless we build varied and open hardware SK sensors.

SK seems to just piggyback the existing data. Asking us to translate perfectly usable n183 and N2K into another, new form/structure of data.

My view is from someone who sails relatively less complex boats and who develops small hardware and writes very basic hardware to UI code. Zero need for yet another signal and yet another device here. This would add only more levels of complexity to an already too complex reality.

So rather than address an existing need, SK seems to create a new one. This sure is one of many ways to run the shop even though I am not compatible with it. I am 100% many people will. Just look around. Who would need an iPhone. ;-)

I am standing by and keeping on reading.

b.

[barnakiel]

Originally Posted by sbender

SignalK works just fine over serial and Ethernet. NMEA2000 is not an open protocol and is difficult to write software for. (...)

From wiki:

"...

NMEA 2000 and proprietary networks

Several manufacturers, including Simrad, Raymarine, Stowe, the Brunswick Corporation and Mastervolt, have their own proprietary networks that are compatible with or akin to NMEA 2000. Simrad's is called SimNet, and Raymarine's is called SeaTalk NG. Stowe's is called Dataline 2000. Brunswick's is called SmartCraft. Some of these, such as SimNet and Seatalk NG, are a standard NMEA 2000 network but use non-standard connectors and cabling; adapters are available to convert to standard NMEA 2000 connectors, or the user can simply remove the connector and make a direct connection.[3]



Trademarks

The term "NMEA 2000" is a registered trademark of the National Marine Electronics Association. Devices which are not "NMEA 2000 Certified" may not legally use the NMEA 2000 trademark in their advertising.

..." End of quote.

It does not seem to suggest the protocol is not open. It says the phrase "NMEA 2000" cannot be used for advertising unless a device is certified by the body.

The two allegedly 'non open' protocols are also said (by wiki) to be be easily in-pluggable, once we cut the proprietary plugs.

So why not simply NOT use the unfortunate 'NMEA 2000' phrase and develop stuff that is 100% compatible with (no names please) Can Bus N2K stuff? Why translate things to and from?

I would suggest a working name NN2K for this project.

Standing by now I mean it. But listening on.

Apologies for this many and probably too lengthy, posts.

Love,
b.

[sbender]

Originally Posted by barnakiel

From wiki:

"...

NMEA 2000 and proprietary networks

Several manufacturers, including Simrad, Raymarine, Stowe, the Brunswick Corporation and Mastervolt, have their own proprietary networks that are compatible with or akin to NMEA 2000. Simrad's is called SimNet, and Raymarine's is called SeaTalk NG. Stowe's is called Dataline 2000. Brunswick's is called SmartCraft. Some of these, such as SimNet and Seatalk NG, are a standard NMEA 2000 network but use non-standard connectors and cabling; adapters are available to convert to standard NMEA 2000 connectors, or the user can simply remove the connector and make a direct connection.[3]



Trademarks

The term "NMEA 2000" is a registered trademark of the National Marine Electronics Association. Devices which are not "NMEA 2000 Certified" may not legally use the NMEA 2000 trademark in their advertising.

..." End of quote.

It does not seem to suggest the protocol is not open. It says the phrase "NMEA 2000" cannot be used for advertising unless a device is certified by the body.

The two allegedly 'non open' protocols are also said (by wiki) to be be easily in-pluggable, once we cut the proprietary plugs.

So why not simply NOT use the unfortunate 'NMEA 2000' phrase and develop stuff that is 100% compatible with (no names please) Can Bus N2K stuff? Why translate things to and from?

I would suggest a working name NN2K for this project.

Standing by now I mean it. But listening on.

Apologies for this many and probably too lengthy, posts.

Love,
b.

Don't you think that for a protocol to be "open" it should be published publicly?

[Lake-Effect]

Originally Posted by barnakiel

BECAUSE THERE ARE NO SK SENSORS.

SignalK is a non-proprietary, genuinely open lingua franca for stuff in your boat's navigation system.

It's not necessarily a plus to have SK sensors, or ONE bus that everything has to plug into. The data rate from the usual sensors can be easily handled in simpler and more common protocols and connections - serial, IIS, I2C, etc - using low-cost commodity hardware and simple, open libraries.

It wouldn't be that hard to come up with open code to run on a commodity processor (like an Arduino Nano) to make any sensor a SK device... but there's not much point, is there? Open boat data systems usually have some central processor (eg a Raspberry Pi or an industrial singleboard PC) that is more than capable of handling a handful of sensors connected directly to it... and SK is used to talk to tablet(s), phones, and other nav gear.

NMEA2000 is a closed, proprietary protocol, the only (quasi-legal) info the non-member has about it has come about from reverse-engineering (which in N2K is deliberately hard). Or you bite the bullet and buy a $200 interface which is like $20 of hardware, but they are members of NMEA, and they gotta pay off that licence somehow.

Is it really a plus to have a NMEA2000 bus running up the mast to a N2K wind instrument? Or a N2K depth transducer? Ditto for SK sensors.

[barnakiel]

Originally Posted by sbender

Don't you think that for a protocol to be "open" it should be published publicly?

Very good question but I will dodge.

Do you think a protocol is no good only because it is not open?

This would render Windows and iOS bad systems. But we both know they are not. And OpenCPN works on Windows and Mac even though Windows and Mac are definitely not open.

But I will make this even harder for you: How are you going to write this N2K to SK translator without knowing the NMEA 2000 info? Because if it is not open then what?

How lacking is this info:

https://www.nmea.org/Assets/20151026...ption_list.pdf

In connection with a tool like this:
http://www.panbo.com/assets_c/2012/0...5x308-5744.jpg

What else do we need to read & understand / then write our own N2K format data?

barnakiel

[Lake-Effect]

Originally Posted by barnakiel

How lacking is this info:

https://www.nmea.org/Assets/20151026...ption_list.pdf

In connection with a tool like this:
http://www.panbo.com/assets_c/2012/0...5x308-5744.jpg

What else do we need to read & understand / then write our own N2K format data?

Your links are to decoded NMEA2000 data, not to the actual transmission format on the bus. In order to receive and send, you need to buy an 'official' interface like the Actisense.

Do you think a protocol is no good only because it is not open?

This would render Windows and iOS bad systems. But we both know they are not. And OpenCPN works on Windows and Mac even though Windows and Mac are definitely not open.

Bad examples - Windows and IOS have open, publicly available and well supported APIs and standards. Anyone can write and run programs on them without giving them a dime. Same with network and interface - I can create wifi or USB connected devices that will connect to those Oses, again without costing a dime beyond the commodity hardware required.

You have nowhere near that freedom in NMEA2000.