Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM

2014-10-11 Thread Robert McGwier
Ooops.   Good catch Bastian.

On Fri, Sep 26, 2014 at 2:29 PM, Tom Rondeau  wrote:

> On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl 
> wrote:
>
>>
>> On 09 Sep 2014, at 15:42, Tom Rondeau  wrote:
>>
>> > On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl 
>> 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
>
>


-- 
Bob McGwier
Co-Owner and Technical Director, Federated Wireless, LLC
Professor Virginia Tech
Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY
Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM

2014-09-27 Thread Tom Rondeau
On Fri, Sep 26, 2014 at 7:26 PM, Dan CaJacob  wrote:

> Does this change affect the recommended block settings to make the magic
> happen?
>
> Very Respectfully,
>
> Dan CaJacob
>

No, this doesn't change the behavior too much. I suspect your settings will
continue to work just fine.

Tom




> On Fri, Sep 26, 2014 at 2:29 PM, Tom Rondeau  wrote:
>
>> On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl 
>> wrote:
>>
>>>
>>> On 09 Sep 2014, at 15:42, Tom Rondeau  wrote:
>>>
>>> > On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl 
>>> 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
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM

2014-09-26 Thread Dan CaJacob
Does this change affect the recommended block settings to make the magic
happen?

Very Respectfully,

Dan CaJacob

On Fri, Sep 26, 2014 at 2:29 PM, Tom Rondeau  wrote:

> On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl 
> wrote:
>
>>
>> On 09 Sep 2014, at 15:42, Tom Rondeau  wrote:
>>
>> > On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl 
>> 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] [SOLVED] Clock Recovery MM

2014-09-26 Thread Tom Rondeau
On Tue, Sep 9, 2014 at 3:21 PM, Bastian Bloessl 
wrote:

>
> On 09 Sep 2014, at 15:42, Tom Rondeau  wrote:
>
> > On Mon, Sep 8, 2014 at 5:49 PM, Bastian Bloessl 
> 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