64MHz USRP Oscillator

GNU Radio
1

Hi All,

I am having lots of issues with the USRP 64MHz (20ppm) on board
oscillator
which does not allow me to get exact and constant RF frequencies out of
the
RFX900 board. I can not really fix that in SW so I was thinking about
replacing the 64MHz crystal with a more precise one. Has anybody a
suggestion of which part to use?

Thanks in advance!
[WM]

2

Wireless Monster wrote:

Hi All,

I am having lots of issues with the USRP 64MHz (20ppm) on board
oscillator which does not allow me to get exact and constant RF
frequencies out of the RFX900 board. I can not really fix that in SW so
I was thinking about replacing the 64MHz crystal with a more precise
one. Has anybody a suggestion of which part to use?

I have replaced the crystal with the 20ppm crystal, but I was unable to
get an “exact and constant” frequency. I ultimately added a software
PLL to track the clock errors. Before I upgraded my software PLL, I
used a signal generator as an external clock source which worked very
well.

Chris

3

On Wed, Jul 23, 2008 at 5:30 PM, Wireless Monster
[email protected] wrote:

Hi All,

I am having lots of issues with the USRP 64MHz (20ppm) on board oscillator
which does not allow me to get exact and constant RF frequencies out of the
RFX900 board. I can not really fix that in SW so I was thinking about
replacing the 64MHz crystal with a more precise one. Has anybody a
suggestion of which part to use?

These guys seem to make a whole slew of TCXO’s:

http://www.rakon.com/

Maybe they’ll be interested in supplying you with some more precise
crystals?

Brian

4

On Wed, Jul 23, 2008 at 3:57 PM, Chris S.
[email protected] wrote:

I am having lots of issues with the USRP 64MHz (20ppm) on board
oscillator which does not allow me to get exact and constant RF frequencies
out of the RFX900 board. I can not really fix that in SW so I was thinking
about replacing the 64MHz crystal with a more precise one. Has anybody a
suggestion of which part to use?

I have replaced the crystal with the 20ppm crystal, but I was unable to get
an “exact and constant” frequency. I ultimately added a software PLL to
track the clock errors. Before I upgraded my software PLL, I used a signal
generator as an external clock source which worked very well.

Just to reiterate, it’s not physically possible to get “exact and
constant” frequencies in a receiver. This is not a bug. All
realistic radio receivers will have to deal with frequency and phase
offsets. Sometimes you can reduce them to the point where you can
ignore them. Other times, such as in mobile wireless or satellite
communications, Doppler effects will make any existing frequency
stability issues worse.

Decades of research have gone into algorithms one can use on a
receiver to recover the exact carrier phase and frequency of a
received modulated waveform, resulting in many tried and true
engineering solutions. Some these, such as software PLLs as Chris
mentions, are available in GNU Radio for your use.

I believe (ISTR) that there are 5 PPM versions of the crystal on the
USRP that fit the same solder pattern. But that still leaves you with
many KHz of potential offset and drift at 900 MHz, so unless your
chosen modulation can withstand that, you’ll still need to solve the
receiver synchronization problem.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

5

Hi,

Can some one explain in a little bit detail how this software PLL can be
implemented and how this synchronization can be acheived. I am using
RFX2400
and facing same problem.

First I tried to solve the problem by calculating the frequency shift at
receiver end by using usrp_fft.py and then by adding/subtracting that
frequency from RX USRP frequency. But it dont solve the problem.

and secondally I am confused why we dont discuss TX clock which is
128MHz
(true…???), I mean what is the role of that.

Thanks

Johnathan C.-2 wrote:

suggestion of which part to use?
realistic radio receivers will have to deal with frequency and phase

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/64MHz-USRP-Oscillator-tp18621090p18632191.html
Sent from the GnuRadio mailing list archive at Nabble.com.

6

Thanks everyone for your answer!

I understand that some frequency offset will always be there on the Rx
but I would like to minimize it.

However, the main problem on my system is on the Tx path as the
receiver (which I can not modify) is not having any frequency
correction algorithm, so I must Tx as close as possible to the
“expected” frequency.

Rgds,

On Wed, Jul 23, 2008 at 7:34 PM, Konstantin Tarasov

7

By the way, could someone tell me what is the part number of the VCTCXO
shipped with USRP Rev 4.5? In the bill of materials of the trunk I see
“CTX286LVCT-ND”, which seems to correspond to CB3LV-3C-64M0000 in the
manufacturer’s nomenclature.

The datasheet
(http://www.ctscorp.com/components/Datasheets/008-0256-0_E.pdf)
specifies +/- 50 ppm, but I have read somewhere that actually it is +/-
20
ppm.

Which is the right one?

Thanks,
Carles.

8

The one used on USRPs shipping now is 20 ppm with this part number –
EC2620ETTS-64.000M

From Ecliptek. They are pin compatible.

Matt

9

Hi Chris,
Can you briefly explain in what exactly consists the Software PLL?

All,
I’ve been trying to set both Tx and Rx to the same frequency and sending
a
sinusoid to try to measure the frequency offset, but it does not seem to
work… it looks like as both Tx and Rx are driven by the same clock,
the
frequency the offset gets compensated on the Rx signal so it can not be
measured… (???)

Anyone has any clue on how to measure it dynamically at the code
startup?

Thanks in advance!
[WM]

10

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 31, 2008, at 12:15 PM, Wireless Monster wrote:

All,
I’ve been trying to set both Tx and Rx to the same frequency and
sending a sinusoid to try to measure the frequency offset, but it
does not seem to work… it looks like as both Tx and Rx are driven
by the same clock, the frequency the offset gets compensated on the
Rx signal so it can not be measured… (???)

Anyone has any clue on how to measure it dynamically at the code
startup?

You have to measure frequency offset between different crystals –
e.g., 2 USRPs. There’s no way to calculate an absolute. Maybe if you
have the RFX version where each DB has (and uses) its own crystal you
could do this between two DBs on the USRP, but this would still only
be their relative offsets.

  • -Dan
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkiSEOcACgkQy9GYuuMoUJ6nhQCgoOXeqTykV1sj8ClohR/1jjdV
IJYAn1XG433cA2mXEfrGFeA/hcxS3o6h
=n9M9
-----END PGP SIGNATURE-----