On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl <bloe...@ccs-labs.org> wrote:
> > On 09 Sep 2014, at 15:42, Tom Rondeau <t...@trondeau.com> wrote: > > > On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl <bloe...@ccs-labs.org> > wrote: > > Hi all, > > > > looking at the clock recovery MM code, I wonder if > d_omega_relative_limit is a relative or absolute deviation from d_omega. > > > > Here it looks like absolute > > > https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L107 > > > > Here it is relative > > > https://github.com/gnuradio/gnuradio/blob/next/gr-digital/lib/clock_recovery_mm_ff_impl.h#L57 > > > > (even though this code has no impact since d_{min,max}_omega is not > used.) > > > > > > I don’t have access to the book linked in the docs atm. > > > > Best, > > Bastian > > > > > > It is supposed to be relative. I'd have to verify the math on that line > 107 in the .cc file, but it's supposed to adjust the center position of the > current omega estimate and then apply the clipping. Then it adds the mid > point back to get it back to where it's centered. Try walking through that > line one more time to verify that it's doing that properly. But yes, it's > supposed to be relative to the original setting of omega. > > > > So this line asserts that the current (absolute) deviation (d_mega - > d_omega_mid) is smaller than the maximum allowed absolute deviation > (d_omega_mid * d_omega_relative_limit). AFAIS, the second argument is > missing “* d_omega_mid”. > > I will create a patch, then you can check if I got you right. > > Bastian > Just to follow up, Bastian was correct and we merged his patch in this week. Tom
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
