[time-nuts] GPSDO TC

[Bruce Griffiths]

Hej Magnus

Magnus Danielson wrote:
> Bruce Griffiths skrev:
>   
>> Magnus Danielson wrote:
>>     
>>> Dick,
>>>
>>> Richard Moore skrev:
>>>   
>>>       
>>>> On Jan 8, 2009, at 2:58 AM, time-nuts-request at febo.com wrote:
>>>>
>>>>     
>>>>         
>>>>> Message: 6
>>>>> Date: Thu, 08 Jan 2009 11:51:50 +0100
>>>>> From: Magnus Danielson <magnus at rubidium.dyndns.org>
>>>>> Subject: Re: [time-nuts] GPSDO time constant
>>>>> To: Tom Van Baak <tvb at leapsecond.com>, 	Discussion of precise time and
>>>>> 	frequency measurement <time-nuts at febo.com>
>>>>> For ThunderBolt owners it is pretty straightforward to adjust the  
>>>>> TC and
>>>>> damping, which is very nice. Use this oppertunity!
>>>>>       
>>>>>           
>>>> So, Magnus (and Tom), what damping factor do you suggest for a TBolt?  
>>>> I'm running a verrry long TC now. If 1.2 is not actually critically  
>>>> damped, what value would be? Any guesses? BTW, I really like that  
>>>> plot of Tom's that tracks the oven and then gets better from the GPS...
>>>>     
>>>>         
>>> Assuming that damping factors match classical analysis of damping, then 
>>> the square root of 2 is the answer... 1.414 or there abouts.
>>>
>>> I would be more conservative than that. I would consider damping factors 
>>> such as 3-4 or so. I have no support from measurements on GPSDOs but it 
>>> is reasonable that the rise of gain at and near the PLL frequency we see 
>>> for other systems will occur and result in similar effects even here.
>>> This gain raises the noise floor and amount of gain is directly coupled 
>>> to the damping factor. It's just standard PLL stuff all over again. The 
>>> only difference is that we view the result in ADEV or MDEV views.
>>>
>>> Cheers,
>>> Magnus
>>>
>>>   
>>>       
>> Hej Magnus
>>
>> For a second order loop, the noise bandwidth is minimised for a fixed
>> time constant by choosing a damping factor of 0.5.
>> Using a damping factor of 1.414 increases the noise bandwidth by about 60%.
>> Using a damping factor of 0.7071 only increases the loop noise bandwidth
>> by about 6%.
>> A damping factor of 0.3 increases the noise bandwidth by about 13%.
>>     
>
> Yes, but the bump comes from the increase gain around the resonance and 
> spoils the OCXO/GPS cross-over. The simplified noise-bandwidth measure 
> does not really comply here since they usually build on a simplified 
> model of noise type (white noise - gaussian). A simple check in Gardiner 
> provides both the generic integrating formula, simplified results and a 
> graph showing the smae numbers that you give.
>   
Whilst the phase noise of a sawtooth corrected M12+T GPS timing receiver
approximates white phase noise (at least for tau < 1 day), this may not
be so for the receiver used in the Thunderbolt.
The phase noise of the OCXO certainly cannot be accurately modeled as
white phase noise for large tau.
> I rather beleive what ADEV, MDEV and TDEV experience in this context.
>
>   
Yes measurements are the key but if one doesnt have a suitable
statistically independent low noise frequency reference it isnt possible
to optimise the loop parameters for an individual GPSDO.
> We could go back to the real integration formula, adapt it to various 
> powers of f^-n noises and analyse it for the same set of PLL loop 
> filters as analysed by Gardiner. Similarly we could cook up a simulation 
> and do the ADEV, MDEV and TDEV measures. Traditional noise bandwidth 
> measures can be calculated alongside.
>
> I am somewhat surprised that you missed the opportunity to correct me as 
> I was giving the incorrect value for damping factor of a critically 
> damped system. It is the square root of 1/2 and not 2, thus 0.7071 is 
> the appropriate damping factor for critically damped systems.
>
>   
I had noted that your quoted damping factor was incorrect but I
suspected that you would realise that.

Actually according to Gardener critical damping factor is 1 ( minimum
settling with no overshoot for a phase step).
However a damping factor of 0.7071 is widely used.
> I am somewhat surprised that when we have been discussing the bandwidth 
> of the PLLs and considering OCXOs being running with fairly high drift 
> rate we have been assuming second degree loops. This form of 
> acceleration requires third degree responses for proper handling, as 
> being well documented in literature such as Gardiner. Going for third 
> degree response the bandwidth of the loop can be (at least more freely) 
> disconnected from tracking requirements due to drift rate.
>   
I only mentioned second order type II loops as the analysis is somewhat
simpler and there is no indication from the number of tuning parameters
for the Thunderbolt that a higher order loop is involved.
> Another aspect worth mentioning is that a pure PLL with a small 
> bandwidth has a very long trackin period. Heuristics to use wider 
> bandwidths or use frequency measure aided bootstrapping or a diffrential 
> element (PID rather than PI regulator) which is equivalent to also feed 
> a frequency error measurement into the loop will significantly aid the 
> loop in quick lock-in. A Kalman filter approach is just along the same 
> lines and when considered next to some more elaborate schemes of 
> heuristic aided PLL seems to much simpler. While the Kalman filter 
> approach isn't as optimum as claimed to be it is still a useful tool.
>
> Cheers,
> Magnus
>
>   

Bruce