From: Terry Given on
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
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

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