[time-nuts] GPS week rollover

[Tom Van Baak]

Hi Pete,

Yes, we are very fortunate that a fellow time-nut took the time to test a TBolt with a GPS simulator:
https://www.febo.com/pipermail/time-nuts/2014-September/086664.html

He also reported that the 1 PPS and the 10 MHz were undisturbed by the rollover. Yes, the date/time gets set back but Mark Sims updated Lady Heather to compensate. So as far as we know, all is well with that GPSDO in 2017 and 2019 and beyond.

Note also that the TBolt handles rollover in a deterministic way and thus lends itself to epoch correction (since it's based on GPS time).

The problem with the TymServe is that, unless they release the source code for the broken algorithm, its handling of epochs is not deterministic (since it's based on the count of leap seconds and can hop forward or back 1024 weeks without warning).

/tvb

----- Original Message ----- 
From: "Pete Stephenson" <pete at heypete.com>
To: "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
Sent: Wednesday, May 06, 2015 5:19 AM
Subject: Re: [time-nuts] GPS week rollover


> On Wed, May 6, 2015 at 6:48 AM, Mark Sims <holrum at hotmail.com> wrote:
>> Well,  a big one will be in 2017 when all our Tbolts roll over.    I have included some code in the next version of Lady Heather to compensate.  If it detects a year from the unit before 2015,  it converts the date/time to Julian,  adds 1024 weeks worth of seconds,  and then converts the date/time back to Gregorian.  You can also specify a user defined rollover adjustment (in seconds).  One issue that I have seen is the Tbolt occasionally spitting out a bogo-year and triggering a false/premature rollover...  still trying to track that down.
>>
>> People using Tbolts for things like NTP servers will have to implement a similar fix...
> 
> I assume the Tbolt rollover will be problematic for those who start
> their Tbolt completely cold (no time, almanac, or ephemeris) and
> without any non-GPS input, but how will the Tbolt behave in situations
> where the user initializes the Tbolt with the then-correct
> post-rollover date and time? For example, one might use Tboltmon and a
> wristwatch to set the approximate time on the unit and then let it
> figure out the precise time from GPS.
> 
> Also, will the rollover cause time-of-day problems for running Tbolts?
> That is, would they "ride through" the rollover and continue to
> provide the correct date and time as expected (that is, they recognize
> that a rollover occurred and keep working normally so long as they're
> not cold-reset) or would they immediately jump back to December 14,
> 1997 (the Thunderbolt "zero" date)? According to
> <https://www.febo.com/pipermail/time-nuts/2014-September/086664.html>
> it looks like they'll output the incorrect date as they cross over the
> rollover point. That's not good.
> 
> -- 
> Pete Stephenson