Re: analog_pll_carriertracking_cc bug

[Paul Boven]

Hi David, list,

On 4/4/20 10:18 PM, David Hagood wrote:
> I applied your correction of multiplying by 2pi, and while it locks now, 
> it also doesn't seem to be very clean - there's a lot of noise on the 
> signal, and the phase compared to the reference still is running through 
> the unit circle. I've tried increasing and decreasing the loop 
> bandwidth, and I cannot get what I would consider a clean signal out.

The PLL blocks took a bit of tinkering for me to get them to work. As 
Michael already explained, frequency is listed in radians per sample, 
instead of Herz. That leaves setting your start and stop frequency, and 
the loop bandwidth.

Although the documentation suggest to use values between pi/200 and 
2pi/100, I've found that you need to go to much lower values to get it 
to do proper filtering.

As an example: To track the FM Stereo pilot signal at 19kHz, I'm using 
these settings:

Sample Rate: 250 kHz
Max Freq: (19000 + 100)*np.pi*2/samp_rate
Min Freq: (19000 - 100)*np.pi*2/samp_rate
Loop Bandwidth: np.pi/20000

I am using the 'PLL Ref Out' block, but that works just the same way as 
the one you are looking at, it just outputs the locked signal at its 
original frequency, instead of at DC.

In the attached graph, you can see the input signal (Data 0, in blue), 
and the PLL filtered 19kHz (in red). The peak of the input and output 
match perfectly, and you can see that the output (Red, Data 1) is much 
cleaner. If I decrease the loop bandwidth even more, the loop does 
unlock, and you can see that the output phase no longer tracks the input 
phase.

Regards, Paul Boven.

GR-PLL-filter.png
Description: PNG image