Tom, others.
An important reason for me to write these posts is to try to try to
understand what I am doing. writing helps me to discover flaws in my
thinking. If its too much feel free to block me.
To test systematic errors when measuring the ratio between two
frequencies a dual channel signal generator was used. One channel set at
static 10MHz, the other channel set to sweep +/- 500 Hz around 10MHz.
Both channels where send to the two inputs of the U6200A and the
tinyCount (own build counter). Both counters measured the ratio between
the two frequencies with a 1 second gate time. Both counters used their
internal reference for measuring the ratio.
Timelab was used to record the frequency difference [1][2] and after
measuring one full sweep and removing the global linear trend a very
weird pattern appeared [3]. Both the U6200A and the tinyCount had a
cyclic deviation from the global linear trend depending on the
difference in frequency. For a span of 1kHz the U6200A showed 1.5 cycle
up to 1.3e-9 error and the tinyCount 25 cycles of up to 2.5e-9 error.
When measuring two static 10 MHz signals with only a small frequency
difference the U6200A and the tinyCount agreed within their measurement
noise.
Further testing showed the amount of cycles in the full sweep was
independent of the sweep span. Reducing the span with a factor 10 also
reduced the maximum deviation with a factor of 10. Reducing the sweep
time did change the amount of cycles in but not with a linear relation
to the change in sweep time.
As the tinyCounter uses regression the amount of points used for the
regression was changed from 20000 to 50000 but this did not create any
visible difference in the frequency deviation cyclic pattern.
Some further work is required to understand the cause of these cyclic
deviations.
Erik.
[1] http://athome.kaashoek.com/time-nuts/1kHz%20sweep%20U6200A.tim
[2] http://athome.kaashoek.com/time-nuts/1kHz%20sweep%20tinyGTC.tim
[3] http://athome.kaashoek.com/time-nuts/1kHz%20sweep.png
On 8-4-2022 21:11, Tom Van Baak wrote:
Thanks for posting both TIM files along with the plots. Here are
replies to 3 of your questions:
> Is this setup meaningful in assessing performance differences?
> If not, how to improve?
It's probably better to compare two different counters using the same
setup. So give them both the same Rb as ext REF and give them both the
same DUT and then collect data simultaneously (apples and apples). But
it sounds like you can't use or don't have an ext REF input for your
DIY counter? In that case, right, you have to resort to the unusual
arrangement that you're using (apples and oranges). This is one reason
why almost every frequency counter has an external REF input.
> How can one compress or expand a TIM file to correct for the
difference in gate time?
> A better approach would be to ensure gate times where identical.
Right, I noticed the two TIM files don't line up. That's a problem.
They are off by several seconds at the beginning of the run and spot
on at the end of the run. I suspect some manual editing? Note this
doesn't affect the ADEV plots, but it messes up the phase and
frequency plots. It's easy to fix.
It looks like you didn't input the correct sample rate when you loaded
the data into TimeLab. There's a box in the acquisition menu to set
the sample rate. Normally close enough is good enough, but when you're
working with simultaneous data you need to be much more precise. This
isn't a problem with timestamp data because the actual sample rate is
implicit in the timestamp. And it's not a problem for zero-dead-time
frequency measurements either because one of the clocks does the
pacing. But for traditional gated measurements, yes, sample rate may
be inexact, and may also vary depending on the measurement data or
auto trigger settings.
A while ago I collected simultaneous data on a several oscillators for
many days. When my PC reads serial data from a counter I always prefix
lines with a MJD timestamp [1]. Days or years later it tells me when I
did the experiment. It can also be used to detect gaps in the data. It
also makes it easy to make x-y scatter plots using MJD as an axis. It
allows multiple runs to be correlated (e.g., environmental data on one
PC, counter data on another PC, GPS data from a third PC, etc.). But
most importantly it allows me to compute the actual sample rate, the
tau, for any data that I ever collect. For example 5 "identical
counters" set for 10 s gate time had actual sample rates of:
10.3475 s
10.3496 s
10.3496 s
10.3494 s
10.3475 s
This doesn't matter for short runs, doesn't matter to ADEV, doesn't
matter for phase or frequency plots of one counter, but matters a lot
when you have multiple counters over an extended period of time.
> How can one use the two TIM files to calculate the RMS of the
differences in frequency?
> My hope is to use this RMS calculation as a single number quality
indicator.
Perhaps explain more what you're trying to do. Remember that frequency
depends very much on the averaging time so you can't just use a single
number. ADEV works because it's always ADEV(tau). There is a special
case when ADEV measurements are strictly linear, usually with a slope
of -1 or -1/2. Then it is customary to use a single number. For
example 1e-9/tau for 1 ns of WPM, or 1e-6/√tau for 1 ppm of WFM.
/tvb
[1] see comcat1 and comcat2 in my www.leapsecond.com/tools/ directory.
On 4/7/2022 12:44 AM, Erik Kaashoek wrote:
To better understand the performance of a home build counter a
comparison was done with a Picotest U6200A
The two channel home build counter was setup to measure the frequency
of the 10MHz output from a Rb on one channel and the 10MHz output
from a not so good OCXO on the other channel.
The ratio between the two frequencies was measured with a 1 second
gate time, multiplied by 1e+7 and send to Timelab.
The U6200A had the Rb output as 10MHz reference and the 10MHz from
the OCXO into channel 1. Gate time was also set to 1 second.
In Timelab the data from the Counter under test and the U6200A where
recorded simultaneously over a 1000 second period
The recorded data was saved and adjusted for the difference in start
time of the measurements and loaded back into Timelab.
U6200A TIM file http://athome.kaashoek.com/time-nuts/U6200A.tim
Own counter TIM file http://athome.kaashoek.com/time-nuts/tinyGTC_2.tim
A first performance check was done by plotting the unwrapped linear
residue of the phase of both measurements. (see:
http://athome.kaashoek.com/time-nuts/tinyGTCvsU6200A_Phase.png ) .
The measurements did show some differences in instantaneous phase but
the differences where small and even at 980 seconds the two
measurements agree rather well.
A second performance check was done using the frequency plot. (see
http://athome.kaashoek.com/time-nuts/tinyGTCvsU6200A_freq.png ).
Overall the two measured frequencies agreed with sometimes up to
1e-10 difference. The difference in gate time of the two counters was
very visible as a gradual shift. As the measurements where aligned in
time at the end of the measurement the time difference at the start
was about 3 seconds.
A detailed plot of the measured frequencies over the last 100 seconds
(see
http://athome.kaashoek.com/time-nuts/tinyGTCvsU6200A_freq_detail.png
) showed an occasional difference between the frequency measurements
of the two counters up to 2e-10
Questions:
1: Is this setup meaningful in assessing performance differences? If
not, how to improve?
1: How can one compress or expand a TIM file to correct for the
difference in gate time? A better approach would be to ensure gate
times where identical.
2: How can one use the two TIM files to calculate the RMS of the
differences in frequency? My hope is to use this RMS calculation as
a single number quality indicator.
Erik.
_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe
send an email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.
_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com -- To unsubscribe send an
email to time-nuts-le...@lists.febo.com
To unsubscribe, go to and follow the instructions there.