SignalK development ?

[barnakiel]

Originally Posted by Lake-Effect

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.

Except that SK still has to translate from N2K and back and how do you do this translation without knowledge of N2K? Or do you already have good N2K knowledge and refuse to share it?

Argghhh. So we do need to know what that N2K data is all about ANYWAYS. Or else we are buying that 200USD device.

And once we know how to read the N2K data, why not plug this directly into OpenCPN?

BTW the idea of 200$ N2K interface somewhat escapes me. Why do you need an interface? To plug it into your SK server? Oooppps. Because most modern plotters and instruments can use N2K data right away.

You are 100% right about a cheap SK sensor (we could build them, even I could), but a cheap n183 sensor (we can build them, same hardware, I do) is just as easy and compatible with what we have in situ. So, why to build SK that is compatible with what we do not have onboard?

And since the proposed SK server will mostly only translate SK data from N2K to and back and to n183 and back, you can forget (imho) about building it cheaply. I do small things Arduino / Android based. Bare bones are cheap but once you add some level shifters, wifi modules, etc. etc. the whole exercise stops being cheap and carries zero warranty benefits. I also think (but I am not sure) that a plain Arduino will not manage a swift SK flow if it is asked to do the translations at the same time. Unless we talk only very few and 'slow' sensors. Right now our 38400 baud sensor is spewing out over 100 sentences a second. It is only one sensor. Add a 10 Hz heading sensor, a 10 Hz gps sensor ... and watch those shields burn. ;-)

C'mon and enlighten me how you are going to plug that N2K data into your SK server without that am 200USD device and without knowing N2K structure and doing heaps of data format translations.

It is getting interesting.

Over,
b.

[barnakiel]

Originally Posted by Lake-Effect

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.

Bad examples - Windows and IOS have open, pubicly 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.

In order to build your SK server you also need in-depth knowledge of N2K anyways. Or not?

How do you get this knowledge without buying, decoding and sharing with others alike?

And if / once you do, then why build the SK translator anyway. Why not use the new found N2K knowledge directly onto (e.g.) OpenCPN.

As for Windows being open, pls post a link to where it has been published (OK, you can dodge this one - see my earlier post). ;-)

I could be wrong on Macs though. Here they cost 5 times the price of a Windows PC so few people have them. They might be open, I just did not know.

The bus thing - we leave it alone - as someone noted above, SK does not address the bus element. It takes in N2K input and translates it to SK and back. Look at the images I posted. The only place where we could talk 'the bus' would be a native SK sensor but since SK does not address the bus challenge, we will not even know how to wire the SK sensor electrically. We sure want some form of CAN bus, unless we are going to build even more (imho not needed) hardware.

Bueno. Off now to my present project. Which happens to be a data translation and distribution thing too.

Thanks for educating me. I will peek in tomorrow again.

Best regards,
barnakiel

[Lake-Effect]

Originally Posted by barnakiel

Except that SK still has to translate from N2K and back and how do you do this translation without knowledge of N2K? Or do you already have good N2K knowledge and refuse to share it?

Argghhh. So we do need to know what that N2K data is all about ANYWAYS. Or else we are buying that 200USD device.

And once we know how to read the N2K data, why not plug this directly into OpenCPN?

BTW the idea of 200$ N2K interface somewhat escapes me. Why do you need an interface? To plug it into your SK server? Oooppps. Because most modern plotters and instruments can use N2K data right away....

C'mon and enlighten me how you are going to plug that N2K data into your SK server without that am 200USD device and without knowing N2K structure and doing heaps of data format translations.
Over,
b.

Dude - I confess I'm a bit lost over what you're fighting about now.

N2K is a closed proprietary system. The only way to access data is to buy an official adaptor ($200) . After the adaptor, yes we now have useable data, in the format described in your linked docs. I think we all agree here.

So let's look at use cases:

1) I have an N2K system I want to extend or access

Answer - buy an official adaptor. That's the price of admission. This is the case I believe you're focused on... and you're right in that if you already have a full N2K system, what's the point of adding something that talks SK? It would probably be along the lines of custom data logging, a wifi link to portable devices, a home-built autopilot, etc. Stuff that not every sailor would necessarily care about.

2) I want a totally open-source boat navigation system and/or I have NMEA0183 stuff that I want to extend

Answer - you can set up a pretty good system with low-cost hardware, open software and SK as intercommunication. Again, not every sailor is that much of a nerd.

I guess what I'm saying is that there won't necessarily be that big of an overlap between those with a full-up N2K system, and those wanting to make extensive use of SK. At least at this early stage.

If SK takes off, the smarter manufacturers will begin to offer a subset of their data available via SK.

[Lake-Effect]

Originally Posted by barnakiel

In order to build your SK server you also need in-depth knowledge of N2K anyways. Or not?

How do you get this knowledge without buying, decoding and sharing with others alike?

And if / once you do, then why build the SK translator anyway. Why not use the new found N2K knowledge directly onto (e.g.) OpenCPN.

We have the decoded data format; you linked the docs. We do not have the actual bus format; we must buy an official interface.

As for Windows being open, pls post a link to where it has been published (OK, you can dodge this one - see my earlier post). ;-)

I could be wrong on Macs though. Here they cost 5 times the price of a Windows PC so few people have them. They might be open, I just did not know.

I never said Windows or IOS were 'open'. I said they provide enough public info that anyone can connect stuff to them and create software to run on them for free, without licences or official proprietary interface. You can't do that with N2K.

The bus thing - we leave it alone - as someone noted above, SK does not address the bus element. It takes in N2K input and translates it to SK and back. Look at the images I posted. The only place where we could talk 'the bus' would be a native SK sensor but since SK does not address the bus challenge, we will not even know how to wire the SK sensor electrically. We sure want some form of CAN bus, unless we are going to build even more (imho not needed) hardware.

As I said, maybe in a roundabout way, having ONE common electrical data bus in a boat isn't always the optimum thing. It's a single point of failure, and it's going to add complexity and cost to every sensor. The users of N2K are all ok with that; the cheapskates nerds like me might be interested in lower initial cost.

In a SK or similar system, the 'bus' is the networking and that's most likely ethernet or wifi. A very common and open standard.

You already know why N2K exists - it's a system that allows a big range of marine instrumentation and electronics - navigation, environment, monitoring, control, display - to intercommunicate, and physically, it's Tinkertoys - a backbone, tee-connectors for everything to connect like leaves on a vine - easy peasy (except it's not quite, but that's the concept). It's something the trade loves, cos it's easy to install and upgrade.

This makes the most sense for the main instruments and repeaters... a bit less sense for transducers. Do you find yourself changing out transducers alot? Is there really a benefit to a N2K bus to the masthead? Most people install sensors and forget about them til they quit. The added cost of having a N2K transducer, the easy Tinkertoyness are mostly a waste then, aren't they?

[conachair]

Originally Posted by barnakiel

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

That pretty much describes my boat. No nmea2k on board, just gps/ais NMEA083 which has a very limited range of messages, not surprising for something 25 years old. So pretty useless for anything like temperatures from engine/alternator/exhaust etc or battery voltages/current draw etc. So in my case signalk is a godsend, load onto a computer like a raspberry pi and it just works. Not sure where you get the idea of complexity. View the data on any web device or the slowly growing number of tablet apps. Easy to save to a file as JSON. Free and open source without being at the mercy of a large commercial association.
Luckily, it doesn't make any difference what negative views of a few posts on an internet forum appear, signalk is alive and well and looks to become a part of equipment coms onboard, albeit a bit slowly...
Just as nmea will continue, like the ancient 0183 continues.

What will be nice is when opencpn, especially the dashboard starts reading signalk, it's running round the houses a bit and very limited to turn sensor data into 0183 so it can all be seen on one screen, eg - engine temp into water temp.

[sbender]

Originally Posted by barnakiel

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

None of this tells you the exact format of the encoded messages. You could not write an N2K decoder with just this info. You will also have to do reverse engineering. Join the NMEA (big bucks) and you can get the the actual details of the protocol. Thus "closed".

[sbender]

Originally Posted by barnakiel

In order to build your SK server you also need in-depth knowledge of N2K anyways. Or not?

How do you get this knowledge without buying, decoding and sharing with others alike?

And if / once you do, then why build the SK translator anyway. Why not use the new found N2K knowledge directly onto (e.g.) OpenCPN.

As for Windows being open, pls post a link to where it has been published (OK, you can dodge this one - see my earlier post). ;-)

I could be wrong on Macs though. Here they cost 5 times the price of a Windows PC so few people have them. They might be open, I just did not know.

The bus thing - we leave it alone - as someone noted above, SK does not address the bus element. It takes in N2K input and translates it to SK and back. Look at the images I posted. The only place where we could talk 'the bus' would be a native SK sensor but since SK does not address the bus challenge, we will not even know how to wire the SK sensor electrically. We sure want some form of CAN bus, unless we are going to build even more (imho not needed) hardware.

Bueno. Off now to my present project. Which happens to be a data translation and distribution thing too.

Thanks for educating me. I will peek in tomorrow again.

Best regards,
barnakiel

We have reverse engineered much of the N2K protocols. That's how we get it into SignalK. Let the server handle that and have the clients use a modern internet based protocol that is easy to write software for and supports more than just N2K and 0183. I'm sorry that you still don't get it.

[barnakiel]

Originally Posted by sbender

We have reverse engineered much of the N2K protocols. That's how we get it into SignalK. Let the server handle that and have the clients use a modern internet based protocol that is easy to write software for and supports more than just N2K and 0183. I'm sorry that you still don't get it.

Any links to the reverse engineered info?

As you can read in another posters entry somewhat earlier, when it is not published, it is not open. Possibly implying non open is no good (my guess, the poster did not say the latter thing explicit). I will disagree.

I think I get it by now. At least part of it. Thanks to you guys.

I will keep on reading. A bit tired by now to argue the fine points - nearly midnight here. I will read on tomorrow.

Thanks for all patience and helping me understand SK.

Cheers,
barnakiel

[barnakiel]

Originally Posted by sbender

None of this tells you the exact format of the encoded messages. You could not write an N2K decoder with just this info. You will also have to do reverse engineering. Join the NMEA (big bucks) and you can get the the actual details of the protocol. Thus "closed".

Are you going to share the N2K know-how that you have reverse engineered?

barnakiel

[sbender]

Originally Posted by barnakiel

Are you going to share the N2K know-how that you have reverse engineered?

barnakiel

It's open source. It's analyzer in the canboat project, which we use to get N2K into the signalk-node-server. (You'll see me there as a contributor). Take a look at this code and you should see why no one wants to deal with this protocol directly.

https://github.com/canboat/canboat/tree/master/analyzer

[barnakiel]

Originally Posted by sbender

It's open source. It's analyzer in the canboat project, which we use to get N2K into the signalk-node-server. (You'll see me there as a contributor). Take a look at this code and you should see why no one wants to deal with this protocol directly.

https://github.com/canboat/canboat/tree/master/analyzer

THX!

Bookmarking now and to read tomorrow.

When I am done doing my present stuff (a BT multiplexer server, n183) we are off to the West Indies (tentative October) where I am likely to be building more small stuff. I hope to have six to eight months for fun and study.

If I manage to understand SK, I could build then SK versions along with n183. People could then assemble whichever style they find best fits their need.

Good night from here (LPGC)

barnakiel

[sbender]

One thing to point out. There is some disinformation about needing to buy the $200 Actisense NTG-1 to get N2K. There are some people who have built Canbus interfaces using an Arduino. I'm not a hardware guy so I never looked into it. Google it.

[Lake-Effect]

Originally Posted by sbender

One thing to point out. There is some disinformation about needing to buy the $200 Actisense NTG-1 to get N2K. There are some people who have built Canbus interfaces using an Arduino. I'm not a hardware guy so I never looked into it. Google it.

That would be me, and was my understanding to this point. I didn't know that that there was a viable open-source project that was capable of speaking native N2K right onto the bus.

So, my apologies, and thanks for the info. I just found this library, (which I had actually bookmarked a while back - oops) and read some discussion around it. Looks doable, but definitely not as easy as installing OpenCPN, so it's still on the expert end of the DIY spectrum.

For the record... if NMEA2000 really does deliver a dependable backbone and provide true interoperability, then $200 for a supported, tested interface to this system isn't a big hit. And a potential savings, depending on how much you value your time.

[barnakiel]

Yes. There is one. But it is just the hardware layer. The knowledge of how the N2K datagram is built/structured is still the prerequisite to built any N2K to X interface. PRICELESS.

One must allow for the fact that Arduino may or may not provide enough muscle to handle the can bus to X (another can bus or Ethernet - if wired // BT or Wi-Fi - if wireless) translation. When there is a lot of data and little hardware one is best off with minimal code. From my (limited) experience with Arduino only the Mega can handle some amount of serial data. Other cheap boards have only one serial (the other 'serials' being data emulation and thus very limited in processing/data speed). Possibly there are some stronger Arduino boards around.

Where I do get (mentally, I admit) stuck is that once the N2K datagram properties are known, any need for translations disappears (to me, not objectively) - you can use N2K directly in the target UI (say OpenCPN, qtVlm, etc.)

The BIG plus of having SK around would be the immediate simplicity of its syntax. Great help for the less hex or binary fluent coder. I think.

The BIG minus seems having yet another interface. A possible bottleneck and another place where things 'get lost in translation'.

You know there are millions of hardware and software people in this world and we all have our personal and not always rational preferences. I may hate java and hearing JSON I get goosebumps. Others will love it. Etc.

I have never investigated but possibly xml is directly machine readable to JSON. Then again learning new stuff is always best for the grey matter, little of it as I have left.

I like being on the hardware / software interface but this makes me neither a good programmer nor a proper hardware developer. A limbo where so many other hobbyists get lost.

Have a fine day.

b.

[conachair]

Originally Posted by barnakiel

) - you can use N2K directly in the target UI (say OpenCPN, .

Are you sure without converting it into 0183?