Back in this article on NMEA 2000
I talked about Instances in N2K. That led to a debate with Panbo's Ben Ellison about my understanding of N2K Instances, and we never really resolved it. More recently, like yesterday, the topic came up again on Panbo in this discussion about Simrad MARPA performance
, a topic that I originally published here
. Ben commented that I had never corrected my N2K article, so I went back and re-read it to see what I had wrong.
I can see how the article could have been better written (that's usually the case with my prose), but I couldn't find anything that was incorrect.
Then, also spurred out of the debate on Panbo about Simrad MARPA, Kees Verruijt posted a comment on my blog saying that he also thought I misunderstood Instancing. Kees is the guy behind CANboat which is an open source N2K decoder, so definitely worth listening to carefully on the topic. His comments cause the light bulb to finally go on in my head.
It turns out we were talking about two different things. NMEA 2000 includes two types of Instancing; Device Instancing and Data Instancing. They are similar, yet different. I had been talking about Device Instancing and Kees was talking about Data Instancing.
With this new illumination, I have placed a note in my original article making it clear that I was talking about Device Instancing. Now, the purpose of this article is to explain the difference between the two, along with where and how each is used.
So what is the difference between a Device Instance and a Data Instance, where is each used and for what purpose, and why should I even care? Well, read on....
First, some reference material is worth noting. As I have mentioned in the past, the N2K spec is secret, only accessible to those who buy it, and when you buy it, you also agree to maintain it's secrecy. I have never seen or read the spec, so am left to observation, reverse engineering, publications that are
publicly accessible, and discussion that I have had with a variety of NMEA committee members, including some vendors. As a result I can't guarantee the accuracy of this, but I have made every effort to use credible published information, and concrete observations of actual N2K data traffic to piece together my view of how all this works. I welcome corrections and additions - that's how I got as this far in the first place.
Here are a couple of very useful publications that have been a great source of info for me.
NMEA 2000 Past, Present, and Future, by Steve Spitzer, Lee Luft, and David Morschhauser
NMEA 2000 PGN Field List, published by NMEA
In some PGNs there is a field know as a Data Instance that is used to distinguish similar data coming from different sensors. This is typically used when one N2K device can have multiple sensors connected to it, but it can also be used to differentiate similar data sent from different N2K devices. It is important to note that a Data Instance number is always carried in the same PGN as the data itself. As a result, the data is self-describing.
Here are two examples of its use:
1) This first example illustrates how a data instance can be used to distinguish data coming from multiple sensors connected to the same N2K device. Maretron's TMP100 temperature device can sense and send data for 6 sensors. It does so using PGN 130312, Temperature. The data fields in this PGN are
- Temperature Instance
- Temperature Source
- Actual Temperature
- Set Temperature
Each time the device sends this PGN, it comes from the same device (mode address) and includes the Instance Number for the particular sensor. With 6 sensors active, it will send 6 PGNs, one for each sensor. These Data Instance numbers are manually assigned when the device is first installed, and must be unique for each sensor. For a device listening to these PGNs and displaying a particular temperature, it needs to be programmed with the correct instance number so it knows which PGN to display and which to ignore.
Note that if there is only one device on the network sending these PGNs, a listening device can ignore which device address the data is coming from and only pay attention to the Data Instance inside the PGN when deciding whether to display the data or not. That brings us to the next example.
2) This example shows how a Data Instance can be used to distinguish data from two different devices. A rudder indicator is typically mechanically connected to a single rudder, so can only report the data for that rudder. It would do so with PGN 127245, Rudder. This PGN has the following fields:
- Rudder Instance
- Direction order
- Reserved bits
- Angle order
- Position- Reserved bits
If you have two rudder sensors, either redundantly connected to the same rudder, or connected to a second independent rudder, each device would need to be configured with a different Rudder Instance. A device listening to this PGN would be programmed with the desired Rudder Instance so it knows which PGNs to listen to, and which to ignore. The device displaying data can ignore which device address the PGN is coming from, and discriminate solely based on the Rudder Instance number contained in each PGN.
Additionally, looking back at example #1, even if there are multiple temperature devices on the network, each
sending the temperature PGN for multiple connected sensors, as long as all the sensor Data Instances are unique, a
listener can continue to ignore which device address the PGN came from and display
data solely based on the Data Instance inside the PGN.
So you can see how Data Instances can be used to distinguish similar data
coming from different sensors, regardless of whether it is coming from
the same or different devices. You can also see how the Data Instance must be programmable in both the transmitting device and the listening device so the correct data can be picked out and displayed.
The big restriction with Data Instances is that not all PGN types support it. Many PGNs can only represent data from a single sensor sent from a single N2K device.
Examples of PGNs with no Data Instance are:
PGN 127250, Vessel Heading
PGN 127251, Rate of Turn
PGN 128259, Speed, Water Referenced
PGN 128267, Water Depth
PGN 129025, Position, Rapid Update
PGN 129026, COG, SOG, Rapid Update
PGN 129283, Cross Track Error
PGN 129284, Navigation Data
PGN 129285, Navigation Route/AP Data
PGN 130306, Wind Data
The full family of AIS and DSC PGNs
As a result, most of the primary navigation data represented in these PGNs and coming from multiple devices has to be distinguished in some other way. The solution to this in N2K is to distinguish this data based on the identity of the device sending the data, and that leads us to the Device NAME and the Device Instance.
Device NAME and Device Instance Number:
A device's NAME uniquely identifies it on the bus. So anybody who wants to pick out data from a particular device can do so based on the device's NAME.
Here's a quick quote from one of the above publications:
"NAME is the contents of the data field of the Address Claim message and must be unique for every device on the network. It consists of sub-fields containing codes for device function, instance numbers for multiple devices of the same type, manufacturer code, and a unique number assigned by the manufacturer. The latter, like a serial number, must be unique for every device of the same type produced by a manufacturer. During the address claim process, claims on the same address are won by the device whose name has priority."
The Device Instance is a number that is part of the device's NAME. Here is the whole makeup of the NAME field:
- Self configurable: Always "1"
- Industry Group: Always "4" for Marine Industry
- System Instance: Used with multiple bridged networks
- Device Class: Code for different classes of devices
- Reserved: Always "0"
- Device Function: Code for different device functions
- Device Instance: Here it is. It's the combination of an upper and lower part, default value zero.
- Manufacturer Code: Number identifying the manufacturer.
- Unique Number: Always unique for any combination of Manufacturer, Device Class, and Device Function.
Continuing on, you can see that for certain key navigation devices (Position Sensors, Heading sensors, Depth sensors, Autopilot controls), the only way to select which sensor you want a chart plotter to us is to tell it which device on the network it should listen to. And we know that the device's NAME is what uniquely identifies each device. Now all we need is a way to tell the plotter which device NAME to listen to for each type of data (position, heading, depth), but that's easier said than done.
Unlike a Data Instance that is contained in every PGN making the PGNs themselves self-describing, the NAME field is only returned in the ISO Address Claim PGN 060928, and that is only sent when the network goes through its self-configuration process or when specifically requested. In practice, it only gets sent when the network powers up or when there is a configuration change like the addition or removal of a device.
All the PGNs that we need to filter/distinguish only contain the node address of the device that sent it, plus of course the data. So we need a way to correlate device NAMEs with node addresses. Knowing that, a receiving device can use or reject data based on the "sent from" node address in the PGN. With a little translation from node address to NAME, the PGNs once again become self-describing.
Creating the correlation between NAME and node address requires a little work. The device NAME only appears when the network reconfigures, so you have to pay attention, catch them all, and remember which node address corresponds to which NAME. Essentially you need to create a map of the network. Once you do that, the listener knows which node address to listen to if it wants data from a particular NAME device. It's a little convoluted, but it works.
How this device selection (source selection) gets presented to an operator varies from manufacturer to manufacturer. Here are some examples that I have encountered:
1) Some listening devices do not provide any user control over which device they listen to. Instead, the device decides on its own which device to select as a source. N2K has the notion of priority of devices, and once the address claim process is complete, higher priority devices have lower node addresses. Much of the time this works, but I have seen cases where what I would consider to be a lower priority device like a standard GPS took on a lower address number than a higher priority device like a Sat Compass/GPS. So if you have a device that depends on this approach, it's worth carefully checking your device addresses to be sure you will get the expected behavior.
All of the N2K to 0183 convert devices that I have seen do device selection on their own with no provision for configuration. This includes the Simrad AT10 and AT10HD, Furuno IF-NMEA2K2 and IF-NMEASC, the Actisense converters, and the AMEC NK80. Actisense says explicitly that they select the lowest address device, so at least you know how it will behave. The Simrad and Furuno devices do not say how they perform device selection.
The AMEC NK80 is totally whacko and does not select any one device, but rather translates all relevant PGNs from all devices. So if you have two GPSs on N2K, you will get GPS info alternately from each GPS on the 0183 side. That's very, very bad, so don't use that device if you have multiple N2K data sources.
2) Furuno presents the text device name which comes from PGN 126996, Product Information, followed by a number which I believe is the unique number from the NAME field. But I have not verified that. What I do know is that they show multiple devices in a unique way so you can pick which one you want to use. And because they use the text device name e.g. HS70, or GP330, or DT200, it's pretty easy to figure out which you want to use.
3) Simrad also uses the text device name from the Product Info PGN, but when the Device Instance Number isn't zero they append the number to the name. So an NSO that is Device Instance zero will be displayed as "NSO", and one with Device Instance 2 will display as "NSO-2". It is not consistently done, but I have seen cases where Simrad automatically assigns Device Instance Numbers to like devices so they are easily distinguished. I made a habit of always assigning unique Device Instance numbers when I had more than one of any given device. So my multiple follow up levers were FU80-1, FU80-2, etc. The NSO and NSS products have a page where you can change the Device Instance number on any device. Lots of other vendors have the same capability, and they use some standard configuration PGN to make the change, but I don't know the details.
4) Maretron, takes a different approach. When you select a data source for display, you aren't presented with a list of named devices. Instead you are asked for an Instance number. One thing that is confusing is that they don't say which Instance Number they want (Data or Device), and sometimes they use one and other times they use the other. For data that comes in a PGN with a self-contained Data Instance like Temperature PGN 130312, they want the Data Instance of the particular sensor. For data that comes in a PGN that does not contain a Data Instance like Vessel Heading PGN 127250, they want the Device Instance.
So a Device Instance is a number that can be used to help distinguish one device
from another on an N2K bus. I'd like to emphasize that it can
be used, but it is not the only way to distinguish devices, and in fact
it's not the preferred way, and can be quite flawed if not used
Assuming you use their N2KAnalyze tool for configuration, they have some features than make this a bit easier in some cases. For example, you can add a text label to each temperature sensor. Then, on N2KView when you look at the drop-down to select the instance number, it shows the label next to the Data Instance number. That helps guide you. But not all devices support labels, so when I want to pick the Device Instance number to select which depth sensor I want to display, I am just presented with a list 253 number to pick from. I have a book with all my boat's info, and among other things I keep track of all my N2K devices and their Device Instance Numbers, plus all the Data Instance numbers where that's applicable. But to make a configuration change to N2KView, I need to dig out the book and look up the Device Instance number.
As you can see, the ONLY way to select a data source with Maretron is via the applicable Data Instance or Device Instance. You can't click on "HS70" or "GP330" to choose your position sensor. Instead, you need to assign each a unique Device Instance Number, keep track of that assignment, and use that number to select your position sensor.
Referring back to this article
, my complaint was that the infrastructure to select devices based on Device Instances is incompletely implemented and enforced. The N2K standard requires that Device Instance Numbers be programmable. It doesn't say how, but there needs to be a way. Maretron depends on this mandatory feature for their device selection, which although I don't like the approach, is still a valid design. However, vendors frequently do not provide a way to program the Device Instance, even though it's required. And when asked, they don't understand why anyone would care because in their view you should be doing device selection based on the device NAME, not the Device Instance number. In fact, NMEA says that any network should work with all Device Instances set to zero. And, the NMEA 2000 Certification process does not test for the ability to configure the Device Instance, so products become fully certified whether they implement it or not. To me, this problem reflects an unclear standard and inadequate certification process, so shame falls squarely on the NMEA 2000 Standards Committee. But that's the subject of the other article, not this one.
Hopefully I have cleared up the ever-so-confusing topic of "Instancing" in N2K.