Re: benchmark_ofdm_rx not working

Tom, Matt, Robert, and others,

Thanks for the OFDM implementation; it looks very cool.

Unfortunately I’m having the same problems running
gnuradio-examples/python/ofdm/benchmark_ofdm_rx.py from the svn trunk.
I’ve attached a screenshot of benchmark_ofdm_tx.py as seen from
usrp_fft, and it looks reasonable.

My commmand lines:
./benchmark_ofdm_rx.py -v -R A -f 2.5e9
./benchmark_ofdm_tx.py -v -T A -f 2.5e9 --tx-amplitude=1000

(have also tried --tx-amplitude=10,100,500,2000,4000, and played with
–rx-gain at the receiver, and tried -f 2.45, -f 2.4 at both.)

USRPs Rev. 4.2 (circa 2006). I’ve tried both FLEX2400 and RFX2400/Rev
30 daughterboards. My transmitter and receiver are two feet away from
each other.

Program output:

$ ./benchmark_ofdm_rx.py -v -R A -f 2.5e9

gr_fir_ccf: using SSE
gr_fir_fff: using SSE

OFDM Demodulator:
Modulation Type: bpsk
FFT length: 512
Occupied Tones: 200
CP length: 128
Warning: failed to enable realtime scheduling
gr_buffer::allocate_buffer: warning: tried to allocate
20 items of size 1600. Due to alignment requirements
64 were allocated. If this isn’t OK, consider padding
your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.


Any pointers or suggestions why this isn’t working would be much
appreciated. Which daughterboards were used to develop/debug this?

Kyle Jamieson

Kyle Jamieson wrote:

./benchmark_ofdm_rx.py -v -R A -f 2.5e9

your structure to a power-of-two bytes.
On this platform, our allocation granularity is 4096 bytes.


Any pointers or suggestions why this isn’t working would be much
appreciated. Which daughterboards were used to develop/debug this?

Kyle Jamieson

These issues are most likely related to the synchronization at the
receiver. I can’t find the message someone sent out a couple of days ago
that mentioned being able to receive data with one board as the TX and
the other as the RX but not the other way around. At one point, we had a
bug in the code that would only correct for frequency offsets in one
direction, but I was sure Matt and I fixed this in early August. It’s
possible that this is still a problem and what you are seeing.

I doubt I’ll have a chance to look at this for a while, though, since
I’ll be traveling all of November.

Tom