[Top][All Lists]

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

Re: [Discuss-gnuradio] OFDM on E100

From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] OFDM on E100
Date: Sun, 13 Nov 2011 23:10:29 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 11/13/2011 11:00 PM, Josh Blum wrote:
It looks like the ofdm blocks are using a fair amount of multiply and
multiply const blocks:

gr-digital$ find -name "*ofdm*" | xargs grep mult
./python/ofdm_sync_ml.py:        self.mixer = gr.multiply_cc();
./python/ofdm_sync_ml.py:        # The output theta of the correlator above is 
multiplied with this correlation to
./python/ofdm_sync_ml.py:        self.mul = gr.multiply_ff()
./python/ofdm_receiver.py:            self.chan_filt = gr.multiply_const_cc(1.0)
./python/ofdm_receiver.py:        self.sigmix = gr.multiply_cc()
./python/ofdm_sync_pn.py:        self.corr = gr.multiply_cc();
./python/ofdm_sync_pn.py:        self.square = gr.multiply_ff()
./python/ofdm_packet_utils.py:    to get to a multiple of 8.
./python/ofdm_packet_utils.py:    # pad to multiple of 8
./python/ofdm_packet_utils.py:    up being a multiple of 512 bytes when sent 
across the USB.  We
./python/ofdm_packet_utils.py:    is a multiple of 128 samples.
./python/ofdm.py:        @param pad_for_usrp: If true, packets are padded such 
that they end up a multiple of 128 samples
./python/ofdm.py:        self.scale = gr.multiply_const_cc(1.0 / 
./python/ofdm_sync_pnac.py:        self.corr = gr.multiply_cc();
I bet many of these multiply consts could be simplified out. But, doing
little things like replacing the multiplier implementation with one
optimized with the SIMD unit makes a big difference, especially on a arm
where NEON>>  FPU.

So, there is a multiply and multiply const for floats that has been
optimized in my gr-basic branch. You may want to try using those blocks
instead. http://gnuradio.org/cgit/jblum.git/log/?h=gr_basic

The main transform in an OFDM transmitter, though, is an inverse FFT, and I assume those blocks use the built-in FFTW implementation,
  rather than doing their own.

Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

reply via email to

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