OFDM test with USRP

GNU Radio
1

Hi everyone,

I have built a tx and a rx grc flowchart for OFDM using USRP. I found
the
range of the amplitude of the input is fairly small in order to get it
working (i.e., the USRP at the rx end can successfully decode the
packets.)
I wound if anyone can share some thoughts about this? I’ve been stuck
here
for several days.

To quantify the packet reception performance, I modified
digital.crc32_bb
so that even when the crc test fails, the wrong packet is still fed to
the
output. In this way, I can evaluate the packet error rate (PER). Through
my
test, I found the const in multiply_const in the tx part (which
corresponds
to amplitude adjustment) needs to be (0.05, 0.025). In this range, the
PER
can be 0. However, when the const value increases, for example, to 0.06.
the PER is around 0.0044. When we further increase the const value to
0.08,
the PER is above 10% or even higher. I guess this is probably because
the
input signal amplitude of the USRP needs to be in a certain working
range.
However, it seems to me this range is too small. Besides, how can I find
some numerical statistics about the amplitude limitation? On the other
hand, if the amplitude is decreased to 0.02, many packets will be failed
to
synchronize. But I do observed that the packets successfully
synchronized
are also correctly decoded. In other words, the PER is still 0, but the
number of packets correctly decoded is actually much smaller than the
number of packets sent.

I also tried to enable the two disabled blocks in the files but it is of
no
help.

Thanks for any comments.

link:
https://www.dropbox.com/s/ndrtide1g73u5ju/grc_ofdm_rx.grc?dl=0
https://www.dropbox.com/s/8g3kg2tg6pdh0dy/grc_ofdm_tx.grc?dl=0

2

Hi Henry,

I have built a tx and a rx grc flowchart for OFDM using USRP. I found
the range of the amplitude of the input is fairly small in order to
get it working (i.e., the USRP at the rx end can successfully decode
the packets.) I wound if anyone can share some thoughts about this?
I’ve been stuck here for several days.
there’s very many factors limiting the decodability of a transmission –
the main being SNR, especially since you get problems the further you
move away, but also aspects like the increased multipath effects, that
the equalizer might or might not be up to compensate.

What you’re seeing might be something else, though:

Through my test, I found the const in multiply_const in the tx part
(which corresponds to amplitude adjustment) needs to be (0.05, 0.025).
that value definitely has the effect of limiting the sample amplitude
that goes into your USRP. The USRP driver framework maps values from
-1;1 to (DAC_min; DAC_max), basically. Driving the USRP with values
close to (or even over) 1.0 will lead to clipping/gain compression
problems. However, small values of course lead to “weak signal” on
average, leading to low SNR. The OFDM Tx that you use internally uses
apropriate scaling to limit the values to magnitudes <= 1.0, so I’m a
bit surprised your constant is so small.

That is a problem so common in transmitters, especially in OFDM, that
there’s an abbreviation for that PAPR - Peak-to-Average Power ratio.
You often combat that by doing appropriate coding, with the aim of
guaranteing that no info symbols that map to time signals with strong
peaks exist. However, that means that you can’t use all the information
“capacity” of the OFDM words – and will be slower in the end. You can
solve that by ignoring the clipped/compressed peaks and fix the
resulting packets by doing error correction – but that also comes at
the price of less bits per second, since you have to add sufficient
redundancy in the transmitter. Your third option is to just don’t care
so much and retransmit broken packets – for low packet error rates,
that might be sufficient.

I’m a bit surprised, though – you just feed in random information, and
that should be white, which means that packets with unhealthily high
PAPR are seldom.

You should save the samples that come out of the OFDM mod block using a
file sink, and analyze them later; look for samples with magnitude >1.0
(they shouldn’t be there, because the output of the internal IFFT is
scaled with 1/sqrt(fftlen)).

However, when the const value increases, for example, to 0.06. the PER
is around 0.0044
That doesn’t sound half bad, considering you don’t do any equalizing. I
think (I’m not totally sure, was too lazy to look into the source code
just now) that the OFDM implementation (you’re using the older one, the
newer one is cooler) doesn’t do much on the receiving side to recover
the signal.
Have a look at the rx_ofdm example (in
/usr/[local/]share/gnuradio/examples/digital/, or so). That’s a bit more
advanced than your RX.

Greetings,
Marcus

On 03/19/2015 01:34 AM, Henry J. wrote:

Hi everyone,

I have built a tx and a rx grc flowchart for OFDM using USRP. I found
the range of the amplitude of the input is fairly small in order to
get it working (i.e., the USRP at the rx end can successfully decode
the packets.) I wound if anyone can share some thoughts about this?
I’ve been stuck here for several days.