Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Clark, K3IO wrote: > Bruce Griffiths wrote: > > >> The Dallas delay lines aren't all that accurate, you need to calibrate >> them to acheive 1ns accuracy (read the specs) and then you have to >> worry about temperature variations. >> To use them you need to decode the sawtooth correction message from >> the GPS timing receiver. >> If you've decoded this message then you have all the information >> needed to make a software correction to the measured phase error. >> > I need to correct some impressions that seem to have gone astray. To > help me, I refer you to a PowerPoint presentation that I gave to the > technicians and operators at the world's VLBI (Very Long Baseline > Interferometry) sites. The presentation is available at > http://gpstime.com as the 2007 version of "Timing for VLBI". > > [Aside -- If you are interested in learning about some of VLBI's > buzz-words, I also gave a tutorial "What's all this VLBI stuff, anyway?" > that was intended as a view of the Physics and Radio Astronomy of making > VLBI measurements. Some people find my de-mystifying of Heisenberg's > Uncertainty Principle interesting -- especially the Schroedinger quotes > at #21. This "plays" best if you view it as a PPT presentation.] > > Starting on Slide #20, I describe the reason that the Motorola receivers > have the sawtooth "dither". Basically clock edges of the receiver's 1PPS > pulse are locked to a crystal oscillator in the receiver and that > oscillator is on a frequency that is not neatly commensurate with the > "true" second marks. As has been pointed out in these discussions, > Motorola reports an estimate of the error on the NEXT 1PPS tick. Slides > 21 and 22 show some of the pathological example we have seen on typical > receivers. AFAIK, all the bizarre behavior has been traced to firmware > problems. > > The reason for making sawtooth corrections (and not simply averaging > multiple samples) can be seen in the "hanging bridges" (22:34 to 22:36 > on #22, 01:04:30 to 01:05:30 on #23) when the 1PPS signal went thru a > zero-beat. For these 1-2 minute windows, all statistical averaging > breaks down and typical GPSDO's perform badly. However, when the > sawtooth is corrected in software (blue line on #23) the resulting > "paper clock" is well behaved (at ~1.5 nsec RMS level). > > Slides #24 & #25 describe an annoying problem in VLBI -- we want to be > able to blindly trust ANY 1PPS pulse whenever (rarely) we need to reset > the "working" VLBI clock. Slide #26 is the block diagram of the circuit > that Rick has implemented in his newest clock. Slide #29 shows a (more > noisy than normal) comparison between the hardware ans software > correction performance with only 0.3 nsec RMS noise between the two. > > Bruce noted a misconception that may have come from our earlier > implementation of the correction algorithm. What we found was that EVERY > sample of the 1 nsec step Dallas/Maxim delay line showed considerably > more scatter.What we found, on closer examination, was that it seems > that the DSI delay line chip defines "one nsec" about 10% differently > than Motorola's "one nsec". After correcting for this "definition" > problem, as you see in #30, the hardware and software correction are in > agreement with an observed regression coefficient of 0.9962 (on this > sample, which shows correlation coefficient > 0.999) and good tracking > between samples. > > Bruce also made some disparaging comments on the stability of the delay > lone. I can say that we have not seen any stability problems at all. > This is quite logical when you carefully reverse engineer the DSI chip > based on its data sheets. The delay inside the chip is really an analog > delay. The 8-bit number you sent to the chip programs a D/A converter to > produce a (256 step) constant current source. When the input pulse is > applied to the DSI delay line, the constant current charges an on-chip > capacitor. When the resulting ramp matches the level defined by a > comparator, the output is changed. The comparator level and capacitor > value are temperature compensated by a second, fixed rate ramp. This is > pretty much the same thing that you all have been described here. > > I know exactly how these delay devices work, the problem is that using them in this way relies on a one time calibration of the device delays, it would be far better if delay calibration cycles could be interspersed between PPS transitions. This would technique would cope with any ageing or temperature drifts. The variable slope technique (see Dallas application note AN107) for setting the delays used in these devices means that the delay jitter increases faster with increasing delay than in the equivalent fixed slope variable threshold ramp timed delay technique. The DS1020 -15-datasheet specifies a 4ns max deviation from the programmed delay. There is no statement on the datasheet as to if this error is due to scale factor error, offset error or integral
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Tom Clark, K3IO wrote: > >> Why add the cost of a programmable delay line when the additional cost >> of correction is a few lines of code? >> They also don't remove the requirement for subnanosecond phase >> measurement resolution and accuracy. >> > But the receiver itself has intrinsic noise at the nsec level. You are > better off by averaging sawtooth corrected (either hardware or software) > measurements to achieve sub-nsec precision; IMHO, sub-nsec individual > measurements aren't needed. Surely you don't plan to tweak a GPSDO every > second! A good xtal is much better than ANY GPS rcvr on times of 1-100 sec. > >> Whilst an analog phase lock loop can have the necessary resolution >> they are somewhat impractical for the relatively long averaging times >> required when optimally disciplining a good OCXO. >> >> The computational load isnt that severe as you only make one phase >> measurement per second. >> >> One of the simplest ways of achieving subnanosecond phase measurement >> resolution is to feed a quadrature phase 10MHz sinewave into a pair of >> simultaneous sampling ADCs (MAXIM have suitable devices prices seem >> reasonable). The sinewaves are sampled at the leading edge of the GPS >> receiver PPS signal. >> The ADC outputs can then be used to determine where in the cycle the >> PPS edge occurred. This in effect is a subnanosecond resolution phase >> detector with a range of 100nsec. The range can easily be extended by >> using a small CPLD which incorporates a couple of synchronisers (one >> clocked by the positive slope transition of the 10MHz signal and the >> other clocked by the negative slope xero crossing transition of the >> 10MHz signal) The output of both synchronisers samples the value of a >> synchronous counter which is clocked by the positive slope zero >> crossing of the 10MHz sinewave. Software then sorts out which latched >> count is most reliable (the synchroniser whose clock edge is furthest >> from the PPS transition). This sounds complex but it isnt, especially >> if you select the right PIC (or other micro) with built in counters >> (PIC18F4550?) that can be sampled by an external transition (output of >> a synchroniser). The counter need only be an 8 bits counter. >> > This sure sounds like a more complicated measurement than is necessary > to me. If you have a 10 MHz oscillator, simply feed it into the "D" > input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of > the latch is a 0 or 1 depending on the precise phase of the oscillator. > You want this latched 0/1 measurement to average to ½ over a long term > (seconds). As the statistics deviate from a 50/50 split, you tweak the > oscillator. The ~1 nsec of residual noise from the sawtooth corrected > GPS rcvr acts a natural dither. No counters, no ramps, no big A/D > converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase > ambiguity) is too fine for your oscillator, then divide it to 5 MHz > (=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in > a xtal that is off by 1:10e6. > Very nice technique, much better to make use of the receiver noise if you can. In this case hardware correction of the PPS error is of course essential. In essence this technique implements a servo with a narrow proportional band of a few nanoseconds the width of the proportional band being determined by the corrected PPS signal noise characteristics. Outside the proportional band the servo saturates but retains the sign of the phase error. As the noise of the receiver increases so does the width of the proportional band. How then does one then actually measure the receiver timing noise, if one wishes to detect when it deteriorates to a point where it is prudent to go into holdover mode? Perhaps a chain of (3) flipflops whose D inputs are driven by the OCXO derived (10MHz, IMHz, etc) frequency and the clock inputs of which are driven by successively delayed (stable delay) versions of the PPS edge. For example the first flipflop is clocked by the PPS edge, the second fliflop is clocked by the PPS edge delayed by say T ns, and the third flipflop is clocked by PPS delayed by 2T ns. Follow these flipflops by a set of synchronisers. Lock the OCXO so that the 2nd Flipflop has 50% probability of being either 1 or 0. The probability of occurrence of say a logic 1 at the outputs of the other first and third flipflops can then be used to monitor the receiver timing noise level. Alternatively the D inputs to the flipflops could be successively delayeed by T ns whilst all flipflops are clocked by the PPS signal. Surely it would be better to use a synchroniser and/or a flipflop/latch with extremely short regeneration time constant to ensure that the probability of metastable states is insignificant. In this case subsequent stages of the synchroniser could be clocked by delayed (fixed non critical delay) versions of the PPS transition as waiting several seconds f
Re: [time-nuts] Software Sawtooth correction prerequisites?
Lester I have no idea you'll need to contact Acam direct. http://www.acam.de Bruce Lester Veenstra M0YCM K1YCM wrote: > What is the cost of the two channel pci system, if you happen to have the > price in hand. If not, I will ask direct. > > Full Name: Lester B Veenstra > Job Title: Communication Sys Des Engr Sr Stf > Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) > Company:Integrated Systems & Solutions > > Business Address: > > Lockheed Martin IS&S > PSC 45 Box 781 > APO AE 09468 > > Home Address Address: > > Dawn Cottage > Norwood, Harrogate > HG3, 1SD UK > > Telephones: > > Office 940-6456 > > Office +44-(0)1423-846-385 > > Home: +44-(0)1943-880-963 > > UK Cell +44-(0)7716-298-224 > > US Cell +1-240-425-7335 > > Jamaica+1-876-352-7504 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dr Bruce Griffiths > Sent: Saturday, May 12, 2007 7:00 AM > To: Tom Van Baak; Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? > > Tom Van Baak wrote: > >>> Define cheap. >>> You can already get essentially single chip TICs with a resolution (and >>> accuracy) better than 100ps for around 100 Euros or so. >>> >>> >> Has anyone in the group tried one of these? I would very >> much like to see the results. >> >> > > All except Xavier seem to have shied away from obtaining these on cost > grounds and the need to layout a 4 layer PCB. > Although the vendor does offer an evaluation system (External box plus > card plugs into PC with fat multiconductor SCSI type (but not SCSI > signalling)cable connecting the two), too expensive for general use but > perhaps useful for performance evaluation. > The above price was for an earlier version the later reduced cost higher > resolution version (range 5 nanosec - 4millisec) should be cheaper. > The range can easily be extended to years if required (using CPLD > counters (or even a PIC with built in counters - eg PIC18F4550) + > software+ 74AC164). > > Bruce > ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Will do Likes like an interesting product line Full Name: Lester B Veenstra Job Title: Communication Sys Des Engr Sr Stf Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) Company:Integrated Systems & Solutions Business Address: Lockheed Martin IS&S PSC 45 Box 781 APO AE 09468 Home Address Address: Dawn Cottage Norwood, Harrogate HG3, 1SD UK Telephones: Office 940-6456 Office +44-(0)1423-846-385 Home: +44-(0)1943-880-963 UK Cell +44-(0)7716-298-224 US Cell +1-240-425-7335 Jamaica+1-876-352-7504 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr Bruce Griffiths Sent: Saturday, May 12, 2007 10:12 AM To: Discussion of precise time and frequency measurement Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Lester I have no idea you'll need to contact Acam direct. http://www.acam.de Bruce Lester Veenstra M0YCM K1YCM wrote: > What is the cost of the two channel pci system, if you happen to have the > price in hand. If not, I will ask direct. > > Full Name: Lester B Veenstra > Job Title: Communication Sys Des Engr Sr Stf > Department: 6L01 Site Operations Collaboration and Reach-Back (SOCAR) > Company:Integrated Systems & Solutions > > Business Address: > > Lockheed Martin IS&S > PSC 45 Box 781 > APO AE 09468 > > Home Address Address: > > Dawn Cottage > Norwood, Harrogate > HG3, 1SD UK > > Telephones: > > Office 940-6456 > > Office +44-(0)1423-846-385 > > Home: +44-(0)1943-880-963 > > UK Cell +44-(0)7716-298-224 > > US Cell +1-240-425-7335 > > Jamaica+1-876-352-7504 > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dr Bruce Griffiths > Sent: Saturday, May 12, 2007 7:00 AM > To: Tom Van Baak; Discussion of precise time and frequency measurement > Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? > > Tom Van Baak wrote: > >>> Define cheap. >>> You can already get essentially single chip TICs with a resolution (and >>> accuracy) better than 100ps for around 100 Euros or so. >>> >>> >> Has anyone in the group tried one of these? I would very >> much like to see the results. >> >> > > All except Xavier seem to have shied away from obtaining these on cost > grounds and the need to layout a 4 layer PCB. > Although the vendor does offer an evaluation system (External box plus > card plugs into PC with fat multiconductor SCSI type (but not SCSI > signalling)cable connecting the two), too expensive for general use but > perhaps useful for performance evaluation. > The above price was for an earlier version the later reduced cost higher > resolution version (range 5 nanosec - 4millisec) should be cheaper. > The range can easily be extended to years if required (using CPLD > counters (or even a PIC with built in counters - eg PIC18F4550) + > software+ 74AC164). > > Bruce > ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Clark, K3IO wrote: > If you have a 10 MHz oscillator, simply feed it into the "D" > input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of > the latch is a 0 or 1 depending on the precise phase of the oscillator. > You want this latched 0/1 measurement to average to ½ over a long term > (seconds). As the statistics deviate from a 50/50 split, you tweak the > oscillator. The ~1 nsec of residual noise from the sawtooth corrected > GPS rcvr acts a natural dither. No counters, no ramps, no big A/D > converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase > ambiguity) is too fine for your oscillator, then divide it to 5 MHz > (=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in > a xtal that is off by 1:10e6. > Tom How does one do robust statistical filtering of outliers when one uses this technique?? Bruce > I hope these comments helped a bit -- 73, Tom > ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Jim Miller wrote: > My first post...newbie...be gentle... > > I spent the last several evenings reading the archives and saw mention of > sawtooth error correction in software. Since the corrections to be applied > are on the order of 1e-9 seconds it would seem that the phase detector > outputs to which these are applied must be similar in resolution. > > That would seem to require a pretty hefty phase detector and a pretty > substantial computing resource. Doesn't sound inexpensive. Is there a way > around this? > > OTOH, the Dallas Semi delay line pushes the "computation" out into the input > of the phase detector at the cost of a $17 chip (1k qty) which in small > quantities is likely $50 or so. This would seem to allow for a wider variety > of phase measurement techniques. > > Do I have this right? > > tnx > > jim miller > ab3cv > > > ___ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > Jim DS1021-15 (SOIC package) price is about $31 (1 off) from the Maxim-Dallas on line shop Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
$31 is certainly a reasonable price and would allow flexibility in the phase comparator design. I had forgotten that Maxim had a direct sale page. My bad... tnx jim miller ab3cv - Original Message - From: "Dr Bruce Griffiths" <[EMAIL PROTECTED]> To: "Jim Miller" <[EMAIL PROTECTED]>; "Discussion of precise time and frequency measurement" Sent: Saturday, May 12, 2007 9:18 AM Subject: Re: [time-nuts] Software Sawtooth correction prerequisites? Jim DS1021-15 (SOIC package) price is about $31 (1 off) from the Maxim-Dallas on line shop Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
I got a few of them off eBay a long time ago, it doesn't appear the seller has any more of them (they were removed from some other equipment IIRC). I still have two of the Superstar II receivers. They are older OEM models with the 4mb flash (all the new firmwares require the 8mb flash) so they are not firmware upgradeable. I scrounged up some PDFs with basic info, their pinout is very similar to the older Rockwell Jupiter receivers. Anyhow, yes they do have the Rakon 10 MHz TCXO on them. I was going to do something with these, but I know I'll never get around to it and I'm sure one of you guys could put them to better use. $25 shipped takes the pair of receivers and a pair of 9" MCX-SMA pigtails. Contact me off-list... first come first serve. Jason > The Novatel SuperstarII receivers use an on board Rakon 10MHz TCXO (made > a little (120km) to the North of me) local oscillator which can be > disconnected with relatively little surgery and replaced with a piece of > thin coax and a connector. However the required amplitude is relatively > small - easily fixed with a pair of resistors - typically the output > from the onboard TCXO itself has to be attenuated. > Magnus acquired some of these cheaply, however even the new price isn't > too steep. UNSW has used these receivers in geodetic survey/monitoring > applications. The code phase field data from some of these exhibits > encouraging stability (about 5 -10x better than the oscillator specs) > when averaged over a few seconds even with the standard TCXO. > > If you want to roll your own GPS receiver the MITEL/ZARLINK chipsets use > a 10MHz reference. ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
> This sure sounds like a more complicated measurement than is necessary > to me. If you have a 10 MHz oscillator, simply feed it into the "D" > input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of > the latch is a 0 or 1 depending on the precise phase of the oscillator. > You want this latched 0/1 measurement to average to ½ over a long term > (seconds). As the statistics deviate from a 50/50 split, you tweak the > oscillator. The ~1 nsec of residual noise from the sawtooth corrected > GPS rcvr acts a natural dither. No counters, no ramps, no big A/D > converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase > ambiguity) is too fine for your oscillator, then divide it to 5 MHz > (=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in > a xtal that is off by 1:10e6. This sounds really simple and irresistible. Have you or Rick tried it out? I see instead of a TIC (Time Interval Counter) you have a TAC (Time Average Controller ;-) Not just GPS 1PPS noise but any oscillator noise (jitter), if large enough, is also a source of natural dither. Sounds like this design would be especially ideal for a low-end GPSDO; i.e., one that only needs to be accurate to 10^-9 or 10^-10. Did you envision that the OCXO EFC would be driven by a statistics-collecting microprocessor and a high-resolution DAC? Or is there some clever way to tie statistical results of the D-latch to the EFC and avoid the DAC too? /tvb ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
The statement that Dallas' version of the nanosecond differs by 10% from Motorola's is somewhat disconcerting until one analyses how the delay generator works. Simplified description Aside from the contribution from internal logic propagation delays Delay = Constant*RC, Where R is the value of a resistor that determines the current used to charge a capacitor and the constant is determined by resistor ratios. Thus a naive implementation may use 256 equal resistors (r) connected in series with a set of switches used to select the the required resistance value (Nr) in 256 nominally equal steps. The delay would then be proportional to N. Unfortunately the ramp slope would vary over a range of 256 to 1 as would the current. The current mirror used in the actual circuit may have some dificulty in operating accurately over a current range of 256:1. Also the power dissipation in some of the resistors in the string would vary over a large range. The large range (256:1) in the ramp slew rate seen by the comparator would lead to significant variations in the comparator delay. Fortunately if the effective value of the resistor corresponding to N=0 is made somewhat larger (=Ro) than r then although the N=0 delay will increased, the range of currents seen by the current mirror and the corresponding slew rates seen by the comparator can be reduced significantly improving the performance and reducing the variation in resistor dissipation. This implementation should be inherently monotonic despite variations in r and Ro. The effective RC product and the corresponding delay can be designed to have a low temperature coefficient. The RC product will vary from lot to lot and this variation can be compensated by resistor trimming. There are other schemes other than a series resistor string that can be used, however most of these are not inherently monotonic and resistor trimming to correct this error as well as the scale error may be necessary. The attached plot of the error of a typical DS1020-15 illustrates that the integral non linearity of the delay may amount to several nanoseconds worst case. This indicates that if one uses say 30ns of the range to correct for the sawtooth error of an M12M or equivalent GPS timing receiver, that a typical correction error due to the intergral non linearity of the DS1020-15 may be as large as 1ns. However this can be reduced significantly by calibration or perhaps by just calibrating the gain. However unless an actual calibration or parameter fitting to a more elaborate model for the INL other than just a change of scale factor the specified data sheet maximum value for the delay it is unlikely that a mere adjustment of the scale factor will ensure that the delay error of every DS1021-15 that meets its datasheet specification will be less than 1 nanosecond. The optimum scale factor may also vary from wafer to wafer as well as within the wafer. Thus whilst it is highly likely that calibrating the delay and using a lookup table or a model for the INL using several adjustable parameters will allow a programmed delay error of under 1ns, it is unlikely that merely adjusting the "gain" will reduce the programmed delay error to under 1ns for all DS1021-15s ever produced that meet the datasheet specifications. More detailed <>___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] Software Sawtooth correction prerequisites?
Tom Van Baak wrote: >> This sure sounds like a more complicated measurement than is necessary >> to me. If you have a 10 MHz oscillator, simply feed it into the "D" >> input into a latch clocked by the de-sawtoothed GPS 1PPS. The output of >> the latch is a 0 or 1 depending on the precise phase of the oscillator. >> You want this latched 0/1 measurement to average to ½ over a long term >> (seconds). As the statistics deviate from a 50/50 split, you tweak the >> oscillator. The ~1 nsec of residual noise from the sawtooth corrected >> GPS rcvr acts a natural dither. No counters, no ramps, no big A/D >> converter -- it couldn't be simpler! And if the 10MHz (=> 100 nsec phase >> ambiguity) is too fine for your oscillator, then divide it to 5 MHz >> (=>200 nsec) or 1 MHz (=> 1µsec). This should be good enough to pull in >> a xtal that is off by 1:10e6. >> > > This sounds really simple and irresistible. Have you or Rick > tried it out? I see instead of a TIC (Time Interval Counter) > you have a TAC (Time Average Controller ;-) > > Not just GPS 1PPS noise but any oscillator noise (jitter), if > large enough, is also a source of natural dither. Sounds like > this design would be especially ideal for a low-end GPSDO; > i.e., one that only needs to be accurate to 10^-9 or 10^-10. > > Did you envision that the OCXO EFC would be driven by a > statistics-collecting microprocessor and a high-resolution > DAC? Or is there some clever way to tie statistical results > of the D-latch to the EFC and avoid the DAC too? > > /tvb > > > > ___ > time-nuts mailing list > time-nuts@febo.com > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > > Tom A D flipflop is a better choice than a transparent latch. If the PPS signal also interrupts the micro, the built in interrupt synchroniser will ensure sufficient delay that when the output of the D flipflop is sampled the probability of its output being in a metastable state will be extremely low particularly if a 74AC74 or faster flipflop is employed. Bruce ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
