On Mon, Mar 25, 2013 at 3:02 PM, Bob Camp <[email protected]> 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... 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
