Waqas, U can use PFB_clock_sync instead of M&M. PFB_clock_sync implements the maximum likelihood estimation algorithms, so using this block increasing sps should not produce incorrect results.
http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1pfb__clock__sync__ccf.html -Adeel On Sat, Jul 20, 2013 at 6:44 PM, Waqas Bin Abbas <waqas.abb...@nu.edu.pk>wrote: > 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. > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
