Re: [Discuss-gnuradio] serial_to_parallel and fft_v{f,c}c

[Eric Blossom]

On Thu, Mar 16, 2006 at 09:45:05PM +0100, Patrick Strasser wrote:
> Hello!
> 
> I'm playing arround, trying to do FFT.
> Connecting some float source to fft_vfc did not work as flow_graph 
> complains about "raise ValueError, 'source and destination data sizes 
> are different'", which means that input data is not matching the input 
> signature.
> 
> (BTW: With the Debian package when using fft_vfc with False as second 
> argument for inverse FFT I get
> 
> fft_vfc: forward must == true
> terminate called after throwing an instance of 'std::invalid_argument'
>   what():  fft_vfc: forward must == true
> 
> With the current CVS-code I get
> 
>     return _gnuradio_swig_python.fft_vfc(*args)
> TypeError: in method 'fft_vfc', argument 3 of type 
> 'std::vector<float,std::allocator<float > > const'
> 
> I liked the old behaviour much more)

The calling sequence changed to allow the user to specify the window
to use.  The debian package has the old stuff.

> Back to topic:
> From Chuck's FFT-example I could see i need some serial/parallel 
> conversion. But I'm completely lost why this is needed as I don't 
> understand all the magic behind the blocks and the different kinds of 
> data that are pushed arround. So I'd be glad if someone could shed some 
> light on the following:
> What is serial_to_parallel doing?
> Why is this needed?

The fft_v{f,c}c block is defined to consume and produce a stream of
vectors.  The size of the vectors must be equal to the FFT size.
serial_to_parallel (also known as: serial_to_vector) converts a stream
of items into a stream of (fixed length) vectors of items.

> Why vectors and not the usual block data?

Seemed like the right answer.  It allows us to deal with the input and
output of the block oriented FFT in a natural way.

> What is the window flag (3rd parameter) in fft_v{f,c}c for?

It specifies the window to be applied to the data prior to computing the
FFT.  See any DSP book for the background. 
http://comsec.com/wiki?SuggestedReading
Lyons' book is a good place to start.

> What would be the best way to document all this in a nice 
> end-user-compatible way? (I suppose users should be able to do their 
> programming in python with some form of documentation that is _not_ C++ 
> source code)

There are currently the doxygen generated C++-centric docs.
http://www.gnu.org/software/gnuradio/doc/index.html
These are generated by using ./configure --enable-doxygen option when
building gnuradio-core. 

Probably the right answer is to extract the doxygen comments from the
C++ code, convert them to python notation, then merge with the docs
extracted from the native python code.  This requires a combination of
doxygen to extract and generate an XML version of the C++ docs, a bit
of messing around with XSLT or similar, then a run through epydoc.

The output should be python-centric docs in epydoc output format.
See http://epydoc.sf.net and http://www.stack.nl/~dimitri/doxygen

I've got a patch somewhere in my email that's supposed to do this.
If you're interested in testing it out, I'll dig it out and you can
try it.  If it works, we'll apply it.

Eric