j99harman@gmail.com said:

I think it's worse than that.  You have to hold the temperature constant, and
maybe even the power supply voltage.  A probe on the crystal can might allow
you to correct for temperature.

--
These are my opinions.  I hate spam.

Wouldn't "aging" be the change in the temperature v. frequncy graph over
time?      It is hard to hold temperture constant so maybe record the
function at several different times.

This is one big advantage of using a microprocessor inside the GPSDO, It
can log internal data to either a SD card or use a USB link to a PC to be
recored in log files.  Even my "simple as possible" GPSDO push data to a
PC over USB.  It is easy to glue a temperature sensor to "whatever" and
log it

On Wed, Oct 5, 2016 at 10:14 PM, Hal Murray hmurray@megapathdsl.net wrote:

--

Chris Albertson
Redondo Beach, California

Hi

As normally used, the term “aging” means the long term drift in the frequency of an OCXO.
It is independent of the temperature effects and things like retrace, warmup, and voltage
stability. It is rare that there is any impact on the aging of a properly designed OCXO from
drift of the oven temperature.

Any time you try to estimate (or measure) aging on an OCXO, you will have a hard time
separating it from the other things that affect the frequency of the oscillator. The somewhat
amazing holdover estimates on the HP units are one example of this problem. It does not
take much testing to quickly realize that they are far more often wrong than right on a unit
that has been on power for less than a few weeks.

Bob

said: "The somewhat amazing holdover estimates on the HP units are one example of this problem. It does not take much testing to quickly realize that they are far more often wrong than right on a unit that has been on power for less than a few weeks."
Thank you Bob.  These two sentences clear it all up.  Silly me thinking that the HP units could actually project aging from minimum data.  I can sample every hour and always have the past 24 hours to look at.  In fact, it might even be better to have multiple days in the queue and take a simple average for projection.  Naivety has been my biggest foe in this project.

Bob
 -----------------------------------------------------------------
AE6RV.com

GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info

  From: Bob Camp <kb8tq@n1k.org>

To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Thursday, October 6, 2016 12:24 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?

Hi

As normally used, the term “aging” means the long term drift in the frequency of an OCXO.
It is independent of the temperature effects and things like retrace, warmup, and voltage
stability. It is rare that there is any impact on the aging of a properly designed OCXO from
drift of the oven temperature.

Any time you try to estimate (or measure) aging on an OCXO, you will have a hard time
separating it from the other things that affect the frequency of the oscillator. The somewhat
amazing holdover estimates on the HP units are one example of this problem. It does not
take much testing to quickly realize that they are far more often wrong than right on a unit
that has been on power for less than a few weeks.

Bob

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

One very simple experiment:

Take a HP that has been off power for a year or so. Fire it up and watch it’s predictions
of holdover accuracy. Many of them will go through a “zero” time estimate at one or
two days. At three or four days they are struggling to hit spec (10us). The reason is
pretty simple. The OCXO warmed up and went through an inflection (reversal in direction).
They estimated across the inflection, got zero and passed that on ….

Bob

Hi Hal,

I concur. Here is a nice example for all of you:

http://leapsecond.com/pages/tbolt/TBolt-20a-043.gif

The image shows 20 new Trimble Thunderbolt's being tested for aging in my house. The daily temperature change was about 5 C. Horizontal scale is about 5 days elapsed time. Vertical scale is some ppb or ppt in frequency. The actual numbers aren't important here.

What is instructive about the image is that it shows that "identical" oscillators can have very different tempco's and that oscillators can have very different aging rates. And to your point, it also demonstrates that in many cases an aging rate measurement can take many days before you know if it's just aging or if it's other effects (temperature, voltage, humidity, pressure, tilt, retrace, etc.).

One way to speed up the process is keep the ambient measurement constant as you suggest. Another way is to measure the temperature and then post-process the data for a fit of both temperature and aging. This is also one reason why many GPSDO, like the TBolt, have internal precision thermometers. It helps the user (or optionally the disciplining algorithm) distinguish thermal effects from aging effects.

Just a reminder -- what we usually mean by oscillator "aging" is the long-term secular drift in frequency over time due to physical effects within the oscillator. This systematic effect not only applies to quartz crystals, but also to a lesser degree: rubidium vapor, rubidium & cesium CSAC, and hydrogen maser clocks. By contrast, cesium beam and cesium fountain designs tend not to have aging effects.

Note also that aging rates are traditionally quoted in "per day" units, even though technically the units are seconds per second per second. For example, the aging spec for a 10811A quartz oscillator is 5e-10/day. This does not imply that it is or will be consistent day by day, nor that you are able to measure it within one day. For some oscillators it is not uncommon to have to collect a month of data before you have a clue what the daily aging rate is, how consistent it is, how predictable it is, and so on.

/tvb

----- Original Message -----
From: "Hal Murray" hmurray@megapathdsl.net
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Cc: hmurray@megapathdsl.net
Sent: Wednesday, October 05, 2016 10:14 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?

On 10/6/16 10:11 AM, Chris Albertson wrote:

In fact, many processors like the Freescale parts used on the Teensy
have a temperature sensor built into them - sure it's the die temp, and
it varies with processor loading, but it's better than nothing.

Hi,

On 10/06/2016 08:38 PM, Bob Camp wrote:

Indeed. The Z3801A does a least-square fit and then tries to maintain
that. If done at the wrong time it will be wildly off. I don't remember
the details, but I think I recall that you can trigger the
re-calibration routine which is what you want to do to drive it in the
right direction.

Least-square fitting isn't all that magic and doesn't really require
lots of memory, if you do it properly. You just need the oscillator to
heat up and settle before you attempt to do anything involving long
time-constants. Usually it's not the core algorithms, but the heuristics
that needs to work well.

Cheers,
Magnus

To expand on the replies by Bob and Magnus...

Many years ago after pForth was discovered inside the entire hp 585xx and Z38xx series "SmartClock" GPSDO, Magnus and I worked on the mystery of how the 58503A GPSDO worked so well. HP appears to use a 64-entry circular buffer to record hourly EFC history. Given 64 hours (2.7 days) of data, a GPSDO can make a reasonable prediction of GPS reception or OCXO frequency stability (via ADEV-like statistics) and frequency drift (via linear or quadratic LSQ fits).

Why 64 hours? Well, C programmers working with circular buffers like powers of 2. And from personal experience working with GPSDO I know that high sampling rates are mostly noise and not useful. So hourly EFC data makes sense to me. Also from experience I know that less than one day of EFC data can be misleading. Similarly more than a week of stale past data can also be irrelevant to a prediction of 1 day into the future. So for all these reasons, 64 hours seems an adequate choice.

Note HP and other high-end GPSDO provide both a FFOM (frequency figure of merit) and TFOM (time FOM) value via the SCPI interface. There is lots more info on all these subjects scattered in the time-nuts archives. Here's an example 58503 dump (log1348.txt):

p4th D > pr_efc
efc = 280607.843750

p4th D > pll_rep
start ptr = 7    stop_ptr = 6
max loop time = -1412584448
ffom = 0
tfom = 1.0e-06 secs

p4th D > efc_rep
65.698517 282457.3 3
66.698517 282468.8 3
67.698517 282473.8 3
68.698517 282485.2 3
69.698517 282490.1 3
70.698517 282496.9 3
7.698519 280841.3 3
8.698519 280943.2 3
9.698519 281063.8 3
10.698519 281126.8 3
11.698519 281185.4 3
12.698519 281259.0 3
13.698519 281316.7 3
14.698519 281353.4 3
15.698519 281413.1 3
16.698519 281464.9 3
17.698519 281511.9 3
18.698519 281567.6 3
19.698519 281622.8 3
20.698519 281634.8 3
21.698519 281671.7 3
22.698519 281705.8 3
23.698519 281736.4 3
24.698519 281768.2 3
25.698519 281813.6 3
26.698519 281847.9 3
27.698519 281872.4 3
28.698519 281899.0 3
29.698519 281919.0 3
30.698519 281950.0 3
31.698519 281974.3 3
32.698517 282001.1 3
33.698517 282043.5 3
34.698517 282054.2 3
35.698517 282056.2 3
36.698517 282060.2 3
37.698517 282081.5 3
38.698517 282092.2 3
39.698517 282093.2 3
40.698517 282094.1 3
41.698517 282100.7 3
42.698517 282127.8 3
43.698517 282126.1 3
44.698517 282143.3 3
45.698517 282150.0 3
46.698517 282162.9 3
47.698517 282188.4 3
48.698517 282213.4 3
49.698517 282244.7 3
50.698517 282255.4 3
51.698517 282260.3 3
52.698517 282280.5 3
53.698517 282286.6 3
54.698517 282307.0 3
55.698517 282319.3 3
56.698517 282336.2 3
57.698517 282350.4 3
58.698517 282367.3 3
59.698517 282367.2 3
60.698517 282395.8 3
61.698517 282411.4 3
62.698517 282430.3 3
63.698517 282441.6 3
64.698517 282450.1 3
a= 2.793488e+05 b= -2.535462e+00 c= 7.822419e+02
p4th D >

/tvb

----- Original Message -----
From: "Magnus Danielson" magnus@rubidium.dyndns.org
To: time-nuts@febo.com
Cc: magnus@rubidium.se
Sent: Thursday, October 06, 2016 3:40 PM
Subject: Re: [time-nuts] Measure GPSDO stability with minimum resources?

Hi,

On 10/06/2016 08:38 PM, Bob Camp wrote:

Indeed. The Z3801A does a least-square fit and then tries to maintain
that. If done at the wrong time it will be wildly off. I don't remember
the details, but I think I recall that you can trigger the
re-calibration routine which is what you want to do to drive it in the
right direction.

Least-square fitting isn't all that magic and doesn't really require
lots of memory, if you do it properly. You just need the oscillator to
heat up and settle before you attempt to do anything involving long
time-constants. Usually it's not the core algorithms, but the heuristics
that needs to work well.

Cheers,
Magnus

Hi Tom,

On 10/07/2016 06:02 PM, Tom Van Baak wrote:

I found the big binary dump of the flash on Tom's page, and that he
already found a bunch of strings.

I've spent a lot of time to disassemble and decompile the code,
identifying libc routines, decode the pForth, finding variables etc.
It's a large piece of code to decrypt. The decompiler tool has bugs and
crashes, and it turns out that only the older version is stable enough
to do any useful work, and well there is no source-code. Part of the
problem in decrypting the whole thing is to figure out the pSos
routines. These hurdles aside, it's nice to see the code slowly come
clear, figuring out routine for routine, variable after variable...

It would be interesting to complete it some day, but ah well.

Now, any other number would also work, it would not be too much code to
do properly, but whenever power of 2 is achieveable, it is very handy in
a binary system.

For least-square estimation, higher number of samples provide steeper
filters for the estimated parameters. A simple estimation of degrees of
freedom would be number of samples minus estimated parameters plus one.
However, 64 samples should be enough to get a fair idea with fairly good
confidence interval, so it would kind of work good enough, which is the
purpose here anyway.

It would be nice to recreate more of these algorithms.

Cheers,
Magnus