Re: [time-nuts] Brooks Shera
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:
Another great ham passes on, I'm sorry I never had a chance to meet him.
Definitly a sad day....
Is the GPS controller that Brooks published still useful today, or has
it been
superseded by something newer?
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:
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:
Another great ham passes on, I'm sorry I never had a chance to meet him.
Definitly a sad day....
Is the GPS controller that Brooks published still useful today, or has
it been
superseded by something newer?
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 lack of synchronisers when crossing clock domains is a design flaw
that should be corrected.
Bruce
I think with these it becomes obvious where the problem lies and what
the solution is.
Attila Kinali
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:
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?
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 think with these it becomes obvious where the problem lies and what
the solution is.
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?
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 06:56:30 -0700
"Tom Van Baak" tvb@LeapSecond.com wrote:
I think with these it becomes obvious where the problem lies and what
the solution is.
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?
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
On Mon, 25 Mar 2013 18:56:34 +0100
Attila Kinali attila@kinali.ch wrote:
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.
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
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).
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:
Actually, most modern FFs are hardened against metastability so often a
single synchronizer will do especially if it is feeding a synchronous
circuit.
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:
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).
But these numbers don't go directly to the PI loop, there is a
software layer between that can inspect for outliers.
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:
-
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. -
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:
On Mon, 25 Mar 2013 11:18:06 -0700
Chris Albertson albertson.chris@gmail.com wrote:
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).
But these numbers don't go directly to the PI loop, there is a
software layer between that can inspect for outliers.
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:
-
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. -
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
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, 25 Mar 2013 14:03:23 -0400
David McGaw n1hac@alum.dartmouth.org wrote:
Actually, most modern FFs are hardened against metastability so often a
single synchronizer will do especially if it is feeding a synchronous
circuit.
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
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
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
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.
--
Chris Albertson
Redondo Beach, California
On Mon, Mar 25, 2013 at 12:45 PM, David McGaw n1hac@alum.dartmouth.org 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
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:
On Mon, Mar 25, 2013 at 12:45 PM, David McGawn1hac@alum.dartmouth.org 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
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
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.
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:
On Mon, Mar 25, 2013 at 12:45 PM, David McGawn1hac@alum.dartmouth.org
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
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
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
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:
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:
On Mon, Mar 25, 2013 at 12:45 PM, David McGawn1hac@alum.dartmouth.org
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
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
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
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.
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.
--
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:
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:
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:
On Mon, Mar 25, 2013 at 12:45 PM, David McGawn1hac@alum.dartmouth.org
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
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
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
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.
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.
--
Chris Albertson
Redondo Beach, California
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.
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
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:
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…..
Looking at the source code...
-
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 -
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