From: kirgizz on
>
>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
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
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
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
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