Re: [Discuss-gnuradio] some problems about usrp motherboard that i make by myself
thank you for your reply, Eric. we tested the motherboard, source code can be loaded into FX2, and usrper can be used to configure something. that means FX2 works well. we use usrp_benchmark_usb to test the board, it doen't work. something wrong with FPGA. but the clock of FPGA and ADCs are all OK, and FX2 to FPGA connections are also ok. it seems rbf cann't load to FPGA, why? can you give me some guide? thank you again. Eric Blossom wrote: > > On Sun, Jul 25, 2010 at 07:50:10PM -0700, tonygc wrote: >> >> thank you for your reply, Eric! our team plans to integrate USRP with >> other >> functions, so we first want to copy the USRP motherboard to convince our >> PCB >> design. PCB has been tested, all is ok. after finishing the soldering, >> first >> load the firmware of FX2(with build_eeprom.py), then LEDs blinks. the >> daughterboard can be detected by Probe. but can't receive any signals, >> neither transmitting... is there something we omit? in addition, how to >> test >> whether FPGA image is loaded into FPGA? > > There could be any number of things that you have omitted... > > Either you, or somebody on your team will have to really understand > what is going on, how code is loaded into the FX2, how the fpga image > is loaded, etc, or you will have no hope of debugging this. > > Once you have an understanding of what you expect to happen, then you > can look to see if it's happening. If it is, good, go on to the next > thing. If it isn't, then figure out why what you expect to be > happening isn't happening. > > > Suggested reading: > > USB 2.0 Specification > FX2 Technical Reference Manual > The USRP schematics > The source code for the FX2: usrp/firmware/* > The source code for usrp/host/apps/usrper.cc > The source code in usrp/host/* > Datasheets for all parts on the board > The FPGA source code > > Eric > > > >> Eric Blossom wrote: >> > >> > On Wed, Jul 21, 2010 at 08:48:46PM -0700, tonygc wrote: >> >> >> >> who can tell me the reason? any help will be appreciated... >> > >> > Bringing up new hardware (even if you think it's a perfect copy of >> > somebody else's design) is always a challenge. It requires a wide >> > range of skills, patience, test equipment and the ability to figure >> > out how to debug a problem. >> > >> > Most people I know learned these skills by working side-by-side at a >> > bench with people who had more experience than they did, both looking >> > at the same board... >> > >> > A couple of things to check: >> > >> > Are the power supplies as expected? >> > Do the clocks look good? >> > Can you load code into the FX2? >> > Can you load an FPGA image into the FPGA? >> > ... >> > >> > Good luck! >> > Eric >> > >> > >> > >> >> tonygc wrote: >> >> > >> >> > although there's no PCB of USRP motherboard, i make the PCB by >> myself. >> >> > there's no change of the motherboard, according to the schs. after >> >> > finishing the PCB and all components soldering, i burn the eeprom of >> >> the >> >> > motherboard by /gnuradio/usrp/firmware/src/usrp2/burn-usrp4-eeprom. >> >> > finally, its leds blinks. that's a small success for me. when i plug >> in >> >> > the rfx400 and run benchmark_tx.py, there's a sign that it's working >> >> > because it displays it's transmitting signals with >> >> > .. unfortunately, the receiver receives >> >> nothing... >> >> > then i use the probe to detect whether USRP works, and the probe >> >> displays >> >> > that it can detect the USRP and the daughterboard. it's the same as >> the >> >> > board bought from Ettus. i'm confused. the daughterboard is also ok >> on >> >> > the USRP motherboard bought from Ettus. >> >> > anyone can help me? i don't know how to deal with this problem... >> thank >> >> > you for your help! > > > ___ > 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/some-problems-about-usrp-motherboard-that-i-make-by-myself-tp29225435p29303365.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] How can i make usrp_rx-cfile.py to store the data in queue datastructure and another python file reading it,.
On Thu, Jul 29, 2010 at 06:41:02PM +0530, Anil Sharma wrote: > Hi everyone, > I have a query , hope someone help me in this.I want usrp_rx_cfile to > capture > data and store the captured date in some queue datastructure and > simultaneously > another python file reads the queue in realtime .Will it be possible and if so > how can i do so without any crashing of my another python file .Hoping for a > guidance from someone. I don't know if this'll work without any modifications to usrp_rx_cfile.py, but of course you can simply use a named pipe as file. Your other process could read this file in the same manner. Note that you must kind of sync the process initialisations, since named pipes won't return from an 'open()' call until the other end was opened, too. 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-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp455LrV23EJ.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Report configure - Packages skipped
On Thu, Jul 29, 2010 at 02:41:31PM -0400, Jeffrey Lambert wrote: > In particular, make sure you have the small device compiler > installed (SDCC). Not sure about gr-utils. I think that simply depends on gr-usrp due to the usrp_*.py scripts. It should work once usrp is up and running, it doesn't have much stuff of it's own. 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-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpeXKkVI0QDU.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] set_auto_tr() and set_enable()
Hi , I am confued by set_auto_tr() and set_enable(). In my opinion set_auto_tr(True) means that if there is something to transmit( something sent to the FPGA), the Rx path will be disabled, but if there is nothing sent to the FPGA, then the Rx path will be always enabled. On the other hand, if set_enable(True) is set, no matter whether there is something or not sent to FPGA, the TX path will always be enabled, and Rx path will always be disabled. But could set_auto_tr() and set_enable() be both set to True? if the answer is YES, what will happen? Am i correct? Any correction will be appreciated! sincerely, shanki ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] rfx900.pcb
Hi，all. I tried to get rfx900.pcb on the WIKI but failed. Could anyone who have this pcb file give me a copy? Thanks! lyrens ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] anyone had luck with high throughput IPC to GNU Radio?
Hi all, Has anyone had any luck achieving high throughput (e.g., supporting interpolation of 8 or 16 with USRP2) from Octave to a GNU Radio flowgraph? I am trying to stream a signal to my GR flowgraph, and at first I tried sockets but then realized it was way too slow, and so I moved to pipes but I am also finding it cannot keep up. I have tried writing/reading in larger blocks, such as using an fwrite() in Octave of size 20480, and then attempting a larger read within GNU Radio using a gr.file_source(20480,'/tmp/mypipe') and then converting it to a stream for the USRP2 with gr.vector_to_stream(gr.sizeof_gr_complex,20480). But alas, still no luck... I am under-running like crazy from the looks of my spectrum. Has anyone had any better luck? Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] anyone had luck with high throughput IPC to GNU Radio?
Hi, I am unfamiliar with Octave, so I cannot be sure about your particular scenario, but a potential problem could be internal buffering between writes... Maybe try flushing the stream more? Kunal On Fri, Jul 30, 2010 at 11:09 AM, George Nychis wrote: > Hi all, > > Has anyone had any luck achieving high throughput (e.g., supporting > interpolation of 8 or 16 with USRP2) from Octave to a GNU Radio flowgraph? > I am trying to stream a signal to my GR flowgraph, and at first I tried > sockets but then realized it was way too slow, and so I moved to pipes but I > am also finding it cannot keep up. > > I have tried writing/reading in larger blocks, such as using an fwrite() in > Octave of size 20480, and then attempting a larger read within GNU Radio > using a gr.file_source(20480,'/tmp/mypipe') and then converting it to a > stream for the USRP2 with gr.vector_to_stream(gr.sizeof_gr_complex,20480). > But alas, still no luck... I am under-running like crazy from the looks of > my spectrum. > > Has anyone had any better luck? > > Thanks! > George > > ___ > 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] WBX and auto TR switching?
I'm assuming the WBX has auto TR switching? Is there any code needed to enable auto TR switching from C++ after initializing the USRP2 with the standard usrp2::usrp2::make(interface, mac_addr_str); and then setting center frequency, decimation, interpolation, and gains? Thanks for the help. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio land speed record?
I'm curious what people do with the wideband capability of the gnuradio/usrp and what is the widest bandwidth signal one can really process with available computers? For reference I have a ~2.4 GHz core 2 duo laptop. For a 200 kHz FM demodulator I consume about 40% of one cpu. That's pretty much the simplest useful thing anyone can do so that maps to my laptop might be able to process 1 MHz bandwidth continuously. Similarly, my hard drive can't really keep up with 32 Mbyte/s recording. So if samples are 16-bit and you really can't afford lost data it seems like recording is limited to maybe 10 MHz or so bandwidth. However, with gigabit Ethernet you can send 100 Mbyte/s or more. What's the most anyone has recorded or processed continuously? What level of compexity was the processing? Thanks, Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio land speed record?
On 07/30/2010 09:33 AM, Clark Pope wrote: I'm curious what people do with the wideband capability of the gnuradio/usrp and what is the widest bandwidth signal one can really process with available computers? For reference I have a ~2.4 GHz core 2 duo laptop. For a 200 kHz FM demodulator I consume about 40% of one cpu. That's pretty much the simplest useful thing anyone can do so that maps to my laptop might be able to process 1 MHz bandwidth continuously. Similarly, my hard drive can't really keep up with 32 Mbyte/s recording. So if samples are 16-bit and you really can't afford lost data it seems like recording is limited to maybe 10 MHz or so bandwidth. However, with gigabit Ethernet you can send 100 Mbyte/s or more. What's the most anyone has recorded or processed continuously? What level of compexity was the processing? With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s recording to disk. With 4 and 6 core systems and the i7 architecture you can get more than 5X the performance of your laptop. There are a lot of applications using the full 25 MHz of RF bandwidth. You just need to pay a lot of attention to efficiency of your program and algorithms. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio land speed record?
On 07/30/2010 01:19 PM, Daniel Halperin wrote: On 07/30/2010 09:33 AM, Clark Pope wrote: I'm curious what people do with the wideband capability of the gnuradio/usrp and what is the widest bandwidth signal one can really process with available computers? What's the most anyone has recorded or processed continuously? What level of compexity was the processing? With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s recording to disk. With 4 and 6 core systems and the i7 architecture you can get more than 5X the performance of your laptop. There are a lot of applications using the full 25 MHz of RF bandwidth. You just need to pay a lot of attention to efficiency of your program and algorithms. For 'speed record' type information, you might be interested in SORA, a software radio project from Microsoft Research. They use different hardware and custom software, but the fundamentals are the same. As Matt points out, efficiency is a function of engineering. Using modern processors, 64-bit architecture, multicore, software LUTs, and a variety of other optimizations they were able to fully process 802.11g signals of 20 MHz bandwidth and sustain reception of 54 Mbps signals including Viterbi decoding, etc. I see no reason this couldn't be done with USRP(2) / GNU Radio... but looking at Microsoft's author list they had a lot of developers working pretty hard on it! There's not a ton of detail in the original paper, and what code is available is almost certainly not something you want to look at without reading the license very carefully, but here's the link to the project website: I don't think you need to read the license carefully to realize you do not want to download the code. 1) No commercial use clause. 2) You cannot distribute derived works. 3) You grant MS the right to use your modifications to the code. Even if you are in an academic situation, you need to think about your future in the commercial space before looking at the code. Philip http://research.microsoft.com/en-us/projects/sora/ and the original paper: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 Dan ___ 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] Wireshark issue
Hi, I am relatively new to GNU Radio. I set up a simple experiment of connecting a file source directly to the usrp sink and monitoring the traffic on the ethernet port using wireshark. The source file simply contains the letters abc. When I ran the flowgraph in GRC it did seem to initiate traffic on the ethernet interface to the USRP but I could not find the string abc in any ethernet frame. I thought that since there is no modulation or any other manipulation of the source data in the flowgraph before the usrp that I would be able to find this data string in the ethernet frame. Is there anything the USRP sink block could be doing on the host side that would alter the data before it gets sent out over ethernet interface to the USRP? Thanks, Dave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio land speed record?
On 07/30/2010 09:33 AM, Clark Pope wrote: I'm curious what people do with the wideband capability of the gnuradio/usrp and what is the widest bandwidth signal one can really process with available computers? What's the most anyone has recorded or processed continuously? What level of compexity was the processing? With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s recording to disk. With 4 and 6 core systems and the i7 architecture you can get more than 5X the performance of your laptop. There are a lot of applications using the full 25 MHz of RF bandwidth. You just need to pay a lot of attention to efficiency of your program and algorithms. For 'speed record' type information, you might be interested in SORA, a software radio project from Microsoft Research. They use different hardware and custom software, but the fundamentals are the same. As Matt points out, efficiency is a function of engineering. Using modern processors, 64-bit architecture, multicore, software LUTs, and a variety of other optimizations they were able to fully process 802.11g signals of 20 MHz bandwidth and sustain reception of 54 Mbps signals including Viterbi decoding, etc. I see no reason this couldn't be done with USRP(2) / GNU Radio... but looking at Microsoft's author list they had a lot of developers working pretty hard on it! There's not a ton of detail in the original paper, and what code is available is almost certainly not something you want to look at without reading the license very carefully, but here's the link to the project website: http://research.microsoft.com/en-us/projects/sora/ and the original paper: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio land speed record?
On 07/30/2010 01:01 PM, Matt Ettus wrote: > > With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 > MB/s recording to disk. With 4 and 6 core systems and the i7 > architecture you can get more than 5X the performance of your laptop. > > There are a lot of applications using the full 25 MHz of RF bandwidth. > You just need to pay a lot of attention to efficiency of your program > and algorithms. > > Matt > > For reference, an early version of my IRA radio astronomy receiver was able to do single-channel at 16MHz bandwidth, using a Core 2 Extreme 9770 and 8GB of memory and a USRP1. The IRA code does a number of things o compute total power over the entire bandwidth o compute an FFT with 1Hz resolution (that's a 16 million point FFT) o do a SETI analysis of the resulting FFT o do a transient signal analysis of the total power data o run a narrowband interference filter based on an FFT filter o run a GUI with lots of bells 'n whistles -- 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] ADC calibration
Hi, I'm calibrating my USRP setup using a function generator. I remember seeing that someone else had done this before in the past and written down a bunch of (input voltage, ADC output) pairs on the web somewhere, but I'm unable to find it on the wiki even with google site: search. Does anyone have a pointer? Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wireshark issue
On 07/30/2010 10:41 AM, David Barton wrote: Hi, I am relatively new to GNU Radio. I set up a simple experiment of connecting a file source directly to the usrp sink and monitoring the traffic on the ethernet port using wireshark. The source file simply contains the letters abc. When I ran the flowgraph in GRC it did seem to initiate traffic on the ethernet interface to the USRP but I could not find the string abc in any ethernet frame. I thought that since there is no modulation or any other manipulation of the source data in the flowgraph before the usrp that I would be able to find this data string in the ethernet frame. Is there anything the USRP sink block could be doing on the host side that would alter the data before it gets sent out over ethernet interface to the USRP? Thanks, Dave There may be data format conversion happening. What data types are you using? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
> Date: Fri, 30 Jul 2010 10:01:41 -0700 > From: m...@ettus.com > To: cepop...@hotmail.com > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] gnuradio land speed record? > > On 07/30/2010 09:33 AM, Clark Pope wrote: > > > > I'm curious what people do with the wideband capability of the > > gnuradio/usrp and what is the widest bandwidth signal one can really > > process with available computers? > > > > For reference I have a ~2.4 GHz core 2 duo laptop. For a 200 kHz FM > > demodulator I consume about 40% of one cpu. That's pretty much the > > simplest useful thing anyone can do so that maps to my laptop might > > be able to process 1 MHz bandwidth continuously. > > > > Similarly, my hard drive can't really keep up with 32 Mbyte/s > > recording. So if samples are 16-bit and you really can't afford lost > > data it seems like recording is limited to maybe 10 MHz or so > > bandwidth. > > > > However, with gigabit Ethernet you can send 100 Mbyte/s or more. > > What's the most anyone has recorded or processed continuously? What > > level of compexity was the processing? > > > With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s > recording to disk. With 4 and 6 core systems and the i7 architecture > you can get more than 5X the performance of your laptop. > > There are a lot of applications using the full 25 MHz of RF bandwidth. > You just need to pay a lot of attention to efficiency of your program > and algorithms. > > Matt Good point, if you remove the CPU bottleneck and go straight to storage you can do 100 MByte/s. Now is gigE the best for that or would SATA be better? Seems like once you buy the networking and storage equipment you've blown your budget relative to the usrp price. Yeah, I'd be interested in what those 25 MHz apps are. Maybe we need a contest for widest bandwidth, practical, most useful application on gnuradio. One ground rule though would be that the cost of the processing device has to be less than the USRP2, for example. Thanks, Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
> Date: Fri, 30 Jul 2010 10:19:35 -0700 > From: dhalp...@cs.washington.edu > To: m...@ettus.com > CC: cepop...@hotmail.com; discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] gnuradio land speed record? > > > On 07/30/2010 09:33 AM, Clark Pope wrote: > >> > >> I'm curious what people do with the wideband capability of the > >> gnuradio/usrp and what is the widest bandwidth signal one can really > >> process with available computers? > >> > >> What's the most anyone has recorded or processed continuously? What > >> level of compexity was the processing? > > > > > > With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s > > recording to disk. With 4 and 6 core systems and the i7 architecture you can > > get more than 5X the performance of your laptop. > > > > There are a lot of applications using the full 25 MHz of RF bandwidth. You > > just need to pay a lot of attention to efficiency of your program and > > algorithms. > > > > For 'speed record' type information, you might be interested in SORA, a > software radio project from Microsoft Research. They use different > hardware and custom software, but the fundamentals are the same. > > As Matt points out, efficiency is a function of engineering. Using modern > processors, 64-bit architecture, multicore, software LUTs, and a variety > of other optimizations they were able to fully process 802.11g signals of > 20 MHz bandwidth and sustain reception of 54 Mbps signals including > Viterbi decoding, etc. I see no reason this couldn't be done with > USRP(2) / GNU Radio... but looking at Microsoft's author list they had a > lot of developers working pretty hard on it! > > There's not a ton of detail in the original paper, and what code is > available is almost certainly not something you want to look at without > reading the license very carefully, but here's the link to the project > website: > > http://research.microsoft.com/en-us/projects/sora/ > > and the original paper: > > http://research.microsoft.com/apps/pubs/default.aspx?id=79927 > > Dan > Thanks that's a good data point! So a huge corporation with infinite resources tops out at about 20 MHz sustained processing of what I would call a real world practical signal. -Clark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
> Date: Fri, 30 Jul 2010 13:55:10 -0400 > From: mle...@ripnet.com > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] gnuradio land speed record? > > On 07/30/2010 01:01 PM, Matt Ettus wrote: > > > > With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 > > MB/s recording to disk. With 4 and 6 core systems and the i7 > > architecture you can get more than 5X the performance of your laptop. > > > > There are a lot of applications using the full 25 MHz of RF bandwidth. > > You just need to pay a lot of attention to efficiency of your program > > and algorithms. > > > > Matt > > > > > For reference, an early version of my IRA radio astronomy receiver was > able to do single-channel > at 16MHz bandwidth, using a Core 2 Extreme 9770 and 8GB of memory and > a USRP1. > > The IRA code does a number of things > > o compute total power over the entire bandwidth > o compute an FFT with 1Hz resolution (that's a 16 million point FFT) > o do a SETI analysis of the resulting FFT > o do a transient signal analysis of the total power data > o run a narrowband interference filter based on an FFT filter > o run a GUI with lots of bells 'n whistles > > > > > -- > 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 Now was the FFT continuous, i.e. you got one output bin for every input sample or you did snapshots? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
On Fri, 30 Jul 2010, Clark Pope wrote: and the original paper: http://research.microsoft.com/apps/pubs/default.aspx?id=79927 Dan Thanks that's a good data point! So a huge corporation with infinite resources tops out at about 20 MHz sustained processing of what I would call a real world practical signal. -Clark I think that should be thought of as a lower bound not an upper bound :). They accomplished their goal of handling dot11g and haven't (that I'm aware of) moved on to anything harder (yet). Aside: reading the paper doesn't come with any licensing terms, and there's even ASM code in the appendix for a SIMD-enabled FIR filter at the end. Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
> > > > >> Date: Fri, 30 Jul 2010 10:19:35 -0700 >> From: dhalp...@cs.washington.edu >> To: m...@ettus.com >> CC: cepop...@hotmail.com; discuss-gnuradio@gnu.org >> Subject: Re: [Discuss-gnuradio] gnuradio land speed record? >> >> > On 07/30/2010 09:33 AM, Clark Pope wrote: >> >> >> >> I'm curious what people do with the wideband capability of the >> >> gnuradio/usrp and what is the widest bandwidth signal one can really >> >> process with available computers? >> >> >> >> What's the most anyone has recorded or processed continuously? What >> >> level of compexity was the processing? >> > >> > >> > With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s >> > recording to disk. With 4 and 6 core systems and the i7 architecture you >> > can >> > get more than 5X the performance of your laptop. >> > >> > There are a lot of applications using the full 25 MHz of RF bandwidth. You >> > just need to pay a lot of attention to efficiency of your program and >> > algorithms. >> > >> >> For 'speed record' type information, you might be interested in SORA, a >> software radio project from Microsoft Research. They use different >> hardware and custom software, but the fundamentals are the same. >> >> As Matt points out, efficiency is a function of engineering. Using modern >> processors, 64-bit architecture, multicore, software LUTs, and a variety >> of other optimizations they were able to fully process 802.11g signals of >> 20 MHz bandwidth and sustain reception of 54 Mbps signals including >> Viterbi decoding, etc. I see no reason this couldn't be done with >> USRP(2) / GNU Radio... but looking at Microsoft's author list they had a >> lot of developers working pretty hard on it! >> >> There's not a ton of detail in the original paper, and what code is >> available is almost certainly not something you want to look at without >> reading the license very carefully, but here's the link to the project >> website: >> >> http://research.microsoft.com/en-us/projects/sora/ >> >> and the original paper: >> >> http://research.microsoft.com/apps/pubs/default.aspx?id=79927 >> >> Dan >> > > Thanks that's a good data point! So a huge corporation with > infinite resources tops out at about 20 MHz sustained > processing of what I would call a real world practical signal. Their infinite resources are in fact limited by their management's mindset and inability to think clearly about the consequences of their business model, the impact of the Internet, etc. A guy like Ballmer is just a much a reason why Linux exists as is Linus himself. His rhetoric about GPL being a cancer, Linux developers are communists, etc. has provided "infinite inspiration" to the guys with limited resources. SORA may be a useful data point, but advise to carefully consider the source. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_radar_mono.py
I guess this is a long shot, but does anyone know of any resources or documentation on this script? I am working on a custom radar application for a novel temperature sensor using the usrp and gnu radio libraries, and it seems that usrp_radar_mono.py could be of help in getting started. Thanks, ~Jeff -- ~Jeffrey Lambert, K1VZX ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] gnuradio land speed record?
> Date: Fri, 30 Jul 2010 15:22:21 -0500 > Subject: RE: [Discuss-gnuradio] gnuradio land speed record? > From: jbro...@signalogic.com > To: cepop...@hotmail.com > CC: discuss-gnuradio@gnu.org > > > > > > > > > > >> Date: Fri, 30 Jul 2010 10:19:35 -0700 > >> From: dhalp...@cs.washington.edu > >> To: m...@ettus.com > >> CC: cepop...@hotmail.com; discuss-gnuradio@gnu.org > >> Subject: Re: [Discuss-gnuradio] gnuradio land speed record? > >> > >> > On 07/30/2010 09:33 AM, Clark Pope wrote: > >> >> > >> >> I'm curious what people do with the wideband capability of the > >> >> gnuradio/usrp and what is the widest bandwidth signal one can really > >> >> process with available computers? > >> >> > >> >> What's the most anyone has recorded or processed continuously? What > >> >> level of compexity was the processing? > >> > > >> > > >> > With RAID arrays or SSDs, it isn't that hard anymore to sustain 100 MB/s > >> > recording to disk. With 4 and 6 core systems and the i7 architecture you > >> > can > >> > get more than 5X the performance of your laptop. > >> > > >> > There are a lot of applications using the full 25 MHz of RF bandwidth. > >> > You > >> > just need to pay a lot of attention to efficiency of your program and > >> > algorithms. > >> > > >> > >> For 'speed record' type information, you might be interested in SORA, a > >> software radio project from Microsoft Research. They use different > >> hardware and custom software, but the fundamentals are the same. > >> > >> As Matt points out, efficiency is a function of engineering. Using modern > >> processors, 64-bit architecture, multicore, software LUTs, and a variety > >> of other optimizations they were able to fully process 802.11g signals of > >> 20 MHz bandwidth and sustain reception of 54 Mbps signals including > >> Viterbi decoding, etc. I see no reason this couldn't be done with > >> USRP(2) / GNU Radio... but looking at Microsoft's author list they had a > >> lot of developers working pretty hard on it! > >> > >> There's not a ton of detail in the original paper, and what code is > >> available is almost certainly not something you want to look at without > >> reading the license very carefully, but here's the link to the project > >> website: > >> > >> http://research.microsoft.com/en-us/projects/sora/ > >> > >> and the original paper: > >> > >> http://research.microsoft.com/apps/pubs/default.aspx?id=79927 > >> > >> Dan > >> > > > > Thanks that's a good data point! So a huge corporation with > > infinite resources tops out at about 20 MHz sustained > > processing of what I would call a real world practical signal. > > Their infinite resources are in fact limited by their management's mindset > and inability to think clearly about the > consequences of their business model, the impact of the Internet, etc. A guy > like Ballmer is just a much a reason why > Linux exists as is Linus himself. His rhetoric about GPL being a cancer, > Linux developers are communists, etc. has > provided "infinite inspiration" to the guys with limited resources. > > SORA may be a useful data point, but advise to carefully consider the source. > > -Jeff > This is true. And I seem to recall Gates saying basically that the reason windows is coded so inefficiently is because the hardware will always increase faster than Microsofts bad coding. I have an internet explorer process running right now that's use 80 megabytes of memory! Years ago we ran an entire graphical interface and gui in 64 kByte on the commodore 64. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] anyone had luck with high throughput IPC to GNU Radio?
On Fri, Jul 30, 2010 at 8:38 AM, Kunal Kandekar wrote: > Hi, > > I am unfamiliar with Octave, so I cannot be sure about your particular > scenario, but a potential problem could be internal buffering between > writes... Maybe try flushing the stream more? > > I could be wrong, but I thought named pipes stay in memory? It seems like part of my problem might be that pipe size is limited to something like 4k in size, which does not allow me to push a lot of data through. It seems like I could modify this in linux/limits.h to increase its size. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
