# GnuRadio: Clock Recovery MM: imu out of bounds

**URL:** <https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061>\
**Category:** GNU Radio\
**Created:** [August 19, 2015, 9:13am UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061 "2015-08-19T09:13:08Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\
**Post date:** [August 19, 2015, 9:13am UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061/1 "2015-08-19T09:13:08Z")

</div>

I have created a flowgraph, based on an example of Michael O.,  
which takes in a signal, and should output bits.I need to use the clock  
recovery MM block, which I do not fully understand yet. However, after  
reading some blogposts, I am quite sure that I can leave most of the  
settings default, except for the Omega one. Here’s my flowgraph:  
[http://imgur.com/pHRXnZu](http://imgur.com/pHRXnZu)

When running this flowgraph, it gives me the following error:

thread[thread-per-block[5]:\<block clock\_recovery\_mm\_ff (9)\>]:  
mmse\_fir\_interpolator\_ff: imu out of bounds.

While searching, I stumbled upon this piece of code in the source of  
GnuRadio:

int imu = (int)rint(mu \* NSTEPS);  
if((imu \< 0) || (imu \> NSTEPS)) {  
throw std::runtime\_error(“mmse\_fir\_interpolator\_ff: imu out of  
bounds.\n”);  
}

So, I suspect it is not due to my Omega setting (which might be wrong, I  
have to play with that setting), but that it is due to my Mu setting,  
which is just the default (0.5). However, I understand that Mu needs to  
be between 0 and 1, so I do not really understand what the problem is.  
Anyone who does?Environment details:GNU Radio Companion 3.7.7.1Running a  
GNU Radio live DVD in a virtual machine (VirtualBox 4.2.12) on Windows  
7.Using Volk machine: ssse3\_64

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [August 19, 2015, 3:42pm UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061/2 "2015-08-19T15:42:48Z")

</div>

On Wed, Aug 19, 2015 at 2:51 AM, Michael B [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> have to play with that setting), but that it is due to my Mu setting, which

Michael,

I don’t have an answer, but I can say where you’re doing something  
wrong.  
You’re samples/symbol (samp\_per\_sym) is definitely /not/ 2.5k. That’s a  
massively oversampled signal and can’t be right. You need to think  
what’s  
the sampling rate of the system? What’s the symbol rate of my signal?  
That  
will tell you the samples/symbol you need. It should small, like 2 or 4.

Tom

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [August 20, 2015, 10:07pm UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061/3 "2015-08-20T22:07:49Z")

</div>

Hi Tom,

Thanks for your answer. That’s indeed something that I need to think  
about more. However, as I understand it, the samples per symbol rate is  
equal to (samp\_rate / data\_rate). My sample rate is 500k, and my data  
rate (i think) is only around 100 or 200. See this figure of my  
(cleaned) signal:

[http://imgur.com/8pNqCop](http://imgur.com/8pNqCop)

You see that it takes approximately 10 ms to transmit one symbol. This  
means 100 symbols per second. As I have 500k samples per second, this  
means 5k samples per symbol, right?

However, I have tried setting the samples per symbol to 4, just to try,  
and the ‘out of bounds’ error still persists.

Regards,  
Michael

From: removed\_email\_address@domain.invalid  
Date: Wed, 19 Aug 2015 09:41:19 -0400  
Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out of  
bounds  
To: removed\_email\_address@domain.invalid  
CC: removed\_email\_address@domain.invalid

On Wed, Aug 19, 2015 at 2:51 AM, Michael B [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

I have created a flowgraph, based on an example of Michael O.,  
which takes in a signal, and should output bits.I need to use the clock  
recovery MM block, which I do not fully understand yet. However, after  
reading some blogposts, I am quite sure that I can leave most of the  
settings default, except for the Omega one. Here’s my flowgraph:  
[http://imgur.com/pHRXnZu](http://imgur.com/pHRXnZu)

When running this flowgraph, it gives me the following error:

thread[thread-per-block[5]:\<block clock\_recovery\_mm\_ff (9)\>]:  
mmse\_fir\_interpolator\_ff: imu out of bounds.

While searching, I stumbled upon this piece of code in the source of  
GnuRadio:

int imu = (int)rint(mu \* NSTEPS);  
if((imu \< 0) || (imu \> NSTEPS)) {  
throw std::runtime\_error(“mmse\_fir\_interpolator\_ff: imu out of  
bounds.\n”);  
}

So, I suspect it is not due to my Omega setting (which might be wrong, I  
have to play with that setting), but that it is due to my Mu setting,  
which is just the default (0.5). However, I understand that Mu needs to  
be between 0 and 1, so I do not really understand what the problem is.  
Anyone who does?Environment details:GNU Radio Companion 3.7.7.1Running a  
GNU Radio live DVD in a virtual machine (VirtualBox 4.2.12) on Windows  
7.Using Volk machine: ssse3\_64

Michael,  
I don’t have an answer, but I can say where you’re doing something  
wrong. You’re samples/symbol (samp\_per\_sym) is definitely /not/ 2.5k.  
That’s a massively oversampled signal and can’t be right. You need to  
think what’s the sampling rate of the system? What’s the symbol rate of  
my signal? That will tell you the samples/symbol you need. It should  
small, like 2 or 4.  
Tom

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [August 21, 2015, 3:33am UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061/4 "2015-08-21T03:33:51Z")

</div>

On Thu, Aug 20, 2015 at 3:09 AM, Michael B [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> means 100 symbols per second. As I have 500k samples per second, this means  
> 5k samples per symbol, right?
> 
> However, I have tried setting the samples per symbol to 4, just to try,  
> and the ‘out of bounds’ error still persists.
> 
> Regards,  
> Michael

Decimate decimate decimate. You should down sample your signal as soon  
as  
possible to something reasonable. You want your sample rate to be large  
enough to hold the information, but not too large that you’re just  
wasting  
cycles. Take your input signal down to reasonably represent the slow  
data  
rate so that the actual sps is correct. You can just set these numbers  
arbitrarily.

Tom

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [August 21, 2015, 8:01am UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061/5 "2015-08-21T08:01:27Z")

</div>

Hi Tom,

Thanks for your help. I’ve adapted the sample rate of the result coming  
out of the low-pass filter now. However, if I decimate much further, my  
signal becomes a bit too weak I think.  
New chart:  
[http://imgur.com/mbt288s,etHbYLT#0](http://imgur.com/mbt288s,etHbYLT#0)

New result:  
[http://imgur.com/mbt288s,etHbYLT#1](http://imgur.com/mbt288s,etHbYLT#1)

Is this a better approach?  
The initial error still persists though.

Regards

From: removed\_email\_address@domain.invalid  
To: removed\_email\_address@domain.invalid  
Date: Thu, 20 Aug 2015 09:09:42 +0200  
CC: removed\_email\_address@domain.invalid  
Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out of  
bounds

Hi Tom,

Thanks for your answer. That’s indeed something that I need to think  
about more. However, as I understand it, the samples per symbol rate is  
equal to (samp\_rate / data\_rate). My sample rate is 500k, and my data  
rate (i think) is only around 100 or 200. See this figure of my  
(cleaned) signal:

[http://imgur.com/8pNqCop](http://imgur.com/8pNqCop)

You see that it takes approximately 10 ms to transmit one symbol. This  
means 100 symbols per second. As I have 500k samples per second, this  
means 5k samples per symbol, right?

However, I have tried setting the samples per symbol to 4, just to try,  
and the ‘out of bounds’ error still persists.

Regards,  
Michael

From: removed\_email\_address@domain.invalid  
Date: Wed, 19 Aug 2015 09:41:19 -0400  
Subject: Re: [Discuss-gnuradio] GnuRadio: Clock Recovery MM: imu out of  
bounds  
To: removed\_email\_address@domain.invalid  
CC: removed\_email\_address@domain.invalid

On Wed, Aug 19, 2015 at 2:51 AM, Michael B [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

I have created a flowgraph, based on an example of Michael O.,  
which takes in a signal, and should output bits.I need to use the clock  
recovery MM block, which I do not fully understand yet. However, after  
reading some blogposts, I am quite sure that I can leave most of the  
settings default, except for the Omega one. Here’s my flowgraph:  
[http://imgur.com/pHRXnZu](http://imgur.com/pHRXnZu)

When running this flowgraph, it gives me the following error:

thread[thread-per-block[5]:\<block clock\_recovery\_mm\_ff (9)\>]:  
mmse\_fir\_interpolator\_ff: imu out of bounds.

While searching, I stumbled upon this piece of code in the source of  
GnuRadio:

int imu = (int)rint(mu \* NSTEPS);  
if((imu \< 0) || (imu \> NSTEPS)) {  
throw std::runtime\_error(“mmse\_fir\_interpolator\_ff: imu out of  
bounds.\n”);  
}

So, I suspect it is not due to my Omega setting (which might be wrong, I  
have to play with that setting), but that it is due to my Mu setting,  
which is just the default (0.5). However, I understand that Mu needs to  
be between 0 and 1, so I do not really understand what the problem is.  
Anyone who does?Environment details:GNU Radio Companion 3.7.7.1Running a  
GNU Radio live DVD in a virtual machine (VirtualBox 4.2.12) on Windows  
7.Using Volk machine: ssse3\_64

Michael,  
I don’t have an answer, but I can say where you’re doing something  
wrong. You’re samples/symbol (samp\_per\_sym) is definitely /not/ 2.5k.  
That’s a massively oversampled signal and can’t be right. You need to  
think what’s the sampling rate of the system? What’s the symbol rate of  
my signal? That will tell you the samples/symbol you need. It should  
small, like 2 or 4.  
Tom

---

<div class="post-metadata">

**Author:** ![casper\_the\_ghost](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/58956e/32.png) [@casper\_the\_ghost](https://www.ruby-forum.com/u/casper_the_ghost)\
**Post date:** [September 7, 2015, 10:40am UTC](https://www.ruby-forum.com/t/gnuradio-clock-recovery-mm-imu-out-of-bounds/243061/6 "2015-09-07T10:40:17Z")

</div>

Hi Michael,

so, this having sat on my “what the hell, I need to look at this” list  
for the weekend:  
I can’t reproduce the behaviour, but that might simply have the cause of  
me using white noise instead of your recording. Could you share that?

I have two hypotheses and one observation so far:  
The observation is that in many places where we want to get the closest  
int to a float, we use stuff like int imu= rint(mu\*NSTEPS), which is  
wrong in respect to the return value (double), the parameter type  
(double) and in most cases also the side effects (rint is the version of  
nearbyint that sets error flags, but we don’t check them). We should use  
something else; that’s an overhaul of existing code that’ll have to be  
done another day.

So first hypothesis:  
It’s your signal that will suffice for us to reproduce the error. That’s  
the “good” case, because then one can actually inspect what goes wrong  
here.

Second hypothesis:  
Based on above observation and VirtualBox’ history of delicate floating  
point bugs, this might get a bit more involved, especially since  
floating point exception registers are involved, which historically were  
hard to properly multithread/make ISR save; maybe the overhaul mentioned  
above would solve the issue, though.

Best regards,  
Marcus