discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr.fft_vcc usage in make_fft_sink_X


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] gr.fft_vcc usage in make_fft_sink_X
Date: Wed, 16 Mar 2005 12:56:34 -0800
User-agent: Mutt/1.5.6i

On Wed, Mar 16, 2005 at 02:49:22PM -0500, cswiger wrote:
> Are there any illustrative examples of using ifft?

Nope.  It just computes the inverse.

> I just discovered the 2nd argument in gr.fft_vcc can set direction
> forward (True) or reverse, which is cool as I want ifft for some
> kind of simple OFDM.

> I guess what I don't understand is how gr.serial_to_parallel works. Do
> you use serial_to_parallal(type N) and suddenly end up with N data
> paths? gr.keep_one_in_n seems self explanatory.

serial_to_parallel and parallel_to_serial are format converters.

The gr.fft_vcc block requires a vector of complex numbers for its
input and produces a vector of complex numbers on its output.
serial_to_parallel takes a stream of items and turns them into a
stream of vectors.  parallel_to_serial is the inverse.


gr_serial_to_parallel::gr_serial_to_parallel (size_t item_size, size_t 
nitems_per_block)
  : gr_sync_decimator ("serial_to_parallel",
                       gr_make_io_signature (1, 1, item_size),
                       gr_make_io_signature (1, 1, item_size * 
nitems_per_block),
                       nitems_per_block)
{
}

serial_to_parallel take a single stream of items of the size item_size
and produces a single output of items of size items_size * nitems_per_block.
(In reality it just memcpy's its input to its output.)

> Also looking at James' gr_seperate_streams and gr_combine_streams re:
> fft processing.

I have also begun adding an optional vlen (vector length) option to
some of the blocks.  At this point gr.complex_to_mag, complex_to_arg,
complex_to_float, complex_to_real, complex_to_imag,
gr.single_pole_iir_filter and gr.nlog10 all accept vlen.  They are
thus able to work on either a stream of items or a stream of vectors
of items.  These new options are handy for processing the inputs or
output of vector blocks such as the fft.

I expect to have the New! Improved! fftsink that supports averaging
checked in later today.

For a sneak preview, here's how the graph looks:

        s2p = gr.serial_to_parallel(gr.sizeof_gr_complex, fft_size)
        one_in_n = gr.keep_one_in_n(gr.sizeof_gr_complex * fft_size,
                                     int(sample_rate/fft_size/fft_rate))
        fft = gr.fft_vcc(fft_size, True, True)
        c2mag = gr.complex_to_mag(fft_size)
        self.avg = gr.single_pole_iir_filter_ff(1.0, fft_size)
        log = gr.nlog10_ff(20, fft_size)
        sink = gr.file_descriptor_sink(gr.sizeof_float * fft_size, self.w_fd)

        fg.connect(s2p, one_in_n, fft, c2mag, self.avg, log, sink)
        gr.hier_block.__init__(self, fg, s2p, sink)


gr.single_pole_iir_filter_ff computes

   y[i] = (1-alpha) * y[i-1] + alpha * x[i]

By changing alpha from 1.0 (no averaging) to say 0.01, we low pass
filter (average) the output of each of the fft bins.


gr.nlog10_ff computes

    out[i] = n * log10(std::max(in[i], (float) 1e-18));

Eric




reply via email to

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