We did not try clock_recovery_mm for that much low samples per symbols.
Minimum samples per symbols that we used was 24.
Waqas
--
View this message in context:
http://gnuradio.4.n7.nabble.com/Problem-faced-with-clock-recovery-mm-at-low-data-rates-tp42591p42985.html
Sent from the GnuRadio
Thanks Tom and Adeel for the suggestion.
We have sorted out the problem and now our system is working at low data
rates.
The real problem was with our *high pass filter* block. We are using it to
eliminate the DC-shift present at the output of quad_demod block. But its
not working at low data
I am also interested in this topic, since I was unable to configure MM
bloxk once. In fact it was working for 26 samples per symbol but for 5 not.
Could you provide some more information?
On Thu, Aug 1, 2013 at 9:11 AM, Waqas Bin Abbas waqas.abb...@nu.edu.pkwrote:
Thanks Tom and Adeel for the
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
On Sat, Jul 20, 2013 at 9:44 AM, 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
Waqas,
U can use PFB_clock_sync instead of MM. 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
