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. Thanks. On Mon, Apr 25, 2011 at 7:26 PM, Marcus D. Leech <mle...@ripnet.com> 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. > > > > -- Phenomenon # Life is the most precious phenomenon ever happen ... # Lets pray and give emotional strength to the innocent brave victims of japan.
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
