[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
Mon, 24 Sep 2012 00:19:43 +1000
On 21/09/2012, at 11:37 PM, Tom Rondeau wrote:
> On Fri, Sep 21, 2012 at 8:15 AM, Kyle Zhou <address@hidden> wrote:
>> 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
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
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
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
Description: Binary data