Re: [Discuss-gnuradio] Questions about synchronization and modulation in benchmark
Check the source code of costas loop and Mueller Mueller clock recovery blocks. They have the link to the reference papers used for the implementation. Regarding your bpsk/dbpsk question. There is a differential encoder block in the transmit_path of this modulator. Remove this from the connect path and you will get bpsk. Thanks, Mir On Sun, Jan 31, 2010 at 2:54 AM, Timothy Lawrence Sitorus timothy.l.sito...@gmail.com wrote: Hi Adib Thanks for the reply. I check it in the net and download it. I don't know about costas loop and clock recovery in detail. may I know how they they estimate frequency offset, and recover it? as far as I know, they are using gr.quadrature_demod_cf(1) and subtract it using gr.single_pole_iif_filter_ff(alpha) for frequency offset?is it right? Tim On Sun, Jan 31, 2010 at 4:03 PM, adib_sairi adib_sa...@yahoo.com wrote: there is some work from Thomas Schmid which modulate and demodulate O-QPSK which mean for IEEE802.15.4 standard.. you can search and download the code online. good luck.. Adib Timothy Lawrence Sitorus wrote: HI all, Please anyone help me. Is there anyone succeeded to modulate qpsk, even frequency offset occurs? Best Regards, Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Questions-about-synchronization-and-modulation-in-benchmark-tp27371719p27390702.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RSSI Measurement--
hi friends, I need to measure the Received signal strength. I am using the programs in gnuradio/examples/python/digital/ folder. I am transmitting at one end using benchmark_tx.py and receiving at the other end with benchmark_rx.py. I need to calculate the bit error rate and plot it against Receiver SNR. If some one has done any work related to this, please share it here. Atleast I need to program that gives the RSSI value. Thanking you in advance, -- AMARNATH.A ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] issue 406
Back in August I found a small issue with the usrp_fft.py and usrp_oscope.py utlis always selecting subdevice(0,0). I created ticket 406 and attached my 2-line patch. http://gnuradio.org/redmine/issues/show/406 Since then nothing happened. Johnathan (or anyone else), can you please merge that? Thanks Dimitris Symeonidis If you think you're too small to make a difference, try sleeping with a mosquito! - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] docs/doxygen/other/omnithread.pdf broken
The pdf file docs/doxygen/other/omnithread.pdf is broken, while the html and postscript files both look fine. Tried with both evince and acroread. A simple ps2pdf from the postscript file produces a correct pdf Best regards Dimitris Symeonidis If you think you're too small to make a difference, try sleeping with a mosquito! - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Transceiver Residual Carrier Offset
I recently purchased two new USRP2 boards each with a XCVR2450 transceiver board. In testing the two boards, I began by conducting a simple tx/rx test in which both boards share a COMMON 10MHz reference clock, as opposed to two independent references. This test was conducted to determine if the measured channel would remain relatively unchanged (time invariant) in a static channel environemnt. A single 2MHz tone was used as my baseband test signal (no BPSK or QAM). In comparing the baseband tx signal to the baseband rx signal, I noticed that although both signals were 2MHz in frequency, they were out of phase as expected. However, the phase difference was not constant over time. Rather the phase difference was changing over time quite a bit. This occurrence may limit the MIMO capabilities of these boards since the residual carrier offsets must be corrected for individually for each transceiver. Take a 2x2 MIMO system fore example. Four different carrier offsets may need to be corrected rather than one as in the case of a fully coherent system. I'm curious as to whether other users have encountered similar problems with their systems as well, and if so, would be able to explain this occurrence. -- View this message in context: http://old.nabble.com/Transceiver-Residual-Carrier-Offset-tp27424897p27424897.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] running OFDM on USRP2
Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Mailing list subscription settings
I do need the list mail at my address to see the follow up on the query submitted. Turning off the list email was done in error. Pls enable the same . On Tue, Feb 2, 2010 at 2:32 PM, supp...@nabble.com wrote: Dear Nabble user: After your subscription request to Discuss-gnuradio@gnu.org has been accepted, please follow the link below to turn off list mail delivery to your email address: http://old.nabble.com/mailing_list/SubscribeDefaults.jtp?forum=1878k=bunzag5n Regards, supp...@nabble.com -- Thanks Regards, Anupama Purohit 972 697 8183 (M) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] running OFDM on USRP2
Hi Anupama Unfortunately, I can't offer a solution at this stage. However, I had similar error messages a few days ago. I thought perhaps these python scripts were to be used exclusively for the original USRPs, though I think in one or two posts I have seen, people mentioned successfully running them for USRP2s. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Anu000 Sent: Wednesday, 3 February 2010 8:04 AM To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] running OFDM on USRP2
Hi, The example provided with the gnuradio codebase requires small modifications in order to work with USRP2. You can try with the modifications I made: www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz In my case with XCVR2450 daughter boards running the following works fine: transmitter: benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 receiver: benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128 You can try with the transmitter only first and usrp2_fft.py on the other end, just to see if there's something getting transmitted and if it looks like OFDM. cheers, veljko 2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au: Hi Anupama Unfortunately, I can't offer a solution at this stage. However, I had similar error messages a few days ago. I thought perhaps these python scripts were to be used exclusively for the original USRPs, though I think in one or two posts I have seen, people mentioned successfully running them for USRP2s. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Anu000 Sent: Wednesday, 3 February 2010 8:04 AM To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] running OFDM on USRP2
Thanks Veljko Actually, the problems I had were not with the OFDM case, but just benchmark_tx.py and benchmark_rx.py. Are similar modifications necessary for those scripts? Ian. Hi, The example provided with the gnuradio codebase requires small modifications in order to work with USRP2. You can try with the modifications I made: www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz In my case with XCVR2450 daughter boards running the following works fine: transmitter: benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 receiver: benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128 You can try with the transmitter only first and usrp2_fft.py on the other end, just to see if there's something getting transmitted and if it looks like OFDM. cheers, veljko 2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au: Hi Anupama Unfortunately, I can't offer a solution at this stage. However, I had similar error messages a few days ago. I thought perhaps these python scripts were to be used exclusively for the original USRPs, though I think in one or two posts I have seen, people mentioned successfully running them for USRP2s. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Anu000 Sent: Wednesday, 3 February 2010 8:04 AM To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] running OFDM on USRP2
Hi, Thanks, we would try the below in our modifications . however is someone is aware if the below script works with Basic TX/Basic Rx Daughter Boards, that would be really helpful On Tue, Feb 2, 2010 at 5:05 PM, Ian Holland ian.holl...@rlmgroup.com.auwrote: Thanks Veljko Actually, the problems I had were not with the OFDM case, but just benchmark_tx.py and benchmark_rx.py. Are similar modifications necessary for those scripts? Ian. Hi, The example provided with the gnuradio codebase requires small modifications in order to work with USRP2. You can try with the modifications I made: www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz In my case with XCVR2450 daughter boards running the following works fine: transmitter: benchmark_ofdm_tx_new.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk --fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128 receiver: benchmark_ofdm_rx_new.py -e eth1 -f 2.45G -m bpsk --fft-length=512 --occupied-tones=80 -d 64 --rx-gain=30 --cp-length=128 You can try with the transmitter only first and usrp2_fft.py on the other end, just to see if there's something getting transmitted and if it looks like OFDM. cheers, veljko 2010/2/2 Ian Holland ian.holl...@rlmgroup.com.au: Hi Anupama Unfortunately, I can't offer a solution at this stage. However, I had similar error messages a few days ago. I thought perhaps these python scripts were to be used exclusively for the original USRPs, though I think in one or two posts I have seen, people mentioned successfully running them for USRP2s. Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.hollanddiscuss-gnuradio-bounces%2Bian.holland =rlmgroup.com...@gnu.org] On Behalf Of Anu000 Sent: Wednesday, 3 February 2010 8:04 AM To: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] running OFDM on USRP2 Hi, We did try the below command on two USRP2s coneected via a SMA Cable (Tx-Rx) with freq = 25M however it returned the following error on both sides At Rx side it shows like the below - [r...@gnuradio1 ofdm]# ./benchmark_ofdm_rx.py -f 25M -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_rx.py, line 210, in module main() File ./benchmark_ofdm_rx.py, line 199, in main tb = my_top_block(rx_callback, options) File ./benchmark_ofdm_rx.py, line 51, in __init__ self._setup_usrp_source() File ./benchmark_ofdm_rx.py, line 70, in _setup_usrp_source fusb_nblocks=self._fusb_nblocks) File /usr/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py, line 1699, in source_c return _usrp_swig.source_c(*args, **kwargs) RuntimeError: can't open usrp At Tx side - r...@gnu2 ofdm]# ./benchmark_ofdm_tx.py -f 25M -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 usrp: failed to find usrp[0] Traceback (most recent call last): File ./benchmark_ofdm_tx.py, line 217, in module main() File ./benchmark_ofdm_tx.py, line 190, in main tb = my_top_block(options) File ./benchmark_ofdm_tx.py, line 51, in __init__ self._setup_usrp_sink() File ./benchmark_ofdm_tx.py, line 66, in _setup_usrp_sink fusb_nblocks=self._fusb_nblocks) File /usr/local/lib/python2.5/site-packages/gnuradio/usrp/usrp_swig.py, line 2415, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp May we request somebody to support us at the earliest to resolve the above issue with either software or hardware . Thanks again, Anupama bin zan wrote: Hello, I was trying to run following OFDM command on USRP2, however, I got a bunch of Stime out at the receiver side. ./benchmark_ofdm_tx.py -f 2.4G -i 512 --fft-length=64 --occupied-tones=32 --cp-length=4 ./benchmark_ofdm_rx.py -f 2.4G -d 256 --fft-length=64 --occupied-tones=32 --cp-length=4 I wonder if there is any one successfully running OFDM on USRP2, what are the command parameters you are using and if there is any modification in the code, can you let me know. Thanks, Bin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/running-OFDM-on-USRP2-tp27342376p27427749.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi, The problem I guess is with the SD cards only. Even I was facing the same problem. But today I tried with an old SD card and it worked. I am not able to catch hold of a card reader and the one in my laptop is not working. manav On Tue, Feb 2, 2010 at 5:14 PM, Ian Holland ian.holl...@rlmgroup.com.auwrote: Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/%0Alib/ db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Manav I tried both of my daughterboards with the same SD card in the USRP2, so perhaps we were actually facing different problems, or at least I am facing an additional problem with one of my cards. Your problem may be resolved once you try Josh's earlier suggestion of reflashing the latest FPGA and firmware images, but of course you will need an SD card reader to do this. You should be able to find them at any electronics/photography/home entertainment store, and they are quite cheap. Ian. From: Manav Seth [mailto:smartyma...@gmail.com] Sent: Wednesday, 3 February 2010 10:54 AM To: Ian Holland Cc: j...@ettus.com; discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2 Hi, The problem I guess is with the SD cards only. Even I was facing the same problem. But today I tried with an old SD card and it worked. I am not able to catch hold of a card reader and the one in my laptop is not working. manav On Tue, Feb 2, 2010 at 5:14 PM, Ian Holland ian.holl...@rlmgroup.com.au wrote: Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/ http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ %0Alib/ db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult);
Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Ya, what I mean is that for you too the problem may be the SD card only. Actually we had got around 20 USRP's/daughterboards from Ettus and none of them were working with the SD cards they supplied with them (20 in all). When I tried with an older SD card, it worked. On Tue, Feb 2, 2010 at 5:43 PM, Ian Holland ian.holl...@rlmgroup.com.auwrote: Hi Manav I tried both of my daughterboards with the same SD card in the USRP2, so perhaps we were actually facing different problems, or at least I am facing an additional problem with one of my cards. Your problem may be resolved once you try Josh’s earlier suggestion of reflashing the latest FPGA and firmware images, but of course you will need an SD card reader to do this. You should be able to find them at any electronics/photography/home entertainment store, and they are quite cheap. Ian. -- *From:* Manav Seth [mailto:smartyma...@gmail.com] *Sent:* Wednesday, 3 February 2010 10:54 AM *To:* Ian Holland *Cc:* j...@ettus.com; discuss-gnuradio@gnu.org *Subject:* Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2 Hi, The problem I guess is with the SD cards only. Even I was facing the same problem. But today I tried with an old SD card and it worked. I am not able to catch hold of a card reader and the one in my laptop is not working. manav On Tue, Feb 2, 2010 at 5:14 PM, Ian Holland ian.holl...@rlmgroup.com.au wrote: Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/%0Alib/ db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Perhaps? We only have two USRP2s and 2 XCVR2450s. However, if it was the SD card, I would think both XCVR2450s should have the problem. Actually, even the better of the two occasionally fails, so I can't be sure. Ya, what I mean is that for you too the problem may be the SD card only. Actually we had got around 20 USRP's/daughterboards from Ettus and none of them were working with the SD cards they supplied with them (20 in all). When I tried with an older SD card, it worked. On Tue, Feb 2, 2010 at 5:43 PM, Ian Holland ian.holl...@rlmgroup.com.au wrote: ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] about FM radio question
Hi: Can I use the FM frequence to transmission file/data to receive side? If can, how can I do? Or which files I can modify and reach I want. Mei-Wen Li (Emily) National Cheng-Kung University Dept. of Computer Science and Information Engineering emily7...@hotmail.com _ Hotmail 是功能強大又值得信賴的免費信箱 https://signup.live.com/signup.aspx?id=60969___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi again Josh Since my below post this morning, the 2nd XCVR2450 card that had repeatedly failed this morning, is now working with the other USRP2, though still unable to tune reliably near band edges. I will probably try swapping the XCVR2450/USRP2 combination and see whether somehow one XCVR2450 has an affinity for one particular USRP2, and won't work on the other, but I can't really understand why that should be the case. Can you think of what might cause such a behaviour? For now, I was just glad that I could successfully transmit a 5 GHz signal from one USRP2's antenna and display the correct spectrum on the receiving USRP2. Best Regards Ian. Hi Josh Thanks for the advice. I tried the full range of low and high band frequencies, in increments of 10 MHz with 2 different XCVR2450 boards. This was done at least 4 times after power cycling for each card. I noticed the following: - For one of the XCVR cards, it repeatedly failed for all frequencies. - For the other card, it intermittently failed for frequencies at the lower and upper end of the low band, and at the higher end of the high band. I tried several values of N_DIV_MIN_Q16, and expect with a really large value (131 22), which seemed to fail for almost all frequencies, and also seemed to cause the USRP2 to freeze up a few times, I noticed negligible difference in the behaviour of this daughtercard. - For both XCVR2450s I noticed that sometimes after power cycling the USRP2 either froze when I tried to run my test, or it was unable to be found by my host PC in some cases. - I tried (131 16) (i.e. original) value for N_DIV_MIN_Q16 and also (131 19) on the card that failed for all frequencies, and that made no difference. I am not hugely concerned about the band-edge instability for the working card (although of course it would be nice to get to the bottom of that issue), but do you have any idea what could be wrong with the 2nd card, that fails for all frequencies? Best Regards Ian. Is it failing to lock at all different frequencies? and in the high band and low band ranges? Do you have more than one XCVR board with this problem? It could be possible that for this board, and the frequencies you have chosen, the N divider value teeters on the border or locking/not locking. You may want to modify the usrp2 firmware code and build custom image. The file to modify is http://gnuradio.org/redmine/repositories/entry/gnuradio/usrp2/firmware/ lib/db_xcvr2450.c Add some printfs to the xcvr2450_set_freq function and try to raise the value of N_DIV_MIN_Q16 and see if you can get it to lock. I hope that helps, -Josh On 02/01/2010 06:08 PM, Ian Holland wrote: Thanks Josh I can now confirm that it is definitely failing to lock. I have noticed on some rare occasions that it actually does lock. However, as soon as the USRP2 is power-cycled it goes back to the default behaviour of being unable to lock. What can be done to make sure that it will lock? Is this likely to be a hardware issue specific to our daughtercards, or is there something else we can do in software to get around it? Thanks Ian. It could be failing to lock. You may want to watch the debug port on the usrp2. If the lock detect is failing, it will print out on the serial console. attach a 3.3v level serial port On 01/28/2010 10:09 PM, Ian Holland wrote: Hi Josh The xcvr has a high band and a low band, which means there is a gap in the tunable frequency range for the xcvr. Therefore, the auto-calculated mid-point frequency is an invalid frequency for the xcvr. Pick a frequency in the high band or low band range: #define LB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(2.3e9) #define LB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(2.6e9) #define HB_FREQ_MIN U2_DOUBLE_TO_FXPT_FREQ(4.8e9) #define HB_FREQ_MAX U2_DOUBLE_TO_FXPT_FREQ(6.1e9) Thanks - I will keep that in mind when using usrp_siggen.py in future. However, I have tried 2.4G with the source code from my original post (relevant code snippet for Tx tuning just below this paragraph, for which successTx is 0 and all frequency properties in TxTuneResult are 0), and also with usrp2_fft.py -f 2.4G, after burning the latest images. I still face the same problem that neither the Tx nor the Rx will tune. /* try tuning Tx to a test frequency */ double Fc = 24.0; usrp2::tune_result TxTuneResult; bool successTx = device-set_tx_center_freq(Fc,TxTuneResult); ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
