Forum: GNU Radio frequent phase slip with the new digital.costas_loop_cc

I adapted my codes from gnuradio-3.3 to the new 3.6 version.
One of the changes is the new digital.costas_loop_cc is now implemented 
based on control_loop.
The costas loop is used for phase recovery of a QPSK signal.
But I noticed that with the new version, the output experiences a lot of 
phase slips.
To be exact, the phase at the output rotate 90 degree from time to time.
I changed it back to the old gr.costas_loop_cc and this did not happen.
The setting for the old loop is alpha=0.01, beta=alpha*alpha/4, 
max_freq=2*pi*0.1, min_freq=-max_freq.
The setting for the new loop is loop bandwidth = 2*pi/100

The new version is only good when SNR is very high, say 13dB+

Any has encountered the same problem? or am I doing something wrong?
KZ

On Thu, Sep 20, 2012 at 9:56 AM, Kyle Zhou <kylenix@gmail.com> wrote:
>
> Any has encountered the same problem? or am I doing something wrong?
> KZ

Hi Kyle,

I was using this just last week in a demonstration and hadn't noticed
any problems. If you can pin-point what's going wrong, though, I'll be
sure to fix it.

Tom

On 21/09/2012, at 12:45 AM, Tom Rondeau wrote:

>> The new version is only good when SNR is very high, say 13dB+
> Tom
Thanks Tom.
I am trying to write a small test case to reproduce the problem 
reliably, and will get back to you shortly.
At the same time, what was the SNR you tried in your demo? The problem 
would not happen when you have a high SNR say 13dB.
KZ

On 21/09/2012, at 12:45 AM, Tom Rondeau wrote:

>> The new version is only good when SNR is very high, say 13dB+
> Tom
After playing the module for a while, I figured out where the problem 
is.
The default setting to the loop bandwidth 2*pi/100 is too big.
I am not familiar with the control loop bandwidth stuff. But change it 
to 2*pi/1000 makes things working.
For a QPSK, Eb/N0=8 dB will cause the loop out of lock if set as 
2*pi/100. Even with 10 dB, the frequency offset varies a lot.
I know it is certain trade off between max captured offset and 
performance. But 2*pi/100 is definitely far from optimal.
I will learn more about control loop to get an idea how the bandwidth 
should be determined.
Any suggestions?
KZ

On 21/09/2012, at 12:45 AM, Tom Rondeau wrote:

>> The new version is only good when SNR is very high, say 13dB+
> Tom
Hi Tom,
I spent some time on reading the code in gri_control_loop. However, the 
calculation from loop bandwidth to alpha and beta is quite complicated 
and from digital_costas_loop_cc I do not see how loop bandwidth is 
related to the loop behavior etc.
Is the implementation based on some paper or text? I am really 
interested to read the theory.
BTW, the phase detector is a decision-directed method. In a costas loop 
the phase error should be detected in a non-data aided way. so the block 
is not a costas loop strictly speaking.
KZ

On Fri, Sep 21, 2012 at 8:15 AM, Kyle Zhou <kylenix@gmail.com> wrote:
>>> The setting for the old loop is alpha=0.01, beta=alpha*alpha/4, 
max_freq=2*pi*0.1, min_freq=-max_freq.
>> any problems. If you can pin-point what's going wrong, though, I'll be
>> sure to fix it.
>>
>> Tom
>
> Hi Tom,
> I spent some time on reading the code in gri_control_loop. However, the 
calculation from loop bandwidth to alpha and beta is quite complicated and from 
digital_costas_loop_cc I do not see how loop bandwidth is related to the loop 
behavior etc.
> Is the implementation based on some paper or text? I am really interested to 
read the theory.
> BTW, the phase detector is a decision-directed method. In a costas loop the 
phase error should be detected in a non-data aided way. so the block is not a 
costas loop strictly speaking.
> KZ

Kyle,

Correct, this is not really a 'Costas Loop', but that algorithm
doesn't really translate into the digital signal world all that well.
It's also not a great algorithm, frankly. What we call the
'costas_loop_cc' block started off as a Costas loop but morphed into
something that's more applicable to software radio.

One question, are you sending critically sampled symbols to the block?
This block is really meant to operate on 1 sps, preferably where that
one sample is at the optimal sampling point. So it's really meant to
come after a timing recovery loop and/or equalizer. This is the
scenario that I've used in the past with low SNRs. I can't tell you
the actual SNR, but visually it would have been down to 5 - 8 dB (just
looking at the constellation) for QPSK signals.

So 2pi/1000 seems very small, but then again, that's why this value is
an adjustable parameter so you can tweak it for your purposes.

If you're looking for more information on the control loop, I have a 
post here:
http://www.trondeau.com/blog/2011/8/13/control-loo...

Tom

On 21/09/2012, at 11:37 PM, Tom Rondeau wrote:

>
> scenario that I've used in the past with low SNRs. I can't tell you
> the actual SNR, but visually it would have been down to 5 - 8 dB (just
> looking at the constellation) for QPSK signals.
>
> So 2pi/1000 seems very small, but then again, that's why this value is
> an adjustable parameter so you can tweak it for your purposes.
>
> If you're looking for more information on the control loop, I have a post here:
> http://www.trondeau.com/blog/2011/8/13/control-loo...
>
> Tom
Hi Tom,
Spent some time during the weekend on reading your post and now 
understand most of the bandwidth stuff.
Thanks for the great work.

Yes, in my system the phase recovery follows the timing recovery at one 
sample per symbol.
I constructed a test in grc in baseband 1sps as attached.
The frequency output from costas loop is connected to scope.
When loop bandwidth is set to 2pi/100, the frequency varies a lot. I 
think this might explain the phase slip problem. Although the 
constellation seems OK, but the phase slip is not tolerable.
A smaller loop bandwidth will improve the frequency variation as well as 
the phase slip.
However, that leads to longer initial catch up time, which is 
proportional to inverse of bandwidth.
For my case, this is fine since it is a continuous transmission system.
But for a packet-wise transmission with short packet length, this could 
be of no use.
KZ