Hi All,
I have 2 pairs of USRP2s with GNURadio3.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
nonworking
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,
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
nonworking 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
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 txamplitude 0.9 M 8 s 200 m bpsk
–fftlength=512 occupiedtones=80 i 64 txgain=10 cplength=128
./benchmark_ofdm_rx.py f 2.45G m bpsk fftlength=512
–occupiedtones=80
d 64 rxgain=20 cplength=128
I calculate the datarate 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,
On 02/12/2010 03:53 PM, Srinivas wrote:
–occupiedtones=80 d 64 rxgain=20 cplength=128
I calculate the datarate 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
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
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
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
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
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.
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
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
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
Hi
can i get the coding u used to implement OFDM receiver in USRP2??
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
Discussgnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discussgnuradio
–
View this message in context:
http://old.nabble.com/OFDMreceiveronUSRP2tp27557644p30658514.html
Sent from the GnuRadio mailing list archive at Nabble.com.
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 intercarrier 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
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
Discussgnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discussgnuradio
–
View this message in context:
http://old.nabble.com/OFDMreceiveronUSRP2tp27557644p30658519.html
Sent from the GnuRadio mailing list archive at Nabble.com.
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 macaddr=xxxx f 2.462G m
qpsk i
100 txgain=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 intercarrier 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/discussgnuradio
Discussgnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discussgnuradio
–
View this message in context:
http://old.nabble.com/OFDMreceiveronUSRP2tp27557644p30669471.html
Sent from the GnuRadio mailing list archive at Nabble.com.
On Mon, Jan 17, 2011 at 7:58 PM, Guanbo [email protected] wrote:
2.462G i 512 txgain=30 fftlength=2048 occupiedtones=200
d_coarse_freq is 64 → 6103Hz
I tried to look into the problem by changing the filter BW line 6668 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
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
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 macaddr=ADD m qpsk f
2.462G i 512 txgain=30 fftlength=2048 occupiedtones=200
@RX: $ sudo python benchmark_ofdm_rx_new.py macaddr=ADD m qpsk
f
2.462G d 512 rxgain=30 fftlength=2048 occupiedtones=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 6668 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
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)
Discussgnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discussgnuradio
–
View this message in context:
http://old.nabble.com/OFDMreceiveronUSRP2tp27557644p30676780.html
Sent from the GnuRadio mailing list archive at Nabble.com.