Well, thats good enough. But then, I havent still got the relevant
documentation on this anywhere on the trac. I mean, I want to know how
does the host side handle all the related (I)FFT stuff.
Please help me in this regard.
Maybe some USRP documentation on OFDM might suffice.
Thanks a lot.
Regards,
Kuntal
Trond D. wrote:
I read in an earlier thread that you want to do the (I)FFT processing
in the FPGA. This is not how it is intended to be used. GNU Radio is a
software radio framework, and the goal is to move as much of the
signal processing as possible onto the host computer. Moving the FFT
back to the FPGA would therefore be a step backward in the software
approach. This is just my personal opinion, so feel free to spank me
with a 10 foot monopole if your view is different
An interesting debate. FPGA is indeed hardware, but I’d argue that if
the (I)FFT can be done faster on the FPGA and can use the appropriate
window sizes, etc (eg on-the-fly reconfigurable) that it would still
technically meet the definition of ‘software’. If it frees up USB
bandwidth somehow or frees up host-CPU and lets the host have more
resources left to do its job and we’re not really doing a mode-specific
function that locks us into MIMO or GMSK or OFDM, etc that it would be
OK by me as a consumer.
That Cyclone FPGA was awfully full last I checked- I don’t know enough
about this type of thing to say it wouldn’t fit, but it seems at least
possible that the amount of real-estate required to do the FFT might be
more than the current generation USRP could handle?
IANAE (expert), but I thought the debate was interesting enough to risk
embarassment 
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
