Re: [Discuss-gnuradio] what is the minimal transmission time for gnuradio
On Wed, Jun 03, 2009 at 06:01:25PM -0400, ywan...@vt.edu wrote: I am doing some experiment using benchmark_tx. The purpose is to let the gnuradio to send small packages lasting for about 0.1 ms every 0.1 second. However, even the payload is set to be , the burst time is still around 0.2 ms. Is there any method will allow to control or detect the transmission time accurately? And is that possible to reduce this the minimal burst time? benchmark_tx uses the GNU Radio framing/packaging module which does all kinds of stuff. I recommend setting up your own flow graph if you want precise control over the transmission time. 0.1 ms should not be a problem. However, if you're sending an n second burst every n seconds, you get something continuous, right :) MB -- Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790 Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071 Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/ pgpTzzmXuPjx5.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about the USB of USRP1
On Friday 05 June 2009 05:14:40 Andrew Lutomirski wrote: On Thu, Jun 4, 2009 at 7:20 AM, Sebastiaan Heunis sheu...@gmail.com wrote: Hi all I've got a question about the bandwidth that the USRP1 can support across the USB. We have 32MB/s across the USB corresponding to 8Msps for a single I-Q stream. When we have two I-Q streams, this becomes 4Msps for each stream. This means that when I have two I-Q sampled channels, I should be able to set the decimation for each channel to 16. This does however not work. With two I-Q channels, if I set decimation to 16, I get about 40 of those 'uO' s printed on my screen. With a decimation of 32, I get about 4. With a decimation of 64, I get none. So, currently I am only able to support 8MB/s accross my USB without losing any samples. Keep in mind there is no direct relation between number of reported Overruns and the number of dropped samples, as the usrp is only polled for overruns at a fixed interval. Still the general figure of increased number of overruns for low dec rate stands. I ran the usrp_benchmark_usb.py and got the following: Testing 32MB/sec... usb_throughput = 32M ntotal = 1600 nright = 1565 runlength = 1565 delta = 35 OK So here I'm also losing 35 samples? This is expected behaviour (more or less). The first sample sent to the USRP may be received different to the first received sample, i.e there is some misalignment. The only important figure is the runlength, if it is sufficiently large, no sample has been dropped during the test run. I have an HP Pavilion dv6500 laptop with a 1.5GHz Core2Duo CPU and 2GB of RAM. I'm also using a CPU frequency scaling utility to make sure that my PC is running at full blast. Might it be that the USB controllers of laptops aren't that great, or is it normal to lose some samples at 32MBps? Disk access, some video card drivers may be keeping the kernel from rescheduling for quite some time. The guys using Linux for audio recording have some more information for sure, try googling ... I have 12 USRPs running at a decimation of 16 with 2 I/Q channels. On the current run, I've collected 2 *trillion* samples on each without any overruns. I'm doing this on Celeron 220's, which makes your laptop look positively fast. I'd check if you have realtime scheduling enabled and maybe try with C++ code instead of Python -- I've had good luck with usrp/host/apps/test_usrp_standard_rx.cc, although I haven't had much trouble with the Python code either. Realtime scheduling makes a very big difference if you have sporadic drops. There should be no difference between C++ and Python code, as the signal processing is done by the C++ code always. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen mailto:lurch at gmx.li http://www.kawo1.rwth-aachen.de/~lurchi/ phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Changes from 3.1 to 3.2?
Mikael Olofsson wrote: Greetings, I have just upgraded from GNU Radio 3.1 to 3.2. At the same time I upgraded from Ubuntu 8.04 to Ubuntu 9.04. The hardware setup is a USRP1 with an LFTX daughterboard. Under the previous setup (8.04+3.1), I could generate signals with an amplitude up to approx 1V. Above that the signal was severely distorted, which fits very well with what I've been able to read about the hardware. With the new setup (9.04+3.2), the same code generates signals with an amplitude of approx 0.28V, and above that the signal again is severely distorted. The old Python code has a line that sets the gain to midpoint, but it is conditionalized out, leaving it at the maximum. The current C++ db code sets it to midpoint in the constructor. .28V is roughly 10 dB down. The default is now -10 dB, which is the midpoint between 0 dB and -20dB. You need to send a call to set_gain to set it back to the maximum of 0 dB. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions Regarding Schematic Files and their Contents
Fahimeh Rezaei wrote: Hi Dear All friends I have two questions about some parts of schematic files 1- in the powe page, there are some capesitors which are connected between GND and different Voltages (DVDD, VDD5:1,), I tend to know if there is any relationship between the number of capecitors and the voltage which is connected to them and GND? for instance I could figure out that the number of capecitors which are connected to DVDD:1 and GND is 24 while the number of pins are 12 (12 220pF and 0.1uF pair), however for VCC1:5 I could not found exact relationship! can anybody help me in this issue? We try to get at least one cap per power pin, but sometimes there are more or less. 2- some of the values for resistors are not clear for instance in clocking page of schematic resistors which are connected to S[0..10] pins of AD9513 have no distict value. I'm wondering if anyone can help me regarding this problem! The AD9513 datasheet will give you enough information to figure out which resistors are populated and which are not. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP with USB/IP
Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. One can also setup a Linux box as the USB server to connect an USB device physicaly whith it and forward the USB connection to another computer. These boxes are small/cheap and supposable maintainance-free, though. Anyone already used USB/IP with USRP? Anyone used one of these boxes with USRP? Patrick [1] http://www.ednet-gmbh.de/?lang=enpage=1cat=10,70,0artnr=87025 [2] http://www.raidsonic.de/en/pages/products/external_cases.php?we_objectID=5376 [3] http://usbip.sourceforge.net/ -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser patrick dot strasser at student dot tugraz dot at Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP with USB/IP
Hi, --- On Fri, 6/5/09, Patrick Strasser patrick.stras...@tugraz.at wrote: Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. Patrick From the web site the transfer rate of these boxes is 10/100Mb/s. So theoretically it should transfer a maximum of 12.5MByte/sec which is far below the required 32Mbyte/sec of USRP1. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 80211_mac Carrier Sensing
Hello, I had a couple of questions about the carrier sensing functionality of the USRP2 and the BBN 802.11 code. When we call the carrier_sensing function and it returns a value in dB, how does the USRP2 sample its data? I know that it takes an average of the samples of the channel by using an IIR filter with the parameter alpha = 0.001. I calculated the sample period to be approximately 10 usec. Does the USRP2 actually sample faster (i.e. 1 usec), filter/decimate the data before returning a value every 10 usec? How fast can the USRP2 actually sample data? Does anyone suggest a value for alpha? With the given alpha, the carrier sensing block is storing values of the channel on the order of 10s of msec ago. Packets should last about 1-2 msec, so storing information for that long does not make a lot of sense. Thanks, Miklos Christine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP with USB/IP
On Fri, 2009-06-05 at 12:14 -0700, Firas Abbas wrote: Hi, --- On Fri, 6/5/09, Patrick Strasser patrick. stras...@tugraz.at wrote: Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. Patrick From the web site the transfer rate of these boxes is 10/100Mb/s. So theoretically it should transfer a maximum of 12.5MByte/sec which is far below the required 32Mbyte/sec of USRP1. Hello Firas. Just for my understanding: The 32Mbyte/s requirement is for a full speed - 4 channel USRP operation. But if we suppose a simpler application, e.g. 1 TX/RX channel only, wouldn't this fit in the USB/IP? Thanks for your reply. BR Alberto Promozione di Primavera ! Stampa le tue foto nei formati 13x17 e 13x19 a soli 0,11 euro. http://photo.tiscali.it ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP with USB/IP
Hi, --- On Sat, 6/6/09, Alberto Trentadue albtrenta...@tiscali.it wrote: On Fri, 2009-06-05 at 12:14 -0700, Firas Abbas wrote: Hi, --- On Fri, 6/5/09, Patrick Strasser patrick. stras...@tugraz.at wrote: Hello! ednet[1] and RaidSonic[2] sell boxes that can forward USB ports over via the Linux USB/IP[3] system. Patrick From the web site the transfer rate of these boxes is 10/100Mb/s. So theoretically it should transfer a maximum of 12.5MByte/sec which is far below the required 32Mbyte/sec of USRP1. Hello Firas. Just for my understanding: The 32Mbyte/s requirement is for a full speed - 4 channel USRP operation. NO. But if we suppose a simpler application, e.g. 1 TX/RX channel only, wouldn't this fit in the USB/IP? The 32MB/s is required for 1,2 and 4 channels. For 1 Channel when you sustain 32MB/s, this means that your dealing with 8M complex samples. For 2 channels, this means that you are dealing with 4M complex samples for each channel, ..etc. Thanks for your reply. BR Alberto Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
