[time-nuts] GPSDO TC

[Magnus Danielson]

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.

I rather beleive what ADEV, MDEV and TDEV experience in this context.

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 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.

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