[Discuss-gnuradio] Broken WBX?
Hi Guys, I have recently received a WBX and am struggling to get it to work. Please see the following screenshots: http://www.flickr.com/photos/47218...@n06/sets/72157623341034652 shows a very strong GSM base station at 940.2MHz. As you can see, the DBSRX works perfectly but the WBX (using the same antenna) receives nothing. http://www.flickr.com/photos/47218...@n06/sets/72157623341037644 shows my WBX receiving nothing over 930-960Mhz using the same antenna as the DBSRX. The spikes seen on the WBX are drifting signals which don't go away. The 88-108MHz FM broadcast band cannot be received by the WBX either, although my TVRX receives it fine. Changing the gain, frequency and antenna port doesn't do anything apart from alter background RF levels. I have compiled from the latest trunk using the git repository, running ubuntu 9.04 32 bit. Here are the commands I have been using: DBSRX: ./usrp_fft.py -R B -f 940.2M -d 64 -g 35 WBX (TX/RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A TX/RX WBX (RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A RX Have I received a broken WBX or am I missing something obvious? Thanks, Mike M0MIK ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Viewing timestamps using USRP2
I am trying to use wireshark to extract the timestamp from the received ethernet packets to test my sync_every_pps() function is working. I have located the word I need to extract from the received data but how can I automatically extract this and display it as an integer in the display window in wireshark? Alternatively, is there a better way to view the timestamp information to check for a reset? -- View this message in context: http://old.nabble.com/Viewing-timestamps-using-USRP2-tp27435137p27435137.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] Viewing timestamps using USRP2
MarcW wrote: I am trying to use wireshark to extract the timestamp from the received ethernet packets to test my sync_every_pps() function is working. I have located the word I need to extract from the received data but how can I automatically extract this and display it as an integer in the display window in wireshark? Alternatively, is there a better way to view the timestamp information to check for a reset? You can either write a custom wireshark plugin to parse the packets (in which case you'll want to consult with a better source of information on wireshark - perhaps their mailing list), simply monitor the word yourself, or you could write a c++ application that talks to libusrp2 directly and prints out the timestamp. I did at one point modify the rx_streaming_samples application that is packaged with gnuradio to do just that. But I've also used wireshark and simply watched for the reset manually. Doug -- Douglas Geiger Code 5545 U.S. Naval Research Laboratory Washington, DC 20375 (202) 767-9048 douglas.gei...@nrl.navy.mil ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Viewing timestamps using USRP2
Thanks for your help Doug. I thought I knew which bits to monitor which contained the timestamp but now im not sure! The packets received seem very large. I have included a screenprint of one below. Please could you tell me which bits are the timestamp in this packet? The data appears to start from line 0020 but every other 32 bits are either ff or 00. Do we add the sync_every_pps() to txrc.c immediately before the while loop? 00 15 17 d2 56 23 00 50 c2 85 33 f7 be ef 00 00 V#.P ..3. 0010 00 00 6c 00 00 00 00 00 cd a6 fe 10 00 06 00 0c ..l. 0020 ff f0 ff f2 ff f1 00 33 00 36 00 13 00 20 00 31 ...3 .6... .1 0030 00 15 00 17 00 00 ff ff 00 11 ff f1 00 12 00 0f 0040 00 09 00 03 ff fa ff e7 00 00 ff fb ff f9 00 09 0050 ff e7 00 04 ff df ff e9 ff df 00 23 00 0d 00 09 ...# 0060 ff e7 ff c5 ff e2 00 2f 00 09 00 29 ff ec ff e1 .../ ...) 0070 ff da ff ff ff fc 00 05 00 09 ff e3 ff e0 ff e3 0080 ff e4 ff ed ff ec ff fe ff fe ff cc ff ee ff da 0090 ff bc ff d1 ff db ff ee ff ec ff fb ff f5 ff e7 00a0 00 0b 00 0f ff e5 00 00 ff f9 00 15 ff fb 00 09 00b0 00 13 00 0c 00 10 00 3f 00 11 00 32 00 0b ff f6 ...? ...2 00c0 ff f6 00 03 00 37 00 14 00 3f ff e8 ff f8 ff fb .7.. .?.. 00d0 00 0a ff e5 00 03 ff e9 00 07 ff e9 ff f5 00 08 00e0 00 27 00 00 00 0c ff f0 ff ef 00 1f 00 13 ff ee .'.. 00f0 ff eb ff f0 ff f3 00 04 00 11 ff de ff e6 00 05 0100 ff e6 ff ef 00 0c 00 0c ff e2 00 02 ff e2 00 19 0110 ff f5 00 37 ff fe 00 21 00 17 ff f7 00 18 00 09 ...7...! 0120 00 03 ff e5 ff e4 ff fb 00 1e ff f7 00 04 ff de 0130 ff db 00 00 ff f8 ff db ff ca ff bd ff f0 ff bb 0140 ff fc ff e5 ff fd ff fe ff f7 ff e3 ff da ff ef 0150 00 18 00 11 00 25 ff ff 00 2b ff ee ff fc 00 23 .%.. .+.# 0160 ff ef 00 08 ff dc ff bf 00 0d 00 00 00 17 00 20 ... 0170 ff f1 00 09 00 06 ff fb 00 07 00 0e 00 09 ff fe 0180 00 21 00 1a ff fa 00 39 ff e2 00 0a 00 31 ff f4 .!.9 .1.. 0190 00 19 00 1c 00 06 00 0a ff bd ff b6 00 09 00 0b 01a0 00 18 00 05 ff cc 00 13 ff fd ff dc ff f6 ff ed 01b0 00 18 00 23 00 00 ff ea ff fe 00 0c 00 0d ff e7 ...# 01c0 00 27 ff de 00 0c 00 03 00 17 00 2f 00 1b 00 31 .'.. .../...1 01d0 00 27 00 1e ff e5 00 26 ff d1 ff ee 00 02 00 01 .'. 01e0 ff ee ff f7 ff e7 ff d3 ff c4 ff ce ff ef ff d3 01f0 ff f5 ff e5 ff bc ff d4 ff ec ff cf ff d6 00 28 ...( 0200 ff f9 00 12 ff fd 00 03 ff db 00 14 ff f2 ff d5 0210 ff cf ff bf ff da ff d4 ff e3 00 1a ff e1 00 0d 0220 00 10 00 00 00 0e 00 10 ff f7 00 11 00 08 00 31 ...1 0230 ff fe 00 08 00 06 ff ed ff ff ff d7 ff f3 ff fc 0240 ff d2 00 0e ff d7 ff fe 00 0f 00 1c 00 30 00 26 .0. 0250 ff fe 00 1b 00 1e 00 14 00 01 00 0d 00 03 00 29 ...) 0260 00 0b ff f5 00 07 ff f4 00 0a ff ed 00 00 00 0a 0270 00 16 00 2e ff eb ff f0 00 03 00 12 00 23 ff ff .#.. 0280 00 16 00 14 00 05 00 06 ff f6 ff eb ff f2 ff c8 0290 00 10 00 00 00 19 ff f0 00 2a 00 18 ff e0 ff ff .*.. 02a0 ff f8 ff d6 ff f8 ff ef ff e2 00 0e 00 10 00 0c 02b0 00 34 00 27 00 28 00 25 ff f4 ff f0 00 05 ff df .4.'.(.% 02c0 00 18 ff ed ff ef 00 19 00 0d ff e2 00 1c 00 00 02d0 00 00 ff f9 00 17 ff f4 00 10 00 11 00 0a 00 3d ...= 02e0 00 2e 00 13 00 1b 00 0e 00 20 00 03 ff d8 ff db . .. 02f0 ff f8 ff d5 ff c1 ff e8 ff dd ff e5 ff eb 00 2a ...* 0300 ff c4 ff d7 00 0a ff d9 ff fd 00 0c ff f2 00 05 0310 ff dc ff ee 00 00 00 1f 00 1b 00 25 ff fe ff f2 ...% 0320 00 03 ff e2 00 0b 00 27 00 1a 00 0c ff fa ff f7 ...' 0330 ff fb 00 13 00 1e 00 0d ff e1 00 00 00 0c ff f5 0340 00 53 00 18 00 3b ff c2 ff f9 ff de 00 0a 00 29 .S...;.. ...) 0350 00 03 00 0c 00 09 00 23 ff e8 00 21 00 04 00 18 ...# ...! 0360 ff fc ff ed ff f0 ff bf ff dd ff ef ff fc ff b4 0370 ff f3 ff bc ff c9 ff f7 ff c8 ff ea ff fc ff ef 0380 00 2d 00 28 ff fa 00 2d 00 09 00 00 ff f5 00 04 .-.(...- 0390 ff ec 00 02 00 05 ff f3 ff fa ff fb ff d6 ff d9 03a0 00 18 00 1d 00 18 00 3d 00 00 00 22 ff fd 00 0e ...= ... 03b0 ff ff ff f9 00 23 00 20 ff f6 ff f5 ff f6 ff f9 .#. 03c0 ff fd ff e5 ff f5 ff e4 00 07 ff dd ff fc 00 0f
Re: [Discuss-gnuradio] Viewing timestamps using USRP2
MarcW wrote: Thanks for your help Doug. I thought I knew which bits to monitor which contained the timestamp but now im not sure! The packets received seem very large. I have included a screenprint of one below. Please could you tell me which bits are the timestamp in this packet? The data appears to start from line 0020 but every other 32 bits are either ff or 00. Do we add the sync_every_pps() to txrc.c immediately before the while loop? Which version of gnuradio are you running? If you're using the usrp2-vrt git branch, the frame format has changed dramatically. If you're using the released code (or the master branch from git) the frame structure is (IIRC) defined in usrp2/firmware/include/usrp2_eth_packet.h. There's the standard ethernet header (dst, src, ethertype), a short 'transport' header (some flags, sequence number, etc.), and the 'fixed' header which has some more flags, and the 32-bit timestamp. The VRT format has a much longer header, and includes a seconds count and a fractional seconds count. You don't need to call sync_every_pps() in the firmware (do you really want to reset the clock every PPS?). The host can send the command to sync_*_pps() when setting up the connection to the USRP2. For example, in rx_streaming_samples, call u2-sync_to_pps() (or sync_every_pps() if you really want that) before calling u2-start_rx_streaming. Then you can have the copy handler print out the timestamp from each frame received by the USRP2. In the VRT branch I believe there is already an example application that prints out the timestamp from received frames. Doug -- Douglas Geiger Code 5545 U.S. Naval Research Laboratory Washington, DC 20375 (202) 767-9048 douglas.gei...@nrl.navy.mil ___ 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
Ian- 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. If you rule out the SD card, then is there a way you and Manav can compare PCB revisions for USRP2 and XCVR2450 -- and USRP2 logic revision -- and make sure your systems are absolutely identical? Even a small rework or logic change might make a difference... -Jeff 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
Re: [Discuss-gnuradio] running OFDM on USRP2
On Tue, Feb 2, 2010 at 4:34 PM, Anu000 anupama.puro...@gmail.com wrote: 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 This is because you do not have the right permissions set to talk to the USRP2 as a non-root user. See the USRP2 FAQs on the GNU Radio web page for how to fix this. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] running OFDM on USRP2
On Wed, Jan 27, 2010 at 11:21 AM, bin zan zanbin2...@gmail.com 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 The 'S' appear because you're missing packets. Using the interpolation and decimation rates you specified shouldn't be taxi/ng your CPU, which is a common cause of these problems. Are you running the USRP2 through a switch or is it directly connected? The time out occurs when the receiver sees the preamble symbol of the OFDM stream but nothing else. So what is probably happening is that you get some of the symbols through, including the preamble symbol, but you're dropping other packets (causing the Ses), which will trigger the time out message. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] running OFDM on USRP2
Hi Tom , Thanks , we did try the updated script from Veljko . It works though we have missing packets after a while ( as suggested in the forum we would play with the interpolation and decimation ) though the 2 USRP2s are directly connected . We are still probing into the permissions issue as indicated though we ran with root permissions ( may be not in totality) , would keep posted on the later if we find something on the same Thanks again , /Regards On Wed, Feb 3, 2010 at 8:17 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Tue, Feb 2, 2010 at 4:34 PM, Anu000 anupama.puro...@gmail.com wrote: 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 This is because you do not have the right permissions set to talk to the USRP2 as a non-root user. See the USRP2 FAQs on the GNU Radio web page for how to fix this. Tom -- Thanks Regards, Anupama Purohit 972 697 8183 (M) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building GNU Radio on the Beagle board
From time to time people ask about building GNU Radio for the Beagleboard. In an attempt to make it easier for more people to work on this, I posted some notes at: http://www.opensdr.com/node/17 describing how to build GNU Radio on the Beagleboard (obviously building it cross is much faster, but you need to be aware of some tricky bits). I know this is all a bit vague, but hopefully someone finds it useful :) If you have Beagle specific questions, please ask those on the appropriate list/irc channel. I'll be glad to respond to GNU Radio specific issues here. Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BER test in FH system
I need to do a ber test and my current system is based on frequence hopping. I think I should send a random 01 bit sequence at the transmiter side and then,obsever the received bit sequence. In next step,when campare the two sequence in order, how decided the order?or how to do the Sync in two radio?especially in a Fh system. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BER plots for various modulation schemes
Same question. How build a scenario to measure a ber vs. snr with two radio? 2010/1/6 amarnath alapati amarnath.alap...@gmail.com hello everybody, I wanted to test the USRP performance for various modulation schemes by varying the power level of transmitted signal and plotting the BER. Can i use one of the existing gnuradio-examples/python/ programs to do this? How to check the power level of the transmitted signal? Cheers, AMARNATH.A. ___ 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 Tom, In our case, even with script from Veljko, the OFDM receiver doesn't show any thing. And we always see usrp2: failed to enable realtime scheduling. Do you think that will cause problem? Thanks, Bin On Wed, Feb 3, 2010 at 12:57 PM, Anupama Purohit anupama.puro...@gmail.comwrote: Hi Tom , Thanks , we did try the updated script from Veljko . It works though we have missing packets after a while ( as suggested in the forum we would play with the interpolation and decimation ) though the 2 USRP2s are directly connected . We are still probing into the permissions issue as indicated though we ran with root permissions ( may be not in totality) , would keep posted on the later if we find something on the same Thanks again , /Regards On Wed, Feb 3, 2010 at 8:17 AM, Tom Rondeau trondeau1...@gmail.comwrote: On Tue, Feb 2, 2010 at 4:34 PM, Anu000 anupama.puro...@gmail.com wrote: 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 This is because you do not have the right permissions set to talk to the USRP2 as a non-root user. See the USRP2 FAQs on the GNU Radio web page for how to fix this. Tom -- Thanks Regards, Anupama Purohit 972 697 8183 (M) ___ 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] PLL loop bandwidth
Hi All, But I guess only Matt can answer this :-) What is the bandwidth of the PLL loop of the RFX1800 and the XCVR2450 ? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Broken WBX?
Mike, Doe your USRP have a serial number below 500? I know you've been a longtime user, so yours may be that old. If so, the WBX won't work for you since USRPs under #500 do not send a clock to the daughterboard, and the WBX needs one. Also, note that in the following command: WBX (RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A RX it should read -A RX2 on the end. Matt On 02/03/2010 01:45 AM, mike wrote: Hi Guys, I have recently received a WBX and am struggling to get it to work. Please see the following screenshots: http://www.flickr.com/photos/47218...@n06/sets/72157623341034652 shows a very strong GSM base station at 940.2MHz. As you can see, the DBSRX works perfectly but the WBX (using the same antenna) receives nothing. http://www.flickr.com/photos/47218...@n06/sets/72157623341037644 shows my WBX receiving nothing over 930-960Mhz using the same antenna as the DBSRX. The spikes seen on the WBX are drifting signals which don't go away. The 88-108MHz FM broadcast band cannot be received by the WBX either, although my TVRX receives it fine. Changing the gain, frequency and antenna port doesn't do anything apart from alter background RF levels. I have compiled from the latest trunk using the git repository, running ubuntu 9.04 32 bit. Here are the commands I have been using: DBSRX: ./usrp_fft.py -R B -f 940.2M -d 64 -g 35 WBX (TX/RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A TX/RX WBX (RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A RX Have I received a broken WBX or am I missing something obvious? Thanks, Mike M0MIK ___ 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] Straight from USRP to Wave File
Hello, I wish to have a USRP source receiving at 54.1Mhz sent straight to a stereo wave file sink with no demodulation or any other manipulation. Side A of the USRP would record to the left channel and side B to right. I'd like to record at 192khz 24bit if possible (and no this isn't for a listening application that would just be silly). Let's just say I'm not a crack programmer and the documentation for this things are scattered in the wind across the internet. This is probably one of the simplest programs you can write for gnuradio but I need some help. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Broken WBX?
Hi Matt, Thanks for your reply. My USRP1 serial number is 134 :( -A RX2 was used, I clearly can't copy and paste correctly! Is there a clock you could recommend that will fit inside the USRP1 enclosure to fix this issue? Fingers crossed! Cheers, Mike M0MIK On 3 February 2010 22:23, Matt Ettus m...@ettus.com wrote: Mike, Doe your USRP have a serial number below 500? I know you've been a longtime user, so yours may be that old. If so, the WBX won't work for you since USRPs under #500 do not send a clock to the daughterboard, and the WBX needs one. Also, note that in the following command: WBX (RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A RX it should read -A RX2 on the end. Matt On 02/03/2010 01:45 AM, mike wrote: Hi Guys, I have recently received a WBX and am struggling to get it to work. Please see the following screenshots: http://www.flickr.com/photos/47218...@n06/sets/72157623341034652 shows a very strong GSM base station at 940.2MHz. As you can see, the DBSRX works perfectly but the WBX (using the same antenna) receives nothing. http://www.flickr.com/photos/47218...@n06/sets/72157623341037644 shows my WBX receiving nothing over 930-960Mhz using the same antenna as the DBSRX. The spikes seen on the WBX are drifting signals which don't go away. The 88-108MHz FM broadcast band cannot be received by the WBX either, although my TVRX receives it fine. Changing the gain, frequency and antenna port doesn't do anything apart from alter background RF levels. I have compiled from the latest trunk using the git repository, running ubuntu 9.04 32 bit. Here are the commands I have been using: DBSRX: ./usrp_fft.py -R B -f 940.2M -d 64 -g 35 WBX (TX/RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A TX/RX WBX (RX antenna): ./usrp_fft.py -R A -f 940.2M -d 64 -g 35 -A RX Have I received a broken WBX or am I missing something obvious? Thanks, Mike M0MIK ___ 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] How to implement 64QAM?
Thanks Isaac for your kindly suggestion. I think i have to dive into python now... idg101 wrote: Hi, I haven't looked at any of the QAM-related code in the GNU Radio baseline, but it should be possible to design a generic MQAM demodulator. In fact, you should be able to build a generic MQAM demodulator for a given constellation set. This, I've done before in Matlab. You start with an AGC, feed through an equalizer which is optimized for minimizing the phase error between recovered and truth symbols. Another way to look at it that for each symbol, find the symbol that matches closest to the constellation vector (thats your decode symbol) and then feed the error into the equalizer. I believe there is a way to form a generic carrier recovery and symbol recovery loops that can deal with generic MPSK style constellation of which MQAM is a part of. In fact, you could write a routine that can do anything from BPSK to 64QAM. my 2 cents, Isaac -- View this message in context: http://old.nabble.com/How-to-implement-64QAM--tp27396489p27446003.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] Unable to tune Tx or Rx with XCVR2450 on USRP2
Hi Josh I am now in a position to summarise what I have observed. - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Do you have any idea what might be wrong? Has such behaviour ever been previously observed? Also, can you please comment as to whether it is likely that the other XCVR2450 will keep working with at least one USRP2? Cheers Ian. 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. 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
[Discuss-gnuradio] About Basic TX amplifer question
Hi: Have anyone use BasicTX and TVRX, did you used amplifer? What's amplifer or antenna amplifer do you use, can you tell me, that let me reference, thanks. Best Regards. 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] Straight from USRP to Wave File
On Wed, Feb 03, 2010 at 03:39:34PM -0700, Jon Paul Lundquist wrote: Hello, I wish to have a USRP source receiving at 54.1Mhz sent straight to a stereo wave file sink with no demodulation or any other manipulation. Side A of the USRP would record to the left channel and side B to right. I'd like to record at 192khz 24bit if possible (and no this isn't for a listening application that would just be silly). Let's just say I'm not a crack programmer and the documentation for this things are scattered in the wind across the internet. This is probably one of the simplest programs you can write for gnuradio but I need some help. Thanks! To get that signal in, it will need to be downconverted in the FPGA. Is your input a quadrature signal (i.e., two inputs: I Q), or is it two (unrelated) real signals? Which daughterboard are you planning on using? Take a look at usrp_rx_cfile.py for the basic framework for a single channel (or quadrature signal). If the two inputs are independent, gnuradio-examples/python/multi-antenna/multi_file.py may provide a better starting point. You'll want to use a gr.wavefile_sink to write the wavefile. http://gnuradio.org/doc/doxygen/classgr__wavfile__sink.html Eric ___ 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
Manav, Sorry for not being active in this thread. Things have been very busy here. In any case, it sounds like you are seeing something very different from Ian. You are having one of 2 problems -- - You received bad SD cards. If you power up your USRP2 with the SD card in it, and you don't see 2 LEDs light up on the front panel, then this is what you are seeing, and it has nothing to do with the XCVR2450. Go to this page and follow the directions there: http://www.ettus.com/flash - If the card is not bad, then you have a flash version which does not match your GNU Radio install. Newer flash cards come with new versions of the firmware and FPGA, but these will only work with updated GNU Radio code. If this is the case, you either need to update GNU Radio, or put an old version of the FPGA and firmware on your card. I recommend the first option. Matt On 02/02/2010 05:08 PM, Manav Seth wrote: 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 mailto:ian.holl...@rlmgroup.com.au wrote: 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 mailto:smartyma...@gmail.com] *Sent:* Wednesday, 3 February 2010 10:54 AM *To:* Ian Holland *Cc:* j...@ettus.com mailto:j...@ettus.com; discuss-gnuradio@gnu.org mailto: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 mailto: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
Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Ian, When you said it fails to lock over the full high band and low band do you mean it locks nowhere, or do you mean that it locks on some frequencies, but not everywhere? If the latter, can you be more specific about where it locks and where it doesn't? Also, what are the serial numbers of your USRP2s and your XCVRs? Which are the working combos and which combos fail? Thanks, Matt On 02/03/2010 04:56 PM, Ian Holland wrote: Hi Josh I am now in a position to summarise what I have observed. - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Do you have any idea what might be wrong? Has such behaviour ever been previously observed? Also, can you please comment as to whether it is likely that the other XCVR2450 will keep working with at least one USRP2? Cheers Ian. Hi again Josh Since my below post this morning, the 2nd XCVR2450 card that had repeatedlyfailed this morning, is now working with the other USRP2, though stillunable to tune reliably near band edges. I will probably try swapping the XCVR2450/USRP2 combination and see whethersomehow one XCVR2450 has an affinity for one particular USRP2, and won'twork on the other, but I can't really understand why that should be thecase. Can you think of what might cause such a behaviour? For now, I was just glad that I could successfully transmit a 5 GHz signalfrom one USRP2's antenna and display the correct spectrum on the receivingUSRP2. 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 ___ 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 Matt Are you able to also comment on the problem that I am having? (Summary below): - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Thanks Ian. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Recall: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
Ian Holland would like to recall the message, [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2. ___ 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 Matt Sorry I wasn't completely clear in my previous post below. Specific details are as follows: When I say it fails to lock over the full high band and low band, what I mean is as follows. I ran a test program to step through the frequencies 2.3 GHz to 2.6 GHz, and 4.8 to 6.1 GHz in 10 MHz increments, and for every single one of those frequencies, it failed to tune the Rx frequency and it also failed to tune the Tx frequency. This was, based on earlier debugging, shown to be due to it not locking (i.e. Lock detect bit was not set). Serial number combinations are as follows. Please note that by Working, I mean not all frequencies fail to tune. However, some frequencies near the edges of the lower band, and the upper edge of the higher band, intermittently fail to tune even for combinations of cards I refer to in the table as Working. Combination ID | USRP2 Serial | XCVR2450 Serial | Working A | 933 | 990 | YES B | 933 | 988 | NO C | 1159 | 990 | YES D | 1159 | 988 | YES In my testing today, an additional problem was also noticed, as below. Whilst using the internal clocks, a test was run to compare sampling rates using combination A as Rx and combination D as Tx. As would be expected without locked clocks, the sampling rates at Tx and Rx differed. Then, another test was performed using the same external 10 MHz reference to both Tx and Rx USRP2s. As soon as the external reference signal was fed into the reference clock input of combination D (Tx), the transmitted signal level was observed to drop into the noise floor, hence, I was unable to reliably detect the transmitted signal with locked clocks. (I had previously run the same test with the BasicTx and BasicRx daughterboards, connected by and SMA-SMA cable, and this effect had not occurred with the BasicTx/BasicRx. Instead, the sampling rates at Tx and Rx were identical, and I was able to successfully demodulate a file transmitted using BPSK). Best Regards Ian. -Original Message- From: Matt Ettus [mailto:m...@ettus.com] Sent: Thursday, 4 February 2010 4:24 PM 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 Ian, When you said it fails to lock over the full high band and low band do you mean it locks nowhere, or do you mean that it locks on some frequencies, but not everywhere? If the latter, can you be more specific about where it locks and where it doesn't? Also, what are the serial numbers of your USRP2s and your XCVRs? Which are the working combos and which combos fail? Thanks, Matt On 02/03/2010 04:56 PM, Ian Holland wrote: Hi Josh I am now in a position to summarise what I have observed. - 1 of our 2 XCVR2450s works with both of our USRP2s. - The other XCVR2450 works with only one of our USRP2s (i.e., it fails to lock over the full high band and low band on the second USRP2). Do you have any idea what might be wrong? Has such behaviour ever been previously observed? Also, can you please comment as to whether it is likely that the other XCVR2450 will keep working with at least one USRP2? Cheers Ian. Hi again Josh Since my below post this morning, the 2nd XCVR2450 card that had repeatedlyfailed this morning, is now working with the other USRP2, though stillunable to tune reliably near band edges. I will probably try swapping the XCVR2450/USRP2 combination and see whethersomehow one XCVR2450 has an affinity for one particular USRP2, and won'twork on the other, but I can't really understand why that should be thecase. Can you think of what might cause such a behaviour? For now, I was just glad that I could successfully transmit a 5 GHz signalfrom one USRP2's antenna and display the correct spectrum on the receivingUSRP2. 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
Re: [Discuss-gnuradio] Unable to tune Tx or Rx with XCVR2450 on USRP2
On 02/03/2010 10:19 PM, Ian Holland wrote: Hi Matt Sorry I wasn't completely clear in my previous post below. Specific details are as follows: When I say it fails to lock over the full high band and low band, what I mean is as follows. I ran a test program to step through the frequencies 2.3 GHz to 2.6 GHz, and 4.8 to 6.1 GHz in 10 MHz increments, and for every single one of those frequencies, it failed to tune the Rx frequency and it also failed to tune the Tx frequency. This was, based on earlier debugging, shown to be due to it not locking (i.e. Lock detect bit was not set). Clearly locking nowhere is a problem. Serial number combinations are as follows. Please note that by Working, I mean not all frequencies fail to tune. However, some frequencies near the edges of the lower band, and the upper edge of the higher band, intermittently fail to tune even for combinations of cards I refer to in the table as Working. You should know that we only spec the boards from 2.4 to 2.5 GHz and 4.9 to 5.9 GHz. When we test XCVRs before shipping, we make sure that they will lock from 2.35 to 2.55 and 4.85 to 5.95 so that there is 50 MHz of margin in case of variation due to temperature or other factors. But there is no reason to think that they would lock all the way to the edges of the ranges you list since those are well outside of what we (and the chip manufacturer) specify. Combination ID | USRP2 Serial | XCVR2450 Serial | Working A | 933 | 990 | YES B | 933 | 988 | NO C | 1159 | 990 | YES D | 1159 | 988 | YES In my testing today, an additional problem was also noticed, as below. To simplify testing, you only need to run either RX or TX since they both share the same synthesizer on the XCVR2450. Normally I would tell you to send the parts back for me to check them, but since you are in AU, it would be expensive and take a long time. Instead, we may be able to debug this if you have an oscilloscope. If so, can you look at the signal on R45 and R56 on the XCVR? Note the frequency, and high and low voltages for each of the 4 combinations you mention above. They should look like a square wave in all cases. Whilst using the internal clocks, a test was run to compare sampling rates using combination A as Rx and combination D as Tx. As would be expected without locked clocks, the sampling rates at Tx and Rx differed. Then, another test was performed using the same external 10 MHz reference to both Tx and Rx USRP2s. As soon as the external reference signal was fed into the reference clock input of combination D (Tx), the transmitted signal level was observed to drop into the noise floor, hence, I was unable to reliably detect the transmitted signal with locked clocks. (I had previously run the same test with the BasicTx and BasicRx daughterboards, connected by and SMA-SMA cable, and this effect had not occurred with the BasicTx/BasicRx. Instead, the sampling rates at Tx and Rx were identical, and I was able to successfully demodulate a file transmitted using BPSK). Assuming the signal you were transmitting was a sine wave with a baseband frequency of 0, then what you are seeing here is completely expected and normal. When the clocks are not locked to the same reference, there is some frequency error, and the signal received is at some frequency other than exactly on the LO of the receiver, and it will get through just fine. However, when the 2 clocks are locked to the same reference, the transmitted tone will be received exactly on the LO frequency of the receiver. When this is downconverted to baseband, it will appear at DC, and it will be nulled out by the DC offset correction, which occurs in both the analog and digital domains. You can turn off the digital one, but not the analog one on the XCVR. To demonstrate this, you can run the following commands: - To show a good tone being received: usrp_siggen.py -f 5.65G -A 0.1 -x 100k --sine usrp2_fft.py -f 5.65G - To show the tone being nulled out: usrp_siggen.py -f 5.65G -A 0.1 -x 0 --sine usrp2_fft.py -f 5.65G Matt ___ 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 Matt, Ya, I am having the second problem. But, I have the gnuradio 3.2.2 code base only. Will try to checkout again from the git repository and build. Anyways, I did have a working card. So if this does not work, I will try to copy this card to all the other cards. Can you please guide me how to copy a SD hard having a working image to another using a card reader. Today I tried doing this but the card was not being recognised. Thanks, Manav On Wed, Feb 3, 2010 at 10:26 PM, Matt Ettus m...@ettus.com wrote: Manav, Sorry for not being active in this thread. Things have been very busy here. In any case, it sounds like you are seeing something very different from Ian. You are having one of 2 problems -- - You received bad SD cards. If you power up your USRP2 with the SD card in it, and you don't see 2 LEDs light up on the front panel, then this is what you are seeing, and it has nothing to do with the XCVR2450. Go to this page and follow the directions there: http://www.ettus.com/flash - If the card is not bad, then you have a flash version which does not match your GNU Radio install. Newer flash cards come with new versions of the firmware and FPGA, but these will only work with updated GNU Radio code. If this is the case, you either need to update GNU Radio, or put an old version of the FPGA and firmware on your card. I recommend the first option. Matt On 02/02/2010 05:08 PM, Manav Seth wrote: 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 mailto:ian.holl...@rlmgroup.com.au wrote: 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 mailto:smartyma...@gmail.com] *Sent:* Wednesday, 3 February 2010 10:54 AM *To:* Ian Holland *Cc:* j...@ettus.com mailto:j...@ettus.com; discuss-gnuradio@gnu.org mailto: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 mailto: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
