DSPRelated.com
Forums

Digital PLL acquisition problem

Started by Unknown March 15, 2007
Vladimir Vassilevsky wrote:

> > > patrick.melet@dmradiocom.fr wrote: > > >> I made a digital PLL, with multiplier based phase detector, digital >> loop filter C1 + C2/(1-z^-1) and a digital NCO with 16 bits >> accumulator >> >> I want to lock on a 22170 Hz sine signal in 10 ms lock time >> >> My problem is when I don't have the 22170 Hz signal, my output filter >> sweep very slowly (1 second) beetween min and max of my input NCO and >> don't lock when my 22170 Hz signal is on >> >> So I put a window at the ouput of my filter to only sweep in a 2600 Hz >> window >> And when this ouput is out of this window I reset the filter >> accumulator to its maximum value, now the ouput of the filter sweep >> this window very slowly ( about 2 seconds) >> >> So with this when I put my 22170 Hz off and on my loop locks into it, >> but I have a very long lock time ( 200 ms) and not 10 ms... >> >> Is in acquisition mode I have to "manually" sweep my input NCO in the >> 2600 Hz window and look at the ouput of the loop filter to say if I'm >> lock or not ? > > > 1. You should use the state machine frequency/phase detector, not a > multiplier. This will guarantee the reliable quick PLL pull-in. >
Unless you're trying to lock to a signal that's embedded in noise, in which case a state machine detector will be worse than useless. If you sample the data first, then implement your PLL, a pure-logic state machine frequency/phase detector will have an uncertainty around the edges of +/- 1/2 sample, which quite broad for many purposes. I rarely encounter an application that can suffer this much noise being injected by the algorithm itself. Assuming that the tone is strong enough you can get the same effect by estimating the incoming signal's phase and counting rotations -- this works very well in practice, with much noisier signals than you can hope to use a frequency/phase detector on, and doesn't have the edge uncertainty. It does have the drawback that it twists your brain in loops, but once you get it figured out you'll be smarter than you were going in.
> 2. The pull-in time depends on the loop filter parameters. There is a > tradeoff between the PLL noise bandwidth and the pull-in time. >
Yea verily. If you can detect lock you can switch (or slide) to a narrower bandwidth once the phase & frequency are acquired.
> 3. The RMS variation of the NCO frequency can be used as the measure of > PLL lock.
Assuming a pure enough tone -- here again, in a noisy environment it can be rough to distinguish noise-induced RMS variation of the error signal from an unlocked loop. If you're doing something extreme like digging a tone that's buried several dB deep into the noise then you can have a perfectly adequate lock yet have a very difficult time pulling it out -- in this case you'd have to low-pass filter the NCO frequency variations, and look at the RMS variation of the resulting signal. It could be done, but you'd have to approach the problem of determining when you have a good lock very carefully lest you simply build a false-positive generator. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html
patrick.melet@dmradiocom.fr wrote:

> Hi all, > > I made a digital PLL, with multiplier based phase detector, digital > loop filter C1 + C2/(1-z^-1) and a digital NCO with 16 bits > accumulator >
Sounds fine so far, assuming your accumulator will give you the frequency precision you need.
> I want to lock on a 22170 Hz sine signal in 10 ms lock time > > My problem is when I don't have the 22170 Hz signal, my output filter > sweep very slowly (1 second) beetween min and max of my input NCO and > don't lock when my 22170 Hz signal is on
The fact that it sweeps in one direction indicates that you have a roundoff problem in your multiplier. If you're doing the multiplication then letting the processor naturally truncate the data it'll be biased -- this will cause the drift.
> > So I put a window at the ouput of my filter to only sweep in a 2600 Hz > window > And when this ouput is out of this window I reset the filter > accumulator to its maximum value, now the ouput of the filter sweep > this window very slowly ( about 2 seconds) > > So with this when I put my 22170 Hz off and on my loop locks into it, > but I have a very long lock time ( 200 ms) and not 10 ms... > > Is in acquisition mode I have to "manually" sweep my input NCO in the > 2600 Hz window and look at the ouput of the loop filter to say if I'm > lock or not ? >
How well do you know your tone frequency ahead of time? Is the tone guaranteed to be there all the time? What's the signal to noise ratio of your tone? Is the noise colored? If you know your tone frequency quite well ahead of time, and you know for sure that the tone will be there when you start to acquire, you should start up with the integrator value set to your incoming tone frequency. If the tone is guaranteed to be there all the time and and it's SNR is high, then you can schedule the gains of your PLL to get a fast, reliable acquire followed by a nice low-bandwidth track phase. Theoretically you'll do this by going through all the math to generate an extended Kalman filter; in the real world you can often get by with tuning each phase experimentally to do well enough while optimizing the filter for design time. If the noise is white then you can worry less. If it may contain interfering tones close to the target tone then you can worry more. If the tone frequency is uncertain, if the tone goes on and off, if it's buried in noise, and if there are interfering tones -- you have a long row to hoe, and you may want to hit the books or hire a consultant. Assuming that you have the easy case of a known-frequency, strong, continuous tone then you shouldn't be having this trouble. I'd suspect that you have some implementation problem, rather than an algorithmic one. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.html

Tim Wescott wrote:

>>> I made a digital PLL, with multiplier based phase detector, digital >>> loop filter C1 + C2/(1-z^-1) and a digital NCO with 16 bits >>> accumulator >>> >>> My problem is when I don't have the 22170 Hz signal, my output filter >>> sweep very slowly
[...]
>> >> 1. You should use the state machine frequency/phase detector, not a >> multiplier. This will guarantee the reliable quick PLL pull-in. >> > Unless you're trying to lock to a signal that's embedded in noise, in > which case a state machine detector will be worse than useless. > > If you sample the data first, then implement your PLL, a pure-logic > state machine frequency/phase detector will have an uncertainty around > the edges of +/- 1/2 sample, which quite broad for many purposes. I > rarely encounter an application that can suffer this much noise being > injected by the algorithm itself. > Assuming that the tone is strong enough you can get the same effect by > estimating the incoming signal's phase and counting rotations -- this > works very well in practice, with much noisier signals than you can hope > to use a frequency/phase detector on, and doesn't have the edge > uncertainty. It does have the drawback that it twists your brain in > loops, but once you get it figured out you'll be smarter than you were > going in.
Agreed completely. The state machine does not have to be like a dual flip-flop thing from the textbook. The point is to make a frequency sensitive phase detector, and that can be accomplished by different ways. Counting the phase rollovers cost me a couple of days to make it work, but that was also the phase modulated signal :) BTW, implementing a PLL as PID rather then PI also makes it frequency sensitive.
> >> 2. The pull-in time depends on the loop filter parameters. There is a >> tradeoff between the PLL noise bandwidth and the pull-in time. >> > Yea verily. If you can detect lock you can switch (or slide) to a > narrower bandwidth once the phase & frequency are acquired.
There is also some shamanistic theories for using the nonlinear filters for that purpose.
>> 3. The RMS variation of the NCO frequency can be used as the measure >> of PLL lock. > > > Assuming a pure enough tone -- here again, in a noisy environment it can > be rough to distinguish noise-induced RMS variation of the error signal > from an unlocked loop. If you're doing something extreme like digging a > tone that's buried several dB deep into the noise then you can have a > perfectly adequate lock yet have a very difficult time pulling it out -- > in this case you'd have to low-pass filter the NCO frequency variations, > and look at the RMS variation of the resulting signal. It could be > done, but you'd have to approach the problem of determining when you > have a good lock very carefully lest you simply build a false-positive > generator.
The detecting of a PLL lock requires some sort of measurement of the RMS noise in the loop. I don't know if there can be the other way for doing that. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
hi

in your article : Efficient Multitone detection

you have a low pass filter wk(n) = wk(n-1) + uk(n)/16 - wk(n-1)/16
which have a 10 Hz cutoff at 8 kHz sampling

how to compute the new filter for a 300 kHz sampling frequency and 30
kHz sampling ?


patrick.melet@dmradiocom.fr wrote:
> hi > > in your article : Efficient Multitone detection > > you have a low pass filter wk(n) = wk(n-1) + uk(n)/16 - wk(n-1)/16 > which have a 10 Hz cutoff at 8 kHz sampling
No. It has 10Hz cutoff at Fs = 1kHz .
> how to compute the new filter for a 300 kHz sampling frequency and 30 > kHz sampling ?
You are the Ph.D., aren't you? Here is the Ph.D. stuff: y += (x-y)*A A = 1 - exp(-2*Pi*Fs/Fsa); Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com