Re: [time-nuts] Question about frequency counter testing
olegskydan@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.
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@megapathdsl.net wrote:
olegskydan@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.
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.
Hi Hal,
Exactly correct. For more details see this posting:
https://www.febo.com/pipermail/time-nuts/2014-December/089787.html
That's one reason for the 1/10/100/1000 Hz PIC divider chips -- to make measurements at 100PPS instead of 1PPS.
JohnA could have designed the TAPR/TICC to be a traditional two-input A->B Time Interval Counter (TIC) like any counter you see from hp. But instead, with the same hardware, he implemented it as a Time Stamping Counter (TSC) pair. This gives you A->B as time interval if you want, but it also gives you REF->A and REF->B as time stamps as well.
You can operate the two channels separately if you want, that is, two completely different DUT measurements at the same time, as if you had two TIC's for the price of one. Or you can run them synchronized so that you are effectively making three simultaneous measurements: DUTa vs. REF vs. DUTb vs.
This paper is a must read:
Modern frequency counting principles
http://www.npl.co.uk/upload/pdf/20060209_t-f_johansson_1.pdf
See also:
New frequency counting principle improves resolution
http://tycho.usno.navy.mil/ptti/2005papers/paper67.pdf
Continuous Measurements with Zero Dead-Time in CNT-91
http://www.testmart.com/webdata/mfr_promo/whitepaper_cnt91.pdf
Time & Frequency Measurements for Oscillator Manufacturers using CNT-91
http://www.testmart.com/webdata/mfr_promo/whitepaper_osc%20manu_cnt91.pdf
Some comments and links to HP's early time stamping chip:
https://www.febo.com/pipermail/time-nuts/2017-November/107528.html
/tvb
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@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@megapathdsl.net wrote:
olegskydan@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.
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@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@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@megapathdsl.net wrote:
olegskydan@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.
Azelio, the problem with that approach is that the more stable and accurate your DUT & REF sources the less likely there will be transitions, even during millions of samples over one second.
A solution is to dither the clock, which is something many old hp frequency counters did. In other words, you deliberately introduce well-designed noise so that you cross clock edge transitions as much as possible. It seems counter-intuitive that adding noise can vastly improve your measurement, but in the case of oversampling counters like this, it does.
/tvb
----- Original Message -----
From: "Azelio Boriani" azelio.boriani@gmail.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Friday, April 27, 2018 7:39 AM
Subject: Re: [time-nuts] Question about frequency counter testing
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@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@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@megapathdsl.net wrote:
olegskydan@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.
Hi
Since you are using averaging to get more bits (much like a CIC ) the idea that you
need noise to make it happen is actually pretty common. There are app notes
coming at it from various directions on ADC’s and SDR going way back (like to
when I was in school …. yikes ….).
What is a bit odd is working your head around it being needed in this case.
It is sort of a 1 bit A/D. There is a very tenuous connection.
Bottom line is still that you are doing signal processing. Since that is what is going
on, you very much need to get into the grubby details to work out what the limitations
(and benefits) will be. It doesn’t look like a radio, but it has a lot of SDR-like issues.
Bob
On Apr 27, 2018, at 11:58 AM, Tom Van Baak tvb@LeapSecond.com wrote:
Azelio, the problem with that approach is that the more stable and accurate your DUT & REF sources the less likely there will be transitions, even during millions of samples over one second.
A solution is to dither the clock, which is something many old hp frequency counters did. In other words, you deliberately introduce well-designed noise so that you cross clock edge transitions as much as possible. It seems counter-intuitive that adding noise can vastly improve your measurement, but in the case of oversampling counters like this, it does.
/tvb
----- Original Message -----
From: "Azelio Boriani" azelio.boriani@gmail.com
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Friday, April 27, 2018 7:39 AM
Subject: Re: [time-nuts] Question about frequency counter testing
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@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@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@megapathdsl.net wrote:
olegskydan@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.
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.
Hi
From: "Bob kb8tq" kb8tq@n1k.org
Sent: Friday, April 27, 2018 4:38 PM
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”.
Thanks a lot for pointing me to this problem! It looks like that was the
reason I lost a digit. The frequency in my experiment appear to be close to
the exact subharmonic of the PLL multiplied reference. It was not less than
2.5ppb off frequency (the difference was approx 0.3ppm), but it still was
close enough to degrade the resolution.
Fortunately it can be fixed in firmware using various methods and I have
made the necessary changes. Here are Allan deviation and frequency drift
plots. The first one with the old firmware, the second one with the updated
firmware that count for the lost of information you mention.
The frequency difference plot also shows the measurement "noise" now is much
lower. It looks like I have got 11 significant digits now and my old OCXOs
are better than manufacturer claims by almost 10 times.
Thanks!
Oleg UR3IQO
Hi
As you have noticed already, it is amazingly easy to get data plots with more than the
real number and less than the real number of digits. Only careful analysis of the underlying
hardware and firmware will lead to an accurate estimate of resolution.
This is by no means unique to what you are doing. Commercial counters are
very often falling into this trap. If you hook up a SR-620 to it’s internal standard,
you will see a lot of very perfect looking digits …. they aren’t real. The HP 5313x
counters have issues with integer related inputs / reference. This isn’t easy.
Bob
On Apr 27, 2018, at 2:47 PM, Oleg Skydan olegskydan@gmail.com wrote:
Hi
From: "Bob kb8tq" kb8tq@n1k.org
Sent: Friday, April 27, 2018 4:38 PM
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”.
Thanks a lot for pointing me to this problem! It looks like that was the reason I lost a digit. The frequency in my experiment appear to be close to the exact subharmonic of the PLL multiplied reference. It was not less than 2.5ppb off frequency (the difference was approx 0.3ppm), but it still was close enough to degrade the resolution.
Fortunately it can be fixed in firmware using various methods and I have made the necessary changes. Here are Allan deviation and frequency drift plots. The first one with the old firmware, the second one with the updated firmware that count for the lost of information you mention.
The frequency difference plot also shows the measurement "noise" now is much lower. It looks like I have got 11 significant digits now and my old OCXOs are better than manufacturer claims by almost 10 times.
Thanks!
Oleg UR3IQO
<1137.png><1138.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.
Hi
I have got a pair of not so bad OCXOs (Morion GK85). I did some
measurements, the results may be interested to others (sorry if not), so I
decided to post them.
I ran a set of 5minutes long counter runs (two OCXOs were measured against
each other), each point is 1sec gate frequency measurement with different
number of timestamps used in LR calculation (from 10 till 5e6). The counter
provides continuous counting. As you can see I reach the HW limitations at
5..6e-12 ADEV (1s tau) with only 1e5 timestamps. The results looks
reasonable, the theory predicts 27ps equivalent resolution with 1e5
timestamps, also the sqrt(N) law is clearly seen on the plots. I do not know
what is the limiting factor, if it is OCXOs or some counter HW.
I know there are HW problems, some of them were identified during this
experiment. They were expectable, cause HW is still just an ugly
construction made from the boards left in the "radio junk box" from the
other projects/experiments. I am going to move to the well designed PCB with
some improvements in HW (and more or less "normal" analog frontend with good
comparator, ADCMP604 or something similar, for the "low frequency" input).
But I want to finish my initial tests, it should help with the HW design.
Now I have some questions. As you know I am experimenting with the counter
that uses LR calculations to improve its resolution. The LR data for each
measurement is collected during the gate time only, also measurements are
continuous. Will the ADEV be calculated correctly from such measurements? I
understand that any averaging for the time window larger then single
measurement time will spoil the ADEV plot. Also I understand that using LR
can result in incorrect frequency estimate for the signal with large drift
(should not be a problem for the discussed measurements, at least for the
numbers we are talking about).
Does the ADEV plots I got looks reasonable for the used "mid range" OCXOs
(see the second plot for the long run test)?
BTW, I see I can interface GPS module to my counter without additional HW
(except the module itself, do not worry it will not be another DIY GPSDO,
probably :-) ). I will try to do it. The initial idea is not try to lock the
reference OCXO to GPS, instead I will just measure GPS against REF and will
make corrections using pure math in SW. I see some advantages with such
design - no hi resolution DAC, reference for DAC, no loop, no additional
hardware at all - only the GPS module and software :) (it is in the spirit
of this project)... Of cause I will not have reference signal that can be
used outside the counter, I think I can live with it. It worth to do some
experiments.
Best!
Oleg UR3IQO
