[time-nuts] Question about frequency counter testing

Azelio Boriani azelio.boriani at gmail.com
Fri Apr 27 10:39:59 EDT 2018


You can measure your clocks down to the ps averaged resolution you
want only if they are worse than your one-shot base resolution one WRT
the other. In a resonable time, that is how many transitions in your
2.5ns sampling interval you have in 1 second to have a n-digit/second
counter.

On Fri, Apr 27, 2018 at 4:32 PM, Azelio Boriani
<azelio.boriani at gmail.com> wrote:
> Yes, this is the problem when trying to enhance the resolution from a
> low one-shot resolution. Averaging 2.5ns resolution samples can give
> data only if clocks move one with respect to the other and "cross the
> boundary" of the 2.5ns sampling interval. You can measure your clocks
> down to the ps averaged resolution you want only if they are worse
> than your one-shot base resolution one WRT the other.
>
> On Fri, Apr 27, 2018 at 3:38 PM, Bob kb8tq <kb8tq at n1k.org> wrote:
>> Hi
>>
>> Consider a case where the clocks and signals are all clean and stable:
>>
>> Both are within 2.5 ppb of an integer relationship. ( let’s say one is 10
>> MHz and the other is 400 MHz ). The amount of information in your
>> data stream collapses. Over a 1 second period, you get a bit better than
>> 9 digits per second.  Put another way, the data set is the same regardless
>> of where you are in the 2.5 ppb “space”.
>>
>> Bob
>>
>>
>>
>>> On Apr 27, 2018, at 5:30 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
>>>
>>>
>>> olegskydan at gmail.com said:
>>>> No, it is much simpler. The hardware saves time-stamps to the memory at each
>>>> (event) rise of the input signal (let's consider we have digital logic input
>>>> signal for simplicity). So after some time we have many pairs of {event
>>>> number, time-stamp}. We can plot those pairs with event number on X-axis and
>>>> time on Y-axis, now if we fit the line on that dataset the inverse slope of
>>>> the line will correspond to the estimated frequency.
>>>
>>> I like it.  Thanks.
>>>
>>> If you flip the X-Y axis, then you don't have to invert the slope.
>>>
>>> That might be an interesting way to analyze TICC data.  It would work
>>> better/faster if you used a custom divider to trigger the TICC as fast as it
>>> can print rather than using the typical PPS.
>>>
>>> ------
>>>
>>> Another way to look at things is that you have a fast 1 bit A/D.
>>>
>>> If you need results in a second, FFTing that might fit into memory.  (Or you
>>> could rent a big-memory cloud server.  A quick sample found 128GB for
>>> $1/hour.)  That's with 1 second of data.  I don't know how long it would take
>>> to process.
>>>
>>> What's the clock frequency?  Handwave.  At 1 GHz, 1 second of samples fits
>>> into a 4 byte integer even if all the energy ends up in one bin.  4 bytes, *2
>>> for complex, *2 for input and output is 16 GB.
>>>
>>>
>>> --
>>> These are my opinions.  I hate spam.
>>>
>>>
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at 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 at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.



More information about the time-nuts mailing list