Re: [Discuss-gnuradio] Help : Is this right that the daughterboard passes data to the usrp board in the I and Q format.

[Marcus D. Leech]

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.