On Mon, Apr 25, 2011 at 7:26 PM, Marcus D. Leech
<address@hidden> wrote:
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 ... ?
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.