[time-nuts] Thunderbolt Rollover Testing
qb4 at comcast.net
Sat Mar 4 21:45:02 EST 2017
In order to test the changes I've made to the ntpd reference
implementation's palisade driver (to add support for newer Resolution
boards) I obtained all of the receivers the driver currently supports,
along with a Spirent GSS6100 simulator.
While looking over the manual for the Thunderbolt I noticed that its
adjusted GPS week rollover will happen this year, so I decided to test
that first since I didn't see any reports of anyone (successfully)
implementing a test for it. I used a Thunderbolt with app 3.00 & core
10.02 that has a rev D DS1620 and 37265 oscillator. The simluator and
receiver were warmed up for 2 weeks prior to testing. The simulator
was configured with a geostationary orbit so that the receiver
estimated error reports could be used without any processing. I set
the simulation start time for about 30 minutes before the week 936
rollover to give the receiver some time to tune.
Ladyheather was used to monitor the unit with auto-rollover
compensation disabled. I was able to observe the rollover with this
setup, and the receiver's estimated errors were stable for about 2
hours after the rollover, even though the simulator's OCXO isn't that
great. The TB's PPS output was delayed by 12 to 16ns from the
simulator's PPS output (after subtracting the TB's estimated error).
Two hours after rollover the TB thinks the ephemeris expires and, due
to a problem with the simulator, the week number jumps ahead by 7. I
had set the navigation message to indicate an ephemeris transmission
interval of 24 hours but it seems the Thunderbolt always expects a 2
hour interval even with the fit interval flag set. Once the TB stops
using the old ephemeris data it reverts to the almanac orbital
parameters (which can't describe a geostationary orbit) and goes into
I verified with a Novatel Superstar that as soon as week 935 ends the
simulator incorrectly adds 7 to the week number, but the TB doesn't
notice this jump until it thinks the ephemeris has expired. It seems
like there is a bug in the simulator firmware where weeks with certain
bit patterns don't increment properly. I have the latest firmware,
but I don't have a support contract so I can't check with Spirent if
this is a known issue. The simulator does not support ephemeris
cutovers, or even changing anything in the navigation message in
realtime, so I dont know if I can improve this test.
Two runs of LH monitoring the unit can be found at
I'll test the week 1024 rollover soon.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 348524 bytes
Desc: not available
More information about the time-nuts