[time-nuts] Trimble Thunderbolt no longer determines the correct date

[Mike Cook]

Unfortunately I did not have the log activated. 

Although I did not see a phase shift I think that that may be just luck as looking back at the screen print of tboltmon 1 sec after the roll, I see that the DAC voltage changed by +0,00533mV from the value 10mins prior to the roll. My antenna is not positioned optimally so I am used to seeing occasional 40-200ns phase offsets due to multi path. My phase shift before rollover (-9min) was -118ns and drifting toward 0. The Tbolt and only been powered on 4Hrs prior to rollover but was in position hold and had a good almanac.  At rollover +1s it was 50,52ns and at 41secs after rollover the offset was 127,66ns so I didn’t think it unusual. Looking at it again, I see that the 10MHz frequency offset was 0,10ppb prior to the rollover , but 2.01ppb at +1s , so it looks like I did get a glitch, but one of lesser magnitude than you reported.



> Le 30 juil. 2017 à 16:18, Tom Van Baak <tvb at LeapSecond.com> a écrit :
> 
> Hi Mike,
> 
>> I was running Tboltmon as the rollover occurred and did not see any phase shift.
> 
> I'm pleased you saw no phase shift at all. Did you happen to have a TBoltmon log running?
> 
>> Maybe your phase offset was due to your Tbolt being in survey mode and its apparent position shifted . 
> 
> The particular TBolt I used for the screen capture was powered up too soon before GPS midnight for the survey to complete. So I just entered the coordinates manually before the photo-op.
> 
> But if you look at the two images again, the phase shift may be due to a change in DAC value. My theory at this point is that the DAC voltage calculation includes at least one component based on slope; and slope implies elapsed time interval. A calculation like that would be upset if the underlying time frame changes by -1023 weeks instead of +1 week, or -7168 days instead of +1 day, etc. Or maybe the TBolt reset on rollover and went back to a previously saved DAC value. I don't know. But for those of you making your own GPSDO, keep subtle details like this in mind.
> 
> The duration of the recovery depends on the time constant. Notice that Mark uses a 500 s time constant and I used the default (100 s), so my TBolt recovered much quicker than his. I'll have more info as I sift through several TBolt's.
> 
> /tvb
> 
> 
> ----- Original Message ----- 
> From: "Mike Cook" <michael.cook at sfr.fr>
> To: "Tom Van Baak" <tvb at leapsecond.com>; "Discussion of precise time and frequency measurement" <time-nuts at febo.com>
> Sent: Saturday, July 29, 2017 11:47 PM
> Subject: Re: [time-nuts] Trimble Thunderbolt no longer determines the correct date
> 
> 
> Hi,
>  I was running Tboltmon as the rollover occurred and did not see any phase shift. Old type Tbolt firmware 3.0
> Maybe your phase offset was due to your Tbolt being in survey mode and its apparent position shifted . 
> 
> Mike
> 
> 
>> Le 30 juil. 2017 à 02:16, Tom Van Baak <tvb at LeapSecond.com> a écrit :
>> 
>> Caught it. Some Trimble Thunderbolt TBoltmon.exe screen shots attached:
>> 
>> GPS WN 1959 TOW 604799 (July 29, 2017 23:59:41) advanced to
>> GPS WN 936 TOW 0 (December 13, 1997) instead of
>> GPS WN 1960 TOW 0 (July 29, 2017 23:59:42).
>> 
>> 1960 - 936 is 1024 weeks, as advertised for this version of the TBolt GPSDO. Note this happened at 23:59:42 UTC as expected (that's GPS midnight - 18 UTC leap seconds). I did not expect the reported 2.75 us 1PPS phase change and will look into that.
>> 
>> /tvb
>> <tbolt-20170729T165941.gif><tbolt-20170729T165942.gif><TBoltrollover.gif>
> 
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw