discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] The power of N log N


From: Eric Blossom
Subject: [Discuss-gnuradio] The power of N log N
Date: Mon, 13 Jun 2005 13:36:20 -0700
User-agent: Mutt/1.5.6i

Matt and I had quite the hack-a-thon over the past few days.

Here is partial list of bugs fixed and features added:

* FFT based FIR filtering.  We've currently coded gr.fft_filter_ccc,
  but it handles the float taps case too.  For ntaps = 64 with
  decimation = 1, it's more than 9 times faster than our best
  hand-coded SSE assembler on the Pentium M.  The break-even point is
  somewhere in neighborhood of 8 - 16 taps.  The speed-up you'll see
  depends on your machine architecuture and microarchitecture, as well
  as the configure options you use to build FFTW.

  See gnuradio-core/src/python/gnuradio/gr/benchmark_filters.py for
  code to compare gr.fir_filter_ccc to gr.fft_filter_ccc.

* Support for large FFT's

* The FFT sink display is now normalized by the number of bins, so
  that changing the number of bins doesn't change the displayed result.

* Support for fir filters with lots of taps (more than you should be
  using in a single stage).

* All the examples were examined and all calls to fftsink were
  changed to use the new prefered keywork argument form.  This makes
  available additional functionality not accessible through the legacy
  interface.  Details of the new interface are in fftsink.py

* Uniformly modulated polyphase DFT filter banks: analysis and
  synthesis.  This allows us to very efficiently separate out a bunch
  of evenly spaced channels on Rx or generate a bunch of uniformly
  spaced channels on Tx.  We've still got a bit of tuning to do on
  this, as well as shuffling the channels around so that they occur in
  left to right order (they've currently got the raw fft ordering,
  which most folks don't find intuitive ;-))
  
  See gnuradio-core/src/python/gnuradio/blksimpl/filterbank.py

* 6 new "plumbing" blocks:

  - gr.stream_to_streams(item_size, nstreams)
  - gr.streams_to_stream(item_size, nstreams)
  - gr.streams_to_vector(item_size, nstreams)
  - gr.vector_to_streams(item_size, nstream)
  - gr.stream_to_vector(item_size, vector_size)
  - gr.vector_to_stream(item_size, vector_size)

  (The last two were previously know as "serial_to_parallel" and
  "parallel_to_serial" respectively.)

  I'll draw some diagrams and send them to the list later on.

  * gr.stream_to_streams takes a single stream in, and produces nstreams
    out.  It effectively commutates the input items across the output
    streams.  The output streams are running at the input rate/nstreams

  * gr.streams_to_stream is the inverse of gr.stream_to_streams.

  * gr.streams_to_vector takes N streams in and produces a single
    stream of vectors out.  vector_element[0] comes from stream[0],
    vector_element[1] comes from stream[1], ...

  * gr.vector_to_streams is the inverse  of gr.streams_to_vector.

  * gr.stream_to_vector "reshapes" the input stream from N single
    items into a single output stream of vectors, each of which has N
    items.

  * gr.vector_to_stream is the inverse of gr.stream_to_vector.


Those are the highlights.  I'm sure I forgot something.

Eric




reply via email to

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