Software PLL (SPLL)

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.

Software PLLs have some significant advantages over hardware PLLs, mostly in the reliability of the VCO and the ability to easily concoct complicated loops without having it show up as an embarrassing second PC board. They have some significant difficulties, as well, mostly having to do with the fact that you're operating in sampled time.

Most of the problems you will encounter will be because of the sampled-time nature of a software-based loop.

For a logic-level input signal my favorite phase detector is a timer capture input. If this is available it should be able to sample the state of a free-running timer at the instant that the reference signal changes from low to high (or visa-versa). Once this sample is taken you have a nice, unambiguous measure of the time that the transition happened to a precision proportional to the clock speed of your timer. You can use this time to compare to the state of your NCO phase accumulator (with appropriate interpolation between NCO sampling periods) and do whatever you want with your NCO command as a result.

If you must feed the logic-level signal into an ADC then you will run into severe problems with aliasing. The sharp edges of the incoming signal will cause the phase measurement to be ambiguous by the ADC sampling interval, which will make it impossible to lock precisely. If you must use the ADC input then you should use anti-alias filtering to soften up the edge -- which means that you should be sampling well in excess of your 20kHz maximum signal frequency, probably 50kHz at a minimum. To determine the phase difference of your signal you just multiply the ADC reading by the output of your NCO and average (or low-pass filter) -- if you want faster lock you can get make a phase/frequency detector by using both the inphase and quadrature output of your NCO, and look at the phase rotation of the two averages (this is why software PLL's can be nice...).

This is more a DSP question than electronics design, so I'm taking the liberty of cross-posting my response to the DSP newsgroup. Maybe someone there will have some good insights.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Tim,

That was a very nice explanation. I have always considered software PLLs to be a bit of an enigma, though a future project goal of mine is going to require one. In my case, the reference and the incoming signal will both be aprox 50 or 60hz sine waves. For the PFD, I was planning on multiplying them and filtering the result which would be used to drive the NCO.

I was wondering if you would you please elaborate a little more on the concept of using the inphase and quadriture outputs and their phase rotation and what this does / how / why it works?

I always consider software PLLs to be very straightforward -- until I get caught up in actually making them work. Then I try to act casual while I'm struggling with them so that when I finally stumble onto the right combination I look clever...

On using inphase and quadrature outputs:

First, see my opening paragraph -- I missed a detail in that recommendation, it isn't as powerful as I had thought (d'oh). I'll explain as I go.

Let's say that you're keeping track of the NCO phase and calling it 'theta', and you're phase locking to a signal -- I'll call it 'line' in honor of your 50 or 60Hz signal. A multiplying phase detector can be made by finding

phaseError = sin(theta) * line;

You take this phase error and run it through a loop filter:

frequency = loopFilter.Update(phaseError); // pretend this is C++

Then you calculate the NCO phase:

theta += frequency;

And you're done.

The cool thing is that the variable phaseError will have an average value that's proportional to the phase, so if your loop settles at all it will do so at zero average error.

The problem is that if all you know is phaseError then it's average could be zero for other reasons -- either the NCO frequency is significantly different from the line frequency, or you're hovering on a phase error of 180 degrees. Usually the 180 degrees out of phase issue isn't a big one because it's inherently unstable and eventually your loop will lock. A large frequency difference can be a bigger problem.

If you do the quadrature thing, then you may calculate

phaseErrorI = sin(theta) * line; phaseErrorQ = cos(theta) * line;

Now, when you are at 0 degrees phase error phaseErrorI will average to 0 and phaseErrorQ will average to a positive number. With 180 degrees phase error phaseErrorI will average to 0 and phaseErrorQ will average to a _negative_ number, so you will be able to distinguish the 180 degree out of phase condition and deal with it.

In addition, if there is a frequency difference between the line frequency and your NCO frequency then the average values of phaseErrorI and phaseErrorQ will rotate around each other -- so first phaseErrorI will be high, then phaseErrorQ, then phaseErrorI will be negative, etc. You can use the averages of these two phase errors like the output of a quadrature encoder to track the phase error and determine if it is rising or falling, which will let you determine if your frequency error is positive or negative -- which in turn will let you bring your loop into lock quicker.

Unfortunately (and hence the d'oh), if the frequency error is large then the average values will both be quite small, and this method won't give great success. So for this sort of thing you may be better to have a coarse frequency loop that just counts zero crossings or something to bring the loop into approximate lock, then allow a simple multiplying phase detector to take over.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

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.

Tam

Thank you both. I think I understand things a bit better than before.

I think the idea of using a gross zero crossing aproximator to drive the PLL into the neighborhood of the incoming frequency and then letting the loop filter / NCO take over sounds like a very workable idea.

Tim, as I indicated, I have been planning this as a future sub project for a while now. I have played around with the PFD concept multiplying a reference and "line" (sine and cosine waves at various magnitudes, frequencies and phase offsets) and filtering the result in mathcad to get an intuitive feel for the operation and effects. From these experiments, I believe I understand what you are saying about the phase error I and Q rotating (like a vector spinning in time) and how depending on the phase relationship of the signals one will be high, the other will be low.

The big part that I haven't addressed in time is the part about driving the NCO. I realize that the output of the loop filter does this, but I suspect part of the trick will be determining the gain or attenuation factor to the NCO, but that can wait till another day.

If your reference is already TTL, DO NOT feed it into that stereo audio in jack on the ez-kit, even after an appropriate voltage divider.

The DSP chip has some GPIO bits, connect to those instead as you can sample them much faster than you can sample the serial ADC (which needs at least 32 clocks to get you one sample, maybe more).

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

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

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

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

the delay of those filters is as harmful as phase lag. Filters used in feedback should be "prompt"; as close to minimum phase as practical.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

What's important isn't the mismatch in phase between the reference and VCO; it's the total phase lag between a loop disturbance and the system's response to it that will make or break a control loop.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

...

I can't remember a single thing from my control systems course from many years past, so I'm probably asking some stupid questions.

Would using minimum phase filters instead of linear phase ones (with the same frequency respose) cause any problems?

IMHO. YMMV.

--
rhn A.T nicholson d.0.t C-o-M

In article , Dougal McDougal of that Elk wrote: [...]

Ten times is a bit more than you really really need. 5 will work with some extra effort.

To extend this comment a little:

Generally, you want 2 poles and a zero in the PLL's filter. One pole is well below the gain cross over. The zero is just about at the gain cross over and the 2nd pole is well above.

If you plot out a Bode plot you'll see why this works well.

In a multiplying PLL, you often can create a signal to mostly cancel the

2F signal in the filter. Also, a tri-stating phase detector doesn't make much 2F at all.

You can also do things like add a notch up at the 2F point too if you need to supress it further.

--
--
kensmith@rahul.net   forging knowledge

Perhaps because this is what he has seen.

IEEE doubles requires some serious amount of electronics and is not really the best way to go. You do better with a 64 bit fixed point system.

I've done quite a few digital PLL systems and have never needed to go beyond about 32 bits to get good results.

Still if you are making a square wave on the output you have 1 clocks worth of jitter.

--
--
kensmith@rahul.net   forging knowledge

Now fit that FFT into a PIC.

--
--
kensmith@rahul.net   forging knowledge

Minimum phase filters are preferred. Linear phase ones are likely to cause problems, due to the delay affecting the phase margin.

As Jerry said, you want 'prompt' filters.

Regards, Allan

The OP specified a 200 MHz DSP. Why add a PIC in addition to the DSP? And if he knows something about the signal, there might be more computationally efficient statistical estimators than some FFT frames.

IMHO. YMMV.

--
rhn A.T nicholson d.0.t C-o-M

yuck!

you would have to work quite very to match, let alone beat, the performance you can get from a software PLL, requiring negligible computational overhead.

swatting flies with Howitzers often causes more problems than it solves.

Cheers Terry