On Mon, 19 Sep 2011 03:52:15 +0200
"Peter Krengel" krengeldatec@gmx.de wrote:

The circuit diagram depends on the PLL you use. And what PLL you use
depends on the frequencies, the loop bandwidth and the noise level
of the PLL output you want to accheive.

I'd do i the following way:

1. Get the book "Phase Locked Loops" by R.Best, read at least the
   introductory sections. Come back to this book later, when you've
   selected your PLL and read the relevant sections
2. Get an phase noise plot of your TCXO
3. Define how much oscillator noise at which frequencies your system
   can tollerate
4. Calculate to how much noise at the PLL output this translates
5. Go shopping for a PLL IC that fits your parameters
6. Enter your whole design into Spice and see whether it actally meets your
   requirements or not (be aware that you have to be carefull here, otherwise
   you get a very good random number generator)
7. Build your device
8. Measure it
9. Go back to 1 and refine your circuit.

Though, i must say that i don't see any obvious reason why an high sampling rate ADC should be synced to a Thunderbold. At least not when you have
this high noise requirements (a free running XO has the better noise figure
than a VCXO). On the other hand, your noise requirements cannot be that high,
otherwise you'd be using a high quality OCXO instead of a "cheap" TXCO. ;)

		Attila Kinali

--
Why does it take years to find the answers to
the questions one should have asked long ago?

Peter,

How closely locked to GPS time or frequency does your
TCXO need to be?

Would it be possible for your application to let the 100 MHz
TCXO free-run? Then you could use one or two of the ADC
channels to sample the TBolt 10 MHz and 1PPS leaving all
the rest of the channels to do real work.

This would then give you all the information you need to apply
phase adjustments to your ADC readings as an after-the-fact
software correction. Essentially you get all the benefits of GPS
time tagging and accurate reference frequency along with the
low jitter of your TCXO but without any of the additive noise of
a hardware PLL.

/tvb

Hi Tom,

but of course: Whatever algorithms you put into your after-the-fact
software correction will have an influence similar to a hardware PLL.

{With the added benefit that you can improve your code at your
leisure and re-iterate without having to repeat your data recording.}

If one doesn't want to sacrifice an ADC channel to sample the reference,
I'd suggest going Chuck's route, divide the 100 MHz down to 10 and let
the thunderbolt discipline the 100 MHz TCXO.

But when business gets serious, you can break the loop and put the
Thunderbolt into holdover manually. It will then keep the control input
of the 100 MHz stable but will still measure the phase and frequency
offset with respect to GPS time. You could then use the data recorded
from the thunderbolt to do phase corrections on your sampled data as
suggested.

Chris

Chris,

I'm curious about this. What are the inherent limits of each
approach? One difference comes to mind -- with a software
post-processing solution you get the benefit of being able to
see samples in both the past and future. A hardware PLL
works in real-time with data from the past.

/tvb

Hi Tom,

Christian Vogel vogelchr@vogel.cx:

Tom Van Baak tvb@leapsecond.com:

I have to admit that my comment was backed only by my "gut feeling"
about how I would implement such a post-processing, which
resembles a numerical PLL.

But your question about a non-causal correction/filter/... is a very
interesting one. I think it would be worthwhile to try and find it out
experimentally: Setup a thunderbolt that receives the GPS signal
but is undisciplined. Log both the internally measured PPS offset and
the measured PPS versus a known good reference. Try to find the algorithm
that gives the best estimate of the externally measured PPS offset
from the internally measured (serial port logged) thunderbolt data.

Greetings,

      Chris