Clock Recovery MM documentation

Hello,

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

Thank you.

Regards.

Hi Klauss,

You could also take a look at
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. [email protected]
wrote:

Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Best regards…

                 Daniel

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. [email protected]

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

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. [email protected] wrote:

On Thu, Jul 30, 2015 at 2:38 PM, Iluta V [email protected] 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

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
[2] See discussion: http://gnuradio.org/redmine/issues/812

2015-07-30 16:03 GMT-03:00 Iluta V [email protected]:

On Thu, Jul 30, 2015 at 3:03 PM, Iluta V [email protected] 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

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

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

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
[2]
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/clock_recovery_mm_ff_impl.cc#L83

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.

Hi Marcus,

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

Best regards.

Klauss.

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:
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
so much more comfortable! And with modern mail clients and webmail
interfaces, much better searchable.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs