[time-nuts] GPS week rollover

Wed May 6 19:50:14 UTC 2015

Hi Pete,

I didn´t test the transition - I just entered a few dates 
well after the rollover. After locking, the phase of the 10 
MHz output was stable against the phase of the 10 MHz REF 
out of the signal generator I used for testing, which was 
what I expected. The 1 PPS looked "reasonable".

I´m not aware of a way to set a date manually for the Tbolt.

I have to admit that I use the thunderbolt different from 
many other list members: I switch it on from time to time to 
check the OCXO which I use as a common reference for my 
counter, spectrum analyzer, some generators etc. against it. 
If the frequency error is in the range of 1e-9, this is more 
than sufficient for me. So the output of date and time is a 
nice to have feature, but not really important for me.

Anyway, if there´s something you´d like me to test with the 
simulator, just let me know.

Best regards,

Matthias

Am 06.05.2015 um 16:39 schrieb Pete Stephenson:
> On Wed, May 6, 2015 at 3:39 PM, Tom Van Baak<tvb at leapsecond.com>  wrote:
>> Hi Pete,
> Hi Tom,
>
>> 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
> That's the link I included in my message. :)
>
> I'm quite grateful for Matthias's work with the GPS simulator, but I
> was unclear about a few details. For example, he doesn't mention if
> tested the Tbolt as it transitioned over the overflow point itself (to
> tell if the Tbolt will maintain continuity and keep working as
> expected) or if he tested it by setting the date on the simulator to
> dates before and after the overflow point. Similarly, it's unclear if
> manually priming the Tbolt with the current date/time will allow it to
> determine the correct epoch or if it will simply use the 1997-2017
> epoch baked into the firmware regardless of user input.
>
>> 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.
> Excellent, particularly regarding 1 PPS and 10 MHz outputs. It'd be
> nice if the unit itself would output the correct date rather than
> needing to rely on external software to interpret and correct the
> output.
>
>> 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).
> Excellent.
>
>> 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).
> Ouch. No fun at all.
>
> Hopefully more modern receivers are more clueful about handling
> rollovers. At minimum, they should accept user input telling them what
> the current epoch is.
>
> Cheers!
> -Pete
>
>> ----- 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
>> _______________________________________________
>> time-nuts mailing list --time-nuts at febo.com
>> To unsubscribe, go tohttps://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>