The CNT91 is really a CNT90 with some detailed improvements to reduce time-errors to be conform with 50 ps rather than 100 ps resolution.
In the CNT90 the comparators where in the same IC, which caused ground-bounce coupling between channels, but separating them was among the things that went in. Also, improved grounding of the front-plate as I recall it. The core-clock is 100 MHz, giving 10 ns steps or coarse counter, the interpolators then have 10 bits, so while not the full range is being used, some 10-20 ps of actual resolution, but Pendulum engineers consider the RMS performance as they measure the beat frequency sweep over phase states. Cheers, Magnus On 04/26/2018 11:16 PM, Azelio Boriani wrote: > If your hardware is capable of capturing up to 10 millions of > timestamps per second and calculating LR "on the fly", it is not a so > simple hardware, unless you consider simple hardware a 5megagates > Spartan3 (maybe more is needed). Moreover: if your clock is, say, at > most in an FPGA, 300MHz, your timestamps will have a one-shot > resolution of few nanoseconds. Where have you found a detailed > description of the CNT91 counting method? The only detailed > description I have found is the CNT90 (not 91) service manual and it > uses interpolators (page 4-13 of the service manual). > > On Thu, Apr 26, 2018 at 2:45 PM, Bob kb8tq <kb...@n1k.org> wrote: >> Hi >> >> Even with a fast counter, there are going to be questions about clock jitter >> and just >> how well that last digit performs in the logic. It’s never easy to squeeze >> the very last >> bit of performance out ….. >> >> Bob >> >>> On Apr 26, 2018, at 3:06 AM, Azelio Boriani <azelio.bori...@gmail.com> >>> wrote: >>> >>> Very fast time-stamping like a stable 5GHz counter? The resolution of >>> a 200ps (one shot) interpolator can be replaced by a 5GHz >>> time-stamping counter. >>> >>> On Thu, Apr 26, 2018 at 12:28 AM, Bob kb8tq <kb...@n1k.org> wrote: >>>> Hi >>>> >>>> Unfortunately there is no “quick and dirty” way to come up with an >>>> accurate “number of digits” for a >>>> math intensive counter. There are a *lot* of examples of various counter >>>> architectures that have specific >>>> weak points in what they do. One sort of signal works one way, another >>>> signal works very differently. >>>> >>>> All that said, the data you show suggests you are in the 10 digits per >>>> second range. >>>> >>>> Bob >>>> >>>>> On Apr 25, 2018, at 3:01 PM, Oleg Skydan <olegsky...@gmail.com> wrote: >>>>> >>>>> Dear Ladies and Gentlemen, >>>>> >>>>> Let me tell a little story so you will be able to better understand what >>>>> my question and what I am doing. >>>>> >>>>> I needed to check frequency in several GHz range from time to time. I do >>>>> not need high absolute precision (anyway this is a reference oscillator >>>>> problem, not a counter), but I need fast high resolution instrument (at >>>>> least 10 digits in one second). I have only a very old slow unit so, I >>>>> constructed a frequency counter (yes, yet another frequency counter >>>>> project :-). I is a bit unusual - I decided not to use interpolators and >>>>> maximally simplify hardware and provide the necessary resolution by very >>>>> fast timestamping and heavy math processing. In the current configuration >>>>> I should get 11+ digits in one second, for input frequencies more then >>>>> 5MHz. >>>>> >>>>> But this is theoretical number and it does not count for some factors. >>>>> Now I have an ugly build prototype with insanely simple hardware running >>>>> the counter core. And I need to check how well it performs. >>>>> >>>>> I have already done some checks and even found and fixed some FW bugs :). >>>>> Now it works pretty well and I enjoyed looking how one OCXO drifts >>>>> against the other one in the mHz range. I would like to check how many >>>>> significant digits I am getting in reality. >>>>> >>>>> The test setup now comprises of two 5MHz OCXO (those are very old units >>>>> and far from the perfect oscillators - the 1sec and 10sec stability is >>>>> claimed to be 1e-10, but they are the best I have now). I measure the >>>>> frequency of the first OCXO using the second one as counter reference. >>>>> The frequency counter processes data in real time and sends the >>>>> continuous one second frequency stamps to the PC. Here are experiment >>>>> results - plots from the Timelab. The frequency difference (the >>>>> oscillators are being on for more than 36hours now, but still drift >>>>> against each other) and ADEV plots. There are three measurements and six >>>>> traces - two for each measurement. One for the simple reciprocal >>>>> frequency counting (with R letter in the title) and one with the math >>>>> processing (LR in the title). As far as I understand I am getting 10+ >>>>> significant digits of frequency in one second and it is questionable if I >>>>> see counter noise or oscillators one. >>>>> >>>>> I also calculated the usual standard deviation for the measurements >>>>> results (and tried to remove the drift before the calculations), I got >>>>> STD in the 3e-4..4e-4Hz (or 6e-11..8e-11) range in many experiments. >>>>> >>>>> Now the questions: >>>>> 1. Are there any testing methods that will allow to determine if I see >>>>> oscillators noise or counter does not perform in accordance with the >>>>> theory (11+ digits)? I know this can be done with better OCXO, but >>>>> currently I cannot get better ones. >>>>> 2. Is my interpretation of the ADEV value at tau=1sec (that I have 10+ >>>>> significant digits) right? >>>>> >>>>> As far as I understand the situation I need better OCXO's to check if >>>>> HW/SW really can do 11+ significant digits frequency measurement in one >>>>> second. >>>>> >>>>> Your comments are greatly appreciated! >>>>> >>>>> P.S. If I feed the counter reference to its input I got 13 absolutely >>>>> stable and correct digits and can get more, but this test method is not >>>>> very useful for the used counter architecture. >>>>> >>>>> Thanks! >>>>> Oleg >>>>> 73 de UR3IQO >>>>> <1124.png><1127.png>_______________________________________________ >>>>> 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. >>> _______________________________________________ >>> 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. > _______________________________________________ > 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.
