From: Ken Smith on 8 Feb 2006 21:38 In article <1139427882.792589.126890(a)f14g2000cwb.googlegroups.com>, Ron N. <rhnlogic(a)yahoo.com> wrote: >Tim Wescott wrote: >> 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. > >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). Now fit that FFT into a PIC. -- -- kensmith(a)rahul.net forging knowledge
From: Allan Herriman on 8 Feb 2006 22:55 On 8 Feb 2006 17:48:03 -0800, "Ron N." <rhnlogic(a)yahoo.com> wrote: >Tim Wescott wrote: >> Ron N. wrote: >> > 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? >... >> 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. > >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? 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
From: Ron N. on 9 Feb 2006 03:07 Ken Smith wrote: > In article <1139427882.792589.126890(a)f14g2000cwb.googlegroups.com>, > Ron N. <rhnlogic(a)yahoo.com> wrote: > >Tim Wescott wrote: > >> 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. > > > >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). > > Now fit that FFT into a PIC. 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
From: Terry Given on 9 Feb 2006 03:53 Ron N. wrote: > Tim Wescott wrote: > >>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. > > > 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 > 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
From: Ron N. on 9 Feb 2006 15:00 Terry Given wrote: > Ron N. wrote: > > Tim Wescott wrote: > >>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. .... > > 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). .... > 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. If a simple feedback PLL is such a good solution, why isn't it used more often for general frequency estimation and interpolation problems? IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-M
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: MELP / MELPe vocoder and IMBE vocoder Next: Audio Fingerprinting Technology |