Changing the vctcxo

GNU Radio
1

Hello,

I want to change the clock on the usrp. Anyone know of a mail order
place that would have the right kind of vctcxo at 38.4MHz ? I tried
Digikey and Mouser. no luck.

Thanks,
Hans

2

Hans G. wrote:

I want to change the clock on the usrp. Anyone know of a mail order
place that would have the right kind of vctcxo at 38.4MHz ? I tried
Digikey and Mouser. no luck.

Based on the common frequency table here:

http://www.cardinalxtal.com/common-frequencies.htm

it doesn’t look like it’s going to be easy to find a 38.4 MHz vctcxo.

I just spent a decent amount of time looking for more stable clocks to
replace the onboard TCXO. I found that unless you’re willing to order a
custom TCXO/OCXO (which is expensive and takes a long time), your best
bet is to choose a frequency which is common, and then use one of those
TCXOs. That way, you get the quantity advantage. For example, a 13 MHz
GPS TCXO that’s 0.5 ppm can cost well under $10. (Also, don’t forget you
can multiply the clock up, either using a discrete IC, or some
transistors.)

-Roshan

3

On Thu, Mar 08, 2007 at 02:44:12PM -0800, Hans G. wrote:

Hello,

I want to change the clock on the usrp. Anyone know of a mail order
place that would have the right kind of vctcxo at 38.4MHz ? I tried
Digikey and Mouser. no luck.

Thanks,
Hans

Not sure about where to get them.
Are you sure you need to reclock the USRP?

How about using the rational resampler with N = 3, M = 5?
At the data rates I suspect you’re running at, this shouldn’t be a
problem.

See gnuradio-examples/python/audio/test_resampler.py for an example.
The example is at audio, but it works fine at IF too.

Eric

4

Hi,
Thanks for the replies.

Yes, I have had it working with the rational resampler, but I’m trying
to
eliminate that block. I’m eventually going to use a very low power,
fanless
pc to run the software, so we’re trying to shave off as many cycles as
possible.

I attached an external signal generator at 38.4MHz and decimated by 250
to
get down to a sample rate of 153.6KHz per channel (we use four rx
channels).
This works well, gives the needed bandwidth, and lowers the usb data
rate
down to a minimum. If I can replace the vctcxo for a few dollars and
eliminate this block, then I think it’s worth it.

I just found this one on Digikey:
http://www.abracon.com/Oscillators/ASVTX11.pdf

I’m not an experienced hardware guy, but it looks like it would work in
the
usrp. Please tell me if I’m wrong.

Thanks,
Hans

----- Original Message -----
From: “Eric B.” [email protected]
To: “Hans G.” [email protected]
Cc: “gnuradio mailing list” [email protected]
Sent: Thursday, March 08, 2007 3:25 PM
Subject: Re: [Discuss-gnuradio] changing the vctcxo

5

Eric wrote:

Have you tried using oprofile to determine where the hot-spots are in
the code? http://oprofile.sf.net

In some of our other code we’ve noticed that substantial time is being
consumed computing sin and cos in some NCOs. That’s one of the next
places we’re looking at addressing with some SIMD assembler.

I didn’t know about that tool.

Thanks,
Hans

6

On Thu, Mar 08, 2007 at 04:39:09PM -0800, Hans G. wrote:

I didn’t know about that tool.

Thanks,
Hans

Most GNU/Linux distributions have it packaged.

Eric

7

Hans G. wrote:

I just found this one on Digikey:
http://www.abracon.com/Oscillators/ASVTX11.pdf

I’m not an experienced hardware guy, but it looks like it would work in
the usrp. Please tell me if I’m wrong.

I believe the USRP needs a 3 Vpp clock in, and this TCXO only outputs
0.8 Vpp. Plus, it’s a clipped sine. So you may want to throw it through
a squarer that will bump it up to 0 → 3V before putting it into J2001.
Is this right Matt?

8

On Thu, Mar 08, 2007 at 03:54:15PM -0800, Hans G. wrote:

channels). This works well, gives the needed bandwidth, and lowers the usb
data rate down to a minimum. If I can replace the vctcxo for a few dollars
and eliminate this block, then I think it’s worth it.

Makes sense.

I just found this one on Digikey:
http://www.abracon.com/Oscillators/ASVTX11.pdf

I’m not an experienced hardware guy, but it looks like it would work in the
usrp. Please tell me if I’m wrong.

Thanks,
Hans

Have you tried using oprofile to determine where the hot-spots are in
the code? http://oprofile.sf.net

In some of our other code we’ve noticed that substantial time is being
consumed computing sin and cos in some NCOs. That’s one of the next
places we’re looking at addressing with some SIMD assembler.

Eric

9

Roshan B. wrote:

into J2001. Is this right Matt?
The rev 4 and newer USRPs have a clock generator chip that is spec’ed to
take a signal as low as 150 mV p-p. However in my testing I found I
needed a voltage as high as 8 or 9dBm. 8dBm is about .8V, so that
should still work.

Matt

10

Roshan B. wrote:

http://www.comsec.com/wiki?USRPClockingNotes

You should probably also remove C924, the 0.01 uF cap going to X2 pin 3.

Thanks for figuring this out! I’ve updated the version of the page on
the new wiki:

http://gnuradio.org/trac/wiki/USRPClockingNotes

Matt

11

Matt E. wrote:

The rev 4 and newer USRPs have a clock generator chip that is
spec’ed to
take a signal as low as 150 mV p-p. However in my testing I found I
needed a voltage as high as 8 or 9dBm. 8dBm is about .8V, so that
should still work.

Sorry if this isn’t relevant to everybody on the list, but it is very
important to those of us who are using external clocks with the Rev 4
USRPs.

I tried out varying clock inputs, and verified Matt’s claim that 800 mV
pp was required for consistent USRP operation. This didn’t seem correct
to me, because Analog (who makes the clock distribution chip) normally
is very good about their specifications.

After further testing (and datasheet reading) we discovered two things:

(1) If you’re using an external clock, in addition to the changes
specified under “Rev 4 USRPs - For the Slave Boards” at:

http://www.comsec.com/wiki?USRPClockingNotes

You should probably also remove C924, the 0.01 uF cap going to X2 pin 3.

(2) Because the holes for J2001 come with solder in them, when
soldering/pushing an SMA connector on, it is very easy to break or
mangle the signal trace from J2001 to C927 (and therefore, to U702, the
AD9513 clock distribution IC).

I believe that (2) is why Matt and I noticed a higher input signal
requirement. On my board, with J2001 physically disconnected from C927,
the leakage was enough to send a dirty/noisy clock into U702, which lead
to flakey USRP performance.

However, once we connected the signal pin on J2001 correctly to C927,
and removed C924, the USRP worked flawlessly, even down to 200 mV pp
input.

-Roshan

NB For those EE types, you may wonder why I recommend removing C924.
It’s true that if pin 3 on X2 is DC, leaving C924 in shouldn’t make a
difference. However, removing C924 makes me feel better, because I know
that U702 is completely disconnected from X2, and isn’t affected if pin
3 on X2 changes at all.