# M&M clock recovery for async digital signal **URL:** \ **Category:** GNU Radio\ **Created:** [February 26, 2015, 10:44am UTC](https://www.ruby-forum.com/t/m-m-clock-recovery-for-async-digital-signal/234356 "2015-02-26T10:44:02Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [February 26, 2015, 10:44am UTC](https://www.ruby-forum.com/t/m-m-clock-recovery-for-async-digital-signal/234356/1 "2015-02-26T10:44:02Z")
Hi I’m trying to synchronize on the bits in an asynchronous digital signal using M&M clock recovery block. For instance, roughly 7 samples of +1. represent a “1” and roughly 7 samples of -1. represent a “0”. I’ve reduced the problem the following test case: a square (or sine) wave generator with a period of 14 samples (a continuous series of 7 sample "1"s and "0"s) and a clock recovery block with the initial value of omega = 7. This is a fair reproduction of what I see on sync headers in my signal, which are a long series of such 101010s [![](https://www.tablix.org/~avian/gnuradio/clock_recovery_test2.grc.png) ](https://www.tablix.org/~avian/gnuradio/clock_recovery_test2.grc.png) Am I wrong to assume that the clock recovery should in this case return roughly [+1, -1, +1, -1, …] (synchronizing on the crests of the input signal)? This does not seem to happen, neither for a square wave nor a sine wave. The clock recovery never seems to settle on the correct frequency and phase, even when the initial omega matches input frequency perfectly. I’ve tried plenty of different settings for mu and omega gains. The sync just drifts more or less slowly. [![](https://www.tablix.org/~avian/gnuradio/clock_recovery_test2.grc_scope.png) ](https://www.tablix.org/~avian/gnuradio/clock_recovery_test2.grc_scope.png) I see M&M clock recovery is a pretty common source of questions, but I failed to find a good answer on how to use it. A suggestion I saw is to write your own synchronizer. I can do that but I don’t want to reinvent the wheel if a well researched one already exists. Am I misunderstanding what M&M clock recovery is supposed to do? Is there another existing block that is more suited for this kind of bit synchronization? Thanks Tomaž ---
**Author:** ![TomaSSSSolc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b5ac83/32.png) [@TomaSSSSolc](https://www.ruby-forum.com/u/TomaSSSSolc)\ **Post date:** [February 26, 2015, 5:26pm UTC](https://www.ruby-forum.com/t/m-m-clock-recovery-for-async-digital-signal/234356/2 "2015-02-26T17:26:32Z")
On Thu, Feb 26, 2015 at 1:41 AM, Tomaž Šolc [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I’m trying to synchronize on the bits in an asynchronous digital signal > using M&M clock recovery block. For instance, roughly 7 samples of +1. > represent a “1” and roughly 7 samples of -1. represent a “0”. In general, timing recovery algorithms attempt to locate and track the “center” of a symbol and output an estimate of what the symbol value is at that point. They also work best when they are preceded by a symbol matched filter; this both improves signal-to-noise ratio and results in a peak near the center that the recovery loop is designed to find. In your case, your symbol is a rectangular pulse 7 samples wide, of bipolar amplitude. A matched filter for this symbol shape is simply a moving average filter of the same period. If you add one of these ahead of the MM block, it will sync up quite easily. ---
**Author:** ![TomaSSSSolc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b5ac83/32.png) [@TomaSSSSolc](https://www.ruby-forum.com/u/TomaSSSSolc)\ **Post date:** [February 26, 2015, 6:17pm UTC](https://www.ruby-forum.com/t/m-m-clock-recovery-for-async-digital-signal/234356/3 "2015-02-26T18:17:51Z")
On 26. 02. 2015 17:24, Johnathan C. wrote: > matched filter; this both improves signal-to-noise ratio and results in > a peak near the center that the recovery loop is designed to find. > > In your case, your symbol is a rectangular pulse 7 samples wide, of > bipolar amplitude. A matched filter for this symbol shape is simply a > moving average filter of the same period. If you add one of these ahead > of the MM block, it will sync up quite easily. Thank you for your answer Jonathan. I suspected that the algorithm doesn’t work on rectangular pulses. This is why I performed my test with a sine wave as well as a rectangular wave (see the block diagram I linked to) I think a sine wave of the same frequency as a rectangular wave should be very close to what is at the output of a symbol matched filter you mention. However in the setup I described, the MM block doesn’t sync to a sine wave either. Best regards Tomaž ---
**Author:** ![TomaSSSSolc](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/b5ac83/32.png) [@TomaSSSSolc](https://www.ruby-forum.com/u/TomaSSSSolc)\ **Post date:** [March 2, 2015, 12:18pm UTC](https://www.ruby-forum.com/t/m-m-clock-recovery-for-async-digital-signal/234356/4 "2015-03-02T12:18:47Z")
Hi I’ve been trying to further debug the problem I’m having with the M&M clock recovery block. It seems to me that the core of the problem is that the interpolation between samples isn’t working correctly. Current code does that with a “mmse\_fir\_interpolator\_ff” block. However, if I test it with the following: (based on what clock\_recovery\_mm\_ff\_impl.cc does) printf(“in[ii+0] = %f\n”, in[ii]); float mu; for(mu = 0.; mu \< 1.; mu += 0.1) { float out\_ = d\_interp-\>interpolate(&in[ii], mu); printf(“mu=%f out=%f\n”, mu, out\_); } printf(“in[ii+1] = %f\n”, in[ii+1]); I get something like this: in[ii+0] = -1.000000 mu=0.000000 out=-0.223138 mu=0.100000 out=-0.178490 mu=0.200000 out=-0.133470 mu=0.300000 out=-0.091666 mu=0.400000 out=-0.046198 mu=0.500000 out=-0.000634 mu=0.600000 out=0.044932 mu=0.700000 out=0.090404 mu=0.800000 out=0.132214 mu=0.900000 out=0.177242 in[ii+1] = -0.901245 I would expect that “out” values would be (roughly) between the two “in”, but as far as I can see, the output values don’t have any relation to the input. This obviously breaks the algorithm. If I replace the d\_interp-\>interpolate() call with a simple linear interpolation between in[ii] and in[ii+1], the clock recovery block actually works correctly. Given correct gains it locks on the sine wave in the test from my previous mail. So, my question now is, can someone confirm that this is in fact a bug? The outputs above have been produced on a fresh build of v3.7.5.1 (Debian Wheezy, x86\_64). Thanks Tomaž