USRP N210 Benchmarks

GNU Radio
1

Hello all:

We have been working on an APCO P25 project at my university, and are
fortunate enough to have 4 USRP N210’s all equipped with the WBX boards.

As the project has progressed we have accomplished many of our goals.
However, one thing that has haunted us throughout the entire project is
transmission from USRP to USRP results in very high bit errors. We also
have 2 P25 handsets available and when Tx’ing from a handset and
receiving
from a USRP or Tx’ing from the USRP and receiving from a handset,
everything
is fine, we have no perceivable bit errors (we haven’t really dug into
the
exact bit error measurements, however, we are working with a DVSI AMBE
vocoder/FEC, which implies the bit errors are large enough to screw up
the
error correction, which, no matter how you cut it, shouldn’t happen with
two
USRP’s 2 feet from each other).

So we ran some tests with the 4 USRP’s

We used a two-tone test at +1kHz and -2kHz. We used GNU Radio and GRC
with
a fairly simple set up that consisted of reading the MATLAB generated
two-tone sample data using the “file source” block into the “UHD USRP
sink.”
On the Rx end, it was the same, but reversed. I have supplied figures
of
the received data, but guessed the GRC setup code isn’t necessary.

In the first figure, we saw that using the same USRP for Tx and
switching
USRP’s on the Rx end resulted in very odd data. In the second, we used
USRP
1 to Tx and 2 to Rx (what we believe to be the “worst” USRP’s in the
bundle)
and attached them to an external clock. It can be seen that as far as
the
two tone test goes, the peaks were right on the money.

Another thing we noted is that by changing the gain on the Tx end, the
harmonics shown don’t scale with the power. At low power, the harmonics
are
far too close to the main peaks, which is worrying (initially we had the
gain of the USRPs marginally under the maximum gain because we initially
thought the errors were caused by the RF front end going into some kind
of
saturation state. From this data we see this isn’t the case). Also of
note
is that at the time the first figure was generated, the USRP’s were
approximately 2 feet from each other. In the latter figure, they were
about
5 feet apart. It is obvious that the harmonics in the second figure are
higher, relative to the main peaks, than the first. I don’t really have
a
solid question to ask other than is this behavior normal?

It is apparent that the poor results in the first figure are caused by
clock
drift, but the harmonics are also very worrying. Especially USRP 4 in
the
first figure, which shows a relatively high harmonic right next to the
main
peaks. Since the time we have sampled the supplied data, we have been
progressing forward in the project, so we haven’t been able to test the
P25
waveform from USRP to USRP, and can’t verify that the initial bit error
problems are alleviated by getting rid of the clock drift, or if they
are
caused by the harmonics. Is there something we can do to remedy this
problem, or, again, is this behavior normal?

http://old.nabble.com/file/p32726685/Rx_DualTone_1.jpg

http://old.nabble.com/file/p32726685/external_clock_dual_tone.jpg

View this message in context:
http://old.nabble.com/USRP-N210-Benchmarks.-tp32726685p32726685.html
Sent from the GnuRadio mailing list archive at Nabble.com.

2

is fine, we have no perceivable bit errors (we haven’t really dug into the
On the Rx end, it was the same, but reversed. I have supplied figures of
far too close to the main peaks, which is worrying (initially we had the
drift, but the harmonics are also very worrying. Especially USRP 4 in the

http://old.nabble.com/file/p32726685/external_clock_dual_tone.jpg
Try setting the RF gain to 25, and scaling the magnitude of the
signals–what happens then? If you’re adding two tones both with
magnitude
“1.0” you’ll end up clipping DAC, producing unwanted products.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

3

Hello to you too

At our university we have seen this behaviour as well.
Our setup is a USRP N210 with a 2400 daughterboard into a Rhode & Swartz
spectrum analyzer.
We also get these sidelobes, and if you trawl the archives, you will
find
others have as well.

Currently we are working on a theory that it might be the CORDIC
algorithm
in the FPGA that causes the disturbance.

I have managed to create Matlab and Python code showing some of the same
characteristics, and am currently working on implementing this into a
block,
so that a channel model can be done.

I believe the reason is the way the CORDIC algorithm is implemented.
In the verilog code, there are two hints that it might be written
better,
but that it is difficult because of the verilog language.
It is however almost trivial using VHDL, so I am currently considering
rewriting the CORDIC in VHDL, although this will probably not be untill
we
have handed in our Masters Thesis (The main object of the thesis is not
correcting possible errors, but documenting their impact).

We would very much like to use the very descriptive images you have
provided
in our work, if that’s okay with you.

Best Regards
Paul M. Bendixen
Stud. Scient EE

2011/10/26 justynnuff [email protected]

4

On 27/10/11 03:42 AM, Paul M. Bendixen wrote:

thesis is not correcting possible errors, but documenting their impact).

We would very much like to use the very descriptive images you have
provided in our work, if that’s okay with you.

Best Regards
Paul M. Bendixen
Stud. Scient EE

The attached two_tone flow-graph shows that close-in intermod products
are sensitive to overall
signal magnitude settings. Keep the digitla signal magnitudes lower,
and the intermod products are
quite well suppressed. The flow-graph is setup for a WBX for the
antenna settings.

Keep in mind that the CORDIC is used only when the desired target
frequency is not a multiple of
the resolution of the PLL synthesizer on whatever daughtercard you’re
using, otherwise the CORDIC
NCO doesn’t do anything to the signal.

Connect the TX/RX port to the RX2 port through a 60dB attenuator, so you
can use the RX side to
monitor the spectrum of the TX side. The RX-side bandwidth is set to
50Khz total, which gives you
a good close-in view of the spectrum around the +/- 1Khz tones. Vary
the digital gain control, and
observe intermod peaks around the fundamental tones, and observe that
at digital gains below 0.250,
the intermod peaks become well suppressed (about 45dB down from the
fundamental tones).

5

Well, that sounds like the lazy solution, intermodulation products are
bad, so just throwing the transmitter power away is not what I’d prefer.
But what it points to is an analog issue, entirely independant of the
CORDIC (which, as I observe, isn’t likely involved in the test cases
at hand here).

Analog gain elements (including DACs) have operating regions over which
they’re linear, and operating regions over which they’re not
linear. If you drive any amplifier near its maximum operating point,
it will start to become non-linear to one degree or another. I’ll
let Matt or one of the other engineering folks at Ettus comment
further, but I personally am totally unsurprised when things start to
become non-linear near the nominal maximum operating point.

Is there any way of finding out what the resolution is? We haven’t
been able to track it down for the RFX2400 board,
but this sounds like a nice way to test if it is the CORDIC.

Look at the tune_result_t from tuning:

http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__result__t.html

If the actual_dsp_freq is 0, then the CORDIC wasn’t involved.

I tuned to an even number of MHz, which on all of the synthesizers
should yield 0 CORDIC frequency.

But maybe Josh can add a feature to ‘uhd_usrp_probe’ to display the PLL
resolution (although in some cases,
it may change with target frequency range, I think).

Only problem there is that there is a 55 dB loop back between the in
and output of the RFX2400 board, so two different radios are needed.

You’re talking about the combined isolation of the two RF switches in
the path between the TX and RX? That’s adequate attenuation
for the tests I’m suggesting.

We have observed this as well, but as described before we do not find
this to be the correct solution.
I’m keen to hear what your “correct solution” is to the problem of
non-linearity in off-the-shelf analog gain devices. I suspect the
solution
won’t be in the digital domain, but I’m always willing to be
surprised.

6

I’ll refer the list to this:

http://gnuradio.org/redmine/attachments/download/249/02-ettus-practical-radios.pdf

Which gives a decent overview of the issues that happen at the interface
between the digital world of “perfection”, and the
horrible, capricious, analog world beyond the DAC.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

7

Hello

2011/10/27 Marcus D. Leech [email protected]

The attached two_tone flow-graph shows that close-in intermod products

are sensitive to overall

signal magnitude settings. Keep the digitla signal magnitudes lower,

and the intermod products are

quite well suppressed. The flow-graph is setup for a WBX for the

antenna settings.

Well, that sounds like the lazy solution, intermodulation products are
bad,
so just throwing the transmitter power away is not what I’d prefer.

Keep in mind that the CORDIC is used only when the desired target

frequency is not a multiple of

the resolution of the PLL synthesizer on whatever daughtercard you’re

using, otherwise the CORDIC

NCO doesn’t do anything to the signal.

Is there any way of finding out what the resolution is? We haven’t been
able
to track it down for the RFX2400 board,
but this sounds like a nice way to test if it is the CORDIC.

Connect the TX/RX port to the RX2 port through a 60dB attenuator, so you
can use the RX side to

monitor the spectrum of the TX side. The RX-side bandwidth is set to

50Khz total, which gives you
a good close-in view of the spectrum around the +/- 1Khz tones. Vary
the digital gain control, and

observe intermod peaks around the fundamental tones, and observe that

at digital gains below 0.250,
the intermod peaks become well suppressed (about 45dB down from the
fundamental tones).

Only problem there is that there is a 55 dB loop back between the in and
output of the RFX2400 board, so two different radios are needed.

We have observed this as well, but as described before we do not find
this
to be the correct solution.

About the disabling of the CORDIC, I do not currently have a Xilinx ISE
licence, but have instigated measures to get one.
When I (hopefully) do, I will try out both cutting it out and using an
optimized one, written in VHDL.

Best Paul

8 
of the CORDIC (which, as I observe, isn't likely involved in the
  become non-linear near the nominal maximum operating point.

confirms what we have observed.
At 2.4GHz there is no problems, when we go 300 kHz up, we start
seeing the problems. (see images attached)

This is further collaborated, with the fact that we can find “good”
frequencies up through the entire band.

Keep in mind also that spur and phase-noise performance of a PLL
synthesizer will tend to
change with different tunings. Said performance on spot frequencies
can be improved by
engaging in an optimization exercise involving not only PLL register
settings, but changing
the analog loop filter on the PLL as well.

9

2011/10/27 Marcus D. Leech [email protected]

they’re linear, and operating regions over which they’re not
but this sounds like a nice way to test if it is the CORDIC.
yield 0 CORDIC frequency.

But maybe Josh can add a feature to ‘uhd_usrp_probe’ to display the PLL
resolution (although in some cases,
it may change with target frequency range, I think).

Thank yo very much for this, It is really usefull, and it furthermore
confirms what we have observed.
At 2.4GHz there is no problems, when we go 300 kHz up, we start seeing
the
problems. (see images attached)

This is further collaborated, with the fact that we can find “good”
frequencies up through the entire band.

Only problem there is that there is a 55 dB loop back between the in and
output of the RFX2400 board, so two different radios are needed.

You’re talking about the combined isolation of the two RF switches in
the path between the TX and RX? That’s adequate attenuation
for the tests I’m suggesting.

I think I prefer our measurement equipment at the University

We have observed this as well, but as described before we do not find
this to be the correct solution.

I’m keen to hear what your “correct solution” is to the problem of
non-linearity in off-the-shelf analog gain devices. I suspect the solution
won’t be in the digital domain, but I’m always willing to be surprised.

I have implemented the cordic in vhdl now, this should reduce the phase
error (which is also mentioned in the pdf you referenced) because of the
ability to increase the CORDIC stages.

I am now just waiting for a Xilinx license.

Best Paul

10

Hey guys, sorry for the extremely late response. Although identifying
and
solving USRP problems is great, our focus lies in the project at hand.

That being said, the responses on here were great. We tried scaling the
input signal magnitude and it actually worked very well. The perplexing
thing, however, is that the more we scale the magnitude, the better the
observable spectrum got. There was no point in which scaling the
magnitude
didn’t show at least a little improvement on the spectrum. I have
attached
the spectrum of our actual P25 waveform with scaling. Also included in
that figure (yellow) is a signal captured by the USRP that was
transmitted
using an EF Johnson handset with a P25 waveform installed. Clearly the
EF
Johnson’s spectrum looks the best, and although we didn’t try scaling
our
data further than by .0625, the signal decreases in strength. At some
point the signal must be too weak to transmit without both compromising
the
SNR and the “granularity” or resolution of the original signal (if
that’s
the appropriate word to use).

The biggest thing I am considering is this: we are using a 12.5kHz
channel
on a daughterboard whose range is between 50MHz to 2.2GHz. Is such a
narrowband signal on such a wide band board problematic?

Although the spectrum looks great when scaled, when we actually test our
waveform from USRP to USRP we still get bit errors. Again, it’s hard to
say how many because we are utilizing a waveform that is equipped with a
software vocoder, encryption (small bit errors mean huge losses in
packets
we receive) and forward error correction (should eliminate small bit
errors). You can see how it is difficult to track down bit errors, but
my
personal opinion is that with forward error correction and the boxes
sitting no more than 4 feet away from each other, there are enough
errors
to ruin our encrypted messages, and that’s just too much.

We would very much like to use the very descriptive images you have

provided in our work, if that’s okay with you.

This is completely fine with all of us here, and thanks again for great
responses. With the availability of so many USRPs (did I mention we
have 2
USRP1s with the RFX daughterboards in them?) we can at least narrow
things
down a bit.

11

On Tue, Nov 22, 2011 at 3:54 PM, Justyn B. [email protected] wrote:

12

Hi again
Thank you very much, we expect our thesis will be available from some
time
next year, we will add it to the academic section.

The work we have done so far have pointed us to the daughterboard mixer.
All mixers have problems causing harmonics, and our research so far has
shown us that this is the big problem.
The work with gain adjusting the I Q channels in the drivers give us an
idea we might be right :wink:

We have spent a good while describing what frequencies the osclilator on
the daughterboard can supply.
When in auto mode, the UHD driver will try to select a frequency that is
offset, so that an actual direct up/down conversion does not take place.
This is what is normally known as the “Superheterodyne radio”. However,
because of the division of labour between the mixer in the FPGA and the
mixer on the daughterboard, the IF frequency selected is often too close
to
the daughterboard mixer frequency.

This results in quite a bit of nasty spikes around the desired signal.
There are two ways of testing this:
1: the “scientific”)
Try sending out a single frequency, a flowgraph of [complex cosine] →
[UHD
Sink] was good enough for us.
Check out what spurious frequencies are created. You will typically see
the
wanted signal (f_c +/- f_s), a bit of the actual carrier (f_c) and
mirrors of different description. (eg f_c +/- 2*f_s ; f_c -/+ f_s).
Increasing the signal frequency(f_s) will reveal which is the
oscilator(f_c) and which is the mirror.

Page 19 of the AD8349 (mixer for the RFX2400) showed part of this
explanation.

2: the “mechanics version”)
Try other frequencies, maybe you will get lucky :wink:

One other method might be to write all or parts of the application in
C++,
that way you should be able to select a mixer frequency far away from
the
one you need (the N210 FPGA mixer can provide +/- 50MHz offset, i
believe
the USRP1 can supply +/- 32MHz).
This way you should be able to reduce the spurious emissions.

The problem using this approach is that you will send the spurious
emissions into other parts of the band (the problem with having a narrow
signal in a wide-band application).

Best
Paul

2011/11/23 Justyn B. [email protected]

13

On Thu, Nov 24, 2011 at 5:59 AM, Paul M. Bendixen
[email protected] wrote:

Hi again
Thank you very much, we expect our thesis will be available from some time
next year, we will add it to the academic section.

The work we have done so far have pointed us to the daughterboard mixer.
All mixers have problems causing harmonics, and our research so far has
shown us that this is the big problem.
The work with gain adjusting the I Q channels in the drivers give us an idea
we might be right :wink:

Can you give more details? If you can, please post your measurements
which lead to this conclusion.

This results in quite a bit of nasty spikes around the desired signal.
Page 19 of the AD8349 (mixer for the RFX2400) showed part of this
explanation.

2: the “mechanics version”)
Try other frequencies, maybe you will get lucky :wink:

One other method might be to write all or parts of the application in C++,
that way you should be able to select a mixer frequency far away from the
one you need (the N210 FPGA mixer can provide +/- 50MHz offset, i believe
the USRP1 can supply +/- 32MHz).
This way you should be able to reduce the spurious emissions.

You can use the advanced tuning parameters in Python as well. No need
for C++ if you don’t want it. You can pick whatever LO offset
frequency you like.

http://files.ettus.com/uhd_docs/manual/html/general.html

The problem using this approach is that you will send the spurious emissions
into other parts of the band (the problem with having a narrow signal in a
wide-band application).

You will have this issue with essentially any direct-conversion
transceiver which has an open (or reasonably open) front end.

–n

14

Just to follow up, have you tried using the auto calibration of the IQ
channel released recently?

As far as we can discern, this might give you a good deal of reduction
in
the problematic spurious frequencies.
Also by using manual tuning where the daughterboard tuning is at least
12.5
kHz away (for the P25, as I understand that is the bandwidth?) and the
DSP
handles the rest? Effectively changing the setup to a superhet.

Just some thoughts

Best
Paul

15

Hi Nick

Thank you for looking into this.

2011/11/26 Nick F. [email protected]

The work with gain adjusting the I Q channels in the drivers give us an
idea
we might be right :wink:

Can you give more details? If you can, please post your measurements
which lead to this conclusion.

We did a couple of measurements just around the 2,4 GHz mark. The reason
we
thought it might be the daughterboard mixer is that the problem arose
whether we used a 2,4003 GHz carrier and a “zero” cosine or a 2,4GHz
carrier and a 300kHz cosine.

Since the mixer stage in the DAC is not activated (that we can see, is
this
a future possibility?) the (~only) next stage is the daughterboard
mixer.

The included picture is a 2,401GHz carrier, no cosine frequency into a
N210_r3 using an RFX2400, 42dB attenuator on a cable to a Rhode&Swartz
Spectrum analyser.

If you compare the peaks to the datasheet, you will see they are almost
identical (bear in mind that the datasheet uses LSB and we use USB).

This is in the very part where IQ imbalance is presented. Employing the
auto calibration might help reduce the peaks.
(when the RFX2400 gets support)

the daughterboard mixer frequency.
mirrors

http://files.ettus.com/uhd_docs/manual/html/general.html

OK, thank you, if we have the time before deadline, we will check this
out.
We have been using the GRC exclusively.

The problem using this approach is that you will send the spurious
emissions
into other parts of the band (the problem with having a narrow signal in
a
wide-band application).

You will have this issue with essentially any direct-conversion
transceiver which has an open (or reasonably open) front end.

Exactly. As I mentioned in the second paragraph :wink:
Our best bet as I see it, is to use a quasi-superhetrodyne approach,
where
possible.

Best
Paul