[time-nuts] Re: Evaluating counter performance, seeking feedback.

Fri Apr 8 20:21:05 UTC 2022

Tom
Thanks for the excellent feedback.
About what I try to do: I'm trying to find a way to evaluate the
performance of a GPSDO/Counter/Timer
For the GPSDO an ADEV plot should be ok but for the counter/timer I'm
struggling. For the the two input time stamping counter part I understand
that one test is to have two 10MHz signals at 0.001 Hz aparts and verify
there are no odd jumps in the phase relation. This measurement has been
done but as the prototype is still partly a dead-bug construction the phase
errors are up to 1 ns and I hope a PCB version will improve this phase
measurement.
For the frequency counter part I tried to use an ADEV plot but I understand
now that does not make sense so I am trying to find a way to measure and
specify the performance of the frequency measurement function. In spec
sheets one reads "x digits per second". Or per frequency range the
accuracy. But how to measure the accuracy in a meaningful way? So I thought
why not use a much better counter, measure exactly the same inputs and
calculate the error. I understand now that I should use both counters in
exactly the same way. That can be done as the U6200A can also measure the
ratio between two input signals. Any pointers on how to measure and specify
performance of a frequency counter or timer apart from mentioning the raw
time resolution?
I have found a way to test the trigger level setting by using a sawtooth
signal to both inputs. One triggering on the negative edge and the other on
a positive level crossing of the trigger level and measuring the
relationship between trigger level and time between two inputs.
Any pointers or input is most welcome as there is still so much to learn
Erik

On Fri, Apr 8, 2022, 21:22 Tom Van Baak <tvb at leapsecond.com> 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 at lists.febo.com -- To unsubscribe send
> an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.