NMEA OneNet finally released

laika

Well-Known Member
Joined
6 Apr 2011
Messages
8,307
Location
London / Gosport
Visit site
Don't know if it's been widely reported but I just noticed that version 1.0 of NMEA OneNet was finally released a couple of weeks ago. Only about 8 years late:
https://www.nmea.org/Assets/2020 NMEA OneNet Press Release.pdf

Not available to anyone except manufacturer members at this point and probably a while before we see any products. Anyone have any more info, like which of the working groups' output was included (e.g. does it include a radar imaging standard?)?
 
Is the lack of comment because
- you don't know what this is about
- it's already been discussed
- it's a non-story until there are actual products on the shelves
- you have no reason to replace the walker log and the lead line
?
 
Is the lack of comment because
- you don't know what this is about
- it's already been discussed
- it's a non-story until there are actual products on the shelves
- you have no reason to replace the walker log and the lead line
?

None of the above, but uninterested cos signalk exists - what nmea could be like if it ever grows up ;)
 
For those who were unaware, OneNet is the NMEA's new data networking standard. It's about 8 years late. Whereas NMEA-2000 ran over CAN-bus, OneNet is layered on top of IPv6 over ethernet. In other words it runs on a regular computer network, but not quite because the "Internet Protocol" it uses is the "next generation" one which was supposed to have replaced the most common current one 20 or more years ago but in fact is only creepingly slowly doing that now.

The NMEA are stating that OneNet is a supplement to rather than a replacement for NMEA-2000 because N2K offers "real time" control which OneNet doesn't, although that's for a technical notion of "real time" which is important in some safety critical systems but largely shouldn't bother leisure sailors.

None of the above, but uninterested cos signalk exists - what nmea could be like if it ever grows up ;)

I never know whether you mean the SignalK server program or the SignalK JSON data format but either way they're not really competing in the same space. SignalK has a monolithic central server and communicates with a "fat" JSON data transfer mechanism. It's designed by and for people who program applications in high level languages and thus is great for allowing people to write nice looking javascript apps. It's all dependent on a small group of hobbyists who may disappear off sailing for the summer, it's continually evolving and there's no formal certification process which is not a worry for your $4.99 phone app but might be for the €2000 chart plotter you want to talk to the rest of your boat.

OneNet by contrast is a full-stack distributed system which should be* backed by certification processes in the same way as the previous NMEA protocols but higher bandwidth now allows stuff like a standard for radar imaging transmission potentially offering the possibility of mix and match scanners and MFDs**. I'm happy to negotiate some wager involving rum regarding the presence or absence of support for NMEA OneNet vs SignalK in Raymarine, Navico and Garmin products in 2 years' time....

I'm not a fan of the NMEA's pay-for-standards model but from what I know of OneNet (or what I knew about the concept 8 years ago) it sounds like a pretty reasonable design.

*Apparently the certification tool for OneNet is not yet available
**Assuming the radar working group has delivered or will deliver what Ben Ellison of panbo said they were working on
 
In other words, it's a bit of a dog's dinner and we simple leisure sailors shouldn't worry our little heads about it until the manufacturers start selling the kit in XX years' time.
 
It's designed by and for people who program applications in high level languages and thus is great for allowing people to write nice looking javascript apps.
Nah, design for sailors actually, and gets more user friendly every day :cool:
Many people involved and the slack help is as good as you could hope for though it's robust now so mainly people digging deeper & developing on there.
The money is with the manufacturers though and few are forward thinking enough to see how powerful it is, one day :)

Also, I don't care about NMEA cos signalk will accept whatever format they can come up with, no need to get involved.
Rock on opensource! :cool:

One day a major will release a MFD with a signalk server built in and the ball will start off down the hill. Maybe.
Data overload with Signal K Server, a Raspberry Pi and a whole lot of tools – Panbo
 
Last edited:
Is the lack of comment because
- you don't know what this is about
- it's already been discussed
- it's a non-story until there are actual products on the shelves
- you have no reason to replace the walker log and the lead line
?
:-)
I'd go for C

Interested, didn't know of this development though.
Having spent enough time playing with N2K, setting things up, reverse engineering (with the help of Timo) some Maretron custom PGNs, then building my own custom PGNs, working with Timo's libs and even sorting and building a batch of teensy 3.5-3.6 boards for all sorts of jobs on board my mobo, I'd be interested to know how this would affect me in the long run.
I fear with the snail pace standards move, develop and get implemented and accepted by mainstream builders it will be of interest to me once I retire in 10yrs time and start considering a move to sail...
I'd be happy to stop having to buy expensive tees and M12 micro connectors, but I already have an extensive network with over a dozen devices on!

V.
 
It's not like everything with an nmea 0183 connection worked seamlessly with other 0183 stuff.....same for n2k...there will always be proprietary adaptation and anomalies in use....shock horror...the manufacturers want *ALL* your kit to be bought from them.
 
well, not quite, they'll try and add some custom sentences especially for special kit they only produce, both Garmin and Maretron (that I know fairly well by now) do it.
but again, in many cases it has to do with the stupidity of the standard itself.
for example, try measuring EGT with the normal temp PGNs. No fcking chance! the relevant PGNs only go up to 250C or thereabouts (have to look my papers) So, Garmin has no thermocouple sensors and ignores it completely (doesn't support it at all!) Maretron has thermocouples, a custom black box to wire them, and inevitably a custom PGN to support it on its screens. Eventually got the PGN contents and currently using EGT measurement through my custom board but cannot view the values in my Garmins, only the Maretron.

My other pet hate is the stupidity of Garmin in limiting gearbox oil pressure value in their displays to 200psi (iirc) when normal mobo gboxes run at 25-30bar, wtf! Again Maretron without using custom PGNs just leave the limits to be set by the user and of course it works.
At least even on PGNs that are not fully supported, you can do the calcs on your board and issue Engine Warning/Error PGNs so that at least you're aware of something going on and then investigating further on the right display.
 
In other words, it's a bit of a dog's dinner and we simple leisure sailors shouldn't worry our little heads about it until the manufacturers start selling the kit in XX years' time.
:)
I'd go for C

"I'll worry about it when I see a product" is a perfectly reasonable view however although I often get confused between the various meals dogs have (of which lunch must be the best because no-one speaks badly of that), without having seen the standard there's nothing to suggest it's appropriate for canine consumption: I rather like the concepts I know of.

Anyway, given this protocol has been such a saga getting to version 1 I think it's newsworthy and means I might delay buying a new radar for a year or so. I haven't invested as much as vas in N2K.

Nah, design for sailors actually, and gets more user friendly every day :cool:
Many people involved and the slack help is as good as you could hope for though it's robust now so mainly people digging deeper & developing on there.

Again when you talk about "Signal K" I never know whether you're talking about the signalk data exchange format and saying that JSON over http from a monolithic central server is far better for a marine data and control network than a binary multicast protocol over udp over IPv6 or just that you like the applications that are bundled with the Signal K server. The two things both have their place but different optimum use cases. "Normal" people (largely unlike anyone me, you, or probably anyone else on this thread :) aren't interested in mucking about with raspberry pis and having everything fall over if one dies: they want to plug something in and have it just work with their other stuff because it's been tested for compatibility (in the core functionality at least, proprietary extensions notwithstanding). If it doesn't work they want to send it back, not sign up for a slack account for a back and forth with "the community". From your panbo link:

In the process of getting data into my server, I came across a small syntax error in the SKS code that was causing my connection to die periodically. After discussing with the Signal K Server team I made a small change to the code and was off and running.
 
Again when you talk about "Signal K" I never know whether you're talking about the signalk data exchange format and saying that JSON over http from a monolithic central server is far better for a marine data and control network than a binary multicast protocol over udp over IPv6 or just that you like the applications that are bundled with the Signal K server.
Whoa there Sunshine. We now have Civilised Public Discourse rules init? o_O

Richard
 
A few points worth responding to here. Sounds maybe a while since you've had a play with signalk? It's come on fantastically in the last year or so.

Again when you talk about "Signal K" I never know whether you're talking about the signalk data exchange format and saying that JSON over http from a monolithic central server is far better for a marine data and control network than a binary multicast protocol over udp over IPv6 or just that you like the applications that are bundled with the Signal K server.

The server / the messages are pretty much synonymous these days, no one else mentions it, like whatsapp is messages and an app. I don't really care much about what format is transporting the interesting data around though being able to read the messages makes life so much easier if you want to dig a bit deeper , best bit is it just works all the time and will do anything you can think of with boat data.
In fairness nmea doesn't actually do anything apart from shove numbers from one place to another so there's not really much of a comparison.

The two things both have their place but different optimum use cases. "Normal" people (largely unlike anyone me, you, or probably anyone else on this thread :) aren't interested in mucking about with raspberry pis and having everything fall over if one dies: they want to plug something in and have it just work with their other stuff because it's been tested for compatibility (in the core functionality at least, proprietary extensions notwithstanding).
True, most people aren't interested in much more than seeing their boat and maybe some ais on a chart plotter, over many years now I've never had a Pi die, though killed a couple ;) So cheap if you worry buy 2. Can't think there would be many compatibility problems, maybe a few wierder nmea2K massages won't get recognised. The server will decode seatalk1 messages now though you'll need a little circuit to get the voltages right.

One area which is pretty rubbish though is documentation, as often happens with opensource. There is an expanding crowdsourced FAQ but nothing like an in depth manual.

If it doesn't work they want to send it back, not sign up for a slack account for a back and forth with "the community". From your panbo link:
"In the process of getting data into my server, I came across a small syntax error in the SKS code that was causing my connection to die periodically. After discussing with the Signal K Server team I made a small change to the code and was off and running."
Isn't that a good example of just how well opensource works? Article was April so guessing this was maybe a year a go - someone found a bug in some software, happens all the time, then it was fixing really quickly, - " I mention this because it’s worth noting that these are still early days for an open source effort composed of volunteer developers contributing to a non-commercial product for the good of other boaters. While working with the SK team on a few new features and issues I’ve been really impressed at how quickly features and fixes are implemented; usually only taking an hour or two."
A year is a long time for opensource, the slack channel is *always* busy with responses to questions very rapid but mainly developers discussing esp32 and plugin development, very rare to see a bug come up in the core server though tweaks happen all the time with updates common.
Also should be put to bed the myth that you need to be some ubergeek to get a Pi running openplotter capable of doing pretty much whatever you could think of involving boat data. If you can get opencpn running on a laptop then openplotter will not be walking into the unknown. Installs on windows as well with a download and click of a mouse.
Each to their own but there's a little core negativity against openplotter/RPI on here which after running for years I really think is unfounded. SigK just works, rock solid day in day out. If you want to actually dig deeper into all the data.
Can't think of anything which comes even remotely powerful available for so little money and power consumption.

You'll still need a case and some 5v though.

Or a damp chart and blunt pencil. :)
 
Last edited:
Top