[time-nuts] question Alan deviation measured with Timelab and counters

[Magnus Danielson]

Bonjour Stéphane,

On 01/14/2015 02:16 AM, Stéphane Rey wrote:
> Hi Magnus,
>
> For some reason I've missed this message and the one from Jim until now ! This answers many of the questions I had. For my defense, I've 3000 messages since the last 3 months on the list !!!
>
> ah, yes, I'd like to get even better than 1E-12. 1E-14 would be perfect but my best standards for now are a HP GPSDO and an Effratrom FRK Rb which both are around 1E-12 'only'. I may have to invest in something better if prices are acceptable. I guess I won't be able to measure beyond the standard itself.
>
> The method you describes gives tau=2E-9 ? This is more or less what I could get with the frequency measurement (even a bit lower). So what is the benefit of the time interval measurement here against the frequency measurement ?

I've been sloppy with the scaling factor, so there is a fixed scaling 
factor for the noise that the single-shot resolution produces, and that 
would be a measurement limit that if everything else is ideal would 
dominate. This quantization noise is sqrt(1/12) or about 0.289 if I 
remember correctly, so that is the scale-factor. It will also have a 
1/tau slope. So that is how you can expect this noise to behave, it will 
look like white phase noise, but isn't, it is highly systematic noise, 
and if you play nicely with it, you can measure below it. However, doing 
so is non-trivial.

I have one counter that does that. The good old HP5328A with the Option 
040-series of boards will introduce noise to the counting 100 MHz 
oscillator such that averaging gets you down towards 10 ps rather than 
10 ns resolution in TI mode. However, it does not help you to get nice 
frequency or stability measures.

I've not taken the time to detail-analyse the ADEV scaling factor 
thought, I should do that, but it follows the general formula of 
ADEV(tau) = k*t_res/tau
where t_res is the single-shot resolution and k is a constant.
There is more to this, as counters can show up non-linearities of 
several sorts, and that the trigger conditions of the input has been 
optimized, which can be slew-rate limited for many counters and conditions.

So, anyway, there is a bit of hand-waving in there, but I thought it was 
better to get you to "get" the basic trend there first, and then we can 
discuss the detailed numbers, as theory is one thing and achieved number 
can be quite a different one.

As for frequency and time-interval measurements, if properly done, they 
can be used interchangeably without much impact. Realize that frequency 
and time-interval measurements will both be based on time-interval 
measurements as the core observation inside the counter, so the 
single-shot resolution limit applies to them both. However, subtle 
details lies in how the counter works and there is ways that the 
frequency precision can be lost. A good counter is the SR620, but the 
way it does the frequency measure, you need to calibrate the internal 
delay to make it "on the mark" measure. Using it in time-interval mode 
and you can eliminate that offset, because the start and stop measure of 
your signal under test is done with the same channel, with essentially 
the same delay both trigger-times.

Another subtle detail is that when you make frequency measurements, you 
arm your counter, the start channel triggers, you wait the time you have 
programmed as the measurement time before you arm the stop channel, and 
then it triggers, after which you then read out your coarse counter of 
cycles, the interpolator states for the start and stop channels and 
well, the count of the time-base (which should be known), you calculate 
the frequency and output and well, once you cleared the "bench" from 
that measure you then arm the counter core of the next measurement. The 
time from the stop event to the following start event is called the 
dead-time. This dead-time is a period when the signal is not being 
observed. The actual time between the measures (time between the start 
events) and the length of the measures (time between the start and stop 
events) will not be the same, this will create a measurement bias in the 
ADEV. If you can establish the length of the dead-time you can 
compensate the measures. Very very few people do this these days, part 
of it is ignorance, part of it is why bother when you can use any of a 
number of techniques that avoid the dead-time altogether.

Being able to measure frequency does not easily convert into making 
quality ADEV measures.

Also, another danger of using frequency measures is that many modern 
counters use one of several techniques to improve the frequency 
measurement resolution by using things like linear regression. This 
behaves as a narrow-band filter, and the ADEV measures for white noise 
depend on the bandwidth of the system, and well, very very few 
measurements is annotated with their bandwidth, so traceable ADEV 
measurements will not be done there, and this pre-filtering effect 
bandwidth isn't even mentioned in those systems, even if it can quite 
accurately be modeled and calculated, which very very very few 
researchers do (yes, I know them). Also, typically such a pre-processing 
creates a bandwidth effect to "improve" the reading, but as the tau 
increases, the "improvement" wears off, and only becomes apparent as a 
low-tau drop in the ADEV, which deviates from the expected measurement 
limit of 1/tau, and as you go into higher taus, you end up back on the 
1/tau line that the raw time-interval measures gives you, so why bother?

So while I see the frequency measures as "problematic", for some setups 
it may be the only thing practical.

The details of how the measurement is actually done will no doubt create 
a whole range of subtle problems down the calculation route.

So, welcome to time-nuts, where the devil in the details, some of which 
few on this globe oversee and understand, and as you learn more you 
learn quirks about many more things you thought you needed to know and 
understand. :)

Your PM6654C deviates a little from the above description, as there 
isn't interpolators, it get's its 2 ns single-shot resolution from the 
fact that it uses a 500 MHz counter directly. The ECL chips in there 
get's hot, but ah well. The HP5535A counter that it rivaled was using a 
10 MHz clock for coarse counter and then used analog interpolators to 
get 200 times better time-resolution. With the PM6680 series and forward 
Philips Industrier (also branded Fluke, later changed name to Pendulum 
after it was sold of from Philips) went the analog interpolator route.

> However if I hear what you says, the GPSDO provides the 10 MHz standard reference for the counter, the GPSDO PPS on channel A and channel B receives for instance a 10 MHz signal I want to measure.
> So what will be the result of Time A-B then ? I do not understand why you put the PPS on channel A instead of something of the same frequency than the DUT ? How the time A-B will behave with these two different frequencies... " By letting TimeLab know the frequency, it can adjust for any slipped cycles on the fly." I guess this is what I've not understood.

No, only one channel should receive the signal you measure. You use the 
other channel to "start" the measure. You get a time-interval from each, 
and that is what you feed TimeLabs with, and it will track it.

You can use the 10 MHz on the A channel, if you let the PPS arm the 
measurement. This have the benefit that the PPS jitter may be replaced 
by the 10 MHz jitter (which will be significantly less usually). You do 
however want the PPS to arm it to get stable distances between your 
samples. The arming action regardless of how you do it will be of 
importance, as it can fool you to miss measurements, and make wiggely 
time-lines. However, if you measure TI of signals 2 times or higher than 
the arming rate, you can hide the dead-time neatly in the arming pattern 
(this is also known as picket fence).

So, yes you can improve things, but I wanted to reduce the complexity of 
the initial setup to a minimum setup, to start there. Once that is 
operating well, we can make the setup a little more complex.

Oh, always verify the trigger noise of the inputs and try to minimize 
it. You want to reduce it so that it doesn't limit you even more than 
the counter resolution would make you expect. For DMTD measures, trigger 
jitter is the reason that you don't put your general counter straight of 
the mixers, but need amplifier stages to optimize the performance.

> Now if I mix down the 10 MHz DUT with a 10.005 reference to increase the resolution, I'll get 5 kHz on channel B and still PPS on channel A ? Again I do not understand what will happen with these two signals on the time A-B. If I push your method a bit more, I could even get a beat frequency of 1 Hz and with 10-digits I would have increased my resolution by 10E6. Then I will be limited by the standard stability but on the principle would it work as well ?
> On that document http://www2.nict.go.jp/aeri/sts/2009TrainingProgram/Time%20Keeping/091017_DMTD.pdf it says (page 6) the accuracy of measurement is improved by a factor v/vb (the DUT and offset LO 1/2.PI.f). So it sounds to me that there is a compromise between resolution increase and accuracy. If I chose a beat frequency of 1 Hz the accuracy will not be improved but the resolution will be, right ?

I used those numbers to show where you would end up getting in the right 
neighborhood. DMTD style operation is a great tool for improved 
resolution, but it has it's own set of challenges.

The trigger jitter of a comparator. A general counter's trigger point is 
a voltage comparator, and the "event" occurs when the voltage passes 
that point and the time-stamping of that trigger event is taken. A 
general counter input is a wide-band type of input, so it has not been 
optimized. The trigger jitter of such an input can be modelled to be 
some internal jitter plus the total input noise divided by the slew-rate 
of the signal (at the trigger voltage). The quick and easy fix of the 
experienced operator is to change the trigger point to such a point on 
the signal that you get the highest slew-rate (and thus lowest jitter). 
However, what if you already measures at the maximum slew-rate? Well, 
you *might* reduce the noise somewhat.

Now, coming out of a mixer you have two sines (huge simplification, but 
let's just assume it to get the basic problem), one being the sum of the 
input frequencies and one being the difference. We filter away the sum 
frequency, as we want to measure the difference (beat) frequency signal. 
The peak slew-rate of this signal will be

S = 2 * pi * f * A

where f is the frequency of the sine and A is the peak amplitude of the 
sine. You get this from the model of V(t) = A * sin(2*pi*f*t), deriving 
it to get the slope, getting V'(t) = 2*pi*f*A * cos(2*pi*f*t) and 
realizing that the peak will be found at V'(0) as cos(0)=1.

The lower frequency, the lower slew-rate, and the trigger jitter formula is:

t_n = e_n / S

where e_n is the total noise (V RMS), S is the slew-rate (V/s) and t_n 
is the RMS time noise. Combining them gets you

t_n = e_n / (2*pi*f*A)

You naturally wants to keep the amplitude out of the mixer to a maximum.

Anyway, now we clearly see how the gain of the low beat frequency turns 
out to be our enemy in the trigger jitter of the resulting beat-note.

What you can do is to make sure that the amplifier you apply, does not 
have a bandwidth higher than needed to support the slew-rate you have, 
thus reducing the e_n part of the formula. State of the art DMTD works 
by providing a chain of low-noise amplifiers (to keep adding as little 
additional noise as possible in each stage), with increasing bandwidth, 
only to support each step's output slew-rate, and then considering the 
beat-frequency as the amplifiers noise will now be a combination of 
white noise and flicker noise (1/f) combination. In order to achieve the 
gain of the DMTD "trick" there is a whole range of issues to attend to, 
which is why this is not widely used of the shelf in generic counters.

Another part of the DMTD trick is that you do this to two channels, 
which to some degree cancels the noise of the offset oscillator, and the 
some degree aspect naturally provides that the remaining leakage can 
become a measurement limit too.

> What is the transfer clock you're talking about ? and by the way should the offset LO be as stable as the standard reference meaning greater than the DUT ?

The offset oscillator will be a "transfer clock" in the DMTD setup, as 
it's noise mostly cancels when doing DMTD.

The reason it does not fully cancels is due to the fact that the two 
channels of the DMTD setup will not go though zero at the same time, so 
the noise integrate over different time-periods and thus do not fullly 
cancel between the measurments, it would if the noise would fully 
correlate between the channels.

If they would work properly, the following simple model of phases would 
work:

P_AT = P_A - P_T
P_BT = P_B - P_T
P_AB = P_AT - P_BT = (P_A - P_T) - (P_B - P_T) = P_A - P_T - P_B + P_T = 
P_A - P_B

where P_A and P_B is the input phases, P_T is the transfer oscillators 
phase, P_AT and P_BT is the phases out of the mixer difference signals 
(assuming no other effects) and then doing the time-difference (TD) part 
of the DMTD we produce the P_AB difference, which as you see, should be 
the A - B phase difference. The gain factor of the beat note does not 
show in these equations, because they show up as time when you measure 
these phases at some frequency. The gain being

G_A = F_A / F_AT = F_A / (F_A - F_T)
G_B = F_B / F_BT = F_B / (F_B - F-T)

Since we assume that F_A and F_B is so close that they are nearly the 
same. They will actually create slightly different beat frequencies so 
you will span over the full range of relative phases. The beat frequency 
range needs to be large enough to handle the frequency difference, again 
making it harder to use in a general setup, but work well enough for the 
dedicated time-nuts.

A more modern way to do things, which is similar to DMTD but use a 
different approach was introduced by Sam Stein, and uses the fine A/D 
converters available today with low noise, nice sampling capability, and 
the back-side being FPGAs to digitally decimate the signal down. This 
can both get very much lower noise while being a much more generic 
technique. This is what the TimePod is. Correctly used, it can do more 
nice tricks, as the cross-correlation tricks which allows you to measure 
under the noise level of your reference oscillators. I regularly use two 
8600 BVAs as reference to my TimePod, which is a pretty decent setup.

> Well, it's far too late here to let my brain working anymore. I will perform further experiments tomorrow at the office.

Speaking of which, I should get up and to the office. The joy of a 
morning post. :)

Cheers,
Magnus