[Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates

[Waqas Bin Abbas]

Hi all,

We have encountered an interesting problem in the clock_recovery_mm block
used in our BFSK system.
What happening is that, at lower data rates (i.e. at less than 54bps) we are
unable to decode the received data correctly,
however at higher data rates data is decoded fine.


What we are doing ?


We are implementing a BFSK receiver and our flow-graph consist of
Bandpass filter-> Hilbert transform-> quad_demod-> high pass filter ->
clock_recovery_mm-> binary slicer.
We are using 16k and 18k frequencies and our sampling rate is 48k (well
enough according to Nyquist criteria).


How and what we figured out ?


Our system was decoding the data correctly till 54bps and fails below
54bps.For debugging the issue We sent the same sequence from our transmitter
and received
at our receiver end with both 100 bps and 50 bps.we checked the output of
each block in our flow graph, using scope sink in GRC.
We found no difference in the outputs of other blocks except the
clock_recovery_mm block.What we found was that 
for consecutive sequence (either 1 or 0) the block fails to estimate the
symbol correctly (snapshot are provided in the link below ).The boxed area
is where we think the problem exist. 
We checked the block output further for alternating sequence of 1 and 0 and
found that the block is estimating correctly.

http://sysnet.org.pk/w/Snapshots

we also found that for same sequence (either 1 or 0) the problem exists at
each datarate but less than 54bps it become weird.
The link below shows the output of clock_recovery_mm block at 100bps and
50bps for same sequence of bits.
The arguments of the blocks are set as
gr.clock_recovery_mm_ff((samples/symbol),0.000625,0.5,0.01,0.05)
**For 100 bps we are having samples/symbol= 480 and for 50 bps we are
keeping it 960.


Our Questions ?


Now since we are just changing the value of the "Omega"(samples/symbol)  in
clock_recovery_mm block for 100bps and 50bps.
So we want to know the following:
1) Is there a limit to maximum value omega? (due to which we are not getting
the right results at lower data rates)
2) Do we have to change some other parameter in the clock_recovery_mm to
rectify our problem?
3) Is it the limitation of clock_recovery_mm block? 
4) Or there is some other solution to the specified problem?



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Problem-faced-with-clock-recovery-mm-at-low-data-rates-tp42591.html
Sent from the GnuRadio mailing list archive at Nabble.com.