Using Oven Controlled Crystal Oscillator instead of TCXO

Has anyone tried using an OCXO instead of a TCXO? We recently made changes to our design by changing the VDDBAT pin to 3.0 volts and running the TCXO off 3.0v and got impressive improvement. We have an engineering manager who wants to know if Decawave performance can be further improved with even lower phase noise. To check that out I propose to use a 38.4 MHz OCXO which typically has 10 - 20 dB less phase noise at close-in frequencies than the TCXO’s currently proposed by Decawave. And of course, uses 200 or 300 times more current.
It’s hard to find a 3.0 volt OCXO but there’s no shortage of 3.3 volt parts. Also, none of them seem to have the usual 0.8 volt clipped outputs - they’re more likely to be a CMOS-type output. Does anyone have any suggestions about integrating the OCXO into a Decawave (using a daughter board for now) in a way that keeps the VDDBAT pin and the 38.4 MHz input pins happy? Thank you
Also, is there a possibility of diminishing returns by going to very low phase noise devices?
regards,
Bob

We have not done so, but it would be handled the same way as a TCXO setup per the Decawave guidance.

What we have done is use a synthesizer that had a time base using an OCXO to drive a 38.4 MHz signal into the DW1000. Given the synthesizer, it isn’t clear the phase noise was improved this way, but it did allow us to perform various experiments in carrier shifting. The performance was similar to TCXO in terms of stability, range, time performance. I don’t recall the phase noise spec on the instrument.

If that was improvement in location accuracy, then that can happen.

If it was improvement in reception range, this suggests you are not managing XTAL_TRIM properly to have nodes track towards a common frequency. Anything within +/- 2 ppm gets you all the range that can be had as far as we can tell.

Probably.

The modern TCXO is really a series of piece wise adjustments that introduce various subtle phase shifts as the temperature moves. This can actually make a system worse depending on the TCXO behavior.

The OCXO is not like that, keeping the crystal at a fixed temperature results in a fixed frequency. This is the best stability one can get without getting wildly exotic (GPS DO, atomic clock, etc).

Note that the OCXO takes some time to stabilize, minutes in many cases, so it isn’t ready right at power up.

I’d be very interested in your experiments so please post results when you have them.

VDDBAT needs to be LDO filtered to remain noise free. 3.0 volts is a good choice.

XTAL1 input needs 0.8 to about 1.5 volts for optimal results. To reduce noise, a CMOS square wave is not great, prefer more of a sine (what the crystal provides) or clipped sine (what most TCXOs do). A simple way to do this is a passive low pass filter consisting of RLC section with roll off about 35 MHz. This will both “sine up” the signal, and reduce it amplitude from 3.3 volts if a CMOS source. Don’t forget to DC block the signal into XTAL1.

Be sure to do a CW test with any new clock setup. If you aren’t getting a good CW test (spurs -30 dBc or less, say), then you have to fix that first. Very subtle errors in clock signal and voltages can create lots of weird behavior in the system.

It is an area we have not delved into. My expectation is that it would be a VERY unusual system where the OCXO is advantageous with regard to the cost, power, size issues it presents.

Mike Ciholas, President, Ciholas, Inc
3700 Bell Road, Newburgh, IN 47630 USA
mikec@ciholas.com
+1 812 962 9408

We installed a Rakon ROM9070PA 38.4 MHz Oven Controlled Crystal Oscillator in each of two Decawave modules. Compared to the current NDK TCXO, the OCXO noise is 22 dB better at 1 kHz offset and 9 db better at 10 kHz offset.
There was no change in the useful range of the DW modules.
regards,
Bob