Re: [time-nuts] Software Sawtooth correction prerequisites?
Bruce Griffiths wrote:
The Dallas delay lines aren't all that accurate, you need to calibrate
them to acheive 1ns accuracy (read the specs) and then you have to
worry about temperature variations.
To use them you need to decode the sawtooth correction message from
the GPS timing receiver.
If you've decoded this message then you have all the information
needed to make a software correction to the measured phase error.
I need to correct some impressions that seem to have gone astray. To
help me, I refer you to a PowerPoint presentation that I gave to the
technicians and operators at the world's VLBI (Very Long Baseline
Interferometry) sites. The presentation is available at
http://gpstime.com as the 2007 version of "Timing for VLBI".
[Aside -- If you are interested in learning about some of VLBI's
buzz-words, I also gave a tutorial "What's all this VLBI stuff, anyway?"
that was intended as a view of the Physics and Radio Astronomy of making
VLBI measurements. Some people find my de-mystifying of Heisenberg's
Uncertainty Principle interesting -- especially the Schroedinger quotes
at #21. This "plays" best if you view it as a PPT presentation.]
Starting on Slide #20, I describe the reason that the Motorola receivers
have the sawtooth "dither". Basically clock edges of the receiver's 1PPS
pulse are locked to a crystal oscillator in the receiver and that
oscillator is on a frequency that is not neatly commensurate with the
"true" second marks. As has been pointed out in these discussions,
Motorola reports an estimate of the error on the NEXT 1PPS tick. Slides
21 and 22 show some of the pathological example we have seen on typical
receivers. AFAIK, all the bizarre behavior has been traced to firmware
problems.
The reason for making sawtooth corrections (and not simply averaging
multiple samples) can be seen in the "hanging bridges" (22:34 to 22:36
on #22, 01:04:30 to 01:05:30 on #23) when the 1PPS signal went thru a
zero-beat. For these 1-2 minute windows, all statistical averaging
breaks down and typical GPSDO's perform badly. However, when the
sawtooth is corrected in software (blue line on #23) the resulting
"paper clock" is well behaved (at ~1.5 nsec RMS level).
Slides #24 & #25 describe an annoying problem in VLBI -- we want to be
able to blindly trust ANY 1PPS pulse whenever (rarely) we need to reset
the "working" VLBI clock. Slide #26 is the block diagram of the circuit
that Rick has implemented in his newest clock. Slide #29 shows a (more
noisy than normal) comparison between the hardware ans software
correction performance with only 0.3 nsec RMS noise between the two.
Bruce noted a misconception that may have come from our earlier
implementation of the correction algorithm. What we found was that EVERY
sample of the 1 nsec step Dallas/Maxim delay line showed considerably
more scatter.What we found, on closer examination, was that it seems
that the DSI delay line chip defines "one nsec" about 10% differently
than Motorola's "one nsec". After correcting for this "definition"
problem, as you see in #30, the hardware and software correction are in
agreement with an observed regression coefficient of 0.9962 (on this
sample, which shows correlation coefficient > 0.999) and good tracking
between samples.
Bruce also made some disparaging comments on the stability of the delay
lone. I can say that we have not seen any stability problems at all.
This is quite logical when you carefully reverse engineer the DSI chip
based on its data sheets. The delay inside the chip is really an analog
delay. The 8-bit number you sent to the chip programs a D/A converter to
produce a (256 step) constant current source. When the input pulse is
applied to the DSI delay line, the constant current charges an on-chip
capacitor. When the resulting ramp matches the level defined by a
comparator, the output is changed. The comparator level and capacitor
value are temperature compensated by a second, fixed rate ramp. This is
pretty much the same thing that you all have been described here.
The place where I suspect that there may be some temperature sensitivity
is in the modular GPS receivers. If you look at my slide #19 from late
2000, the really great "Never Happened" receiver had to be temperature
controlled (to ~ 1ºC), otherwise it showed diurnal room temperature
variations. All these receivers have a bandpass filter with ~1.8 MHz
wide somewhere in their IF chain; this filter's bandwidth is matched to
the 1.023 MHz C/A code chip rate that is the root of the timing
performance. Heisenberg would argue that a filter this wide will show a
group delay ~500 nsec and it is often implemented as a SAW (Surface
Acoustic Wave) device at an IF in the 50-200 MHz range. This is a
measurement topic itching for some work! Regarding the SAW filters, on
slide #33 you will see that the 4 M12+ receivers that Rick tested at
USNO fell into two groups with ~4-5 nsec "DC" timing difference between
them.You will also note on #36 that the one sample of the new iLotus
M12M that I've seen has ~30 nsec of bias.
Why add the cost of a programmable delay line when the additional cost
of correction is a few lines of code?
They also don't remove the requirement for subnanosecond phase
measurement resolution and accuracy.
But the receiver itself has intrinsic noise at the nsec level. You are
better off by averaging sawtooth corrected (either hardware or software)
measurements to achieve sub-nsec precision; IMHO, sub-nsec individual
measurements aren't needed. Surely you don't plan to tweak a GPSDO every
second! A good xtal is much better than ANY GPS rcvr on times of 1-100 sec.
Whilst an analog phase lock loop can have the necessary resolution
they are somewhat impractical for the relatively long averaging times
required when optimally disciplining a good OCXO.
The computational load isnt that severe as you only make one phase
measurement per second.
One of the simplest ways of achieving subnanosecond phase measurement
resolution is to feed a quadrature phase 10MHz sinewave into a pair of
simultaneous sampling ADCs (MAXIM have suitable devices prices seem
reasonable). The sinewaves are sampled at the leading edge of the GPS
receiver PPS signal.
The ADC outputs can then be used to determine where in the cycle the
PPS edge occurred. This in effect is a subnanosecond resolution phase
detector with a range of 100nsec. The range can easily be extended by
using a small CPLD which incorporates a couple of synchronisers (one
clocked by the positive slope transition of the 10MHz signal and the
other clocked by the negative slope xero crossing transition of the
10MHz signal) The output of both synchronisers samples the value of a
synchronous counter which is clocked by the positive slope zero
crossing of the 10MHz sinewave. Software then sorts out which latched
count is most reliable (the synchroniser whose clock edge is furthest
from the PPS transition). This sounds complex but it isnt, especially
if you select the right PIC (or other micro) with built in counters
(PIC18F4550?) that can be sampled by an external transition (output of
a synchroniser). The counter need only be an 8 bits counter.
This sure sounds like a more complicated measurement than is necessary
to me. If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
Another technique is to start a ramp on the leading edge of the PPS
signal from the GPS receiver and stop it at the corresponding output
transition of a synchroniser (clocked at 10MHz) whose output samples
an (8bit) counter (also clocked at 10MHz - your local OCXO standards
frequency). The final value of the ramp is sampled by an ADC and
combined with the sampled count to resolve the 1 count ambiguity at
the synchroniser output. The ramp is then reset for the next PPS
pulse. Calibration of the ramp generator is required but calibration
cycles are easily interleaved between PPS pulses.
Although it may seem that a fast opamp is required for the ramp
generator, this isnt so as you can wait for any opamp (and/or ADC
input) to settle to before sampling the ramp output.
With careful design curvature correction isn't required (don't
slavishly copy the Linear technology Application note, you can do
better with less). The ramp generator needs a range of 300ns or
greater with a 10MHz synchroniser clock. A 10-12 bit ADC will provide
subnanosecond resolution. The ADC need not be fast (10us per
conversion is adequate), however a sigma delta ADC is unsuitable.
This also strikes me as a more complicated implementation than is
needed. But then, I prefer beer and white zinfandel wine too.
I hope these comments helped a bit -- 73, Tom
Tom Clark, K3IO wrote:
Bruce Griffiths wrote:
The Dallas delay lines aren't all that accurate, you need to calibrate
them to acheive 1ns accuracy (read the specs) and then you have to
worry about temperature variations.
To use them you need to decode the sawtooth correction message from
the GPS timing receiver.
If you've decoded this message then you have all the information
needed to make a software correction to the measured phase error.
I need to correct some impressions that seem to have gone astray. To
help me, I refer you to a PowerPoint presentation that I gave to the
technicians and operators at the world's VLBI (Very Long Baseline
Interferometry) sites. The presentation is available at
http://gpstime.com as the 2007 version of "Timing for VLBI".
[Aside -- If you are interested in learning about some of VLBI's
buzz-words, I also gave a tutorial "What's all this VLBI stuff, anyway?"
that was intended as a view of the Physics and Radio Astronomy of making
VLBI measurements. Some people find my de-mystifying of Heisenberg's
Uncertainty Principle interesting -- especially the Schroedinger quotes
at #21. This "plays" best if you view it as a PPT presentation.]
Starting on Slide #20, I describe the reason that the Motorola receivers
have the sawtooth "dither". Basically clock edges of the receiver's 1PPS
pulse are locked to a crystal oscillator in the receiver and that
oscillator is on a frequency that is not neatly commensurate with the
"true" second marks. As has been pointed out in these discussions,
Motorola reports an estimate of the error on the NEXT 1PPS tick. Slides
21 and 22 show some of the pathological example we have seen on typical
receivers. AFAIK, all the bizarre behavior has been traced to firmware
problems.
The reason for making sawtooth corrections (and not simply averaging
multiple samples) can be seen in the "hanging bridges" (22:34 to 22:36
on #22, 01:04:30 to 01:05:30 on #23) when the 1PPS signal went thru a
zero-beat. For these 1-2 minute windows, all statistical averaging
breaks down and typical GPSDO's perform badly. However, when the
sawtooth is corrected in software (blue line on #23) the resulting
"paper clock" is well behaved (at ~1.5 nsec RMS level).
Slides #24 & #25 describe an annoying problem in VLBI -- we want to be
able to blindly trust ANY 1PPS pulse whenever (rarely) we need to reset
the "working" VLBI clock. Slide #26 is the block diagram of the circuit
that Rick has implemented in his newest clock. Slide #29 shows a (more
noisy than normal) comparison between the hardware ans software
correction performance with only 0.3 nsec RMS noise between the two.
Bruce noted a misconception that may have come from our earlier
implementation of the correction algorithm. What we found was that EVERY
sample of the 1 nsec step Dallas/Maxim delay line showed considerably
more scatter.What we found, on closer examination, was that it seems
that the DSI delay line chip defines "one nsec" about 10% differently
than Motorola's "one nsec". After correcting for this "definition"
problem, as you see in #30, the hardware and software correction are in
agreement with an observed regression coefficient of 0.9962 (on this
sample, which shows correlation coefficient > 0.999) and good tracking
between samples.
Bruce also made some disparaging comments on the stability of the delay
lone. I can say that we have not seen any stability problems at all.
This is quite logical when you carefully reverse engineer the DSI chip
based on its data sheets. The delay inside the chip is really an analog
delay. The 8-bit number you sent to the chip programs a D/A converter to
produce a (256 step) constant current source. When the input pulse is
applied to the DSI delay line, the constant current charges an on-chip
capacitor. When the resulting ramp matches the level defined by a
comparator, the output is changed. The comparator level and capacitor
value are temperature compensated by a second, fixed rate ramp. This is
pretty much the same thing that you all have been described here.
I know exactly how these delay devices work, the problem is that using
them in this way relies on a one time calibration of the device delays,
it would be far better if delay calibration cycles could be interspersed
between PPS transitions. This would technique would cope with any ageing
or temperature drifts. The variable slope technique (see Dallas
application note AN107) for setting the delays used in these devices
means that the delay jitter increases faster with increasing delay than
in the equivalent fixed slope variable threshold ramp timed delay
technique. The DS1020 -15-datasheet specifies a 4ns max deviation from
the programmed delay. There is no statement on the datasheet as to if
this error is due to scale factor error, offset error or integral
linearity error or differential linearity error. If one doesn't
calibrate each individual chip how can one relay on achieving a delay
accurate to within 1ns? The datasheet certainly gives one no confidence
that this is indeed possible. Surely one cannot rely on the manufacturer
achieving significantly better specifications than the specified
datasheet limits for every chip produced?
The place where I suspect that there may be some temperature sensitivity
is in the modular GPS receivers. If you look at my slide #19 from late
2000, the really great "Never Happened" receiver had to be temperature
controlled (to ~ 1ºC), otherwise it showed diurnal room temperature
variations. All these receivers have a bandpass filter with ~1.8 MHz
wide somewhere in their IF chain; this filter's bandwidth is matched to
the 1.023 MHz C/A code chip rate that is the root of the timing
performance. Heisenberg would argue that a filter this wide will show a
group delay ~500 nsec and it is often implemented as a SAW (Surface
Acoustic Wave) device at an IF in the 50-200 MHz range. This is a
measurement topic itching for some work! Regarding the SAW filters, on
slide #33 you will see that the 4 M12+ receivers that Rick tested at
USNO fell into two groups with ~4-5 nsec "DC" timing difference between
them.You will also note on #36 that the one sample of the new iLotus
M12M that I've seen has ~30 nsec of bias.
There are receivers installations where everything from and including
the antenna, the coax connecting the receiver to the receiver, and the
receiver itself are temperature controlled.
The variation in the group delay of the ceramic bandpass filters
typically used in timing antennas may be problematic, it would be nice
if there were specifications/measurements for these.
Bruce
Tom
Tom Clark, K3IO wrote:
Why add the cost of a programmable delay line when the additional cost
of correction is a few lines of code?
They also don't remove the requirement for subnanosecond phase
measurement resolution and accuracy.
But the receiver itself has intrinsic noise at the nsec level. You are
better off by averaging sawtooth corrected (either hardware or software)
measurements to achieve sub-nsec precision; IMHO, sub-nsec individual
measurements aren't needed. Surely you don't plan to tweak a GPSDO every
second! A good xtal is much better than ANY GPS rcvr on times of 1-100 sec.
Whilst an analog phase lock loop can have the necessary resolution
they are somewhat impractical for the relatively long averaging times
required when optimally disciplining a good OCXO.
The computational load isnt that severe as you only make one phase
measurement per second.
One of the simplest ways of achieving subnanosecond phase measurement
resolution is to feed a quadrature phase 10MHz sinewave into a pair of
simultaneous sampling ADCs (MAXIM have suitable devices prices seem
reasonable). The sinewaves are sampled at the leading edge of the GPS
receiver PPS signal.
The ADC outputs can then be used to determine where in the cycle the
PPS edge occurred. This in effect is a subnanosecond resolution phase
detector with a range of 100nsec. The range can easily be extended by
using a small CPLD which incorporates a couple of synchronisers (one
clocked by the positive slope transition of the 10MHz signal and the
other clocked by the negative slope xero crossing transition of the
10MHz signal) The output of both synchronisers samples the value of a
synchronous counter which is clocked by the positive slope zero
crossing of the 10MHz sinewave. Software then sorts out which latched
count is most reliable (the synchroniser whose clock edge is furthest
from the PPS transition). This sounds complex but it isnt, especially
if you select the right PIC (or other micro) with built in counters
(PIC18F4550?) that can be sampled by an external transition (output of
a synchroniser). The counter need only be an 8 bits counter.
This sure sounds like a more complicated measurement than is necessary
to me. If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
Very nice technique, much better to make use of the receiver noise if
you can.
In this case hardware correction of the PPS error is of course essential.
In essence this technique implements a servo with a narrow proportional
band of a few nanoseconds the width of the proportional band being
determined by the corrected PPS signal noise characteristics.
Outside the proportional band the servo saturates but retains the sign
of the phase error.
As the noise of the receiver increases so does the width of the
proportional band.
How then does one then actually measure the receiver timing noise, if
one wishes to detect when it deteriorates to a point where it is prudent
to go into holdover mode?
Perhaps a chain of (3) flipflops whose D inputs are driven by the OCXO
derived (10MHz, IMHz, etc) frequency and the clock inputs of which are
driven by successively delayed (stable delay) versions of the PPS edge.
For example the first flipflop is clocked by the PPS edge, the second
fliflop is clocked by the PPS edge delayed by say T ns, and the third
flipflop is clocked by PPS delayed by 2T ns.
Follow these flipflops by a set of synchronisers. Lock the OCXO so that
the 2nd Flipflop has 50% probability of being either 1 or 0. The
probability of occurrence of say a logic 1 at the outputs of the other
first and third flipflops can then be used to monitor the receiver
timing noise level. Alternatively the D inputs to the flipflops could be
successively delayeed by T ns whilst all flipflops are clocked by the
PPS signal.
Surely it would be better to use a synchroniser and/or a flipflop/latch
with extremely short regeneration time constant to ensure that the
probability of metastable states is insignificant.
In this case subsequent stages of the synchroniser could be clocked by
delayed (fixed non critical delay) versions of the PPS transition as
waiting several seconds for a particular decision to propagate to the
output of the synchroniser if each synchroniser stage (D flipflop ) is
clocked by the PPS signal may be undesirable. Although a 2 or 3 stage
PPS clocked synchroniser would only have a delay of 3 seconds or so.
Using a 2 stage PPS clocked synchroniser should make the metastable
state probability at the output of the second flipflop insignificant
even if one used relatively slow HCMOS.
The question of the effect of any asymmetry of the decision statistics
of the first flipflop remains.
Since the PPS edge is being adjusted so that it has a high probability
of occurring within a few nanoseconds of the OCXO clock edge the
standard formula for calculating the metastability characteristics
doesn't apply the effective frequency of the 10MHz clock is in effect
much higher (200MHz??) for the purposes of metastability calculations.
Instead of using such a fudge factor its better perhaps to use a more
fundamental analysis to determine the metastable state probability a
little more accurately.
There is little enough information available on the metastability
characteristics of particular flipflops let alone the symmetry of the
decision characteristics.
However one should remember that even ADC's (particularly flash ADCs)
exhibit "sparkle" codes so they are not immune to metastability effects.
It may still be necessary to have some way of detecting "missing" PPS
pulses.
Another technique is to start a ramp on the leading edge of the PPS
signal from the GPS receiver and stop it at the corresponding output
transition of a synchroniser (clocked at 10MHz) whose output samples
an (8bit) counter (also clocked at 10MHz - your local OCXO standards
frequency). The final value of the ramp is sampled by an ADC and
combined with the sampled count to resolve the 1 count ambiguity at
the synchroniser output. The ramp is then reset for the next PPS
pulse. Calibration of the ramp generator is required but calibration
cycles are easily interleaved between PPS pulses.
Although it may seem that a fast opamp is required for the ramp
generator, this isnt so as you can wait for any opamp (and/or ADC
input) to settle to before sampling the ramp output.
With careful design curvature correction isn't required (don't
slavishly copy the Linear technology Application note, you can do
better with less). The ramp generator needs a range of 300ns or
greater with a 10MHz synchroniser clock. A 10-12 bit ADC will provide
subnanosecond resolution. The ADC need not be fast (10us per
conversion is adequate), however a sigma delta ADC is unsuitable.
This also strikes me as a more complicated implementation than is
needed. But then, I prefer beer and white zinfandel wine too.
I hope these comments helped a bit -- 73, Tom
Bruce
Tom Clark, K3IO wrote:
If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
Tom
How does one do robust statistical filtering of outliers when one uses
this technique??
Bruce
I hope these comments helped a bit -- 73, Tom
This sure sounds like a more complicated measurement than is necessary
to me. If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
This sounds really simple and irresistible. Have you or Rick
tried it out? I see instead of a TIC (Time Interval Counter)
you have a TAC (Time Average Controller ;-)
Not just GPS 1PPS noise but any oscillator noise (jitter), if
large enough, is also a source of natural dither. Sounds like
this design would be especially ideal for a low-end GPSDO;
i.e., one that only needs to be accurate to 10^-9 or 10^-10.
Did you envision that the OCXO EFC would be driven by a
statistics-collecting microprocessor and a high-resolution
DAC? Or is there some clever way to tie statistical results
of the D-latch to the EFC and avoid the DAC too?
/tvb
The statement that Dallas' version of the nanosecond differs by 10% from
Motorola's is somewhat disconcerting until one analyses how the delay
generator works.
Simplified description
Aside from the contribution from internal logic propagation delays
Delay = Constant*RC,
Where R is the value of a resistor that determines the current used to
charge a capacitor and the constant is determined by resistor ratios.
Thus a naive implementation may use 256 equal resistors (r) connected in
series with a set of switches used to select the the required
resistance value (Nr) in 256 nominally equal steps.
The delay would then be proportional to N.
Unfortunately the ramp slope would vary over a range of 256 to 1 as
would the current. The current mirror used in the actual circuit may
have some dificulty in operating accurately over a current range of
256:1. Also the power dissipation in some of the resistors in the string
would vary over a large range. The large range (256:1) in the ramp slew
rate seen by the comparator would lead to significant variations in the
comparator delay. Fortunately if the effective value of the resistor
corresponding to N=0 is made somewhat larger (=Ro) than r then although
the N=0 delay will increased, the range of currents seen by the current
mirror and the corresponding slew rates seen by the comparator can be
reduced significantly improving the performance and reducing the
variation in resistor dissipation. This implementation should be
inherently monotonic despite variations in r and Ro. The effective RC
product and the corresponding delay can be designed to have a low
temperature coefficient. The RC product will vary from lot to lot and
this variation can be compensated by resistor trimming. There are other
schemes other than a series resistor string that can be used, however
most of these are not inherently monotonic and resistor trimming to
correct this error as well as the scale error may be necessary.
The attached plot of the error of a typical DS1020-15 illustrates that
the integral non linearity of the delay may amount to several
nanoseconds worst case.
This indicates that if one uses say 30ns of the range to correct for the
sawtooth error of an M12M or equivalent GPS timing receiver, that a
typical correction error due to the intergral non linearity of the
DS1020-15 may be as large as 1ns. However this can be reduced
significantly by calibration or perhaps by just calibrating the gain.
However unless an actual calibration or parameter fitting to a more
elaborate model for the INL other than just a change of scale factor the
specified data sheet maximum value for the delay it is unlikely that a
mere adjustment of the scale factor will ensure that the delay error of
every DS1021-15 that meets its datasheet specification will be less than
1 nanosecond. The optimum scale factor may also vary from wafer to wafer
as well as within the wafer.
Thus whilst it is highly likely that calibrating the delay and using a
lookup table or a model for the INL using several adjustable parameters
will allow a programmed delay error of under 1ns, it is unlikely that
merely adjusting the "gain" will reduce the programmed delay error to
under 1ns for all DS1021-15s ever produced that meet the datasheet
specifications.
More detailed
Tom Van Baak wrote:
This sure sounds like a more complicated measurement than is necessary
to me. If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
This sounds really simple and irresistible. Have you or Rick
tried it out? I see instead of a TIC (Time Interval Counter)
you have a TAC (Time Average Controller ;-)
Not just GPS 1PPS noise but any oscillator noise (jitter), if
large enough, is also a source of natural dither. Sounds like
this design would be especially ideal for a low-end GPSDO;
i.e., one that only needs to be accurate to 10^-9 or 10^-10.
Did you envision that the OCXO EFC would be driven by a
statistics-collecting microprocessor and a high-resolution
DAC? Or is there some clever way to tie statistical results
of the D-latch to the EFC and avoid the DAC too?
/tvb
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Tom
A D flipflop is a better choice than a transparent latch.
If the PPS signal also interrupts the micro, the built in interrupt
synchroniser will ensure sufficient delay that when the output of the D
flipflop is sampled the probability of its output being in a metastable
state will be extremely low particularly if a 74AC74 or faster flipflop
is employed.
Bruce
Tom Van Baak wrote:
This sure sounds like a more complicated measurement than is necessary
to me. If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
This sounds really simple and irresistible. Have you or Rick
tried it out? I see instead of a TIC (Time Interval Counter)
you have a TAC (Time Average Controller ;-)
Not just GPS 1PPS noise but any oscillator noise (jitter), if
large enough, is also a source of natural dither. Sounds like
this design would be especially ideal for a low-end GPSDO;
i.e., one that only needs to be accurate to 10^-9 or 10^-10.
Did you envision that the OCXO EFC would be driven by a
statistics-collecting microprocessor and a high-resolution
DAC? Or is there some clever way to tie statistical results
of the D-latch to the EFC and avoid the DAC too?
/tvb
Tom
Perhaps a software implementation of a 1 bit oversampled DAC the 1 bit
output of which is low pass filtered to control the EFC input is the
closest approach to this ideal.
With an appropriate algorithm the idle tone and inherent instability
problems (of high order modulators - 3rd or higher order) of the sigma
delta modulator will not occur.
An oversampling ratio of 1000 - 10000 should readily be possible
together with a resolution of 24 bits or more with low gain and offset
tempcos together with a monotonic transfer function. A low integral non
linearity isn't necessary as the EFC control input transfer function
typically isnt that linear. Relaxing the integral linearity spec
simplifies the design considerably. A 1 bit output also simplifies
isolation (either optical or chip scale transformer isolation??) of the
DAC from the processor should this be required.
Bruce
Just to clarify, credit for the clever D-latch idea goes to a posting
by the other Tom (Dr Tom Clark), not me.
Tom Clark, K3IO wrote (on May 11, 2007):
This sure sounds like a more complicated measurement than is necessary
to me. If you have a 10 MHz oscillator, simply feed it into the "D"
input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of
the latch is a 0 or 1 depending on the precise phase of the oscillator.
You want this latched 0/1 measurement to average to ½ over a long term
(seconds). As the statistics deviate from a 50/50 split, you tweak the
oscillator. The ~1 nsec of residual noise from the sawtooth corrected
GPS rcvr acts a natural dither. No counters, no ramps, no big A/D
converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase
ambiguity) is too fine for your oscillator, then divide it to 5 MHz
(=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in
a xtal that is off by 1:10e6.
Tom Van Baak (tvb) replied:
This sounds really simple and irresistible. Have you or Rick
tried it out? I see instead of a TIC (Time Interval Counter)
you have a TAC (Time Average Controller ;-)
Not just GPS 1PPS noise but any oscillator noise (jitter), if
large enough, is also a source of natural dither. Sounds like
this design would be especially ideal for a low-end GPSDO;
i.e., one that only needs to be accurate to 10^-9 or 10^-10.
Did you envision that the OCXO EFC would be driven by a
statistics-collecting microprocessor and a high-resolution
DAC? Or is there some clever way to tie statistical results
of the D-latch to the EFC and avoid the DAC too?
/tvb
On Jul 24, 2007, at 1:32, Dr Bruce Griffiths wrote:
Perhaps a software implementation of a 1 bit oversampled DAC the 1 bit
output of which is low pass filtered to control the EFC input is the
closest approach to this ideal.
With an appropriate algorithm the idle tone and inherent instability
problems (of high order modulators - 3rd or higher order) of the sigma
delta modulator will not occur.
It is easy to design stable sigma delta converters of orders higher
than two. I have calculated a 7th order ADC which is implemented on
silicon and stable of coarse. A 11th order sigma delta with
oversampling ratio 128 is stable in simulation and has 228dB snr.
{This is no typo two hundred and twenty eight dB)
Higher order sigma delta converter require higher order
reconstruction filters but it is easy to design for more bandwidth
than needed and so to relax the filter spec.
Henk