# Large spike at the center frequency when using Ettus X310

I am using the Ettus X310 SDR and GNU radio. On the GNU radio schema I have a standard UHD USRP source block connected to a GUI FFT sink - basically I'm just displaying the spectrum of the raw signal from the device.

Parameters for the USRP source block:

• sample rate = 1.024 MS/s,
• center freq = 101 MHz,
• gain = 42 dB,
• bandwidth = 130 MHz

The problem that I have is that I always have a big spike (10-15 dB) directly on the center frequency (no matter what frequency I set). I am relatively new to all this so I would appreciate any pointers on how to get rid of the spike.

The problem that I have is that I always have a big spike (10-15 dB) directly on the center frequency (no matter what frequency I set). I am relatively new to all this so I would appreciate any pointers on how to get rid of the spike.

That spike is probably nothing surprising – just the LO leakage/DC offset, a very common artifact in direct conversion receivers!

Now, getting rid of it with a USRP is relatively simple.

You have to understand that the USRPs have a two-step tuning process:

1. There's a physical oscillator, the LO, which gets synthesized by the daughterboard, and is used to mix down the target signal to IQ baseband signals. Typically, synthesizers can only generate a discrete set of LO frequencies $f_\text{RF}$.
2. The ADC then samples these signals at the master clock rate, and the FPGA digitally shifts that sample stream in the master clock rate (i.e. 200 MHz for the X310 by default) wide baseband by essentially multiplying with $e^{j2\pi f_\text{offset} n}$, to give you your baseband signal from the desired $f_\text{target}$:

By default, $f_\text{RF}$ is set as closely as possible to $f_\text{target}$, minimizing $f_\text{offset}$, and hence, putting the LO into your observed bandwidth $b_\text{sample}$.

You can, however, manually set a "desired" $f_\text{offset}$; as soon as that is more than $\frac 12 b_\text{sample}$, the LO is out of your observer band!

Instead of using 101e6 in the Center Frequency input field, just use

uhd.tune_request(f_target, f_offset)


e.g.

uhd.tune_request(101e6, 4e6)


Let me comment on a few other issues directly, too:

I am using the Ettus X310 SDR and GNU radio.

The X310 is the platform, indeed, but the actual analog signal processing (generating the LOs for mixing, mixing, amplification, baseband filtering) happens on the daughterboard. In such cases, it's usually important to specify which daughterboard you're using

On the GNU radio schema I have a standard UHD USRP source block connected to a GUI FFT sink - basically I'm just displaying the spectrum of the raw signal from the device.

Indeed, that should work. Notice that the WX Gui blocks are kind of becoming deprecated; if you're just starting with GNU Radio and don't need to continue an existing application based on WX, I'd recommend changing the "build options" in the option block to "Qt", and replacing the "WX GUI FFT sink" with a "Qt GUI frequency sink". Same thing, more functionality, less CPU usage, usually.

Parameters for the USRP source block:

• sample rate = 1.024 MS/s,

You probably were using a master clock rate of 184.32 MHz, right?

For future readers, reproducing this (this specific rate really comes up more often then you'd think!):

The X310 doesn't support that sampling rate in the default configuration! The console window should contain a clear warning that UHD decided to use a different frequency, and which frequency that was – in your case, probably 1.02048… MS/s.

UHD Warning:
The hardware does not support the requested RX sample rate:
Target sample rate: 1.024000 MSps
Actual sample rate: 1.020408 MSps


That's because the X310 runs its ADC/DAC at what is called the master clock rate, which can take the values 200 MHz (default), 184.32 MHz (typical for some cellular network standards), 120 MHz (typical for LabView). The sample rate you deliver to the PC is a sample stream sampled at that rate, decimated in the FPGA to the rate you're requesting – and that decimation is done with "normal" decimating FIR filters, which can only give you an integer fraction of the input rate.

So,

$$1.020408… \frac{\text{MS}}{s} = \frac{200\frac{\text{ MS}}{s}}{196}$$

is possible,

$$1.024 \frac{\text{MS}}{s} = \frac{200\frac{\text{ MS}}{s}}{195.3125}$$

is not, when the MCR is set to it's default of 200 MHz.

With an MCR of $184.32\text{ MHz}$, which is $1.024\text{ MHz}*180$, this is indeed possible!

• center freq = 101 MHz,

Which probably means you're using the WBX or UBX daughterboard,

• gain = 42 dB,

which is not a gain setting that UBX or WBX support, their gain ranges are 0 – 31.5 dB and 0 – 31 dB, respectively.

• bandwidth = 130 MHz

That's the analog bandwidth specification; it applies to daughterboards with adjustable baseband low pass filters. However, there's no daughterboard in existence that has an adjustable baseband filter and a maximum bandwidth > 8 MHz.

In fact, this setting does nothing on UBX or WBX.

• Thank you very much for a lot of useful information! Regarding the daughterboard, I am using the UBX-160. You are right about the sample rate, I was getting the warning you mentioned above. Regarding the spike, I changed the cable from the antenna to the SDR and the spike disappeared (to my surprise). Then I realized it disappeared on higher gains (~30) but was still present at low gain values. After I used the tune_request trick the spike completely disappeared even on low gain values. – Tihomir Meščić May 4 '16 at 14:30
• Reading this answer again after some new learnt materiel. The answer is eye candy. – Denis May 9 at 10:42