Forum: GNU Radio Higher phase noise present on DBSRX when operated with USRP2

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
13a430b221ac6fe01d231967b9b2072b?d=identicon&s=25 Javier Arribas (Guest)
on 2010-07-26 19:47
(Received via mailing list)
Attachment: phase_noise_DBSRX.JPG (70 KB)
Dear all,

In our research center we are using the USRP2 to capture GNSS signals
present on the GPS L1 and Galileo E1 frequency bands, which are centered
at 1.57542 GHz. For this purpose, we have a DBSRX daughter board plugged
into a USRP2. Before going into details, we would like to list the
hardware and software versions of GNURadio and USRP we are using:

-    Operating system: Linux Ubuntu 9.10
-    Computer hardware: Intel Core 2 Quad, 8 GB RAM, SATA hard disk and
Realtek RTL8111/8168B PCI Express Gigabit Ethernet card.
-    GNURadio software: Stable v3.3.0 tarball build
-    DBSRX: hardware revision v2.2
-    DBSRX EEPROM: DBSRXclkmod (programmed with USRP2 firmware Burn
DBSRX EEPROM    Jul 14, 2010)
-    USRP2:  hardware revision v4.0
-    USRP2 FPGA image: Raw Ethernet  rel-20100603
-    USRP2 Firmware:  Raw Ethernet, No WBX or XCVR v3.3.1git  Jun 08,

The conversion from DBSRX to DBSRX clock mod was performed using the
procedure. Everything went fine and the DBSRX started to work with the

The program used to capture the signal samples was implemented with the
GNURadio Companion tool. A USRP2 source block diagram was connected
directly to a file sink. The real-time scheduler was enabled. The USRP2
source parameters are listed here:

-    Output type: Complex
-    Gain: 60 dB
-    Frequency: 1.57542 GHz
-    LO Offset: Default
-    Decimation: 8

By post-processing the captured signal with a MATLAB-based GPS software
receiver, we realize that the captured signal contains higher phase
noise than the previously captured by the same DBSRX board, but working
with the USRP1. The phase noise even prevents the correct decoding of
the GPS telemetry bits, so it is a problem.

Our first idea was that this noise could come from the PLL VCO not
locked to the MAX2118 PLL. We have found several posts regarding the
spurious signals coming from the USRP1 64 MHz local oscillator, although
this not match our problem. An attempt to solve the problem was done
decreasing the value of DBSRX resistor R194 (which is the reference
clock resistor input) in order to increase the oscillator clock level to
help the PLL, but the phase noise is still present.

If we are not wrong, the USRP1 uses a 4 MHz reference clock to feed the
DBSRX PLL, using the io_rx_00 pin.
Our question is: When it is operating with USRP2, the clock frequency
present on the clock_p pin is 100 MHz? Actually we could not found any
documentation about this signal. We know that there is a reference
frequency divider on USRP2 but nothing is clear to us.

According to the MAX2118 datasheet, the frequency range for the PLL XTAL
input is 4-27 MHz, and then 100 MHz is out of specifications. May be
this is the cause of the higher phase noise.
A partial solution could be to modify the PLL loop filter response to
handle the new reference frequency.

Any ideas or suggestions about how to reduce this phase noise would be
much appreciated.

Attached you can see the phase noise on the FFT plot of a DBSRX + USRP2
captured signal. The test signal is a non-modulated carrier signal
generated by an Agilent signal generator. The frequency was set to
1.57562 GHz, 200 kHz shifted from the GPS L1 center frequency.

Best regards,


   Javier Arribas Lázaro
   PhD Candidate
   Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
   Parc Mediterrani de la Tecnologia (PMT)
   Av. Carl Friedrich Gauss, 7
   Box 08860 - Castelldefels - Barcelona
   Voice: +34 93 645 29 00
   Fax: +34 93.645.29.01
This topic is locked and can not be replied to.