SignalK - anyone actually using it?

[GHA]

Fairly decent write-up here...

http://www.practical-sailor.com/issues/37_60/features/Signal-K-and-the-Sailboat_11878-1.html

Seems to be getting there, the 2 pages available so far are below. Available as a web page on any device onboard. On the instruments panel you can resize, move around and turn panels on and off. The device remembers the settings. Not quite sure yet what the different lines mean on the wind page, but apparently it will calculate the true wind from apparent wind and gps velocity. Displays M/S instead of Kts which is a bit annoying.

Dead easy and very cheap if you have everything on a NMEA0183 feed already, just add a raspberry pi, wifi dongle & usb/serial adapter.

So will this reach critical mass and be the next be thing for shoving data around a boat?

Got to be better than the closed shop nmea and a mish-mash of manufacturers own methods we have at the moment. .

 

[KAL]

Never heard of it but looks interesting. What do you need to do to set it up and approx what is the cost?

 

[DJE]

I am waiting for delivery of one of the first Digital Yacht gateways under their crowd-funding programme. Hoping to have a play with it this season.

 

[GHA]

Never heard of it but looks interesting. What do you need to do to set it up and approx what is the cost?

The software is free. I'm using a raspberry pi 2 mini computer..about 30 quid but that's as a chartplotter as well using opencpn.
Just to broadcast the data a raspberry pi zero should do it. 5 quid! If you can actually get one, they're constantly sold out.
In addition you'll need a 5v usb power supply, a few quid off ebay, a usb wifi dongle - a few quid, and a usb/serial adapter for each nmea feed, a few quid each. And a little case of some sort. And a micro SD card which is the hard drive.
You can set it up without a monitor using a laptop over wifi.

https://boatdatasystems.wordpress.com/2016/01/02/raspberry-pi-as-a-nmea-wifi-repeater/

 

[laika]

Dead easy and very cheap if you have everything on a NMEA0183 feed already, just add a raspberry pi, wifi dongle & usb/serial adapter.

So will this reach critical mass and be the next be thing for shoving data around a boat?

Got to be better than the closed shop nmea and a mish-mash of manufacturers own methods we have at the moment. .

As you're aware (but some people won't be) the graphical applications pictured could have been written to use data in any format. Those were written to showcase SignalK. Plenty of others available which do the same thing with "NMEA-0183-over-wifi".

Right now you have to ask why, if you've got an NMEA-0183 feed already, you'd go to the bother of installing a heavyweight node.js or java application to translate NMEA-0183 into a more verbose and bandwidth-intensive format ( which doesn't have a formally defined transport layer so I hesitate to call it a "protocol" ) which few applications currently understand. Will this do anything your OpenPlotter couldn't do without Signal K?

"No" I think is currently the answer. Will it replace NMEA protocols on board? Again I think "No". It's not a "protocol" in the same way as NMEA-2000. It's heavyweight, verbose, and designed with ease of use by web developers rather than embedded device programmers, and none of the lower layers are defined (deliberately).

The (current at least) model is that it isn't an "NMEA-replacement": it's a way for your mobile device apps to consume your boat data which is translated from NMEA protocols via a commercially obtained gateway (e.g. iKommunicate). In initial iterations there's no way for those apps to "talk back" to the boat.

A lot of the arrows on those diagrams about "on water social boating" simply don't exist. The challenge there is more the creation of inter-boat ad-hoc networks (if anyone actually even wants them).

Having said all that....Yes I think it will gain traction. The data model it uses which initially I didn't like because I'm not a "monolithic central server" kinda guy is very similar to that adopted by many IoT/home automation projects. Being "low level protocol agnostic" it can provide a common interface for your mobile apps to stuff which natively speaks N2K, NMEA-0183 or some proprietary control protocol. the model will also lend itself well (from an access control point of view) to the fluffier concepts the creators tout: The inter-boat ad-hoc network thing is not *actually* such pie-in-the-sky as it's being intensely worked on for cars:
https://en.wikipedia.org/wiki/Vehicular_communication_systems
Still doesn't mean that I want "social boating", but the waterborne twitterati will love it.

 

[GHA]

Will this do anything your OpenPlotter couldn't do without Signal K?

Haven't got that far yet but engine data and battery voltage displayed on any device spring to mind.

Also, andriod isn't that well catered for with apps to read nmea data (which openplotter also broadcasts over wifi) so right now the web pages broadcast by signalK are the only way I can get at wind data ( and free) , though one just come out reads both nmea & signalk..
https://play.google.com/store/apps/details?id=com.easybizness.oceanIX

anyone know of any others?

 

[laika]

Haven't got that far yet but engine data and battery voltage displayed on any device spring to mind.

That's a function of an application which is displaying data on a web server rather than of "Signal K". I haven't looked at the code but I believe Teppo's Kurki's navgauge (which I think you have pictured) displayed N2K and NMEA-0183 before he started working with the others on Signal K.

I'll also argue that if you have a simple LCD display with a microcontroller on the back of it then writing a whole http stack just to get battery voltage is a bit of a faff.

OTOH N2K-over-IP hasn't gained any traction, there's no standard NMEA-0183 representation for lots of things (like engine data) and a recent foray into LED RGB light control using NMEA-0183 with an arduino (blog report coming soon did underline how inelegant it was bastardising it to use as a control protocol.

But I challenge you to reveal whether you *are* actually displaying battery voltage and engine data
ISTR your battery monitor is home-brew, so you'd have had to have written a backend plugin for the Signal K server. I think you're talking about what you could "in theory" do with this

 

[GHA]

I'll also argue that if you have a simple LCD display with a microcontroller on the back of it then writing a whole http stack just to get battery voltage is a bit of a faff.

Not if someone else has done it already and it's sitting on a Pi wanting something to do

But I challenge you to reveal whether you *are* actually displaying battery voltage and engine data
ISTR your battery monitor is home-brew, so you'd have had to have written a backend plugin for the Signal K server. I think you're talking about what you could "in theory" do with this

I need to figure out how to get non nmea data from an arduino into signalk running on a Pi. Already the arduino is fixing a wrong nmea checksum on the wind sensor, then signalk does everything else (I've no app which reads nmea data over wifi) , so for me signalk is dead easy. Feed it a string of characters and it does everything else. The broadcast web page auto updates with new feeds .

Just need to find out what to send it...

 

[JohnGC]

<snip>
It's heavyweight, verbose, and designed with ease of use by web developers rather than embedded device programmers,
<snip>

This is a significant issue when you begin to consider the transport layer on a small boat.

CAN BUS is ideal for all of the data you are likely to want to move around with the exception of RADAR or imaging sonar.
- It is electrically robust.
- It is protocol robust with self detection mechanisms for BUS error isolation and automatic message retransmission.
- There is a large selection of powerful but inexpensive micro-controllers available.
- It is multi-drop for both talkers and listeners.
- It only requires two data wires which can be tapped into relatively easily. (There are constraints but they are not onerous.)

If I where to update from SeaTalk and NMEA 0183, then moving to a CAN BUS based system would be ideal.

But sending Signal-K data over a CAN BUS network would use up a lot of bandwidth. The amount of useful data in the heading message example shown on the SK web-site is 26 characters out of 438 (6%). Fewer still if it where binary data.

On a high bandwidth transport layer such as Ethernet it isn't really a problem. But if I where to replace my depth transducer and log (which are next to each other) I would not want each one to be a node on a network requiring either a local network switch or separate cables. Much better to have one 4 core cable which includes the power and data and can be daisy chained and extended.

As laika points out, Signal-K addresses multi-boat data sharing from a web-app perspective. All of the associated overhead for that is of no practical use within a small boat's own network.

CAN BUS (J1939) is a really good choice for NMEA 2000. The problem from the small developer's and amateur's point of view is the cost of obtaining the standard. Personally I think a CAN BUS based, open-source standard for small boats would be more benefit. I have designed a simple CAN BUS based display (monochrome graphic, transflective). But I do not have the time to take it any further at present.

 

[Boo2]

CAN BUS is ideal for all of the data you are likely to want to move around with the exception of RADAR or imaging sonar OR CHART IMAGE DATA.

True but consider :

ETHERNET is ideal for all of the data you are likely to want to move around INCLUDING RADAR AND imaging sonar AND CHART IMAGE DATA.
- It is electrically robust.
- It is protocol robust with self detection mechanisms for BUS error isolation and automatic message retransmission.
- There is a large selection of powerful but inexpensive micro-controllers available.
- It is multi-drop for both talkers and listeners when conected to switches
- It only requires 4 data wires and can use commercial off the shelf connectors and netwok infrastructure

CAN bus is not present on standard PCs by default which is another huge disadvantage. And the data rate of CAN bus is stone age and the protocol design intrinsically limits the (line length * data rate) product so you can't have fast data over long distances. IMHO CAN bus is a short term solution and it would have been much better if N2k had been based on ethernet, but there you go...

Boo2

 

[JohnGC]

True but consider :

ETHERNET is ideal for all of the data you are likely to want to move around INCLUDING RADAR AND imaging sonar AND CHART IMAGE DATA.
- It is electrically robust.
- It is protocol robust with self detection mechanisms for BUS error isolation and automatic message retransmission.
- There is a large selection of powerful but inexpensive micro-controllers available.
- It is multi-drop for both talkers and listeners when conected to switches
- It only requires 4 data wires and can use commercial off the shelf connectors and netwok infrastructure

CAN bus is not present on standard PCs by default which is another huge disadvantage. And the data rate of CAN bus is stone age and the protocol design intrinsically limits the (line length * data rate) product so you can't have fast data over long distances. IMHO CAN bus is a short term solution and it would have been much better if N2k had been based on ethernet, but there you go...

Boo2

Well.......

Ethernet between the radar scanner and the PC seems eminently sensible. Imaging SONAR can be run at modest data rates although I wouldn't add it to a CAN BUS with other data on. But I just don't need RADAR data in the bilge where by log transducer is or anywhere forward of the nav table. Nor do I want to have a cheap commercial ethernet switch there and I don't want to pay for one with a high IP rating.

Ethernet isn't anything like as robust as CAN BUS. Particularly when it comes to EMC.
The protocol isn't as robust as CAN BUS at least in the sense that CAN BUS peripherals have error isolation built in to the hardware, they don't depend on software.
Micro's with ethernet tend to be more expensive than those with CAN although I admit they are still not very expensive.
Needs switches - not multi-drop and can't be daisy chained.
Off-the-shelf connectors - also true for CAN BUS.

CAN BUS data rate * line length is quite fast enough and long enough for all data on a small boat except imaging data.

The CAN BUS to PC interface is a significant issue and would need to be addressed for enthusiasts and small developers. There are many CAN BUS to USB and ethernet dongles but they are expensive and are mostly for analysis use. But a simple CAN BUS / USB / ethernet device need not be expensive. To my mind a combined system would be good; CAN BUS for the low bandwidth data for all transducers and simple displays plus a gateway to ethernet or USB.

 

[prv]

To my mind a combined system would be good; CAN BUS for the low bandwidth data for all transducers and simple displays plus a gateway to ethernet or USB.

...which is pretty much exactly what Raymarine/B&G/Simrad etc use

Pete

 

[Boo2]

Ethernet between the radar scanner and the PC seems eminently sensible. Imaging SONAR can be run at modest data rates although I wouldn't add it to a CAN BUS with other data on. But I just don't need RADAR data in the bilge where by log transducer is or anywhere forward of the nav table. Nor do I want to have a cheap commercial ethernet switch there and I don't want to pay for one with a high IP rating.

You wouldn't put the switch in the bilge, you'd run a cable (with PoE) to each of two transducers whereever they happened to be situated. Calling high-IP switches expensive is ironic given the costs of integrated CAN systems like eg Raymarine cables.

Ethernet isn't anything like as robust as CAN BUS. Particularly when it comes to EMC.
The protocol isn't as robust as CAN BUS at least in the sense that CAN BUS peripherals have error isolation built in to the hardware, they don't depend on software.
Micro's with ethernet tend to be more expensive than those with CAN although I admit they are still not very expensive.
Needs switches - not multi-drop and can't be daisy chained.
Off-the-shelf connectors - also true for CAN BUS.

Ethernet is a far more robust protocol wrt EMC than CAN which relies on passive pull-ups on the data lines. Ethernet has all the benefits of TCP/IP as well in terms of error crrection and automatic packet re-transmission so an altogether safer protocol wrt data loss. Ethernet switches are cheap as chips and can be daisy chained, compare the cost of an ethernet switch with a Raymarine backbone extender for instance. Multi drop can be nice but is not essential and star wiring has the advantages of fault-resilience and adaptability.

CAN BUS data rate * line length is quite fast enough and long enough for all data on a small boat except imaging data.

Or, translating, CAN is not fast enough to cope with marine application data rates.

Multi-protocol systems with multiply-wired connections are a complete kludge and will hopefully come to an end as soon as someone in the industry comes to their senses and proposes a standard N3k based on ethernet with PoE.

Boo2

 

[GHA]

I am waiting for delivery of one of the first Digital Yacht gateways under their crowd-funding programme. Hoping to have a play with it this season.

Looks like a cool device
Obviously bigging it up a lot but even so..

 

[laika]

Sorry to mention it but are people getting their OSI layers a little muddled?

Multi-protocol systems with multiply-wired connections are a complete kludge and will hopefully come to an end as soon as someone in the industry comes to their senses and proposes a standard N3k based on ethernet with PoE.

Like OneNet?
https://en.wikipedia.org/wiki/NMEA_OneNet

No idea the details of how it works or whether radar/sonar is covered. The release date seems to have been a little...errr...delayed. At least a couple of times...

 

[laika]

Looks like a cool device

A few more nuggets of info on iKommunicate and Digital Yacht's Signal K approach if anyone is interested:
http://stripydog.blogspot.com/2015/10/ikommunicate.html

 

[DJE]

Most of this thread has gone straight over my head. I can handle NMEA 0183 wiring between compatible devices and I can just about get by on ethernet wiring and TCP/IP through running my own home/office network. I have an ageing Navico network on the boat which will need bits replacing before too long I'm sure. And I really want to get the instrument data - plus AIS when I get round to installing it - onto a laptop and wirelessly to tablet displays for maximum flexibility in future. So I am taking a punt on the iKommunicate gateway. I got in at the start of the Kickstarter process so it is coming reasonably cheap.

I met Paul Sumpner of Digital Yacht at the London Boat Show and he says he will help me out if I get stuck. I will let you know how I get on.

 

[laika]

Most of this thread has gone straight over my head.
[...]
I met Paul Sumpner of Digital Yacht at the London Boat Show and he says he will help me out if I get stuck. I will let you know how I get on.

Don't stress: Everyone is saying intelligent things above but a discussion about the best physical + datalink layer for a backend boat network to which your transducers etc. are connected is possibly tangential to GHA's original "Will Signal K catch on?" question.

Unless I missed something the iKommunicate does the same things as DY's current NMEA-0183/N2K to NMEA-0183-over-IP boxes in addition to Signal K (just as well since there's not many Signal K apps out there yet) but (at the kickstarter price) for rather less cash. If Signal K doesn't catch on, it's still a useful acquisition.

Also Paul seems like a top bloke: knowledgeable and straight forward. I look forward to your iKommunicate review when you have yours installed.

Other sources of support for Signal K include the google group:
https://groups.google.com/forum/#!forum/signalk

 

[GHA]

Other sources of support for Signal K include the google group:
https://groups.google.com/forum/#!forum/signalk

Where I'm struggling to not drown in a sea of ignorance about json et al
But seems the signalk server will accept json strings, so in that respect signalk is wonderful for tinkerers like me who don't really know what we're doing but just get lucky with cut and paste
No need to learn about web coding or anything like that, just get one line of data formatted right to the server and it will do the rest, and other clever folk will come along with cool apps to look at it

 

[JohnGC]

...which is pretty much exactly what Raymarine/B&G/Simrad etc use

Pete

Yup - but not with an open standard.