[Top][All Lists]
[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