From: kirgizz on 8 Feb 2006 11:22 > >John wrote: > >Yes, I've programmed them. x is typically the phase error. It comes >from a phase detector. There are quite a view different types. One is a >zero crossing detector, in which the phase error is the value of high >speed (compared to the input) counter at the time of the crossing. > >JS > > Do you mean by that you're using an external phase detector and feeding the "error-impulses" into your DSP/uC? You implement the loop in program and send the NCO output to this external phase detector? Do you? regards, kirgizz
From: Mark on 8 Feb 2006 11:43 As long as we are on the subject of software PLLs, I have a question.... A software PLL is based on an NCO and an NCO unlike a VCO has a minimum step size so it can only achieve a number of discrete frequencies, i.e. the output frequency is quantized. Now if the input to the PLL is an arbitrary frequency the NCO will not be able to lock exactly to the correct frequency but only to the nearest step. (I know the resolution steps can be very small under 1 Hz but this is more of a theoretical question rather than practical. For the sake of discussion, lets make it easy and assume the step size is 1 Hz). So I assume the NCO will toggle between the two steps that are just above the exact frequency and just below the exact frequency. This will create undesired jitter or phase noise in the output i.e. unwanted FM with deviation of ~+/-0.5 Hz. I also assume the frequency (speed) of this toggling will be a function of the loop bandwidth but that the magnitude of the frequency deviation is fixed by the NCO step size (resolution). This seems to me to be analogous to any quantized system. It seems this issue can be addressed in the same way quantization is addressed, and that is with dither. If random phase noise is present or added, the system will average out to the exact frequency but it still seems to me the NCO frequency must jump back and forth +/-0.5 Hz (in this example). It also seems that if you try to address this by adding bits to the NCO improving its resolution and making the step size smaller that you will decreases the deviation of the FM but you will also increase the rate of the toggling which may or may not be better. (If you had a course step size of 10 Hz, the toggling might be once per second, but if you had a finer step size resolution of say 0.1 Hz, the toggling would speed up to 100 Hz) So the questions... Are these observations correct and why is it not a problem in practice. thanks Mark
From: Ron N. on 8 Feb 2006 14:21 Mark wrote: > A software PLL is based on an NCO and an NCO unlike a VCO has a minimum > step size so it can only achieve a number of discrete frequencies, i.e. > the output frequency is quantized. Why do you say this? An NCO is, of course based on some digital number representation; but if you use IEEE doubles, the quantization error of the phase is much smaller than the thermal noise of any analog oscillator, maybe even smaller than the quantum limits physics allows any analog VCO. IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-M
From: Ron N. on 8 Feb 2006 14:38 Dougal McDougal of that Elk wrote: > You need to watch the stability - ie phase margin. Make sure you sample at > about ten times the unity gain cross-over freq. Your unity gain freq could > be around 12Hz - this should filter out the 2f at 120Hz. You may also need a > phase-lead compensator depending on the number of integrators you want (ie > for just the VCO you have one integrator - but you can add a phase-lag to > increase the slope). You need a Bode Plot in your head or on paper.If you > use a low-pass filter this will introduce phase lag and the amount depends > on the order of teh filter. The more you filter, the less 2f carrier > feedthrough but the more instability. Since this is being done in software, can't one get rid of all the phase lead/lag problems by using identical linear phase FIR filters on both the reference input and the VCO? Thanks. -- rhn A.T nicholson d.0.t C-o-M
From: Ron N. on 8 Feb 2006 14:44 Tim Wescott wrote: > Implementing a PLL in software uses the same basic theory as > implementing a PLL in hardware -- you compare your synthesized signal to > a reference, generate a phase difference, then servo the frequency of > your synthesized signal to your reference. Why? Isn't a software PLL just a forward interpolator. Why not just estimate (statistical, FFT, phase vocoder or otherwise) the frequency, phase, derivatives of phase, etc.; generate a forward interpolation of the input reference using that information, and call that the output of the PLL NCO? Recalculate periodically (every sample if the compute power is available). rhn A.T nicholson d.0.t C-o-M
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: MELP / MELPe vocoder and IMBE vocoder Next: Audio Fingerprinting Technology |