How to read NMEA data

Recently I’ve had troubles with getting a Speed alarm intermittently on our fin stabilizers system.

This alarm is supposedly caused by the speed reading that is outside of the preset speed limits.

Since the speed information is supplied by the GPS, first step was determining whether GPS is communicating speed information to the stabilizers in an orderly fashion.

I observed GPS speed (Speed Over Ground) on the GPS HMI during the occurrence of the alarm and the reading was nice and steady.

Next step was checking if that speed info is delivered properly to the stabilizers.

GPS uses NMEA sentences for communication with connected devices so the idea was to read those sentences during the speed alarm and see if the sentences are complete and accurate.

So how to read an NMEA sentence?

NMEA sentence is a serial type of communication and I could use USB-to-serial adapter I had onboard to connect my laptop to the USB side of the adapter and serial communication terminals on the GPS or stabilizers control unit to the serial side of the adapter and then read the serial data through a dedicated app.

After failing to set up my adapter (it wasn’t getting recognized in the Device Manager), I had to buy a new one that turned out working well: PL2303-DB9.

Looking at the drawing of the stabilizers control cabinet, I saw that the 2 wires coming from the GPS are connected to the terminals marked as RX+ and RX- inside the stabilizers control cabinet so that is where I needed to connect 2 wires from the serial side of the adapter.

Since the serial side of the USB-to-serial adapter is a DB9 male connector, I plugged into it DB9 female-to-male and soldered 2m wires to all 9 pins on the male side. This way I could use any DB9 pins with ease in the future.

Next step was determining which pins to use on DB9 connector to read the data sent by the GPS to the stabilizers.

I couldn’t find info on which specific protocol was used to deliver NMEA sentences from GPS to the stabilizers but from my experience I was expecting it to be either RS-232 or RS-422 or RS-485.

Since the wires from the GPS to the stabilizers were connected to the terminals marked as RX+ and RX-, it would mean that RS-232 is probably not the protocol used, since it doesn’t use RX- (or TX-). It uses TX and GND for transmitting and RX and GND for receiving.

So our protocol was either RS-422 or RS-485.

After googling a bit, I saw there is no standardized pinout for the DB9 connectors when using RS-422 or RS-485 so I found few different pinouts and played hit-and-miss 😊

What ended up working for me was this pinout:

I ended up connecting pin 2 on the DB9 connector to the RX- terminal inside the stabilizer control cabinet and connecting pin 6 on the DB9 connector to the RX+ terminal inside the stabilizer control cabinet.

To summarize the hardware setup: plug USB cable of the USB-to-serial adapter to the laptop USB port and connect pin 6 to RX+ and pin 2 to RX- on the serial side of the USB-to-serial adapter.

It ended up looking like this:

To see the actual NMEA sentences sent by GPS to stabilizers, in this case, I used an app that can allow me to read serial data – a popular app for these purposes named Putty.

After plugging in USB-to-serial adapter (and installing drivers if necessary), check Device Manager to see which port is USB-to-serial adapter connected to. In my case, it was COM3 so type this in into the Serial line field.

We want to read serial data so we tick that box.

Next, serial data is transmitted at a certain speed, this speed is called bauds.

If we don’t get the speed right, we cannot read the data.

The way I determined the speed was checking the GPS unit.

I checked the GPS drawing to find out to which output was the stabilizers cable connected.

In the Settings of the GPS unit, it is possible to see the speed of each output. Ours was set to 4800 bauds so we set the same speed in the Putty.

After that, click Open and voila – you will start receiving NMEA sentences sent by the GPS:

To us, the most interesting NMEA sentence was the one starting with the $GPVTG because this sentence contains speed over ground value which stabilizers use to obtain the current speed.

Next step was waiting for the Speed alarm to occur again and checking if the sentence sent by the GPS during the alarm was complete.

I didn’t have to wait for long, Speed alarm came after a few hours and I could see that the $GPVTG sentence was complete and accurate during the alarm. The conclusion was there is no problem from the GPS side and the problem is caused by something on the stabilizer side.

Since this was end of my contract, I left this issue to be further tackled by my reliever.