[time-nuts] TIC resolution impact on GPSDO's performance

Dr Bruce Griffiths bruce.griffiths at xtra.co.nz
Sun Dec 24 17:10:46 EST 2006

Ulrich Bangert wrote:
> Hi folks,
> I am starting a new thread because this topic ist still discussed very
> controversial. I hope this posting helps to get more insight. What
> follows is by no means to be understood as an act of personal
> aggression. Nevertheless I will phrase my point of view as clear as
> possible. I suggest that you have a look at the attached pdf now.
> First obey the dotted blue line. This is the Allan plot for a HP10811
> OCXO as a typical example for what a lot of us have at hand. The
> undotted blue line indicates the lowest ADEV that is reached anywhere
> between 10 and 1000 s. 
> While it is not necessary for the understanding of the further
> discussion you might want to know WHY the Allan plot has this banana
> like looking: Within an oscillator an number of DIFFERENT noise
> processes are active and play a part in the overall noise that the
> oscillator emits. Some of these processes have the property that they
> tend to cancel themselves a bit when averaged over a certain time,
> others do not. The minimum of the ADEV must be considered as being
> located at the averaging time where further averaging leeds to no more
> improvement in noise and where the other noise processes (mainly
> environmental sesibilities) that do not tend to cancel start to overrule
> the scene. 
> While the Allan plots of different OCXOs are not identical they look all
> very similar. My FTS1200 may start at 1E-12 @ 1 s and be in the range of
> some parts in 1E-13 up to 1000 s. Also its ascending slope is not as
> steep as the HP's one. Nevertheless it looks pretty similar. In contrast
> to that the Allan plot of a simple xtal oscillator is also a banana but
> may be located 4 orders of magnitude above the HP's one.
> Now look to the yellow line. This is the Allan plot for a Motorola M12+
> receiver if we squeeze ALL available time information out of it, i.e.
> when we apply the sawtooth correction value to the 1pps. The plot starts
> at 2E-9 @ 1 s and has a slope which is little bit smaller in magnitude
> than -1. 
> Note one thing: The sawtooth correction value of the M12+ is an integer
> multiple of 1 nanosecond. To make full use of this 1 ns correction
> resolution it should be clear that we need to measure the receivers's 1
> pps with at least the same resolution. Bruce has already pointed out a
> number of times that if we want to neglect the influence of sheer
> resolution at all at this point even a few ps timing resolution need not
> be considered an overshot. 
To avoid some of the nasty effects of coherence and quantisation it is 
useful to add noise to smooth out the effects of quantisation and reduce 
the bias when averaging (exponentially weighted average or otherwise). 
However such noise reduces the phase measurement accuracy. The smaller 
the quantisation step the less noise is required until eventually the 
receiver noise alone may be sufficient. The uncorrected sawtooth timing 
error of the receiver PPS output is not sufficiently noise like to be 
used instead of  bandlimited gaussian timing noise with the appropriate 
> Clearly we see the crossing point with the OCXO's Allan plot located
> between 1000 and 2000 s. Although I have already stressed it a lot in
> the last days let us consider again what needs to be done it we are
> going to marry this receiver with this OCXO in a GPSDO. What would
> happen when we set the regulation loop's time constant to say 100 s?
> Setting the loop time constant to a certain value means as much as:
> Starting from that time the receiver more and more overrules the OCXO. 
> But then: At 100 s the ADEV of the receiver is more than an order of
> magnitude worse than that of the OCXO ALONE! If we allow the receiver to
> overrule the OCXO at a loop time constant of 100 s the Allan plot for
> the OUTPUT of the frequency standard at 100 s will be dominated by the
> receiver which will give us an inferior result than if it were dominated
> by the OCXO! 100 s is not a good loop time constant! 
> Whats the story with a loop time constant of say 10000 s? The
> argumentation is pretty much the same as for 100 s but with a role
> reversal between receiver and OCXO. For the 10000 s the OCXO's ADEV is
> an order of magnitude worse that that of the receiver. If we allow the
> receiver to enter the scene that late the Allan plot for the OUTPUT of
> the standard will be dominated by the OCXO at 10000 s which will give us
> an inferior result than if it were dominated by the receiver. 10000 s is
> not a good loop time constant!
> For the most of you it will already now be kind of evident that the
> crossing point defines the magical value that we have to set the loop
> time constant to but this fact can be formulated with a bit more of
> scientifical preciseness: At no observation time tau will it be possible
> to have an ADEV at the OUTPUT of the standard that is lower then BOTH
> Allan plots at this tau. Where should its origin come from? The very
> best we can do for any tau is to find the lower of the two Allan plots
> for this tau and to choose the according source as the instance that
> shall dominate the standard's output at this tau. From there it is only
> a small step to notice that below the crossing point the OCXO's Allan
> plot is lower and above it the receiver's Allan plot is lower and that
> we really have identified the crossing point as the correct loop time
> constant. TVB has pointed out that marginal errors in setting the loop
> time constant will not prevent the circuit to work as a frequency
> standard. However this may go hand in hand with a loss in precision may
> it be marginal or not so why not use the correct value?
> What if we had not used the sawtooth corrected values but the raw 1pps
> phase data? This situation is diagrammed by the black dotted line. Again
> we have to set the loop time constant according to the crossing point
> which is considerably later than with the corrected values. 
> This alone should not bother us but let us consider its impact: Since
> below the crossing point the standard OUTPUT's Allan plot is dominated
> by the OCXO we are going to create a local maximum in the standard
> OUTPUT's Allan plot which we should not be especially proud of. But the
> more important point is: At least up to a day or more the Allan plot of
> the SAW corrected data is significant BELOW that of the uncorrected data
> and this can be expressed in two ways:
> 1) For a given observation time tau the standard's output will exhibit
> more stability whith the corrected data
> or
> 2) In order to get to an certain stability of the standard's output you
> will need longer measurement times with the uncorrected data compared to
> the corrected phase data.
> This discussion does NOT take into account the awkward effects of
> bridge-building that make everything even worse.
> What does that all mean in reality? Suppose the distance of a satellite
> in an orbit around planet Mars is going to be measured up to a
> resolution and precision of a few meters (!) by means of a 'time of
> flight' measurement on an electromagnetic wave that is transmitted to
> the satellite and answered by an transponder. What may sound like
> 'rocket science' for some of you this is what radio amateurs (!) of the
> AMSAT hopefully will do within a timeplan of a few years! Of course the
> delay introduced by the transponder alone is determined before the start
> of the satellite!
> With the speed of light being app. 0.3 m/ns this will involve to measure
> a time interval of some thousand s (runtime forth and back for a medium
> distance Earth to Mars) with some ns precision and resolution what asks
> for a abt. 1E-12 relative resolution and precision. If we do not want
> that our measurements are disturbed by the statistical fluctuations of
> the timebase used, these fluctuations shall be less than 1E-12 at a few
> thousand seconds. With a GPSDO using SAW corrected data this is achieved
> at abt. 4000-5000 s. A GPSDO using uncorrected data will have
> statistical fluctuations 5 times the planned measurement resolution and
> precision at this tau and will not make a suitable timebase for that
> purpose. 
> And yes, I know that the TIE RMS and the MTIE are the better suited
> statistical measures for this kind of problem but I did not want to
> complicate the discussion by introducing new terms. (For those
> interested: Not only does my Plotter utility compute TIE RMS and MTIE
> from phase data, in the case of MTIE it does it orders of magnitude
> faster than Stable32 due to a modern binary matrix de-composition
> algorithm). In case you did not know: Plotter can be downloaded for free
> from
> http://www.ulrich-bangert.de/plotter.zip
> Even for the uncorrected data we had assumed that we had measured them
> with a TIC resolution small enough to neglect the effects of
> quantization. What happens if the TIC in use has a quantization interval
> that is in the order of the effect being measured or even bigger? If we
> were measuring an infinite stable and jitter-free signal with a TIC
> having a quantization interval of 41.6 ns (as in the case in the Shera
> design) we will introduce statistical fluctuation sheer due to the
> quantization and nothing else that are diagrammed by the red dotted
> line. 
> The vertical distance to the yellow line (stability using SAW corrected
> phase data) is almost an order of magnitude! And please don't mistake
> the red dotted line with the overall result of measuring the raw phase
> data with 41.6 ns quantization interval! It shows the effect of
> quantization ALONE! Computing the real noise to be expected when
> measureing the receiver's pps would involve to compute the RMS sum of
> BOTH the receiver's noise and the quantization noise resulting in a line
> that is located even adverse compared to the red line!
> Brooks Shera's argument that he may average over raw phase data measured
> with his 41.6 ns quantization to remove noise is correct! Indeed, the
> red line may serve him as an (a bit too optimistic) estimation on how
> long to average for a given noise level. His misconception has its roots
> in the false conclusion that when averaging does remove noise it is
> pretty much EQUIVALENT to using sawtooth corrected data. THAT is NOT
> true! 
> Compare the red and the yellow line: Whenever the red line has reached a
> certain noise level, the yellow line has reached the same noise level in
> 1/10 the time. Or argument the other way around: Surely a Shera standard
> can reach a stability level of 1E-12 (We leave questions of DAC
> resolution and/or tempcos of parts and solder joints(!) out of the
> discussion. They can only make things worse) But consider at what
> observation times tau this is possible: 40000-50000 s. Not to be used
> for the Mars ranging where we need this stability at 4000 s! Where the
> Shera design needs to get by heavy averaging a design using SAW
> corrected values gets in 1/10 the time due to using less noisier input
> data! Got the clue?
> This is ONLY due to the 41.6 ns quantization interval and that is the
> reason why Bruce and I insist on the proposition that the noise
> introduced by the 41.6 ns quantization interval is the dominant one in
> the Shera design and that this noise is a factor 10-20 worse than that
> of the best receivers available today.
> I leave it to your own judgement whether claims like
>> In most cases you can... Forget the quantization error.
> or
>> In summary, it appears that 1pps sawtooth/bridge noise can be ignored
> for a 
> are consistent with the laws of physics and mathematics.
> Hey Brooks, you are an fantastic engineer but claims like this are not
> worth to leave your mouth!
> Best regards and a Merry Christmas for everyone in the group
> Ulrich Bangert, DF6JB
> ------------------------------------------------------------------------
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

Just added a short comment on quantisation and coherence.


More information about the time-nuts mailing list