Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"
At 16:27 -0800 09-01-2011, John Gilmore wrote: > -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lartmaker.nl/ Why is your email signature advertising a website that hasn't been updated since 2003? Perhaps that's a cautionary tale about free-hardware projects - they tend to go dead when only one or two people lose the interest or time required to keep them alive. Fair point. The sad truth is that it would be close to impossible to build a LART today, mostly because key components (the processor, the Flash chips) are out of production and impossible to find. The software, on the other hand, does live on. I get occasional support requests for commercial hardware which uses (a derivative of) our bootloader, and the FFT for ARM code gets more than a few hits. JDB. [I've a few other projects I'd like to publish, some SDR-related, but as you point out I've not found the time yet -- day job keeps getting in the way] -- Years from now, if you are doing something quick and dirty, you imagine that I am looking over your shoulder and say to yourself, "Dijkstra would not like this," well that would be immortality for me. -- Edsger Dijkstra, 1930 - 2002 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 connection problem
tcpdump ? - Original Message - From: mehmet kabasakal To: discuss-gnuradio Sent: Monday, January 10, 2011 6:56 PM Subject: [Discuss-gnuradio] USRP2 connection problem Hi everyone, I am using USRP2 on ubuntu 10.10. When i try to run it with grc i got the this message, Traceback (most recent call last): File "/home/mehmet/top_block.py", line 46, in tb = top_block() File "/home/mehmet/top_block.py", line 29, in __init__ self.usrp2_sink__0 = usrp2.sink_32fc() File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1137, in sink_32fc return _usrp2.sink_32fc(ifc, mac) RuntimeError: No USRPs found on interface eth0 then i run ifconfig eth0 command then i got, meh...@mehmet-pc:~$ sudo ifconfig eth0 [sudo] password for mehmet: eth0 Link encap:Ethernet HWaddr 60:eb:69:29:bb:c8 inet6 addr: fe80::62eb:69ff:fe29:bbc8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10416 errors:0 dropped:0 overruns:0 frame:0 TX packets:2654 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2112887 (2.1 MB) TX bytes:324570 (324.5 KB) Interrupt:48 Base address:0x4000 finally i tried find_usrps but again no response, meh...@mehmet-pc:~$ sudo find_usrps No USRP2 found. I have checked if i install sdcc compiler from synaptic package manager and it seems it is installed. I use the ethernet cable that comes with usrp2 in the package. then i changed the ethernet cable. I used the one that is for internet connection but it didn't work. The screenshot of the basic grc problem is attached. Thanks for your help. Mehmet -- ___ 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] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]
[Please! Möller, add a one line before and after you text, reading your replies is really a pain.] schrieb Moeller am 2011-01-09 18:07: > On 09.01.2011 05:48, Brian Padalino wrote: >>> Hello Mr. Ettus, >>> Do you have any plan to reduce price for USRP1 or release PCB layout for >>> poor students? >> So lets figure out something that is worth while for you to do - >> simulate something. Simulate anything! There is a channel simulator >> built into GNU Radio. Use it. Get familiar with it. Familiarize > He didn't ask for a simulator, he asked for real hardware. He did not back his request with some deeper insight why he exactly needs this thing except for he wants it and has not enough money to buy it. We do not know what he wants to accomplish, and how he thinks to get there, what he already did. This would be very valuable information - There are people around who could show alternatives that are easier to get or cheaper/free, and some people have set up USRPs to be used by other people. If you need off-the-air samples, some can be found already online, or maybe someone is willing to record some special signal for offline use on request. Having a transmit capability is one really not replaceable capability, but first that's quite at the end of the things to do, and second you can easily run in problems with frequency licence regulations. Moreover having an USRP is just half of the bill. The RF front-ends are necessary too, and if you want one of the more advanced, you want get far with <100$. Compared to other systems that's still cheap, but not for free. I agree with Brian, there is plenty of things that can be done without (expensive) hardware. > I saw some simpler approaches with a sound card. But that's really > narrow band. Not very much for a spectrum analyzer. > The SSRP approach seems to be more interesting: > > http://oscar.dcarr.org/ssrp/ > > It has a 15 MS/s ADC, 40 MS/s DAC, he counts $120 for the ADC board. > There's software to interface with Gnuradio. Last time I asked David Carr had not time/interrest in continueing the project. IMO the Elrasoft Interface board is ridiculous expensive. Its merely an Cypress EZ-USB FX2 with some voltage regulators for 89$. I think it was a good start, but there are other more promising parts worth investigating: * Have a look at Digilent [1] Basys and Nexsys boards. You get the same interface chip as the USRP, which should give a good start for firmware development, and a FPGA, switches, buttons, displays, connectors (VGA/PS2 etc.) for about the same or less price. Academics/Students get it cheaper. Moreover Digilent offers a number of modules to connect, with examples and schematics. If you really want high sampling rates and frequencies, have a look at the Charleston SDR [2]. * One interresting RX interface coming up these days is the FuncubeDongle [3]. Unfortunately it's under a NDA spell, but the thingy rocks. Hopefully the next batch will not be sold out in seconds. * The Icom PCR1000 [4] is a commercial part with great frequency range. ZFs at 10.7MHz and 450kHz exist, so maybe you can connect it to some other standard hardware to do some great hacks and get RF OTA very cheap. * If you have equipment to bring your signal down to baseband there is nothing more promising than the SDR Widget [5][6]. They target USB Audio usage, at 24 bits/192kHz, which should be quite sufficient for a number of things to try. They claim to beat most of the commercial high end PC sound interfaces in signal performance. You see, there are quite some parts for ~100$ as alternative to USRPs. Hardware exists, software is cheap if you have time and skill, as J.D. Baker explained. If you do not have the skill, you still can learn ;-) Regards Patrick [1] https://www.digilentinc.com/ [2] http://www.amrad.org/projects/charleston_sdr/ [3] http://www.funcubedongle.com/ [4] http://shop.ebay.com/i.html?_nkw=icom+pcr [5] http://code.google.com/p/sdr-widget/ [6] http://groups.google.com/group/sdr-widget -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telemati_cs_, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About clock rate of USRP E100
Hello list, We are planning to do some experiments with USRP E100. One advantage of E100 that we are excited with is that "The user can choose (at run time) a convenient clock rate". Our question is: 1) When we change the clock rate changed, is the main clock rate changed, or is it just change in the decimation rate? We are asking this because we are interested in the energy consumption of USRP E100. The energy consumption is likely to be reduced if the main clock rate is reduced, but unlikely to be reduced if it's just change in decimation rate. 2) How long does it take for the USRP E100 to stablize from one clock rate to another? Could you help clarify the problem if you know about the USRP E100? Thanks!! -- View this message in context: http://old.nabble.com/About-clock-rate-of-USRP-E100-tp30634189p30634189.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Make check failure in next branch
I'm seeing this make check failure on x86 and armv7 in the next branch: qa_set_msg_handler::t0 Assertion qa_set_msg_handler.cc 84 equality assertion failed - Expected: 10 - Actual : 0 Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]
On Mon, Jan 10, 2011 at 02:23:47PM +0100, Patrick Strasser wrote: > > He didn't ask for a simulator, he asked for real hardware. > > He did not back his request with some deeper insight why he exactly > needs this thing except for he wants it and has not enough money to buy > it. We do not know what he wants to accomplish, and how he thinks to get > there, what he already did. This would be very valuable information - If I may add a note here: I agree with Brian and Patrick, and would even go further to say that developing fun stuff needs no hardware at all. In fact, whenever I do, say, some kind of receiver, the first thing I do is record signals to a file, so I don't have to touch any hardware *at all* until I've reached a point where I believe my code might work in real life. As long as I'm in the software domain, my tools of choice are Matlab (my dishes out free licences to our students) and scipy. You can get quite far that way. Pre-recorded signals are available on the net, and a polite query on this list to obtain such files from other users is not uncommon. Of course, using Matlab etc. it's also quite possible to write transmitters. As Patrick said, we have no idea what the OP wanted to achieve, but as was also said before, writing something along the lines of "I've just completed a complete receiver chain for standard XYZ, is there anyone with a working USRP to help me out" is likely to get a more favourable response. Finally, if you're a student, a university's probably not far. Here, if you're a student and really want to do something with a USRP (and other hardware), we usually manage to figure something out. The common case is that we make developing something with GNU Radio and the USRP a topic for a Bachelor's thesis. Students get lab access, some tutoring, meet other GNU Radio developers (unfortunately not too many) and even get a degree at the end. How about that. In fact, that's how most of the guts of the Spectral Estimation Toolbox got created. So, I hope this didn't sound too snobbish -- but I think that using GNU Radio, essentially any budget is enough to get started doing serious SDR stuff. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpHoG5h9qWzl.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 & DBSRX2
Hi everyone, Does one have to make any changes to the hardware when working with a DBSRX2 and a USRP2, as was the case with the original DBSRX? Are there any python examples that demonstrate how to work with the DBSRX2 on the USRP2? Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Parallel programming
Hello All, I've been writing my own signal processing blocks and I noticed that gnuradio only uses one of my cores. I'm not sure if it is using just one core for my blocks or for all processing. Is gnuradio written to take advantage of multicore processing? I have been writing my blocks in generic c++ code, but now I am looking to write my blocks using multithreading/multicore processing. However, I am new to this and would like some advice on how to approach this. I have an Intel 8-Core Xenon in my PC (I don't know the exact model but I believe the clock rate works around 2.8 Ghz). What libraries should I use? I have been looking into Intel Thread Building Blocks, but I am wondering what people mainly use for gnuradio. Please let me know. Thanks -- View this message in context: http://old.nabble.com/Parallel-programming-tp30634902p30634902.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using a TV tuner as a high speed ADC
FWIW Analog to Digital Converter with 16 bits and 448000 Samples per second based in the Bt878A http://hackaday.com/2005/11/08/using-a-tv-tuner-as-a-high-speed-adc/ ---which takes you to http://www.domenech.org/bt878a-adc/index-e.htm ---Also see btaudio.c module modification to get 896000 Samples per second with the Bt878A ADC http://www.domenech.org/bt878a-adc/index-decimator-e.htm My added comments: The above is a cool hardware hack that claims to take care of the baseband problem only- but I find it intriguing to wonder if it would be possible also to do two more ambitious things- 1) Using its TV tuner module (under software control of course), down-convert a swath of its output spectrum (prior to any detection) into the band covered by the extended range of the ADC 2) All of the above is based on the audio ADC. If some way could be found to hack into the video one also, MHz bandwidths could become theoretically possible... Best Regards Max ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 & DBSRX2
On 01/10/2011 10:45 AM, Nick Othieno wrote: > Hi everyone, > > Does one have to make any changes to the hardware when working with a > DBSRX2 and a USRP2, as was the case with the original DBSRX? > > Are there any python examples that demonstrate how to work with the > DBSRX2 on the USRP2? > > Nick > > > No hardware changes are required, but only UHD supports the DBS_RX2. If you update to the latest GIT for both Gnu Radio and UHD, it should "just work". -- 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] USRP2 & DBSRX2
On Mon, 2011-01-10 at 10:45 -0500, Nick Othieno wrote: > Hi everyone, > > Does one have to make any changes to the hardware when working with a > DBSRX2 and a USRP2, as was the case with the original DBSRX? > > Are there any python examples that demonstrate how to work with the > DBSRX2 on the USRP2? If you haven't moved to UHD yet, you will have to upgrade. If you have moved to UHD, update to the latest code and rebuild. No changes should be required to your Python code (if it's already using UHD). --n > Nick > > > ___ > 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] USRP2 & DBSRX2
Wow. Slow down there. I am a newbie. I downloaded and compiled the gnuradio code sometime in late December 2010. However from your response, I am guessing I should first download (checkout), compile and install UHD, then finally compile and install gnuradio. (Just thinking aloud here but a confirmation would not hurt :-)). Meantime, are there any python examples that demonstrate how a USRP2 and DBSRX2 setup should work? Included in this setup is a log periodic antenna (LP0926) that covers the 900MHz to 2.6GHz range ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 & DBSRX2
On 01/10/2011 11:43 AM, Nick Othieno wrote: Wow. Slow down there. I am a newbie. I downloaded and compiled the gnuradio code sometime in late December 2010. However from your response, I am guessing I should first download (checkout), compile and install UHD, then finally compile and install gnuradio. (Just thinking aloud here but a confirmation would not hurt :-)). Meantime, are there any python examples that demonstrate how a USRP2 and DBSRX2 setup should work? Included in this setup is a log periodic antenna (LP0926) that covers the 900MHz to 2.6GHz range Once you have followed the directions for building and installing UHD, and the Gnu Radio branch that supports UHD, then I'd recommend spending some quality time with Gnuradio Companion (gnuradio-companion) to put together simple Rx flow-graphs. With GnuRadio Companion, you don't necessarily *need* conventional "examples". It's a GUI-based "flow-graph builder". For the most part, applications (at least in the UHD universe) don't really need to "know" much about the daughtercard that is plugged into the hardware. In this case, you'd create a UHD source, at an appropriate input bandwidth, set the desired frequency, and then "do stuff" with the result--like plotting on a graphical FFT sink, etc, etc. -- Marcus Leech 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] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]
Hi there, Just my 2 cents: It's possible to use gnuradio with the soundcard as a receiver / transmitter. Most of the people that listens to DRM (Digital Radio Mondiale) in the shortwaves band just buy small tuners that just downconverts the desired frequency to 12kHz for soundcard input, like this one: http://www.pappradio.de Or you just use your normal AM/FM transmitter and downconverts the FI of the radio to 12kHz using for example this box: http://www.electronicspecialtyproducts.com/dm1.html I'll be able to use gnuradio to inspect and analyze any narrowband signal you want just with a sound card and inexpensive hardware. Best regards, Rafael Diniz > On Mon, Jan 10, 2011 at 02:23:47PM +0100, Patrick Strasser wrote: >> > He didn't ask for a simulator, he asked for real hardware. >> >> He did not back his request with some deeper insight why he exactly >> needs this thing except for he wants it and has not enough money to buy >> it. We do not know what he wants to accomplish, and how he thinks to get >> there, what he already did. This would be very valuable information - > > If I may add a note here: I agree with Brian and Patrick, and would even > go further to say that developing fun stuff needs no hardware at all. > In fact, whenever I do, say, some kind of receiver, the first thing I do > is record signals to a file, so I don't have to touch any hardware *at > all* until I've reached a point where I believe my code might work in > real life. > As long as I'm in the software domain, my tools of choice are Matlab (my > dishes out free licences to our students) and scipy. You can get quite > far that way. Pre-recorded signals are available on the net, and a > polite query on this list to obtain such files from other users is not > uncommon. Of course, using Matlab etc. it's also quite possible to write > transmitters. > > As Patrick said, we have no idea what the OP wanted to achieve, but as > was also said before, writing something along the lines of "I've just > completed a complete receiver chain for standard XYZ, is there anyone > with a working USRP to help me out" is likely to get a more favourable > response. > > Finally, if you're a student, a university's probably not far. Here, if > you're a student and really want to do something with a USRP (and other > hardware), we usually manage to figure something out. The common case is > that we make developing something with GNU Radio and the USRP a topic > for a Bachelor's thesis. Students get lab access, some tutoring, meet > other GNU Radio developers (unfortunately not too many) and even get a > degree at the end. How about that. > In fact, that's how most of the guts of the Spectral Estimation Toolbox > got created. > > So, I hope this didn't sound too snobbish -- but I think that using GNU > Radio, essentially any budget is enough to get started doing serious SDR > stuff. > > Cheers, > MB > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > KaiserstraÃe 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > ___ > 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] Parallel programming
Assuming you're using a reasonably recent GIT checkout, then your flow-graph should be executing in "thread per block" mode by default -- each block you create in your flow-graph will reside in its own unique thread. You can manually override this setting to be in "single threaded scheduler" mode instead, where all blocks are executed within a single thread in a round-robin fashion (roughly; no need for its complexities here). Those are your 2 choices when using GNU Radio (without rewriting the scheduler yourself). IIRC the latter (STS) is being deprecated "real soon now" -- someone please correct me if I'm remembering incorrectly. Generally, you shouldn't need to further parallelize beyond what's already provided. A specific case where one would want do add another thread is when data must be transferred non-synchronously (e.g., async or isync) -- for example, the native USB driver for Mac OS X spawns a new thread to handle the OS-interface part. Otherwise, you can probably find a clever way to create a "meta-block" that encloses a number of actual blocks, and then let the "thread per block" scheduler handle them. GNU Radio uses Intel's TBB already, so if you feel for some reason that your particular block(s) need more parallelization, then that's probably the best way to go. My US$0.02, for what it's worth. - MLD On Jan 10, 2011, at 10:52 AM, sirjanselot wrote: > I've been writing my own signal processing blocks and I noticed that > gnuradio only uses one of my cores. > > I'm not sure if it is using just one core for my blocks or for all > processing. > > Is gnuradio written to take advantage of multicore processing? > > I have been writing my blocks in generic c++ code, but now I am looking to > write my blocks using multithreading/multicore processing. However, I am > new to this and would like some advice on how to approach this. > > I have an Intel 8-Core Xenon in my PC (I don't know the exact model but I > believe the clock rate works around 2.8 Ghz). What libraries should I use? > I have been looking into Intel Thread Building Blocks, but I am wondering > what people mainly use for gnuradio. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]
> Or you just use your normal AM/FM transmitter and downconverts the FI of I was supposed to say receiver instead of transmitter. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 & DBSRX2
Thanks for the info. I will look into that ASAP! On Mon, Jan 10, 2011 at 12:16 PM, Marcus D. Leech wrote: > On 01/10/2011 11:43 AM, Nick Othieno wrote: > >> Wow. Slow down there. I am a newbie. >> >> I downloaded and compiled the gnuradio code sometime in late December >> 2010. However from your response, I am guessing I should first download >> (checkout), compile and install UHD, then finally compile and install >> gnuradio. (Just thinking aloud here but a confirmation would not hurt :-)). >> >> Meantime, are there any python examples that demonstrate how a USRP2 and >> DBSRX2 setup should work? Included in this setup is a log periodic antenna >> (LP0926) that covers the 900MHz to 2.6GHz range >> >> Once you have followed the directions for building and installing UHD, > and the Gnu Radio branch that supports UHD, then I'd recommend > spending some quality time with Gnuradio Companion (gnuradio-companion) to > put together simple Rx flow-graphs. > > With GnuRadio Companion, you don't necessarily *need* conventional > "examples". It's a GUI-based "flow-graph builder". > > For the most part, applications (at least in the UHD universe) don't really > need to "know" much about the daughtercard that is plugged into > the hardware. In this case, you'd create a UHD source, at an appropriate > input bandwidth, set the desired frequency, and then > "do stuff" with the result--like plotting on a graphical FFT sink, etc, > etc. > > > -- > Marcus Leech > > 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 & DBSRX2
On Mon, Jan 10, 2011 at 12:04 PM, Ben Ahrens wrote: >> >> Dig these two links, in order: >> http://code.ettus.com/redmine/ettus/projects/uhd/wiki >> http://www.ettus.com/uhd_docs/manual/html/build.html >> >> Then just install gnuradio as usual. >> >> Ben On Mon, Jan 10, 2011 at 11:43 AM, Nick Othieno wrote: > Wow. Slow down there. I am a newbie. > > I downloaded and compiled the gnuradio code sometime in late December > 2010. However from your response, I am guessing I should first download > (checkout), compile and install UHD, then finally compile and install > gnuradio. (Just thinking aloud here but a confirmation would not hurt :-)). > > Meantime, are there any python examples that demonstrate how a USRP2 and > DBSRX2 setup should work? Included in this setup is a log periodic antenna > (LP0926) that covers the 900MHz to 2.6GHz range > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Alternative Hardware
On 01/10/2011 08:23 AM, Patrick Strasser wrote: * Have a look at Digilent [1] Basys and Nexsys boards. You get the same interface chip as the USRP, which should give a good start for firmware development, and a FPGA, switches, buttons, displays, connectors (VGA/PS2 etc.) for about the same or less price. Academics/Students get it cheaper. Moreover Digilent offers a number of modules to connect, with examples and schematics. If you really want high sampling rates and frequencies, have a look at the Charleston SDR [2]. Oooh, the Charleston SDR is within about 5-6dB(Msps) of what I'd like in a cheaper hardware alternative. You know, a "reasonable" project for some C++ keener on this list would be to write a UHD driver interface for the Charleston SDR system, and open-source the results. Might even make a not-bad undergraduate project. But since we're on the topic of alternative hardware, I'll throw in my ***PERSONAL two-cents about this. I think that there are a couple of different "forks" to this. There are experimenters who do Rx-only (I'd say perhaps more than half of the folks on this list), for whom a less-functional hardware system (and presumably less costly) would be "reasonable". For experimenters who want to do Tx, they also overwhelmingly-likely want to do Tx/Rx, and for that, it would be hard to beat what is already out there (although, I'm willing to be convinced otherwise). For an Rx-only "solution", I'd want: o Integrated RF down-conversion chain o It would be hard to get much better than what the WBX uses here, based on the ADL5387 (quadrature mixer) and ADF4350 (PLL synthesizer). Such a "line-up" would give coverage from 68.75MHz to 2.2GHz. o Ability to use external 10MHz reference both for PLL and sampling clock. o One might simplify this to use an external 40MHz reference that is used directly for the sampling clock, and /4 for the PLL. o Perhaps a switch-in upconverter that converts HF up to a convenient IF (70MHz, 100MHz??) for the ADL5387/ADF4350 stage. o 40Msps ADC o possibly one with built-in DDC and decimation hardware, with the proviso that it support full-rate (no decimation). The one used by the Charleston SDR has the right overall architecture, but supports a maximum bandwidth of 2.5Msps complex. o possibly variable sample rate o A convenient computer interface o I'd prefer 1GiGe, so that I could "deliver" the full 40Msps (with reduced sample sizes) to the host computer. o USB would be acceptable. Notice that there's no FPGA shown here. My hope is that there's something similar to the TI parts used by the Charleston SDR, but allowing higher bandwidths (lower decimation). An alternative (that still doesn't require an FPGA) is to have switchable baseband filters on the output of the analog front-end, covering various "useful" bandwidths. These would have to be fairly "stiff", to allow a lower sample rate to work properly. I wonder if SCFs (Switched-Capacitor Filters) exist that cover these bandwidths (let's say, 2.5MHz to 20MHz). My off-the-cuff proposal for such a scheme would be four discrete filters: o 20MHz(40Msps) o 10MHz(20Msps) o 5MHz (10Msps) o 2.5MHz (5Msps) -- Marcus Leech 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] Compile Gnuradio 3.3.0
Can anyone advice on the following: I am compiling gnuradio 3.3.0 on Ubuntu 10.10 and following instruction on UbuntuInstall of gunradio.org And I've installed the Boost by apt-get, is it necessary to install Boost manually? - For Ubuntu 8.04 and older, download and install Boost 1.35 or later as follows Then, the instruction than teaches me to set the LD_LIBRARY_PATH, however, the ENV_VAR $BOOST_PREFIX is not set. export LD_LIBRARY_PATH=$BOOST_PREFIX/lib Where should I post $BOOST_PREFIX to? to /usr/lib as the .a lib files are there or to /usr/include/boost where the hpp files are there Moreover, it sets the $BOOST_PREFIX/lib and I can't find lib under the boost directories. And here are the result of config.log grep boost: configure:20389: checking for boost>= 1.35 configure:20955: checking whether the boost::thread includes are available Thanks for kindly help. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Creating a gr_sync_block subclass in python?
On 01/08/2011 01:10 PM, Holger Freyther wrote: > Hi, > > I would like to convert symbols (1 float) into two bytes. I thought I want to > use a gr_sync_block for that (1:1 mapping). Now I would like to do this in > python. After looking around, trying things and reading an old thread from > october 2006 I come to the conclusion that it is not possible to create a > gr_sync_block and have ''work'' called in python? > You cant make functions in python and pass them into C++. I think the swig docs say something about this. Basically, the python functions are just objects, they are not functions to be called when you get into the c++ level. Maybe it can be done, but its outside the scope of what swig covers, or at least its not simple or obvious. > The reason to use python would be to avoid having the user compile stuff > and being faster in prototyping a solution. Is there any way to do some > processing in python? > Yes, make a generic hier block class that has message queues in and out, and a thread to read data, call a work function, write the data. Now you can override this block with your own work function and io signature and plug it into any generic python flowgraph. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Compile Gnuradio 3.3.0
I assume you're looking here: http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall. If so, you just need to run this: sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ automake libtool python-dev libfftw3-dev \ libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-libraries \ libsdl1.2-dev python-wxgtk2.8 subversion git-core guile-1.8-dev \ libqt4-dev python-numpy ccache python-opengl libgsl0-dev \ python-cheetah python-lxml doxygen qt4-dev-tools \ libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools If you look carefully boost is in there. If you use the above script there shouldn't be any other dependencies you need to install. You shouldn't need to use those instructions to install libboost after that. Ben On Mon, Jan 10, 2011 at 12:50 PM, Howard Wong wrote: > Can anyone advice on the following: > > I am compiling gnuradio 3.3.0 on Ubuntu 10.10 > and following instruction on UbuntuInstall of gunradio.org > > And I've installed the Boost by apt-get, is it necessary to install Boost > manually? > - For Ubuntu 8.04 and older, download and install Boost 1.35 or later as > follows > > > > Then, the instruction than teaches me to set the LD_LIBRARY_PATH, > however, the ENV_VAR $BOOST_PREFIX is not set. > > export LD_LIBRARY_PATH=$BOOST_PREFIX/lib > > > Where should I post $BOOST_PREFIX to? > to /usr/lib as the .a lib files are there > or to /usr/include/boost where the hpp files are there > > Moreover, it sets the $BOOST_PREFIX/lib and I can't find lib under the > boost directories. > > > And here are the result of config.log grep boost: > > configure:20389: checking for boost >= 1.35 > configure:20955: checking whether the boost::thread includes are available > > > Thanks for kindly help. > > ___ > 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] About clock rate of USRP E100
On 01/10/2011 09:25 AM, Miok Wah wrote: Hello list, We are planning to do some experiments with USRP E100. One advantage of E100 that we are excited with is that "The user can choose (at run time) a convenient clock rate". Our question is: 1) When we change the clock rate changed, is the main clock rate changed, or is it just change in the decimation rate? We are asking this because we are interested in the energy consumption of USRP E100. The energy consumption is likely to be reduced if the main clock rate is reduced, but unlikely to be reduced if it's just change in decimation rate. There are two clock rates to consider: there is the fpga clock rate which is settable via uhd. I'm not good enough at fpga's to know how much power can be saved this way. The OMAP3 clock circuitry allows sections of the OMAP to be turned off, or clocked at lower rates to save power. This is how they use this chip in mobile devices. That said, the kernel and user space provided with the E100 has the clock rate set to the max possible and does not take advantage of the OMAP power saving features. It should be possible to do work in this area with the E100 though. There is lots of activity on the linux-omap kernel mailing list in the power management area. Philip 2) How long does it take for the USRP E100 to stablize from one clock rate to another? Could you help clarify the problem if you know about the USRP E100? Thanks!! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Parallel programming
How do I know that my flow-graph is executing in thread per block mode? As far as I can tell my only 1 core out of the 8 is being used when I run my flow-graphs. This is what I see when I run the performance monitor (or whatever it is called) in Ubuntu. I am currently using gnuradio 3.3.0 as my version. So can I parallelize my block without having to create a meta-block as you say? I have a lot of for-loops and vector calculations that need to be optimized (adaptive fir filters). Michael Dickens-3 wrote: > > Assuming you're using a reasonably recent GIT checkout, then your > flow-graph should be executing in "thread per block" mode by default -- > each block you create in your flow-graph will reside in its own unique > thread. You can manually override this setting to be in "single threaded > scheduler" mode instead, where all blocks are executed within a single > thread in a round-robin fashion (roughly; no need for its complexities > here). Those are your 2 choices when using GNU Radio (without rewriting > the scheduler yourself). IIRC the latter (STS) is being deprecated "real > soon now" -- someone please correct me if I'm remembering incorrectly. > > Generally, you shouldn't need to further parallelize beyond what's already > provided. A specific case where one would want do add another thread is > when data must be transferred non-synchronously (e.g., async or isync) -- > for example, the native USB driver for Mac OS X spawns a new thread to > handle the OS-interface part. Otherwise, you can probably find a clever > way to create a "meta-block" that encloses a number of actual blocks, and > then let the "thread per block" scheduler handle them. GNU Radio uses > Intel's TBB already, so if you feel for some reason that your particular > block(s) need more parallelization, then that's probably the best way to > go. > > My US$0.02, for what it's worth. - MLD > > On Jan 10, 2011, at 10:52 AM, sirjanselot wrote: >> I've been writing my own signal processing blocks and I noticed that >> gnuradio only uses one of my cores. >> >> I'm not sure if it is using just one core for my blocks or for all >> processing. >> >> Is gnuradio written to take advantage of multicore processing? >> >> I have been writing my blocks in generic c++ code, but now I am looking >> to >> write my blocks using multithreading/multicore processing. However, I am >> new to this and would like some advice on how to approach this. >> >> I have an Intel 8-Core Xenon in my PC (I don't know the exact model but I >> believe the clock rate works around 2.8 Ghz). What libraries should I >> use? >> I have been looking into Intel Thread Building Blocks, but I am wondering >> what people mainly use for gnuradio. > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Parallel-programming-tp30634902p30636613.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] Compile Gnuradio 3.3.0
Thank you very much, Ben On 11/01/2011 03:43, Ben Ahrens wrote: I assume you're looking here: http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall. If so, you just need to run this: sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ automake libtool python-dev libfftw3-dev \ libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-libraries \ libsdl1.2-dev python-wxgtk2.8 subversion git-core guile-1.8-dev \ libqt4-dev python-numpy ccache python-opengl libgsl0-dev \ python-cheetah python-lxml doxygen qt4-dev-tools \ libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools If you look carefully boost is in there. If you use the above script there shouldn't be any other dependencies you need to install. You shouldn't need to use those instructions to install libboost after that. Ben On Mon, Jan 10, 2011 at 12:50 PM, Howard Wong wrote: Can anyone advice on the following: I am compiling gnuradio 3.3.0 on Ubuntu 10.10 and following instruction on UbuntuInstall of gunradio.org And I've installed the Boost by apt-get, is it necessary to install Boost manually? - For Ubuntu 8.04 and older, download and install Boost 1.35 or later as follows Then, the instruction than teaches me to set the LD_LIBRARY_PATH, however, the ENV_VAR $BOOST_PREFIX is not set. export LD_LIBRARY_PATH=$BOOST_PREFIX/lib Where should I post $BOOST_PREFIX to? to /usr/lib as the .a lib files are there or to /usr/include/boost where the hpp files are there Moreover, it sets the $BOOST_PREFIX/lib and I can't find lib under the boost directories. And here are the result of config.log grep boost: configure:20389: checking for boost>= 1.35 configure:20955: checking whether the boost::thread includes are available Thanks for kindly help. ___ 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] Parallel programming
On 01/10/2011 03:11 PM, sirjanselot wrote: How do I know that my flow-graph is executing in thread per block mode? As far as I can tell my only 1 core out of the 8 is being used when I run my flow-graphs. This is what I see when I run the performance monitor (or whatever it is called) in Ubuntu. I am currently using gnuradio 3.3.0 as my version. So can I parallelize my block without having to create a meta-block as you say? I have a lot of for-loops and vector calculations that need to be optimized (adaptive fir filters). By default, each flow-graph is assigned its own thread. It's up to the kernel to schedule these as it sees fit. Getting parallelism *inside your own custom block* is something you'll have to deal with yourself. I've done experiments with using the multi-threaded FFTW libraries for very large transforms, which causes internal parallelism with the FFTW library. This works, and doesn't appear to adversely affect Gnu Radio thread-per-block scheduling. The thread-per-block scheduler is the default behaviour, so the reason you may only be seeing one core in use is just due to the dynamic behaviour of your flowgraph. -- Marcus Leech 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] Parallel programming
Without seeing your GRC implementation or Python script & block's implementation code, mostly what I or anyone else can provide is general advice. GNU Radio 3.3.0 uses the thread per block (TBP) scheduler by default; if you're not doing anything else except running the flow-graph (meaning: you don't set special GNU Radio environment variables or use a GNU Radio configuration file), then that's what you're using. The performance of any flow-graph really depends on how complex the flow-graph is, how much data you're trying to push through it, and how fast your processors are able to perform the block's computations. The host OS influences execution speed a little, but mostly its those listed factors that make the difference; that said, I haven't used GNU Radio on Ubuntu in a long time so I cannot talk about that OS specifically (Linux, in general, provides very low OS overhead & more time executing the flow-graph's computations). It might be that your flow-graph is running fast enough already to use just 1 core; does it run in "real time" for what you need? Rewriting a given block to use vector-based instructions (SSE, Altivec, Neon) often dramatically increases the computations / time for that block. As for parallelizing your block, without knowing what it is/does exactly, I would always advise you to break down the computations into smaller pieces and then implement those as blocks (if they are no already), then create the "meta-block" (I forget the exact name of it now; maybe "heir_block2"?) using those. That way, the TBP scheduler will have more to work with and the flow-graph will end up being executed more in parallel. If your block has internal data-feedback, then the meta-block will not work (GNU Radio doesn't "do" data-flow feedback in the flow-graph) & you'll have to find some way of parallelizing your algorithm. There are plenty of good books on this subject. - MLD On Jan 10, 2011, at 3:11 PM, sirjanselot wrote: > I am currently using gnuradio 3.3.0 as my version. > How do I know that my flow-graph is executing in thread per block mode? > > As far as I can tell my only 1 core out of the 8 is being used when I run my > flow-graphs. This is what I see when I run the performance monitor (or > whatever it is called) in Ubuntu. > > So can I parallelize my block without having to create a meta-block as you > say? I have a lot of for-loops and vector calculations that need to be > optimized (adaptive fir filters). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Benchmark scripts
All, I am testing 2x USRP1 with RFX2400 daughter cards with benchmark_rx and benchmark_tx scripts and have questions. When I set the MCS to dbpsk, error rate I got was close to zero. When I set it to dqpsk, d8psk, error rate is 100%. When I set it to gmsk, certain daughter cards had close to 0 error rate, but certain swung from 0% to 100%. I asked about it to Ettus research, they told me that it's likely to be due to frequency offset between the two boxes I have. If it is true, 1) how can I compensate the offset? 2) Has someone used dqpsk, d8psk in 2.4MHz ISM band before? If so, what extra step is necessary? Thanks, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Benchmark scripts
Hello Thomas H Kim: I assume you have the two clocks synchronized. There is a 10 MHz reference clock input on the front of the USRP2. But on the USRP you need to get a soldering iron and modify the hardware a little (I think you need to remove a resistor, or something like that) to add a 10 MHz reference input. You could also the use the 1 PPS input for your two USRPs. Let me know if this helps. Steve --- On Mon, 1/10/11, Thomas H Kim wrote: From: Thomas H Kim Subject: [Discuss-gnuradio] Benchmark scripts To: discuss-gnuradio@gnu.org Date: Monday, January 10, 2011, 3:55 PM All, I am testing 2x USRP1 with RFX2400 daughter cards with benchmark_rx and benchmark_tx scripts and have questions. When I set the MCS to dbpsk, error rate I got was close to zero. When I set it to dqpsk, d8psk, error rate is 100%. When I set it to gmsk, certain daughter cards had close to 0 error rate, but certain swung from 0% to 100%. I asked about it to Ettus research, they told me that it's likely to be due to frequency offset between the two boxes I have. If it is true, 1) how can I compensate the offset? 2) Has someone used dqpsk, d8psk in 2.4MHz ISM band before? If so, what extra step is necessary? Thanks, Thomas -Inline Attachment Follows- ___ 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] Benchmark scripts
On Mon, 2011-01-10 at 15:55 -0500, Thomas H Kim wrote: > All, > > I am testing 2x USRP1 with RFX2400 daughter cards with benchmark_rx > and benchmark_tx scripts and have questions. > When I set the MCS to dbpsk, error rate I got was close to zero. > When I set it to dqpsk, d8psk, error rate is 100%. > When I set it to gmsk, certain daughter cards had close to 0 error > rate, but certain swung from 0% to 100%. > > I asked about it to Ettus research, they told me that it's likely to > be due to frequency offset between the two boxes I have. > If it is true, > 1) how can I compensate the offset? Make a simple little FFT sink in GRC and use it on one of the USRPs to determine the received signal offset from the other USRP while it is transmitting. Or receive a signal from a signal generator of known frequency and note the offset for both USRPs. Or transmit a signal from each USRP and receive it using a different receiver and note the difference between the frequencies of the received signals. Or vary the frequency of either benchmark_rx or benchmark_tx via trial and error until you get proper transmission/reception. You will probably find less than 20kHz of offset at 2.4GHz. --n > 2) Has someone used dqpsk, d8psk in 2.4MHz ISM band before? If so, > what extra step is necessary? > Thanks, > > Thomas > ___ > 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] 192KHz sound card experience: WWVB, etc
I finally installed a M-Audio Audiophile 192 sound-card on my F14 system today, further to my efforts to make a WWVB (and DCF77 and any other time station that uses broadly-similar mechanisms) receiver based on little more than a high-rate sound-card, pre-amp, and loop antenna (and of course, Gnu Radio). I have a similar set-up for doing SID detection on VLF, using an external 96KHz USB sound-card--a Creative X-Fi USB. What I've found is that the M-Audio internal 192KHz card has a roughly 10dB higher noise floor (or put another way, a 10dB poorer SNR) than the external sound sysem. The M-Audio Audiophile 192 uses a 24-bit ADC and can sample at 192KHz. I ended up having to turn up the gain on my pre-amplifer, in order to compensate for the much-poorer noise performance on the Audiophile 192. The way things are now, I can't "see" WWVB in the spectrum. I'll see how it is tonight, but it sure doesn't look to "be there". This is at least consistent with my LaCrosse WWVB-synchronized digital clock that I have, which has *never* been able to get a lock on WWVB the entire time I've lived in this house. I may look into the SDR-Widget system (Thanks, Patrick Strasser!), since it boasts better performance than most other 192KHz sound systems out there, and is tailored to narrowband SDR work. -- Marcus Leech 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] Parallel programming
On Mon, Jan 10, 2011 at 3:11 PM, sirjanselot wrote: > > How do I know that my flow-graph is executing in thread per block mode? You can run 'top' while executing your flow graph and then toggle threads on (type capital 'H'). Each thread will be displayed on its own. With a Python-based GNU Radio application, all you will see is python; when you toggle threads on, you should see python listed multiple times; one for each thread. 'man top' will tell you how to get a lot out of that program. Tom > As far as I can tell my only 1 core out of the 8 is being used when I run my > flow-graphs. This is what I see when I run the performance monitor (or > whatever it is called) in Ubuntu. > > I am currently using gnuradio 3.3.0 as my version. > > So can I parallelize my block without having to create a meta-block as you > say? I have a lot of for-loops and vector calculations that need to be > optimized (adaptive fir filters). ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Benchmark scripts
Make a simple little FFT sink in GRC and use it on one of the USRPs to determine the received signal offset from the other USRP while it is transmitting. Or receive a signal from a signal generator of known frequency and note the offset for both USRPs. Or transmit a signal from each USRP and receive it using a different receiver and note the difference between the frequencies of the received signals. Or vary the frequency of either benchmark_rx or benchmark_tx via trial and error until you get proper transmission/reception. You will probably find less than 20kHz of offset at 2.4GHz. --n This topic comes up repeatedly on this list. When you have a radio "tuned" to a specific frequency, there is *nearly-always* a certain amount of residual frequency error. Synthesized LOs (local oscillators) have a frequency offset that is proportional to the PPM tolerance of the reference oscillator that they're using. Let's say that the oscillator has a 10PPM tolerance (which is typical, I don't, off the top of my head, know what the PPM spec is for the XO in the USRP1). So, that's 10Hz for every MHz of crystal frequency. That error "carries through" the PLL synthesizer. In this case, we have an LO frequency of 2.4GHz, so, that 2.4GHz/10PPM which gives us a potential frequency offset error of 24KHz--let's be charitable and assume that means anywhere +/- 12KHz. For wideband modulations (higher data rates), a small frequency offset is generally mostly-harmless, since *most* of the modulation energy falls within your passband, even if the edges of your passband don't fall where you think they fall. But for narrowband modulation schemes (low data rates, or narrow OFDM buckets), frequency offset can be disasterous, since an offset in the band-edge causes most of the energy to fall *outside* of your passband. In "real" data receivers, particularly narrowband ones, there's generally a feedback mechanism that tugs on the LO circuit a little bit to try and zero-in on the correct frequency. In the analog world, FM stereo receivers have a so-called AFC circuit that uses noise estimates to steer the LO. Television does the same thing (so-called AFT). In the world of software-defined radio, it's easy to forget about these things, because, hey, it's all *digital*, and therefore *perfect*, right? Wrong. So, an SDR-based analog data communications system needs to be able to deal with this. There are a couple of ways of doing this: 1) lock your PLL Synthesizer to a high-quality reference clock, usually improving the PPM error by an order of magnitude or more On the USRP2/N2XX/E100 there are explicit inputs for an external 10MHz reference clock, and UHD makes it easy to enable this feature when you create the UHD source/sink. 2) Have your demodulator provide feedback to the frequency-setting code to tweak the actual LO frequency (or DDC frequency, which is usually faster). This is the most general approach, since it makes your code work well even on a platform that doesn't have a high-quality external reference. Note this is on the *receive* side. No sense in tweaking the transmitter when you have potentially-many receivers. The conventional thing to do is to have the receiver track wherever the transmitter is right now. This class of problem is in no way unique to SDR hardware. Ham radio operators on the list will tell you about many adventures (particularly in the old days) of tweaking the LO performance on their VHF receivers to allow "full quieting" reception of the local FM repeater, and as I observed, FM radios and televisions have had some kind of automatic-fine-tuning for many many decades. -- Marcus Leech 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] USRP2 UHD error: No control response
I just successfully (I think!) installed UHD and gnuradio, and have installed the firmware provided by Ettus for UHD installs newer than August 2010. I can successfully find my USRP2 using uhd_find_devices, but running uhd_usrp_probe or any python script using UHD drivers results in the error Error: no control response I found a couple other threads from the past dealing with similar issues but couldn't find anything in them that I could use to troubleshoot my situation. I did notice that after flashing both firmware and fpga binaries on the SD card that instead of just D and F LEDs being lit up, B is also lit. FWIW, I'm on Ubuntu 10.04. Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Parallel programming
Thanks. Yes, my block has internal data-feedback [using signal processing block output to calculate new FIR filter coefficients, a trait common in adaptive filters]. It runs with 1 FIR Filter pretty quickly with 1 core no problem, but once I start pushing it to 5 and up, my computer can't keep up. At around 2 or 3 the core working on it is really stressed. I did notice that when I run example flow graphs or when I create flow graphs that doesn't have any of my custom algorithms, it does really well dividing the tasks to separate cores. Could you point a reference to this topic please? I tried googling "internal data feedback" and "data-flow feedback" with words like parallel, c++, and I'm not getting good results. Thanks. On Mon, Jan 10, 2011 at 3:45 PM, Michael Dickens wrote: > Without seeing your GRC implementation or Python script & block's > implementation code, mostly what I or anyone else can provide is general > advice. GNU Radio 3.3.0 uses the thread per block (TBP) scheduler by > default; if you're not doing anything else except running the flow-graph > (meaning: you don't set special GNU Radio environment variables or use a GNU > Radio configuration file), then that's what you're using. The performance > of any flow-graph really depends on how complex the flow-graph is, how much > data you're trying to push through it, and how fast your processors are able > to perform the block's computations. The host OS influences execution speed > a little, but mostly its those listed factors that make the difference; that > said, I haven't used GNU Radio on Ubuntu in a long time so I cannot talk > about that OS specifically (Linux, in general, provides very low OS overhead > & more time executing the flow-graph's computations). It might be that your > flow-graph is running fast enough already to use just 1 core; does it run in > "real time" for what you need? Rewriting a given block to use vector-based > instructions (SSE, Altivec, Neon) often dramatically increases the > computations / time for that block. As for parallelizing your block, > without knowing what it is/does exactly, I would always advise you to break > down the computations into smaller pieces and then implement those as blocks > (if they are no already), then create the "meta-block" (I forget the exact > name of it now; maybe "heir_block2"?) using those. That way, the TBP > scheduler will have more to work with and the flow-graph will end up being > executed more in parallel. If your block has internal data-feedback, then > the meta-block will not work (GNU Radio doesn't "do" data-flow feedback in > the flow-graph) & you'll have to find some way of parallelizing your > algorithm. There are plenty of good books on this subject. - MLD > > On Jan 10, 2011, at 3:11 PM, sirjanselot wrote: > > I am currently using gnuradio 3.3.0 as my version. > > How do I know that my flow-graph is executing in thread per block mode? > > > > As far as I can tell my only 1 core out of the 8 is being used when I run > my > > flow-graphs. This is what I see when I run the performance monitor (or > > whatever it is called) in Ubuntu. > > > > So can I parallelize my block without having to create a meta-block as > you > > say? I have a lot of for-loops and vector calculations that need to be > > optimized (adaptive fir filters). > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM on USRP2
Hi all, Does anyone know of any updated OFDM benchmark code that is modified to be run on a USRP2? I have seen previous posts of this, however the link to the updated code is no longer available. Thanks, Michael Rahaim Graduate Research Assistant Smart Lighting Engineering Research Center Boston University mrah...@bu.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get started using UHD
Hi, I am trying to do the same thing and I realize exactly what his question is, since the results of the commands I am running do not seem to be leading me anywhere. Please read on :-) I have uhd already compiled and installed. Next I want to do the gr-uhd step so I try: git clone http://gnuradio.org/git/gnuradio.git then after that cd /gnuradio then git branch --track next origin/next git checkout next for which I get the following results: [gnura...@localhost gnuradio]$ git branch --track next origin/next Branch next set up to track remote branch next from origin. and [gnura...@localhost gnuradio]$ git checkout next Switched to branch 'next' And that is all. It kind of leaves me doubting whether I have done the correct thing or not because intuitively I am expecting to see a new directory that reads something like gr-uhd. What am I missing? Nick ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to get started using UHD
> [gnura...@localhost gnuradio]$ git branch --track next origin/next > Branch next set up to track remote branch next from origin. > > and > > [gnura...@localhost gnuradio]$ git checkout next > Switched to branch 'next' > > And that is all. It kind of leaves me doubting whether I have done the > correct thing or not because intuitively I am expecting to see a new > directory that reads something like gr-uhd. > You should see a directory named gr-uhd. Its odd that you dont? Can you post the output of the command: git describe -Jos ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 UHD error: No control response
On 01/10/2011 02:06 PM, Ben Ahrens wrote: > I just successfully (I think!) installed UHD and gnuradio, and have > installed the firmware provided by Ettus for UHD installs newer than > August 2010. I can successfully find my USRP2 using uhd_find_devices, > but running uhd_usrp_probe or any python script using UHD drivers > results in the error > > Error: no control response > Thats not good. The find_devices app does the bare minimum to discover devices, where the probe app does that and more. Seems like something further down the line might be at fault. Can you tell me the following: Git hash of your uhd install. Which images you loaded on the sd card. http://www.ettus.com/downloads/uhd_images/ -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Benchmark scripts
> 2) Have your demodulator provide feedback to the > frequency-setting code to tweak the actual LO frequency (or DDC > frequency, which is usually faster). This is the most general > approach, since it makes your code work well even on a platform that > doesn't have a high-quality external reference. Note this is on the > *receive* side. No sense in tweaking the transmitter when you have > potentially-many receivers. The conventional thing to do is to have > the receiver track wherever the transmitter is right now. Two ideas: * You might need to tweak your transmitter's frequency in order to keep it within your transmission boundaries (e.g. your license), or to meet specs for interoperability. For example, when using an unmodified USRP as a GSM cell tower with the OpenBTS code, the transmitter was too far off frequency spec for some cellphones to interoperate with it. * It seems to me we could minimize this problem by writing a small program that would tune an over-the-air frequency standard (like one of the WWV broadcasts) and compare it to the local oscillator. The resulting frequency offset could then be stored as a default setting for subsequent GNU Radio runs, so that e.g. if your program asked to tune to 250.000 MHz and the USRP's LO was slow by 50 kHz (0.050 MHz) then internally it would know to tune to 250.050 which is probably closer to where the real signal will be. Of course the LO would shift slightly based on temperature, but if you measured and stored the value after warm-up, it would probably be relatively stable. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Benchmark scripts
2) Have your demodulator provide feedback to the frequency-setting code to tweak the actual LO frequency (or DDC frequency, which is usually faster). This is the most general approach, since it makes your code work well even on a platform that doesn't have a high-quality external reference. Note this is on the *receive* side. No sense in tweaking the transmitter when you have potentially-many receivers. The conventional thing to do is to have the receiver track wherever the transmitter is right now. Two ideas: * You might need to tweak your transmitter's frequency in order to keep it within your transmission boundaries (e.g. your license), or to meet specs for interoperability. For example, when using an unmodified USRP as a GSM cell tower with the OpenBTS code, the transmitter was too far off frequency spec for some cellphones to interoperate with it. An excellent point, to be sure. The transmitter carrier frequency should be adjusted to be as close to spot-on as as practical, given test equipment accuracy, etc. [Some frequency counters have woefully-inadequate clock crystals on them, so using them for fine-scale tweaking is just asking for trouble]. But *dynamic* tweaking of the transmitter frequency often leads to trouble in a multi-receiver scenario. * It seems to me we could minimize this problem by writing a small program that would tune an over-the-air frequency standard (like one of the WWV broadcasts) and compare it to the local oscillator. The resulting frequency offset could then be stored as a default setting for subsequent GNU Radio runs, so that e.g. if your program asked to tune to 250.000 MHz and the USRP's LO was slow by 50 kHz (0.050 MHz) then internally it would know to tune to 250.050 which is probably closer to where the real signal will be. Of course the LO would shift slightly based on temperature, but if you measured and stored the value after warm-up, it would probably be relatively stable. John Probably reasonable as a first-order approach. That assumes that frequency errors are more-or-less linear. Further, you want to store the result as a PPM estimate, rather than an absolute frequency offset. For some cards, the difference won't matter, but for something like the WBX, with a very-wideband synthesizer, it does matter. FM radio stations also tend to use very-high-quality LOs for their transmitters, although the wideband nature of their signal makes it somewhat awkward to do fine tweaking. Hmmm, I wonder about the audio carrier of a TV signal, that might also be reasonably stable. Too bad the galaxy is in rotation, else you could use 1420.4058MHz and a small dish as a super-accurate frequency standard :-) [Actually, if you have precise notions of the rotation curve along your line of site, you can correct, but, I digress] -- Marcus Leech 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] Benchmark scripts
On 1/10/2011 6:58 PM, Marcus D. Leech wrote: * It seems to me we could minimize this problem by writing a small program that would tune an over-the-air frequency standard (like one of the WWV broadcasts) and compare it to the local oscillator. The resulting frequency offset could then be stored as a default setting for subsequent GNU Radio runs, so that e.g. if your program asked to tune to 250.000 MHz and the USRP's LO was slow by 50 kHz (0.050 MHz) then internally it would know to tune to 250.050 which is probably closer to where the real signal will be. Of course the LO would shift slightly based on temperature, but if you measured and stored the value after warm-up, it would probably be relatively stable. John Probably reasonable as a first-order approach. That assumes that frequency errors are more-or-less linear. Further, you want to store the result as a PPM estimate, rather than an absolute frequency offset. For some cards, the difference won't matter, but for something like the WBX, with a very-wideband synthesizer, it does matter. FM radio stations also tend to use very-high-quality LOs for their transmitters, although the wideband nature of their signal makes it somewhat awkward to do fine tweaking. Hmmm, I wonder about the audio carrier of a TV signal, that might also be reasonably stable. I haven't used it, but kalibrate [1] seems to do what we're all talking about, using GSM base station clocks (that are required to have an accuracy of 50 parts per billion). Maybe see what that code is all about? [1] http://thre.at/kalibrate -- Patrick Yeon ThinkRF 613-369-5104 x418 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
Hello All, I have something to show the project which was community developed and sold in 450$ even though when it was in prototyping phase and FPGA Atera Cylone used to be so costly that time coz it was not matured that time. USRP has been sold in $450 , how one can claim proprietorship on a product which was develop as open sourced hardware project. many of people have contributed to it on Mr. Ettus alone.. he ought to bring its price to nominal and reasonable at least for students when he is producing it in bulk. I alone Estimated its costing on DIGI key and other sites for parts and PCB sourcing and all it not exceeding $200 and he is www.ettus.com claiming $150 for handling n shipping alone. so outside US it would be around $1000. my apologies if i used harsh words. Below old mails from Mr. Ettus Kind regards, =Q=== http://ftp.sunet.se/geda/mailinglist/geda-user25/msg00049.html =UQ== To: geda-user-atMUNGEDseul_dot_org Subject: gEDA-user: The USRP is for sale From: Matt Ettus Date: Sun, 26 Dec 2004 21:04:00 -0800 Delivery-Date: Mon, 27 Dec 2004 00:04:06 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=eD0MWe9lQkMlgqu26zhotdr1wjiGK5o9tZMN+udJfTjnikboIyaQ8WLcf+H3OcXVe65HF6TQviymxppkyTwRTLp2wJKPvkVVas87pS76RAHXUfEJZxkboUsDqp+MmM8L2YnNHWqmLqsVP3GrrDR0bp7s3vRnB0CgryMs3zUUeCI= Reply-To: geda-user-atMUNGEDseul_dot_org Sender: owner-geda-user-atMUNGEDseul_dot_org The Universal Software Radio Peripheral (USRP) is a completely free design, which is now complete and going on sale. I used gEDA for all schematics, PCB for the daughterboard layouts, and Icarus for all my simulation of FPGA code. I know a lot of people on this list have asked about the USRP in the past, so here is the official announcement: === Ettus Research LLC is pleased to announce that the USRP in now available for purchase! Shipment will begin in the first half of January. For more detailed info on the USRP, check out: http://www.ettus.com http://comsec.com/wiki?UniversalSoftwareRadioPeripheral http://gnu.org/software/gnuradio/ The USRP motherboard is US$450, and includes a USB cable and power supply. The supply is a universal switching type which works on 90-260 VAC, 50/60 Hz, so it will work internationally with a US-type plug converter. The BasicRX and BasicTX daughterboards are also available, for US$50 each. These boards are perfect for operation with an external RF frontend, or for prototyping your own. Each board provides a pair of SMA connectors for IF signals (either two independent signals or one IQ signal), and headers for access to 16 general purpose digital IOs per board, as well as the I2C and SPI buses, and 4 low-speed DAC outputs and 2 low-speed ADC inputs. Each USRP can accommodate 2 Basic RX boards AND 2 BasicTX boards. A simple receive only system would require one BasicRX board. A basic transceiver would require one BasicRX and one BasicTX. A complete system (2 of each) is recommended if you plan to do any multi-antenna systems or custom development of code for the FPGA. Additional daughterboards will be available in the next few months. Ordering information can be found at http://www.ettus.com Payment is only by check or money order at this time. A secured website to accept credit card orders will be online at some point in the future. Orders will be shipped in the order received. Checks will not be cashed until your unit is ready to ship. California residents will need to add 8.25% to the price (not including shipping). To place an order, fill out the form below, email it to sa...@ettus.com, and then print it out, and mail it along with a check or Money Order to: Ettus Research LLC 604 Mariposa Avenue Mountain View, CA 94041 If you need a formal quote, need to get an exact shipping cost for non-US orders, are interested in purchasing more than 5 USRPs, or if you have any further questions, please send email to sa...@ettus.com Order Form Name: Ship to Address: ItemPer UnitQty Price USRPs $450 BasicRX $50 BasicTX $50 Sales Tax (California addresses only) +8.25% Shipping and handling ($25 in US) Total Follow-Ups: Re: gEDA-user: The USRP is for sale From: Karel Kulhavy Prev by Date: Re: gEDA-user: Kicad Next by Date: gEDA-user: Symbol Contribution Page? Prev by thread: RE: gEDA-user: gEDA/PCB desktop icons and remote access? Next by thread: Re: gEDA-user: The USRP is fo
Re: [Discuss-gnuradio] Compile Gnuradio 3.3.0
I get the following warning when running make, does it matter? Thanks. /usr/src/gnuradio-3.3.0/usrp/host/include/usrp/usrp_basic.h:91: warning: explicit link request to 'make' could not be resolved /usr/src/gnuradio-3.3.0/usrp/host/include/usrp/usrp_basic.h:91: warning: explicit link request to 'make' could not be resolved /usr/src/gnuradio-3.3.0/usrp/host/include/usrp/usrp_basic.h:91: warning: explicit link request to 'make' could not be resolved sh: latex: not found Problems running latex. Check your installation or look for typos in _formulas.tex and check _formulas.log! dvips: DVI file can't be opened: _formulas.dvi: No such file or directory Problems running dvips. Check your installation! /usr/src/gnuradio-3.3.0/usrp/host/include/usrp/usrp_basic.h:91: warning: explicit link request to 'make' could not be resolved make[4]: Leaving directory `/usr/src/gnuradio-3.3.0/docs/doxygen' make[3]: Leaving directory `/usr/src/gnuradio-3.3.0/docs/doxygen' make[3]: Entering directory `/usr/src/gnuradio-3.3.0/docs' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/usr/src/gnuradio-3.3.0/docs' make[2]: Leaving directory `/usr/src/gnuradio-3.3.0/docs' make[2]: Entering directory `/usr/src/gnuradio-3.3.0' make[2]: Leaving directory `/usr/src/gnuradio-3.3.0' make[1]: Leaving directory `/usr/src/gnuradio-3.3.0' r...@ubuntu:/usr/src/gnuradio-3.3.0$ On 11/01/2011 03:43, Ben Ahrens wrote: I assume you're looking here: http://gnuradio.org/redmine/wiki/gnuradio/UbuntuInstall. If so, you just need to run this: sudo apt-get -y install libfontconfig1-dev libxrender-dev libpulse-dev swig g++ automake libtool python-dev libfftw3-dev \ libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc sdcc-libraries \ libsdl1.2-dev python-wxgtk2.8 subversion git-core guile-1.8-dev \ libqt4-dev python-numpy ccache python-opengl libgsl0-dev \ python-cheetah python-lxml doxygen qt4-dev-tools \ libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools If you look carefully boost is in there. If you use the above script there shouldn't be any other dependencies you need to install. You shouldn't need to use those instructions to install libboost after that. Ben On Mon, Jan 10, 2011 at 12:50 PM, Howard Wong wrote: Can anyone advice on the following: I am compiling gnuradio 3.3.0 on Ubuntu 10.10 and following instruction on UbuntuInstall of gunradio.org And I've installed the Boost by apt-get, is it necessary to install Boost manually? - For Ubuntu 8.04 and older, download and install Boost 1.35 or later as follows Then, the instruction than teaches me to set the LD_LIBRARY_PATH, however, the ENV_VAR $BOOST_PREFIX is not set. export LD_LIBRARY_PATH=$BOOST_PREFIX/lib Where should I post $BOOST_PREFIX to? to /usr/lib as the .a lib files are there or to /usr/include/boost where the hpp files are there Moreover, it sets the $BOOST_PREFIX/lib and I can't find lib under the boost directories. And here are the result of config.log grep boost: configure:20389: checking for boost>= 1.35 configure:20955: checking whether the boost::thread includes are available Thanks for kindly help. ___ 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] Re: A Humble Request....for allowing to copy Circuit into PCB
Manoj Kumar, Devendra Purohit, Marten Christophe, and others at technosa...@gmail.com, A humble request for you to get some perspective: Running a business costs money: Parts, supplies, equipment, manufacturing, assembly, testing, employees, export compliance, future developments. Maybe the developers like to have a job and eat food? The price you want to pay does not cover the true cost of a USRP. Matt is not the enemy, and using the mailing list to publicly humiliate him into giving you a free USRP is not really an appropriate list topic. If you are angry at the "man" and the big cooperations stepping on the little guy; you are seriously barking up the wrong tree. You can find lots of other projects, or great ways to contribute without radio hardware. I created most of gnuradio-companion with my own laptop and without any radio hardware or test equipment. Maybe you can get a signal capture from someone and work on a demodulator; or come up with a new modulator that works in simulation (as others have suggested). When the time comes to test the software, perhaps you can borrow some hardware (maybe a USRP) from another university. Thank you, -Josh On 01/10/2011 07:24 PM, Marten Christophe wrote: > Hello All, > > I have something to show the project which was community developed and > sold in 450$ even though > when it was in prototyping phase and FPGA Atera Cylone used to be so > costly that time coz it was not > matured that time. USRP has been sold in $450 , how one can claim > proprietorship on a product which was develop as open sourced > hardware project. many of people have contributed to it on Mr. Ettus > alone.. he ought to bring its price to nominal and reasonable at least > for students when he is producing it in bulk. > > I alone Estimated its costing on DIGI key and other sites for parts > and PCB sourcing and all > it not exceeding $200 and he is www.ettus.com claiming $150 for > handling n shipping alone. > so outside US it would be around $1000. my apologies if i used harsh words. > > Below old mails from Mr. Ettus > > Kind regards, > =Q=== > http://ftp.sunet.se/geda/mailinglist/geda-user25/msg00049.html > =UQ== > > To: geda-user-atMUNGEDseul_dot_org > Subject: gEDA-user: The USRP is for sale > From: Matt Ettus > Date: Sun, 26 Dec 2004 21:04:00 -0800 > Delivery-Date: Mon, 27 Dec 2004 00:04:06 -0500 > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; > h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; > b=eD0MWe9lQkMlgqu26zhotdr1wjiGK5o9tZMN+udJfTjnikboIyaQ8WLcf+H3OcXVe65HF6TQviymxppkyTwRTLp2wJKPvkVVas87pS76RAHXUfEJZxkboUsDqp+MmM8L2YnNHWqmLqsVP3GrrDR0bp7s3vRnB0CgryMs3zUUeCI= > Reply-To: geda-user-atMUNGEDseul_dot_org > Sender: owner-geda-user-atMUNGEDseul_dot_org > > > > The Universal Software Radio Peripheral (USRP) is a completely free > design, which is now complete and going on sale. I used gEDA for all > schematics, PCB for the daughterboard layouts, and Icarus for all my > simulation of FPGA code. > > I know a lot of people on this list have asked about the USRP in the > past, so here is the official announcement: > > === > > > Ettus Research LLC is pleased to announce that the USRP in now > available for purchase! Shipment will begin in the first half of > January. For more detailed info on the USRP, check out: > > http://www.ettus.com > http://comsec.com/wiki?UniversalSoftwareRadioPeripheral > http://gnu.org/software/gnuradio/ > > The USRP motherboard is US$450, and includes a USB cable and power > supply. The supply is a universal switching type which works on > 90-260 VAC, 50/60 Hz, so it will work internationally with a US-type > plug converter. > > The BasicRX and BasicTX daughterboards are also available, for US$50 > each. These boards are perfect for operation with an external RF > frontend, or for prototyping your own. Each board provides a pair of > SMA connectors for IF signals (either two independent signals or one > IQ signal), and headers for access to 16 general purpose digital IOs > per board, as well as the I2C and SPI buses, and 4 low-speed DAC > outputs and 2 low-speed ADC inputs. > > Each USRP can accommodate 2 Basic RX boards AND 2 BasicTX boards. A > simple receive only system would require one BasicRX board. A basic > transceiver would require one BasicRX and one BasicTX. A complete > system (2 of each) is recommended if you plan to do any multi-antenna > systems or custom development of code for the FPGA. > > Additional daughterboards will be available in the next few months. > > Ordering information can be found at http://www.ettus.com > > > Payment is only by check or money order at this time. A secured > website to accept credit card orders will be
Re: [Discuss-gnuradio] Alternative Hardware [was: Re: A Humble Request.... - "Open-Hardware"]
On 10.01.2011 15:35, Martin Braun wrote: > If I may add a note here: I agree with Brian and Patrick, and would even > go further to say that developing fun stuff needs no hardware at all. > So, I hope this didn't sound too snobbish -- but I think that using GNU > Radio, essentially any budget is enough to get started doing serious SDR > stuff. Yes, it sounds totally snobbish. You let the tax-payer finance your Gnuradio hardware and tell other people they don't need hardware and should live with simulations. Hey, why do you think people are interested in Gnuradio? You know the words "Wasser predigen und Wein saufen?" ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to calculate the peak values of a signal spectrum by a grc project
usrp_fft.py is one the examples (or utilities) which is prepared in gnuradio source code. this example python utility is in this path: /gr-utils/src/python/usrp_fft.py this python example calculates the fft transform of the signal which is captured from the USRP (as source); and then, plots the spectrum (output of fft transform) via a GUI. one the options prepared on the GUI is "Peak Hold"; that can be selected by checking its checkbox. by checking the Peak Hold checkbox, a green diagram will be ploted on the GUI, that indicates the maximum values of the spectrum in every frequency. I made a project in grc that generates a python code like usrp_fft.py. but now i need to catch the Peak Hold Diagram values as a vector; to do sum calculations on these values. i tried to use some blocks prepared by grc, like "Operator -> FFT" or "Operator -> Log Power FFT", to calculate the fft spectrum of the USRP signal; but i dont know how to manipulate the output of these blocks and how to catch the Peak Values? your help will be appreciated thnx ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] wbx - usrp_benchmark_usb.py failed at testing 4MB/sec
I get the same problem with this one, using ubuntu 10.10, and a DBSRX, WBX the single DBSRX works but it fails with the WBX. So far, I have tried another two computers with ubuntu 9.10 fresh installation. but exactly the same problem. Is anyone having the same issue on WBX? Kyle Kyle Zhou wrote: In order to use WBX, I install git repo on my ubuntu 9.04. When I do usrp_benchmark_usb.py, it goes well with 2MB test, but failed at 4MB showing device busy error. The output is attached below. I tried other daughter boards (RF2400), no problem. So I guess it is related to the WBX. Testing 2MB/sec... usb_throughput = 2M ntotal= 100 nright= 999156 runlength = 999156 delta = 844 OK Testing 4MB/sec... usrp_open_interface:usb_claim_interface: failed interface 1 could not claim interface 1: Device or resource busy usrp_basic_tx: can't open tx interface Traceback (most recent call last): File "./usrp_benchmark_usb.py", line 106, in main () File "./usrp_benchmark_usb.py", line 96, in main ok = run_test (rate, verbose) File "./usrp_benchmark_usb.py", line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File "/usr/local/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py", line 2741, in sink_s return _usrp_swig.sink_s(*args, **kwargs) RuntimeError: can't open usrp ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: A Humble Request.... - "Open-Hardware"
On 10.01.2011 02:22, Marcus D. Leech wrote: > The SSRP, as far as I can tell, is dead. Last status update was nearly 4 > years ago. The development stopped apparently. But at least he has a working design for the RX part. > o The ADC board (single-channel, thus cannot handle direct-conversion with I > and Q sampling) $120.00 > o Uses an Off-The-Shelf ElraSoft FX2 board, which in 2007, sold for $89.00 Oh, forgot about the USB interface, so it's about $200. That would be my limit for a home-product. > > But it won't do complex sampling, and it won't do DDC and decimation, so your > host computer had better be prepared to receive > 25Msps and "do stuff with it". Depends what you want to do with it. For waterfall, spectrum-, logic- and signal analysis you don't need complex sampling, IF will do it. It's just a shift on the frequency axis. Ok, need double sample number, but real-to-complex FFT is faster. Not much difference. My interest is just to have some hobby box that can do more than my old analog oscilloscope. It's also for the kids to do some electronics education. They need a bit more than just a few blinking LED. >$1000 for USRP is a bit too expensive for an electronics toy. > That's $511.00, and we still don't have DDC or decimation, since we don't > have an FPGA, and that poor little FX2 isn't going to be But that's a different design. It can be cheaper. For the material cost, the USRP is about $200, somebody reported on the list. It doesn't have to be a SSRP, but I would like to buy or built something in the €200 range. > Ok, so maybe we can run the ADCs and DACs at a lower rate, so that we can do > the DDC and decimation in the FX2? I'd be > *astonished* if it could keep up with input rates beyond roughly about > 200Ksps complex, which is cheap sound-card territory. Oh dear. Not if a modern PC with appropriate programming (SSE extensions) would do the decimation. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] On Starving Students
Dear List, This is the GNU Radio mailing list, and its purpose is to discuss the use and development of GNU Radio. I try to refrain from talking about our business out of respect for the purpose of this list and the community. However, due to the tenor of the recent conversation, I feel that I must say a few things. GNU Radio can be and is used with _many_ different hardware devices, not just those of our company. Some of those are completely different from the USRP, some emulate the USRP, some are based on the USRP design to a greater or lesser degree, and some are complete clones of it. Some cost less, most cost more. To my knowledge none of them other than the SSRP actually give out schematics or other technical details, but that is the choice of those designers/companies. You have the freedom to use or not use any of these, or even to make your own. If you wish to make your own in a collaborative manner, I think the GNU Radio mailing list is the perfect place to find like minded people to work with, and I would encourage you to use it as such. There are a lot of intelligent people here with a lot of experience to draw upon. At Ettus Research we get daily requests from students (and people falsely claiming to be students) all over the world for free or nearly-free hardware. Most (but not all) of them are at least a bit more courteous than the outright demands we have been receiving for the last 2 months from the multiple people who go by the name "Marten Christophe". If we were to accede to all of these requests/demands we would be sending out more free USRPs than paid ones. Very early on, I fell for this trick. I sent nearly-free hardware to several so-called starving students. Most of those boards were sold on eBay at a profit. The rest, to my knowledge, were never even turned on and the "students" disappeared. I have always found a way to get hardware to those students who actually contribute to the GNU Radio or OpenBTS projects and demonstrate competency and a willingness to collaborate. I fully intend to continue to do so. I will not send out free hardware to someone who just shows up and demands it under a fake name. If you feel that our prices are too high, then I would encourage you to make your own hardware. If you think you are a starving student now, wait until you try to sell USRPs for $450. Matt Ettus President, Ettus Research LLC ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: A Humble Request....for allowing to copy Circuit into PCB
On 11.01.2011 04:24, Marten Christophe wrote: > matured that time. USRP has been sold in $450 , how one can claim > proprietorship on a product which was develop as open sourced > hardware project. many of people have contributed to it on Mr. Ettus The copyright is at Ettus. EDA-files are not distributed. So it's a commercial version, not a community version. At least for the hardware. Only the firmware is open-source (using also opensource components like ethernet implementation). > I alone Estimated its costing on DIGI key and other sites for parts > and PCB sourcing and all > it not exceeding $200 and he is www.ettus.com claiming $150 for > handling n shipping alone. > so outside US it would be around $1000. my apologies if i used harsh words. It's not much for the tax-payer or commercial clients. But it's a lot for a hobbyist. Why can't there be a open-source community version of a Gnuradio-Hardware, about $200 for the material, do-it-yourself assembling, some performance tradeoffs (no expensive MIMO connector, cheap FPGA variant) etc. ? This is a RX-only SDR with all relevant design files (Schematics, PCB, Gerber), BOM about $200 : http://sdrtrack.drupalcafe.com/?q=node/2 Maybe somebody wants to donate a design to the GNU community? It won't by a one-way street. I guess the community will continue to improve the design after an initial start. Also GNU itself didn't start from zero, but used lots of Unix developments to create a free alternative. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 connection problem
Hi Adrew, I used wireshark instead of tcpdump and see something on the screen but don't understand what they mean. As i read wireshark shows if we send and receive packet to/from any device.But i see that i can send and receive packets via eth0 by using ifconfig, meh...@mehmet-pc:~$ sudo ifconfig eth0 [sudo] password for mehmet: eth0 Link encap:Ethernet HWaddr 60:eb:69:29:bb:c8 inet6 addr: fe80::62eb:69ff:fe29:bbc8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10416 errors:0 dropped:0 overruns:0 frame:0 TX packets:2654 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2112887 (2.1 MB) TX bytes:324570 (324.5 KB) Interrupt:48 Base address:0x4000 Hi Eduardo, I use HP pavilion dv6 core i7, and i checked the ethernet card it supports the gigabit ethernet. Do you have any other ideas why this could be happen? Thanks a lot. Mehmet. 2011/1/10, Andrew Rich : > tcpdump ? > - Original Message - > From: mehmet kabasakal > To: discuss-gnuradio > Sent: Monday, January 10, 2011 6:56 PM > Subject: [Discuss-gnuradio] USRP2 connection problem > > > Hi everyone, > I am using USRP2 on ubuntu 10.10. When i try to run it with grc i got the > this message, > > Traceback (most recent call last): > File "/home/mehmet/top_block.py", line 46, in > tb = top_block() > File "/home/mehmet/top_block.py", line 29, in __init__ > self.usrp2_sink__0 = usrp2.sink_32fc() > File "/usr/lib/python2.6/dist-packages/gnuradio/usrp2.py", line 1137, in > sink_32fc > return _usrp2.sink_32fc(ifc, mac) > RuntimeError: No USRPs found on interface eth0 > > then i run ifconfig eth0 command then i got, > > meh...@mehmet-pc:~$ sudo ifconfig eth0 > [sudo] password for mehmet: > eth0 Link encap:Ethernet HWaddr 60:eb:69:29:bb:c8 > inet6 addr: fe80::62eb:69ff:fe29:bbc8/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:10416 errors:0 dropped:0 overruns:0 frame:0 > TX packets:2654 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:1000 > RX bytes:2112887 (2.1 MB) TX bytes:324570 (324.5 KB) > Interrupt:48 Base address:0x4000 > > finally i tried find_usrps but again no response, > > meh...@mehmet-pc:~$ sudo find_usrps > No USRP2 found. > > I have checked if i install sdcc compiler from synaptic package manager > and it seems it is installed. > I use the ethernet cable that comes with usrp2 in the package. then i > changed the ethernet cable. > I used the one that is for internet connection but it didn't work. > > The screenshot of the basic grc problem is attached. > > Thanks for your help. > > Mehmet > > > > > > > > > -- > > > ___ > 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
