Re: analog_pll_carriertracking_cc bug

[Michael Carosino]

Initially sent this to David only, so resending: The frequency limits should be normalized sample rate in radians, I.e. 2*pi*f_hertz/sample_rate. Additionally, make sure you use a somewhat reasonable loop bandwidth, typically something like 2*pi/100.

Also for reference the PLL indeed has Proportional +integral gains that are determined by the loop bandwidth parameter ( they're calculated for a critically damped system).

On Sat, Apr 4, 2020, 7:01 AM David Hagood <address@hidden> wrote:

I was trying to use the PLL carrier tracking block, and found that it
doesn't seem to work at all. I have a simple flow graph demonstrating
this - what would be the best way to share it?


It's pretty easy to demonstrate: take a signal generator generating a
complex sinusoid at some frequency "f". Connect that to the PLL, and set
the PLL to track that frequency (min freq = .99*f/samp_rate, max freq =
1.01*f/samp_rate). Feed the input through a complex conjugate and then
multiply that by the PLL output, and look at the result with a complex
constellation and/or complex spectrum.


If the PLL is actually frequency locked, you would expect the output to
be a DC signal at some phase offset, which would show up as a
constellation cloud at a fixed angle. If the PLL is truely phase locked
the result should be 1+i0.


It isn't. For my example, I was doing 19kHz tone at 200kHz sample rate,
and I had a frequency error of 3 kHz - almost 20% of the desired frequency!


I haven't dug into the implementation of the PLL - if it's analogous to
a hardware PLL, then I would say it's missing an integrator on the
feedback path.