Plug and Play NMEA

For some time now I have been looking at how I get access navigational data for use in my spatial development. That sounds awfully grand, let's try that again!

There are instruments all over modern boats; wind speed, wind direction, depth, vessel heading, location even other vessel locations, all available over a few different communications systems with the title NMEA - Which actually stands for National Marine Electronics Association, so strictly speaking NMEA is not a type of communication, in the same way the Hoover is not is not a vacuum cleaner. It turns out the NMEA set standards for communications. At the time of writing there are essentially 3:

• NMEA 0183 - V1 The original standard, basically RS232 at 4800 baud
• NMEA 0183 - V4 The last of the Serial standards working at 38000 baud
• NMEA 2000 - Essentially CAN bus

The NMEA standard does lots more than just set the protocol, it all defines the messages (or sentences) that are sent over the wire

If you have played around with serial communications before you soon realise that you can only really connect one serial device to another, you can't connect lots; as they will all talk over each other. So either you have devices with lots of serial ports (often you find displays on boats with a few inputs for NMEA) or you have instruments that daisy-chain together to pass the messages along or… you get a multiplexer.

A multiplexer acts like a hub, grouping all the serial messages together and passing them down a single port to be read by your down-stream devices, they are very clever as they buffer all the messages and group them together. However this has some problems as well.

Typically 4800 baud is fine for a single instrument, 4800 bits per second, or 600 8 bit words per second should be enough for a spinning wind vane, even with direction information. Except of course it's not just the data being sent, it's also the tags saying what sort of data. Even if that is only a few letters (e.g. HDG for heading and 180) you are talking 6 letters, plus start, end and error correction. Suddenly you are looking at tens of messages per second. A 10hz GPS updates 10 times per second for location, direction and speed. That on its own could saturate a single NMEA connection. What happens if you have many of these or are transmitting more than 1 instrument? Well the NMEA redefined things and allowed 38000 baud - or roughly 500 messages per second, which is a lot better. But you still have issues connection lots of things together and even then you can use up 500 messages fast!

CAN bus is a relatively new boy in town, it actually comes from the automotive industry as a fault tolerant, high speed communication solution for cars. The idea being you don't need to run a wire for each of the little computers in a car, you just daisy chain them all together and they will cooperate. It's a bit more complicated than that, as it is still a serial communication bus, just a more intelligent one running at up to 1mb per second - or about 128,000 messages per second. That is more like it! You only need one wire between all the instruments and you can have as many receivers or transmitters as you like!

So we have lots of ways to get the instruments to talk together, which one shall we use? Well, there is the quandary; NMEA 0183 has been around the longest and is arguably the easiest to implement, so "Low cost" instruments all use it. NMEA 2000 is obviously the best and easiest to use from user point of view, but it costs more to implement it in the electronics, so typically what you end up with is a mix of all of the protocols:

• NMEA 0183 @ 4800 baud for depth sounders, logs, autopilot maybe GPS
• NMEA 0183 @ 38000 baud for AIS and maybe GPS with heading sensors
• NMEA 2000 for AIS, GPS, autopilot and modern plotters

Anyone who has tried to work with this knows how notorious NMEA 0183 can be for just not working, so I was not looking forward to trying to harvest data from all the disparate busses (busi? Bus'?)

Step up to the mark Actisense they have a range of multiplexers and NMEA bridges that link all this stuff together. I got myself an NDC-4 which lets you plug 4 NMEA 0183 devices together (configurable to 4800 or 38000 with message filtering and priority) + a USB port - which looks like a serial port to any PC. Then I got an NGW-1 which lets you communicate bidirectionally between NMEA 0183 and NMEA 2000. So I can plug the USB into almost any NMEA port. Admittedly I really ought to get the NGT-1 which plugs NMEA 2000 into USB, but all the test software I could get only really talks NMEA 0183 messages, the interface to NMEA 2000 has an SDK and has potential to be fast, but odd. So First things first, prove I can wire all the stuff together and get data!

On my desk I am looking at half a dozen flashing LEDs. I bought a NASA AIS receiver and a B&G GPS and heading sensor - So Location, speed, heading and AIS Data (AIS tells you about other vessels within VHF range at 38000 baud.) The B&G GPS is NMEA 2000 and the AIS is NMEA 0183. So I simply connected the NGW-1 (NMEA 2000 -> NMEA 0183) to the NDC-4 (NMEA Multiplexer) the instructions are in the box with lots of pictures. Remembering that transmit wires on one device connect to receive wires on the other. Then connected the power to the NMEA bus and the NDC, plugged the GPS into the NMEA 2000 bus (plus the terminators and power) and finally plugged a USB cable from the dedicated connector in the NDC-4 into my Windows 10 PC - which automatically detects the NDC as a serial port!

How do you test NMEA networks? Well there are lots of flashing LED's going on here. The handbooks tell me that there is data being exchanged. I can even put a serial port monitor on and capture text flying over the serial ports. But by far the easiest way is to run something that understands these messages. The obvious choice would be OpenCPN, an open source chart viewer with various plug-ins… Unfortunately I have never really had the patience to get on well with OpenCPN, it doesn't choose it's scale band well and the way it renders annoys me intensely. It also suffers from the traditional open-source malaise of only having the sexy bits complete. The hard bits, like declutter, error trapping and reliable import/export all have annoying issues. So I tend to fall back on a reliable (and inexpensive) paid for product, Nuno Navigator.

Nuno Navigator is written by Chersoft who also wrote the digital versions of the UK Hydrographic Office (otherwise known as the Admiralty)  SOLAS Books for radio signals, list of lights, tides and safety publications. That includes not only the user products (known as ADP and Total Tides) but also the systems used internally to manage the products, with an additional layer to license them. Underneath the Admiralty products is a very flexible rendering engine that they also use in their Leisure products - Like Nuno Navigator. I used to work for the UKHO and I have a lot of respect for Chersoft (and more importantly the guys that own and run it!) as people who not only understand their products, but also how they are used by sailors.

Needless to say I quite like Nuno Navigator. I started it up after I had plugged in the NMEA spiders-nest I had created and within a few seconds voila, I had location data and AIS data as an overlay on the chart for Southampton. This all worked first time, no trial and error - just plug and play!

The next step is to see if Signal K (an open source restful interface for marine data) is viable and allows me to do the kind of spatial logging I have planned… But that is for a later blog!

So what is the moral of this rambling blog post?

• Using products like Actisense NDC-4, NMEA really is now plug and play, in fact it's easy!
• Nuno Navigator just gets more and more impressive!