# Clock Recovery MM documentation

**URL:** <https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814>\
**Category:** GNU Radio\
**Created:** [July 30, 2015, 7:16pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814 "2015-07-30T19:16:19Z")\
**Posts on this page:** 13\
**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:** [July 30, 2015, 7:16pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/1 "2015-07-30T19:16:19Z")

</div>

Hello,

I would like to find a proper documentation on MM algorithm block (paper  
for example). Any ideas ?

Thank you.

Regards.

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 1:21pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/2 "2015-07-31T13:21:58Z")

</div>

Hi Klauss,

You could also take a look at  
[https://www.tablix.org/~avian/blog/archives/2015/03/notes\_on\_m\_m\_clock\_recovery/](https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/),  
it helped me quite a bit!

Best regards…

Daniel

On Thu, Jul 30, 2015 at 7:17 PM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > 
> 
> Discuss-gnuradio mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

–  
Best regards…

```
                 Daniel

```

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 1:27pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/3 "2015-07-31T13:27:48Z")

</div>

Another point to keep in mind is that the M&M block isn’t great in  
fading  
environments. It’s really suboptimal in general. Look at the  
pfb\_clock\_recovery block, instead.

Tom

On Thu, Jul 30, 2015 at 2:18 PM, Daniel C. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 1:43pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/4 "2015-07-31T13:43:00Z")

</div>

Research paper CONVERTING RADIO SIGNALS TO DATA PACKETS (Examination of  
Using GNU Radio Companion for Security Research and Assessment) deals  
with  
Clock Recovery MM, I attached the paper, have a look at:

6.Section 6.Counting the Bits  
7.Analyzing Demodulated Data

Both deal with Clock Recovery MM usage and has flowgraphs.

Best regards,

Iluta

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 2:06pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/5 "2015-07-31T14:06:22Z")

</div>

Hi, Tom,

Could you be more specific where exactly it is not “the right  
algorithm”?  
We’d appreciate that and would correct that in own work as well, if  
Security Research Assessment made a mistake here.

I will be looking forward to your response,

Iluta

On Thu, Jul 30, 2015 at 9:55 PM, Tom R. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> >

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 1:59pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/6 "2015-07-31T13:59:21Z")

</div>

On Thu, Jul 30, 2015 at 2:38 PM, Iluta V [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Iluta

That’s great, and I’m glad they got it to work for their application.  
Looks  
like they provide a good explanation of its use, too. Still, it’s not  
the  
right algorithm.

Tom

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 5:21pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/7 "2015-07-31T17:21:30Z")

</div>

From Matlab MM documentation [1]:

“[…] Typically, the input signal is the output of a receive filter  
that  
is matched to the transmitting pulse shape. […]”

Assuming the MM Gnuradio implementation has the same hypothesis on the  
input signal (anybody can confirm this?), I deduced this block is  
usually  
misused when feed with a square signal, because it will take only one  
sample per symbol discarding the rest (with useful energy). You can put  
a  
Moving Average before for better results.

This is one of the reason why the pfb\_clock\_recovery block is better,  
but  
unfortunately unfit for square signals [2]. I found even better results  
using a gaussian filter inside pfb\_clock\_recovery as the pseudo-matched  
filter to square pulses (with a proper bt value). (Obviously I can only  
guarantee this for the specific signal I worked with)

[1]  
[http://www.mathworks.com/help/comm/ref/muellermullertimingrecovery.html](http://www.mathworks.com/help/comm/ref/muellermullertimingrecovery.html)  
[2] See discussion: [http://gnuradio.org/redmine/issues/812](http://gnuradio.org/redmine/issues/812)

2015-07-30 16:03 GMT-03:00 Iluta V [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 6:10pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/8 "2015-07-31T18:10:35Z")

</div>

On Thu, Jul 30, 2015 at 3:03 PM, Iluta V [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Hi, Tom,
> 
> Could you be more specific where exactly it is not “the right algorithm”?  
> We’d appreciate that and would correct that in own work as well, if  
> Security Research Assessment made a mistake here.
> 
> I will be looking forward to your response,
> 
> Iluta

Iluta,

I shouldn’t be so hard on the M&M block. In most situations, it’s tended  
to  
work fine, but it’s suboptimal. It’s based on hardware techniques of  
clock  
recovery that approximate a derivative. The PFB algorithm actually  
calculates the derivative to the numerical approximation required by  
setting the number of filterbank arms. So the results are much better.  
You  
also get to apply your own filter to this block so you don’t have to  
apply  
a separate matched filter.

Also, and I can’t find any papers on this, but fred harris tells me that  
the M&M algorithm behaves particularly poorly in fading environments.

Tom

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 5:29pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/9 "2015-07-31T17:29:06Z")

</div>

Thanks for your explanation! That’s worth while looking into!

On Fri, Jul 31, 2015 at 1:17 AM, Francisco A. \<

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 7:52pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/10 "2015-07-31T19:52:15Z")

</div>

Hi Tom,

why do/I/ have to advertise the PFB approach? Arguing against Mueller &  
M?ller feels strange. Anyway:

Mueller & M?ller in the classical, real valued approach [1, eq (49), p.  
524] in its core is  
eqn. (49) page 524

with $z\_k$ being the timing estimate ,$x\_k$ being the input samples, and  
$a\_k$ the decisions (in our case, -1/+1 [2], so $E{a\_k^2}\equiv 1$).  
Assume timing is correct, ie. $z\_{k-1} = 0$, but we have fading so that  
$|x\_k| = \epsilon |x\_{k-1}|,\quad 0\<\epsilon \ll 1$;  
then regardless of $a\_{k-1}$, the term $|x\_k a\_{k-1}| \ll|x\_{k-1}a\_k|$,  
and hence  
$z\_k \approx -\frac12 {x\_{k-1}a\_k}$

Now, $a\_k$ is exactly the decision we don’t want to put much trust in,  
because it’s a symbol decision with especially bad $\frac{E\_s}{N\_0}$.  
Effectively, you get the bit error probability increase as a factor to  
your timing error probability density, as if things weren’t bad enough!

PFB is cooler because

1. PFB!
2. the derivate is a linear operation, so amplitude changes in the  
input signal at least have the same effect on the error correction  
magnitude.

Cheers,  
Marcus

[1] [http://2n3904.net/library/MM\_Clock\_Recovery.pdf](http://2n3904.net/library/MM_Clock_Recovery.pdf)  
[2]  
[gnuradio/gr-digital/lib/clock\_recovery\_mm\_ff\_impl.cc at master · gnuradio/gnuradio · GitHub](https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L83)

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 9:28pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/11 "2015-07-31T21:28:35Z")

</div>

Wow ! Thank you all for your reply. Very interesting !

Tom, I didn’t find the “pfb\_clock\_recovery block” in my GNU Radio  
Companion, is it new ?

Best regards.

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 9:46pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/12 "2015-07-31T21:46:31Z")

</div>

Hi Marcus,

Aaaaa it’s the Polyphase Clock Sync, I didn’t think about it … 😃  
Thank you for the advice, I will use the mailing list next time.

Best regards.

Klauss.

---

<div class="post-metadata">

**Author:** ![klaussit](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/k/bc79bd/32.png) [@klaussit](https://www.ruby-forum.com/u/klaussit)\
**Post date:** [July 31, 2015, 9:34pm UTC](https://www.ruby-forum.com/t/clock-recovery-mm-documentation/242814/13 "2015-07-31T21:34:33Z")

</div>

Hi Klauss,

> is it new ?

Not really, no. It’s been around since ca April 2012.  
If there’s no “Polyphase Clock Sync”:  
What version of GNU Radio are you using?

Best regards,  
Marcus

PS: I always recommend not using ruby-forum but directly signing up to  
the mailing list:

> **[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)**

so much more comfortable! And with modern mail clients and webmail  
interfaces, much better searchable.