discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: analog_pll_carriertracking_cc bug


From: Michael Carosino
Subject: Re: analog_pll_carriertracking_cc bug
Date: Sat, 4 Apr 2020 15:22:19 -0700

Hi David,

I just tried the example you mentioned of signal source -> pll carrier tracking with the samplerate/freqs you identified and loop_bw 2pi/100, I get a perfect looking constant 1 output (DC) as expected (only varies maybe on the order 1e-5). Is it possible that you set the "Offset" value on the signal source block to be non-zero (apparently if you put a real value into here it will only offset the I-wave and the phase detector in the PLL would have trouble with this). A picture of your flowgraph would be useful if it's still behaving strangely.

Mike

On Sat, Apr 4, 2020 at 2:02 PM Paul Boven <address@hidden> wrote:
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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]