Just thought I'd follow up on this. It turns out that N2K works a bit differently than the data networks that I'm familiar with.
First, network node addresses/IDs are not static. Not at all. When a new device comes onto the network, which can happen if it's plugged in or simply powered on, any and all address can change. In practice they don't change much, and I'm not sure exactly what the rules are for who claims what, but I have seen cases where one device powers up, takes an address already in use, and the device that was previously using the address goes and grabs a different one. Apparently this is completely legitimate.
What had me really confused was trying to understand how you select a preferred data source, say choosing which GPS
you prefer to use, when the device addresses are not static. This is where the Instance Number comes into play. N2K doesn't use source addresses to select a device, it uses Instance Number. If I am in any way an example, Instance Number is a poorly understood concept
, and a very likely cause of many, many seemingly obscure problems with N2K configurations. If everyone already understands it and it's just me who didn't, oh well, shame on me.
Here's how instance numbers work. So far, I have found nowhere where this is explained very well. An instance number is a user-assigned number, and is used to uniquely identify different instances of devices that produce the same data. The instance number is stored in non-volatile memory and is remembered by the device across power cycles, reconfigurations of the network, etc. Dual GPS
and dual heading sensors are good examples. In simple N2K configurations where there are no redundant devices this is a non-issue, but in any larger configuration where redundancy starts to come into play, this becomes critical.
Let's take an example of heading sensors, and let's assume the boat is equipped with an expensive and highly accurate satellite compass
, and a less accurate rate compass
. In this situation you would want all your other electronics
to use the more accurate heading source, unless of course it fails, in which case you want everything to automatically switch over and use the rate compass. Furthermore, you don't want you chart plotter and auto pilot to be randomly switching between sources or your chart orientation and steering
will be all over the place. You want to lock onto one source or the other, and only switch if there is a failure.
If you don't assign different instance numbers to each of these devices, chances are pretty good that your auto pilot and chart plotter will indeed be randomly switching between the two sources, causing all sorts of problem. This is because as the heading data in the form of a PGN message is received by the Auto pilot, it can't tell the difference between PGNs from each of the two devices. Sometimes it might pay attention to one, and sometimes the other. I mistakenly thought that the device's node ID was the way to distinguish. This is called source addressing in the network world, but it's not how N2K works. Instead, N2K looks at this other field in the PGN called Instance Number to distinguish between sources. And it's up to the installer/user to set these numbers up so nothing gets confused.
At a minimum, you need to figure out which devices can send the same data, and be sure each is given a unique instance number. Personally, I prefer a more robust approach, which is to assign a unique Instance Number to every device on the network. Then, when you want a device to give preference to one data source over the other, you just configure it to favor the Instance Number of the preferred device. If that Instance isn't available, most devices will then grab whatever else is out there.
It turns out this was the source of all my problems on the N2K network.