NMEA N2K - What's Wrong With It ?

[DotDun]

To save the continually sniping on other threads about what's wrong with NMEA 2000 specification/implementations, let's discuss those issues in thread dedicated to the topic.

To set the stage, Nick has expressed an opinion in another thread about manufacturers of N2K gear that I mostly agree with, although from a industry standards POV, I won't let NMEA off the hook as easily as he did!

Originally Posted by s/v Jedi

For other readers, it should be clear that any display supports calibrated sendors; the discussion is about which displays support performing that calibration.

My view is a simple one: frak the manufacturers that only care to support their own (branded) sensors, or hold agenda's that are not in line with their customers interests. Consumers should choose to buy equipment from manufacturers that try to bring good, innovative products that will integrate with gear from other manufacturers and help make life easier for consumers. Supporting the calibration in Airmar and Maretron sensors should be obvious. Supporting a standard like N2K should also be obvious, yet there is still much trouble with AIS over N2K and the excuses have been invalidated years ago (yes you Simrad, Furuno etc.!)

For all that is wrong with boat electronics, NMEA is not on top of that list IMHO.

ciao!
Nick.

The goal of this thread is to come up with a list of the top ten (or more) issues with N2k spec and the various manufacturer implementations in the hope that someone with the power to do something will pay attention.

The boat show">Miami Boat Show is in 2 weeks, I'll be glad to distribute a hard printed list of this thread to all manufacturers and NMEA itself.

(more from me to follow in between my day job duties)

[DotDun]

Just thinking out loud.

What if......

CF were to become a NMEA member, would CF members then have a voice in NMEA standards????

[s/v Jedi]

I started with:

1. lack of full AIS support by otherwise NMEA approved gear.

but that is not a NMEA problem. So I rewrite it to:

1. Very slow to correct errors or incomplete specifications.

2. No standard for configuring N2K devices.

3. No standard for updating firmware of N2K devices.

4. No support in standard for N2K switches/repeaters.

ciao!
Nick.

[GordMay]

Originally Posted by DotDun

... If CF were to become a NMEA member, would CF members then have a voice in NMEA standards????

Not likely.

I’d expect that the CF might only qualify for NMEA membership under the Associate, or perhaps Trade classifications.

NMEA Membership categories ➥ National Marine Electronics Association - NMEA

ASSOCIATE ($175/Yr):
An individual, entity, organization having a general interest in the marine electronics industry, but not qualifying to become a member in any other class of the above classes of membership. Associate members have limited benefits and no voting rights in association matters.

TRADE ($355/yr):
Wholesalers; retail distributors; manufacturers' representatives; publications; consulting firms; international non-manufacturer businesses or any business directly involved in the marine industry not classified above.

MANUFACTURER ($625 - $1,425/yr)
BOAT BUILDER ($780/yr)
DEALER ($355/yr)

FWIW:
This paper discusses the National Marine Electronic Association’s (NMEA) marine networking interface standard, NMEA 2000®. It briefly illustrates the technical characteristics and architecture of the standard. It also provides a historical perspective, current highlights and a vision for future NMEA 2000 implementations.
Here ➥ http://www.nmea.org/Assets/20090423%...mea%202000.pdf

[DotDun]

Originally Posted by s/v Jedi

1. Very slow to correct errors or incomplete specifications.

2. No standard for configuring N2K devices.

3. No standard for updating firmware of N2K devices.

4. No support in standard for N2K switches/repeaters.

I agree with these and would add (a lower priority):

5. Start work on standardization of radar to display communication over N2k. (Granted, 250kbps may not be enough, but let the standards process bear that out. If the original spec was done correctly, speed enhancements should not be a problem).

[DotDun]

Originally Posted by GordMay

FWIW:
This paper discusses the National Marine Electronic Association’s (NMEA) marine networking interface standard, NMEA 2000®. It briefly illustrates the technical characteristics and architecture of the standard. It also provides a historical perspective, current highlights and a vision for future NMEA 2000 implementations.
Here ➥ http://www.nmea.org/Assets/20090423%...mea%202000.pdf

Gord,

Thanks for the links. I have read the white paper and really enjoyed/laughed at the way they defend their position on CANbus vs. Ethernet. They spin it to agree with their choice verses looking at the whole story.

I frequently engage in global telepresence meetings where we throw multiple streams of 30mbps (3 screens of 1080p) to multiple locations around the world without a QOS or prioritization problem. My point, the whole package of Ethernet coupled with IP and the various prioritization schemes works, but the engineers engaged in N2K chose to compare it to layer 2 Ethernet only as that better defends their choice.

I digress, probably not a subject for this thread!

[DotDun]

Originally Posted by s/v Jedi

I started with:

1. lack of full AIS support by otherwise NMEA approved gear.

but that is not a NMEA problem. So I rewrite it to:

1. Very slow to correct errors or incomplete specifications.

2. No standard for configuring N2K devices.

3. No standard for updating firmware of N2K devices.

4. No support in standard for N2K switches/repeaters.

ciao!
Nick.

Nick,

Can you cite some specific manufacturer issues.

1) We've identified Furuno's lack of support for AIS over N2k.

2)IIRC correctly, Garmin requires a GMI10 to update firmware on their sensors.

3)RM requires a C (or E) MFD to update the firmware on their STng sensors.

[RicknSue]

Speaking as someone very new to the marine electronics topic, but with probably more time spent working with CAN systems than most anyone other than an automotive engineer (Mercedes Master Diagnostic tech since 1984), the majr issue I see after reading the white paper is that this is antique already..250K...really?
When I read it, I am reminded of when they first taught CAN to us, they told us the components would 'know' where they 'belonged' in the hiearchery, we(the people fixing it) had no need to interpet the signals (just check CAN-H and CAN-L voltages), it would 'protect' the rest of the network...HAHAHA.... that last one lasted about 2 weeks after the first 98's left the lot, and we had cars losing all functions over one component.
Fast forward to a couple years back....the CAN alayzer, and other auto specific scope programs that you can read the data with (although most of us had already figured out how to 'read' the CAN with a scope and look for corrupt signals that would make things quit 100 miles after engine startup)
The auto makers knew that 250K wasn't capable of audio/video data reliably, yet the boat guys can do it? (hence why fibreoptics started- which weren't great either). Now they are all HI speed networks and the light beams are gone, mostly...
Maybe you shoud tell them to talk to SAE, they have a lot of time invested in what goes wrong already.

[goboatingnow]

i would add

* Digital Switching PGNs, - internal groups been over three years and nothing to show for it

* support for star installations with active switches enabling fault isolation and easier debugging

* Centralized error reporting, user retrieval protocol, like SNMP/OBD

* extend PGNs to allow autopilot control, ie standardised PGNs to allow display head A ( OR MFD) to interface to autopilot course computer B

Dave

[s/v Jedi]

Originally Posted by DotDun

Nick,

Can you cite some specific manufacturer issues.

1) We've identified Furuno's lack of support for AIS over N2k.

2)IIRC correctly, Garmin requires a GMI10 to update firmware on their sensors.

3)RM requires a C (or E) MFD to update the firmware on their STng sensors.

- Simrad AI50 still doesn't support the class-B static PGNs IIRC.

- Firmware updating between brands is a problem everywhere.

- DSC PGNs was also troublesome I believe. Like programming a VHF call from an AIS unit ?

ciao!
Nick.

[DotDun]

Originally Posted by RicknSue

Speaking as someone very new to the marine electronics topic, but with probably more time spent working with CAN systems than most anyone other than an automotive engineer (Mercedes Master Diagnostic tech since 1984), the majr issue I see after reading the white paper is that this is antique already..250K...really?
When I read it, I am reminded of when they first taught CAN to us, they told us the components would 'know' where they 'belonged' in the hiearchery, we(the people fixing it) had no need to interpet the signals (just check CAN-H and CAN-L voltages), it would 'protect' the rest of the network...HAHAHA.... that last one lasted about 2 weeks after the first 98's left the lot, and we had cars losing all functions over one component.
Fast forward to a couple years back....the CAN alayzer, and other auto specific scope programs that you can read the data with (although most of us had already figured out how to 'read' the CAN with a scope and look for corrupt signals that would make things quit 100 miles after engine startup)
The auto makers knew that 250K wasn't capable of audio/video data reliably, yet the boat guys can do it? (hence why fibreoptics started- which weren't great either). Now they are all HI speed networks and the light beams are gone, mostly...
Maybe you shoud tell them to talk to SAE, they have a lot of time invested in what goes wrong already.

Yes, I still shake my head at why they chose CAN vs. alternatives. I have to assume they chose 250kbps in order to get the 200 meter distance.

[DotDun]

Originally Posted by s/v Jedi

- DSC PGNs was also troublesome I believe. Like programming a VHF call from an AIS unit ?

ciao!
Nick.

Are the PGNs/0183 Sentences defined to do this?

[s/v Jedi]

Originally Posted by DotDun

Are the PGNs/0183 Sentences defined to do this?

I don't think so... which is why I posted it

ciao!
Nick.

[bcn]

12808 - DSC Call Information
Category: AIS
This PGN provides Digital Selective Calling (DSC) data according to ITU M.493-9 with optional expansion according to ITU M.821-1. DSC is a paging system that is used to automate distress alerts sent over terrestrial communication systems such as VHF, MF and HF marine radio systems. DSC provides a mechanism to report significantly more information regarding a distress call rather than just the distress itself. Products equipped with DSC will transmit and receive this information.

[s/v Jedi]

Originally Posted by bcn

12808 - DSC Call Information
Category: AIS
This PGN provides Digital Selective Calling (DSC) data according to ITU M.493-9 with optional expansion according to ITU M.821-1. DSC is a paging system that is used to automate distress alerts sent over terrestrial communication systems such as VHF, MF and HF marine radio systems. DSC provides a mechanism to report significantly more information regarding a distress call rather than just the distress itself. Products equipped with DSC will transmit and receive this information.

Yes but I don't think this PGN will setup n outgoing DSC individual call...

ciao!
Nick.