GPS week rollover can be a problem on older surplus timing gear that is still in operation. The user may have to reset the unit after a rollover, or deal with an incorrect date display. As the Tria GPS module I am designing is meant for use in just such a unit, the Lucent KS-24361, I decided to do some experimentation on the rollover issue with this box. The Tria GPS has a simple text-based user interface over a serial UART, so I added a GPS week rollover simulation to the available options. After this is selected and the unit is power cycled, the GPS module fast-forwards the date and time to 30 minutes before midnight, April 6th, 2019 to simulate the next rollover.
I used a REF-0 for these tests.
Tria GPS warning the user that the simulation is in progress.
Here's the view in SatStat.
Synchronized to GPS time all right... 4 years in the future.
Simulating this on my board is actually very easy to do. I have complete control over the Oncore serial strings and what I send the GPSDO, so changing the date is just a slight modification to the initialization routine.
As the time approached "midnight", I connected to the U-blox LEA-6T module in u-center and ended the automatic survey early. This way, we could hit midnight in normally operating conditions. Being able to modify GPS settings in u-center is a really nice feature of the Tria GPS.
Changing GPS configuration settings in u-center, and seeing the results in SatStat.
For this simulation, I programmed the module to roll the date back to August 1999 at midnight. That, of course, was when the last rollover occurred. Here I am simulating a GPS module that was built between the rollovers and can't display dates beyond April 6th, 2019.
The simulated rollover just occurred. Will the REF-0 handle it ok?
Well, as you may have expected, nothing dramatic happened. I have found the KS-24361 units to be very tolerant of date/time "mishaps". They simply reset their internal clocks after a minute or so when a significant change occurs on the date/time presented in the serial strings. After the rollover, the unit displayed the wrong date, but never threw an alarm or lost lock.
The REF-0 continues to operate normally after the rollover. However, it now shows
the incorrect date that is being sent to it.
If I can inject a problem with the Tria GPS, I can also fix the problem. U-blox modules handle GPS week rollover pretty well, and of course the RTC in the Tria GPS understands more than 1024 weeks. So it's very possible to "fix" the rollover problem and just send the GPSDO the correct date after April 6th, 2019. I modified my simulation routine to do this with good results.
Here the Tria GPS and REF-0 have rolled over to April 7th 2019 with no ill effects.
This sent me on a quest to determine the actual date range supported by the KS-24361 firmware. Is it effectively unlimited, and the only limitation is the GPS module? Or is there some other date rollover we will eventually hit on these units? I simulated dates further in the future and went all the way up to 2038 with no issues. That's when I ran into the 2038 bug in the C time library I am using. Sigh...
We really broke the date on the Tria GPS and REF-0 trying to go past 19 January 2038.
But this is due to a very different rollover bug.
2038 is a long way off, so I'm not going to worry about that one right now.
By this point, dealing with leaps into the future, two different date rollover bugs, and the outer limits of the C time library had given me a headache. I was quite happy to reset the clock to the correct time and wrap things up.
Playing around with GPS week rollover simulation was an interesting experiment. In the end though, the Tria GPS makes the whole thing a non-issue. One of the many benefits of upgrading to a modern GPS receiver from the Oncore UT+ receivers is that we can better handle things like GPS week limits and leap seconds. This should keep old GPSDOs operating well past the next "rollover".
Thanks for reading!
- Dan W.