Wrong Time Stamp from GPS GGA Sentence?

[AlexP1]

Hello Everyone,

Today I made a short program to interface with a GPS antenna over the serial port, and parse the incoming strings.  That part seems to work great.  However, when I decode the GGA sentence to retrieve the UTC time (hhmmss.ss) and try to convert it to a time stamp, the value seems off. 

First, when I'm watching the UTC time count up, one second of displayed time is longer than 1 second of me counting out loud.  Counting out loud isn't super accurate, I know, but it takes almost 2 seconds of real time to pass before 1 second updates on the display.  Not sure why.  I'm thinking it has something to do with my loop timing?  The expected sample rate coming from the antenna is 5 hz.  I have a wait function built into the program to time the loop, and if I try any value I try besides 200mSec, then the sentences don't read correctly at all.  Am I getting data correctly by setting a wait function, or should I be doing something else. 

Also, the time just doesn't match up with my computer time at all.  When I first ran it, it was like 10 minutes fast.  But I let it run for a little while and now it's 1.5 hours fast.  I'm not sure if it jumped to that time, or worked it's way up.  Either way, if the seconds truly are updating slower than 1 second of real time, I'm not sure why the timer is fast? 

I'm pretty confused at this point.  This is my first time using GPS, so if anyone with some experience could help, I'd appreciate it. 

Thanks,
Alex 

[mikeporter]

Which of the values is wrong, the value in time, or the value in timestamp? It seems very unlikely that GPS is going to be using the same zero-time as LV does. The function you are using to generate a timestamp assumes the number in is the number of seconds since midnight, Jan1, 1904.

What is the format of the "Time " value? I am not familiar with the GGA sentence, but I have parsed the GPRMC sentence and the time field in that message is a six-digit value: two digits of hours, two digits of minutes and two digits of seconds.

Mike...

[Weiyuan]

Some suggestions:

1. only when the GPS is getting satellite signal, can it output a correct time.

2. make sure you set the output of GPS is UT, not local time, day time saving time etc.

3. use the original software to test the GPS first, see if you can get a correct time.

4. use windows Hyper Terminal to test the commands, before using labview to control it.

[mikealder]

Have a read through:

 http://forums.ni.com/ni/board/message?board.id=170&message.id=227405&query.id=16213#M227405 

Which has an example showing the method I use to read GPS information, I was using Bluetooth, but you can easily substitute the serial port front end, there is also a link to a document by Garmin which is a very handy guide to parsing the sentences. - Mike

Message Edited by mike alder on 11-08-2007 02:40 AM

[AlexP1]

Ok, thanks for the quick responses everyone.  I will try to weave together replies to some of your comments, as well as talk about a discovery I made. 

As far as my system goes, I actually have a Blue Tooth unit communicating over the serial port.  It works great through Hyper Terminal, as I can use it to retrieve NMEA sentences just fine.   The VI I made with Labview retrieves the sentences just as well, so I know I am communicating with my antenna.  I know I have a lock on several satellites, because I can get that information from one of the sentences.  The UTC time it provides, in the format hhmmss.ss (similar to your GPRMC Mike), seems correct.  It matches my system time within a minute.  So I am pretty confident with the system setup.

That being said, I made a discovery this morning that might point to the problem.  Right now I am retrieving 2 sentences from the GPS unit: GPGGA and GPVTG.  When only pulling in the GPGGA sentence into Labview, the UTC time seems to be updating as I would expect.  Every time I count one second of time, the UTC time changes by one second.  Great!  Then I programmed the GPS unit to start outputting GPVTG sentences in addition to the GPGGA sentence.  Now when I look at the UTC time, it takes longer than 1 second real time to update 1 second of UTC time.  I hope that makes sense.  So it seems like when I pull in two sentences at a time, the system slows down.  Is this a VISA read error or something?  I don't know where the problem really could be.  This seems like the main issue. 

Otherwise, the second problem I have, is actually converting the GGA time value to a Labview timestamp.  Right now I just have the UTC value (hhmmss.ss) feed into a "to Time Stamp" function within Labview.  I'm not sure that is the correct way of going about it though.  I guess I'm not even sure where a date value comes into play either? 

Anyways, hope you can guys can see something here that I am missing. 

Thanks again. 

[falkpl]

The Time stamp needs a date and time to work I us theGPRMC which has both a date and time UTC.  Here you can cluster the data parse it first into Month Day Year Hour Minuit Second and fraction of second and call the DATE/TIME TO SECONDS VI to convert to a labview time stamp.  I have done this with several Garmin units and all seems to work well.  You can just use the GGA and display the UTC it is easier but there are reasons that the dare is significant then use the first method described.

Paul 

[mikealder]

What GPS device are you using and have you set it up so it will update at 1Hz for each of the NMEA sentences it outputs? It is quite possible the second line you have introduced is only set to output its data every two or three seconds hence the delay you see while the application looks for the syntax match - Mike

[Brian_Beal]

If I read your description correctly, the seconds are incrementing by one, but just not every second.  If that is the case, then somehow the messages are building up in a buffer somewhere.

[AlexP1]

The device is called SXBlue GPS by Geneq.  Here is a URL:
http://www.geneq.com/catalog/en/sxblue.html

Right now I have it set up so that both the GGA and VTG output at 5 hz.  I tried changing the setup so that GGA would output at 5hz, and VTG at 1 hz.  When I ran the program, the time value from the GGA sentence ran a specified interval, but when the VTG sentence came up, the GGA time value paused ever so slightly.