[time-nuts] GPSDO TC
bruce.griffiths at xtra.co.nz
Thu Jan 8 22:53:40 UTC 2009
Magnus Danielson wrote:
> Bruce Griffiths skrev:
>> Magnus Danielson wrote:
>>> 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.
>> 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.
More information about the time-nuts