From: Terry Given on 9 Feb 2006 18:34 Ron N. wrote: > 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? > oh, here I was thinking PLLs abound. best not to mention this to the entire telecommunications and control industries. > > IMHO. YMMV. I've seen a guy develop a PLL by using an FFT, in a pic. he had learned about FFTs at uni, but never learned about PLLs. the code eventually worked....after a year or so. Cheers Terry
From: Ron N. on 9 Feb 2006 19:52 Terry Given wrote: > Ron N. wrote: > > 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? > > oh, here I was thinking PLLs abound. best not to mention this to the > entire telecommunications and control industries. Why would one not think that the use of feedback PLLs abound? But I note that the use of fft's, autocorrelation and other statistical techniques are also popular for many problems where the analysis of only one fundamental frequency is of interest. Why use one technique and not the other? Where are the limits of applicability for feedback PLLs, and have those limits changed with the order of magnitude changes in MACs per dollar? IMHO. YMMV. -- rhn A.T nicholson d.0.t C-o-M
From: john on 9 Feb 2006 20:37 Ron N. wrote: > Terry Given wrote: > > Ron N. wrote: > > > 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? > > > > oh, here I was thinking PLLs abound. best not to mention this to the > > entire telecommunications and control industries. > > Why would one not think that the use of feedback PLLs abound? > > But I note that the use of fft's, autocorrelation and other statistical > techniques are also popular for many problems where the analysis > of only one fundamental frequency is of interest. Why use one > technique and not the other? Where are the limits of applicability > for feedback PLLs, and have those limits changed with the order > of magnitude changes in MACs per dollar? > > > IMHO. YMMV. > -- > rhn A.T nicholson d.0.t C-o-M My impression is that traditional PLLs have become less useful for carrier and symbol synchronization is wireless communcation systems as they have evolved to burst transmission, which requires quick estimates, and use of capacity approaching codes, which can operate at SNRs that cause PLLs to slip cycles. John
First
|
Prev
|
Pages: 1 2 3 4 5 Prev: MELP / MELPe vocoder and IMBE vocoder Next: Audio Fingerprinting Technology |