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=alphaalpha/4,
max_freq=2pi0.1, min_freq=-max_freq.
The setting for the new loop is loop bandwidth = 2pi/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
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.
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
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 2pi/100 is too big.
I am not familiar with the control loop bandwidth stuff. But change it
to 2pi/1000 makes things working.
For a QPSK, Eb/N0=8 dB will cause the loop out of lock if set as
2pi/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 2pi/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
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
The setting for the old loop is alpha=0.01, beta=alphaalpha/4,
max_freq=2pi*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:
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.