OFDM receiver on USRP2

GNU Radio
1

Hi All,

I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On
one
pair I am able to successfully run OFDM (benchmark_ofdm_tx & rx) with
almost
95+% packet success rate. However on the other pair I am not receiving
even
1 packet!

I am using the same host machines and scripts. I also tried swapping the
daughtercards (XCVR2450) and the firmwares with the working pair, but
the
problem remains.

Does any one have a clue of where the problem might be ?

PS: The received signal spectrum (usrp2_fft.py) on one of the
non-working
USRP2s is attached herewith. Besides this I plotted the spectrum of the
received data from usrp2_rx_cfile.py at the receiver using MATLAB. The
spectrum is of the same shape and strength as usrp2_fft.py displays.

thanks,

2

On 02/11/2010 04:45 PM, Srinivas wrote:

Does any one have a clue of where the problem might be ?

PS: The received signal spectrum (usrp2_fft.py) on one of the
non-working USRP2s is attached herewith. Besides this I plotted the
spectrum of the received data from usrp2_rx_cfile.py at the receiver
using MATLAB. The spectrum is of the same shape and strength as
usrp2_fft.py displays.

Srinivas,

It looks like you are using a very narrow signal. The frequency offset
of the USRP2s giving you trouble may be enough that you are outside of
the search range of the OFDM receiver (which is a percentage of the
bandwidth of the signal).

You could try any or all of the following:

  • increasing the data rate by a factor of 2 or 4

  • modifying the OFDM code to widen the search range

  • locking the usrps to a common reference

  • measure the frequency offset of the transmitter, and run the receiver
    with the actual frequency. For example, if the receiver sees the signal
    30 kHz high using usrp2_fft.py, call the ofdm receiver with

    -f 2.450030G
    on the command line

Matt

3

Matt,

There was a frequency offset of ~30 KHz at the Rx w.r.t Tx so I
compensated
for it and it worked!.

The settings I am using is as follows:

./benchmark_ofdm_tx.py -f 2.45G --tx-amplitude 0.9 -M 8 -s 200 -m bpsk
–fft-length=512 --occupied-tones=80 -i 64 --tx-gain=10 --cp-length=128
./benchmark_ofdm_rx.py -f 2.45G -m bpsk --fft-length=512
–occupied-tones=80
-d 64 --rx-gain=20 --cp-length=128

I calculate the data-rate for OFDM as follows Data rate R = (ADC
sampling
rate x Occupied Tones) / (Nfft x Decimation)
For the above setting it is 244 KHz.

Am I right with the data rate calculation ?

Thanks very much for your time,

4

On 02/12/2010 03:53 PM, Srinivas wrote:

–occupied-tones=80 -d 64 --rx-gain=20 --cp-length=128

I calculate the data-rate for OFDM as follows Data rate R = (ADC
sampling rate x Occupied Tones) / (Nfft x Decimation)
For the above setting it is 244 KHz.

Am I right with the data rate calculation ?

That formula will give you the number of occupied tones per second. You
need to multiply by the number of bits per tone to get bps. If you are
using BPSK, multiply by 1. If using QPSK, you’ll need to multiply by 3,
8PSK by 3, etc.

Matt

5

That formula will give you the number of occupied tones per second. You
need to multiply by the number of bits per tone to get bps. If you are
using BPSK, multiply by 1. If using QPSK, you’ll need to multiply by 3,
8PSK by 3, etc.

I meant to say:

BPSK - multiply by 1
QPSK - mult by 2 (not 3 like I said above)
8PSK - mult by 3

sorry for the confusion.

Matt

6

Matt,

Thanks for verifying the data rate calculation!

I tried the other solutions that you suggested, namely,

*- increasing the data rate by a factor of 2 or 4
*It works.
*

  • modifying the OFDM code to widen the search range* - How do I widen
    the
    search range ?
    Should I be looking in the “ofdm_sync_” blocks in “blks2impl” folder ?
    If
    yes, which synchronizer is currently used with ofdm_examples ?

*- locking the usrps to a common reference
*My usrp2s are located wide apart so I guess this solution is not
practical.

Besides, this confirms that the problem is somewhere in the USRP2 board,
right ? (as I tried swapping the daughter cards & firmware with the
working
pair)

Thanks,
Srinivas

7

On 02/16/2010 02:45 PM, Srinivas wrote:

the search range ?
Should I be looking in the “ofdm_sync_” blocks in “blks2impl” folder ?
If yes, which synchronizer is currently used with ofdm_examples ?

*- locking the usrps to a common reference
*My usrp2s are located wide apart so I guess this solution is not practical.

Besides, this confirms that the problem is somewhere in the USRP2 board,
right ? (as I tried swapping the daughter cards & firmware with the
working pair)

No, this confirms that there is no problem. Frequency offset is a
natural part of radio systems. The software needs to handle it
properly.

Matt

8

On Tue, Feb 16, 2010 at 5:45 PM, Srinivas [email protected] wrote:

search range ?
Should I be looking in the “ofdm_sync_” blocks in “blks2impl” folder ? If
yes, which synchronizer is currently used with ofdm_examples ?

You need to add an argument to gr.ofdm_frame_acquisition in
ofdm_receiver.py (in python/gnuradio/blks2impl).

In the current Git master, this is located on line 109 of
ofdm_receiver.py. After the “ks[0]” argument, you can put in an
integer. This is the maximum number of bins the receiver will search
over for correlation. It defaults to 10.

  • locking the usrps to a common reference
    My usrp2s are located wide apart so I guess this solution is not practical.

Besides, this confirms that the problem is somewhere in the USRP2 board,
right ? (as I tried swapping the daughter cards & firmware with the working
pair)

Thanks,
Srinivas

Nope, this is typical of radio hardware. They are always off
frequency. If two oscillators are off frequency and then multiplied up
to another frequency, the difference will also be magnified. So a 2.4
GHz board will have a larger frequency offset than if you ran it just
through the BasicTx/Rx boards (even though the ratios should be the
same).

Tom

9

Hi Tom, Matt

replied inline:

On Wed, Feb 17, 2010 at 10:26 AM, Tom R.
[email protected]wrote:

  • modifying the OFDM code to widen the search range - How do I widen the
    over for correlation. It defaults to 10.

I added this extra argument and tried changing the values from 10 to 100. I
also tried with "int(0.5*occupied_tones) " as the argument, but it
doesn’t
receive for lower data rates (< 1M). Only when I increase the data rate

1.2M, I start receiving some pkts.

As mentioned before, when I compensate for the frequency offset at the
receiver it starts receiving packets successfully too.

  • locking the usrps to a common reference
    My usrp2s are located wide apart so I guess this solution is not
    practical.

Besides, this confirms that the problem is somewhere in the USRP2 board,
right ? (as I tried swapping the daughter cards & firmware with the
working
pair)

Thanks,
Srinivas

Nope, this is typical of radio hardware. They are always off

frequency. If two oscillators are off frequency and then multiplied up
to another frequency, the difference will also be magnified. So a 2.4
GHz board will have a larger frequency offset than if you ran it just
through the BasicTx/Rx boards (even though the ratios should be the
same).

Tom

Thanks! I understand this now.

10

On Thu, Feb 18, 2010 at 12:49 AM, Srinivas [email protected]
wrote:

Thanks for verifying the data rate calculation!
yes, which synchronizer is currently used with ofdm_examples ?
also tried with "int(0.5*occupied_tones) " as the argument, but it doesn’t
receive for lower data rates (< 1M). Only when I increase the data rate >
1.2M, I start receiving some pkts.

As mentioned before, when I compensate for the frequency offset at the
receiver it starts receiving packets successfully too.

For small bandwidths, it’s possible that the frequency offset has
pushed you outside of the channel filter. The filter is probably
specified too tight and is really supposed to cover only the occupied
tones, so if you’re too far away from the center frequency, the
filter’s already hitting it and no amount of frequency correction
after that will work.

In ofdm_receiver.py, try making the bandwidth term (bw on line 66)
wider and see what that does for you.

Also, you can print out d_coarse_freq calculated on line 130 in
gr_ofdm_frame_acquisition.cc. This is the number of bins you’re off by
that you can use to get a feel for how far away in frequency you are.

If opening up the filter works for you, please let us know. We might
want to either parameterize the bandwidth or just set it wider by
default.

Tom

11

Hi Tom,

I tried increasing the bandwidth of the filter and also tried changing
the
window type to KAISER, but it didn’t improve on the offset error. I am
getting a constant frequency offset value “-10”. Currently, I am just
compensating for the offset at the receiver or specifying a minimum BW
to be
used for that pair of USRP2s.

Thanks a lot for your time.

Srinivas

12

On 2/20/2010 7:43 PM, Srinivas wrote:

Srinivas
Changing the window type isn’t going to help much with this problem.
What I was suggesting was that the filter is too small, not the wrong
type. Also, the only way to change the offset value is to actually move
the frequency. I was just suggesting that you see what that value is to
see how many bins you are off by (i.e., calculate the bandwidth of a
subcarrier and multiply that by 10; that’s you’re coarse offset). You
can use that to see how much bigger to make the channel filter’s
bandwidth.

Tom

13

Hi
can i get the coding u used to implement OFDM receiver in USRP2??

14

Hi, Tom

I am not quite understand the ofdm_sync_xx.cc in
python/gnuradio/blks2impl/.

What is the difference between frequency synchronization and carrier
frequency offset.
Why we have to do the timing and frequency synchronization before it?

Thanks,
Guanbo

Tom R. wrote:

integer. This is the maximum number of bins the receiver will search

pair)

Tom

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30658514.html
Sent from the GnuRadio mailing list archive at Nabble.com.

15

On Wed, Jan 12, 2011 at 7:36 PM, Guanbo [email protected] wrote:

Guanbo
There is the difference between the fine frequency tuning (centering
the signal inside of a subcarrier) and coarse frequency tunning
(making sure that subcarrier 0 is at the correct location). The
ofdm_sync_xx blocks perform the timing and fine frequency calculations
(the self.nco in ofdm_receiver.py is generated from the fine frequency
offset from the sync block). This is required before being able to
perform the FFT demo, or else you’ll get inter-carrier interference.

We can then go into the frequency domain (after the FFT) and work on
the subcarrier bins to handle the coarse frequency offset, since it is
easier to do in this domain.

Tom

16

Hi, Tom

I am not quite understand the ofdm_sync_xx.cc in
python/gnuradio/blks2impl/.

What is the difference between frequency synchronization and carrier
frequency offset.
Why we have to do the timing and frequency synchronization before it?

Also,

Thanks,
Guanbo

Tom R. wrote:

integer. This is the maximum number of bins the receiver will search

pair)

Tom

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30658519.html
Sent from the GnuRadio mailing list archive at Nabble.com.

17

Thanks Tom. I tried to see how much the carrier frequency offset would
be.
As you suggested above, I output the coarse freq offset bins, which was
similar as Srinivas’s result. It is constant “-2”.

Does it means the carrier offset can be computed as: ADC rate /(
Decim_rate

  • FFT_len) * 2 ?
    If so, in my case, it is around 4KHz. From my knowledge, it seems too
    good
    to be true.

From your reference, I put on the channel filter code:

    bw = (float(occupied_tones) / float(fft_length)) / 2.0
    tb = bw*0.08
    chan_coeffs = gr.firdes.low_pass (1.0,                     #

gain
1.0, #
sampling rate
bw+tb, #
midpoint of trans. band
tb, #
width
of trans. band
gr.firdes.WIN_HAMMING) #
filter
type
self.chan_filt = gr.fft_filter_ccc(1, chan_coeffs)

    win = [1 for i in range(fft_length)]

Also, my hardware is USRP2+ XCVR2450.
$ sudo python benchmark_ofdm_tx_new.py --mac-addr=xxxx -f 2.462G -m
qpsk -i
100 --tx-gain=30 -M 8 -s 1000
FFT_len = 512 (default)
occupie_tones=200

Tom R. wrote:

Why we have to do the timing and frequency synchronization before it?
perform the FFT demo, or else you’ll get inter-carrier interference.

  • modifying the OFDM code to widen the search range - How do I widen
    ofdm_receiver.py. After the “ks[0]” argument, you can put in an
    right ? (as I tried swapping the daughter cards & firmware with the
    through the BasicTx/Rx boards (even though the ratios should be the

http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30669471.html
Sent from the GnuRadio mailing list archive at Nabble.com.

18

On Mon, Jan 17, 2011 at 7:58 PM, Guanbo [email protected] wrote:

2.462G -i 512 --tx-gain=30 --fft-length=2048 --occupied-tones=200
d_coarse_freq is -64 → -6103Hz

I tried to look into the problem by changing the filter BW line 66-68 of
ofdm_receiver.py, as well as shift length at line 109.
But they does not work out.

Would anyone can help to explain the problem here? Really appreciate :slight_smile:

Thanks,
Guanbo

I know this doesn’t directly answer your question, but I know that
Matt and I performed the exact same tests when we developed the OFDM
code to make sure that the coarse frequency offset followed the input
frequency offset that we used. So if one subcarrier in your case is
~95 Hz, we could easily track the coarse frequency offset output and
match up our results.

One problem that you seem to have is that a 20 kHz is completely
outside your channel. If I’ve done my math correctly, 20 kHz is almost
210 subcarriers and you are only using 200, so you are out of the
receiver’s channel by about 110 bins.

Tom

19

Hi,

I feel like the output of coarse frequency offset is very inaccurate. Or
probably it is not directly related.

For best test, I tried higher resolution of subcarrier bandwidth by
selecting the large FFT length, high Interp/decim rate,
as follows:
@TX: $ sudo python benchmark_ofdm_tx_new.py --mac-addr=ADD -m qpsk -f
2.462G -i 512 --tx-gain=30 --fft-length=2048 --occupied-tones=200
@RX: $ sudo python benchmark_ofdm_rx_new.py --mac-addr=ADD -m qpsk
-f
2.462G -d 512 --rx-gain=30 --fft-length=2048 --occupied-tones=200

From ofdm_frame_acquisition.cc, I can output d_coarse_freq.
Therefore, I can calculate the coarse frequency offset by: (ADC rate /
Decim rate / FFT_len) * d_coarse_freq

But the results I have obtained does not match the real frequency
offset.
From the command above, I obtained the d_coarse_freq = 2 → 190 Hz
By moving the RX center frequency to 2.46202G (20KHz offset), the output
d_coarse_freq is -64 → -6103Hz

I tried to look into the problem by changing the filter BW line 66-68 of
ofdm_receiver.py, as well as shift length at line 109.
But they does not work out.

Would anyone can help to explain the problem here? Really appreciate :slight_smile:

Thanks,
Guanbo

Tom R. wrote:

Thanks a lot for your time.
bandwidth.
> Hi Tom, Matt
>> >
>> > Should I be looking in the “ofdm_sync_” blocks in “blks2impl”
search
> As mentioned before, when I compensate for the frequency offset
In ofdm_receiver.py, try making the bandwidth term (bw on line 66)

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–
View this message in context:
http://old.nabble.com/OFDM-receiver-on-USRP2-tp27557644p30676780.html
Sent from the GnuRadio mailing list archive at Nabble.com.