[Discuss-gnuradio] Standalone USRP1 Operation
Hi, Has anyone tried to run USRP1 without PC? I have an application where a friend supported me with a standalone USRP FPGA image. I used the PC only to load this image to the USRP using gnuradio blocks/tools. After that I can plug-off (disconnect) the USB cable from the PC and USRP continue to operate standalone. My question is, has anyone tried to load USRP FPGA image without a PC? For example using a micro-controller (Like Microchip PIC 18F4550 which has USB 2.0 port) with SD memory holding the image? What it takes/need to do so? Best Regards, Firas -- View this message in context: http://www.nabble.com/Standalone-USRP1-Operation-tp23210804p23210804.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] Definition of USB Interfaces is different in Windows
Yes, I am sure. Because I am running USRP on Ubuntu with GNU Radio on the same computer and usb port and it is running absolutely fine. I read another thread on a forum, which gives same interfaces and endpoint numbers on Windows: http://www.nabble.com/usrp-and-u...@-fedora-9-td22833152.html I get the exact information on Windows as he gets them on Fedora 9. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Fwd: [Discuss-gnuradio] USRP2 eth_buffer
On Thu, Apr 23, 2009 at 01:15:56PM +0300, Juha Vierinen wrote: > I have attached a patch to allow users to define the ethernet packet > ring size. I remove the SLAB_SIZE restriction. I think gnuradio needs > a fairly new >2.6.5 kernel anyway. > > Why is this needed? I challenge anyone to sample at 25 MHz > continuously for two hours without overruns or missing packets to a > five disk raid array (be it ext2 or anything else) with the default 25 > MB buffer. > > Still, the patch maintains the original 25e6 buffer size. A value of > 250e6 to 500e6 allows fairly reliable sampling to disk at 25 MHz, so I > recommend increasing the default buffer size to something higher than > 25 MB. Otherwise new users will have problems with overruns. Even > Firefox consumes hundreds of megabytes. > > juha Juha, thanks for the patch! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Single-tone test using USRP2 with RFX2400 and XCVR2450
Hi, all. I did single-tone test using USRP2 with RFX2400 and XCVR2450. There are some undesired signals in the results. My single-tone test is as follows: - Wired connection between USRP2 and Spectrum analyzer - Single-tone is transmitted from USRP2 using the following commands ./usrp2_siggen.py -f ./usrp2_siggen.py -f -w - For daughter board, RFX2400, XCVR2450 and Basic TX are tested - Newest GNU radio and firmware - PC specification (I'm pretty sure that the spec is good enough to transmit single-tone stably) -- CPU: Intel core2quad processor Q9550 -- Ethernet card: Intel 82567LM Gigabit LAN (PCI express slot) -- Memory: 4GB DDR2 800 MHz SDRAM memory Except the case of Basic TX, there are some undesired signals in the results. So, I guess the undesired signals are generated by RFX2400 and XCVR2450, not by mother board. I'm afraid that the undesired signals cause some kind of distortion of desired signal. (In fact, when I transmit OFDM signal using XCVR2450, I fail to demodulate the received OFDM signal) The resulting spectrum figures are shown in the following link and I marked the undesired signals in the figures. http://141.223.23.5/Spectrum.zip Short descriptions for each figures are as follows: 1. File name: RFX2400_2p375GHz_01 Used daughter board: RFX2400 GNU radio command: ./usrp2_siggen.py -f 2.375e9 2. File name: RFX2400_2p375GHz_02 Used daughter board: RFX2400 GNU radio command: ./usrp2_siggen.py -f 2.375e9 -w 2M 3. File name: XCVR2450_2p52GHz_01 Used daughter board: XCVR2450 GNU radio command: ./usrp2_siggen.py -f 2.52e9 4. File name: XCVR2450_2p52GHz_02 Used daughter board: XCVR2450 GNU radio command: ./usrp2_siggen.py -f 2.52e9 -w 2M 5. File name: BasicTX_30MHz_01 Used daughter board: Basic TX GNU radio command: ./usrp2_siggen.py -f 30e6 6. File name: BasicTX_30MHz_02 Used daughter board: Basic TX GNU radio command: ./usrp2_siggen.py -f 30e6 -w 2M I would appreciate that if somebody let me know what is problem of my daughter boards or my test. Thanks. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is it possible to buy a RFX900 without the filter?
what capacitor does rfx1800 use in C204? On Thu, Apr 23, 2009 at 7:10 PM, Martin DvH wrote: > Hi Jhon, > > On Wed, 2009-04-22 at 22:03 -0700, Jhon Lee wrote: > > > > I read the discuss-gnuradio list and know that I need to bypass the > > filter with a capacitor and cut away the filter. I would like to know > > if it is possible to get a RFX900 which has removed the filter when I > > order it. > > You could always buy an RFX1800 and reprogram it as a RFX900. > to turn your RFX1800 into a RFX900, you can run the command: > >./burn-db-eeprom -A --force -t rfx900_mimo_b > > This way you don't have to solder anything. > > Also see the WIKI: What is involved in changing an RFX900 to an RFX1800? > on: > http://gnuradio.org/trac/wiki/UsrpFAQ/DBoards > > Greetings, > Martin > > > Thank you, > > Jhon > > ___ > > 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] Definition of USB Interfaces is different in Windows
On Fri, Apr 24, 2009 at 01:01:39AM +0600, Ujala Qasim wrote: > Hi, > I am writing a Windows interface for USRP using libusb-win32. However, I am > facing a problem. When I run the testlibusb wizard (a utility tool for > displaying information about USB devices) in Windows, it tells me that the > USRP has only one interface: Interface 0. This interface has three > alternative settings. Each having 6 endpoints. These interfaces are > different than those defined in usrp_interfaces.h. Please let me know which > interface should I be using as the RX and TX interface in Windows? > > Thanks. Are you sure you're plugged into a USB 2.0 port? The USRP requires USB 2.0. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is it possible to buy a RFX900 without the filter?
Hi Jhon, On Wed, 2009-04-22 at 22:03 -0700, Jhon Lee wrote: > > I read the discuss-gnuradio list and know that I need to bypass the > filter with a capacitor and cut away the filter. I would like to know > if it is possible to get a RFX900 which has removed the filter when I > order it. You could always buy an RFX1800 and reprogram it as a RFX900. to turn your RFX1800 into a RFX900, you can run the command: ./burn-db-eeprom -A --force -t rfx900_mimo_b This way you don't have to solder anything. Also see the WIKI: What is involved in changing an RFX900 to an RFX1800? on: http://gnuradio.org/trac/wiki/UsrpFAQ/DBoards Greetings, Martin > Thank you, > Jhon > ___ > 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] length of the signal in USRP_FFT display
I believe that what you want to do is the same as what I was trying to achieve with the scope graphical sink, although I was using GRC as my front end. Josh Blum replied to my post on April 20th. The subject title of the original post was "GRC graphical sink buffer size - how to increase?". I believe the same advice may apply to your situation. Use version 3.2rc2 of GNU Radio and activate the open GL mode for the graphicals sinks. See http://gnuradio.org/trac/wiki/CompGrWxgui#GLSinks for more detail. I followed that advice and it has worked for me. Now, if only the buffer size for the graphical sinks could be made more dynamic, i.e selected automatically based on the timescale selected for the particular scope, or on a flow graph by flow graph basis. Cheers Richard 2009/4/23 Bruhtesfa Ebrahim > Hi all, > > > I am trying to modify usrp_fft.py(oscilloscope mode) to display a longer > duration of decimated data in real time. I think in the default > oscilloscope 5msec of data is displayed(whatever the decimation rate and > time/div is) and these length of data is updated in real time. > > What I want is to decrease the decimation rate to 1KS/sec(64MS/sec > decimated by 128 in FPGA and then by 500 using decimating lowpass > filter) and display 5sec of data and to update this 5sec of data slowly > in real time. > > How can I modify the 5msec default length to 5sec? > > > Bruhtesfa > -- > Posted via http://www.ruby-forum.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] Definition of USB Interfaces is different in Windows
Ujala Qasim wrote: Hi, I am writing a Windows interface for USRP using libusb-win32. However, I am facing a problem. When I run the testlibusb wizard (a utility tool for displaying information about USB devices) in Windows, it tells me that the USRP has only one interface: Interface 0. This interface has three alternative settings. Each having 6 endpoints. These interfaces are different than those defined in usrp_interfaces.h. Please let me know which interface should I be using as the RX and TX interface in Windows? Is this before you download the data files to the USRP? If so, I think the additional endpoints are configured after you load the firmware into the FPGA. Philip smime.p7s Description: S/MIME Cryptographic Signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Definition of USB Interfaces is different in Windows
Hi, I am writing a Windows interface for USRP using libusb-win32. However, I am facing a problem. When I run the testlibusb wizard (a utility tool for displaying information about USB devices) in Windows, it tells me that the USRP has only one interface: Interface 0. This interface has three alternative settings. Each having 6 endpoints. These interfaces are different than those defined in usrp_interfaces.h. Please let me know which interface should I be using as the RX and TX interface in Windows? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] half duplex operation
Hi everyone, I am pretty new to gnu so kindly help me with my silly problems. I am trying to implement a transmitter receiver handshake in which the transmitter first sends a 'Ready to send' and the receiver upon receiving it sends a 'Clear to send' back. After this the TX is supposed to send data and RX is supposed to receive it which they are not being able to do. I have tried using a single antenna with auto tr mode enabled. I have also tried to use two separate antennas at different frequencies however none of these work. I would appreciate it if someone could guide me regarding this. Thanks a lot everyone. Regards Neha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about FSK
Are there any examples about FSK transmitter and receivers? -- View this message in context: http://www.nabble.com/Question-about-FSK-tp23197377p23197377.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] Symbol rates. USRP2 vs USRP1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colby Boyer wrote: > To confirm, you were able to receive 802.11b using the USRP2? > Yes, only at 1 and 2Mbps (DSSS w/Barker Code) rates. Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ8HgugfOzzR5bXIgRAjDZAJ4+VwTHn00cgcVvprerq2hjUVm1dgCfWL+b 7UCtnKv189WcVW9kelHN4hQ= =NSwp -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] length of the signal in USRP_FFT display
Hi all, I am trying to modify usrp_fft.py(oscilloscope mode) to display a longer duration of decimated data in real time. I think in the default oscilloscope 5msec of data is displayed(whatever the decimation rate and time/div is) and these length of data is updated in real time. What I want is to decrease the decimation rate to 1KS/sec(64MS/sec decimated by 128 in FPGA and then by 500 using decimating lowpass filter) and display 5sec of data and to update this 5sec of data slowly in real time. How can I modify the 5msec default length to 5sec? Bruhtesfa -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] KD7LMO Killed while bicycling
> "KD7LMO Killed while bicycling > We have received word that Michael Gray, KD7LMO, was killed Sunday, > April 12, while bicycling to visit his parents. This occurred about > 3:30 P.M. on Maricopa Road near the Maricopa Fire Department. Initial > information was that he was bicyling with two friends, when he was > struck from behind by a drunk driver ." This is a pitty. I started working with gnuradio with the help of his example code and capture files. My condolences to his family and friends, Juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Fwd: [Discuss-gnuradio] USRP2 eth_buffer
I have attached a patch to allow users to define the ethernet packet ring size. I remove the SLAB_SIZE restriction. I think gnuradio needs a fairly new >2.6.5 kernel anyway. Why is this needed? I challenge anyone to sample at 25 MHz continuously for two hours without overruns or missing packets to a five disk raid array (be it ext2 or anything else) with the default 25 MB buffer. Still, the patch maintains the original 25e6 buffer size. A value of 250e6 to 500e6 allows fairly reliable sampling to disk at 25 MHz, so I recommend increasing the default buffer size to something higher than 25 MB. Otherwise new users will have problems with overruns. Even Firefox consumes hundreds of megabytes. juha -- Forwarded message -- From: Juha Vierinen Date: Thu, Apr 23, 2009 at 11:00 Subject: Re: [Discuss-gnuradio] USRP2 eth_buffer To: Bruce Stansby Cc: Eric Blossom , Johnathan Corgan , "discuss-gnuradio@gnu.org" > ext file system is the go, with my high speed digitizer I stream 250 > MB/s (thats bytes) to a six disk raid (0) array. The raid zero is the go > if you can afford to loose data in the unlikely event of a disk failure. I'd guess that your high-speed digitizer has a buffer that is larger than 25 MB too. Do you know what the buffer size is for your sampler? I did a simple benchmark of filesystem bandwidth with xfs and ext2. xfs: j...@liang:/data0$ sudo time dd if=/dev/zero of=tmp.bin bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes (10 GB) copied, 68.1847 s, 154 MB/s ext2: j...@liang:/data0$ sudo time dd if=/dev/zero of=tmp.bin bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes (10 GB) copied, 68.1712 s, 154 MB/s Both give approximately the same bandwidth. I totally agree that ext2 might have less variability in i/o bandwidth, but at the same time, I don't really think there is that large difference between any decent modern filesystem in terms of long time average bandwidth of writing large files to disk. Large distributed filesystems are a different issue, and I'd guess that XFS and IBM's GPFS are good for those uses. I now took the time to reformat the disk to ext2 and tried to write 25 MHz to disk with the vanilla eth_buffer. It also gave an underrun after a few seconds. This might be because I am chopping the data into 100 MB files, but this is a necessity. I cannot have 24 hours of 25 MHz data in one large file. I have suggested a modification to the usrp2 API that would allow increasing the packet_ring buffer, why is that not a good idea? Isn't it a good idea to add a feature that allows people to reliably sample and store to disk at high bandwidth, even with more jittery filesystems? I think nobody is using a pre 2.6.5 kernel, so this there shouldn't really be any reason to restrict the size to the number of pointers that fit into a kernel slab size. I'll write a patch anyway and send it to the list. BR, juha Index: usrp2/host/include/usrp2/usrp2.h === --- usrp2/host/include/usrp2/usrp2.h (revision 10899) +++ usrp2/host/include/usrp2/usrp2.h (working copy) @@ -86,7 +86,7 @@ * If \p addr is HH:HH, it's treated as if it were 00:50:c2:85:HH:HH * "" will autoselect a USRP2 if there is only a single one on the local ethernet. */ -static sptr make(const std::string &ifc, const std::string &addr=""); +static sptr make(const std::string &ifc, const std::string &addr="", size_t rx_bufsize=0); /*! * Class destructor @@ -578,10 +578,10 @@ private: // Static function to retrieve or create usrp2 instance -static sptr find_existing_or_make_new(const std::string &ifc, props *p); +static sptr find_existing_or_make_new(const std::string &ifc, props *p, size_t rx_bufsize); // Only class members can instantiate this class -usrp2(const std::string &ifc, props *p); +usrp2(const std::string &ifc, props *p, size_t rx_bufsize); // All private state is held in opaque pointer std::auto_ptr d_impl; Index: usrp2/host/lib/usrp2_impl.cc === --- usrp2/host/lib/usrp2_impl.cc (revision 10899) +++ usrp2/host/lib/usrp2_impl.cc (working copy) @@ -128,8 +128,8 @@ } - usrp2::impl::impl(const std::string &ifc, props *p) -: d_eth_buf(new eth_buffer()), d_interface_name(ifc), d_pf(0), d_bg_thread(0), + usrp2::impl::impl(const std::string &ifc, props *p, size_t rx_bufsize) +: d_eth_buf(new eth_buffer(rx_bufsize)), d_interface_name(ifc), d_pf(0), d_bg_thread(0), d_bg_running(false), d_rx_seqno(-1), d_tx_seqno(0), d_next_rid(0), d_num_rx_frames(0), d_num_rx_missing(0), d_num_rx_overruns(0), d_num_rx_bytes(0), d_num_enqueued(0), d_enqueued_mutex(), d_bg_pending_cond(&d_enqueued_mutex), Index: usrp2/host/lib/usrp2_impl.h === ---
Re: [Discuss-gnuradio] Symbol rates. USRP2 vs USRP1
Hi Colby! In the RX path the difference in the adc rate should be compensated by the fact that you multiplied the decim by a factor of 1.5. [In your bbn_80211b_rx.py (line 98)] In the TX path Andrea figured out that: Rate = 2 * [FPGA_processing_rate / (spb*interp_rate)] The BBN guys suggested to use spb=4 and interp_rate=32 for communicating with a wifichipset. In fact, with USRP1: 2 * [64 MS/s / (4 S/bit * 32)] = 1 Mbps On the contrary, in USRP2 the FPGA_processing_rate is 100 MS/s. Therefore, in order to transmit at 1 Mbps, we need to set the (spb*interp_rate) accordingly: e.g. 2 * [100 MS/s / (4 S/bit * 48)] = 1Mbps. We were wondering how it is possible that spb=4 can represent a barker sequence. We have tried some different combinations of spb and interp_rate (e.g. spb=8 and interp=24), so that the result is always 1 Mbps. But we still have no success. By "no success", I mean that the wifi chipset monitoring the air receives frames that seem to be randomly generated. Any suggestions? Anyway, thanks for uploading your branch. ;-) Danilo On Wednesday 22 April 2009 22:24:19 Colby Boyer wrote: > Hi all, > > As some of you know, I am working on porting the BBN 802.11b code to the > USRP2. I understand that the ADC/DAC rates are higher than the USRP1. What > are the effects, if any, on the rate at which symbol are sent through the > air? I am suspect that this could be the reason I cannot decode sent > packets. > > Colby > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 eth_buffer
> ext file system is the go, with my high speed digitizer I stream 250 > MB/s (thats bytes) to a six disk raid (0) array. The raid zero is the go > if you can afford to loose data in the unlikely event of a disk failure. I'd guess that your high-speed digitizer has a buffer that is larger than 25 MB too. Do you know what the buffer size is for your sampler? I did a simple benchmark of filesystem bandwidth with xfs and ext2. xfs: j...@liang:/data0$ sudo time dd if=/dev/zero of=tmp.bin bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes (10 GB) copied, 68.1847 s, 154 MB/s ext2: j...@liang:/data0$ sudo time dd if=/dev/zero of=tmp.bin bs=1M count=1 1+0 records in 1+0 records out 1048576 bytes (10 GB) copied, 68.1712 s, 154 MB/s Both give approximately the same bandwidth. I totally agree that ext2 might have less variability in i/o bandwidth, but at the same time, I don't really think there is that large difference between any decent modern filesystem in terms of long time average bandwidth of writing large files to disk. Large distributed filesystems are a different issue, and I'd guess that XFS and IBM's GPFS are good for those uses. I now took the time to reformat the disk to ext2 and tried to write 25 MHz to disk with the vanilla eth_buffer. It also gave an underrun after a few seconds. This might be because I am chopping the data into 100 MB files, but this is a necessity. I cannot have 24 hours of 25 MHz data in one large file. I have suggested a modification to the usrp2 API that would allow increasing the packet_ring buffer, why is that not a good idea? Isn't it a good idea to add a feature that allows people to reliably sample and store to disk at high bandwidth, even with more jittery filesystems? I think nobody is using a pre 2.6.5 kernel, so this there shouldn't really be any reason to restrict the size to the number of pointers that fit into a kernel slab size. I'll write a patch anyway and send it to the list. BR, juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
