[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] frequent phase slip with the new digital.costas_l
Re: [Discuss-gnuradio] frequent phase slip with the new digital.costas_loop_cc
Fri, 21 Sep 2012 09:37:12 -0400
On Fri, Sep 21, 2012 at 8:15 AM, Kyle Zhou <address@hidden> wrote:
> On 21/09/2012, at 12:45 AM, Tom Rondeau wrote:
>> On Thu, Sep 20, 2012 at 9:56 AM, Kyle Zhou <address@hidden> wrote:
>>> 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?
>> 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.
> 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.
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: