Hello,

I would like to find a proper documentation on MM algorithm block (paper

for example). Any ideas ?

Thank you.

Regards.

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

- PFB!
- 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 …

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.

Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs