Brooks GPSDO may be 15 years old but is still perfect for today's
applications. If you look at tvb's Tbolt plot or Ulrich's plots with and without
sawtooth correction for a day or two the limit is GPS. The basic unit has a
resolution of 1.73 E-13 in mode 7. Brooks uses a 40 bit filter. I have
increased  resolution using 100 MHz in stead of 24 and increasing filter time from
30 to 60  and 120 seconds. 240 is also an option, I would only recommend
any thing above  30 seconds if you use a Rb. The only thing wrong is that
chips that where  available 15 years ago are now hard to find. My answer is a $
1 gate array and  if some one will step up to the plate and modify the
available ASM code to  generate the RS232 code to control a FE 5680A I will make
a G/A design and a  board design available. While at it also look at putting
it in a 18 pin PIC. If  interested contact me off list.
With hundreds of 5680's out there many will appreciate a low cost simple
solution. Working with the presently available ASM code now out there it will
be  a very small effort needed to transfer it to the latest version 1.402.1
when it  becomes available. It will take some one willing and able to pick
up at the  point where the filter output drives the DAC and develops code
that reads the  info from the 5680 and generates the correction code. The 5680
does not control  a DAC but the DDS in the 6.8 GHz loop.
As to the input circuit, having looked at many alternatives I still thing
it is the best for a 1 pps input from GPS and its limitations. Hope to have
some  data available of 1.402.1 driving a Morion in the next couple of days.
I also have a couple of A&A boards with all original chips and some of  my
100 MHz boards with components. Please contact me off list if  interested.
Bert Kehren Miami

In a message dated 3/25/2013 2:30:36 A.M. Eastern Daylight Time,
attila@kinali.ch writes:

On Mon,  25 Mar 2013 00:43:02 -0400
"Daniel Schultz" n8fgv@usa.net  wrote:

Definitly a sad day....

it been

That highly depends on what you want and what you  need.

Shera's design is definitly one of the simplest GPSDOs out  there.
And with that it defines what the lowest complexity to get  something
accurate is. If the performance of this circuit is enough for  you,
i wouldn't go for anything else. Of course, if you need better  performance
or want to tinker and see what can be done with home made  equipment, then
you should go for different circuits.

Attila Kinali

--
The people on 4chan  are like brilliant psychologists
who also happen to be insane and  gross.
--  unknown

time-nuts  mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the  instructions there.

The lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.

Bruce

EWKehren@aol.com wrote:

I realize there are many cases where clock domain considerations are important. But why does it matter in a device that is simply doing long-term 1PPS statistical sampling?

Could one of you clock domain specialists actually spell out the GPSDO problem for the rest of us, nanosecond-by-nanosecond?

Thanks,
/tvb

On Mon, Mar 25, 2013 at 2:56 PM, Tom Van Baak tvb@leapsecond.com wrote:

It's hard to discuss this generally, so let's take an example design.
I don't know Brooks Shera's design at all, so I don't know how
applicable the following example is to it. In any case it is an
illustration of the type of clock domain problems one can have while
designing a GPSDO.

Imagine you want to know how many ticks of a 10 MHz source (such as a
VCXO) there are between two rising edges of an externally provided
PPS. By externally provided I mean it is not derived from the 10 MHz
VCXO. Most people today would do it with an FPGA.

One way of doing it wrong is the following:

• Have a free-running counter clocked off the VCXO, counting +1 at
  each tick. If this is a 32-bit counter it contains 32 flip-flops (FFs)
  that you take the output from. These outputs also go to a bunch of
  gates which feed the D inputs of those FFs. These gates implement the
  "+1". The VCXO output is hooked to the clk inputs of all FFs, so at
  every rising edge of the VCXO signal, a new value appears at the Q
  outputs of the FFs. This value is the old value plus 1. Sorry if I am
  explaining this at a too-easy level. The signals out of the FFs take
  some time to go through the gates, but the FPGA Place&Route tool knows
  (because you tell it so) that if the worst case combinational delay
  between any Q output of an FF and any D input of any FF is well below
  100 ns, all is fine. This is the beauty of synchronous design. You
  tell the P&R tool what your clock period is and it makes sure all
  signals at D inputs are stable by the time the next rising edge of the
  clock comes.

• Now you say "OK, I am going to freeze the value of that counter at
  every rising edge of PPS and store it, so a simple subtraction
  afterwards will tell me the period I am measuring". What happens if
  you tap the Q outputs of those 32 FFs and send these signals to the 32
  D inputs of another bunch of FFs which are clocked by the PPS? The PPS
  rising edge can come anywhere withing the 100 ns period of your clock.
  Because of the different latencies for each line inside the FPGA,
  there are chances that some bits in the 32 bit word (as seen by the D
  inputs of the PPS-clocked FFs at the time of a PPS rising edge) have
  changed after a VCXO rising edge, while others still haven't. This can
  give you completely bogus values at the Q outputs of these FFs. You
  might think that you can do a software sanity check and fix the bogus
  values, but this is impossible. You cannot know which bits are wrong
  just by looking at this time-stamp. In addition to this problem, there
  is also the issue of metastability in FFs. If the rising edge of PPS
  as seen by an FF in its clk input is very close in time to a
  transition (rising or falling) in the signal hooked to its D input,
  the Q output can stay in a metastable state (neither '0' nor '1') for
  a long time. This is more or less important depending on what you are
  doing with these outputs further down in your design. It's generally
  very bad.

So how do you do it properly?

You bring the PPS into the VCXO clock domain. You can do this by
feeding the PPS signal to a chain of three FFs clocked by the VCXO:

• FF1 has its D input hooked to the PPS signal.
• FF2 has its D input hooked to the Q output of FF1.
• FF3 has its D input hooked to the Q output of FF2.

The output of FF1 can be metastable from time to time, with a small
but not negligible probability. The output of FF2 is for all practical
purposes safe. For it to be metastable, you would need a
doubly-unlikely event: that FF1's output has gone metastable in the
previous clk tick and that the D input of FF2 is seeing an unsafe (far
from '0' or '1', near the transition region) voltage at the time of
the current tick's rising edge.

Now if you tap the outputs of FF2 and FF3 and hook them to gates which
implement (Q(FF2) and not Q(FF3)), the output of this combinational
block is a nice 1-tick-long pulse which is '1' after detecting a
rising edge of PPS. This pulse is in the VCXO clock domain, so you can
safely use it as an ENABLE of the bank of 32 FFs you use to get a time
stamp. This bank now gets clocked by the VCXO signal, so all FFs in
the design are clocked by the same clock, and the P&R tool can do its
job properly.

I hope I understood your question well and this answers it. Cheers!

Javier

On Mon, 25 Mar 2013 06:56:30 -0700
"Tom Van Baak" tvb@LeapSecond.com wrote:

I'm by far not an expert, but i try to explain it anyways:

The PPS sampling is exactly the problem here.
The PPS occurs at any given time relative to the 24MHz clock. This means
setup and hold times can be violated in a synchronous circuit.
In this case, the input to the 75HCT4520 is an AND connection of the 24MHz
clock and the PPS. Due to this, the clock input to the counter in the
74HCT4520 can become very short, short enough that the minimum width of
the clock pulse is violated (>15ns). Because of this, the behaviour of the
counter is undefined and can lead not only to missing one count (which
would be caught by the PI control loop as additional noise), but the output
of the D-flip flops in the counter can switch or not switch depending
on the wheather in Guatemala. Ie the output of the counter becomes
(more or less) random. Which in turn means the lower 4 bit of the
input to the PI control loop are wrong[1]. Or in terms of time, we
might be off by +/-2^4*42ns=672ns, which is a major hit against the
PI loop (like knocking it with a sledge hammer).

Additionally, it is known that logic circuits can be caught nearly
indefinitly in a meta stable state (until the next clock pulse),
if the circuit has no provisions for this. Ie the output of the
flip flops would not be 1 or 0, but something inbetween, with some
negative effects on the circuitry downstream.

HTH

		Attila Kinali

[1] I ignore the additional +/-1 of bit 5 for clarity

The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
-- unknown

Actually, most modern FFs are hardened against metastability so often a
single synchronizer will do especially if it is feeding a synchronous
circuit.

David

On 3/25/13 1:56 PM, Attila Kinali wrote:

On Mon, 25 Mar 2013 18:56:34 +0100
Attila Kinali attila@kinali.ch wrote:

Maybe to clarify here:
The reason why all 4 flip-flops (and thus all 4 output bits) are affected
is because the 74HC4520 passes the input clock to all four flip-flops
(see figure 5 in http://www.nxp.com/documents/data_sheet/74HC_HCT4520_CNV.pdf)

		Attila Kinali

--
The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
-- unknown

But these numbers don't go directly to the PI loop, there is a
software layer between that can inspect for outliers.

This is how engineers can reduce costs by knowing when something needs
to be perfect and when it does not need to be.  In the end the
controller works about as good as it needs to.    What saves this is
the unstably of the cheap 24MHz clock.  If the clock problem happens
the randomness will make it soon stop happening and the software can
just ignore the outliers.  You have to look at the whole system and
not just the hardware.  Much of the functionality is in the software.

--

Chris Albertson
Redondo Beach, California

On Mon, 25 Mar 2013 14:03:23 -0400
David McGaw n1hac@alum.dartmouth.org wrote:

I would not count on that. Most 74xx that hobbyists use are from
the HC and HCT families. These have been designed in the 70s (IIRC)
and i very much doubt that any of the manufacturers changed anything
in their design since then.

		Attila Kinali

--
The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
-- unknown

On Mon, 25 Mar 2013 11:18:06 -0700
Chris Albertson albertson.chris@gmail.com wrote:

The problem here is that these outliers need not be a seldom occurence.
If you take a LEA6-T as PPS source, you get the PPS pulse within +/-10ns
in 90% of the cases. The 24MHz clock is, even though it's a cheap
crystal, still a crystal. So you can assume a stability of better than
10^-7 short term (couple of seconds to a few minutes), probably in the
range of 10^-8 to 10^-9.

The window for metastability is 15ns (minimum clock pulse width).

Now we have two things to consider:

1. Both the clock and the PPS are relatively stable compared to
   the "size" of the 15ns. Ie if we ever get into region of metastability,
   the probability that one of the next PPS will trigger again a metastable
   condition is relatively high.

2. We have a 24MHz clock, which means the clock pulse width is
   20ns (T=1/24MHz, T/2 = 20ns). Ie the probability that our clock pulse
   is too short is 75% (15ns/20ns).

I dont know why this isnt a big issue with the Shera GPSDO.
I guess that the specs of the 74HC4520 are very conservative
an that the minimum clock pulse length is rather in the range
of 5ns than 15ns for most devices and operation temperatures.
It might also be that the probability of bits being affected
is less for the upper bits than for the lower bits.
Or the PI loop is stable enough to deal with the additional noise.

		Attila Kinali

--
The people on 4chan are like brilliant psychologists
who also happen to be insane and gross.
-- unknown

Minimum clock width is not the window for metastability.  That is
usually 10s to 100s of picoseconds.

On 3/25/13 3:20 PM, Attila Kinali wrote:

S/LS logic was introduced in the mid 70's, F/AS/ALS around 1980, HC was
early 80's.  By the third 7400 generation (F/AS/ALS) the problem was
well known with parameters available and the logic fairly hard to it.

On 3/25/13 2:56 PM, Attila Kinali wrote:

On Mon, Mar 25, 2013 at 12:20 PM, Attila Kinali attila@kinali.ch wrote:

The PPS signal is not sent direct to the 74HC4520.  The PPS first
drives "Phase Detector 3" that is built into the 4046 chip.  this is
an RS flip flop.  Notice it is "RS3 OUT" that drives the 4520.    RS3
uses both the PPS signal and the divided down VCXO to create "RS3 OUT"
I think this gives a minimum pulse width, I'm not sure

--

Chris Albertson
Redondo Beach, California

On Mon, Mar 25, 2013 at 12:45 PM, David McGaw n1hac@alum.dartmouth.org wrote:

I think this is all moot because as I just wrote in another email the
PPS signal never gets out of the 74hct4046 chip.  What gets out is
the output of  "Phase Detector #3".  You've have to know in some
detail how the 4046 chips' PD3 works.

Chris Albertson
Redondo Beach, California

Both edges of the 24MHz clock gating pulse are asynchronous with respect
to the signal being gated.
Metastability can result with clock pulse widths that lie within a
critical range.

Bruce

Chris Albertson wrote:

Hi

With the 24 MHz clock in the circuit, and the logic families shown, the most
likely metastability issues are edge rather than clock pulse width related.
When you hit the "magic window" (think picoseconds) there is a probability
of going metastable. It's not a 100% thing. Even with multiple synchronizer
stages not being metastable is also not a 100% guarantee.

The real question is - does a once every X seconds / hours / centuries event
bother me in the application? Once you get to a multi stage synchronizer,
the dimensions on the time are large enough that the answer is generally no.
The event is so rare that you will never see it with these data rates. Being
sure it's fixed is easy.

It's the flip side - error rate without the synchronizer that is a bit
harder to quantify. Things could run for weeks outside the threat window. Is
it a several times a minute (every few days) or once an hour (every few
weeks) problem? In the first case, you probably do care. Multiple hits per
minute will mess up the loop. In the second case, you will never notice the
issue.

Of course, boost the clock, change the logic family, mix logic families,
fiddle this or that and you probably should look at things again...

Bob

-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com] On
Behalf Of Bruce Griffiths
Sent: Monday, March 25, 2013 4:38 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] Metastability (was Brooks Shera)

Both edges of the 24MHz clock gating pulse are asynchronous with respect
to the signal being gated.
Metastability can result with clock pulse widths that lie within a
critical range.

Bruce

Chris Albertson wrote:

wrote:

https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

First off we have the answer.  This thing works very reliably well.
The question is "why?"

In the normal steady state case the phase of the VCXO is held to be
1024/24,000,000 seconds.  This means the plus from pin 15 of the 4046
would be about 4,000 nanoseconds long and would never be anything so
much as a factor of ten away from 4 uSec.

One thing I notice is that I think the QST artcle has the pins on the
4520 mislabeled.  Pins 9 and 10 are the two inputs to an AND gate.
The 24MHz counter is being "anded" with the phase detector and the
result of the AND is then fed to the counter.  My data sheet shows
pins 2 and 10 as being called "enable".  So what we have as a pulse
that is about 4uSec wide gating a 24MHz square wave.

There might be a "race" to see if the enable pin or the clock pin gets
a pulse first and it would be a coin flip now and then but it's only
an off by one problem.

In the no-steady state case, when power is first applied before the
loop is closed.  I don't think we care about glitches and and if the
VXCO is stable but as soon as it does locj the pulse going to pin the
4520's pin-10 will be 1024 times longer than the the period of the
signal at pin-9  Again, pins 10 and 9 are the two inputs to an AND
gate (after pin-10 is inverted)

On Mon, Mar 25, 2013 at 2:04 PM, Bob Camp lists@rtty.us wrote:

--

Chris Albertson
Redondo Beach, California

Hi

In normal operation, the counter is clocking back and forth across the 1024 / 24,000,000 boundary. It has to do this for the control loop to "see" anything. Put another way, if it's always 1024 / 24,000,000 the loop does nothing at all.

It's the "race" between things like enable and clock or data and clock that generates metastable conditions. If the data is changing as the clock fires, the flip flop oscillates rather than goes to a single state. In this case oscillation is not a good thing…..

Bob

On Mar 25, 2013, at 5:43 PM, Chris Albertson albertson.chris@gmail.com wrote:

I don't disagree with your statement above, but my question was -- does it matter in a GPSDO; does it matter in this GPSDO?

Occasionally missing a 24 MHz tick is a not a worry (all gated frequency counters share this "feature"). A one-count ambiguity is normal and expected, even welcome. Note also that the PIC will see only 0 or 1; there is no metastability in software. So where exactly is the problem?

For educational purposes if nothing else, I'm looking for a precise description of the scenario (at the picosecond level if necessary) that reveals the flaw in his board. I'm not saying there isn't; I'm just saying I'd like to see it explained. Either his design was accidentally or intentionally clever, or there is in fact a minor fault. However, if there is a flaw, we also need to explain why in 15 years no one has reported glitches in their Shera boards.

I sort of understand metastability, but just adding more hardware to reduce it doesn't seem to be the only way to deal with the issue in a GPSDO.

Said -- how do you handle this in your Fury design?

/tvb

On Mon, Mar 25, 2013 at 3:02 PM, Bob Camp lists@rtty.us wrote:

Looking at the source code...

1. He tries to detect what he calls "glitches" which are unexpected
   values of the counters.  He waits for three of them then turns on the
   "glitch LED" and does a hard reset to the counters by lowing the CLR
   line.    This seems to be the only case the  "CLR" is arrested.  In
   other than glitch cases he lets the counters wrap.  So I guess we
   could see by looking at the LED how often this happens.  He defines
   "glitch" as the phase shifting by an impossible amount three times in
   three seconds

2. there is another safety feature in that he only allows the output
   to the DAC to move at a slow rate (I think one count per 30 seconds?)

--

Chris Albertson
Redondo Beach, California

Hi Tom,

In the Shera design the instability of the XO timebase is
a key factor in improving the 30-second update resolution.
With the XO drift varying the sample point across the 1PPS
and 312.5 KHz edges the samples are constantly varying and
the average of the samples has a resolution much closer to
(1/CLK)/30 or 1.4ns. If both signals were synchronized
with the clock the start and stop edges of every sample
would fall exactly on a clock. In lock the odds of the
sources having a sample-to-sample variation greater than
1 clock period (+/- 41.7ns) over the 30 second sample
period is low. So the probability is high that you would
get 30 identical samples with an average resolution much
closer to 41.7ns (+/- 1 clock).
The counter clock and asynchronous gate are applied to
an AND gate in the CD4520 that drives all 4 stages so when
an asynchronous gate edge and clock are coincident a short
clock pulse is generated and the setup and hold times of
the CD4520 counter are not met. Under these conditions the
first 4 stages in the 4520 could end up in an indeterminate
state and the input to the 4040 would be questionable. The
counter should settle to some value by the next clock,
but the value could be up to +/- 31 counts different than
it should be. Shera gates multiple samples into the
counter with a single read/reset per 30-second update so
multiple uncertainties can be introduced in the accumulated
count.
Recognizing the probability of asynchronous gating
resulting in glitches in the data Shera uses a de-glitch
routine in modes 4-7 that detects any 30-second value that
exceeds +/- 30 counts from the previous value as a glitch
and uses the previous value when this condition is detected.
This is far from ideal as multiple errors could be
accumulated with an average value less than +/- 30 counts
per update, but it does handle the occasional glitch when
the gate and XO edges are coincident and a >30 count error
results. The XO stability usually insures coincidence will
be short lived, but multiple 30-second glitched samples
do occur, so a 3 glitched update (90-sec) limit is included.
During my early work on upgrading the Shera a number of
different counter designs with asynchronous gating were
evaluated. I settled on the AC163 as the clock is not
gated directly so no short clock pulses are ever applied to
the stages. Instead the /Q to D is gated and the previous
Q is passed to the next stage on the clock to determine if
it should advance. The gate to clock setup time is 2.5ns
with a hold time of -3ns, so if the setup time is met the
first stage advances, but if it rises and falls immediately
around the clock no advance occurs. This design reduces the
possible uncertainty with coincident gate and clock to
the first stage only (+/- 1 count) but with the hold time
smaller than the setup time typically no glitch will occur.
A 100 MHz XO driving an AC163 prescaler feeding TMR1 was
used with asynchronous gating. Each sample was read, added
to a software accumulator, and the counter reset after
every sample. In testing this asynchronous gated design it
produced no glitches (+/- 30 counts from the previous
sample) during 1 year of continuous operation but still
has the advantage of good sample averaging over the
30-second update period for a phase resolution of 330ps.
Of course the ideal to get the optimum data out of the
GPS is to use a TIC with 1ns resolution and apply GPS
sawtooth correction to reduce the uncertainty in every
sample. To insure the counter value is correct you need
to synchronize the start and stop events to the clock
so only whole clock cycles are counted, but then you are
limited to the resolution of the clock. This is where
interpolation can be used to get the desired resolution
even though the counter resolution is limited to the
clock period. In the Interpolating Discipline Controller
(IDC) the disciplined source is multiplied to 40 MHz for
the TIC timebase and used to produce a 10us delayed
50 KHz phase detector reference. The GPS 1PPS is
synchronized to the 40 MHz clock to start the counter,
with an interpolator determining the 1PPS to clock delay
with 1ns resolution. The 50 KHz stop signal is also
synchronized to the 40 MHz clock to equalize the start
and stop delays, but since both are derived from the
disciplined source their delay is constant and a stop
interpolator is not required. The sample is read from
the counter, multiplied by 25 to 1ns resolution, the
interpolated start delay is added, and the result is
added to a software accumulator over the update period.
A separate PIC accumulates the sawtooth corrections
over the update period and at update the accumulated
sawtooth correction is added to the accumulator before
the data is passed to the filter. The GPS sawtooth
correction removes the sawtooth variation and provides
stable data into the filter for 33ps resolution phase
data per 30-second update.
An interesting point of the IDC design is a single
interpolator is used so there are no tracking issues
typically encountered with dual interpolators. Although
a stable timebase is used the GPS sawtooth constantly
sweeps the 1PPS over the clock edge in lock so good
averaging of the samples occurs in the accumulated
data. The sawtooth causes constant interpolator min
to max variations as the 1PPS passes thru coincidence
with the clock during each ramp, providing the offset
and span data needed to automatically keep the system
in constant calibration.

Richard

On Mon, Mar 25, 2013 at 3:41 PM, Chris Albertson
albertson.chris@gmail.com wrote:

Yes.  the counter value never should go more than 30 counts away from
1024.  He defines a difference of over 30 as a "glitch" and as I
wrote, if this happens three times he does a reset and toggle a LED.
I was surprized at how low the threshold is.  30 seems low but
appearenty it almost never goes that far from 1024

Chris Albertson
Redondo Beach, California

There is an AMD patent where they actually drive the input pin to make it decide rather than hang. I have no first hand knowledge with the design (well other than knowing the designer) since I couldn't use the scheme in my own designs.

-----Original Message-----
From: Bob Camp lists@rtty.us
Sender: time-nuts-bounces@febo.com
Date: Mon, 25 Mar 2013 18:02:33
To: Discussion of precise time and frequency measurementtime-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] Metastability (was Brooks Shera)

Hi

In normal operation, the counter is clocking back and forth across the 1024 / 24,000,000 boundary. It has to do this for the control loop to "see" anything. Put another way, if it's always 1024 / 24,000,000 the loop does nothing at all.

It's the "race" between things like enable and clock or data and clock that generates metastable conditions. If the data is changing as the clock fires, the flip flop oscillates rather than goes to a single state. In this case oscillation is not a good thing…..

Bob

On Mar 25, 2013, at 5:43 PM, Chris Albertson albertson.chris@gmail.com wrote:

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Tom Van Baak wrote:

Agilent go to a lot of trouble to add synchronisers (and sometimes clock
jitter eg HP5345A) to their gated frequency counters to ensure that the
average measured frequency is unbiased.
For more detail see:
http://www.hpmemory.org/an/pdf/an_200.pdf                            pp
27-28
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdfhttp://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf
pp 12-15

The average value of the counter output when sampled is important in a
GPSDO.
Metastability can result in an output that oscillates or dwells at a
level that is neither 1 nor 0.
How the PIC reacts to such inputs is unpredictable although on an
interrupt input, at least, its likely to use a synchroniser.

Probably because those that built them either didn't have the necessary
equipment or were unaware of the potential problem.

Bruce

Hi

The gotcha with using the XO as a "spreading source" is the hanging bridge issue. As long as temperature (or what ever) is constantly changing the XO all the averaging stuff works out. A GPS with a sawtooth output (and no correction) is doing the same thing. The problem comes in when the XO settles down and runs at one frequency. That may sound impossible, but it's not. Injection locking is one way to make it happen. There are a couple of others. When the averaging stops, you get a dead spot. You don't get a glitch, you just loose resolution. The practical effect is a step in the input rather than a smooth transition. Not easy to spot….

Bob

On Mar 25, 2013, at 6:41 PM, Richard H McCorkle mccorkle@ptialaska.net wrote:

Richard H McCorkle wrote:

The above assertion is not correct if the inputs to the synchroniser(s)
are asynchronous to the synchroniser clock.
The gate period will have a bounded (neglecting the effect of
metastability at the output of the synchronisers) variation of +- 1 count.
Provided that the synchroniser (and counter) clock and the divided down
disciplined oscillator clock meet the conditions outlined by David Chu in:
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1974-06.pdf

In practice these conditions may be difficult to meet without adequate
random phase modulation of PPS (and the divided down disciplined
oscillator signal).
Alternatively phase modulating the synchroniser/counter clock is perhaps
simpler.
The sawtooth phase modulation of the PPS signal output produced by many
timing GPS receivers isnt sufficiently random to be particularly useful.

Hi

Using the GPS sawtooth as a source of randomness is dangerous. It can stop moving for minutes at a time if the conditions happen to be just right (or in this case wrong). Of course lack of randomization isn't your only problem when this happens. The (likely substantial) offset in the data is also a significant issue.

Bob

On Mar 25, 2013, at 8:35 PM, Bruce Griffiths bruce.griffiths@xtra.co.nz wrote:

Bob,
You are preaching to the choir and although Brooks felt that
using an XO and asynchronous gating to improve the resolution
was sufficient and GPS sawtooth correction was not needed with
the long averaging times in his controller that doesn't mean
that I agreed. The early work I did just reduced the glitches
and improved the resolution so there was sufficient gain for
proper damping to discipline an atomic source. As I learned
more the benefits of greater phase accuracy became apparent
and led to the development of the IDC.
The IDC uses the disciplined source as a stable timebase with
PICTIC interpolation to increase the resolution. The typical
interpolation gain is 400 for 62.5ps/sample resolution but
this is reduced to 1ns to match the GPS resolution. The combined
instabilities in the interpolator are below +/- 4 ADC counts so
after the 16x reduction the 1ns phase data returned is accurate.
The 1PPS stability has no effect on the 1ns TIC resolution so
the accumulated phase data is accurate whether the 1PPS timing
is varying or stationary. The data has the GPS sawtooth correction
applied before filtering, so even if a 1PPS offset is present for
an extended period during a hanging bridge the sawtooth corrected
phase data entering the filter will be accurate. The only place in
the IDC where the sawtooth is used to advantage is over a 2 hour
calibration period there are typically enough min/max variations
due to the GPS sawtooth to accurately determine the interpolator
offset and span.

Richard

Hi

One very important thing to consider when looking at this design - it was done in the era of selective availability. That provided a lot dither all by it's self.

Bob

On Mar 25, 2013, at 10:05 PM, "Richard H McCorkle" mccorkle@ptialaska.net wrote:

On Mon, Mar 25, 2013 at 11:16 PM, Tom Van Baak tvb@leapsecond.com wrote:

Properly designed gated frequency counters get the input pulses into
their system clock domain by using a synchronizer. Then they use this
synchronized pulse to freeze the value of their internal counters. In
the process of synchronizing the input you do introduce a 1 clock tick
uncertainty, and this is unavoidable unless you go to more evolved
designs based on interpolation. I don't think this is what we discuss
about when we talk about metastability. If my understanding is
correct, what we are discussing is what happens if you try to freeze
the value of a counter with a signal which is asynchronous to the
clock of that counter. Imagine that you have a 32-bit counter and your
async pulse comes when the counter is transitioning from 0xFFFFFFFF to
0x00000000. All bits are changing state. Even without metastability
involved, i.e. assuming you don't hit the metastability window in any
of the 32 FFs you use for freezing the counter value, you have a
problem which is not a 1 tick problem. This is because the delays of
each bit going from the counter FFs to the freezing register FFs are
never exactly the same, so at the moment of freezing you might sample
e.g. 0xABCDABCD, i.e. something completely unrelated to the value you
would expect. Metastability would only make things worse by making
some of those bits "undefined" for some length of time.

So this is a well understood problem with a standard solution. Designs
which don't use this solution can still function well if the
occurrence I described is not very frequent.  It was said in the other
thread that Brooks Shera got rid of outliers (defined by him as more
than 30 ticks offset) in software. That still leaves a 30 tick
uncertainty for the time tag. So again, there is a proper way of
dealing with metastability, but that does not automatically imply that
designs not using it will malfunction. It depends on how often it
happens and what the specifications are for the given design. Still,
coping with metastability properly is so simple and cheap that there
is really no reason not to do it.

Cheers,

Javier