On Fri, Sep 21, 2012 at 8:15 AM, Kyle Z. [email protected] wrote:
The setting for the old loop is alpha=0.01, beta=alphaalpha/4,
any problems. If you can pin-point what’s going wrong, though, I’ll be
sure to fix it.
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
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.
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