SignalK development ?

[barnakiel]

Originally Posted by sbender

And then any application that supports SignalK can display data from the boat without having parse antiquated binary protocols that were designed to save bytes.

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?

We need open hardware sensors. Signal K , N2K, or Santa K. Give me the sensors and I will code for them.

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.

The above (virtual non existence of Signal K open hardware sensors) is one thing.

The other thing is the ignorant Signal K people who tend to write stuff and answer questions in the well established, but sick, Linux forums manner:

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

etc. etc. etc.
..."

People who want to develop something new and useful should remember out there are plain non nerd humans who will want to read, think, understand and chuck in their little help. But not when they are scolded and mentored. If a developer thinks they are so smart that they do not need to answer plain questions in human language then that's that. Let them develop.

You think I am contradictory? Yes, I could be. But you are doing nothing to show me the light. Telling me that I am contradictory is errrr... not constructive. Show me the light. Teach me. Educate me.

So:

- where are the Signal K open hardware sensors?
- what is the electrical/hardware standard to follow?
- where are the datagram structures described?
- where can we find sample files containing sample data stream?

Is the standard truly multipoint?

Cheers,
b.

[sbender]

Originally Posted by barnakiel

Doh.

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

My point is that with SignalK the app doesn't have to write decoders for every possible sentence. And as new sentences are added to the spec, the app does not have to write a whole new set of decoders.

[Paul Elliott]

Originally Posted by sbender

My point is that with SignalK the app doesn't have to write decoders for every possible sentence. And as new sentences are added to the spec, the app does not have to write a whole new set of decoders.

But the app still has to do something with the new data. Now if the data is just (say) windspeed from one of the many different NMEA-0183 wind data sentences, then sure, the app only has to understand the SK wind format. This is indeed an improvement. But there are other cases where new data types are delivered and then you need to modify the app to interpret and display the new data type

In theory, I like SK because it provides a "lingua franca", translating to and from N-2000 and N-0183 (and I suppose Seatalk), and providing a uniform interface. The fact that it's JSON is nice. I'm not personally excited about the multi-vessel extensibility, but it might be useful and I can live with it.

In practice, I've only begun to play with SK, so take my comments with a grain of salt.

[sbender]

Originally Posted by Paul Elliott

But the app still has to do something with the new data. Now if the data is just (say) windspeed from one of the many different NMEA-0183 wind data sentences, then sure, the app only has to understand the SK wind format. This is indeed an improvement. But there are other cases where new data types are delivered and then you need to modify the app to interpret and display the new data type

In theory, I like SK because it provides a "lingua franca", translating to and from N-2000 and N-0183 (and I suppose Seatalk), and providing a uniform interface. The fact that it's JSON is nice. I'm not personally excited about the multi-vessel extensibility, but it might be useful and I can live with it.

In practice, I've only begun to play with SK, so take my comments with a grain of salt.

Actually new data types can be added and displayed without needed know anything about them. For example, I have generic gauges for Amps, Volts, etc. So if someone adds something like "Inverter Amps", it be can displayed just fine without app changes.

So really an app just need to understand the type (Speed, temperature, Volume, etc.), and then it can display anything that is in that type. It can even be very generic and just show the value from an unknown SignalK path.

[muttnik]

To return to the specific case of Signal K and OpenCPN, last I recall nohal was looking to re-architect internal data representations to be protocol agnostic with protocol-specific input modules which hopefully everyone, both fans and foes of Signal K, would appreciate. It's a pretty enormous task, especially with OCPN being in continual development using the existing structures but I'm curious to know how it's coming along.

[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

[teppokurki]

Originally Posted by barnakiel

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

Wind sensors and depth sensors are pretty hardware intensive, SK or the data format in general is sort of a sidetrack.

Would dAISy HAT for Raspberry Pi qualify if there were a Signal K driver for it? https://www.tindie.com/products/astu...-raspberry-pi/
If I had just a bit more time I would dig into this in more detail.

But there is nothing stopping you from leveraging existing, proven, mass marketed sensors by hooking them up to an open source SK server running on inexpensive hardware to make it easier to consume all that data.

Originally Posted by barnakiel

- where are the Signal K open hardware sensors?

Would these projects qualify?
- https://github.com/SignalK/ArduinoTC (thermocouple for Signal K)
- https://github.com/SignalK/signalk-imu (Magnetic heading, Rate of turn, Attitude (yaw, roll, pitch), Temperature, Atmospheric Pressure)
- https://github.com/e-sailing/esp8266_2_signalk (temperature, humidity)

There are undoubtedly others, but my guess is that most of the sensor projects are personal setups: an individual wires together some sensors and connects them to a SK setup and uses it happily. I know my personal Volts and Amps "project" isn't much to look at:
- wiring to the pre-existing shunt
- voltage divider from some resistors that happened to be there
- AD converter
- some code to read the AD via I2C and convert the readings to volts and amps (https://github.com/tkurki/cassiopeia...aster/index.js)
I can document that, but it is not really a project: buy the parts and wire them together. The few lines of code are hardly a software project.

My own ESP8266 SK temperature sensor is literally a NodeMCU board with 3 1W temp sensors and power.

Originally Posted by barnakiel

- what is the electrical/hardware standard to follow?

There isn't one. The spec says HTTP and WebSockets. De facto there is support for at least serial and TCP Sockets. Use what hardware works for you with these.

Originally Posted by barnakiel

- where are the datagram structures described?

I am not sure if JSON message structures qualify for datagram structure, but that is what we have. See

https://signalk.org/specification/master/
https://github.com/SignalK/specifica...master/schemas

Originally Posted by barnakiel

- where can we find sample files containing sample data stream?

The document linked above contains some examples. The tests and related data files at https://github.com/SignalK/specifica...ee/master/test can provide a bit more insight.

There are some demo servers available that you can connect to with a http client (browser) or a websocket client (I can recommend wscat2):
- Signal K :: Consumers
- Signal K Node Server

A very crude but illustrative way is to look at Signal K Sample Consumer

You can also run a SK server yourself. The node server comes with a few real world log files that you can play back. See https://github.com/SignalK/signalk-server-node

(Node-master goes to sleep when it is not in use - please wait for a while to allow it to spin up, please)

Originally Posted by barnakiel

Is the standard truly multipoint?

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]

Originally Posted by Paul Elliott

But there are other cases where new data types are delivered and then you need to modify the app to interpret and display the new data type

If you want some complex visualisation or intelligent handling then that is correct. But for example I have a system that stores all my numeric SK data to a database and allows me to draw graphs on the data. Now if I add a new data type, say Jacuzzi temperature, that is also stored in the database with no configuration or code changes and I get the graphs. That would not happen with N2K nor NMEA0183 (with XDR being a notable exception). If I add Jacuzzi temp to the shared Signal K schema a schema aware UI will get a human oriented name for it, with the possible description, and the UI will know that it is in Kelvins and can translate it to units of your preference.

[teppokurki]

Originally Posted by barnakiel

The other thing is the ignorant Signal K people who tend to write stuff and answer questions in the well established, but sick, Linux forums manner:

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

etc. etc. etc.
..."

People who want to develop something new and useful should remember out there are plain non nerd humans who will want to read, think, understand and chuck in their little help. But not when they are scolded and mentored. If a developer thinks they are so smart that they do not need to answer plain questions in human language then that's that. Let them develop.

I am one of the Signal K people and I am sorry to say I find your comment offensive.

Could you please point out an instance where I have behaved in the manner you describe? Signal K mailing lists are available openly as are all the Github discussions related to Signal K.

If you find one I am happy to apologize in public, because then the error is mine - I try to make my communication friendly and understandable.

I have never called anybody rude or told anybody off in public.

I don't consider myself ignorant, but you are free to do so.

[teppokurki]

Originally Posted by muttnik

To return to the specific case of Signal K and OpenCPN, last I recall nohal was looking to re-architect internal data representations to be protocol agnostic with protocol-specific input modules .

This was actually also one of my original starting points for the work that grew to Signal K: I had N2K and 0183 data and I wanted to handle them in a uniform way. I am curious as to where OpenCPN is going with this as well.

[Pizzazz]

I am slowly getting the idea of Signal K, it is definitely a noble idea (sit on top of nmea for now and eventually displace it as native devices appear). Makes sense but it is a hard sell. For example, I develop simple apps to manipulate/display nmea 0183 data. I would love to work with Signal K instead of directly with the specific device protocols but then I need to buys a converter. It does not make sense for nmea0183 (already quite simple and we'll documented, plus working on low level gives you more options), makes more sense for nmea2000 and especially sharing data. So, for now it is an additional layer of abstraction that has promise. But the big vendors would never support it because they "need" to stay proprietary so that we are forced to buy $100 marine cables and $500 wind sensors. Nmea is trying to make life difficult as usual by requiring certification.

It is the chicken and egg problem. May be the right way is to approach Airmar to make a couple signal K sensors. But then you need to standardize the physical layer, which means either serial or Ethernet. Ethernet is not ideal people say, I get it. Serial is better perhaps. But the boat manufacturers would stick with the big vendors. So then you are stuck with a hobby style customer base (the Arduino folks) or some custom integration projects. This is why I said even earlier that it is a hard sell. Nice idea though.

I would love for us, sailors, to come up with a realistic idea how to improve the boat electronics market. I can't make it work in my head. It is a small market, a few hundred million dollars split between consumer and commercial. Commercial is difficult and legally challenging. Consumer is mostly fishing driven by sonars (typically proprietary, including the cables .

[sbender]

@Pizzazz a lot of good points there.

Originally Posted by Pizzazz

I would love to work with Signal K instead of directly with the specific device protocols but then I need to buys a converter.

You just need an RS422 to USB to do 0183. The node and java servers can take it from there.

I'm actually loving it the way it is now with SignalK. We do N2K and 0183 and give great options for "Makers" and tinkerers to get their custom stuff in too.

I sell a SignalK app and have sold more than I thought I ever would. I'm making enough to cover my expenses. But making much more in friends and contacts and community. I deal with people doing cool stuff with SignalK on a regular basis. Having a blast!

And BTW, sitting here at home monitoring my batteries, solar performance, weather and all N2K and 0183 data on the boat that's a mile away. I also get iOS alerts if the battery is low or the boat moves off the dock, etc. I even have an D-Link siren that goes off in the house in extreme conditions. All this with an investment of around $350 in hardware.

[sbender]

Originally Posted by sbender

All this with an investment of around $350 in hardware.

Just to be clear, that $350 is in hardware to make SignalK work. Don't even want to talk about the cost of the N2K hardware to collect the data. This is a B.O.A.T

[conachair]

Originally Posted by sbender

Just to be clear, that $350 is in hardware to make SignalK work. Don't even want to talk about the cost of the N2K hardware to collect the data. This is a B.O.A.T

Seems quite a lot, couldn't you do the same with a Raspberry pi for a lot less? Then send the data over mqtt with twitter/email sent for alarm conditions.

Any plans to release your app on Android?

Android hasn't such a great choice for signalk apps yet, I just write something in node-red which actually works very well as it's easy to get at all the signalk data plus control the gpio in/out pins on a pi via a Web page.

[sbender]

Originally Posted by conachair

Seems quite a lot, couldn't you do the same with a Raspberry pi for a lot less? Then send the data over mqtt with twitter/email sent for alarm conditions.



Any plans to release your app on Android?



Android hasn't such a great choice for signalk apps yet, I just write something in node-red which actually works very well as it's easy to get at all the signalk data plus control the gpio in/out pins on a pi via a Web page.

I'm using a PI. The big part of that is the Actisence NGT-1. $200. + PI + RS422 adapters, etc.

I currently send alerts through Amazon SNS.

I plan on working on an Android version next winter. Right now... sailing!