Garmin GPS 18x giving funny output

Projects Networking, Protocols, and Devices
1

Not sure if this is the right spot within the forum to post this, but here goes

A few months ago I was able to successfully connect my GARMIN GPS-18x LVC to Arduino and read data from it, as you can see in this screencap: http://www.nickolai.me/uploads/5/6/9/6/5696292/3405496.jpg

Unfortunately school forced me to shelve that project and now I'm retracing my steps from before. I had to switch to a linux machine, and after a number of pains to get Arduino UNO talking with Linux I was finally able to get back to where I was at in that picture.

Sort of. Here's what the data I'm getting this time around looks like: ImageShack - Best place for all of your image hosting and image sharing needs

Why would I be getting weird data like that? Is it possible something happened to the GPS unit? Or is it something to do with Arduino communicating with Linux (I'm on Ubuntu by the way)

There's probably more information I could provide but I really don't know what would be useful. Please let me know if there's anything you'd like me to post and I'll get right on it.

I'm not very electronically inclined, so please go easy on me!

2

Garmin has several output modes and may have gotten switched to the Garmin Binary Output rather than the NEMA standard.

From the technical manual:
http://www8.garmin.com/manuals/GPS18x_TechnicalSpecifications.pdf

4 GPS 18x PC, GPS 18x LVC, & GPS 18x-5Hz SOFTWARE INTERFACE
The interface protocol design of the GPS 18x PC, LVC, and GPS 18x-5Hz products is based on the National Marine Electronics Association’s NMEA 0183 ASCII interface specification. This standard is fully defined in NMEA 0183, Version 2.30. Copies may be obtained from NMEA, www.nmea.org.

In addition to the standard NMEA 0183 sentences, the GPS 18x PC, LVC, and GPS 18x-5Hz may also be configured to transmit information over their serial interface using NMEA 0183 compliant Garmin proprietary sentences. These proprietary sentences begin with the characters, “$PGRM”, instead of the characters “$G” that are typical of the standard NMEA 0183 sentences. The characters “$P” indicate that the sentence is a proprietary implementation and the characters and “GRM” indicate that it is Garmin’s proprietary sentence. The letter (or letters) that follow the characters “$PGRM” uniquely identifies that particular Garmin proprietary sentence.

It is also possible to configure the GPS 18x PC, LVC, and GPS 18x-5Hz to transmit binary data information over their serial interface. See Appendix B: Garmin Binary Output Format for details.

The GPS 18x USB does not transmit NMEA sentences: It transmits using the Garmin USB interface. The Garmin USB interface is discussed in the Garmin Device Interface Specification found in the Garmin Device Interface SDK located on the Garmin Web site at: Garmin: Device Interface SDK.

You can configure the GPS 18x USB to transmit binary data information over the USB interface. Refer to Appendix B: Garmin Binary Output Format.
The following sections describe the NMEA 0183 data format of each sentence transmitted and received by the GPS 18x PC, LVC, and GPS 18x-5Hz products.

3

There are NMEA fragments in there, so I seriously doubt it's in Garmin binary mode. Besides, Garmin binary is a polled mode; it doesn't automatically spew data like NMEA - you must ask for it.

I suspect that there is a wiring problem, or the sketch has changed.

It is conceivable, but extremely unlikely, that the GPS18x has gone insane.

For a sanity test you can connect the GPS18x directly to the PC. Power it with regulated 5V (e.g. from your arduino, a hacked USB cable, a regulated 5V power supply) and connect the GPS TX and GND to the PC RX and GND, respectively.

-j

4

For a sanity test you can connect the GPS18x directly to the PC. Power it with regulated 5V (e.g. from your arduino, a hacked USB cable, a regulated 5V power supply) and connect the GPS TX and GND to the PC RX and GND, respectively.

Here's an easier way...download the sketch below, connect the grounds between the Arduino and GPS and connect a wire from the Arduino Tx (not Rx) and GPS Tx. Open Serial Monitor and cycle through the baud rates until you find the correct one. The below sketch puts the serial ports into high impedance so the Atmega chip is bypassed and the GPS signal is sent directly to Serial Monitor.

void setup(){
  pinMode(0,INPUT);
  digitalWrite(0,LOW);
  pinMode(1,INPUT);
  digitalWrite(1,LOW);
}

void loop(){
  while(1);
}
5

Here's an easier way...download the sketch below, connect the grounds between the Arduino and GPS and connect a wire from the Arduino Tx (not Rx) and GPS Tx.

The GPS18 uses RS232 levels, so a level converter is required between the Arduino and the GPS18.

Your test also fails to eliminate the Arduino as the source of the problem.

Open Serial Monitor and cycle through the baud rates until you find the correct one.

The NMEA standard baud rate is 4800.

-j

6

Your test also fails to eliminate the Arduino as the source of the problem.

It was more of quick test to see if he got different results by taking the sketch out of the equation.

Actually after taking a closer look at both of those screenshots I notice that you are not using the same sketch now as you were in the first screenshot. Your first picture looks like it's just taking in the serial data from the GPS and displaying it to the serial monitor. In the second screenshot it looks like you're taking in the data, parsing it, displaying the original data and then some separate parsed data.

Try using your original sketch first and see if anything changes.

7

Well, the problem has partially resolved itself. Wayneft was correct in pointing out that in the second screenshot I was parsing the data as well as reading it, so I went back to just straight reading it. I still get issues where I'm not getting funny characters, but sentences are cut short or are otherwise mangled such that I can get readings, just not consistent readings. This is intended for a weather balloon launch project, and I was considering using this data to trigger certain action based on an altitude but I simply can't get reasonably reliable altitude readings, as you can see: ImageShack - Best place for all of your image hosting and image sharing needs. That's data from an airplane ride (there was a loss of signal at takeoff which is why that part seems sudden) AFTER I've parsed it and done some data-checking to make sure the altitude looks good. There are still sentences that simply need extra attention in order to be able to get them to output correctly.

Here's the sketch I've been using:

#include <NewSoftSerial.h>

NewSoftSerial gps(0, 1, true);
char byteGPS;

void setup()
{
gps.begin(4800);
Serial.begin(115200);
}

void loop()
{
if (gps.available())
{
byteGPS = gps.read();
Serial.print(byteGPS);
}
}

Some people have noted baud rate issues. As you can see I'm using 115200. I'll try some more baud rates and post the results when I get a chance.

8

You appear to be using NewSoftSerial to talk to your GPS on pins 0 & 1. Those pins are also being used for serial comms by your Serial.print statements. Move the GPS to a different pair of pins & you may have better results.

9

I don't understand, Arduino uses pins 0 and 1 whenever you use Serial.print? I'm just using the serial.print statements to output to my computer....

10

I don't understand, Arduino uses pins 0 and 1 whenever you use Serial.print?

It uses pin 1 when you do a Serial.print(), Serial.println(), or Serial.write(), and it uses pin 0 when you do a Serial.read() (actually, serial data arrives on pin 0, and is buffered, for Serial,read() access later).

So, you can't do hardware serial (Serial is an instance of the HardwareSerial class) and software serial (using NewSoftSerial) on the same pins. Where would incoming data be stored - the hardware buffer or the software buffer?

As was mentioned, use two other pins.

11

I have found that working with a GPS string can be tricky, as you have. I found a lot (and I mean A LOT) of weirdness went away if I called serial.flush() when done reading the sentence. I assume that you look for a new, valid sentence by looking to see if the first character is a "$" sign. If it is not, I further assume you skip the parsing. However, that can potentially leave you with a partially read string hanging in the queue. Whenever I finish reading a sentence or trying to read a sentence, whether it was valid or not (A or V) or whether it was complete or not (started with a $) I call serial.flush(). Has helped hugely.

Hope this is of some assistance.

Ed

12

Unless you plan on sending commands to configure the GPS you can actually run the GPS and debug with serial prints on the same hardware serial port without having to use NewSoftSerial (as long as you don't mind unplugging the GPS every time you upload a sketch). Just connect the GPS Tx to the hardware Rx and leave the GPS Rx floating. Set the baud rate to 4800 and change your code to remove NSS...should work fine.

13

Thanks for all the suggestions, I think edringel is on to something in that GPS is apparently tricky to work with

I tried Serial.flush, but it didn't seem to help
I tried moving the pins from 0,1 to others, and it didn't seem to help
I tried different baud rates, but again, it didn't seem to help. I didn't think it would either, so I only tried half-heartedly

As for wayneft's suggestion to remove NSS, I can't do that because, as kg4wsv said, my specific unit uses RS232 levels so I need an inverter. Thankfully I can do that with one line of code instead of having to go out and buy more hardware.

The unit does read data so I think I will be able to parse the data onboard and determine what I need through a series of filters to make sure the data is good (it can be pretty simple, just compare the parsed data to surrounding data points)

Unfortunately I've been running into another set of issues there. If anyone thinks they might be able to help there please go ahead and take a look at a new thread I started: http://arduino.cc/forum/index.php/topic,64010.0.html

Otherwise, thanks for the suggestions. Cheers,
Nickolai

14

GPS is actually fairly simple to interface. It's RS232 at a reasonably slow rate. It has a checksum to help you verify the data transferred correctly. The checksum algorithm is well known and code is available for it.

The TinyGPS library (written by the NSS author) does a tremendous amount of NMEA parsing for you. Google it.

So, to make this work you need to:

  • get the GPS off pins 0 and 1, since those are already in use (or stop using hardware serial)
  • go get TinyGPS, since you're having trouble parsing NMEA yourself

In addition, for anyone to really help you, you need to post a complete sketch and schematic.

-j