Re: OFDM test with USRP

GNU Radio
1

Hi Marcus,

Thanks for your very detailed comments.

My purpose of testing the PER is to facilitate evaluations on further
modifications of the codes. I’d like to set up a benchmark like the ones
I
have shown and then draw a PER vs SNR curve to show the performance just
like how we do evaluations theoretically. So I prefer to find the root
cause of this phenomenon rather than using error correction
or re-transmission.

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.

Originally, I feed in some fixed sequences. The working range of the
const
value is even smaller, around (0.035, 0.025). So later I replaced it
with
the random source. Indeed, I saw some improvement but yet not good
enough.

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.
According to my knowledge, the OFDM transceiver blocks I used is the
latest
one. I’ve read all the related codes so I know that there is actually
equalization done on the receiver end. Besides, the more advanced
example
you referred to is actually a breaking down of the receiver block that I
used. In other words, that is the internal implementation of the
receiver
block I used.

I will try checking the sample values as you suggested. Also, maybe I’ll
also use another USRP to test but I doubt it matters.

Best,
Henry

Message: 20
Date: Thu, 19 Mar 2015 13:37:53 +0100
From: Marcus M?ller [email protected]
To: [email protected]
Subject: Re: [Discuss-gnuradio] OFDM test with USRP
Message-ID: [email protected]
Content-Type: text/plain; charset=“windows-1252”

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.

2

Hi Marcus,

I later added a throttle and time scope to the tx end to see how large
the
amplitude can be. Indeed, when the multiplier is 60m, the amplitude
increases beyond 1, which will be clipped by the USRP driver. Setting it
to
be 0.45 seems like a safe choice.

For small amplitude cases such as when the multiplier is 20m, the SNR is
also low. The reason the OFDM receiver fails to receive many packets is
actually because the threshold used in digital.ofdm_sync_sc_cfb() for
the
plateau detector. Currently, the code leaves the threshold value to be
default, which is 0.9. In low SNR cases, in fact, we need to set it
smaller
to tolerate noise. Originally, let’s say the synchronization rate is
only
1% or even lower, after this adjustment, it can be over 90%. I suggest
adding a parameter in ofdm_txrx.py to adjust this parameter.

Back to the high SNR cases, one issue puzzling me now is that when the
multiplier is 60m, although indeed there are samples exceeding the
amplitude limitation of 1, many other samples (in fact most of them)
have a
small amplitude less than 0.5. This greatly limits the overall SNR we
can
get. I wonder if there can be any improvements over this?

Thanks
Henry

3

On 19.03.2015 14:11, Henry J. wrote:

Hi Marcus,

I later added a throttle and time scope to the tx end to see how large
the amplitude can be. Indeed, when the multiplier is 60m, the amplitude
increases beyond 1, which will be clipped by the USRP driver. Setting it
to be 0.45 seems like a safe choice.

You might be able to push it a bit more. But definitely stay clear from
1.

For small amplitude cases such as when the multiplier is 20m, the SNR is
also low. The reason the OFDM receiver fails to receive many packets is
actually because the threshold used in digital.ofdm_sync_sc_cfb() for
the plateau detector. Currently, the code leaves the threshold value to
be default, which is 0.9. In low SNR cases, in fact, we need to set it
smaller to tolerate noise. Originally, let’s say the synchronization
rate is only 1% or even lower, after this adjustment, it can be over
90%. I suggest adding a parameter in ofdm_txrx.py to adjust this parameter.

Hm. S&C works fine for low SNRs, and changing the threshold is usually
not required, due to normalization. I’d be hesitant to add that
parameter, there might be another issue here. When you say low SNR,
which regime are you talking about? Because the slicers (QPSK demapping)
will usually fail before the detection.

Back to the high SNR cases, one issue puzzling me now is that when the
multiplier is 60m, although indeed there are samples exceeding the
amplitude limitation of 1, many other samples (in fact most of them)
have a small amplitude less than 0.5. This greatly limits the overall
SNR we can get. I wonder if there can be any improvements over this?

This is a well-known OFDM issue. You can choose an encoding that will
limit PAPR, use pilot tones that decrease PAPR… and many other
PAPR-reducing techniques.
This also depends on how many subcarriers you use. For random data, your
PAPR usually stays within 2*ln(N), which is usually not that bad.

Cheers,
M

4

Hi Martin,

Thanks for the FOSDEM 14 video on youtube (although maybe not posted by
you). Your talk is very informative and helpful.

On Thursday, March 19, 2015, Martin B. [email protected]
wrote:

You might be able to push it a bit more. But definitely stay clear from 1.

There is a typo here. The max multiplier I can set is 0.045. This value
is
based on the display on the time scope. The value ensures that every
sample
stays below the limit of 1.

Hm. S&C works fine for low SNRs, and changing the threshold is usually not
required, due to normalization. I’d be hesitant to add that parameter,
there might be another issue here. When you say low SNR, which regime are
you talking about? Because the slicers (QPSK demapping) will usually fail
before the detection.

Since there seems no available SNR estimators for OFDM yet in GNURadio,
I
implemented one myself. Although it seems to be not quite accurate, but
it
can serve as a reference. The low SNR I was talking about is around 13
dB.
The observation that motivates me to modify the threshold is that the
receiver can almost fully decode every packet it received (i.e., the PER
is
quite low, around 2%). However, I noted that in fact many packets are
missing by observing the inconsistent packet_number in the tag debug at
the
receiver end. Conservatively speaking, more than 80% missed. So I figure
that maybe it is because the sync module fails to detect a peak. By
adding
some debug code, I am able to find the peak gap between each other is
random and large, not constant and small (It should be the exact or
nearly
exact number of samples in the whole frame). So by lowering the
threshold,
now it seems to be working as expected as now many packets can indeed be
received and decoded. To play safe, I only lower the threshold when
needed.
If the SNR is high, default value can still be used.

PAPR-reducing techniques.
This also depends on how many subcarriers you use. For random data, your
PAPR usually stays within 2*ln(N), which is usually not that bad.

I see. Currently, I’m using 48 data subcarriers out of 64 in total.

Cheers,
M

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Best,
Henry