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.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
