NMEA Failover Data Sources

[twistedtree]

Originally Posted by colemj

Well, I haven't tried it yet, but from the manual:



NMEA2000 Data Configuration

This page configures the information that the MFD will output on its own NMEA2000 port. The information embedded in the PGN will be the information coming from the Sensor that will be chosen as the Primary Source (see next paragraph). Enable each NMEA2000 Data PGN that will be sent through the individual MFD’s NMEA2000 port.



Since there is only a single N2K port on the MFD, I assume that this output is back onto the same network it came from.



I do know that at one time I had the GPS output box checked on the Furuno by mistake and the autopilot saw the Furuno as a source in the GPS setup page along with the Maretron GPS.



Mark

I don't think thats what that feature does. As I understand it, it's meant to to get data from the N2K bus on one MFD over to the N2K bus on a second MFD where the MFDs are interconnected by ethernet. The N2K buses on each MFD are isolated segments, and that feature allows bridging of data between segments. I don't think it repeats data on the segment where it initially appeared. As mentioned, that would lead to all sorts of problems.

[twistedtree]

We can talk forever about what N2K should be, but have to deal with what it is because that's what we have, for better or worse.

I think what you need to do is go through each device that is receiving Gps data and see how it handles failover. Then proceed accordingly. Some devices pick the first instance they encounter, and go looking for another one if the first goes away. Others can be given some sort of a priority pick list. Simrad has an approach which, though proprietary, comes in handy. They have the concept of a simrad group, and when you change the Gps source for the group, all members of that group automatically follow.

All this is one reason to limit the number of vendors' N2K equipment that you use. Each handles management differently, so the fewer vendors, the fewer management methods you need to deal with. It's a very imperfect solution, but still beats the hell out of 0183, and is the best we have until an alternative emerges, which will happen very, very slowly.

In your (dockhead) situation, you might almost be better off setting up each half of your network to only use the GPS on that segment and forget about failover unless something actually fails.

[DotDun]

Originally Posted by goboatingnow

Well theres no real capabilities discovery system as standard in NMEA. There is the NAME process. ( which is a bit of a mis -mash). Sorry I should say that there is a Class and function ID system, but that is a very general form of ID. There is nothing that actually lets a 2K device really discover whats out there , It can say "hey Ive found a device thats says its an AP", but in reality it knows nothing about that device.

To my knowledge no system on a NMEA2k network should use the actual source address as an "instance" identifier. If Furuno does, its doing it wrong ( and that wouldn't be the first time they broke 2k rules!!). In a small network address rarely change, but In fact address resolution can occur at many time, including adding and subtracting devices, power up and by devices forcing an address resolution ( name clash etc). The network cannot assume any correlation between a physical device and its address. In reality there are serious shortcomings in some software implementations , where assumptions are made and address are stored. This often leads to aberrant behaviour that is sometimes seen on NMEA 2K networks, especially larger heterogeneous ones.

The correct way is to use the user programmed "instance" number, which is a bit field in the NAME field. This of course requires you to have the requisite setup tools. The instance ID does not change on address resolution, instance #1 remains instance #1.

I can't comment on Furunos discovery capability,( especially in a large heterogeneous network) but expecting all receivers on a NMEA 2k network to have the horsepower and software depth of a serious high end ( Well, OK, it runs Windows XP - LOL ) system like NN3D is not practical.

I susoect Furuno uses instance numbers, anything else is not reliable in that it cannot indicate a particular physical device.
dave

Not at the boat right now......pgn 126208 ?????? (from (a bad) memory )

[colemj]

Originally Posted by twistedtree

I don't think thats what that feature does. As I understand it, it's meant to to get data from the N2K bus on one MFD over to the N2K bus on a second MFD where the MFDs are interconnected by ethernet. The N2K buses on each MFD are isolated segments, and that feature allows bridging of data between segments. I don't think it repeats data on the segment where it initially appeared. As mentioned, that would lead to all sorts of problems.

So if one sat up a N2K network with the Furuno and all sensors/transducers on it, and another with just other instruments on it, and connected the Furuno output to the other network, will the other instruments then get all their sensor/transducer data only from the Furuno and failover when it does?

Mark

[DotDun]

Originally Posted by colemj

So if one sat up a N2K network with the Furuno and all sensors/transducers on it, and another with just other instruments on it, and connected the Furuno output to the other network, will the other instruments then get all their sensor/transducer data only from the Furuno and failover when it does?

Mark

I haven't played with Furuno in such a situation enough to be 100% sure.

In the UI for each interface, you tell Furuno what to transmit on that interface. One has to assume the data it transmits is from the same source the Furuno is using internally.

Given that, I'll retract what I stated yesterday that Furuno won't transmit data to the same network it came from. The reason I stated that is simply because it's good network design to not transmit data onto the same network it came from. But, I haven't tested this exact scenario, so YMMV.

When one has multiple NN3Ds, Furuno is emphatic about not connecting multiple NN3Ds to the same N2K network. I believe the reason for this is due to the fact they repeat any/all sensor data onto their Ethernet for sharing amongst Furuno devices. Hence, a neighboring MFD could take data from the Ethernet and repeat it back onto the same N2K network as the source data, which would then be picked up by the original MFD and put right back on the Ethernet. This would be akin to a bridging loop and saturate/kill the N2K with duplicate data.

What you are proposing, having the Furuno be the redundant controller for a N2K, is interesting and could certainly be the case for disparate N2K networks with multiple Furuno MFDs.

[goboatingnow]

Given that, I'll retract what I stated yesterday that Furuno won't transmit data to the same network it came from. The reason I stated that is simply because it's good network design to not transmit data onto the same network it came from. But, I haven't tested this exact scenario, so YMMV.

I cannot believe that Furuno rebroadcasts information back onto the NMEA2k bus that it comes from, The potential for FUBAR is mind boggling.

Not withstanding that rebroadcast the NAME field would create two identical NAME IDs but with different addresses, that in itself breaks NMEA2K protocols

dave

[goboatingnow]

Originally Posted by DotDun

Not at the boat right now......pgn 126208 ?????? (from (a bad) memory )

huh read/write function code !!!

dave

[colemj]

Originally Posted by goboatingnow

I cannot believe that Furuno rebroadcasts information back onto the NMEA2k bus that it comes from, The potential for FUBAR is mind boggling.

Not withstanding that rebroadcast the NAME field would create two identical NAME IDs but with different addresses, that in itself breaks NMEA2K protocols

dave

I don't know how/if it does rebroadcast, but it clearly has a setup menu with checkboxes where you can choose all the data sources you want it to output onto the N2K network, and the manual has the somewhat cryptic statement I posted earlier (and that is all it has to say about that).

And there is only a single N2K connector on the back of the unit…

Mark

[goboatingnow]

Originally Posted by colemj

I don't know how/if it does rebroadcast, but it clearly has a setup menu with checkboxes where you can choose all the data sources you want it to output onto the N2K network, and the manual has the somewhat cryptic statement I posted earlier (and that is all it has to say about that).

And there is only a single N2K connector on the back of the unit…

Mark

I suspect that this is like all others suppliers features, it allows the Furuno to broadcast out data received via other methods ( like Ethernet, 0183) etc ou rover the NMEA2k, Raymarine and Simrad have similar functionality ( as does garmin), it allows them to support a continuos NMEA 2K network, that is actually 2 networks physically but connected by say Ethernet from MFD to MFD


dave

[colemj]

You may be correct, and the manual is very sparse on this topic, but the sources I remember being allowed to check on that setup page were only the N2K data sources I actually have.

If I remember this correctly - right now the unit is disconnected and buried in the boat and unaccessible for a while.

Mark

[colemj]

OK, this thing was driving me nuts not knowing/remembering, so I dug the electronics out of hiding, dusted all the fiberglass off of them and reinstalled them.

On the Furuno setup page I set all of the data sources to be repeated by the Furuno on the N2K network. After doing so, the Furuno showed up on the Tritons and Simrad AP controller as a data source option for all the sensors/transducers along side the actual sensors/transducers.

BTW, the sensor/transducer sources from the Furuno have different names than the original sources.

The Furuno does not show as a data source on other instruments when I do not check the output boxes for the sources on the Furuno setup page.

When I choose the Furuno as the data source for all sensors/transducers on all other instruments, all the instruments work fine. When I turn off the Furuno, all the instruments lose their data sources (and do not revert back to the original sources on the network).

I don't have any redundant N2K sensors or transducers that I can test whether the Furuno fail-over will propagate to the other instruments. I have redundant 0183 stuff connected to the Furuno, but that isn't the same test.

I am not arguing how N2K works or Furuno's implementation of it because much of it is beyond me. I am only presenting some empirical experiment data.

Mark

[DotDun]

Originally Posted by colemj

OK, this thing was driving me nuts not knowing/remembering, so I dug the electronics out of hiding, dusted all the fiberglass off of them and reinstalled them.

On the Furuno setup page I set all of the data sources to be repeated by the Furuno on the N2K network. After doing so, the Furuno showed up on the Tritons and Simrad AP controller as a data source option for all the sensors/transducers along side the actual sensors/transducers.

BTW, the sensor/transducer sources from the Furuno have different names than the original sources.

The Furuno does not show as a data source on other instruments when I do not check the output boxes for the sources on the Furuno setup page.

When I choose the Furuno as the data source for all sensors/transducers on all other instruments, all the instruments work fine. When I turn off the Furuno, all the instruments lose their data sources (and do not revert back to the original sources on the network).

I don't have any redundant N2K sensors or transducers that I can test whether the Furuno fail-over will propagate to the other instruments. I have redundant 0183 stuff connected to the Furuno, but that isn't the same test.

I am not arguing how N2K works or Furuno's implementation of it because much of it is beyond me. I am only presenting some empirical experiment data.

Mark

Thanks for testing, now I don't have to!

I would guess Furuno rebroadcasts the data as Furuno being the source vs. just repeating the original pgn. That would solve Dave's objection.

[colemj]

If you have redundant N2K data sources, then testing the ability for the Furuno to act as a fail-over controller for all instruments would be a good experiment.

Yes, it does appear that the PGN is changed in the sense that the name field is different. I forgot to look at the instances, but would assume the Furuno takes a different instance # also?

Mark

[goboatingnow]

I would guess Furuno rebroadcasts the data as Furuno being the source vs. just repeating the original pgn. That would solve Dave's objection.

Yes it would, but its seems like a lot of effort on Furunos part , for what specific gain!, hard to see the point

dave

[DotDun]

Originally Posted by goboatingnow

Yes it would, but its seems like a lot of effort on Furunos part , for what specific gain!, hard to see the point

dave

Furuno is offering the capability for their NN3D MFD to become a source of sensor data. This is especially attractive when the data a receiver requires is on a different network. Why is that hard to imagine?

One could have 0183 sensors, Furuno can be the gateway so your N2K only display. One could have multiple 0183 networks, Furuno can multiplex 0183 data onto a single 0183 network (the NN3D has (3) 0183 ports). Furuno can put N2K data onto a 0183 network.

Albeit, all within the realm of 0183 sentences/N2k pgns that are supported (most common ones are).

We've obviously discovered an additional feature, that being a failover controller for multiple N2K sensors on a single N2K network.

You see no value to these features?