Re: [Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates
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 mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates
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 rates (As the frequency of the received symbols decreases with the decrease in the data rate). So now we have replaced the high pass filter with a simple subtractor to eliminate dc-shift. For synchronization we using same clock_recovery_mm and its working fine for large samples per symbols (we have tried till 9600 samples/symbol). Regards, Waqas -- View this message in context: http://gnuradio.4.n7.nabble.com/Problem-faced-with-clock-recovery-mm-at-low-data-rates-tp42591p42860.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
Re: [Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates
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 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 rates (As the frequency of the received symbols decreases with the decrease in the data rate). So now we have replaced the high pass filter with a simple subtractor to eliminate dc-shift. For synchronization we using same clock_recovery_mm and its working fine for large samples per symbols (we have tried till 9600 samples/symbol). Regards, Waqas -- View this message in context: http://gnuradio.4.n7.nabble.com/Problem-faced-with-clock-recovery-mm-at-low-data-rates-tp42591p42860.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 -- Nemanja Savić ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates
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
Re: [Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates
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 data correctly, however at higher data rates data is decoded fine. The MM block is known not to work well with a very large number of samples per symbol. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem faced with clock_recovery_mm at low data rates
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 20, 2013 at 6:44 PM, Waqas Bin Abbas waqas.abb...@nu.edu.pkwrote: 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
