OFDM on USRP2

GNU Radio
1

Hi all,

Does anyone know of any updated OFDM benchmark code that is modified to
be run on a USRP2? I have seen previous posts of this, however the
link to the updated code is no longer available.

Thanks,

Michael R.
Graduate Research Assistant
Smart Lighting Engineering Research Center
Boston University
[email protected]

2

On Mon, Jan 10, 2011 at 5:56 PM, [email protected] wrote:

Graduate Research Assistant
Smart Lighting Engineering Research Center
Boston University
[email protected]

Maybe someone else has done something with the USRP2. I have not,
although it really should not be terribly difficult.

Most likely, we’ll migrate it to use UHD instead of adding another
application that is USRP2-specific.

Tom

3

Hi,

I updated the OFDM example. You can find it at
http://www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz

It supports both USRPs and the UHD driver. I get pretty bad
performance with UHD receiver for some reason. Any ideas?

Cheers,

Veljko

4

On 01/17/2011 11:31 AM, Veljko P. wrote:

Hi,

I updated the OFDM example. You can find it at
http://www.cs.ucsb.edu/~veljko/downloads/ofdm_example.tar.gz

It supports both USRPs and the UHD driver. I get pretty bad
performance with UHD receiver for some reason. Any ideas?

For the UHD performance issue, which model usrp? The following applies
to usrp2:

Was the bad performance on a transmit + receive application? There was
an issue where if receive was not keeping up, the transmit flow control
could be hampered; this is fixed on next branch.

Or was it receive only? And in any case did UHD print and warnings about
buffer sizes? Because it needs sysctl permission to allocate a large
enough receive buffer.

-josh

5

On Mon, Jan 17, 2011 at 2:48 PM, Josh B. [email protected] wrote:

enough receive buffer.

-josh

I found issues with the UHD code in setting the sample rates. When you
set the sample rate, the best thing to do is ask the UHD device what
the real sample rate it was actually set to. I then use a PFB arb
resampler to adjust to the actual sample rate that I want.

I was playing around with some FM signals and found that I couldn’t
get anything clean out until I did this, even though I was setting
what I thought was a standard sample rate (that is, an integer
decimation of the clock) to my N210. What I asked for and what I set
were only off by a little bit, but it makes a huge difference in
performance for FM signals.

That said, we should be adjusting for this in the OFDM code, but it’s
something to keep in mind.

Tom

6

Hi,

Thanks for the suggestions.
I use two USRP2s. When the receiver is loaded with the UHD driver it
exhibits poor performance. No matter if the sender is using the
standard or the UHD driver.

The buffer shouldn’t be the problem:

“Current recv sock buff size: 50000000 bytes”

I do get that filtering warning, though:

“Warning:
WBX: No tunable bandwidth, fixed filtered to 40MHz”

get_samp_rate returns the exact sampling rate I set it to.

Veljko

7

Hi,

I was looking for the source codes through the list.
And I got one from Veljko from UCSB, who are very nice to share his
codes,
“ofdm_example.tar.gz”
The codes are attached.
Given the enough gain in TX and RX, you can see the output result at RX.

Guanbo
http://old.nabble.com/file/p30650478/ofdm_example.zip ofdm_example.zip

mrahaim wrote:

Michael R.

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

8

I use two USRP2s. When the receiver is loaded with the UHD driver it
exhibits poor performance. No matter if the sender is using the
standard or the UHD driver.

I was under the impression that performance meant high cpu load, too
many overflows/dropped packets. I think you mean that the app with UHD
has poor reception of the OFDM packets?

If thats the case, I think UHD is ok; and perhaps this is an issue of
something gets tuned differently, or some gains get set differently, or
the issue of the drifting clock. Have you tried a external 10mhz
reference?

The buffer shouldn’t be the problem:

“Current recv sock buff size: 50000000 bytes”

ok, thats expected

I do get that filtering warning, though:

“Warning:
WBX: No tunable bandwidth, fixed filtered to 40MHz”

this is a result of calling set_bandwidth() on WBX

-Josh