I have a clock project that uses a GPS module (Neo6m) and an RTC module (DS3231) running on an Uno. When the project starts up it is reading the correct time from the RTC module and displays that. When it has established contact with at least 3 satellites it is using the GPS time to set the RTC module's time once a second. It works great! I can get the time to perfectly (by eye) sync with the blinking LED on the GPS module by adding a tiny negative delay to compensate for the internal processing.
But I have noticed something really odd. Sometimes (not always!) when it first establishes contact with the satellites the time is EXACTLY 3.0 seconds OFF (I am in the US if that makes a difference). After a few minutes it gets the proper time from GPS and it is in full sync with correct time. Does anyone know what this is all about? I have seen this multiple times and I would love to understand more about the black magic behind GPS. Thank you!
Its not odd at all and its related to how GPSs deal with the slowing down of the Earths rotation. GPS time actually is based on the time in early 1980. The atomic clocks in the system are synced to that time.
But since 1980, as the Earth has been slowing down in rotation, more leap seconds have been added so that the view of the universe from Earth stays the same at a specific Earth time. There are currently 17 leap seconds to add to GPS time to make it UTC.
The GPSs firmware will likley have the leap seconds value applying at the time it was programmed so could well by now be out of date.
To correct this issue the current value of leap seconds is sent from the satellites as a navigation message which goes out every 12.5 minutes.
So its quite normal for the time sent out by the GPS to be some seconds at startup although most people incorrectly assume its always UTC.
srnet:
Its not odd at all and its related to how GPSs deal with the slowing down of the Earths rotation. GPS time actually is based on the time in early 1980. The atomic clocks in the system are synced to that time.
But since 1980, as the Earth has been slowing down in rotation, more leap seconds have been added so that the view of the universe from Earth stays the same at a specific Earth time. There are currently 17 leap seconds to add to GPS time to make it UTC.
The GPSs firmware will likley have the leap seconds value applying at the time it was programmed so could well by now be out of date.
To correct this issue the current value of leap seconds is sent from the satellites as a navigation message which goes out every 12.5 minutes.
So its quite normal for the time sent out by the GPS to be some seconds at startup although most people incorrectly assume its always UTC.
WOW! What an amazing answer! It is hands down the best answer on here I have seen in a long time. Keep up the great work!! Thank you very much for helping me understand the reason behind this!
gfvalvo:
That seems excessive. Much less often would be sufficient.
That is a good point and I was reasoning like that too in the beginning. But then I changed my mind and let me explain why as I think it is important to see this from the other side.
The time from my RTC modules drifts by about 2 seconds per week. This is within the spec and normal. Assume we update the time once per week. That would mean we would see a time jump of 2 seconds at some point (not likely we would see it as we could do this at night if we want to). Let us assume we do it once per day instead. Then we are less likely to see it happen (0.2 second correction or something like that). But, and this is key, setting the time once every second does not cost anything as the only function of this circuit is to show time. So I can either do nothing or set the time. Then, why not set the time to ensure it is always in sync with the flashing LED. Because even a 0.2 second offset will be noticeable if you compare the time shown with the flashing LED (time is shown with seconds and updated on the second). Sure, I am not saying I don't suffer from OCD... if the LED is blinking in sync with correct time, why not align the time with it to avoid OCD situations all together ...
In that case, you don't even need the RTC. Just keep time using the standard TimeLib.h library -- it uses millis() for its time reference. Then true it up as often as you like with GPS time.
gfvalvo:
In that case, you don't even need the RTC. Just keep time using the standard TimeLib.h library -- it uses millis() for its time reference. Then true it up as often as you like with GPS time.
That is true also. However, I was thinking about your first comment about the update frequency some more.... And there is one aspect of this that I never thought about - limited write cycles on the DS3231 module (EEPROM/NVRAM?). That would be a very good reason for not updating the time every second.... Thank you for bringing my attention to this again as I never did think this thru.
As for not using an RTC. The only reason I am not doing that is that the UNO does not know what the time it is when it is turned on. So I would have to wait for the GPS fix and that could be several minutes (12.5 minutes if you want correct leap seconds as mentioned here). And the DS3231 modules are so in-expensive that it is no problem to include them as it gives you the correct time at boot-up.
amaruk:
So I would have to wait for the GPS fix and that could be several minutes (12.5 minutes if you want correct leap seconds as mentioned here).
Oh dear.
Maybe you dont understand the full implications of the leap seconds update which only occurs once every 12.5minutes.
How can you be really sure its been received and decoded correctly ?
GPS reception is not guaranteeded at all.
If at the exact time the leap seconds update navigation message goes out, someone walks in front of the GPS or there is electrical interference, both of which could harm GPS reception, the GPS might not pick up the leap seconds update.
Maybe you dont understand the full implications of the leap seconds update which only occurs once every 12.5minutes.
How can you be really sure its been received and decoded correctly ?
GPS reception is not guaranteeded at all.
If at the exact time the leap seconds update navigation message goes out, someone walks in front of the GPS or there is electrical interference, both of which could harm GPS reception, the GPS might not pick up the leap seconds update.
Well, I just tried to make the argument that the GPS fix time is not instant hence the need for RTC. I only update the RTC if I receive a time from the GPS module (updated and correct). Time is taken from RTC at all times. The only issue I have had is the 3 second problem mentioned here and the reason for that seems to be that it is not updated twice per second as the GPS time but only once every 12.5 minutes. Thus, in ideal situations in theory you would have to wait an average of (12.5/2) minutes to get the leap seconds updated correctly. But as you said, if you miss that, it can take much longer. As I rely on the RTC at all times it is not an issue. When testing my Arduino clock I experimented with this and I intentionally put it in a metal cage (microwave oven that was turned off!). When my clock has not been updated in a pre-defined time space I have a notification LED that indicates this.
The root cause of this seems to be that there is no way (that I have found) to tell if the leap seconds have been updated yet or not in the library I use for GPS (TinyGPS++). But it really is a non-issue, especially now that I understand what is going on.
But my next version is not going to update the RTC every second as discussed above. I am thinking once very 2 hours would be a happy medium. Thanks again!
amaruk:
The root cause of this seems to be that there is no way (that I have found) to tell if the leap seconds have been updated yet or not in the library I use for GPS (TinyGPS++).
The 'root cause' is that very few appreciate the problem in the first place.
I dont know of a GPS library that will tell you, for sure, if the leap seconds update has occured.
But still most GPS users assume that GPSs always put out UTC time and the reality is that they do not, end of.
gfvalvo:
Does the receipt of the leap seconds update cause the GPS receiver to output a special NMEA sentence?
There is a message, on Ublox GPS, that you can poll which will tell you if the leap seconds correction is active.
You might have thought that it would have been a good idea to have a flag in one of the standard sentences that indicated whether the time being displayed by the GPS was correct, i.e. the leap seconds update had been received.
The leap second correction that shows 23:59:60 is rare event. There have only been a handful since.
What we’re trying to learn is how to tell if the GPS correction built in has been further corrected to reflect the true number of leaps seconds, which it detects somehow and apples at some time around the time of staring up or initialising.
Or I am misreading this, which is always on the tab,e.
alto777:
The leap second correction that shows 23:59:60 is rare event. There have only been a handful since.
What we’re trying to learn is how to tell if the GPS correction built in has been further corrected to reflect the true number of leaps seconds, which it detects somehow and apples at some time around the time of staring up or initialising.
That is exactly my understanding too. It would be nice to have GPS library with a function like this that we could call to tell if the leap second correction has been properly received (which is only sent out every 12.5 minutes):
