Most marine electronics that communicate with each other do so these days using a standard called NMEA 0183, defined by the
National Marine Electronics Association (NMEA), a trade organization of companies working with marine electronics production, service, and sales. Their online magazine
Marine Electronics Journal is an excellent source of latest developments in marine electronics, with in-depth articles on all public matters of the NMEA standards. "NMEA" is, for some unknown historic reason, usually pronounced "nee ma."
The NMEA 0183 standard has been in use for over 30 years. It transmits data between instruments in plain language text
sentences, via a one-to-one serial connection between them. In this system, one talker (the instrument sending the data) can have multiple listeners (instruments receiving the data), but each must have its own wire (or wireless) connection to the talker. When the talker talks, the listeners must listen, so this is a bit like talking on a simplex radio connection. While you are talking on VHF channel 9, for example, several folks could tune into channel 9 and hear you—but that is the end of the analogy. When you stop talking, they cannot talk back to you; they are listeners.
A typical GPS unit, for example, sends out several NMEA 0183 sentences once per second or so, one of which is called "GGA," the abbreviation for GPS Fix Data. Every NMEA sentence has a three-letter description or abbreviation that is usually used in discussing them. A typical GGA sentence looks like this:
$GPGGA,223448.00,4740.4726,N,12223.9026,W,1,08,1.0,39.9,M,-17.3,M,,0000*6A
The NMEA sentence is everything between the $ sign and the *, which are the beginning and end markers for the sentence. Characters following the * are a
checksum used to confirm a proper sentence was received. There are always 5 characters after the $ that identify the source (talker) and the type of data, which is conveyed by the sentence. The first two (GP in this example) identify the talker instrument as a GPS unit. These
talker identification prefixes are specified by NMEA, but they are usually not crucial and not always used consistently—the exceptions are sentences that begin with a P, meaning they are unique (proprietary) to a specific instrument manufacturer.
The GGA in this case is the sentence abbreviation or nickname. There are over a hundred of these defined by NMEA, meaning the data following the comma must be in a specific format and order. Each data element is separated by a comma, with no spaces. If part of the specified data are missing, a null placeholder (,,) must still be in right place. An example is the next to the last data entry in the GGA sentence above, meaning in this case of GGA that the data are not a differential GPS signal.
There are also dozens of these sentences that were at one time defined and recommended by NMEA but are now called
deprecated, meaning
no longer recommended for new instrumentation—although a few are still required in specific navigation software. MDA (meteorological composite), for example, is required if we wish to display barometric pressure in the Plots plugin of OpenCPN—at least at the time of this writing. The dedicated barometer sentence MMB is also deprecated with suggested replacement of XDR, a generic sensor output sentence.
The required data format in a 0183 sentence is sometimes logical and other times not. In the GGA sentence above, 223448.00 is a time, 22h 34m, 48.00s, which is sort of logical, but the position reported (4740.4726,N,12223.9026,W) is an unusual way to specify 47º 40.4726' N, 122º 23.9026' W, although it must make sense from some digital perspective.
Documentation of the standard, meaning what sentences exist and how they are formatted, is proprietary to NMEA, which they offer in an expensive document, several thousand dollars, depending on the category of the buyer. It is in fact a closely guarded document. Their
website warns that anyone who talks about this standard is probably wrong and likely infringing their copyright! An unofficial description of just the sentences can be found online under the name "
NMEA revealed." It is a long standing work of Eric Raymond that thousands of navigators have benefited from over the years—keeping in mind the NMEA warning mentioned above.
NMEA 2000, nicknamed N2k, is the modern upgrade to NMEA 0183. It most likely started in the year 2000!, but seems to have been slow getting underway. I see increased articles and discussion on line about it starting around 2009 or so. There are numerous reasons that 0183 needed to be updated, largely traceable to the very many more sensors we now find on typical vessels, with associated requirements for higher transmission speeds. The slow, one-to-one wiring of the 0183 showed its limits very quickly in this evolution. A need for improvements in data definitions and combinations were also on a steady increase as our instrumentation became more sophisticated.
While this need for improvement was increasing in the marine industry, a similar need in the automotive industry had been largely solved. The electronic circuits in a typical modern car include 50 or more
Electronic Control Units (ECU), each of which is made up one or more microprocessors that monitor and control various subsystems on the car.
It is crucial for safe, efficient operation that these controllers can communicate back and forth amongst themselves quickly and dependably. The networking standard that was developed to meet these needs is called the
Controller Area Network (CAN). It is based on a single cable bus that all the ECU tap into called the
CAN bus.
Sample of a car mechanic's diagnostic tool tapped into the car's network viewing the status of various components. Similar tools are now available to marine electronics engineers for testing vessel's N2k networks.
The automotive CAN bus system is the protocol or standard that N2k was adapted from. It is also used to manage systems of medical instruments, as well as, for example, the many interacting systems of large complex buildings. In the marine application, the CAN bus is called the
backbone, and the controllers or nodes along the bus are the instruments or sensors in use.
A schematic showing how the two systems might link several instruments to a computer to display or use the data. The gateway translates the N2k signals to 0183 used by many nav programs.
The N2k backbone is a 5-pin cable that wanders through the vessel providing a single path for all electronics to tap into. We can get data from GPS units, heading sensors, knotmeters, heel and pitch, radar CPA data, wind instruments, various temperature sensors, barometer and humidity sensors, soundings, house and navigation lights, multimedia equipment, engine, battery, and refrigeration monitors, and more. It is not intended for high bandwidth nodes such as video or live radar, but these inputs are commonly combined with N2k networks.
These data in turn are shared with various multifunction displays (MFD), chart plotters, and switch controllers, along the backbone, and somewhere along the line we have to tap in 12V to power the devices (some devices may still need an independent power source). The power tap can be at one end of the bus, or a special
N2k power tee that can send power both directions in the backbone. A 3A inline fuse is typical. The N2k standard is 12V only, with no 24V alternative—although in principle an all-24V system can be used.
Also, somewhere we need to tap in with a
gateway device that lets us read and connect to any or all of the outputs in a computer or mobile device. Conveniently, it does not matter where the various components tap into the backbone. The gateway devices can also be the place where 0183 instruments are added to the network via 0183 to N2k converters, or this can be done with a separate device on its own node. Gateways are discussed further below.
NMEA 0183 standard network speed is 4800 baud (4.8 kbps), corresponding to about 10 messages per second, with high-speed options, such as 9600 baud for NAVTEX, or 38400 for AIS. N2k speeds are nominally 250 kbps, which is about 50 times faster than 0183 networks. In N2k there are no designated talkers nor listeners; all devices (up to 50 nodes on a backbone) can send, and all can receive, although priorities among them can be set. Larger vessels or more complex networks might have more than one backbone in use.
A schematic N2k network. Terminator plugs (120 ohms) are required at each end of the back bone. There are male and female versions to accommodate each end. Not shown is one of the popular wireless gateways that transmits the data to tablets and phones on the vessel. The multiport connector indicated is called "N2k approved." I first saw it in an official NMEA video, but they now warm that care must be taken when using them, and they are not a "certified" device.
Many N2k suppliers have network installation guides that discuss the networks in general, plus crucial details such as how to compute maximum drop line lengths, power drops along a long backbone, and more—it has long been our advice with all electronics that we should read as many manuals as we can find, not just those for our own brand, because we usually learn something new from each one. Here are a couple samples of the generic network manuals:
Actisense,
Garmin,
Maretron.
There are many virtues of the N2k network, which we look at below, but one simple one is when we are confronted with three or four alarms going off at once, we can turn to one custom designed screen that will not only identify the alarms, but graphically show what parts of the vessel are involved. Sample screen displays are shown below.
Sample from a large power-driven vessel, but even smaller vessels, power and sail, can design a panel with all important gauges showing. Without knowing the details, crew standing watch can report if any lights go red.
Other navigation and performance displays can also be custom defined with some N2k instruments or software products. But that feature is not new. We can do customized performance display with many 0183 instruments; it is just that much more can be included in N2k, and at faster speeds, and indeed the wiring running through the boat is very much cleaner and much easier to assemble.
Here is the backbone on the J/105
Jaded. Thanks to skipper Chris Phoenix for inviting us onboard and taking the panel down to give us a look.
Far left is the power tee and far right is a Garmin GND 10 gateway that converts the N2k data to 0183 for display in the PC nav program Expedition. Other drop lines are MFD displays and wind instruments. The VHF-AIS is mounted on the panel in front.
Chris noted that last year he purchased a N2k heading sensor to be integrated into several devices just before departing on the delivery to the Swiftsure Race, 35 nmi to the north. On the trip north he read the instructions and installed it, then swung ship to calibrate it just before tying up at the dock, and has not had any issues with it since then. It would take an even braver person to make such a last minute underway installation of such a crucial instrument with conventional 0183 wiring.
Thanks, also, to another J/105 (
Jubilee) skipper Erik Kristen who shared his experiences with his N2k system and offered his system for several tests we did together on his boat and with his Actisense gateway in our office.
But despite all its advantages, it would be a long stretch to consider N2k as a step toward a "simpler" networking protocol compared to 0183. It is faster and more versatile, and indeed it is much simpler to plug in all the presumably compatible (certified) components, but it is not in any other sense simpler. Indeed, I would have to guess that this system has notably enhanced the role of trained electronics installers on setting up our electronics, especially if we need to include some 0183 components, which is often the case.
In the 0183 system it has always been easier to interface instruments if we used as many as possible instruments from the same manufacturer. Interfacing instruments from different companies has historically been difficult or impossible. This problem is very much reduced in N2k, which is
in principle plug and play amongst N2k devices from any company... but not quite.
We still have instruments from prominent marine electronic companies such as Raymarine SeaTalkNG, Simrad SimNet, FurunoCAN that are N2k systems, but they each use their own custom connectors and cables—although some now offer official N2k hardware, which follows the DeviceNet standard (Micro-C, M12, 5-pin screw connectors), an N2k standard also adapted from the auto industry. Furthermore, not all devices that use official N2k connectors meet the official N2k device standards.
NMEA warns us that devices advertised as N2k
compatible or
compliant or
approved are not the same as
N2k Certified, which is their proprietary terminology. Components may have the same connectors, but non-certified devices may not interoperate as intended. Think of how many software programs we use daily that start out at installation with a warning from Microsoft or Apple that they are not approved, so you are on your own. Many such apps work fine for what we need, but there could be limits we are not testing. There is a searchable list of certified devices at
nmea.org, or we can check with someone who is already using a device in question as we want to.
Note that a "NMEA 2000 approved"
device is not an official description implying a certified device, but a "NMEA 2000 approved"
cable or backbone component does mean it meets the N2k DeviceNet standard. So the terminology for devices and hardware is slightly different. For actual devices and instruments, look for the official logo on NMEA certified products to gain confidence with interconnecting different company's products.
A big difference between N2k and 0183 that perplexed me early on is the raw data stream in N2k cannot be read like we can read the text sentences in 0183. We have to have an interpreter. The device that typically includes this function is a N2k
gateway, mentioned above. They serve as a bridge between the N2k network and an external computer or other device. A gateway can do more than just display message content and transfer the data to a computer for navigation or analysis, they can also be used to configure various parameters such as frequency of measurements, as the signals move from backbone to computer. Some gateways can also be used to combine 0183 and N2k data as it enters the computer, along with other tasks. Some gateways are data loggers as well, which can in turn display graphs of various parameters.
The various N2k gateways available and what they do make up a subject of its own. Your gateway of choice will be a key component of your N2k system. There are several versions available from several companies, and you may need or benefit from more than one. They each have a hardware and software component. Generally they are designed around the devices of a specific company, but in turn they interact on some level with all signals on any backbone. They can offer USB or wireless export from the backbone, with wide-ranging functionality. Several examples are mentioned below.
Many mariners have gotten by for years without getting into the details of the NMEA 0183 sentence structure, but sometimes we cannot avoid it. In fact, with the transition into N2k we might have to learn more about 0183 sentences than we needed before we got involved with N2k. This can come about when setting up navigation software that reads various performance sensors, because the nav program needs to know where to look for specific data. Sometimes data such as, say, true heading or apparent wind data can be in two or more sentences, which can pose an issue if the software is setup to only read one of them. Or more subtle, some sophisticated wind instruments include GPS, heading sensor, and heel sensor, so they can output a sentence with true wind speed and direction, whereas the software might be intent on computing this themselves from apparent wind and some measure of vessel speed and direction. Some nav software has more control over what sentences are used or allowed to be used than others. In short, there is not a standard that covers how we should use the standards.
This issue has not totally gone away with N2k, but it is much reduced in the new system of data specification. N2k does not use 0183 text sentences, but instead uses hexadecimal data messages identified by their Parameter Group Number (PGN). Thus a
PGN in N2k corresponds to a
NMEA sentence in 0183. Below are some examples.
If we connect several 0183 devices to a computer, and then looked at the serial input with a terminal emulator such as
CoolTerm, we would see something like the following:
These are sentences from a GPS, a heading sensor, and a barometer. Most nav programs have a way to look at this type of raw input without the need of a separate terminal emulator, usually in the connections section of the setup screens. The terminal emulator remains valuable, however, if we, for example, do not see anything getting through to the program; also some programs let us block specific sentences, so knowing what we are sending to the program can be helpful. If these were 0183 devices, this data stream would look essentially like this for any device, and we could plug them into any computer. The structure is:
$ (to start), xx (to ID the talker), xxx (to ID the sentence type), x,x,x... (the data), * (to end), xx (checksum).
On the other hand, if the above devices were N2k we would not be able to directly see equivalent raw data streams in our navigation programs (such as Expedition, Time Zero, OpenCPN, etc). We would need a gateway, whose main job is to make the N2k data visible to programs expecting 0183 data. When we look at these same devices as N2k instruments we would see something like the following for the N2k data stream, depending on the gateway in use.
This is a section of an output screen from the Yacht Devices (YD) Can Log Viewer software (CanView) that reads its USB gateway (YDNU-02NM) from our test bench backbone. The red values are the ones that are changing.
Our simple test bench is shown below.
Key components of a PGN message reflected above are a System ID, followed by a data length code (DLC), followed by the data in coded hexadecimal. The SID encodes and relates the actual data type (PGN) along with other data needed (in other PGNs) to interpret the source and destination, including which data are valid at the same times, priority of devices when more than one has same data, and so on. It is common to have more than one GPS, for example, so one gets priority; also in a complex system that might have competition for bandwidth, a GPS signal will get priority over the temperature of your fridge. In short, there are numerous PGNs needed to interpret the data that are not just the PGNs with direct sensor outputs that have corresponding NMEA sentences.
Within the CanView software we can also look at other aspects of the network including a logging function to plot trends in any of the data.
Several displays from the YD CanView software listing components of the network and present values. Other displays list the NMEA sentences they have created, and more.
This gateway can also be used to set units on the output as well as apply offsets for calibration. The serial numbers and firmware versions of all components can also be accessed here; N2k products are all evolving, so convenient updates is an advantage.
Below is a sample display from the Actisense gateway viewed in their app called NMEA Reader.
This display shows the sentences they have created from the input PGNs along with an option to translate the NMEA 0183 sentence components.
Again, the big difference between viewing N2k raw data streams and the corresponding data stream from a native 0183 device is we cannot read the PGNs in plain language. Everything is encoded. We can't even easily see what the PGN values are themselves. There is an official
NMEA look up table that describes the PGNs very generally (and this
NMEA list that has a bit more detail), but the official N2k standard does not seem to prescribe directly how 0183 sentences are to be converted to PGNs, or vice versa. It appears this is decided by the gateway manufacturers. To see how this is being handled we have to look at the gateway output. As with 0183, the same data can appear in more than one PGN, but the trend is to reduce this variation, meaning multiple sentences that include a specific parameter get rendered into fewer PGNs.
Samples of N2k raw data streams are shown below.
Gateways often include the data conversion information in their manuals—the
Maretron manuals have especially good sections on this, with valuable annotations. A sample of how they describe the PGNs they use is below.
Other gateway documents and displays correlate the conversions being made, as shown in this sample from an
Actisense document:
The above list includes the statement "The NMEA conversions detailed in this list may change without prior notice as part of our ongoing product improvement process," which supports the idea that individual gateways decide how they are going to make the conversions, and that they can vary from one gateway to another.
A barometer pressure, for example, can be contained in two 0183 sentences, MDA or XDR. The former, named Meteorological Composite, is actually deprecated, but some popular programs still require it, such as OpenCPN. The latter is a generic Sensor Output, which is now the preferred choice. Coincidentally, there are also two PGNs that include atmospheric pressure, 130310 and 130311, both called Environmental Parameters, and we have just learned that there is a new recommendation, 130314, called Actual Pressure, although few devices actually read this PGN. In short, the N2k goal of simplifying the parameterization must be a still on going process.
In our tests, the N2k barometer shows up as both 0183 sentences in one gateway, but only as MDA in the other. These matters can be more challenging when working with wind data where we have to distinguish water-referenced wind and ground-referenced wind, with and without corrections for leeway and heel. In this regard, there seems to be enhanced performance of a gateway with its own N2k devices, compared to mixing device and gateway sources. Universality has definitely improved with N2k, but it is not 100 percent. We will have a follow up article on the excellent YD N2k barometer and the unique GPS plus heading sensor from Lowrance.
There is rarely any issue when using all the same manufacturer's sensors, feeding them into the manufacturer's own chart plotter or MFDs. The navigator's challenge comes about mostly when inputting data from diverse sources into a navigation program on a computer or tablet. Then we rely on a gateway for the translations.
A potential nuance is something like this: in 0183 sentences AAM and RMB there is a field for waypoint Name (in other places called waypoint ID). In the 0183 definitions these Names or IDs can be alphanumeric, such as "04-Jones-Pt." This is consistent with our long standing advice that waypoints should always have both a number
and a name. It saves a lot of potential troubles underway. The PGN 129284 is the one often associated with AAM and RMB, but N2k waypoints IDs can only be digital numbers, so using and maintaining real waypoint names could be an issue to keep an eye on.
We can correlate the 0183 sentences with N2k PGNs in many cases, but certainly not all. There are some 148 NMEA 0183 sentences with about 560 parameters defined, in contrast to some 163 N2k PGNs with some 1570 data fields defined, according to a post on an Actisense blog. Nevertheless, despite the expanded options for general communications, most navigation and environmental messages are getting more unified, which is probably for the best.
Again, it seems the key to interacting with a N2k network is the choice of gateways we make. Each of the popular ones we looked at offers a free copy of their software along with samples of data files that can simulate an actual connection to a backbone. Working with these programs and their test files seems a good way to find the best choice for the application at hand. Here are the three we looked at:
Actisense NMEAReader (PC)
Yacht Devices Can Log Viewer (CanView) (PC and Mac)
Maretron N2kAnalyzer (PC)
If it might help, NMEA 0183 sentences can be
decoded online, as well as 0183
AIS sentences.
Some aspects of N2k may not be of much interest to many sailboats, but typical medium to large power boats have more systems to monitor. The subjects of
switching systems and
engine monitoring are all covered well in N2k and can have a major impact on the navigation and functioning of the vessels. Engine monitoring is done on a
similar but different network called J1939, but devices are available to combine them.
• Lets any component communicate with the entire system. See all parts of the network on one screen and tap into any one for diagnosis or configuration.
• Relatively low cost, due to simplified wiring via one backbone. Plus wireless gateways can now replace expensive multifunction displays. (On the other hand, some components are notably more expensive than they might be due to high NMEA N2k licensing fees.)
• Simplified power distribution to most components, with the 12V lines within the backbone.
• Improved protection against individual failures, electromagnetic interference, or salt water damage.
• Technically superior network: faster, safer, and more efficient.
• Flexibility.
Add and remove components as needed, often with plug and play ease.
• With several gateway brands we can log data from any device (i.e., wind speed and direction) and then graph the results or export them as csv to be analyzed in another program. High-end nav programs and high-end sensors offer this feature in several cases on their own, but now it is more generally available to essentially any parameter. Plotted data are always a boon to good navigation.
N2k is much more powerful and versatile than 0183 and vessels will benefit greatly in convenience, efficiency, and indeed safety as a result. The question skippers might face when updating electronics is: Do I add N2k units to my 0183 system, or do I bite the bullet and replace all with a new N2k system? I have spoken with folks who have done both, and my small sample shows two categories: those who are glad they went to all N2k at once, and those who in retrospect wish they had.
Our workplaces on land are more networked and efficient now than they were 10 years ago, but many offices pay the price of needing new staff or consultants trained in what has come to be called "information technology." Well... we have to face it now that navigators are going to have to take on more of the role of an IT person, as well as the other duties in their lap, which include weather work, another area that is becoming more and more technical.
This trend is not going to diminish. The next generation of electronic charts, for example, which we have recently learned will replace
all paper charts within five years, are going to be massive
GIS products that include an
overlay of live weather data available with a click on the chart. Get out your pocket protectors and buckle up!
