[time-nuts] Metastability in a 100 MHz TIC
magnus at rubidium.dyndns.org
Fri Jul 20 20:55:58 EDT 2007
From: "Tom Van Baak" <tvb at LeapSecond.com>
Subject: Re: [time-nuts] Metastability in a 100 MHz TIC
Date: Fri, 20 Jul 2007 17:10:45 -0700
Message-ID: <00fe01c7cb2b$95ca8be0$0300a8c0 at pc52>
> ); SAEximRunCond expanded to false
> Errors-To: time-nuts-bounces+magnus=rubidium.dyndns.org+magnus=rubidium.dyndns.org at febo.com
> I like your point about the random quantization error in the
> sawtooth. Yes, that would help the noise by a few dB.
Certainly. Rather, it is a mostly uncorrelated signal rather than random, but
the effect is the same never the less.
> On the other hand it would also seem the 10 ns resolution
> of the TIC is the limiting factor (by an order of magnitude)
> over the 1 ns resolution limit of the sawtooth corrections,
> so improving the quality of the sawtooth corrections has
> limited gain.
I was thinking the same thing.
> Now, I'd still like to pursue the issue of noise in the 100 MHz
> oscillator. Do we agree one doesn't need a cesium for this?
> Or even an XO?
The TIC only needs a low tau for the range of time on which we depend on it,
which is up to 1 second, which is the maximum time between two PPS signals.
A TIC which does move around will cause small scale errors, but since we have
fairly good sources we can avoid that problem by having the TIC use one of
those. But the TIC does not need to have very good ADEV at tau = 10 ks or
100 ks, it should just not be so high that the scale error grows to high to
cause a problem. So, in practice I agree with you, but the ADEV values does
have an effect even over there in the ADEV spectra, it is just that they work
> True, you want some accuracy in the 100 MHz. But the counts
> are only integers from 0 to 160 so the accuracy requirement
> is just 3 digits, 0.1% (so cheap quartz, at 1e-6, or cesium, at
> 1e-13, is extreme overkill). I mean, almost anything wiggling at
> 100.0 MHz will serve as an adequate timebase.
LC Colpit oscillator should be able to do it. :)
> Also, as you point out, instability or jitter is your friend, not
> your enemy in this case. Would it be possible to introduce
> the +/- 5 ns jitter deliberately in the 1pps trigger level instead
> of in the timebase? I.e., slow down the rising edge enough
> so that you get jitter for free?
We know that we want an increment of 10, so a simple BCD counter setup with a
simple resistor-DAC setup creating a sawtooth which ads ontop of the PPS with
the same amplitude should be able to do the trick. Clocked with the PPS, so
we will not need blitzing speed here. HC should do just fine.
The two-minute averaging should work out very nicely with that. The resolution
would not actually improve, but the hanging bridges would, so you would get the
10/120 ns resolution.
> Another solution might be to deliberately choose an inaccurate
> and unstable oscillator; use the 1pps to count oscillator cycles
> per second, as well as to count the time interval. The larger
> count can be used to calibrate the smaller count on every count.
> This gives all the jitter you need and avoids any injection issues.
> While you're at it, how about N of these oscillators, each making
> its own out of phase measurement of the same OCXO-GPS 1pps.
> Another couple of dB of resolution...
Even very simple interpolating schemes would give much better resolution for
less buck. An improvement of 1 or 2 decades comes very cheaply. Just look at
the HP 5335A for instance. It has 1 ns resolution couting everything except
events in 10 MHz. The interpolators gives a gain of 200.
More information about the time-nuts