[time-nuts] Switching oscillators

Bob Camp lists at rtty.us
Sun Dec 9 22:31:08 UTC 2012


I think the idea is to run the TCXO while the OCXO is > 1 ppm off frequency and then switch to the OCXO when it's sure to be OK. Most inexpensive approaches to locking the TCXO will give you a pretty major frequency transient. Depending on what you are doing, that may muck things up as much as a dropout. 


On Dec 9, 2012, at 5:25 PM, Magnus Danielson <magnus at rubidium.dyndns.org> wrote:

> Hi Joseph,
> On 12/09/2012 10:53 PM, Joseph Gray wrote:
>> The finished project will be placed where I won't have regular access
>> to it, so I think I have justification for wanting this complication.
>> Also, I want to monitor which oscillator is in use, so my application
>> will know.
> First reaction would be to lock the TCXO to the OCXO. It's not that hard to make a PLL which will start acting only when the OCXO is "ready" (oven detection could be part of it).
> Another approach than direct PLL locking could be to use injection locking, but designing for it could be challenging.
> Switching a clock is a bit sensitive, but one solution to achieve it is to lock the OCXO to the TCXO when the OCXO comes around, and only when that PLL has lock, then switch between them and just let the lock state fade out on the OCXO control, as you kill the control loop.
> A few ideas. I don't like switching of clocks, so I would avoid that if possible, even if precaution to make sure they are locked to be phase-aligned. I would go for the lock-up of the TCXO. Make sure that the lock-in does not upset any of the measurements, possibly by making the lock-in a little "weak" so the maximum rate of change isn't too great.
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list