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

[Wilson, Ryan N.]

On 12/7/15, 2:39 PM, "Andy Walls" <address@hidden> wrote:

>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_c
>>utoff_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.p
>>ng?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/mo
>biledevdesign.com/images/archive/0901Litwin32.pdf
>
>
>Regards,
>Andy

Thank you for the information regarding the MM clock recovery parameters
and suggesting to try a symbol rate of 19.2k.

I have change my symbol rate to 19.2k and have added some GUI range
widgets for the Gain Omega, Gain Mu, Omega Relative
Limit and started tinkering with the values. Just to give you an idea of
the transmission bursts, there are 4 ³packets²
Transmitted at a ~15ms interval such as in the figure below:

https://www.dropbox.com/s/e9rit77u3f1j346/4_packet_burst.png?dl=0

Below are some captures containing what clock recovery params were used.
Sometimes the clock recovery output looks better.
And other times, it looks just as bad as it did with the default
parameters. It seems to be very inconsistent:

https://www.dropbox.com/s/pvwm7cjkn535lsi/tpms_MMclockrecoveryoutput_.02ome
gaRelative_.004gainOmega_.07gainMu.png?dl=0

https://www.dropbox.com/s/7aattbr8tnznnvx/tpms_MMclockRecovery_output_5.2sp
s_.03gainOmega_.1gainMu_.01omegaRelativeLimit.png?dl=0

https://www.dropbox.com/s/lrcw46mdxjus80e/tpms_MMclockRecoveryOutput.png?dl
=0

https://www.dropbox.com/s/acoio3px7g2yyzs/MMclock_recovery_omegaRelative.01
_gainOmega.003_gainMu.10.png?dl=0

https://www.dropbox.com/s/187l8j3ha02u29i/MMclock_recovery_omegaRelative.04
_gainOmega.003_gainMu.10.png?dl=0

Omega Relative Limit seemed to have the biggest impact to me as I
increased it. And I do not understand why the amplitude is
Varying so much? I am not quite sure how to proceed forward. I will
continue to adjust these values in hope for a cleaner output
And also look into the corr_est block to flag the preamble symbols.

Thanks,

Ryan


>
>> 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-rad
>>io-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
>> 
>> 
>
>