Gps data incomplete?

Using Arduino Programming Questions
#1

Hiya, im using a neo 6m-0-001
unit connected to an uno board
using windows 7
the most up to date IDE
and the following code

#include <SoftwareSerial.h>
#include <TinyGPS.h> //credit to mikal hart

long lat,lon; // create variable for latitude and longitude object
 
SoftwareSerial serial(2, 3); // create gps sensor connection
TinyGPS gps; // create gps object
 
void setup(){
  Serial.begin(9600); // connect serial 
  serial.begin(38400); // connect gps sensor

 Serial.println("Position: ");
}

 
void loop(){
  
  while(serial.available())
  { 
   char c = serial.read();
   Serial.print(c);
 
   
  } 
}

the problem:
im getting data, correct data, infact, the gps co-ordinates are more accurate than those that i get from my phone, the problem is, i dont seem to be getting enough data according to the format for the NMEA sentence being output

this is pretty much what im getting each time on the serial monitor
$GPRMC,174216.00,A,5339.53122,N,00147.55636,W,0.094,081114,A,

heres an example of what i should be getting from a GPRMC sentence

eg3. $GPRMC,220516,A,5133.82,N,00042.24,W,173.8,231.8,130694,004.2,W*70

1 220516 Time Stamp
2 A validity - A-ok, V-invalid
3 5133.82 current Latitude
4 N North/South
5 00042.24 current Longitude
6 W East/West
7 173.8 Speed in knots
8 231.8 True course
9 130694 Date Stamp
10 004.2 Variation
11 W East/West
12 *70 checksum

taken from here: http://aprs.gids.nl/nmea/#rmc

i seem to be getting clusters of commas with no information in between them, any clues?
any questions, let me know

#2

SeanHowson:
$GPRMC,174216.00,A,5339.53122,N,00147.55636,W,0.094,,081114,,,A,

Empty fields are not necessarily a problem. But your string doesn't have a checksum at the end. That's a problem. It looks like your code is dropping characters.

It's due to a mismatch in the soft serial input (38400 baud) and the serial monitor output (9600) baud. It can't possibly keep up since an RMC string is something like 80 bytes and the Software Serial RX Serial TX buffer is only 64 bytes. You could buffer it yourself instead of echoing it immediately.

In any case, you should set the Serial output to the monitor to as high as possible, probably 115200. Even doing this I couldn't get it to work with the GPS transmitting at 38400 or even 19200. I had to use 9600 baud. I think the problem is that the Arduino supplied Software Serial library hogs the processor so completely that there's no time left for much of anything else. At 9600 baud it uses over 95% of the bandwidth while receiving. At higher baud rates it's worse. You may have to accept 9600 baud for the GPS.

I solved the problem for myself by writing my own soft serial code. Now I can receive GPS at 38400.

#3

I would suggest that whether or not is causes a problem it is very unwise to have an instance of SoftwareSerial called serial. At the very least it will cause confusion with the hardware Serial.

#4

jboyton:
Empty fields are not necessarily a problem. But your string doesn't have a checksum at the end. That's a problem. It looks like your code is dropping characters.

It's due to a mismatch in the soft serial input (38400 baud) and the serial monitor output (9600) baud. It can't possibly keep up since an RMC string is something like 80 bytes and the Serial TX buffer is only 64 bytes. You could buffer it yourself instead of echoing it immediately.

In any case, you should set the Serial output to the monitor to as high as possible, probably 115200. Even doing this I couldn't get it to work with the GPS transmitting at 38400 or even 19200. I had to use 9600 baud. I think the problem is that the Arduino supplied Software Serial library hogs the processor so completely that there's no time left for much of anything else. At 9600 baud it uses over 95% of the bandwidth while receiving. At higher baud rates it's worse. You may have to accept 9600 baud for the GPS.

I solved the problem for myself by writing my own soft serial code. Now I can receive GPS at 38400.

jboyton:
Hiya, thanks for your reply, i had seen someone earlier in the day who had infact reconfigured the ublox chip to run at a lower board rate using a hexadecimal code generated by the ucentre software, i may give this a go, as it would coincide with the problem youve outlined, (baud rates in general) mainly, i plan to pare the date leaving myself with only time, lat & lon but the code seem to be struggling to recognise the sentence structure because of the current problem, do you think its worth trying to reconfigure the ublox cheap upon startup, or should i develop a buffer? how would you go about coding the buffer?
Thanks again for your help
Sean

#5

mmm im getting even less data come through at the highest serial baud rate

#6

SeanHowson:
mmm im getting even less data come through at the highest serial baud rate

I think the same thing happened to me. I'm not sure why.

It might be possible to buffer the incoming data at 38400 so that you can send it back out in between bursts of NMEA strings, depending on the number and frequency of the strings. Or you can send it a command to slow it down.

#7

Hiya

after a bit of research im looking at using the ucentre to generate a hex code i can write to the 6m chip to alter its baud each time the program is run (not a permanent measure it will still default to 38400 upon start up) going to try this, then try the buffer.

Ill let you know if i get anywhere, feel free to PM me if you do too :slight_smile:

#8

I played around with SoftwareSerial a little bit last night. At 38400 baud I could not get it to receive all the characters even with an RX buffer of 1024. Finally I was successful when I turned off the timer0 overflow interrupt while receiving characters and then disabling SoftwareSerial receive when I echoed the characters to the serial monitor. Even with all of that it wouldn’t work unless I was only sending one or two NMEA sentences per second.

I timed the SoftwareSerial receive ISR. It took 254us (+/-2us). That doesn’t count the 2-3us it takes to enter/exit the ISR and push/pop registers. A character at 38400 comes every 260us. So that only leaves about 5us or so to do anything else. The timer0 overflow ISR takes about that long. You can see the problem.

The SerialSoftware code supports baud rates up to 115200. I don’t understand how that could possibly work.

It’s definitely worth learning how to send commands to the GPS. In addition to baud rate you may want to change which data strings are sent and how often.

#9

Hiya

thanks for having a look into, its nice to get a reply several days after the original post, annoyingly at the moment im not having a lot of time for the arduino (electronics student) I've plenty of other work to keep me going, it there any chance you could possibly post up or PM me the most successful code you had with mild annotation if possible, i'd be very grateful, i had almost got the gps to shift its baud from 38400, though it went back to throwing out ASCII code, which usually suggests incorrect baud matching -_- nevermind, either way, thanks for your help, hopefully i'll find some time for it this weekend!
Thanks again
Sean

#10

I’m not sure what you’re looking for exactly. I don’t have the same GPS as you so the command protocol is probably different.

One thing that could be happening to cause your GPS to reject the baud rate command is if it’s sending data at too fast a rate. That is to say, you might have to first tell it to send fewer NMEA strings per second before it will allow you to reduce the baud rate.

Another approach is to replace SoftwareSerial. There is a library you can find on github called AltSoftSerial that may allow you to use your GPS at 38400. I have not tried AltSoftSerial because it only works with certain pins for RX/TX so I’d have to hack my GPS shield. It also uses timer1 (on an Uno) which I’d rather have free for other purposes. I wrote my own soft serial code to get around these problems.

#11

Did u find a solution?I m also having this issue.My checksum is correct and I m using 9600 br.
nmea feed is like this.
...
$GPRMC,102641.00,A,0653.38117,N,07953.52534,E,0.649,,290817,,,D7A
$GPVTG,,T,,M,0.649,N,1.202,K,D2C
...

My lon-lat values are correct.But can't get direction

#12

pManu:
My lon-lat values are correct.But can't get direction

You may not, the GPS needs to be moving .........

#13

The GPS is supposed to do that. If it doesn't have the information, the field is empty. If you're not moving, the speed or heading fields may be empty. If you don't have a satellite fix, the lat/lon and altitude fields may be empty.

My NeoGPS library has valid flags for each GPS field so you can tell if the field was empty. Read more here. NeoGPS is smaller, faster, more accurate and more reliable than all other GPS libraries. If you want to try it, NeoGPS is available from the Arduino IDE Library Manager, under the menu Sketch -> Include Library -> Manage Libraries.

#14