Hi > On May 14, 2018, at 5:25 AM, Oleg Skydan <[email protected]> wrote: > > Hi Bob! > > From: "Bob kb8tq" <[email protected]> >>> I think it will be more than enough for my needs, at least now. >>> >>>> From the 2.5 ns single shot resolution, I deduce a 400 MHz count clock. >>> >>> Yes. It is approx. 400MHz. >> >> I think I would spend more time working out what happens at “about 400 MHz” >> X N or >> “about 400 MHz / M” ……. > > If such conditions detected, I avoid problem by changing the counter clock. > But it does not solve the effects at "about OCXO" * N or "about OCXO" / M. It > is related to HW and I can probably control it only partially. I will try to > improve clock and reference isolation in the "normal" HW and of cause I will > thoroughly test such frequencies when that HW will be ready.
It’s a very common problem in this sort of counter. The “experts” have a lot of trouble with it on their designs. One answer with simple enough hardware could be to run *two* clocks all the time. Digitize them both and process the results from both. …. just a thought …. You still have the issue of a frequency that is a multiple (or sub multiple) of both clocks. With some care in clock selection you could make that a pretty rare occurrence ( thus making it easy to identify in firmware ….). Bob > > All the best! > Oleg > _______________________________________________ > 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. _______________________________________________ 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.
