OFDM Benchmark Tx Issue?

GNU Radio
1

I’ve been playing with the gr-digital OFDM benchmark, Tx -> Rx, and have
an odd issue that seems to be coming from within GNU Radio itself, not
UHD. My setup is: Mac OS X 10.6.8, latest UHD and GNU Radio from their
respective GIT masters, XCode 3.2.3 (gcc 4.2.1). I’m using 2 USRP1’s,
each with an XCVR2450 (in slot A, using antenna J1), connected to my
MacBook Pro (via USB 2.0). ‘uhd_usrp_probe’ and ‘uhd_find_devices’ both
work correctly in finding and identifying both USRP1’s. ‘uhd_fft.py’
seems to work

After installing GNU Radio into /usr/local, if I do in one terminal (or,
the equivalent in GRC), with XXX correct:

pushd /usr/local/share/gnuradio/examples/digital/ofdm
./benchmark_rx.py -a serial=XXX --spec A:0 -A J1 -f 5e+9 --snr 10

and in another (or, the equivalent in GRC), with YYY correct:

pushd /usr/local/share/gnuradio/examples/digital/ofdm
./benchmark_tx.py -a serial=YYY --spec A:0 -A J1 -f 5e+9

The Rx side shows nothing at all. So, I then used ‘uhd_fft.py’ to view
the spectrum, and it looks like the Tx (or, Rx) is off by quite a bit –
high by ~1 MHz. So, correcting via:

./benchmark_tx.py -a serial=YYY --spec A:0 -A J1 -f 4.999e+9

works quite well, with most of the packets being Rx’d correctly. I’ve
verified that swapping XXX and YYY has the same results, so it doesn’t
seem to matter which is doing Rx and which Tx.

I then created my own program in C/C++ to do a Tx using the UHD library,
making a multi-usrp and setting its various parameters as per the above
CLIs, then transmitting a real (complex part all 0) sinusoid of a known
frequency, and it displays (using ‘uhd_fft.py’) correctly centered just
off 5 GHz (like, maybe 1 kHz off, which is within device tolerance).

I’ve looked through the benchmark’s codes (mostly the Python parts, but
also some of the blocks in C++), and nothing pops out as an obvious
issue. I tried “rm -rf” in /usr/local and my build directories (UHD and
GNU Radio), then rebuilding and reinstalling both UHD and GNU Radio, but
with the same results.

Can anyone tell me what I’m not doing correctly, or suggest further
tests to track down the issue?

I highly suspect it’s user error :slight_smile: but I’m truly at a loss right now as
to the error.

Thanks! - MLD

2

I highly suspect it’s user error :slight_smile: but I’m truly at a loss right now as to the
error.

Michael,
we encountered a very similar issue and spent already a lot of time on
that. Configuration is the same except we are using an USRP2 though.

We also did not receive anything at the RX side although the spectrum
looked quite good as we have checked that via usrp_fft.py.
Ultimately, we found out that it was about the sampling rate. We were
able to receive something with a sampling rate (respective bandwidth )
from 1.5 MSamples/s, better 2 MS/s.
We are assuming that this might be a decimation rate issue. We facing
the same problems with both a XCVR2450 and an RFX daugherboards. We
checked whether lower sampling rates are working with both
daughterboards (with another SDR implementation called Iris, also uses
UHD) and they do! Thus, this might eventually be a problem of GNU Radio.

Could you check whether you are receiving something with higher sampling
rates? Just invoke your benchmark scripts with a higher bandwidth, e.g.
-W 2M

BRs, Florian

3

Hi Florian - Interesting observation about better reception when using
larger bandwidths. I tried it out, and yes indeed they do seem better
at 1 MS/s compared with 250 or 500 kS/s – meaning that more packets are
received correctly at the higher rate than the lower rates. I didn’t
try > 1 MS/s yet, but I will later. I need to review my OFDM to get a
better clue as to why this might be the case.

Though this is interesting and useful, my problem wasn’t the packet
error rate.

My issue was that the Tx center frequency was 1 MHz high with a center
frequency of 5 GHz [1], no matter which USRP1 I used for Tx, when using
GNU Radio -> UHD. When I wrote my own C++ program to use UHD for doing
Tx of a real sinusoid – “real” so as to see both the + and - spikes, so
as to be able to determine where the center frequency is – everything
centered correctly when I set the UHD frequency to 5 GHz [2].

I don’t have time right now to investigate further. Mostly throwing
this out to see if anyone else had encountered it. - MLD

[1] 1 MHz off at 5 GHz is 200 ppm (yes?). IIRC a reasonable spec on
these boards is 5-10 ppm. So, > 10x off the spec? I doubt it. My
guess is it’s something in GNU Radio that wasn’t fixed when the
benchmarks were transitioned from gr-usrp* to UHD.

[2] The offset was ~1 kHz, or ~0.2 ppm, which is well within hardware
spec.

4

On Tue, Feb 21, 2012 at 9:14 AM, Michael D. [email protected]
wrote:

Hi Florian - Interesting observation about better reception when using
larger bandwidths. I tried it out, and yes indeed they do seem better at 1
MS/s compared with 250 or 500 kS/s – meaning that more packets are
received correctly at the higher rate than the lower rates. I didn’t try >
1 MS/s yet, but I will later. I need to review my OFDM to get a better
clue as to why this might be the case.

It’s because with the larger bandwidth, the subcarriers, too, have a
larger
bandwidth. The coarse frequency correction is only set to look at so
large
an offset based on a number of subcarriers (+/-5 or 10), so now with the
same frequency offset, 5 (or 10) carriers is a larger frequency span to
check.

I don’t have time right now to investigate further. Mostly throwing this
out to see if anyone else had encountered it. - MLD

[1] 1 MHz off at 5 GHz is 200 ppm (yes?). IIRC a reasonable spec on these
boards is 5-10 ppm. So, > 10x off the spec? I doubt it. My guess is
it’s something in GNU Radio that wasn’t fixed when the benchmarks were
transitioned from gr-usrp* to UHD.

[2] The offset was ~1 kHz, or ~0.2 ppm, which is well within hardware spec.

I think this is a known problem with the XCVR that has been fixed. Make
sure you have the most up-to-date master branch of both the UHD and GNU
Radio.

Tom

5

On Feb 21, 2012, at 9:44 AM, Tom R. wrote:

It’s because with the larger bandwidth, the subcarriers, too, have a larger
bandwidth. The coarse frequency correction is only set to look at so large an
offset based on a number of subcarriers (+/-5 or 10), so now with the same
frequency offset, 5 (or 10) carriers is a larger frequency span to check.

Ah; yes. That makes sense. My mind is thrashing with multi-thread
dilemmas, not signal processing, right now.

1 MHz off at 5 GHz is 200 ppm (yes?). IIRC a reasonable spec on these boards
is 5-10 ppm. So, > 10x off the spec? I doubt it. My guess is it’s something in
GNU Radio that wasn’t fixed when the benchmarks were transitioned from gr-usrp* to
UHD.

I think this is a known problem with the XCVR that has been fixed. Make sure you
have the most up-to-date master branch of both the UHD and GNU Radio.

They were both the most recent as of yesterday. I’ll update right now &
see if that helps, but I’m doubtful since none of the commits since
yesterday seem to impact the behavior of the XCVR. I’ll also remove any
cruft in /usr/local before re-installing. More later. - MLD

6

On Feb 21, 2012, at 10:05 AM, Tom R. wrote:

Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it just
with the OFDM transmitter?

I do see it with uhd_siggen.py. Didn’t know about that utility; cool! -
MLD

7

On Tue, Feb 21, 2012 at 10:00 AM, Michael D. [email protected]
wrote:

1 MHz off at 5 GHz is 200 ppm (yes?). IIRC a reasonable spec on these
yesterday seem to impact the behavior of the XCVR. I’ll also remove any
cruft in /usr/local before re-installing. More later. - MLD

No, this would have been fixed weeks/months ago, so updating today won’t
help.

Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it
just with the OFDM transmitter?

Tom

8

So I just did:

(1) UHD: git pull, redo-cmake, build, install, uninstall, install
(2) GNU Radio: git pull, redo-cmake, build install, uninstall
(3) UHD: uninstall
(4) “cd /usr/local” and remove all cruft
(5) UHD: delete cmake directory, redo-cmake, build, install
(6) GNU Radio: delete cmake directory, redo-cmake, build, install
(7) download latest UHD images, and install them

So, I think I’m being thorough in using the most up-to-date versions of
UHD and GNU Radio, and also not having cruft around. I will admit that
I didn’t do a fresh GIT clone of either UHD or GNU Radio.

Even with all that I get the same results – that Tx is off by 1 MHz. I
guess next I’ll try a fresh clone of UHD and GNU Radio, and see if that
matters. - MLD

9

On Tue, Feb 21, 2012 at 11:35 AM, Florian Schlembach <
[email protected]> wrote:

Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it

just with the OFDM transmitter?

What is this tool doing? Transmitting a sine and checking the offset.
Sorry, for the moment I have no possibilitie to check that.

Yes.

correction algorithms implemented?

There is a coarse and a fine frequency offset correction. The fine
correct
makes sure that the subcarrier is centered in the bin; the coarse
adjusts
for an integer number of subcarriers off from the center frequency. By
default, the OFDM receiver will correct for some number of subcarrier
bins
(it’s either +/-5 or +/-10; I can’t remember). If your radios have a
frequency offset that is greater than the maximum number of subcarriers
specified here, the receiver cannot receive the symbols correctly.

Yes, you can transmit a tone using uhd_siggen.py to fine out a rough
estimate of the frequency offset and adjust either the transmitter or
receiver based on this number.

Tom

10

There is a coarse and a fine frequency offset correction. The fine
correct makes sure that the subcarrier is centered in the bin; the
coarse adjusts for an integer number of subcarriers off from the center
frequency. By default, the OFDM receiver will correct for some number of
subcarrier bins (it’s either +/-5 or +/-10; I can’t remember). If your
radios have a frequency offset that is greater than the maximum number
of subcarriers specified here, the receiver cannot receive the symbols
correctly.

How about the fine frequency offset correction? How can I turn it on?
For instance, how do I have to modify the benchmark/tunnel scripts in
order to do that?

Yes, you can transmit a tone using uhd_siggen.py to fine out a rough
estimate of the frequency offset and adjust either the transmitter or
receiver based on this number.

Thanks, I will try that next days.

11

Although using the same device to check on said carrier as is
transmitting it leads to compounding error in one direction or t’other.

Best to use another device (preferrably a lab spectrum analyser) to
check the offset.

-Marcus

On Tue, 21 Feb 2012 12:56:30 -0500, Tom
Rondeau wrote:

On Tue, Feb 21, 2012 at 11:35 AM, Florian Schlembach
wrote:

Are you seeing the 1 MHz offset when you use the
uhd_siggen.py? Or is it

just with the OFDM transmitter?
What is
this tool doing? Transmitting a sine and checking the offset. Sorry, for
the moment I have no possibilitie to check that.

Yes.

It’s
because with the larger bandwidth, the subcarriers, too, have a

larger bandwidth. The coarse frequency correction is only set to look
at

so large an offset based on a number of subcarriers (+/-5 or
10), so now

with the same frequency offset, 5 (or 10) carriers is a
larger frequency

span to check.

@Tom
does that mean that
there is only a coarse frequency correction implemented? How could I
overcome the offset in the easiest way? Checking it by usrp_siggen.py
and adjust in manually or are there some smart correction algorithms
implemented?

There is a coarse and a fine frequency offset
correction. The fine correct makes sure that the subcarrier is centered
in the bin; the coarse adjusts for an integer number of subcarriers off
from the center frequency. By default, the OFDM receiver will correct
for some number of subcarrier bins (it’s either +/-5 or +/-10; I can’t
remember). If your radios have a frequency offset that is greater than
the maximum number of subcarriers specified here, the receiver cannot
receive the symbols correctly.

Yes, you can transmit a tone using
uhd_siggen.py to fine out a rough estimate of the frequency offset and
adjust either the transmitter or receiver based on this number.

Tom

Links:

12

On Tue, Feb 21, 2012 at 1:06 PM, Florian Schlembach <
[email protected]> wrote:

How about the fine frequency offset correction? How can I turn it on? For
instance, how do I have to modify the benchmark/tunnel scripts in order to
do that?

it is on by default. You can’t receive OFDM unless you are doing that
kind
of correction; the ICI would be awful if you didn’t.

Tom

13

Are you seeing the 1 MHz offset when you use the uhd_siggen.py? Or is it
just with the OFDM transmitter?

What is this tool doing? Transmitting a sine and checking the offset.
Sorry, for the moment I have no possibilitie to check that.

It’s because with the larger bandwidth, the subcarriers, too, have a
larger bandwidth. The coarse frequency correction is only set to look
at
so large an offset based on a number of subcarriers (+/-5 or 10), so
now
with the same frequency offset, 5 (or 10) carriers is a larger
frequency
span to check.

@Tom
does that mean that there is only a coarse frequency correction
implemented? How could I overcome the offset in the easiest way?
Checking it by usrp_siggen.py and adjust in manually or are there some
smart correction algorithms implemented?