PLL jitter and tracking filters
in [Design]
|
Prev: This is funny
Next: One mouse click, 2 PC's
From: John Larkin on 16 Jun 2010 09:59 On Tue, 15 Jun 2010 23:09:29 -0700 (PDT), crasic <trueurssian(a)gmail.com> wrote: >Hi all, > >I posted this topic over at comp.dsp and they suggested I try you >guys. > >I'm working on a problem that requires a tracking bandpass filter. The >center frequency is known a priori, but has some drift within the >range 0.01-0.05 f. A typical frequency would be 700KHz with a >corresponding 1-2Khz drift and fairly noisy which, after digitizing >and edge detection, is in the form of frequency jitter, Ideally the >center frequency should be easily set. The output of the circuit is >essentially a square wave, with some predetermined (and preferably >adjustable) pulse width. > >The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. >What we are worried about most is reducing jitter on the resultant >square wave. We are currently successfully using a sequence of >amplifiers, an analog (constant) bandpass, and a sine->square >converter based on some 74XX chips. > >Unfortunately this analog circuitry is power hungry, expensive, >nonconfigurable, and bulky. So we want to (if possible) move >everything to the digital domain, ideally implemented on some >programmable logic like an FPGA. > >So one idea is to use a purely digital PLL synthesized in an altera >fpga. We are essentially using something like http://opencores.org/project,dpll_rwf >but independently designed by me from the same references (not by >choice, I stumbled on his open source design after the work was done). >The DPLL design is based on some older IEEE papers (late 70's) and >uses a binary phase detector and a sequential loop filter (a "Variable >Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is >essentially two up/down counters hooked up in a clever way, > >We measured our noise floor with the PLL running in an open loop to be >approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all >measurements are taken over 1 second. 10 readings are taken and >averaged). About ten times better than our "ideal" output jitter of >the running loop. > >As it turns out, the PLL is working too much as an ideal bandpass. On >a scope you can see a clearly mimicked signal, i.e. it is following >the input signal with all its jitter and the output jitter of the pll >matches the input jitter (when measured on a frequency counter). The >input and output jitter is 3 orders of magnitude above our intrinsic >jitter of the loop so there is room for improvement. The paper which >this design is based on (reference 3 on that open cores page) >experimentally predicts frequency jitter reduction of ~5-10 fold over >input jitter on a relatively noisy signal. We are getting almost no >reduction. > >Does anyone have any thoughts on this problem with the PLL? Or maybe >more generally: How would you approach the general problem stated at >the top? > >Thanks for reading Hi, Is your input signal a sine wave, or is it already squared up? One way to do this is to build a PLL using a DDS, clocked at 160 MHz maybe, as the local oscillator. The input signal, if analog, would be mildly analog filtered and then digitized by the best ADC you can afford. Then the phase detector is essentially a lockin, integrating ADC samples multiplied by the MSB of the DDS. Close the loop to tune the DDS frequency. The result is of course time-quantized to the 160 MHz clock; if that's too much jitter, some number of DDS MSBs can be used to drive a DAC-lowpass-comparator to interpolate, just like any DDS synthesizer. There's a little analog stuff outside the FPGA, but it's simple and you get a system that's easily tunable. A small FPGA could do all the work. This uses a Spartan3 to do eight DDSs, with all sorts of terrible modulations and stuff, clocked at 128 MHz. http://www.highlandtechnology.com/DSS/V346DS.html What's the physics? John > >Andrey Shmakov >University of California Berkeley >Department of Physics
From: MooseFET on 16 Jun 2010 10:32 On Jun 16, 2:09 pm, crasic <trueurss...(a)gmail.com> wrote: [... PLL ...] > As it turns out, the PLL is working too much as an ideal bandpass. On > a scope you can see a clearly mimicked signal, i.e. it is following > the input signal with all its jitter and the output jitter of the pll > matches the input jitter (when measured on a frequency counter). The > input and output jitter is 3 orders of magnitude above our intrinsic > jitter of the loop so there is room for improvement. The paper which > this design is based on (reference 3 on that open cores page) > experimentally predicts frequency jitter reduction of ~5-10 fold over > input jitter on a relatively noisy signal. We are getting almost no > reduction. Others are suggesting the CD4046 which is likely a better idea than the FPGA or that the jitter is withing the bandwidth. If the jitter on the output is equal to but not identical to the jitter on the input, you may just be very unlucky with you numbers. Take a very careful look at how you made your filter. Basically, your filter and "VCO" need to do something like this: if the input is before the output increase the frequency (long term) shift the vco phase earlier (short term) else decrease the frequency You need to shift the phase because the VCO to phase detector represents an integrator and the filter is a second integrator. With two integrators inside the loop, the system will want to oscillate. The shifting of the phase of the VCO removes some of the phase shift and makes the loop stable. You only need one phase shifting operation because the filter will settle just a little off the right value and the phase shifting will happen on every other cycle. This is equivelent to shifting in both directions by half the amount. Doing the phase shift by one clock cycle works but forces you to have a "proportional gain" that works out to one clock cycle. You can make your phase shift by increasing the frequency for a while and then decreasing it again. In a phase accumulator style system this means that the phase number just needs to be increased by an extra amount some number of times after each phase comparison. In the programable divide by N style, it is a bit trickier but the N needs to be a little less. PLLs of this sort tend to bobble back and forth by 2 clock cycles. You can improve on this if you put a backlash in the logic that drives the integration. So long as the phase shifting logic can keep the system in step, the integrator doesn't need to change at all. When more than some number (say 64) phase corrections land in the same direction, the integrator can be allowed to move.
From: Vladimir Vassilevsky on 16 Jun 2010 10:32 crasic wrote: > Hi all, > > I posted this topic over at comp.dsp and they suggested I try you > guys. > [...] So, omitting all obscure wording, all you need is output the input frequency averaged per X amount of time, right? The simplest way to do it in FPGA is just measure the period, calculate average and generate the output. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: j on 16 Jun 2010 10:55 Hi, I read your post over on the dsp group. But I find it difficult to help you due to what appears to be conflicting information. Is the objective to track and clean-up a signal with undesirable short term stability, (jitter to be defined), but wanders 1-2 kHz over time? Or is the objective to correct the wander of 1-2KHz signal that has good short term stability? Over on the dsp group post you seemed to indicate that your NCO when run in the open loop static case had much worse pk-pk jitter that your ref source, (input test gen). Is this the case or not? (A side note, typically in the comm/instrumentation world when speaking of jitter folks talk about this in terms of time or % of UI. In your case your speaking in terms of aved freq measurements taken with a counter?) regards, j
From: Tim Wescott on 16 Jun 2010 11:15
On 06/15/2010 11:09 PM, crasic wrote: > Hi all, > > I posted this topic over at comp.dsp and they suggested I try you > guys. > > I'm working on a problem that requires a tracking bandpass filter. The > center frequency is known a priori, but has some drift within the > range 0.01-0.05 f. A typical frequency would be 700KHz with a > corresponding 1-2Khz drift and fairly noisy which, after digitizing > and edge detection, is in the form of frequency jitter, Ideally the > center frequency should be easily set. The output of the circuit is > essentially a square wave, with some predetermined (and preferably > adjustable) pulse width. > > The signal drift is fairly small, ~+- 500Hz for the 700KHz signal. > What we are worried about most is reducing jitter on the resultant > square wave. We are currently successfully using a sequence of > amplifiers, an analog (constant) bandpass, and a sine->square > converter based on some 74XX chips. > > Unfortunately this analog circuitry is power hungry, expensive, > nonconfigurable, and bulky. So we want to (if possible) move > everything to the digital domain, ideally implemented on some > programmable logic like an FPGA. > > So one idea is to use a purely digital PLL synthesized in an altera > fpga. We are essentially using something like http://opencores.org/project,dpll_rwf > but independently designed by me from the same references (not by > choice, I stumbled on his open source design after the work was done). > The DPLL design is based on some older IEEE papers (late 70's) and > uses a binary phase detector and a sequential loop filter (a "Variable > Reset Random Walk Filter" or "VR-RMF" in dsp jargon) which is > essentially two up/down counters hooked up in a clever way, > > We measured our noise floor with the PLL running in an open loop to be > approximately ~50uHz at 700KHz and a 160Mhz (10*16) clock (all > measurements are taken over 1 second. 10 readings are taken and > averaged). About ten times better than our "ideal" output jitter of > the running loop. This is different from what you reported over at comp.dsp -- you corrected a problem? > As it turns out, the PLL is working too much as an ideal bandpass. On > a scope you can see a clearly mimicked signal, i.e. it is following > the input signal with all its jitter and the output jitter of the pll > matches the input jitter (when measured on a frequency counter). The > input and output jitter is 3 orders of magnitude above our intrinsic > jitter of the loop so there is room for improvement. The paper which > this design is based on (reference 3 on that open cores page) > experimentally predicts frequency jitter reduction of ~5-10 fold over > input jitter on a relatively noisy signal. We are getting almost no > reduction. > > Does anyone have any thoughts on this problem with the PLL? Its loop gain is too high, leading to a too-high bandwidth. Find the design element that sets the loop gain and reduce it. > Or maybe > more generally: How would you approach the general problem stated at > the top? Without reading the papers involved, I'm suspicious of your methods. Digital PLLs are easy things to implement these days, where in the 1970's you would have been severely constrained by the hardware available. Are you sure you're not doing a whole bunch of work that's necessary if you're building a circuit from resistor-transistor logic, but which is a massive waste of gates if you're doing it in an FPGA? If your FPGA design isn't easily separable into a phase comparator, a loop filter, an and NCO, then it's not a good design and working with it is going to be an ongoing PITA. input signal -> phase compare --> loop filter --> counter value --> loadable down-counter --> output signal. (If you need a "real" PLL at all -- think about Vladimir's response. If you need phase lock then you do need something that's going to be a PLL when all is said and done, though). -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com |