[time-nuts] uncertainty calculations

Sun Apr 16 09:31:06 UTC 2017

Below your post are posts I copied from last year from me and others
about the pseudo-random phase modulation in certain Tektronix counters
from the 1980's and 1990's. You can read more about metastability at
these links:

http://www-classes.usc.edu/engr/ee-s/552/coursematerials/ee552-G1.pdf

http://www-s.ti.com/sc/psheets/sdya006/sdya006.pdf

My main point is that averaging quantized values (contents of a counter
at the end of a gated input) doesn't always work as intended if there is
some bias in the quantization process due to metastability or other
timing nonlinearities or if  the random timing jitter is very small.
Here are some examples:

(1) Let's say that the 1 PPS signal is is generated by a process which
has NO sawtooth timing edge delay errors (jitter) due to
resynchronization. We use that signal to gate a counter which is clocked
by a 10 MHz signal with very low jitter. If the gating and counting
circuits use fast logic and they react to the rising edge of both
signals, then as long as the timing relationship between these two input
signals is stable and the rising edge of the 1 PPS signal is coincident
with the falling edge of the 10 MHz clock, there will be no
metastability and the counter will always register 10^7 counts per gate.
The system is deterministic over time intervals of many years. See
Figure 8 (on page 6) of the second link above (TI application note).

In this case, averaging has no effect. Over time intervals longer than
the lifetime of a human the count will always be 10^7.

(2) Now let's say we adjust the delay of the 10 MHz clock so the 1 PPS
rising edges coincide with 10 MHz rising edges. We now have the
metastable situation shown in Figure 2 (on page 2) of the TI application
note. We now don't know if the first clock rising edge within the gate
interval will be counted. Similarly, we don't know if the last clock
rising edge within a specific gate interval will be counted. If neither
edge is recognized the count will be 9,999,999. If one edge is
recognized the count will be 10,000,000. If both edges are recognized
the count will be 10,000,001. The system may jump between these three
cases slowly in a manner which is not completely random. So if you
average you might get the correct result (remember - we are assuming
that the frequencies and timings of the external signals are perfect),
or have an average result anywhere between -1 count and +1 count from
10,000,000.

(3) Finally, consider the case of a GPS 1 PPS output with sawtooth
timing jitter due to the manner the 1 PPS signal is generated by one
clock sampling another signal. If there is any bias in the sawtooth
delay my guess is that averaging might not produce the desired result,
especially if some process in the accumulation of the counter results
does not perform end-to-end data collection and only averages some of
the counts.

With regards to error introduced by the purposeful phase jitter imposed
on the clock: Voltage digitizing systems often add known analog dither
noise before an A/D, then remove that noise digitally from the result.
This can improve the accuracy of systems by reducing the effect of
differential nonlinearity and other system errors.
--
Bill Byrom N5BB
Full disclosure: I am a Tektronix Application Engineer

----- Original message -----
From: Hal Murray <hmurray at megapathdsl.net>
To: Discussion of precise time and frequency measurement
<time-nuts at febo.com>
Cc: hmurray at megapathdsl.net
Subject: Re: [time-nuts] uncertainty calculations
Date: Sat, 15 Apr 2017 21:46:22 -0700

time at radio.sent.com said:
> * You might have any possible phase relationship between the two
>   signals. If they are exactly related by a 10^7 ratio, it's possible
>   for the 1 PPS edges to exactly coincide with the 10 MHz edges.
>   Depending on the type of gating circuit, you will have jitter and
>   possibly metastability resolving whether which edge occured first. ...

> * To stay away from such problems, most precision counters add a small
>   amount of controlled jitter (phase modulation) to the clock.  ...

My experience with metastability is that it's really hard to make it
happen.

Are the clock and data in a good lab setup really stable enough to make 
metastability a problem?

How much does the added jitter screw up measurements where it isn't
needed?

-- 
These are my opinions.  I hate spam.
_______________________________________________

----- Original message -----
From: Bill Byrom <time at radio.sent.com>
To: time-nuts at febo.com
Subject: Re: [time-nuts] How does sawtooth compensation work?
Date: Sun, 07 Aug 2016 21:36:21 -0500

A slight correction to a typo in the description below (sorry for the
long delay). The correct Tektronix model numbers of these counters start
with DC (not TM).

The Tektronix TM500 (manual control) and TM5000 (GPIB or manual control)
instruments which used the National Semiconductor MM5837 noise generator
chip were the following:
DC509
DC510
DC5009
DC5010
These models were manufactured from the early 1980's until 1995.

The first two digits of the instrument model number designated the type
of instrument. So:
DC = Digital Counter
DM = Digital Multimeter
SG = Signal Generator
PG = Pulse Generator
AA = Audio Analyzer
PS = Power Supply
TM = Test Mainframe (which includes the power supply for the plug-
in modules)

Typically the 10 MHz internal standard or proportional oven timebase
(or external 1/5/10 MHz rear edge connector timebase input) is dived
down with 7490 TTL /5 and /2 divider sections to 1 MHz. The 1 MHz
reference then drives a X100 PLL (using an ECL oscillator with varicap
frequency control and 4044 phase detector) to create the 100 MHz main
internal clock. The MM5837 pseudo-random noise generator phase
modulates the PLL in some instrument modes of operation so that time
interval averaging works correctly if the input signal is synchronously
related to the clock.
--
Bill Byrom N5BB
Tektronix Application Engineer

On Tue, Jul 19, 2016, at 01:52 AM, Mark Sims wrote:
> The Tektronix TM509/5009 (and I think the 5010) counter modules have a
> National Semiconductor noise generator chip in them.  It injects noise
> into the counter to get around counter oscillator/input frequency
> synchronization.  I was once given a TM509 with a bad noise generator
> chip...   Some Very Smart People spent ages thinking the
> problem was in
> the device they were working on until they tried a different counter.
> The Very Smart People (too smart to RTFM)  could never figure
> out why the
> counter was flakey and finally tossed it.  A little dumpster
> diving a few
> minutes with a scope yielded a very nice little counter.
> ----------------------------
>> Universal timer/counters and equivalent time sampling DSOs can have
> this problem when their timebase ends up synchronized with the signal
> they are measuring.