I think a group picture of the NMEA 2000 Standards Committee deserves a place on the Wall of Shame. NMEA 2000, aka N2K, has so much potential, and has helped the marine industry in many ways. But it's implementation falls well short of it's real potential. It's great for wiring up a 25' center console boat with one of this and one of that. But try building up a bigger system with lots of devices, many of which are redundant, and it very quickly comes unglued. It's no wonder that N2K is not part of any IMO approved device.
One of the biggest problems is that N2K is a secret. To get a copy of the spec costs $5000 or more, so nobody other than a manufacturer will ever see it. And even if you cough up to $5000 to buy the spec, it comes with a stipulation that you keep it secret. The result is that none of "us" - not boat owners, not repair techs, and not electronics installers - really know how it's all supposed to work. So when something isn't behaving properly, there is no way for us to know what's right and what's wrong, and hence no way to chase down whoever's product is misbehaving.
Instead, we get the run around. Has anyone else ever experienced this? You are having a problem, and might even be using an analyzer like Actisense's NMEA Reader, or Maretron's N2KAnalyze (both great products) and have an idea where the problem might be. So you call tech support for vendor A, describe the problem and tell them how you think their product might be misbehaving. Vendor A gives you some mumbo jump about how things are supposed to work and tells you that Vendor B's product isn't doing things correctly. Not knowing any better, you believe them and now call Vendor B, explaining to them what you were told by Vendor A. Vendor B now gives you some different mumbo jumbo and explains how Vendor A is doing things wrong and that they are the problem. Now you are in the dark here, so have no way of calling bull-shit on either of them. And these two companies won't pick up the phone to the other company to sort out the issue, but instead leave you as monkey in the middle. Sound familiar to anyone?
If purchasing a spec includes other stipulations, one should be that you are not allowed to tell a customer that another vendor's product is broken, but rather be required to call that vendor and work it out. If these guys want to sell more product, it has to work. By way of example, my boat started out 100% N2K. I have subsequently removed about 30% of the N2K devices, and the replacement communications is via 0183. I did NOT want to do that, but it has proven to be the only way to make it work in a reliable and predictable way.
The next issue is NMEA 2000 Certification. I read over and over again about how all troubles will go away if you only use NMEA 2000 Certified devices. These are devices that have voluntarily subjected their products to a battery of tests that demonstrate proper adherence to the N2K standard. Well, I can tell you in no uncertain terms that NMEA 2000 Certification does not indicate that a product complies with the standard, and there is one very large and glaring example. Instancing.
[Editor's note, Dec 12, 2015. Please note that in this post I am talking about NMEA 2000 Device Instance Numbers, not Data Instance Numbers. I was not clear and I believe this has led to a lot of confusion. Here is an article explaining the difference
, so please take a look]
[Editor's note, Dec 12 2015. Please also note that the following discussion of Device Instancing is heavily used by Maretron, and not used at all by many other vendors. Please read all the way through to understand NMEA 2000 NAMEs and how they provide an alternate, and more commonly used way distinguish and select devices. But keep in mind that these two different approaches and the conflicting support in device certification is exactly the point of this post.]
Instancing is a way to distinguish between otherwise similar devices. It's a number that you assign to devices, kind of like taking a ticket at a deli counter. The picture below shows a real life example of where this comes into play. The network in the pictures shows a chart plotter, a sat compass, a GPS, and a rate compass.
|Example N2K network with redundant sensors|
The sat compass and GPS both provide position, speed, and course information, but the sat compass is the superior instrument providing more accurate info than the GPS. Similarly, the sat compass and the rate compass both provide heading and rate of turn info, and once again the sat compass is the superior instrument yielding more accurate info.
In the absence of instance numbers, the chart plotter would have no way to distinguish between the two duplicate sources of data. It might pick randomly, or even worse it might use both, mixing data from different sources.
Instancing solves this problem in two steps. The first step is that every device producing data, typically referred to as a Source (the sat compass, GPS, and rate compass in this example) must have a way to change its instance number. There is a standard message that can be sent across the N2K bus to change it, and many devices support this, though it's not required. But if a device doesn't support that method, it must provide some other way.
The second part of the solution is that any device making use of data on the bus, sometimes called a Listener, needs to have a way to pick which device it wants to listen to. More sophisticated devices can be given a prioritized list of devices, and they will always use the highest priority device that is available.
Bringing this back to N2K Certification, I have encountered numerous devices that are certified and that do not provide programmable instance number. These are certified as standard compliant devices, yet they blatantly violate the spec. And if you try to use these devices in anything other than the most simplistic network, or more accurately a network where there is never more than one such device, it doesn't work. This is a HUGE loop hole in the certification process, and a huge short fall in vendors implementation of N2K devices.
Devices where the Instance number cannot be changed or doesn't work properly:
- ICOM M506 N2K
- ICOM M506 N2K-AIS
- Simrad HS70 sat compass
- Simrad AT10
- Simrad AT10HD
- Simrad NAIS400 AIS transceiver
- Furuno NavPilot 700 computer (FAP7002)
Looking at the other side of the problem, it gets even more complicated. I actually don't know whether devices are required to be capable of source selection. If I could read the spec I could tell you, but I can't read the spec, and if I could I wouldn't be allowed to tell you. What I do know is that there are a variety of ways a device COULD do source selection, they all seem to be valid and compliant, but are often times incompatible. Here are two examples.
Every N2K device has a "Name", and that name is guaranteed to be unique. A device's name is composed of a number of different things similar to a first, middle, and last name in our US culture. An N2K name is a combination of the device type, manufacturer, instance number (there it is again) and a unique number assigned by the manufacturer. Worth noting is that every device has a unique name even if they all have the same instance number. So every device on the planet could have instance number zero and you would still be able to differentiate all of them.
When doing source selection, some vendors use the unique name and are not dependent of programmable instance numbers. But other vendors depend on programmable instance numbers and use it as the primary way to perform source selection. Both approaches are legitimate, but it results in two very different views on the importance if programmable instance numbers.
One guy at NMEA told me that a network should be completely usable and operable even if all instance numbers or zero. That says that one cannot depend solely on instance numbers for source selection. And a number of vendors I have spoken with about their non-programmable instance number point out that it's not needed. Well, maybe it's not needed by them.
Maretron, a prominent vendor and member of the NMEA 2000 Standards Committee has build a product line that depends 100% on programmable instance numbers to do source selection. If you can't program a devices instance number, then you can't tell it apart from another device sending similar data. Maretron defends their position saying that programmable instance numbers are mandatory in the standard and that other vendors needs to implement it.
Both are right, but the result is that building larger, redundant networks is very problematic, and we the customer are caught in the middle. It also means that we the customer aren't buying as much product as we would if we could reliably build redundant systems using N2K.
All this comes back to the N2K Standards Committee. If they can enforce secrecy of the specification, then surely they can enforce compliance with the spec. And at a minimum, certification should actually reflect compliance with the spec. Then it would be a mark that we could seek out to buy with confidence. But right now, NMEA 2000 Certified doesn't mean much of anything.