DMTD and TICC with YimeLab question
I have a DMTD front end (based upon the William Wriley design) driving a
TAPR TICC and processing the data with TimeLab. I just want to make sure
that I understand how all the pieces fit together and that my results are
correct.
The input signals are at 10MHz and I am using a 10,000,010 Hz offset
oscillator.
This means that I am getting 10 readings per second and that the input
phase difference should be multiplied by 10E6 (one million).
So, if I feed the same signal into both inputs with one delayed 9ns the
TICC (operated in time difference mode) should give a reading of 9x10E-9 x
10E6 = 9ms (9x10E-3).
Now, to make TimeLab give rational results the TICC difference readings
have to be scaled by the DMTD front end multiplication factor (one
million). So, in setting up TimeLab the TICC time difference readings need
to be multiplied by 10E-6. But I think there is a notation problem here -
I represent numbers as
n.n x 10Ey and I think the TimeLab representation is n.nEy (can anyone
confirm this?). This makes things very easy to be off by a factor of 10
(the problem I think I am having).
Also, the TICC has a resolution of about 60ps.When the DMTD front end is
factored in does this mean that the (theoretical) resolution is 60 x
10E-18s? I realize that the noise floor is MUCH higher than this.
Thanks for any insights, or putting me on the right track.
Skip Withrow
Hi Skip,
On Thu, 24 Nov 2022 19:45:21 -0700
Skip Withrow via time-nuts time-nuts@lists.febo.com wrote:
I represent numbers as
n.n x 10Ey and I think the TimeLab representation is n.nEy (can anyone
confirm this?). This makes things very easy to be off by a factor of 10
(the problem I think I am having).
Well, you are using a non-standard notation.
The a E b notation is interpreted as a * 10^b
(see https://en.wikipedia.org/wiki/Scientific_notation#E_notation )
So, your notation using a x 10E b to mean x 10^y is not how people
normally use this notation. Hence the libraries usually used to
read and interpret numbers will not correctly handle your notation.
I would suggest that you switch your notation to what is the "standard".
If you don't have the source of the pogram that generates these numbers,
a simple perl line fixes things:
perl -pe 's/x\s?10E/E/g' <inputfile >outputfile
Attila Kinali
--
Science is made up of so many things that appear obvious
after they are explained. -- Pardot Kynes
Skip,
Most programming languages and computer software, including Stable32 and
TimeLab, use an ascii computer form of scientific notation with an E in
it (lower case e is ok too). So 1 million is 1e6, or 1000e3 or 1000000.
2048 is 2.048e3, and so on. If in doubt use Excel or Python or a
calculator app to compute 1000 × 1000 and it should show 1e6 or 1.0e6 or
maybe 1 × 10^6 or 1.00 × 10^6. So that's the off-by-ten problem you are
having. For a million write 1E6, not 10E6. What you wrote, 10E6, is ten
million.
When you see the E, read it out loud as "times ten to the power". So
1.23E6 is 1 point 2 3 times 10 to the power 6.
I used to nudge members to correct their postings where E-format
scientific notation was misused, or Allan was misspelled Allen, or when
10 MHz was written 10 mhz or 10 Mhz or 10 MHZ, or when ns was spelled nS
or nsec or nsecs, but that turned out to be a losing battle over time.
In many cases the meaning in context was clear even if what was written
was technically incorrect.
On the TICC question, with a DMTD heterodyne factor of one million,
which is 1e6, and a resolution of 60 ps, which is 60e-12 or 6e-11 s, the
theoretical resolution is 6e-11 / 1e6 = 6e-17 s. You could also call
that 60 as (attosecond).
/tvb
On 11/24/2022 6:45 PM, Skip Withrow via time-nuts wrote:
I have a DMTD front end (based upon the William Wriley design) driving a
TAPR TICC and processing the data with TimeLab. I just want to make sure
that I understand how all the pieces fit together and that my results are
correct.
The input signals are at 10MHz and I am using a 10,000,010 Hz offset
oscillator.
This means that I am getting 10 readings per second and that the input
phase difference should be multiplied by 10E6 (one million).
So, if I feed the same signal into both inputs with one delayed 9ns the
TICC (operated in time difference mode) should give a reading of 9x10E-9 x
10E6 = 9ms (9x10E-3).
Now, to make TimeLab give rational results the TICC difference readings
have to be scaled by the DMTD front end multiplication factor (one
million). So, in setting up TimeLab the TICC time difference readings need
to be multiplied by 10E-6. But I think there is a notation problem here -
I represent numbers as
n.n x 10Ey and I think the TimeLab representation is n.nEy (can anyone
confirm this?). This makes things very easy to be off by a factor of 10
(the problem I think I am having).
Also, the TICC has a resolution of about 60ps.When the DMTD front end is
factored in does this mean that the (theoretical) resolution is 60 x
10E-18s? I realize that the noise floor is MUCH higher than this.
Thanks for any insights, or putting me on the right track.
Skip Withrow
All,
What would the SNR of the input to the TICC have to be to have a no
noise in the zero crossing when the time has been stretched by a factor 1e6?
1e6 calculates to 120 dB, 1e17 to 320 dB
Is that a problem when cascading a DMTD and a TICC?
Erik.
On 25-11-2022 11:51, Tom Van Baak via time-nuts wrote:
Skip,
Most programming languages and computer software, including Stable32
and TimeLab, use an ascii computer form of scientific notation with an
E in it (lower case e is ok too). So 1 million is 1e6, or 1000e3 or
1000000. 2048 is 2.048e3, and so on. If in doubt use Excel or Python
or a calculator app to compute 1000 × 1000 and it should show 1e6 or
1.0e6 or maybe 1 × 10^6 or 1.00 × 10^6. So that's the off-by-ten
problem you are having. For a million write 1E6, not 10E6. What you
wrote, 10E6, is ten million.
When you see the E, read it out loud as "times ten to the power". So
1.23E6 is 1 point 2 3 times 10 to the power 6.
I used to nudge members to correct their postings where E-format
scientific notation was misused, or Allan was misspelled Allen, or
when 10 MHz was written 10 mhz or 10 Mhz or 10 MHZ, or when ns was
spelled nS or nsec or nsecs, but that turned out to be a losing battle
over time. In many cases the meaning in context was clear even if what
was written was technically incorrect.
On the TICC question, with a DMTD heterodyne factor of one million,
which is 1e6, and a resolution of 60 ps, which is 60e-12 or 6e-11 s,
the theoretical resolution is 6e-11 / 1e6 = 6e-17 s. You could also
call that 60 as (attosecond).
/tvb
On 11/24/2022 6:45 PM, Skip Withrow via time-nuts wrote:
I have a DMTD front end (based upon the William Wriley design) driving a
TAPR TICC and processing the data with TimeLab. I just want to make
sure
that I understand how all the pieces fit together and that my results
are
correct.
The input signals are at 10MHz and I am using a 10,000,010 Hz offset
oscillator.
This means that I am getting 10 readings per second and that the input
phase difference should be multiplied by 10E6 (one million).
So, if I feed the same signal into both inputs with one delayed 9ns the
TICC (operated in time difference mode) should give a reading of
9x10E-9 x
10E6 = 9ms (9x10E-3).
Now, to make TimeLab give rational results the TICC difference readings
have to be scaled by the DMTD front end multiplication factor (one
million). So, in setting up TimeLab the TICC time difference
readings need
to be multiplied by 10E-6. But I think there is a notation problem
here -
I represent numbers as
n.n x 10Ey and I think the TimeLab representation is n.nEy (can anyone
confirm this?). This makes things very easy to be off by a factor of 10
(the problem I think I am having).
Also, the TICC has a resolution of about 60ps.When the DMTD front end is
factored in does this mean that the (theoretical) resolution is 60 x
10E-18s? I realize that the noise floor is MUCH higher than this.
Thanks for any insights, or putting me on the right track.
Skip Withrow
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hi
If you head back into the archives and search for “Collins Limiter” ( hopefully spelled
correctly ) you will find a whole bunch of info on attempting to convert low frequency
sine waves to fast edge square waves. It suggests that the “SNR” needs to be managed
against the slew rate through a number of stages to do things well.
There are a lot of designs out there that don’t use the Collins approach. There also are
papers from various well known folks calling into question some of the basic assumptions
made in the paper. Possibly somebody will chime in with links to a range of papers.
Bottom line is that you are doing well to get a net of 1x10^-13 out of a system like this.
Getting to 1x10^-14 at one second seems to be out of range for whatever reason.
Bob
On Nov 25, 2022, at 6:39 AM, Erik Kaashoek via time-nuts time-nuts@lists.febo.com wrote:
All,
What would the SNR of the input to the TICC have to be to have a no noise in the zero crossing when the time has been stretched by a factor 1e6?
1e6 calculates to 120 dB, 1e17 to 320 dB
Is that a problem when cascading a DMTD and a TICC?
Erik.
On 25-11-2022 11:51, Tom Van Baak via time-nuts wrote:
Skip,
Most programming languages and computer software, including Stable32 and TimeLab, use an ascii computer form of scientific notation with an E in it (lower case e is ok too). So 1 million is 1e6, or 1000e3 or 1000000. 2048 is 2.048e3, and so on. If in doubt use Excel or Python or a calculator app to compute 1000 × 1000 and it should show 1e6 or 1.0e6 or maybe 1 × 10^6 or 1.00 × 10^6. So that's the off-by-ten problem you are having. For a million write 1E6, not 10E6. What you wrote, 10E6, is ten million.
When you see the E, read it out loud as "times ten to the power". So 1.23E6 is 1 point 2 3 times 10 to the power 6.
I used to nudge members to correct their postings where E-format scientific notation was misused, or Allan was misspelled Allen, or when 10 MHz was written 10 mhz or 10 Mhz or 10 MHZ, or when ns was spelled nS or nsec or nsecs, but that turned out to be a losing battle over time. In many cases the meaning in context was clear even if what was written was technically incorrect.
On the TICC question, with a DMTD heterodyne factor of one million, which is 1e6, and a resolution of 60 ps, which is 60e-12 or 6e-11 s, the theoretical resolution is 6e-11 / 1e6 = 6e-17 s. You could also call that 60 as (attosecond).
/tvb
On 11/24/2022 6:45 PM, Skip Withrow via time-nuts wrote:
I have a DMTD front end (based upon the William Wriley design) driving a
TAPR TICC and processing the data with TimeLab. I just want to make sure
that I understand how all the pieces fit together and that my results are
correct.
The input signals are at 10MHz and I am using a 10,000,010 Hz offset
oscillator.
This means that I am getting 10 readings per second and that the input
phase difference should be multiplied by 10E6 (one million).
So, if I feed the same signal into both inputs with one delayed 9ns the
TICC (operated in time difference mode) should give a reading of 9x10E-9 x
10E6 = 9ms (9x10E-3).
Now, to make TimeLab give rational results the TICC difference readings
have to be scaled by the DMTD front end multiplication factor (one
million). So, in setting up TimeLab the TICC time difference readings need
to be multiplied by 10E-6. But I think there is a notation problem here -
I represent numbers as
n.n x 10Ey and I think the TimeLab representation is n.nEy (can anyone
confirm this?). This makes things very easy to be off by a factor of 10
(the problem I think I am having).
Also, the TICC has a resolution of about 60ps.When the DMTD front end is
factored in does this mean that the (theoretical) resolution is 60 x
10E-18s? I realize that the noise floor is MUCH higher than this.
Thanks for any insights, or putting me on the right track.
Skip Withrow
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
On Fri, 25 Nov 2022 12:39:21 +0100
Erik Kaashoek via time-nuts time-nuts@lists.febo.com wrote:
What would the SNR of the input to the TICC have to be to have a no
noise in the zero crossing when the time has been stretched by a factor 1e6?
1e6 calculates to 120 dB, 1e17 to 320 dB
Is that a problem when cascading a DMTD and a TICC?
There is not a problem when using a TICC as counter for a DMTD. If anything,
it's even a rather good approach. If one wants to build an analog DMTD.
But your calculation is not quite right. 1e6 does not calculate to 120dB.
You have to consider how much noise is in your instrument's bandwidth and
integrate over this noise bandwidth.
See Walt Kester's app note on converting phase noise to jitter for details [1]
On Fri, 25 Nov 2022 09:34:34 -0500
Bob kb8tq via time-nuts time-nuts@lists.febo.com wrote:
If you head back into the archives and search for “Collins Limiter” ( hopefully spelled
correctly ) you will find a whole bunch of info on attempting to convert low frequency
sine waves to fast edge square waves. It suggests that the “SNR” needs to be managed
against the slew rate through a number of stages to do things well.
There are a lot of designs out there that don’t use the Collins approach. There also are
papers from various well known folks calling into question some of the basic assumptions
made in the paper. Possibly somebody will chime in with links to a range of papers.
The main source is Collins' paper [2]. But be aware that his approximation
leads to large errors when first few stages have low amplifications. For an
accurate calculation see [3].
Bottom line is that you are doing well to get a net of 1x10^-13 out of a system like this.
Getting to 1x10^-14 at one second seems to be out of range for whatever reason.
The limit is mostly the SNR of the input signal. Having a 10dBm signal
only leaves you with an SNR of at most 184dB. Assuming only white noise
and a conservative signal bandwidth of 1Hz-1kHz, this leads to a jitter
of 28ns RMS. I.e. proper filtering and amplification is key to achieve
the 1e-13 that is currently state of the art. But narrow band filters
have the problem that they have temperature dependent delay, thus cause
additional instability.
Attila Kinali
[1] "Converting Oscillator Phase Noise to Time Jitter", by Walt Kester, 2008
http://www.analog.com/static/imported-files/tutorials/MT-008.pdf
[2] "The Design of Low Jitter Hard Limiters", by Oliver Collins, 1996
https://doi.org/10.1109/26.494304
[3] "A Fresh Look at the Design of Low Jitter Hard Limiters", by yours truly, 2019
https://people.mpi-inf.mpg.de/~adogan/pubs/IFCS2019_collins_isf.pdf
In science if you know what you are doing you should not be doing it.
In engineering if you do not know what you are doing you should not be doing it.
-- Richard W. Hamming, The Art of Doing Science and Engineering
FWIW, here are year-to-date plots of a BME280 temp/pressure/humidity as
well as an RTD thermometer in my clockroom. I don't know how accurate
the pressure is, but it seems to be stable over time.
I find the difference in temp reported by the BME280 and the RTD
interesting. They are located within a few inches of each other (at the
top in the middle of my racks of equipment, a definite warm spot).
John
On 11/29/22 04:45, Attila Kinali via time-nuts wrote:
On Fri, 25 Nov 2022 12:39:21 +0100
Erik Kaashoek via time-nuts time-nuts@lists.febo.com wrote:
What would the SNR of the input to the TICC have to be to have a no
noise in the zero crossing when the time has been stretched by a factor 1e6?
1e6 calculates to 120 dB, 1e17 to 320 dB
Is that a problem when cascading a DMTD and a TICC?
There is not a problem when using a TICC as counter for a DMTD. If anything,
it's even a rather good approach. If one wants to build an analog DMTD.
But your calculation is not quite right. 1e6 does not calculate to 120dB.
You have to consider how much noise is in your instrument's bandwidth and
integrate over this noise bandwidth.
See Walt Kester's app note on converting phase noise to jitter for details [1]
On Fri, 25 Nov 2022 09:34:34 -0500
Bob kb8tq via time-nuts time-nuts@lists.febo.com wrote:
If you head back into the archives and search for “Collins Limiter” ( hopefully spelled
correctly ) you will find a whole bunch of info on attempting to convert low frequency
sine waves to fast edge square waves. It suggests that the “SNR” needs to be managed
against the slew rate through a number of stages to do things well.
There are a lot of designs out there that don’t use the Collins approach. There also are
papers from various well known folks calling into question some of the basic assumptions
made in the paper. Possibly somebody will chime in with links to a range of papers.
The main source is Collins' paper [2]. But be aware that his approximation
leads to large errors when first few stages have low amplifications. For an
accurate calculation see [3].
Bottom line is that you are doing well to get a net of 1x10^-13 out of a system like this.
Getting to 1x10^-14 at one second seems to be out of range for whatever reason.
The limit is mostly the SNR of the input signal. Having a 10dBm signal
only leaves you with an SNR of at most 184dB. Assuming only white noise
and a conservative signal bandwidth of 1Hz-1kHz, this leads to a jitter
of 28ns RMS. I.e. proper filtering and amplification is key to achieve
the 1e-13 that is currently state of the art. But narrow band filters
have the problem that they have temperature dependent delay, thus cause
additional instability.
Attila Kinali
[1] "Converting Oscillator Phase Noise to Time Jitter", by Walt Kester, 2008
http://www.analog.com/static/imported-files/tutorials/MT-008.pdf
[2] "The Design of Low Jitter Hard Limiters", by Oliver Collins, 1996
https://doi.org/10.1109/26.494304
[3] "A Fresh Look at the Design of Low Jitter Hard Limiters", by yours truly, 2019
https://people.mpi-inf.mpg.de/~adogan/pubs/IFCS2019_collins_isf.pdf
Dear Friends of precise time and frequency measurements,
On Tuesday, 29 November 2022 20:28:23 CET John Ackermann N8UR via time-nuts
wrote:
FWIW, here are year-to-date plots of a BME280 temp/pressure/humidity as
well as an RTD thermometer in my clockroom. I don't know how accurate
the pressure is, but it seems to be stable over time.
I find the difference in temp reported by the BME280 and the RTD
interesting. They are located within a few inches of each other (at the
top in the middle of my racks of equipment, a definite warm spot).
From my own experience, the BME is almost impossible to integrate in circuit
without suffering from self-heating effects: You would have to mount it on its
own PCB far from the other electronics connected to it (Breakout board?) and
preferably power it with a low duty cycle.
As the data sheet says: The point of it having its own temperature sensor is
mainly for compensating its pressure and humidity readings, and for that
purpose self-heating is O.K. as the actual in-package temperature is relevant:
"The integrated temperature sensor has been optimized for lowest noise and
highest resolution. Its output is used for temperature compensation of the
pressure and humidity sensors and can also be used for /estimation/ of the
ambient temperature." (emphasizing by me)
That said, there are even some NMIs using this sensor for logging the
environmental conditions of their UTC labs onto ftp://ftp2.bipm.org/pub/tai/
data/2022/meteo/, namely
Laboratório de Referência de Tempo e Espaço in Sao Carlos, Brazil and
Institute of Metrology of Bosnia and Herzegovina in Sarajevo, Bosnia and
Herzegovina
Cheers,
Jürgen