Re: [Discuss-gnuradio] Burst FSK Receiver Clock Synchronization Problems

[Andy Walls]

Ryan Wilson wrote:
> Hi all,
> 
> 
> I am currently attempting to get a bit stream from a captured RF
> signal that I know is from a burst FSK transmitter( 433.92 MHz
> carrier, 10kHz deviation, Manchester).
> 
> Using GNU Radio 3.7.8.
> 
> 
> I have isolated the signal and would say I have successfully
> demodulated the signal. I am not sure of the bit rate but approximated
> it from the preamble
> 
> and then ran the signal through a matched low-pass filter (I
> approximated the bit rate of 20k) giving me this output below:
> 
> 
> https://www.dropbox.com/s/jubmjxt0y4lrg95/200ksamp_quad_demod_lpf_20khz_cutoff_output.png?dl=0

OK, so you had square looking pulses that you then run through a square
pulse filter to get triangl-ish looking peaks that the clock recovery
blocks need.

> It is with the clock recovery/binary slicer that things are not going
> my way. I have been digging a lot and see people have questions about
> the
> 
> M&M clock recovery. I have found some paper and blogs that I have
> followed which seem to be working with signals very similar to mine:
> 
> 
> http://www.inguardians.com/pubs/GRC_signal_analysis_InGuardians _v1.pdf
> 
> 
> https://nccgroup.github.io/RFTM/fsk_receiver.html
> 
> 
>  I have also read many threads from the gnuradio mailing list and it
> seems like the M&M clock recovery works the best with around 2-4sps (I
> have not
> 
> adjusted any of the other values from this block at this time). The
> amplitude of my signal is between +/- 1 going into the clock
> recovery .So I have
> 
> decimated to give me a sampling rate of 100k and 5sps and ran my
> demodulated signal into the M&M clock recovery block:
> 
> 
> 
> https://www.dropbox.com/s/o1eyhmgpzsaaghf/mm_clock_recovery_5sps_output.png?dl=0
> 

The matched filtering on the square pulses: Good
Scaling and centering the signal to +/-1.0: Good
Decimating down to 5 sps: Hrm.. probably not necessary.
Not adjusting any other M&M clock recovery block params: Bad.

It's obvious to me that the gains in the M&M clock recovery block are
set too high.

Here are the meanings of the parameters:

Omega: the nominal samples per signal you expect the modulation to be
using

Gain Omega: a control loop value that dictates how reactive the block
will be in adjust the Omega value to try and track the actual samples
per signal of the incoming signal.

Mu: The initial intersample fraction at which the block interpolates an
output value.  This value is always between 0.0 and 1.0.  Starting at
0.5 is just fine.

Gain Mu: a control loop value that dictates how reactive the block will
be in adjusting the Mu value to determine where the block will
interpolate between to samples to produce an output value.

Omega relative limit: how far the block is allowed to deviate from the
nominal Omega as +/- x%.  I.e. 5.0 sps +/- 1%, your would specify 0.01
for this value a 5.0 for Omega.


So create yourself some GUI Range widgets for the two gain parameters,
and maybe one for the omega relative limit as well.  Continually pipe
the same signal through the chain and watch the output as you adjust the
sliders.

I figure the Omega Gain is what matters in your case.  You should notice
that it is a trade off between how fast the block locks in on the
clock-phasing preamble, vs. how fast the block wanders off during long
runs of 1's or 0's.

To avoid that trade-off somewhat, you can use the corr_est block to flag
your preamble symbols, which should reset the M&M tracking loop in the
GNURadio block.  That way you can use a lower Gain Omega, if you need
to, to keep the M&M block from wandering off, once tracking in a burst.

BTW, this PDF gives a short explanation of the M&M error term that is
the feedback in the M&M clock recovery loop on page 5 of the PDF:
http://mobiledevdesign.com/site-files/mobiledevdesign.com/files/archive/mobiledevdesign.com/images/archive/0901Litwin32.pdf


Regards,
Andy

> I am not sure why it looks so bad.  So then I found others
> recommending the polyphase sync block instead of the M&M clock
> recovery block. I have tried
> 
> loop bandwidth between 2pi/100 to 2pi/200, 5 sps, and low-pass filter
> taps with 20khz cut-off with similar results:
> 
> 
> https://www.dropbox.com/s/oqbnqar7cvfi9tf/pfb_5sps_output.png?dl=0
> 
> 
> I do not know much about the polyphase sync block and I could have not
> configured it correctly. And now
> 
> that is why I am worried that I may have something else misconfigured.
> Here is my flowgraph:
> 
> 
> https://www.dropbox.com/s/yc530rjs7vqvmn6/fsk_demod_flowgraph.png?dl=0
> 
> 
> I just ran into the work that was done for better support burst modems
> (which is what my transmitter is):
> 
> https://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1310
> 
> 
> http://oshearesearch.com/2015/05/31/building-a-burst-fsk-modem-in-gnu-radio-with-message-lambda-blocks-and-eventstream/
> 
> 
> So I will be attempting to get my flow graph running with this FSK
> burst modem and report back with results. But any other input or 
> 
> recommendations would be greatly appreciated.
> 
> 
> 
> Thanks,
> 
> 
> 
> Ryan Wilson
> 
>