NMEA 2000; Some Limitations and Cautions

The intent of this article is to familiarize the boat owner with some limitations that I and others have found with NMEA2000.

NMEA2000 technology was borrowed from the non-marine industry (CAN bus) and adapted to the boating industry. Unfortunately, that has left it with some short comings which I will attempt to explain in this article. Also along the way, some manufacturer's have seen fit to produce products that don't fully comply with the nmea standard.

So what is NMEA2000?

The idea for which the bus was developed, is effectively to use a display from manufacturer A, and possibly a sensor from manufacturer B, connect them both to the NMEA2000 network, and the display will show what the sensor detects. In the ideal network, this should be possible. Even NMEA 0183 could do this in a limited way.

Prior to the development of NMEA2000, the boating industry used an older standard for interconnecting equipment; NMEA 0183. This standard was meant to provide a point-to-point connection between two devices. Obviously the point-to-point scheme between just two devices, is very limited. NMEA 0183 is great for simple applications. It’s so good, in fact, that an updated, high-speed version has been introduced to handle the information from AIS receivers. But a truly integrated system requires more than NMEA 0183 can provide.  NMEA 2000 is 50 times faster than its predecessor, NMEA 0183, so it can handle data from up to 50 different devices, but it’s still not the complete answer. That’s because those message headers can occupy any amount of data up to half of each frame. The result is that NMEA 2000 is too slow and inefficient to be useful for complex data such as video images or cartography.  NMEA2000 is a shared network, not unlike Ethernet, where many sensors, displays, and control units can be interconnected on one common network but has severe bandwidth restrictions to what is available over ethernet. 

Also, when in implementing the standard, manufacturers, for whatever reason, have tended to "go their own way" with NMEA2000. For instance, some of the first generation NMEA2000 hardware used different (and incompatible) connectors, depending on the manufacturer. An example of the first generation incompatible connectors are the Lowrance "Blue" connectors, which will only connect to a Lowrance NMEA2000 device. Fortunately, most manufacturers have seen fit to finally embrace the standard, and Lowrance's "Red" connectors are NMEA2000 standardized, and will interconnect with any other vendor's NMEA2000 connector. 

In addition, Maretron does provide field installable connectors that you can use to correct the early manufactured non-standard connections. For instance, with Lowrance "Blue" devices, I cut the connector off and installed a Maretron field installable connector to make them compatible with the network.

However, there are still some incompatibilities across the various manufacturers as each manufacturer is allowed to develop their own private data packets in addition to the standard (or public) packets defined by the NMEA2000 standard and used by everybody. As well, not every device understands every packet - even the standard NMEA2000 defined packets. That rudder packet may be ignored by a certain display if it doesn't have the capability to display rudder information. For that reason, you cannot simply use any display with any sensor. You may need to review the capabilities of the display unit you wish to use to ensure it can read the sensor. Fortunately, most manufacturers do publish this information.

So this leads me to my first caution...
Because of these "private data packets",  some vendors may purposely use private PGNs (those that only that manufacturer's equipment understands). So a certain device may only be able to be read  that manufacturer's equipment, regardless of whether or not the device has a standard connector.
Also, many sensors must be programmed before use, and this usually requires a display unit of the same manufacturer to program them. However, once programmed - the sensor may be able to be detected by any other manufacturer's product. This incompatibility still exists to some degree, so be aware when mixing products from different manufacturers that you may run across a few problems.

Building a Network
NMEA-2000 initially provided for two network cabling schemes; called Mini and Micro. Maretron now offers a third scheme called Mid. So the first question to answer is which one do I use? While each cabling scheme is identical in their bus configuration, the major difference is the capacity each network will provide. They are:

Since each device on the network requires a different amount of power (i.e. a display unit is likely to demand more power than a sensor), some thought must be given to how much total power the various devices require. NMEA-2000 includes a LEN specification that every NMEA-2000 device must provide. ( 1 LEN = 50mA ) Therefore, if a sensor states that it has a LEN of 5, you know that it's current requirement is 250mA. The idea of the LEN is to add them all up, and they should be less than the maximum LEN of the cable. From the chart, essentially the decision of which cable to use is determined by the length of the network you want to install, and the number of devices you need to support, and their total current requirement.

But there are limitations to the network.
The cable distance between any two points (a point being an electronic product or terminator) must not exceed 250 meters (820 feet) for a system based on the Mini or Mid trunk cable or 100 meters (328 feet) for a system based on a Micro trunk cable
AND the cumulative drop line length is the sum of all drop lines, Mini, Mid or Micro cable in the cabling system; This sum cannot exceed 78 meters (256 feet) and no single device can be more than 6 meters (20 feet) from the trunk line.
This places limits for sail boats with masts greater than 20 feet. Effectively it means the main trunk of the Network has to go up the mast, and  to cover instruments or sensors forward of the mast the main trunk has to do a big "U" back, or use a drop line no more than 20 feet. If one wants to put more than one sensor at the top of the mast, the wiring becomes more of a problem with probably the "T' junctions and terminator living outside the mast in the elements.

BUT in addition to this, excessive voltage drop can be an issue when using Micro cable, due to the small size of the power wires within the backbone. Especially on long cable runs you can have excessive voltage drop, even if the total power required by all of the devices is less than the LEN rating of the cable. To determine the voltage drop, an easy formula can be used: Voltage drop = LEN X Cable Length(in meters) X Cable Resistance(in ohms)/100

Clearly for sailboats the micro cable probably can't be used, but one could use a Micro network with a Mid backbone cable. Essentially the only difference is that the Mid cable uses 16 AWG power wires, where the Micro cable uses 22 AWG. Otherwise, all of the connectors and terminators are identical. This is the most cost-effective solution as Mid cables do not really cost much more than a Micro cable, and you can still use the less expensive Micro connectors and drop cables.

One important item that needs repeating is voltage drop.  Attention must also be given to the feed wires. The wiring route from the battery to the NMEA22000 power tee should be minimized to reduce voltage loss. This is sometimes difficult as often, the power switch for the network logically belongs at the helm, however (especially with a center-feed network), the power tee may be located some distance from the helm. One solution is to install a relay near the power tap, which is switched at the helm. The relay would allow a remote switch at the helm to turn the network on or off with minimum voltage loss.

Now my second caution......
Now consider this. If there is a problem with the NMEA2000 back bone, every piece of gear on that network that is dependent on it, stops working. Everything, that comunicates with each other, becomes non effective.

• The GPS stops working, including the plotter
• The fluxgate compass  doesn't work
• Engine instruments don't work
• AIS doesn't show anything
• the autpilot stops working because it doesn't get a heading from the compass 

Get the picture? Now we all know this will happen at the most inopportune  moment.  One may start (trying to find the fault) by unconnecting and reconnecting every connector on the back bone to make sure that they are properly connected. There can be meters of cabling in hard to reach and dar,k places on your boat and all it takes is just one of those connectors to fail and it's "lights out". And if the problem is intermittent, as it very likely will be, then the trouble shooting is going to be ten times more difficult. Then if cleaning and reseating connectors or terminators cannot solve a problem, then by all means seek the professional help of an NMEA-certified electronics technician. Good luck with that, in some of the locations we go to!

What we need to think about is what a network failure will do to us on a dark night in a tricky situation. We must have a backup plan. And because of the issues with trouble shooting these complex systems in remote places, it would be good to have a plan for continuing our cruise without all this interconnection potential problems. Here's some things that could help

•  Have a plotter with a separately connected GPS sensor, or GPS with paper charts, available. Or consider an iPad with it's own charting system. We use it all the time now, to compare two separate chart systems. It has it's own GPS
• There is a separate AIS unit with its own screen and direct connection to its own GPS within sight of the helm. Some of the latest up market VHF have AIA receivers on the screen.
• There are backup hard wired, or mechanically connected, engine instruments.
• And don't forget a properly swung magnetic compass. 

 Now it's not that I'm against NMEA2000. I like the idea of just one cable running the length of the boat. But consider this; since the 14 years NMEA2000 has been out, we now find a class of products specifically marketed to users of existing navigation software that offer to gateway from NMEA2000 physical networks to USB, translating NMEA2000 packets on the fly to NMEA0183 sentences that existing software can read. This reveals that NMEA2000 adds little information and little value to the contents of an NMEA0183 stream of navigation data. The coupling of NMEA2000 to a proprietary physical network is so tight that there is no standard for shipping it over USB, RS232, Ethernet, or any of the other physical networks commonly used in the general computing market at the present time. However, in the near future,  NMEA is going to release a standard called "OneNet" for interfacing NMEA2000 to ethernet and I suspect the bridges to USB etc will appear around the same time.

So when that comes about, are boats then going to run another cabling system around their boat to accommodate for the higher bandwidth of devices today, that NMEA2000 can't handle? It sort of defeats the purpose of running just one cable. NMEA2000 specification itself is proprietary and expensive. Ethernet is more of an open standard and open source and open protocols grow markets and create opportunities. NMEA2000 sharply illustrates the obverse of this point. It is tied tightly to a specific physical networking scheme, and has made the specification expensive and proprietary. And so in 2014, I look at NMEA2000 and see how atypical and archaic it looks. Binary packets instead of HTTP?  Proprietary physical layers that don't lead to a nice plug and play? And bandwidth handicapped! This is not the direction the rest of the Web-enabled  world is moving. Imagine having google earth directly overlayed on to your charts, integrated web tracking of your AIS information as standard on your chartplotter; just to mention of few.

NMEA 2000 operates at 250 kbits/second, very slow compared to Ethernet. Because of this bandwidth limitation, sonar and radar overlays can't be sent over the NMEA 2000 networks, that is why all the major manufacturers have their own proprietary networks for sonar and radar integration with their large display devices. But, NMEA2000 has a few advantages over Ethernet, cost, a collision-less system, time sensitive point to point delivery to name a few. It was developed to function in electrically noisy environments and to have a predictable delivery time for messages. Ethernet does not always provide a real time predictable delivery time or quality of service capabilities.

goal for OneNet is to "Transport NMEA 2000 network messages on Ethernet in a standardized manner" or as the release's subtitle says "Think of it as NMEA 2000 on steroids." That's because OneNet will break out of N2K's speed and node limitations big time, like increasing the maximum number of devices from 50 to over 65,000! (Now, that would be quite a vessel.) - See more at: http://www.panbo.com/archives/2012/08/onenet_nmea_finally_creates_a_marine_ethernet_standard.html#sthash.chOhWjdS.dpuf

Now, I'm not going to comment much about OneNET (as it still hasn't been released in it's final form), but it's stated goal is to transport NMEA2000 packet data on Ethernet in a standardized form. Think of it as NMEA2000 on steroids. This will break out nmea2000 speed limit and node limitations by a huge amount. The number of devices would increase from 50 to over 65,000! I don't see OneNET replaceing NMEA2000 or NMEA 0183 in the near future, but I am left wondering why NMEA has made this protocol so late, with an internet PC centric world everywhere. Also, I suspect, at least initially, it won't play nice with with existing ethernet devices, and I'm pretty sure it won't carry both NMEA2000 packets as well as NMEA0183 data sentences at the same time. You will need to use another gateway for that. However, once they convert NMEA to Ethernet the possibly of connecting to the outside world is endless.

What all this boils down to is that we boaters have three main ways of creating a network, each of which complements the strengths and weaknesses of the others: NMEA 0183 is perfect for very simple systems—it’s tried, tested, and virtually universal. NMEA 2000 is for most current multisensor/multidisplay systems, and Ethernet is suited to handle large volumes of complex data. Your best to consult your marine electronics expert to see what best suits your application. For me, I'm still running mostly NMEA0183, and with that, I have a number of back up solutions which give me confidence that when the lights go out on my main network, I can use the backup to get home safely. By that time, OneNet may be well established, and it could be a good time to upgrade. I'll just have to do my homework on the best system at the time, which is what we all do mostly.

A Comparison of the main types of networks/standards

OneNet will not replace NMEA 2000 or NMEA 0183 within the foreseeable future. Each will have its place on a boat - See more at: http://www.panbo.com/archives/2012/08/onenet_nmea_finally_creates_a_marine_ethernet_standard.html#sthash.chOhWjdS.dpuf

goal for OneNet is to "Transport NMEA 2000 network messages on Ethernet in a standardized manner" or as the release's subtitle says "Think of it as NMEA 2000 on steroids." That's because OneNet will break out of N2K's speed and node limitations big time, like increasing the maximum number of devices from 50 to over 65,000! (Now, that would be quite a vessel.) - See more at: http://www.panbo.com/archives/2012/08/onenet_nmea_finally_creates_a_marine_ethernet_standard.html#sthash.chOhWjdS.dpuf

goal for OneNet is to "Transport NMEA 2000 network messages on Ethernet in a standardized manner" or as the release's subtitle says "Think of it as NMEA 2000 on steroids." That's because OneNet will break out of N2K's speed and node limitations big time, like increasing the maximum number of devices from 50 to over 65,000! (Now, that would be quite a vessel.) - See more at: http://www.panbo.com/archives/2012/08/onenet_nmea_finally_creates_a_marine_ethernet_standard.html#sthash.chOhWjdS.dpuf