Re: regarding fft-ifft processing

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 :slight_smile:

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 :slight_smile:


Discuss-gnuradio mailing list
[email protected]id
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Robert McGwier wrote:

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 :slight_smile:


Marcus L. Mail: Dept 1A12, M/S: 04352P16
Security Standards Advisor Phone: (ESN) 393-9145 +1 613 763 9145
Strategic Standards
Nortel Networks [email protected]

On Wed, Mar 07, 2007 at 06:17:04AM -0800, Kuntal M. 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

Can you reconfigure the FPGA by changing some software based description
in a development tool (Quartus) or do you need to break out a soldering
iron or SMT rework station?

The facts are: what is run in an FPGA is SOFTWARE DEFINED.

I despise this dichotomy to the n-th degree and aver it is wholly
artificial. If the goal (as it should be) is to MAXIMIZE the amount of
code running on the desktop or embedded controller with the code written
in C++ (with some hand coded assembler to help) then I will subscribe to
that. But to say we cannot rewrite programs for the FPGA because it is
a violation of principles is entirely too strong IMNSHO. I have
requested, on at least one occasion that I recall, a modification be
made to the USRP firmware allowing for different operation. I received
what I asked for (I have made poor use of it but that is for a different
forum). To me, this is the essence of software defined we should be
targeting. When Matt releases the USRP2 and more importantly, the
“ultimate engine” he is planning, this will progress even further.

As HPSDR accelerates into its releases, with FPGA’s and CPLD’s
everywhere and “untrained (very smart/extraordinary) mortals” doing ALL
of the programming and releasing their cores into the wild, this will
also help immensely.

HPSDR’s Atlas Bus is < $30 (!!) in a very easy to build kit form.

http://www.tapr.org/kits_atlas.html

HPSDR’s main controller (Ozy) is the hub of activity on the Atlas
backplane:

http://www.tapr.org/kits_ozy.html

and has a very credible Cyclone II on it.

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


AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL,
TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair
“Taking fun as simply fun and earnestness in earnest shows
how thoroughly thou none of the two discernest.” - Piet Hine

Marcus L. wrote:

signal processing. Interface will be done in Ozy. This is a pretty

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 :slight_smile:

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs