PLL jitter and tracking filters
in [Design]
|
Prev: This is funny
Next: One mouse click, 2 PC's
From: crasic on 16 Jun 2010 18:12 On Jun 16, 7:55 am, j <jdc1...(a)gmail.com> wrote: > 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 Sorry to J and Tim for the spam, I accidentally hit reply to author instead of simply reply. The input signal is essentially stable with some slow long term drift, You can think of it as a 700KHz signal with a 1KHz sweep width at 1hz. There is however plenty of fast noise that we want to eliminate. Right now I'm not even worried about the long term tracking, and simply feeding the PLL a noisy signal and seeing how well it filters. The signal used on the test bench is fixed with no sweep. I omitted the details of the progress I made since my comp.dsp post, I admit I wasn't thinking of those that frequent both groups. Yes I did have a open loop frequency jitter problem, but replacing the clock source with a much more stable one I have since solved that problem. On Jun 16, 8:15 am, Tim Wescott <t...(a)seemywebsite.now> wrote: > > 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 consultingwww.wescottdesign.com Unfortunately I do need a phase lock. The circuit is acting as the control element in an oscillator loop, so it will be feeding an oscillator that is then feeding the pll. Having the two signals out of phase would not properly drive the oscillator. The PLL from the papers is essentially how you described it. However the nco is set with an adjustable constant rather than constantly updated by the loop filter, this decreases the lock in range, but improves the tracking and supposedly the noise reduction. The loop filter then inhibits or adds fast clock pulses to the nco in order to lock onto the signal. I was originally using a more traditional pll, but since this design still had a variable center frequency and since we would know that frequency beforehand, the possibility of a cycle slip causing the a coarse frequency shift was not very appealing when compared to this alternative. The design however still has clearly seperated phase comparator, loop filter, and nco. Fortunately the papers were very theoretical in that they didnt talk about specific hardware implementations at all. They gave a very general RTL diagram of the scheme and then s-parameters and mathematical analysis of individual loop elements, Fortunately they didn't require me to cut through any of the 70's specific hardware details that you mentioned Andrey Shmakov University of California Berkeley Department of Physics
From: John Larkin on 16 Jun 2010 19:11 On Wed, 16 Jun 2010 15:12:56 -0700 (PDT), crasic <trueurssian(a)gmail.com> wrote: > > >On Jun 16, 7:55 am, j <jdc1...(a)gmail.com> wrote: >> 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 ave�d freq measurements taken >> with a counter?) >> >> regards, >> j > > >Sorry to J and Tim for the spam, I accidentally hit reply to author >instead of simply reply. > >The input signal is essentially stable with some slow long term drift, >You can think of it as a 700KHz signal with a 1KHz sweep width at 1hz. >There is however plenty of fast noise that we want to eliminate. Right >now I'm not even worried about the long term tracking, and simply >feeding the PLL a noisy signal and seeing how well it filters. The >signal used on the test bench is fixed with no sweep. > >I omitted the details of the progress I made since my comp.dsp post, I >admit I wasn't thinking of those that frequent both groups. Yes I did >have a open loop frequency jitter problem, but replacing the clock >source with a much more stable one I have since solved that problem. > >On Jun 16, 8:15 am, Tim Wescott <t...(a)seemywebsite.now> wrote: > >> >> 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 consultingwww.wescottdesign.com > > >Unfortunately I do need a phase lock. The circuit is acting as the >control element in an oscillator loop, so it will be feeding an >oscillator that is then feeding the pll. Having the two signals out of >phase would not properly drive the oscillator. > >The PLL from the papers is essentially how you described it. However >the nco is set with an adjustable constant rather than constantly >updated by the loop filter, this decreases the lock in range, but >improves the tracking and supposedly the noise reduction. The loop >filter then inhibits or adds fast clock pulses to the nco in order to >lock onto the signal. I was originally using a more traditional pll, >but since this design still had a variable center frequency and since >we would know that frequency beforehand, the possibility of a cycle >slip causing the a coarse frequency shift was not very appealing when >compared to this alternative. The design however still has clearly >seperated phase comparator, loop filter, and nco. If you know in advance what the sweep pattern is, you can add that into the nco input, to feedforward-track the expected signal. Then the PLL can be a lot narrower-band and have less tracking error and/or less jitter. Is your nco a DDS phase accumulator? That was difficult in the 70's, trivial in an FPGA now. John
From: crasic on 16 Jun 2010 19:31 On Jun 16, 4:11 pm, John Larkin <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > On Wed, 16 Jun 2010 15:12:56 -0700 (PDT), crasic > > > > <trueurss...(a)gmail.com> wrote: > > >On Jun 16, 7:55 am, j <jdc1...(a)gmail.com> wrote: > >> 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 ave d freq measurements taken > >> with a counter?) > > >> regards, > >> j > > >Sorry to J and Tim for the spam, I accidentally hit reply to author > >instead of simply reply. > > >The input signal is essentially stable with some slow long term drift, > >You can think of it as a 700KHz signal with a 1KHz sweep width at 1hz. > >There is however plenty of fast noise that we want to eliminate. Right > >now I'm not even worried about the long term tracking, and simply > >feeding the PLL a noisy signal and seeing how well it filters. The > >signal used on the test bench is fixed with no sweep. > > >I omitted the details of the progress I made since my comp.dsp post, I > >admit I wasn't thinking of those that frequent both groups. Yes I did > >have a open loop frequency jitter problem, but replacing the clock > >source with a much more stable one I have since solved that problem. > > >On Jun 16, 8:15 am, Tim Wescott <t...(a)seemywebsite.now> wrote: > > >> 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 consultingwww.wescottdesign.com > > >Unfortunately I do need a phase lock. The circuit is acting as the > >control element in an oscillator loop, so it will be feeding an > >oscillator that is then feeding the pll. Having the two signals out of > >phase would not properly drive the oscillator. > > >The PLL from the papers is essentially how you described it. However > >the nco is set with an adjustable constant rather than constantly > >updated by the loop filter, this decreases the lock in range, but > >improves the tracking and supposedly the noise reduction. The loop > >filter then inhibits or adds fast clock pulses to the nco in order to > >lock onto the signal. I was originally using a more traditional pll, > >but since this design still had a variable center frequency and since > >we would know that frequency beforehand, the possibility of a cycle > >slip causing the a coarse frequency shift was not very appealing when > >compared to this alternative. The design however still has clearly > >seperated phase comparator, loop filter, and nco. > > If you know in advance what the sweep pattern is, you can add that > into the nco input, to feedforward-track the expected signal. Then the > PLL can be a lot narrower-band and have less tracking error and/or > less jitter. > > Is your nco a DDS phase accumulator? That was difficult in the 70's, > trivial in an FPGA now. > > John I know in general what the sweep is (i.e. its slow and within 1Khz), but it is a natural process and therefore far from regular or predictable. Since the oscillator I'm driving only requires a square wave to drive (with a 10% duty) my "NCO" is simply a counter and a flipflop. In an open loop it is simply dividing the base system clock to whatever center frequency I set, with a signal in the loop the loop filter inhibits or adds clock pulses into the counter, thus modulating the phase and (to a smaller extent) the frequency. Andrey Shmakov University of California Berkeley Department of Physics
From: j on 16 Jun 2010 22:42
On Jun 16, 4:31 pm, crasic <trueurss...(a)gmail.com> wrote: > On Jun 16, 4:11 pm, John Larkin > > > > > > <jjlar...(a)highNOTlandTHIStechnologyPART.com> wrote: > > On Wed, 16 Jun 2010 15:12:56 -0700 (PDT), crasic > > > <trueurss...(a)gmail.com> wrote: > > > >On Jun 16, 7:55 am, j <jdc1...(a)gmail.com> wrote: > > >> 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 ave d freq measurements taken > > >> with a counter?) > > > >> regards, > > >> j > > > >Sorry to J and Tim for the spam, I accidentally hit reply to author > > >instead of simply reply. > > > >The input signal is essentially stable with some slow long term drift, > > >You can think of it as a 700KHz signal with a 1KHz sweep width at 1hz. > > >There is however plenty of fast noise that we want to eliminate. Right > > >now I'm not even worried about the long term tracking, and simply > > >feeding the PLL a noisy signal and seeing how well it filters. The > > >signal used on the test bench is fixed with no sweep. > > > >I omitted the details of the progress I made since my comp.dsp post, I > > >admit I wasn't thinking of those that frequent both groups. Yes I did > > >have a open loop frequency jitter problem, but replacing the clock > > >source with a much more stable one I have since solved that problem. > > > >On Jun 16, 8:15 am, Tim Wescott <t...(a)seemywebsite.now> wrote: > > > >> 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 consultingwww.wescottdesign.com > > > >Unfortunately I do need a phase lock. The circuit is acting as the > > >control element in an oscillator loop, so it will be feeding an > > >oscillator that is then feeding the pll. Having the two signals out of > > >phase would not properly drive the oscillator. > > > >The PLL from the papers is essentially how you described it. However > > >the nco is set with an adjustable constant rather than constantly > > >updated by the loop filter, this decreases the lock in range, but > > >improves the tracking and supposedly the noise reduction. The loop > > >filter then inhibits or adds fast clock pulses to the nco in order to > > >lock onto the signal. I was originally using a more traditional pll, > > >but since this design still had a variable center frequency and since > > >we would know that frequency beforehand, the possibility of a cycle > > >slip causing the a coarse frequency shift was not very appealing when > > >compared to this alternative. The design however still has clearly > > >seperated phase comparator, loop filter, and nco. > > > If you know in advance what the sweep pattern is, you can add that > > into the nco input, to feedforward-track the expected signal. Then the > > PLL can be a lot narrower-band and have less tracking error and/or > > less jitter. > > > Is your nco a DDS phase accumulator? That was difficult in the 70's, > > trivial in an FPGA now. > > > John > > I know in general what the sweep is (i.e. its slow and within 1Khz), > but it is a natural process and therefore far from regular or > predictable. > > Since the oscillator I'm driving only requires a square wave to drive > (with a 10% duty) my "NCO" is simply a counter and a flipflop. In an > open loop it is simply dividing the base system clock to whatever > center frequency I set, with a signal in the loop the loop filter > inhibits or adds clock pulses into the counter, thus modulating the > phase and (to a smaller extent) the frequency. > > Andrey Shmakov > University of California Berkeley > Department of Physics- Hide quoted text - > > - Show quoted text - Andrey, Since your in the experimenting / discovery process: And you know that the loop is stable and that your short term stability of your nco is better than your ref why dont you just reduce the loop bandwidth by a factor of 10 and see what happens. Of course this is an empirical approach, but you should see a improvement in your jitter. The correct way to do this is to characterize the noise profile of the nco at the freq of operation which would then allow you to tailor the loop cross overs for your app.. But at least this will tell you if your on the right track and shouldn't be that difficult. Regards j |