Re: PLL convergence problem
- From: Tim Wescott <tim@xxxxxxxxxxxxxxxx>
- Date: Mon, 17 Oct 2005 10:17:02 -0700
yoni.baron@xxxxxxxxx wrote:
Allan Herriman had a good answer for the false lock issue. I've never had to deal with that myself, so I'm not the one to speak to it other than to say that it clearly seems to be an issue.Hi Tim, Eric
Thanks for the reply.
I use a PI filter. all the design is floating point. When I plot the PSD of the error metric I see that the error spectral line is at about 10db higher then the self noise around it.
I see no overflows in either the NCO or the loop accumulator.
I still don't see how a small leaky integrator that has cutoff frequency way higher then that of the closed loop filter can cause any difference. The frequency response of both loops - the one with the leaky integrator and the one without is almost identical. The only difference is that the one with the leaky integrator has a little higher stopband attenuation.
I don't have any extra delay in the loop except for the normal PI loop delays (i.e for the accumulators) and one for the detector.
As for the false lock theory, Is there a way to check if I this is the case?
Thanks, Yoni.
As for the noise and the low pass filter in the loop, the noise characteristic you want to look for is not the spectral density of the noise vs. the spectral density of the error signal; what you need to look at is the total noise power vs. the total power of the error signal. Since the NCO is a time-domain construct it doesn't care about the spectral density of the noise, only the total amount of noise that it's getting pounded with. If this is greater or even about the same amplitude as the error signal that gets through then it's too much.
If this noise is fairly flat then you could be having big problems given the ratio between your loop bandwidth and your sampling rate. Any time I design a loop with such a large discrepancy I routinely do two things: first I put in some low pass filtering well above the bandwidth of the loop (lower than yours, by the way) to kill any such noise; second I check for underflow. If you're using IEEE 32-bit floating point you only have 25 bits of mantissa to play with; you probably have a ratio of integrator gain to proportional gain of around 1:1000, which means that you've already used up 10 bits. If your NCO has more than 15 bits of precision on it's input you should be worried about underflow right now.
--
Tim Wescott Wescott Design Services http://www.wescottdesign.com .
- References:
- PLL convergence problem
- From: yoni.baron@xxxxxxxxx
- Re: PLL convergence problem
- From: Tim Wescott
- Re: PLL convergence problem
- From: yoni.baron@xxxxxxxxx
- PLL convergence problem
- Prev by Date: Re: Analog to digital filter conversion
- Next by Date: Re: how to prove that y=x((cos(t))^2 is not Time Invariant?
- Previous by thread: Re: PLL convergence problem
- Next by thread: Re: PLL convergence problem
- Index(es):
Relevant Pages
|
