N2K address assignment/claim?

[twistedtree]

Does anyone know how n2k device address (I think they call it a device I'd) works? In particular, is the assignment static for a given configuration? And could it be different if some devices are initially powered off, then come online later? I'm seeing some whacky behavior that I think might be related to device ids that jump around depending on what's powered on when.

[DotDun]

Theoretically, deviceID won't affect the data stream. If a device attempts to use an ID that is already used, it'll simply chose another.

[twistedtree]

Originally Posted by DotDun

Theoretically, deviceID won't affect the data stream. If a device attempts to use an ID that is already used, it'll simply chose another.

What I see is the Maretron display losing track of data, and devices disappearing from the. Network. The display will normally accept data from any valid device, but can be told to "prefer" data from a particular ID. That only works if the ID is static.

I actually have a few different problems, so let me focus on one of them. Among other things on the network, I have a Bennett trim tab sensor and Simrad autopilot computer (AC42). The TT device reports itself as a Lowrence device, not Bennett, and the device SN is garbled, so im immediately suspicious of its implementation quality. The TT indicator powers up when the bus is powered up and claims I'd 00. It also spawns off a second device that's I'd 00, instance 254. And has a different manufacturer name. I don't recall right now, but I think it's "Bennett". After a while this second device goes away. My guess is that it's some appendage hack that was added to make the TT manageable, but it's just a guess.

When the AP is powered on, it joins the network and also takes ID 00., then the TT move to ID 01. Is that expected behavior?

[DotDun]

Let me start by stating that I don't know the NMEA 2k spec, it's not available for the free, hence it keeps the 'commoner' in the dark as to it's nuances. But I do have vast experience with network protocols and dynamic addressing of devices.

Once a device boots up and goes thru the address claim process, any device afterwards that attempts to use the same address will chose another one. Basically, a device broadcasts on the network, 'I'm going to use address 01'. If no other device complains, the first one uses '01', if someone complains the device will chose another address, broadcast it's intention to use it and wait to see if another complains about it.

It sounds from your description the trim tab device is not following the 'rules'. Instead of telling the AP that address '01' is in use, the trim tab device changes his address. And, yes, this will drive devices like the Maretron display crazy as it's expecting devices to maintain their address during the whole session.

I would disconnect the trim tab device and see if the network behaves properly. If yes, contact the trim tab manufacturer and ask them to fix their device (or refund your money).

Is the trim tab device N2k certified?

[twistedtree]

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.