Re: [Discuss-gnuradio] gnuradio-3.3.0 Build Error On Fedora 14 (x86_64)
On Sat, Nov 13, 2010 at 11:33:05PM -0800, Arya Santini wrote: Hi List, I'm trying to build gnuradio-3.3.0 on Fedora 14 x86_64. I've installed all the prerequisites, and I run ./configure and it completes fine, reporting the modules going to be built. But when I run 'make', it runs for a while and then exits with the following error(s): This particular problem is fixed in the git master. Please use that until a new release is made. http://gnuradio.org/redmine/wiki/gnuradio/Download Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] file transmission with GRC question
On Sat, Nov 13, 2010 at 2:06 AM, Josh Blum j...@joshknows.com wrote I can run the programs (Rx first, then Tx) and I receive the file, but *slightly* smaller than the transmitted file. The file being transmitted is 2 MB of /dev/urandom and the received file is 8.192e3 bits smaller than the transmitted file. It may be not flushing to file. Try using a head block with the size param set to the expected file length and set the flow graph to run to completion. -Josh Any ideas as to where those bits went? Were they lost during synchronization? its also possible Hi Josh, Thanks for the tips; however, I suspect it has also something to do with how packet encoder/decoder works. I ran some tests using a simpler setup without USRP in the loop (.grc attached) file source - packet encoder - GMSK modulator - GMSK demodulator - packet decoder - file sink When using an input file with size that is an integer multiple of the Payload Length parameter of the packet encoder, the last packet will be missing, i.e. if payload length is 1000 bytes then the output file will be 1000 bytes smaller than the input file. Using vbindiff I could confirm that it is indeed the last packet that is missing. When using an input file with size that is not an integer multiple of the payload length of the packet encoder then both the last full packet and the reminder bytes will be missing in the output. When input file size = payload length (only one packet) the output file will be empty. I tried many different payload sizes, pad for USRP on/off, replaced gmsk with dbpsk, all gave same results. Adding a Head block did not make any difference either; however, making the Num Items smaller than the size of the input file resulted in an output file with NumItems-PayloadSize bytes so also in this case the last packet was missing. Maybe there is some end-of-stream signal that stops the flow graph before the last packet is decoded. I ran these tests using v3.3.1git-96-g1fa9a8ea Alex fcp.grc Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [USRP-users] Ettus Research Announcements -- Nov 2010
Sounds great. Will the USRP2-N210 be supported by UHD from start (software, firmware, bitstream) ? Should I anticipate any problems when using a combination of old and new USRP2s in a MIMO configuration ? BR/ Per On Thu, 2010-11-11 at 15:32 -0800, Matt Ettus wrote: === Ettus Research Announcements November 2010 1USRP Nominated for Technology of the Year! 2USRP N210 Product Announcement 3DBSRX2 Product Announcement 4RFX2200 Product Announcement 5Rackmount Product Announcement 6UHD Driver status 7New Simulink Drivers for the USRP2 8New Mailing List 9DBSRX and TVRX End of Life 10 SDR'10 Conference and GNU Radio Meeting === 1USRP Nominated for Technology of the Year! The USRP Family of Products has been nominated for the 2010 Technology of the Year award from the Wireless Innovation Forum. We are very honored to have the USRP family be nominated from among the many exciting products and technologies in the Software Radio field. Members of the Wireless Innovation Forum may cast their vote online for the winner here: http://groups.winnforum.org/p/su/rd/sid=56 Votes need to be in by 12 Pacific Time on Friday Nov 12th. === 2USRP N210 Product Announcement The USRP N210 software radio system builds on the success of the USRP2, offering higher performance and increased flexibility. The N210 offers the following improvements over the USRP2: - Xilinx Spartan 3A-DSP3400 FPGA - on-board TCXO frequency reference - Flash configuration memory. - An improved ADC (still 14 bits, 100 MS/s) The flash memory replaces the SD card used on the USRP2, and is reprogrammable over the network. The N210 is usable with our entire line of daughterboards. The USRP N210 introductory price is $1700, and orders placed now will ship in mid- to late- December. The USRP2 will continue to be available for those who cannot use the N210, but lead times may be longer. === 3DBSRX2 Product Announcement The DBSRX2 is now shipping. It has the same price ($150) and features as the original DBSRX, including an 800 MHz to 2.4 GHz frequency range, with the following improvements: - Better phase noise - No modifications necessary to use with the USRP2 The DBSRX2 works with all USRP motherboards, including USRP1, USRP2, and USRP N210. The DBSRX2 requires the use of the UHD drivers. Please see below for status of the original DBSRX. === 4RFX2200 Product Announcement The RFX2200 is now shipping. This transceiver covers 2.0 GHz to 2.45 GHz, has 50+ mW output power, and is otherwise similar to the other members of the RFX-series. It is full duplex capable, and is ideal for use in the satellite up and downlink bands. It costs $275 and works with all USRP systems. === 5Rackmount Product Announcement We are now selling a rack mount frame for the USRP2 and USRP N210 products. This frame allows 4 systems to be mounted in a standard 19 rack, occupying 3 Units of space. It costs $250. You can see a picture of it here: http://www.ettus.com/images/U2-Rackmount.JPG === 6UHD Driver status The UHD is now the preferred driver system for all USRP products. It supports all of our hardware, and works well with GNU Radio as well as other software packages. It is strongly recommended that users migrate their applications to the new system. More information about the UHD can be found here: http://www.ettus.com/uhd_docs/manual/html/ === 7New Simulink Drivers for the USRP2 The MathWorks latest version (release R2010b) of Communications Blockset™ for Simulink® now ships with receiver and transmitter interface blocks to the USRP2. These blocks allow engineers to speed development of communications systems in a design environment that streams real world signals to and from the USRP2 radio. More information can be found here: http://www.ettus.com/simulink === 8New Mailing List We have created a new mailing list for users of USRP hardware who use it with software other than GNU Radio. This is the preferred support forum for use of USRPs with Simulink, LabVIEW, or custom software. Subscription information and archives can be found here:
[Discuss-gnuradio] make check error for GNU Radio on Beagleboard
Hello, I am able to configure, make and make install GNUradio 3.2 on Beagleboard successfully. However, I met some error when running make check as follows: ..terminate called after throwing an instance of 'std::invalid_argument' what(): data length must be a multiple of vlen Aborted --- I noticed there is a similar error report on http://www.mail-archive.com/beagle-...@opensdr.com/msg00189.html, but no solution at that time. So is there any suggestion to solve it? Thanks a lot! Zhen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SD Cards
I have several SD cards to which I tried burning the FPGA and firmware images. When I try reusing the cards I have no success. How do I reset an SD card to its original state? Thanks, Al Vinegar___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] make check error for GNU Radio on Beagleboard
On 11/14/2010 07:36 AM, Zhen wrote: Hello, I am able to configure, make and make install GNUradio 3.2 on Beagleboard successfully. However, I met some error when running make check as follows: I don't know what fixes this, but the gnuradio next branch in git is building and passing make check fine. I'd also suggest getting something like an Overo Tide which has 512M of RAM. With this much RAM, you no longer need to tweek vm settings to do native builds. You could look at the revision history of the file being tested and see if there is a commit that looks like it might help. Philip ..terminate called after throwing an instance of 'std::invalid_argument' what(): data length must be a multiple of vlen Aborted --- I noticed there is a similar error report on http://www.mail-archive.com/beagle-...@opensdr.com/msg00189.html, but no solution at that time. So is there any suggestion to solve it? Thanks a lot! Zhen ___ 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] bandwidths 400Khz no longer work with USRP2
I did a git pull for both UHD GnuRadio yesterday. I'm on the next branch for gnuradio, and on master for UHD. Since doing a rebuild yesterday, bandwidths below 400KHz no longer work on the USRP2. I did a test with a dead-simple flowgraph: UHD single source--multi-const x 32767--FFT For bandwidths = 400KHz, the resulting FFT, with my existing RF front-end with 40dB gain feeding the BASIC_RX on my USRP2, the FFT looks just fine (showing a level around -40dB). But anything below 400KHz bandwidth (I tried various bandwidths between 200KHz and 400KHz), produces an FFT with nothing useful in it, and a level around -400dB. This used to work just fine below 400KHz. What happened? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: [USRP-users] Ettus Research Announcements -- Nov 2010
On 11/14/2010 07:24 AM, Per Zetterberg wrote: Sounds great. Will the USRP2-N210 be supported by UHD from start (software, firmware, bitstream) ? Yes, it works with UHD. The N210 will _ONLY_ be supported by UHD, not the old-style drivers. All of our new products going forward will be UHD-only. Should I anticipate any problems when using a combination of old and new USRP2s in a MIMO configuration ? The ADC in the USRP2 and the N210 is different, so it has a different pipeline delay. This means you would need to account for this effect in calibration. It is doable, but will be a little bit of work. Transmit should match very closely as the DAC has not changed. The vast majority of the logic in the FPGA is exactly the same between the two of them. My suggestion is to give preference to like pairs. For example, if you have 2 USRP2s and 2 N210s, it would be best to set them up as: System 1 -- USRP2 + USRP2 System 2 -- N210 + N210 rather than mixing them. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2-XCVR2450 receive problem
Hi, I met a problem for receiving signal by the USRP2-XCVR2450. Already installed GNU Radio 3.3.0 and The latest firmware and Raw Ethernet FPGA images have been written onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin. I used usrp2_fft.py and the centre freq is 2.421G (I typed my bluetooth keyboard quickly that would send many packets on frequence 2.421G). But the usrp2_fft.py script shown only noise, none of the useful signal could be received on my USRP2. Is there a USRP2-XCVR2450 receive problem while using the latest firmware and raw ethernet FPGA code? Thanks Lion ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2-XCVR2450 receive problem
For the gnuradio + usrp2 driver, there is a separate firmware image for WBX and XCVR2450. Which image did you use? http://code.ettus.com/redmine/ettus/projects/public/wiki/U2binaries#Firmware-Images -Josh On 11/14/2010 12:08 PM, XIAN PAN wrote: Hi, I met a problem for receiving signal by the USRP2-XCVR2450. Already installed GNU Radio 3.3.0 and The latest firmware and Raw Ethernet FPGA images have been written onto the SDRAM: u2_rev3-20100603.bin, u2_rev3-20100603.bin. I used usrp2_fft.py and the centre freq is 2.421G (I typed my bluetooth keyboard quickly that would send many packets on frequence 2.421G). But the usrp2_fft.py script shown only noise, none of the useful signal could be received on my USRP2. Is there a USRP2-XCVR2450 receive problem while using the latest firmware and raw ethernet FPGA code? Thanks Lion ___ 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] SD Cards
Same with me. Was was just able to modify the original card. Duplicating the card didn't work. I ripped it with dd and tried to copy the image to another sd card, but without success. A spare card in reserve would be really nice. BR Markus DL8RDS Am Sonntag, den 14.11.2010, 12:11 -0500 schrieb Allen Vinegar: I have several SD cards to which I tried burning the FPGA and firmware images. When I try reusing the cards I have no success. How do I reset an SD card to its original state? Thanks, Al Vinegar ___ 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] SD Cards
I continued hunting for an answer and found the following website. I downloaded their software and was able to reformat 3 SDs that I hadn't been able to reuse before. Now they work fine. Hope this is of some help to others. Al Vinegar This software formats all SD memory cards and SDHC memory cards using a formatting program that complies with official SD memory card requirements. ... www.sdcard.org - Original Message - From: Markus Heller M.A. (relix GmbH) hel...@relix.de To: Allen Vinegar tok...@myranch.com Cc: discuss-gnuradio@gnu.org Sent: Sunday, November 14, 2010 6:34 PM Subject: Re: [Discuss-gnuradio] SD Cards Same with me. Was was just able to modify the original card. Duplicating the card didn't work. I ripped it with dd and tried to copy the image to another sd card, but without success. A spare card in reserve would be really nice. BR Markus DL8RDS Am Sonntag, den 14.11.2010, 12:11 -0500 schrieb Allen Vinegar: I have several SD cards to which I tried burning the FPGA and firmware images. When I try reusing the cards I have no success. How do I reset an SD card to its original state? Thanks, Al Vinegar ___ 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] help on BBN 802.11b code
thanks~ Tom. It is solved. Best, Guanbo On Thu, Nov 11, 2010 at 9:36 PM, Tom Rondeau trondeau1...@gmail.com wrote: On Thu, Nov 11, 2010 at 9:59 PM, Guanbo Zheng gbzh...@gmail.com wrote: Hi I tried to install the BBN 802.11b trunk from CGRAN project website, and got some problems duing sudo make, as follows: --- bbn_tap.cc: In constructor ‘bbn_tap::bbn_tap(std::string, int)’: bbn_tap.cc:51: error: ‘memset’ was not declared in this scope bbn_tap.cc:53: error: ‘strncpy’ was not declared in this scope bbn_tap.cc: In member function ‘int bbn_tap::tap_write(std::string)’: bbn_tap.cc:137: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ bbn_tap.cc:153: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’ bbn_tap.cc:158: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result make[4]: *** [bbn_tap.lo] Error 1 The errors came from make. The configure of the code works fine. My system is: Ubuntu 9.04 + gnuradio 3.2.2 + USRP2 + XCVR2450. I did the installation before, was successfully on USRP2. Not sure what happened this time. :( Many thanks for any advice -- Regards, Guanbo Likely an updated version of GCC that's being more picky about include files. Try including string.h in the offending file and recompile. Tom -- Regards, Guanbo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] new modulation schemes do not work on my usrps while the old ones work
hi, I have the latest gnuradio installed on my Ubuntu 10.04 computers and two USRPs with RFX-2400 cards. I tested the benchmark_tx.py/benchmark_rx.py and benchmark_tx2.py/benchmark_rx2.py with dbpsk and dbpsk2 modulation schemes but only the old schemes work. 1. With old schemes both usrps transmit and receive when tested in both tx/rx modes. 2. With the new scheme one of the receive computer displays 'false ' for almost all the packets received. I didn't see any successfully received packets. 3. One of the USRPs in the receive mode doesn't even acknowledge a transmission and hence the benchmark_rx2.py script doesn't print any thing on stdout. What changes in parameters should I try in order for them to work? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] new modulation schemes do not work on my usrps while the old ones work
On 11/14/2010 08:38 PM, John Andrews wrote: hi, I have the latest gnuradio installed on my Ubuntu 10.04 computers and two USRPs with RFX-2400 cards. I tested the benchmark_tx.py/benchmark_rx.py http://benchmark_tx.py/benchmark_rx.py and benchmark_tx2.py/benchmark_rx2.py http://benchmark_tx2.py/benchmark_rx2.py with dbpsk and dbpsk2 modulation schemes but only the old schemes work. 1. With old schemes both usrps transmit and receive when tested in both tx/rx modes. 2. With the new scheme one of the receive computer displays 'false ' for almost all the packets received. I didn't see any successfully received packets. 3. One of the USRPs in the receive mode doesn't even acknowledge a transmission and hence the benchmark_rx2.py script doesn't print any thing on stdout. What changes in parameters should I try in order for them to work? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Some modulation schemes are more sensitive to frequency offsets than others. Try that. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Timer Event with GRC(Relationship among Sample Rate, Frequency, Decimation)
Hi I am using signal source and variable sink to generate a variable with name” carrier_frequency”. I am interested to transmit signal at 920 MHz 2 GHz. For that purpose, the signal source parameters are as follows: Sample Rate: 1000 Waveform: Triangle Frequency:1 Amplitude:2G The variable source parameters are: Variable : Carrier frequency Decimation: 125 What is the relation among Sample rate, Frequency and decimation? PLEASE GUIDE ME IN THIS REGARD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Timer Event with GRC(Relationship among Sample Rate, Frequency, Decimation)
sample_rate/decimation is the rate at which the variable sink block samples the incoming stream and updates the variable. -Josh On 11/14/2010 06:05 PM, hafiz zimran wrote: Hi I am using signal source and variable sink to generate a variable with name” carrier_frequency”. I am interested to transmit signal at 920 MHz 2 GHz. For that purpose, the signal source parameters are as follows: Sample Rate: 1000 Waveform: Triangle Frequency:1 Amplitude:2G The variable source parameters are: Variable : Carrier frequency Decimation: 125 What is the relation among Sample rate, Frequency and decimation? PLEASE GUIDE ME IN THIS REGARD ___ 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] USRP connection failure
Now I'm trying to test a very simple TX/RX examples I have a USRP1 and basic TX/RX board GNUradio flow graph is like a link here http://picasaweb.google.com/gee.songsong/Study#5539608314025540050 When I run it by pressing F6, it is terminated with an error message like below: Generating: /home/songsong/Desktop/top_block.py Executing: /home/songsong/Desktop/top_block.py usrp: failed to find usrp[0] Traceback (most recent call last): File /home/songsong/Desktop/top_block.py, line 84, in module tb = top_block() File /home/songsong/Desktop/top_block.py, line 34, in __init__ self.usrp_simple_sink_x_0 = grc_usrp.simple_sink_c(which=0, side=A) File /usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/simple_usrp.py, line 91, in __init__ self._make_usrp(which=which, nchan=1) File /usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/common.py, line 28, in _make_usrp def _make_usrp(self, *args, **kwargs): self._u = self._usrp_args[0](*args, **kwargs) File /usr/local/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 2475, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp Done I really really cannot find out what am I doing wrong :( ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 basic RX/TX frequency range
I am wondering that what frequency range does USRP1 basic RX/TX board support ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 basic RX/TX frequency range
On 11/14/2010 10:18 PM, Songsong Gee wrote: I am wondering that what frequency range does USRP1 basic RX/TX board support ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Up to about 32MHz in the first nyquist zone, and then aliases up to about 200MHz. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP connection failure
Did you setup the udev permissions on your system? -Josh On 11/14/2010 07:13 PM, Songsong Gee wrote: Now I'm trying to test a very simple TX/RX examples I have a USRP1 and basic TX/RX board GNUradio flow graph is like a link here http://picasaweb.google.com/gee.songsong/Study#5539608314025540050 When I run it by pressing F6, it is terminated with an error message like below: Generating: /home/songsong/Desktop/top_block.py Executing: /home/songsong/Desktop/top_block.py usrp: failed to find usrp[0] Traceback (most recent call last): File /home/songsong/Desktop/top_block.py, line 84, inmodule tb = top_block() File /home/songsong/Desktop/top_block.py, line 34, in __init__ self.usrp_simple_sink_x_0 = grc_usrp.simple_sink_c(which=0, side=A) File /usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/simple_usrp.py, line 91, in __init__ self._make_usrp(which=which, nchan=1) File /usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/common.py, line 28, in _make_usrp def _make_usrp(self, *args, **kwargs): self._u = self._usrp_args[0](*args, **kwargs) File /usr/local/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 2475, in sink_c return _usrp_swig.sink_c(*args, **kwargs) RuntimeError: can't open usrp Done I really really cannot find out what am I doing wrong :( ___ 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] USRP connection failure
I've tried USRP udev permission configuration, like below:
*# /usr/sbin/groupadd usrp
# /usr/sbin/usermod -a usrp [username]*
(in file, 10-usrp.rules)
# rule to grant read/write access on USRP to group named usrp.
# to use, install this file in /etc/udev/rules.d as 10-usrp.rules
*ACTION==add, BUS==usb, SYSFS{idVendor}==fffe,
SYSFS{idProduct}==0002, GROUP:=usrp, MODE:=0660
*
after rebooting a machine,
*ls -lR /dev/bus/usb*
/dev/bus/usb:
total 0
drwxr-xr-x 2 root root 80 2010-11-15 13:13 001
drwxr-xr-x 2 root root 80 2010-11-15 13:09 002
/dev/bus/usb/001:
total 0
crw-rw-r-- 1 root root 189, 0 2010-11-15 13:09 001
crw-rw 1 root usrp 189, 2 2010-11-15 13:13 003
/dev/bus/usb/002:
total 0
crw-rw-r-- 1 root root 189, 128 2010-11-15 13:09 001
crw-rw-r-- 1 root root 189, 129 2010-11-15 13:09 002
So, the connection before execution is fine.
However, everytime I run a flow graph, it immediately disconnects.
And through me an error
usrp: failed to find usrp[0]
Traceback (most recent call last):
File /home/songsong/Desktop/top_
block.py, line 84, inmodule
tb = top_block()
File /home/songsong/Desktop/top_block.py, line 34, in __init__
self.usrp_simple_sink_x_0 = grc_usrp.simple_sink_c(which=0, side=A)
File
/usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/simple_usrp.py,
line 91, in __init__
self._make_usrp(which=which, nchan=1)
File /usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/common.py,
line 28, in _make_usrp
def _make_usrp(self, *args, **kwargs): self._u =
self._usrp_args[0](*args, **kwargs)
File /usr/local/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py,
line 2475, in sink_c
return _usrp_swig.sink_c(*args, **kwargs)
RuntimeError: can't open usrp
2010/11/15 Josh Blum j...@joshknows.com
Did you setup the udev permissions on your system? -Josh
On 11/14/2010 07:13 PM, Songsong Gee wrote:
Now I'm trying to test a very simple TX/RX examples
I have a USRP1 and basic TX/RX board
GNUradio flow graph is like a link here
http://picasaweb.google.com/gee.songsong/Study#5539608314025540050
When I run it by pressing F6, it is terminated with an error message like
below:
Generating: /home/songsong/Desktop/top_block.py
Executing: /home/songsong/Desktop/top_block.py
usrp: failed to find usrp[0]
Traceback (most recent call last):
File /home/songsong/Desktop/top_block.py, line 84, inmodule
tb = top_block()
File /home/songsong/Desktop/top_block.py, line 34, in __init__
self.usrp_simple_sink_x_0 = grc_usrp.simple_sink_c(which=0, side=A)
File
/usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/simple_usrp.py,
line 91, in __init__
self._make_usrp(which=which, nchan=1)
File
/usr/local/lib/python2.6/dist-packages/grc_gnuradio/usrp/common.py,
line 28, in _make_usrp
def _make_usrp(self, *args, **kwargs): self._u =
self._usrp_args[0](*args, **kwargs)
File
/usr/local/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py,
line 2475, in sink_c
return _usrp_swig.sink_c(*args, **kwargs)
RuntimeError: can't open usrp
Done
I really really cannot find out what am I doing wrong :(
___
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
