OFDM - on air?

GNU Radio
1

Hello,

I’m currently trying to make your ofdm simulation work with two usrp
rev4. The scripts benchmark_ofdm_tx.py and …rx.py are modified in
order to send (I looked on the examples in the directory
“examples/python/digital/”).

Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
Flex2400RF boards used. (Maybe my first faults lay here)

I also recorded some seconds to a file so I can now replay the same
scenario.

The first thing I observe is that the synchronisation needs to know a
value for the SNR. Fiddling around with that, the synchronizer starts
the sampler even if no signal present (at high SNR-value), but no
samples get through it if the value is lower than 8.

The correlator block thinks to have found the known symbols sometimes in
the noise. And, very confusing to me, the first ofdm symbol, after the
correlation found a peak, is always the first known symbol - even in
absence of a signal.

The message “found at search delta…” appears very often, compared to
your simulation.
It looks like the following lines (I also edited some blocks to output
debug info):

found at search delta: 1,
demod out: 38 e6 55 d1 21 93 6f d4 2b ea 3a e3 41 4f d2
9 bf f9 f5 16 73 45 9c a e2 len: 25
bin 1 h_sqrd = ( 37442.839844, 1714.728149 ) power = 42633.847656
real(h)/p = 0.878242 angle = 0.045764

This is repeated until I kill the process. There are also other outputs,
with more “demod out” lines grouped together etc.

e.g. the first lines after the gr_buffer warning
bin 0 h_sqrd = ( 2.125927, 1.626051 ) power = 2.299746
real(h)/p = 0.924418 angle = 0.652948
found at search delta: 0,
demod out: 38 e6 55 d1 21 93 6f d4 2b ea 3a e3 41 4f d2
9 bf f9 f5 16 73 45 9c a e2 len: 25
demod out: 18 3c 8d b3 e7 9 5b cf f4 d6 52 3d a0 d2 be
1a a8 9c 4a a7 a1 36 9a 85 19 len: 25
demod out: e9 9c 88 d9 c4 93 db c7 c6 9d 87 49 21 b1 3a
40 12 6f 27 30 de a5 c8 97 f2 len: 25
demod out: 7f a5 bb 14 54 b4 84 e5 e9 3f e9 9d f5 a5 44
54 0 fb 6 21 0 44 49 9f fa len: 25

Thank you very much in advance
You did a great work on gnuradio!!
Dominik

2

rev4. The scripts benchmark_ofdm_tx.py and …rx.py are modified in
order to send (I looked on the examples in the directory
“examples/python/digital/”).

Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two
Flex2400RF boards used. (Maybe my first faults lay here)

Actually, your first fault was using the code :wink: We made a lot of
progress
last week, but we still have a ways to go before we get it to work over
the
air. OFDM requires a high dynamic range, and clipping can happen easily.
We
haven’t really analyzed this yet.

If you want to start playing around with it, benchmark_ofdm.py does a
loopback simulation with optional AWGN and multipath channels between
the Tx
and Rx blocks. We’re hoping to inject some quiet time into this
simulation
to test the signal acquisition capabilities. That is, we know that under
steady-state conditions we synchronize pretty well, but we don’t know
the
transient behavior when we first get s signal into the receiver.

I also recorded some seconds to a file so I can now replay the same
scenario.

The first thing I observe is that the synchronisation needs to know a
value for the SNR. Fiddling around with that, the synchronizer starts
the sampler even if no signal present (at high SNR-value), but no
samples get through it if the value is lower than 8.

Yes. We hope to make that more automatic if we can.

The correlator block thinks to have found the known symbols sometimes in
the noise. And, very confusing to me, the first ofdm symbol, after the
correlation found a peak, is always the first known symbol - even in
absence of a signal.

The message “found at search delta…” appears very often, compared to
your simulation.
It looks like the following lines (I also edited some blocks to output
debug info):

That’s a little disturbing. The search delta should only appear if we
correlate to the known PN sequences. Granted, we didn’t do a good job in
creating these two symbols, I still don’t think we should often randomly
correlate against noise with 200 symbols.

found at search delta: 1,
demod out: 38 e6 55 d1 21 93 6f d4 2b ea 3a e3 41 4f d2
9 bf f9 f5 16 73 45 9c a e2 len: 25
bin 1 h_sqrd = ( 37442.839844, 1714.728149 ) power = 42633.847656
real(h)/p = 0.878242 angle = 0.045764

This is repeated until I kill the process. There are also other outputs,
with more “demod out” lines grouped together etc.

Yes, we’ve injected a lot of debug information here, but I thought the
code
checked in had that output turned off. Are you using the newest code
(and
yes, I did just check a few new things in that we didn’t do before Matt
left).

demod out: 7f a5 bb 14 54 b4 84 e5 e9 3f e9 9d f5 a5 44
54 0 fb 6 21 0 44 49 9f fa len: 25

Thank you very much in advance
You did a great work on gnuradio!!
Dominik

Thanks! It’s a bit premature still, but I’m sure we’ll all be glad for
more
feedback as it comes together.

Tom

3

Hi!

So there is no obvious fault, e.g. that I set the wrong
decimation/interpolation rate? (the samplerate should be 400kS/s?)

I just compared “tx_ofdm.dat”, recorded in your simulation, to my
recorded file. Therefore I modified usrp_fft.py. In tx_ofdm.dat, it
shows a large frequency band in use, as expected. Unfortunately, my file
does not show the same behavior :frowning: It looks like gaussian noise with a
small carrier in the middle. Maybe I did not setup correctly the
transmit path.

The first few seconds while recording, there were no signal
transmission. This stage can be recognized in a waterfall diagram. It
seems to me that “the gaussian noise” I saw could be the transmitted
OFDM signal.

If you want to start playing around with it, benchmark_ofdm.py does a
loopback simulation with optional AWGN and multipath channels between the Tx
and Rx blocks. We’re hoping to inject some quiet time into this simulation
to test the signal acquisition capabilities. That is, we know that under
steady-state conditions we synchronize pretty well, but we don’t know the
transient behavior when we first get s signal into the receiver.
Good work! I studied the simulation for some hours, before I started to
port the sim to use the usrp.

Yes, we’ve injected a lot of debug information here, but I thought the code
checked in had that output turned off. Are you using the newest code (and
yes, I did just check a few new things in that we didn’t do before Matt
left).
The debug information appear because I turned it on. I am working on the
latest copy.

Thanks! It’s a bit premature still, but I’m sure we’ll all be glad for more
feedback as it comes together.
If you like, I can give you further feedback from time to time.

Dominik

4

Hi!

Just curious on the channel transfer function, I did some modification
on the ofdm simulation to see the magnitude and the argument. I am
inverting your equalizer coefficients (and actually scaling them down).
The coefficients of the region of interest in frequency domain are sent
out through a new vector stream.

In order to have it visual, the simulation script now is a class derived
from stdgui.

Maybe you are interested in that, e.g. for some demo purposes. I
attached a patch.

Dominik