U-Blox neo-6m serial problem

Please re-direct me if I am on the wrong section.

While there has been significant documentation on using GPS modules with arduino, I am still having problems.

I am using an Uno with the Ublox neo-6m gps module connected on a breadboard (http://www.hobbyking.com/hobbyking/store/__31135__neo_6m_gps_module.html)

This simple code is giving me gibberish in the serial window.


#include "SoftwareSerial.h"

SoftwareSerial mySerial(10, 11); // RX, TX

void setup() 
  // Open serial communications and wait for port to open:

  Serial.println("uBlox Neo 6M");

  // set the data rate for the SoftwareSerial port


void loop() // run over and over
  if (mySerial.available())



???Blox Neo 6M

and so on…

I have tried many many many different baud rates, but I still haven’t gotten anything resembling NMEA protocol GPS data.

any help would be greatly appreciated :slight_smile:

This looks like a speed problem.

It might be a speed problem between the arduino and pc, or between the arduino and gps.

Your first line seems to be good ( except for the missing u ), so the problem would seem to be between arduino and gps.

38400 seems to be a very high default speed for a gps module. Most of them start off with 4800 or 9600 and if you want faster, you have to send a command to them to change it.

How is the data appearing ? does it appear in bursts at 1 second intervals ?

Do you have an issue with 3V - 5V incompatibility ?

You might want to read the datasheet https://www.u-blox.com/images/downloads/Product_Docs/NEO-6_DataSheet_%28GPS.G6-HW-09005%29.pdf

and section 1.15.1 in particular,

Your module might have been wired to output UBX data by default.

Section 7 of mfg datasheet says their default setting is 9600 baud, but this can be influenced by whoever made the breakout board you have, by tying the two configuration pins high and low ( sect 1.15.1 ). If you can see those pins you can poke them with your multimeter to see if high or low.

You can find out about ubx dataset in one of the ublox docs somewhere, those droney people like the non-nmea data.

If you looks closely at your gobbledegook there, you will see on the end of each short line, the greek letter "mu" used for micro, as in microsecond or micrometre, followed by lower case b.

This is the first two characters of the ublox ubx data format message. So that is what you are receiving.

And the reason why the first two chars of the message packet appear at the end of the line, rather than the beginning where you would expect, is the next byte is a 0D or 0A and is being spuriously interpreted by serial monitor as a line feed although it is actually part of the data message. I got a copy here of the Ublox5 ubx data description, you need to find the Ublox6 document, I don't know how different it is.

Then you need to create a struct which is a union of an array of bytes and the int/short fields of the message. You read the bytes from the serial into the array and then you can read the data items from the relevant fields in the struct.

if you don't want to figure out the ubx, your alternative is to find the command string to send to the module, to instruct it to start broadcasting nmea messages instead.

The easiest way to set up (or reset to factory defaults) UBlox GPS units is to use the control program that UBlox provides. Download it here for Windoze: http://www.u-blox.com/en/evaluation-software/u-center.html

I have tried the ublox configuration software. I removed the atmega32 chip and plugged the gps module into input 0 and 1 (rx and tx). I attempted to set the baud to 9600 and port out to only NMEA. It was defaulted to ubx. However, I don't think my changer are saving. I think I need an FTDI To USB adapter?

This article shows some configuration stuff: http://www.hobbyking.com/hobbyking/store/uploads/748462262X568156X16.pdf

If you can talk to the chip using the U-center software, you should be able to set and save the configuration. If that doesn’t work, it will if you use a serial-to-USB adapter (FTDI or CP2012) and bypass the Arduino completely.

If you cannot reset the chip, you can learn to decode the ubx format. it is not very difficult, and it is actually more efficient,

I believe the tinyGPS library works best with NMEA protocol, so I will attempt to configure the GPS to only put out NMEA. Using the arduino to connect the GPS to ublox isn’t working, so I need a cable.

Does this look like the right adapter? http://www.amazon.com/GearMo®-3-3v-Header-like-TTL-232R-3V3/dp/B004LBXO2A

I have a quick question related to the project. Will an arduino uno allow me to connect:

  • This GPS module
  • An RFID reciever module connected through an RS232 shield
  • An SD or micro SD card reader

Will all of these be able to function at the same time?

Using the arduino to connect the GPS to ublox isn't working, so I need a cable.

This sentence doesn't quite make sense. The GPS device IS the ublox. Do you mean, to connect GPS to Uno ?

If you want to get the gps device to output nmea, you need to successfully be able to switch it to nmea mode. This usually requires you to transmitt some kind of control message to it, when you power up the system. This tends to be a bit complicated and tricky, you need to calculate checksum and know correct initial baud rate and other things. I know how to do this for SIRF and gtk devices, I don't know how for ublox, I never needed to do it for my ublox, and the instructions are not obvious. Someone else will know.

SD card connects to Uno by SPI. No problem there.

GPS, computer/serial monitor, and RS232 shield (?) all each need serial port. Uno has one serial port. You will need 2 softwareserial connections, which is apparently unreliable, or mega arduino with 4 serial port, or some other work-around.

Sorry, that was poorly worded. There is a ublox configuration software that will allow me to set the ublox gps module to output only NMEA. I attempted to use my arduino uno as a FTDI to usb adapter (removed the atmega32 and plugged into pins 0 and 1). I don't think this method worked, so I wasn't able to configure the module properly. The FTDI to usb cable I mentioned should allow me to configure the gps module correctly. Does this sound correct?

Using multiple SoftwareSerial's was my worry. So it sounds like placing the final product on a Mega would allow me to use all the sensors because it has 4 serial ports.

Also, I will not need to use usb while the device is running. The rfid and gps will store data to the sd card. The usb will only be used to upload the code. Will I still need 2 software serial ports? I should only need 1 for the rfid and 1 for the gps.

Solve one problem at a time. If you get a proper TTL-Serial COM port adapter and attach it correctly, the U-Center software package WILL be able to configure the GPS module in any way allowed by the manufacturer.

I can connect all my gps devices to pc using usb-serial adapter $4 gadget.

The issue might be, whether you can save the configuration change on the gps device, or if you have to make the change every time you use it. Some of mine don't have any eprom or backup battery, they need the configuration change every time it is powered up. Which is not a problem though, because the arduino does it.

I have an adapter ordered, so I should be able to configure it soon.

My device does have a battery on it.

they need the configuration change every time it is powered up. Which is not a problem though, because the arduino does it.

I'm not sure what you mean by this. Are you saying the arduino configures the protocol output automatically? From what I've understood, the arduino does not program settings like this for the gps.

It does if you program it to do so.

Are you saying the arduino configures the protocol output automatically?

That is exactly what it does. Only one of my gps devices has a battery. The others have to be configured every time I run them. It isn't "automatic", thats the point. When the system is powered up or reset, the arduino starts the serial port which the gps is connected to, and sends a command string to the gps to change the baud rate from 9600 to 38400, and sends another command string which sets the nmea messages I want, and how often to send them.

Has anyone tried with SPI communication?