[time-nuts] question Alan deviation measured with Timelab and counters
Stéphane Rey
steph.rey at wanadoo.fr
Wed Jan 14 13:30:29 EST 2015
Bonjour Magnus,
Many thanks for your very long and detailed answer. I've read quickly bu will go deeper tonight.
Here are the results of today experiments... which are not giving anything valuable... I still don't understand the results I get :-/
With the PM6654C, I've put the HP GPSDO on the standard input, the 1 PPS on channel A and the 10 MHz from the DUT (GPSDO as well) on channel B. This gives something in the range of 2E-9 which looks like the counter resolution, right ? The gating takes 4s and the Time A-B displays a value like 64 E-6
Now if I downmix the channel B to 5 kHz (LO is a DDS Standford & Reseach generator), I have a sinus with lower amplitude and no squarer in my hand at the moment to shape the signal. Anyway, I do the same operation and I get on the display two more digits like xx.xx E-6 but the ADEC is in the range of E-7.... I do not understand at all this fact. Even if the slew rate is not great, I was expecting an improvement.
Note that the values displayed are always changing quite a lot between two samples. For instance with the 5 KHz channel B signal, I can read first sample at 27.11E-6, in the next one is 31.22E-6... which sounds huge, right ?
I've then found an HP5370A and tried the same operation. Unfortunately the 5 kHz output is too low for the HP5370A sensitivity. I need an amplifier or sqauerer here but had no time to build on today.
Si I could not get anything valuable with the HP5370A at the moment...
Stephane
-----Message d'origine-----
De : time-nuts [mailto:time-nuts-bounces at febo.com] De la part de Magnus Danielson
Envoyé : mercredi 14 janvier 2015 08:04
À : time-nuts at febo.com
Cc : magnus at rubidium.se
Objet : Re: [time-nuts] question Alan deviation measured with Timelab and counters
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
_______________________________________________
time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com
More information about the time-nuts
mailing list