Re: tvb racal STDEV measurement anamoly
Tvb- what did you conclude caused the stdev measurement anamoly you
referenced at http://leapsecond.com/pages/racal/stdev.htm ?
Regards,
Dwayne Esterline
On Aug 5, 2022 5:59 PM, time-nuts-request@lists.febo.com wrote:
Send time-nuts mailing list submissions to
time-nuts@lists.febo.com
To subscribe or unsubscribe via email, send a message with subject
or
body 'help' to
time-nuts-request@lists.febo.com
You can reach the person managing the list at
time-nuts-owner@lists.febo.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of time-nuts digest..."
Today's Topics:
1. Re: Testing frequency pulling on a DYI counter (Magnus
Danielson)
2. Re: Testing frequency pulling on a DYI counter (Tom Van Baak)
3. GPSDO/GNSSDO project: STM32G4 + u-blox ZED-F9T + TDC7200
(Carsten Andrich)
--------------------------------------------------------------------
--
Message: 1
Date: Fri, 5 Aug 2022 04:25:16 +0200
From: Magnus Danielson <magnus@rubidium.se>
Subject: [time-nuts] Re: Testing frequency pulling on a DYI counter
To: Erik Kaashoek <erik@kaashoek.com>, time-nuts@lists.febo.com
Message-ID: <bacf5887-4505-9777-ed39-09d550033c68@rubidium.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Erik,
Good job there. I suspected that the actual frequency pulling, if
any,
was very low.
Yes, numerical issues in linear regression can be painful.
In the accelerated method I developed, you can engineer the values
to
avoid major numerical issues. Also, you are not the first to have
seen
such issues. This is done first-degree by making sure that things is
accumulated without making any roundings, and secondly by choosing
the
number of samples just right to make the unavoidable final division
not
too terrible to the end result.
It's well known that you get fractional issues too.
Cheers,
Magnus - tired after driving 600+ km
On 8/4/22 20:04, Erik Kaashoek wrote:
Bob, Magnus,
Using a second counter (my famous Picotest U6200A) locked to the
reference output of the DIY counter and measuring the output of
the
signal generator and also set to gate of 10 s it is confirmed that
the
frequency pulling (if any) is below 1E-11 (not more digits on the
display of the U6200A)
Generator is set to 10.000,000,000,2 MHz and is measured as such
by
the U6200A
As there seems to be no frequency pulling I went back to the
simulation of the linear regression algorithm and discovered that
when
there is a integer divide/multiply relation between the internal
reference and the measured frequency the regression looses some
accuracy.
For sure if the reference is close to an integer multiple of the
measured frequency (10 Mhz measured -> 200 MHz reference) the
regression collapses completely in accuracy. I hoped that by
creating
a fractional relation this collapse would not happen at 10 MHz but
is
still there, although much smaller. For this test I'm using a "div
3
times 64 e.g. 213.333,333,333,333... MHz" internal reference
frequency
derived from the external 10MHz reference. Ton van Baak warned me
against using fractional relations in a counter but otherwise it
is
impossible to measure a 10 MHz input signal with any accuracy
without
a HW time to digital as the interpolation no longer works. I can
switch dynamically to 200 MHz or 245 MHz reference and these
produce
much much worse results.
I realize this test only measures if the TCXO used as reference in
the
DIY counter does not show frequency pulling but it does not show
if
the PLL used to convert the 10MHz to 213.333333333... MHz for the
internal counters shows any frequency pulling.
NOt
Erik.
------------------------------
Message: 2
Date: Fri, 5 Aug 2022 05:55:16 -0700
From: Tom Van Baak <tvb@LeapSecond.com>
Subject: [time-nuts] Re: Testing frequency pulling on a DYI counter
To: time-nuts@lists.febo.com
Message-ID: <06dec117-7204-1f78-d802-59f87cb1f55b@LeapSecond.com>
Content-Type: multipart/mixed;
boundary="------------98CC5F907E674D28F1A164FE"
the measured frequency the regression looses some accuracy.
Yes, the hp/Agilent/Keysight 53132A does that too. Here's the
footnote
from the user manual:
http://leapsecond.com/pages/53132/53132-reduced-resolution.gif
And it's not just at 10 MHz. Any fraction or multiple within 600 ppb
is
affected too. What impressed me is that the hp firmware engineers
specifically detected this condition and reduced the number of
digits
displayed accordingly. This avoids the user from getting a false
sense
of precision.
Tom Van Baak warned me against using fractional relations in
a counter but otherwise it is impossible to measure a 10 MHz
input signal with any accuracy without a HW time to digital
as the interpolation no longer works.
Right, which is probably why many high-end commercial counters use
interpolators. But you aren't, and that's ok because your design
spec is
on the order of 9 digits. Keep it simple. Later if you design a 10
or 11
or 12 digit counter you'll have to resort to using h/w interpolation
as
well. Even the Lars GPSDO uses a crude interpolator; it's not that
difficult. Many threads in the time-nuts archive on the topic.
----
Your slow sweeping experiments reminded me of a great example I once
ran
into. So I wrote it up with photos and plots:
http://leapsecond.com/pages/racal/
http://leapsecond.com/pages/racal/stdev.htm
Even if you aren't building a frequency counter, this strange event
is
quite interesting. One of the plots is attached; the rest are in the
URL
above.
/tvb
On 8/4/2022 11:04 AM, Erik Kaashoek via time-nuts wrote:
Bob, Magnus,
Using a second counter (my famous Picotest U6200A) locked to the
reference output of the DIY counter and measuring the output of
the
signal generator and also set to gate of 10 s it is confirmed that
the
frequency pulling (if any) is below 1E-11 (not more digits on the
display of the U6200A)
Generator is set to 10.000,000,000,2 MHz and is measured as such
by
the U6200A
As there seems to be no frequency pulling I went back to the
simulation of the linear regression algorithm and discovered that
when
there is a integer divide/multiply relation between the internal
reference and the measured frequency the regression looses some
accuracy.
For sure if the reference is close to an integer multiple of the
measured frequency (10 Mhz measured -> 200 MHz reference) the
regression collapses completely in accuracy. I hoped that by
creating
a fractional relation this collapse would not happen at 10 MHz but
is
still there, although much smaller. For this test I'm using a "div
3
times 64 e.g. 213.333,333,333,333... MHz" internal reference
frequency
derived from the external 10MHz reference. Ton van Baak warned me
against using fractional relations in a counter but otherwise it
is
impossible to measure a 10 MHz input signal with any accuracy
without
a HW time to digital as the interpolation no longer works. I can
switch dynamically to 200 MHz or 245 MHz reference and these
produce
much much worse results.
I realize this test only measures if the TCXO used as reference in
the
DIY counter does not show frequency pulling but it does not show
if
the PLL used to convert the 10MHz to 213.333333333... MHz for the
internal counters shows any frequency pulling.
NOt
Erik.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com