N2k to 0183 Not thought through worth a darn!

twistedtree said:

The tough part with all of them in interfacing them into a system that is otherwise N2K. The Class A devices are IMO compliant, so not dependent on N2K. In fact, only the AMEC even has N2K, and it is output only.

There is a whole other post that could be made about the issues of interfacing in a mixed N2K and 0183 environment.

Click to expand...

So basically the core problem was source selection and failover with N2k to 0183 converters which are required on IMO devices (IMO devices are 0183) as N2k i guess you could say isn't stable enough to be put in a real world commercial operation.

So lets do an example:

You have a Furuno FAR2117BB Radar that you want to add to your boat which totally N2k. You have to acquire converters that convert data to 0183 so the radar can digest the data. So that's where all the fun ends and the ripping out of hair begins. Say you have multiple heading sources on the N2k network and one is much more accurate then the other, for your radar you want it to have the best heading available but your N2k to 0183 converter doesn't allow you to pick which compass to use. Now that's stupid. This is basically a repeat problem as the Radar requires heading, Nav data, and AIS data which are all 0183.

And that's just half the problem.

That sums it up.

There isn't anything wrong with using 0183, particularly at high baud rates. Sure, its going to be mostly with older gear. But its relatively trouble free. And using an Actisense multiplexor you can set priority order for the input ports and thereby get your preferred GPS or heading sensor signals used first, then other ones if 1st pref falls over. I've got some N2K but would not try to use it for everything. What we need is the successor to N2K. I like that my radar is using ethernet, easy to feed to both flybridge and pilothouse via an ethernet switch.

Insequent said:

There isn't anything wrong with using 0183, particularly at high baud rates. Sure, its going to be mostly with older gear. But its relatively trouble free. And using an Actisense multiplexor you can set priority order for the input ports and thereby get your preferred GPS or heading sensor signals used first, then other ones if 1st pref falls over. I've got some N2K but would not try to use it for everything. What we need is the successor to N2K. I like that my radar is using ethernet, easy to feed to both flybridge and pilothouse via an ethernet switch.

Click to expand...

It's just personal preference, I try to minimizes the best to my ability adding 0183. N2k is the way of the future, but it isn't there yet.

On the topic of N2K and Ethernet, I don't think switching to ethernet will address any of the problems. The underlying choice of network fabric isn't the problem. The problem is the incomplete protocols and standards run over those fabrics. I don't think ethernet will make vendors more aware and thoughtful about supporting multiple, redundant devices.

On a brighter side, it's worth noting that there are pockets of vendors doing a really good job of this. Coastal Explorer lets you prioritize devices and it utilizes them in that order based on availability. And Simrad has a really nice, though proprietary feature called Groups where you tell devices what source group you want them to be part of. Then, if you change the preferred data source (say the selection of GPS) for one device in that group, all the devices in that group follow suit. So if I go to the NSO chart plotter and change heading sensors, the chart plotter, radar, AIS, and autopilot all change as well. It save having to go around to every device individually to make the change in the event of a failure. Standardizing something like that would be a big step forward for N2K.

But here we are back talking about N2K, not just converters. The challenge with converters, as Oliver so eloquently described, is that as soon as you convert to 0183 you lose the Device Instance number that identified the data source on N2K. And none of the converters let you select the Device Instance that you want converted. It's up to the converter to randomly pick or whatever, so you really have no idea which you get, including whether you are getting some blend of multiple devices.

And when you bring data onto the N2K bus via a converter, you are dependent on those converters properly implementing instancing so you can distinguish between them. So if I have two heading sensors on 0183 and bring them on to N2K each via it's own converter, I need to be able to set up those converters with unique instance numbers. My only hands on experience so far is with the AT10, and you can't change it's instance number. It's always zero. I'll let you know what I find with others.

Actually, Oliver, you are using a Furuno IF-NMEA2k2, right? Can you check to see if it accepts a change to its instance number?

twistedtree said:

.

Actually, Oliver, you are using a Furuno IF-NMEA2k2, right? Can you check to see if it accepts a change to its instance number?

Click to expand...

I will try to today.

Just tried on both Furuno and Maretron, you can't change the instance #.

Great, so there is another NMEA Certified device (I'm pretty sure) that blatently violates the spec. And no way to bring two redundant 0183 devices on the N2K network and select which one to use.

If I read the manual on my Actisense NDC-4 multiplexer correctly, it allows NMEA 0183 filtering and prioritization if used as an autoswitch so you could switch between GPS sources based on a priority order. I've not used that capability since the only NMEA 0183 I am using today is AIS from my Standard Horizon GX2150 to Coastal Explorer and to a Lowrance HDS-8 from the NDC-4. Everything else is N2K or Ethernet.

tpbrady said:

If I read the manual on my Actisense NDC-4 multiplexer correctly, it allows NMEA 0183 filtering and prioritization if used as an autoswitch so you could switch between GPS sources based on a priority order. I've not used that capability since the only NMEA 0183 I am using today is AIS from my Standard Horizon GX2150 to Coastal Explorer and to a Lowrance HDS-8 from the NDC-4. Everything else is N2K or Ethernet.

Click to expand...

We're not talking multiplexers, just N2k to 0183 converters.

If you then run the output of the mux to the N2K 0183 gateway then the GPS's are effectively filtered. It's two devices but effectively does what you want to do. It doesn't scale well to multiple sensors like both GPS and a heading as each sensor would seem to require its own set of equipment.

tpbrady said:

If you then run the output of the mux to the N2K 0183 gateway then the GPS's are effectively filtered. It's two devices but effectively does what you want to do. It doesn't scale well to multiple sensors like both GPS and a heading as each sensor would seem to require its own set of equipment.

Click to expand...

Yes, it can work. Lots of people just use selector switched to select between two redundant devices. But all this hollows out the value in N2K. Having both sensors operational on the network, and selectable by each listener, is really useful, provided it works. And when it does work, it's a thing of beauty.

Take the screen below. It's a status view of a number of redundant sets of sensors. They include GPS, Heading, Rudder Angle, and Depth. At a glance I can see if all the devices are working regardess of whether they are primary or backup. And I can compare the data from the sensor pairs to see if they are in agreement. In this case I can see that neither Rudder indicator is working. They are, but due to a squabble between Simrad and Maretron, the info doesn't display. Simrad insists their PGN is legally formatted, and Maretron insists it is not. To their credit, Simrad provided a workaround firmware update, but it broke their autopilot so I can't use it.

Moving on, I can see that both depth sounders are working. I can also see that my GPSs are both working and agree on my location and speed, but can't agree on what direction I'm heading because I'm not moving. And both heading sensors are working, but disagree about my heading.

There are a couple of different themes here. Firstly there is an issue with supposedly Certified N2K equipment not meeting the Standard. Fair enough to highlight that. But the manufacturers may already know and not care. Or worse, see it as a means of 'encouraging' consumers to stick with one brand to ensure compatibility. However, even one brand wont solve some of the issues raised above.

Secondly there is the issue of automatic failover, and knowing source has changed. This is important as you are aware of it and can troubleshoot if it is an unexpected event. Using an Actisense multiplexor to set port priority via software on my PC, and my MFD12 as the 0183 to N2K converter I achieve this. For example, my NavPilot is N2K. If I turn off my preferred 0183 GPS then the AP beeps saying GPS source has changed to the second prioity 0183 GPS until I acknowledge it. Turn the preferred GPS back on and ditto. So, even with 0183 you can effectively manage source priority and failover. I would avoid multiple 0183 to N2K converters - apart from having to buy extra devices you likely then lose the source priority and alert functionality.

Now I agree that as Twisted notes, N2K can give a lot more info and is an ideal goal. My point is just that if you cant get what you want via N2K then consider 0183. It is robust and can still get you a good practical solution.