[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Help : Is this right that the daughterboard passe

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] Help : Is this right that the daughterboard passes data to the usrp board in the I and Q format.
Date: Mon, 25 Apr 2011 09:56:14 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

On 25/04/2011 9:33 AM, ton ph wrote:
Thanks marcus ,
i very much appreciate the info and has cleared many of my wrong concepts about usrp and gnuradio. As you have said , processing 100Mhz of bandwidth using gnuradio will be a bit Hard unless handcrafting the signal processing block by hand , what if I processes the 100Mhz bandwidth by a 200Mhz , 12 bit ADC and later on i choose only 10 channels out of my 100Mhz full band data , by a 32 channel DDC , in which i can access each channel data from software. Which might reduce my bandwidth entering the CPU to about for example: 350 * 10 = 3500 Khz . If i follow this trend, i could reduce much of the overhead to the CPU. But my doubt still exist, processing the 100Mhz bandwidth using gnuradio wil be possible or not ? ... Do we need high IF upto how much so as it can process 100Mhz ... ?

Certainly, if you pre-process your entire bandwidth in the FPGA on your front-end device, such that only a smaller bandwidth is
  required to be processed on the host computer, that will help a lot.

I don't think there's a clear answer to "can Gnu Radio do what I want", without knowing what you want to do with the data on the host computer. You might want to put together a few "test" flow-graphs and see how much CPU resources they consume, and use
  that as a model to guide you.

Gnu Radio isn't inherently limited to any particularly bandwidth--it doesn't really know anything about bandwidth. But as a *practical matter*, Gnu Radio executes *algorithms*--collections of mathematical operations on the data stream from a sample source. Those mathematical operations have some cost, in terms of how many millions of them you can execute in any given
  length of time on any given CPU configuration.

Since Gnu Radio uses floating-point, it's quasi-useful to know how many FLOPS (Floating-point operations/second) your particular CPU can perform. The Core i7 920, for example, is rated at roughly 70 GFLOPS (7 x 10**10 FLOPS), which means that it can execute roughly 70 billion floating-point multiply-add pairs per second (probably using SSE floating-point operations).

So, let's say we're processing 100Msps complex samples, that's effectively 200Msps (I and Q). Let's say we're processing those samples on the above-stated Core i7 920, and that we're using a perfectly-optimal algorithm, with perfectly-optimal compilers, etc, etc. That
  means that our overall processing algorithms can only perform:

    7.0e10-FLOPS  / 2e8-SAMPLES = 350 OPS/SAMPLE

You won't be able to perform more than 350 multiply-add equivalent operations *in the very best case*, before your CPU isn't able to "keep up". In reality, you'll run out of performance long before the theoretical limit has been reached.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]