M&M clock recovery for async digital signal

GNU Radio
#1

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

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

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ž

#2

On Thu, Feb 26, 2015 at 1:41 AM, Tomaž Šolc [email protected] 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.

#3

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ž

#4

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ž