listening to NMEA 2000?

Ian_Edwards

Well-Known Member
Joined
9 Feb 2002
Messages
2,221
Location
Aberdeen Scotland
Visit site
What do I need to listen-in on what my NMEA2000 system is doing?

I know NMEA 2000 is basically CanBus and I'd like to be able to monitor what's going on the bus.

Ideally I'd like to be able to connect a "box of tricks" to the UBS port on my laptop, with supporting software that displays the strings being transmitted on the Bus

I've looked on the web and I see many CanBus monitoring systems ranging in price from a few pounds to £200 or more, many seem to be aimed at monitoring the CanBus on cars.

In the past I've have successfully listened to NMEA183 on a Laptop using a USB to serial converter and a simple program like hyperterminal.

What's the equivalent set-up for NMEA2000?
 
What do I need to listen-in on what my NMEA2000 system is doing?

Even if you had a device that got the data in and displayed it, it would not mean much without a decoder as unlike 183 it's binary mush. As the standard is closed and expensive, and NMEA are litigious if anyone bypasses giving them money, I don't think you are likely to see much without buying something specifically designed to do the job for muchos £$€.
 
I had contemplated something like this, but discovered it'll cost ya muchos bucks.

Essentially, you'd need something that can read NMEA-2000, such as...
http://www.nmeashop.co.uk/index.php?route=product/product&path=66_73&product_id=54

and then you need software that can understand the NMEA-2000 sentences. That's the really expensive bit.

If I were you, I'd go for one of these...
http://www.nmeashop.co.uk/index.php?route=product/product&path=66_73&product_id=65

and then you can pick up the nmea-0183 versions of the sentences with any piece of software that can read nmea-0183. Or even Mark 1 eyeball.
Though of course it won't recognise any nmea-2000 only sentences.
 
What do I need to listen-in on what my NMEA2000 system is doing?

I know NMEA 2000 is basically CanBus and I'd like to be able to monitor what's going on the bus.

Ideally I'd like to be able to connect a "box of tricks" to the UBS port on my laptop, with supporting software that displays the strings being transmitted on the Bus

I've looked on the web and I see many CanBus monitoring systems ranging in price from a few pounds to £200 or more, many seem to be aimed at monitoring the CanBus on cars.

In the past I've have successfully listened to NMEA183 on a Laptop using a USB to serial converter and a simple program like hyperterminal.

What's the equivalent set-up for NMEA2000?

Professional CAN bus development tools are expensive. The cost of a CAN/USB dongles will include some very basic PC software which won't allow you to do very much analysis. Vector's tools are probably regarded as the best but you will need to spend many hundreds for the dongle and more for software.

There is some free analysis software available for the PC called BUSMASTER, it handles standard and extended CAN2 as well as J1939 and all 3 can exist on a single CAN bus at the same time. BUSMASTER was started by Bosch and now has an open source version. BUSMASTER is a bit clunky and a bit buggy but I use it successfully for work. So with free software you need a dongle that BUSMASTER supports (unless you want to write your own driver). It supports several CAN PC interfaces some of which are USB. I have a Peak device.

With the above you will be able to find the baud rate, standard, extended or J1939 protocols and then display, log and graph the messages being transmitted on the CAN bus. However, you'll either need to reverse engineer the messages or obtain the message formats from somewhere before they make any sense.

CAN bus is a truly wonderful standard, highly robust and a perfect choice for boat instrumentation. I have not worked with NMEA2000 but I understand it's a closed standard which is expensive to purchase.

I wonder if this marvellous device would do it:

http://www.hobbytronics.co.uk/bus-pirate

Sorry Nigel, not a hope.

Some links.
http://www.etas.com/en/products/applications_open_source.php
https://github.com/rbei-etas/busmaster/wiki/Hardware-support
I have one of these;
http://www.peak-system.com/PCAN-USB.199.0.html?&L=1

I know nothing of low cost dongles that are sold on Ebay, but they might do what you need at a better (lower) price.

If you want to experiment with your own dongle (or instrument) then this is a good platform but you need to sort out your own interface and programme an ARM Cortex M0;
http://www.embeddedartists.com/products/lpcxpresso/lpc11C24_xpr.php
 
Hi, thanks for the replies so far, I'm beginning to a get feel for NMEA2000 and CanBus.

But if its such a closed shop, why do Raymarine publish a list of NMEA 2000 sentences in the handbook for the new e series MFDs?

This is an extract:

The display supports the following NMEA 2000 sentences.
These are applicable to NMEA 2000, SeaTalkng and SeaTalk 2 protocols.
Message number Message description Transmit Receive Bridge


59392 ISO Acknowledgment ● ● ●
59904 ISO Request ● ●
60928 ISO Address Claim ● ● ●
65240 ISO Commanded address ● ●
126208 NMEA - Request group function ●
126208 NMEA - Command group funciton ●
126208 NMEA - Acknowledge group function ● ● ●
126464 PGN List ● ● ●
126992 System time ● ● ●
126996 Product information ● ● ●
127237 Heading/Track Control ●
127245 Rudder ● ● ●
127250 Vessel heading ● ● ●
127488 Engine parameters rapid update ●
127489 Dynamic engine parameters ●
127493 Dynamic transmission parameters ●
127498 Static engine parameters ●
127505 Fluid level ●
128259 Speed ● ● ●
128267 Water depth ● ● ●
128275 Distance log ● ● ●
129025 Position rapid update ● ● ●

The formatting hasn't come through the cut and paste, the dots are for Transmit, Receive and Bridge.

With this information then surely it is possible to listen to the CanBus Traffic?
 
The plot seems to thicken!

Thanks for the additional information, I can see that reverse engineering NMEA 2000 wouldn't be a simple task, although it appears that the process is underway in various opensource projects.

My interest in read NMEA 2000 is driven by my recent experience of faults on a NMEA 2000 systems and in a different domain a fault on my Subaru. In both cases the service engineers, Raymarine and at the Subaru dealer didn't have the foggyest idea of what he problem was and how to solve it. They were effectively swapping modules until the fault went away. Both these faults were fixed under guarantee, so they didn't cost me any cash. But they cost me a whole heap of time, multiple trips to the garage and days of prime sailing time waiting for engineers to appear.

The Subaru problem was eventually fixed after the fault was referred back to the factory in Japan and in turned out to be a faulty sensor on the glow plugs, although this fault caused the warning lights for the ABS, stability control, oil pressure, hand brake, etc all to come on. Basic garage diagnostics could only tell me that I had an electrical fault!

I never found out what the Raymarine fault was, but it disappeared after replacing the PCB in the SPX30 autopilot and then at a later date after the fault had reappeared, the fluxgate compass.

My Southerly has 2 seperate CanBus systems on board NMEA 2000 and EmpirBus, so I'm looking for a first line of defense, monitoring the bus would at least allow me to "see" what was going on and give me a better chance of diagnosing the problem, if not fixing it.

It's a great pity that NMEA 2000 is a closed shop, it would be much better if it was an open standard, if it becomes the de facto standard method for data transmission in the marine electronics industry, it will get reverse engineered and no amount of litigation will stop that happening, better IMHO to make it an open standard and reap all the benefits that come from that.

By the way, I do have quite a lot of programming experience, before I got promoted, according to the "Peter Principle", I programmed in assembly language, Fortran, C++ and various forms of Basic, although I would admit to being rusty, since I have actively programmed for a living since the early 1990's.
 
May or may not help you in the right kind of direction:

http://forum.arduino.cc/index.php?PHPSESSID=hmlg23vrir2nc6ksv7fljvtri1&topic=50893.15

also this may or may not help: http://www.cananalyser.co.uk/ In face I've emailed them to see what they say as I'd be interested in this for future projects.

I've dabbled a bit in this to some extent, not on the Arduino side, though the ARM based board has considerable CANBUS support now. I was incensed by being locked out of my cars by proprietary interfaces and different standards, and went the Lawicel - CANUSB adapter route. Without some background knowledge, decoding CAN messages - 11 or 29 bit versions is not easy.
That's deliberate. Franchised dealers love it!!
You need software and a laptop to control the rear handbrake motors of my wife's car- just to replace the pads!! I've spent almost £1K on both Mercedes and VW software / adapters. It's paid for itself I reckon, over the last 8 years.
With a much smaller consumer base, I think breaking the NMEA 2000 monopoly will take longer.but it will happen. As time progresses - the number of people with minor problems with less than new equipment, but who are not able to simply throw money at the problem will increase vastly. Enter a cottage industry to fill the gap? Hope so!!
Graeme
 
Maretron's N2KView software displays NMEA2000 data on a PC or iPad but at over $400 is not cheap.

Navigation.jpg


http://www.maretron.com/products/N2KView.php
 
With a much smaller consumer base, I think breaking the NMEA 2000 monopoly will take longer.but it will happen. As time progresses - the number of people with minor problems with less than new equipment, but who are not able to simply throw money at the problem will increase vastly. Enter a cottage industry to fill the gap? Hope so!!
Graeme

I'll second that, and it's really were I'm coming from.

It's not just the cost of sorting NMEA 2000 stuff out. Its the fact that the technicians I've come across haven't been trained to repair NMEA 2000 in other than a rudimentary fault tree analysis and swap the module. And as I learnt from my Subaru experience, the apparent fault (in this case a whole heap of warning lights coming on) wasn't remotely related to the actual fault, which was a faulty glow plug and/or glow plug sensor. I guess that the glow plug fault was outputting "rubbish" on the CanBus and this was being picked up as faults in all sort of other subsystems.

Thanks for all the input, and I've looked at all the links, which reflect a lot of interesting stuff going on out there, but none of it satisfy my basic requirement, which is to passively monitor the NMEA 2000 bus to see if I can identify a faulty component.
 
It's a great pity that NMEA 2000 is a closed shop, it would be much better if it was an open standard, if it becomes the de facto standard method for data transmission in the marine electronics industry, it will get reverse engineered and no amount of litigation will stop that happening, better IMHO to make it an open standard and reap all the benefits that come from that.

I'd suggest that N2K is the actual incumbent standard already. Minor thread drift but it'll be interesting to see where we are in a few years' time.

We're seeing a huge explosion in the use of marine data over IP. Manufacturers have their proprietary protocols for radar, sonar, video etc., but the de facto standard for marine data over IP is the application layer from NMEA-0183, and not the newest version (how many of your apps would barf if a TAG block was prepended to a sentence?). I don't think I'm alone in suspecting that this is in no small part due to (an older version of) NMEA-0183 having been outed:
http://www.catb.org/gpsd/NMEA.html
The N2K standard costs a few grand to buy (ie more than the expected take for most app developers) and even if purchased legitimately cannot be used in open source software (like OpenCPN) for fear of pursuit by the litigious NMEA who allegedly class such use as illegal re-distribution of their intellectual property.

The interesting thing will be what happens when the NMEA eventually come to release OneNet which by all accounts is pretty much NMEA 2000 over IP. Unfortunately we're unlikely to see any products in the next couple of years and by the time we do, where's the incentive for software developers to convert from a de-facto (non) standard which is effectively in the public domain to a closed one which costs thousands to buy, has restrictions on use and needs mass uptake to be of any relevance? Maybe the NMEA will have to be dragged kicking and screaming from the 1980s where they brought CANbus from and recognise that opening the protocol will be the optimal route to gaining acceptance (and maintaining their revenue on certification etc.).

Don't get me wrong: I think don't think lack of a proper standard is a good thing. Like Ian_Edwards I think an open standard would be the best for everyone (especially people trying to fix their own networking problems) and probably least bad for the NMEA.

Same thoughts only in more words:
http://stripydog.blogspot.co.uk/2014/01/the-curious-world-of-marine-data.html

Obligatory xkcd in honour of the marine electronics industry:
http://xkcd.com/1072/
 
The N2K standard costs a few grand to buy (ie more than the expected take for most app developers) and even if purchased legitimately cannot be used in open source software (like OpenCPN) for fear of pursuit by the litigious NMEA who allegedly class such use as illegal re-distribution of their intellectual property.

The EU directive on legal protection of computer programs (which is implemented in the law of the UK and other EU countries) specifically allows reverse engineering for interoperability purposes. It's in article 6 here...

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250:EN:NOT

Given that, I can't see how the NMEA can protect their protocol forever. They can protect the trademark "NMEA 2000", and they can prevent products being marketed as NMEA 2000 compliant because that uses the protected trademark, but they cannot prevent others from implementing the protocol they have defined as long as it has been discovered by reverse engineering for interoperability reasons only. Despite that, and there being case law now in the EU of the inventors of protocols losing court cases when they have tried to protect their standard (Skype being an example), the NMEA is a particularly nasty and litigious organisation and they know that any small outfit will not risk the expense of defending their position through the courts.
 
Top