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.bori...@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 <kb...@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 <hmur...@megapathdsl.net> wrote: >>> >>> >>> olegsky...@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@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.