Hej Magnus Magnus Danielson wrote: > Bruce Griffiths skrev: > >> Magnus Danielson wrote: >> >>> Dick, >>> >>> Richard Moore skrev: >>> >>> >>>> On Jan 8, 2009, at 2:58 AM, [email protected] wrote: >>>> >>>> >>>> >>>>> Message: 6 >>>>> Date: Thu, 08 Jan 2009 11:51:50 +0100 >>>>> From: Magnus Danielson <[email protected]> >>>>> Subject: Re: [time-nuts] GPSDO time constant >>>>> To: Tom Van Baak <[email protected]>, Discussion of precise time and >>>>> frequency measurement <[email protected]> >>>>> 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
