I did a quick little experiment this morning. I wanted to see what happens to the NMEA data coming out of my GPS when it can't contact any satellites. To mask the satellites I put a shopping centre over my GPS receiver. Or, more truthfully, I parked my car in the car park below a shopping centre, then ran my GPS off my laptop.
On startup the GPS immediately spews out NMEA data, including the date and time. The date/time that it supplied initially was 2006-10-29 00:00:00.
What's the significance of that date? I can only assume it was the date the firmware was baked into the chip. But I suppose there could be a hundred other reasons for that date. Did the programmer have a baby in 2006 like we did? Who knows. Interestingly though, the μC defaulted to 2009-01-01 00:00:00. So when the program tried to set the system time to 2006, it failed. The system time was mismatched and not even the minutes value was correct. Amazingly the GPS locked on to the current time in about 60 seconds even with a shopping centre over it's head. I didn't stick around to see how long a position fix took (it was 09:00 and I didn't take a packed lunch)
The reason for this experiment is to answer the question "How do I know the GPS has the correct time?" You see, this process seems to occur on startup:
On startup the GPS immediately spews out NMEA data, including the date and time. The date/time that it supplied initially was 2006-10-29 00:00:00.
What's the significance of that date? I can only assume it was the date the firmware was baked into the chip. But I suppose there could be a hundred other reasons for that date. Did the programmer have a baby in 2006 like we did? Who knows. Interestingly though, the μC defaulted to 2009-01-01 00:00:00. So when the program tried to set the system time to 2006, it failed. The system time was mismatched and not even the minutes value was correct. Amazingly the GPS locked on to the current time in about 60 seconds even with a shopping centre over it's head. I didn't stick around to see how long a position fix took (it was 09:00 and I didn't take a packed lunch)
The reason for this experiment is to answer the question "How do I know the GPS has the correct time?" You see, this process seems to occur on startup:
- The GPS spits out some arbitrary time value (2006, as seen above). This could be for one second during a normal startup or for hours if you cold-started it underground.
- The GPS corrects its time value but does not otherwise indicate it has a lock on the correct time. A change of year might be an indicator of this event.
- The GPS emits the Valid code and begins to output location data.
So how do you know when the time is correct? The initial (garbage) value might be random. If it is some 'firmware date' then it's probably different for every make and model of GPS receiver. Who's to say a brand new model of receiver won't default to 2012-01-01? So a change of year or even year/month won't be a good indicator of the time being corrected. The pessimistic option is to wait until valid location data is produced, then you know you have a signal lock on the satellites. But I've seen this take 20 minutes for a cold boot indoors.
As much as I don't like putting assumptions and conditions on a program it looks like I need one here. I'm going to assume the GPS default date is before some arbitrary value, like 2012-01-01. A date before this value is "garbage data" from a GPS that has not locked onto a satellite signal. Any GPS datetime after this value is assumed to be correct. The worst case scenario here is that an old program with a brand new receiver will always accept the datetime value from the receiver even when it's at a startup default value. Then when the datetime is corrected, the program will time travel.
Today's first goal is to implement the above assumption and then datetime tag each NMEA sentence coming from the GPS regardless of if the sentence type includes datetime data.
That is all.
Comments
Post a Comment