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<[email protected]> 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"<[email protected]>
To: "Discussion of precise time and frequency measurement"<[email protected]>
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<[email protected]> 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 [email protected]
To unsubscribe, go tohttps://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
