Help! Which DSC radios are compatible with which plotters?

[s/v Jedi]

Originally Posted by Jerry Woodward

Thanks Jedi for this eye-opening thread. I am in need of a new VHF and was seriously considering the SH GX2400. I have a full N2K network, Zeuss 2 MFD, Vesper XB8000, plus other N2K stuff not related to this issue. My main GPS source is the Vesper GPS and I assumed that any N2K enabled VHF would be able to acquire the Vesper GPS from the N2K network.

I was aware of the issues of not being able to call a AIS target from the chart plotter, but that didn't bother me too much: if the VHF has AIS, then you can simply select it from the VHF list of targets.
But if the VHF has trouble getting GPS from the N2K network, that is a big issue. I hope that issue has been resolved for the GX2400.

I am now looking more seriously at the B&G V50 as that should play nice with my Zeuss 2 plotter. But you and others seem to have a problem with the wireless remote. Other than that, you seem to be happy with the V50. If I don't need the remote, would you recommend the V50?
One thing that would be nice is if a DSC position request (as well as a distress call) would show up on the chart plotter. Can you comment on whether both of these radios will do that or just the V50?

I would not get the B&G V50 because the PTT switch is unsuitable for serious use and most can’t work it at all. The lack of a good working remote is a dead end as well. They now have a V60 I think but again with similar wireless remote. It’s range without loss of audio quality is less than 20’ and at some point they don’t even pair anymore.

[Jerry Woodward]

Originally Posted by Kamen

My experience is with a previous generation Navico hardware (Simrad NSS Evo2 MFD and Lowrance LINK8 VHF). Everything works. AIS targets and DSC position polling requests show up on the MFD and you can initiate DSC calls from the MFD.

This is good to know! The Lowrance Link8 VHF looks identical to the B&G V50 and the EVo2 MFD looks identical to the Zeus 2 (likely since they are both part of Navco) Did this all work using N2K only or did you have to use 0183 also?

Reading some of the links that Jedi provided, it seems like the biggest problem is correct display of DSC position information on the MFD. Here is an interesting discussion and test from 2012 that still seems to be relevant:
Chart Plotter and DSC Radio Interface

The good news from this test was that the correct coordinates of the DSC position showed up on the chartplotter (a Lawrence Link 8 talking to a Lawrence chartplotter). The bad news is that the chartplotter had trouble identifying the nature of the DSC message. Using 0183, the plotter incorrectly identified the DSC polling reply as "unknown distress". On N2K, the plotter identified it as "Grounding Buddy". That would be funny if it wasn't so sad.

[s/v Jedi]

Let me say this again: coding for this has been done by a couple of kids copy & pasting code from the net. It is a sad affair.

Icom has let me down in the past with all their microphone cords falling apart and customer support telling you to send them the mike for repair... like if that helps when sailing in some 3rd world country. Now I understand they also have trouble with their nmea2000 support

Furuno had this trouble with their first generation of 3D plotters so I’m not sure if trying their radio would be wise. Navico has a black box radio with regular phone horns which may be the ticket? Who knows?

[Jerry Woodward]

Originally Posted by s/v Jedi

I would not get the B&G V50 because the PTT switch is unsuitable for serious use and most can’t work it at all. The lack of a good working remote is a dead end as well. They now have a V60 I think but again with similar wireless remote. It’s range without loss of audio quality is less than 20’ and at some point they don’t even pair anymore.

Jeez, that is such a fundamental flaw, I would think they would need to issue some sort of recall to fix it. Is this only in the remote, or do you find the same issue with the PTT on the wired mic?

I have a small cat and I don't really need the wireless. I have a good handheld VHF if I really need to use it away from the helm.

[s/v Jedi]

I think B&G just launched a new V100 radio... one with AIS receiver and one with transponder. I wish I could try one

[Kamen]

N2K only.

[s/v Jedi]

Originally Posted by Kamen

N2K only.

I want nmea2000 only but the v100 has 0183 as well

[Kamen]

What I meant was that I networked the Evo2 and the Link-8 with NMEA2000 only. Yes, they also support NMEA-0183. I did not have to resort to that.

[s/v Jedi]

Originally Posted by Kamen

What I meant was that I networked the Evo2 and the Link-8 with NMEA2000 only. Yes, they also support NMEA-0183. I did not have to resort to that.

The link 8 is the same as my V50... don’t you have trouble with the PTT switch on the mike? On the B&G radios it feels like it clicks but it doesn’t tx unless you push it with all your might. A friend here just bought a new one and the same problem.

I believe the link 8 can’t use the wireless remote mike... that’s just fine because it’s a pos

But indeed, nmea2000 implementation works good. I already found something strange though: PGN 129799 is transmitted 5 times per second while the Standard Horizon only transmits when a setting changes. Not sure which is the correct way yet, can think of positive points for either.

[s/v Jedi]

I have identified some more related PGN’s:

127233 MOB data
129041 AIS AtoN report (? does my Vesper do that?)
129798 AIS SAR Aircraft position report

These came up while reading the manual for that new V100 radio. If the hardware checks out, this may be the first radio to do it all. The V90S had an AIS receiver but the V100 has no AIS at all and the V100B has an AIS transceiver. I would opt for no AIS in that case as I prefer a separate system, especially when these radios require two antennas anyway.

[Kamen]

I sold the boat 3 years ago, but the radio was fine and it integrated well with the MFD. Sorry about your troubles.

[tanglewood]

Originally Posted by s/v Jedi

I already found something strange though: PGN 129799 is transmitted 5 times per second while the Standard Horizon only transmits when a setting changes. Not sure which is the correct way yet, can think of positive points for either.

This is a good example of the apparent gaps in the N2K specification. I would expect it to give some guidance on the xmit frequency, and when/why to deviate. But I have never seen any guidance on how to exchange messages - only the definitions of the messages themselves. What to do with them, when to send, what to expect as a response, how to respond, all seems to be unspecified.


One area where this is highly problematic, and SH seems to have gotten tangled up in it too, is how you do device discovery, how you enumerate multiple devices that can provide the same date (like multiple GPSes), and how you pick which to use. So everyone does it differently.


ICOM announces that it is a GPS and all sorts of other things, sends out those PGNs, but with blank data. The announcement causes some other devices to think it's the new priority source of data and switch to it. Then those devices alarm because the data in the PGN is blank. Most then switch back, at least until you cycle power on the VHF again, or until another device comes or goes on the network and it triggers again.


When the ICOM first came out it had a lot of trouble finding N2K GPS data sources which sounds very much like the current SH problem (or at least one of them).


NMEA has a published paper that walks through how you uniquely and persistently identify devices so you can select one to use. It's not part of the spec, I don't think, simply because it's not how everyone does it. The paper says to use the devices "NAME" field which is actually the concatenation of several sub-fields. This field is globally unique, identifying each device with a manufacturer name, device type, and unique serial number. Lots of vendors do this, showing you a list of devices with vendor names and device type, plus a serial number.


Maretron does it differently, and I have seen hints that Garmin is the same. They only look at the device type (GPS, Depth, etc), and only differentiate between multiple devices of the same type based on either the Device Instance or the PGN Data Instance. Maretron would have you think this is the correct way to do it, and they certainly had me convinced for a while. But after reading the paper above and looking at other products I realized that Maretron is (or was) alone in their approach. There is nothing that says you can't do what Maretron is doing, but it depends on the ability to easily program the Device Instance and the PGN Data Instance, and that's a problem. Granted, the standard requires that those fields be adjustable, but it doesn't say how, or how easily. And many products don't offer any practical way to change them. And in defense of the products that don't allow easy programing of that field, the standard does explicitly say the network needs to operate even if all Instance fields are zero. But I guess it depends on your definition of "operate". But the result is that Maretron can only operate with devices that have easily programmed Instances.


It's all very frustrating, and countless hours wasted is what has driven me back to 0183. It's inelegant, but works flawlessly.

[s/v Jedi]

Originally Posted by tanglewood

This is a good example of the apparent gaps in the N2K specification. I would expect it to give some guidance on the xmit frequency, and when/why to deviate. But I have never seen any guidance on how to exchange messages - only the definitions of the messages themselves. What to do with them, when to send, what to expect as a response, how to respond, all seems to be unspecified.


One area where this is highly problematic, and SH seems to have gotten tangled up in it too, is how you do device discovery, how you enumerate multiple devices that can provide the same date (like multiple GPSes), and how you pick which to use. So everyone does it differently.


ICOM announces that it is a GPS and all sorts of other things, sends out those PGNs, but with blank data. The announcement causes some other devices to think it's the new priority source of data and switch to it. Then those devices alarm because the data in the PGN is blank. Most then switch back, at least until you cycle power on the VHF again, or until another device comes or goes on the network and it triggers again.


When the ICOM first came out it had a lot of trouble finding N2K GPS data sources which sounds very much like the current SH problem (or at least one of them).


NMEA has a published paper that walks through how you uniquely and persistently identify devices so you can select one to use. It's not part of the spec, I don't think, simply because it's not how everyone does it. The paper says to use the devices "NAME" field which is actually the concatenation of several sub-fields. This field is globally unique, identifying each device with a manufacturer name, device type, and unique serial number. Lots of vendors do this, showing you a list of devices with vendor names and device type, plus a serial number.


Maretron does it differently, and I have seen hints that Garmin is the same. They only look at the device type (GPS, Depth, etc), and only differentiate between multiple devices of the same type based on either the Device Instance or the PGN Data Instance. Maretron would have you think this is the correct way to do it, and they certainly had me convinced for a while. But after reading the paper above and looking at other products I realized that Maretron is (or was) alone in their approach. There is nothing that says you can't do what Maretron is doing, but it depends on the ability to easily program the Device Instance and the PGN Data Instance, and that's a problem. Granted, the standard requires that those fields be adjustable, but it doesn't say how, or how easily. And many products don't offer any practical way to change them. And in defense of the products that don't allow easy programing of that field, the standard does explicitly say the network needs to operate even if all Instance fields are zero. But I guess it depends on your definition of "operate". But the result is that Maretron can only operate with devices that have easily programmed Instances.


It's all very frustrating, and countless hours wasted is what has driven me back to 0183. It's inelegant, but works flawlessly.

I agree with all that, but programming the instance is done with standard PGN’s so not vendor specific and I found they can be set with every display/adapter made by Maretron but also B&G. I didn’t look at my Furuno RD33’s but wouldn’t be surprised because every certified device which allows user interaction is supposed to have it, even this Standard Horizon radio that utterly fails because it can’t even generate the list of connected devices, let alone program them.

But what Icom does is very disappointing. Reason not to buy it

[tanglewood]

Originally Posted by s/v Jedi

I agree with all that, but programming the instance is done with standard PGN’s so not vendor specific and I found they can be set with every display/adapter made by Maretron but also B&G. I didn’t look at my Furuno RD33’s but wouldn’t be surprised because every certified device which allows user interaction is supposed to have it, even this Standard Horizon radio that utterly fails because it can’t even generate the list of connected devices, let alone program them.

But what Icom does is very disappointing. Reason not to buy it

Unfortunately I've encountered quite a few that don't accept the PGN that allows for programming of the instance. And the spec doesn't say how it needs to be programmed, just that there needs to be some way. So if it's via proprietary software or proprietary PGNs, that would be completely compliant.


But regardless, the fundamental problem is that it's a free for all. Thankfully there are only two defacto approaches to disambiguation and source selection, and not dozens. Well, maybe more than two when you consider SH & ICOM. But the the two groups each argue they are correct, and look at the other group like they are daft. Meanwhile we are left with products that don't interoperate.


At this point I just accept that it is what it is, and use N2K where is makes sense, and use other things where it doesn't. NMEA has had 20 years to address this stuff and hasn't, so I don't think salvation is coming. In the mean time, cave-man 0183 is looking pretty good these days. My system came right up, I enabled the various transmit sentences, and it's all working fine. No drama. That's how I like it.

[continuouswave]

Originally Posted by Jammer

DSC defines a "position request" and a "position report" message. They are not widely used, but are supported by all DSC-capable radios.

This is true and not true.

Support for POSITION REQUEST or POSITION REPORT is not REQUIRED in a VHF Class-D DSC radio, but, in actual practice, most DSC Class-D VHF radios do support it.

But that has nothing to do with how a chart plotter will behave.