[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: ton ph
Subject: Re: [Discuss-gnuradio] Help : Is this right that the daughterboard passes data to the usrp board in the I and Q format.
Date: Tue, 26 Apr 2011 19:23:40 +0530

Hi  marcus ,
 As spotted by khaleed i think that could be possible regarding ,let another external FPGA does all the heavy works , Now as i have spotted out before , If i just do not let the complete 100Mhz band to be processed in my CPU and just choose only some part of the band for exp: 350 * 10 = 3500 Khz , to let enter my cpu and process that much bandwidth only. Which will reduce much of the overhead calculations in the CPU. I think this could help out. Now, i would like to point out what i have in my mind,what  I am thinking is ,to let the 100Mhz bandwidth to be processed by my 12 bit 200MSPS ADC , and later my 32 bit DDC  choose only  350*10 = 3500 Khz bandwidth , and let the 3500 Khz bandwidth to be processed in my i5 processor ( thou i dont know how system performance can be calculated ) and by doing so i can make the system be able to do the calculations. Now here my doubt comes that, using the high speed ADC , DDC would not gnuradio breaks in some part like processing , data transfer etc.

 I apologize for any mistaken questions or my innocence with regard to gnuradio capability, any proper guides  will be highly appreciated. 
And can you Please suggest me , how much IF i should require to make the 100Mhz bandwidth to be able to process in my 200MSPS ADC,
Sorry for late reply.


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 ... ?

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.

# Life is the most precious phenomenon ever happen ...
# Lets pray and give emotional strength to the innocent brave victims of japan.

reply via email to

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