Visit our Popular Forums

DotDun · 27-09-2015, 19:04

Redundancy does require wiring both to the plotter.

Connect both, choose which one is primary, in your case I would suggest to listen to the transceiver. If the transceiver fails, your plotter *should* auto rollover to the receiver. Assuming the transceiver failure includes transmission, you will not see your own ship.

Looking at the protocol, a transceiver identifies own ship transmissions, which the plotter understands. Obviously early/some plotter implementations don't consider the case of listening to different unit than the active transceiver. It's understandable (but not an excuse).

colemj · 27-09-2015, 19:10

Quote:

Originally Posted by DotDun

Redundancy does require wiring both to the plotter.

.

Not when one has its own display in the cockpit and the other is feeding computers and ipads wirelessly. It is only the plotter that needs one of them wired. In the case of our plotter, it matters which one. It shouldn't.

Mark

DotDun · 27-09-2015, 19:24

Ah, your redundancy is more like dual systems running simultaneously.

One could just as easily state the AIS receiver should filter own ship before outputting to NMEA, obviously it understands own ship. The receiver should send it as own ship on NMEA the same as your transceiver does.

I'm not defending the way Furuno handles it, just trying to be pragmatic about the choices the engineer made.

colemj · 27-09-2015, 20:16

Quote:

Originally Posted by DotDun

One could just as easily state the AIS receiver should filter own ship before outputting to NMEA, obviously it understands own ship. The receiver should send it as own ship on NMEA the same as your transceiver does.

I did state that.

Furuno's AIS implementation is the worse I have seen. The only "choice" I can detect that was made was simply to support AIS at the minimal level needed to legally say they have AIS support in their marketing material. And I think they did that grudgingly.

Mark

DotDun · 27-09-2015, 20:42

I would guess the implementation is closer to what was state of the art in 2006/7 when the NN3D system was designed. I do know the NMEA took an extremely long time finishing AIS in both 0183 and N2k, I believe both protocols were still in flux 8 years ago.

But, that's no excuse for Furuno to not update the NN3D since they are still offering it as a 'current' product. I would like to see AIS ATONs displayed different from vessels.

tanglewood · 02-10-2015, 18:56

Quote:

Originally Posted by DotDun

Or maybe the standards never considered that one would run both a transceiver and a receiver.

Is there a reason to run 2 receivers at the same time??

Redundancy would be the obvious reason, but this becomes incrementally more complicated as AIS receivers are included in more and more VHFs. I first bumped into this when I installed two ICOM M506 VHFs one with builtin AIS receiver. I figured the extra receiver would be useful as a backup if my transceiver failed, but I suddenly had my own boat on top of myself on the plotter and constant alarms. And you can't turn off the AIS function in the M506. So I think as people start installing VHFs with AIS, this will start to become a common problem.

I guess I just don't understand a network design where nobody asked the question "what if there are two of these on the network?" Isn't that the definition of a network? WTF?

tanglewood · 02-10-2015, 19:04

Quote:

Originally Posted by DotDun

Ah, your redundancy is more like dual systems running simultaneously.

One could just as easily state the AIS receiver should filter own ship before outputting to NMEA, obviously it understands own ship. The receiver should send it as own ship on NMEA the same as your transceiver does.

I'm not defending the way Furuno handles it, just trying to be pragmatic about the choices the engineer made.

The problem is that different vendors have elected to do it different ways because the standard doesn't standardize how it should be done. Some AIS receivers filter own-ship's reports, and others don't. And some plotters filter own-ships reports, and others don't. If you put the wrong combination together, you have constant alarms. NMEA deserves a good slap in the head for this little oversight.

DotDun · 02-10-2015, 19:51

Quote:

Originally Posted by tanglewood

Redundancy would be the obvious reason, but this becomes incrementally more complicated as AIS receivers are included in more and more VHFs. I first bumped into this when I installed two ICOM M506 VHFs one with builtin AIS receiver. I figured the extra receiver would be useful as a backup if my transceiver failed, but I suddenly had my own boat on top of myself on the plotter and constant alarms. And you can't turn off the AIS function in the M506. So I think as people start installing VHFs with AIS, this will start to become a common problem.

I guess I just don't understand a network design where nobody asked the question "what if there are two of these on the network?" Isn't that the definition of a network? WTF?

Does your chartplotter not allow to choose the source of AIS? Chose the xcvr and ignore the receive-only.

tanglewood · 03-10-2015, 04:23

Quote:

Originally Posted by DotDun

Does your chartplotter not allow to choose the source of AIS? Chose the xcvr and ignore the receive-only.

No. It should, but it doesn't. The Simrad/Navico/B&G plotters don't let you select the AIS source. They assume there will never be more than one. I'm not aware of any plotters that can, but I haven't done a huge survey.

I have subsequently "solved" the problem by switching to the non-AIS version of the M506 so I am back to having only one AIS source. This is one of many areas where N2K proved itself not ready for prime time. In principal it can do it, but the spec isn't mature enough - for example, it could, but doesn't say that all receiving devices MUST be able to do source selection. And it doesn't say HOW they should do source selections, so you end up with Maretron doing it one way, and the rest of the world doing it a different way. It should also say where own-ship filtering takes place. It could be in the receiver, or it could be in the display device. Either will work, but you need to pick and everyone needs to do it the same way or you end up with... well, just read this and other web posts. I sadly moved the majority of my nav equipment back to 0183 because it was the only way to get reliable, deterministic communications between devices.

DotDun · 03-10-2015, 04:53

Quote:

Originally Posted by tanglewood

No. It should, but it doesn't. The Simrad/Navico/B&G plotters don't let you select the AIS source. They assume there will never be more than one. I'm not aware of any plotters that can, but I haven't done a huge survey.

Interesting. I know both Furuno and Raymarine let you chose the source. IIRC, a friend used to have the Simrad NSO, and I thought it let the user chose the source. My (now very dated) Furuno NN3D, let's you chose the primary source for most data and if that disappears, it'll use anything it finds on other ports/sources (within the scope of it's capabilities, i.e., it doesn't support AIS on N2k). The only thing it doesn't allow this for is DSC, which I find very interesting.

Quote:

Originally Posted by tanglewood

I have subsequently "solved" the problem by switching to the non-AIS version of the M506 so I am back to having only one AIS source. This is one of many areas where N2K proved itself not ready for prime time. In principal it can do it, but the spec isn't mature enough - for example, it could, but doesn't say that all receiving devices MUST be able to do source selection. And it doesn't say HOW they should do source selections, so you end up with Maretron doing it one way, and the rest of the world doing it a different way. It should also say where own-ship filtering takes place. It could be in the receiver, or it could be in the display device. Either will work, but you need to pick and everyone needs to do it the same way or you end up with... well, just read this and other web posts. I sadly moved the majority of my nav equipment back to 0183 because it was the only way to get reliable, deterministic communications between devices.

Not sure I would blame N2k for a 'box' issue. NMEA defines the communication protocol, but doesn't/shouldn't control what goes on inside any particular box, that's up to the vendor. The communication protocol supports identifying 'own ship', hence that's the extent of NMEA's responsibility.

Believe me, I'm not a fanboy of NMEA, in fact I think as a modern communication protocol it is very poorly architected.

tanglewood · 03-10-2015, 05:45

Quote:

Originally Posted by DotDun

Not sure I would blame N2k for a 'box' issue. NMEA defines the communication protocol, but doesn't/shouldn't control what goes on inside any particular box, that's up to the vendor. The communication protocol supports identifying 'own ship', hence that's the extent of NMEA's responsibility.

I see how 0183 says which data is own-ship, but I'm not seeing that in N2K. Do you happen to know which PGN and/or field provides the distinction? I couldn't find it, but documentation on the super double top secret specification is sparse.

tanglewood · 03-10-2015, 05:53

Quote:

Originally Posted by tanglewood

I see how 0183 says which data is own-ship, but I'm not seeing that in N2K. Do you happen to know which PGN and/or field provides the distinction? I couldn't find it, but documentation on the super double top secret specification is sparse.

I think part of the issue might be that the guys specifying N2K viewed it only as a protocol rather than "how to do something". TCP is a protocol that is used everywhere, but it only works if the devices on either end agree on how they are using it. In contrast, the SMTP spec spells out how to use TCP to send email, and details how each end of the connection behaves. N2K seems to have left out some key elements about how the devices on each end need to behave.

DotDun · 03-10-2015, 06:25

Quote:

Originally Posted by tanglewood

I see how 0183 says which data is own-ship, but I'm not seeing that in N2K. Do you happen to know which PGN and/or field provides the distinction? I couldn't find it, but documentation on the super double top secret specification is sparse.

Since the documentation is sparse, I'll have to reverse engineer from a network dump when time is available.

DotDun · 03-10-2015, 06:42

Quote:

Originally Posted by tanglewood

I think part of the issue might be that the guys specifying N2K viewed it only as a protocol rather than "how to do something". TCP is a protocol that is used everywhere, but it only works if the devices on either end agree on how they are using it. In contrast, the SMTP spec spells out how to use TCP to send email, and details how each end of the connection behaves. N2K seems to have left out some key elements about how the devices on each end need to behave.

You are correct, NMEA does a lot of hand waving about interoperability, but reality is each vendor is in 'lock-in' mode. That's why we haven't seen any NMEA protocols for configuration. The vendors don't want it.

The dilemma is for standards bodies is where do standards stop? If you specify every detail, all products will look/act alike. We'd end up eating hamburgers with ketchup, mustard, and pickles. No other options.

FWIW, the IETF (authors of TCP and SMTP) doesn't dictate what happens inside the box, only how the protocol should be used. It's the vendors that decide to interoperate. There are no IETF protocol police, unlike the marine industry, pure market pressure makes things work on the Internet.