Re: [Discuss-gnuradio] regarding fft-ifft processing
Brett L. Trotter wrote: 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? On that note, does anyone how much of the Cyclone we're currently using? This whole discussion may be moot for the time being... -Roshan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding fft-ifft processing
2007/3/7, Kuntal Majumdar [EMAIL PROTECTED]: Recently, Brian told me that the FFT-IFFT processing is handled by the host side. Can I know how this is done exactly? Is there any relevant documentation for this on the Wiki? Did you read this: http://www.gnu.org/software/gnuradio/doc/exploring-gnuradio.html? The document is a bit old, but still give a very good introduction to the basics of GNU Radio. 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 :) -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding fft-ifft processing
Trond Danielsen 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 Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] regarding fft-ifft processing
On Wed, Mar 07, 2007 at 06:17:04AM -0800, Kuntal Majumdar wrote: 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. It uses the GNU Radio fft block, which itself uses FFTW. http://gnuradio.org/doc/doxygen/classgr__fft__vcc.html Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: FPGA's are Software Defined (was Re: [Discuss-gnuradio] regarding fft-ifft processing)
Marcus Leech wrote: Robert McGwier wrote: The wideband engine, Mercury: http://hpsdr.org/wiki/index.php?title=MERCURY is almost ready to release and its accompanying transmitter Penelope will follow shortly. BOTH of these boards will have ANOTHER Cyclone II on them with almost 100% of their territory being devoted to signal processing. Interface will be done in Ozy. This is a pretty inexpensive big jump in processing capability. Look at the prices on these boards that are already available. This is very interesting to say the least. I do believe we will see GnuRadio support for these boards as HPSDR has borrowed heavily from GnuRadio on the USB 2.0 interface side. Bob The MERCURY board looked intriguing to me, but it's real-mode only, which makes interfacing to a DC quadrature receiver a bit awkward. For my application (radio astronomy) getting the most bandwidth up to the PC where I can fiddle with it is most useful. But I fully agree that an FPGA is as legitimate a CPU to host SDR software as a Pentium D :-) I can't understand why everyone wants to build the same board. We do this over and over and over again. We know the limitations of USB (distance, bandwidth) so why do we continue down the same path. The converters provide more resolution but 95% of the people here will probably not benefit from that. The Gigabit idea sounds like a plan to me. Ryan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
