How to find when GPS is 'locked on'

Hi,

I have an arduino project that includes a GPS module. I like to log the date and time in the log file when the power is connected. the problem is that if the module isn’t battery backed I have no way of knowing when the date and time data is valid.

Currently I check the GPGGA for the field that specifies number of satellites in view, I make the assumption (dangerous, I know) that if the GPS module can see satellites, then it must have picked up date and time. Is there a better way of doing this? and is there a way of doing it from the GPRMC sentence only?

I’m hoping for a method that will work with the LS32060, SR-92 and the GPS Ultimate from Sparkfun.

thanks

You could look at how TinyGPSPlus determines that it has valid data to work with.

Read the "valid flag" of the $GPRMC sentence.

You could look at how TinyGPSPlus determines that it has valid data to work with.

As far as I can tell (maybe wrong) it checks that it has managed to read some data, rather than checking it's actually locked on to anything.

Read the "valid flag" of the $GPRMC sentence.

Thanks - I had looked at the 2nd field of this record before, but the link you supplied is a lot more clear on what it actually means!

Thanks

Just a quick update for anyone who's interested. I've just finished monitoring the output of a GPS, it get's the time right after about 10 seconds (even before it claims to spot any satelites). About a minute later it updates the date (but gets it wrong), then about a minute after that it updates the date (and get's it right this time) then another view seconds later it updates the lat and long and set the 'valid flag' on the RMC sentence.

Cheers

Doesn't the Ultimate GPS have a 'fix' signal pin for just that purpose?

Currently I check the GPGGA for the field that specifies number of satellites in view, I make the assumption (dangerous, I know) that if the GPS module can see satellites, then it must have picked up date and time. Is there a better way of doing this? and is there a way of doing it from the GPRMC sentence only?

The NeoGPS library will merge the information from both sentences (and others!) into a coherent fix data structure, along with valid flags for each piece of information, including status, date, time, and satellites. Besides being much faster and smaller than other libraries, you can configure it to parse any or all of the supported messages.

Here’s some typical code for what you describe:

NMEAGPS gps;
gps_fix fix;

void loop()
{
  if (gps.available( gps_port )) {
    fix = gps.read();

    if (fix.valid.date && fix.valid.time && fix.valid.status && (fix.status >= gps_fix::STATUS_TIME_ONLY)) {
      Serial << fix.dateTime; // format: "YYYY-MM-DD HH:MM:SS"
      Serial.println();
    }

The valid flags would reflect what you are seeing in the raw NMEA sentences. You could also check the satellite count, or whether the location field is valid yet:

    if (fix.valid.satellites && (fix.satellites > 3))

…or

    if (fix.valid.location)

The fix structure returned from gps.read() contains a merged set of GPS fields, from all the messages you have enabled (see this table). If you only enable the RMC, it will only contain fields from that message. All other fields will be marked as NOT valid.

Several users have switched to my library and have typically saved thousands of bytes of program space and hundreds of bytes of RAM. :o

NeoGPS can also be used in conjunction with my Neo–Serial libraries in an interrupt-driven mode for even more efficiency and immunity to other libraries that block (e.g., SDFat).

You may also be interested in NeoSWSerial, a more-efficient replacement for SoftwareSerial. It only supports bauds 9600, 19200 and 38400, but it does not disable interrupts for long periods of time. It can also transmit and receive at the same time. If you have pins 8 & 9 available for the GPS device, it would be even better to use AltSoftSerial.

Cheers,
/dev

Doesn't the Ultimate GPS have a 'fix' signal pin for just that purpose?

I have the same project that runs on several hardware setups, each with a different GPS - I would prefer a solution that isn't hardware specific.

Now that I understand a bit better the 'valid flag' i think I it will be fine. The reference that I originally used to understand the NMEA sentences was a bit vague about the exact purpose of this field, so I'd never used it properly.

Thanks everyone.

Fulliautomatix: I have the same project that runs on several hardware setups, each with a different GPS - I would prefer a solution that isn't hardware specific. ...

I get that. I am a physical scientist, so I like hardware solutions.