Hi Brooke,

True, except that in most cases the long-term frequency drift rate is so tiny compared to all the short- and mid-term instability that it is not worth worrying about. In other words, I agree it is modeled as a "linear ramp", but the ramp, even at huge timescales, is so close to flat, what's the point?

Look at the output of a typical OCXO. Short-term the frequency varies by tens or hundreds of ps/s; that's parts in 10^11 or 10^10. By contrast, you have wait an entire day or week before you get that level of frequency error due to drift.

When you're in a rowboat outside SF bay, it's the 3 m waves every 5 to 10 seconds that you need to steer against, not the 3 m tides that occur gradually over 12 hours.

Can someone show me a counter-example? Why is it better to include aging rate into the PID. What quantitative improvement in performance does this actually represent? I don't disbelieve it, I just have never seen the numbers.

One case where knowing the aging rate is important is during multi-hour or multi-day holdover. Perhaps that's why HP included the 128-hour circular record of frequency/aging into their firmware.

/tvb

In message F11541BEBE334AE4881A450859222572@pc52, "Tom Van Baak" writes:

... unless you care about holdovers of multiple days or weeks.

Otherwise:  I fully agree.

--
Poul-Henning Kamp      | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG        | TCP/IP since RFC 956
FreeBSD committer      | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

Hi Tom:

That makes sense because the GPS was just coming on line and not anywhere near a full compliment of satellites and SA
was on.
HP had some way around SA that improved the timekeeping.
Has that ever been disclosed?

Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/2012Issues.html

Tom Van Baak wrote:

Hi Brooke,

HP called it the "Smartclock Algorithm" and you can find some very basic
information about it here:

http://www.hpl.hp.com/hpjournal/96dec/dec96a9.pdf

I have been trying months to find a reference on how it REALLY works but it
seems that this is one of the better kept secrets of HP.

Best regards

Ulrich

Brooke, Ulrich,

Keep in mind the hp SmartClock product line dated from the early-90's and it was one of the first GPSDO on the market. So even simple things like using timing receivers, partial ionospheric correction, sawtooth correction, sub-ns TIC, 1PPS filtering, high-quality OCXO, PIID, DAC dithering, aging history and compensation would qualify as "smart". That's not to say there weren't other tricks going on.

One can learn a lot by playing with SCPI and pForth commands, as has been discussed here over the years. But the point is what was called smart 20 years ago may no longer be that magic. Page 6+ of the Kusters paper is interesting but nothing we don't already talk about weekly here.

Still, this is guessing. How about we find out for sure? Two ideas:

As a block box, a 58503A/Z3801A has only two inputs and two outputs. One input is the 1PPS from the Oncore VP (along with Motorola binary messages). The other input is the 10811. One output is 10 MHz, the other output is 1PPS, which is usually just locked to the phase of the LO. Or you could argue that there is really only one input (GPS 1PPS) and one output (DAC setting).

I propose someone on the list take a working 58503A and replace the Oncore VP with a pseudo GPS timing receiver and maybe also replace the 10811 with a DDS. In a very controlled manner, we can then mimic SA and post-SA jitter from the synthetic 1PPS. We can also mimic various oscillator phase and frequency behavior, including offsets, drift, and jumps using the DDS. The digital input to the DAC/EFC can be monitored to continuously track steering attempts. Or one could do man-in-the-middle games on the data to the DAC and avoid the need for the DDS.

By precisely watching how the SmartClock reacts to precise stimulus over seconds to days we can infer how the algorithms work with high confidence. Any number of people on the list can suggest clever stimulus scenarios to try. Unlike the GPSDO simulator (gpsim1), which can simulate a day in a seconds, the SmartClock experiment would have to run in real-time. That is, to infer how it handles aging prediction and holdover you'd actually have to let it run for a week.

The other idea, which I keep hoping Magnus will do, is to run the firmware under 68k emulation. It would be a large project, but I know he's already spent time on firmware disassembly.

/tvb

----- Original Message -----
From: "Ulrich Bangert" df6jb@ulrich-bangert.de
To: "'Discussion of precise time and frequency measurement'" time-nuts@febo.com
Sent: Friday, April 11, 2014 3:06 AM
Subject: Re: [time-nuts] GPSDO & Crystal Aging

I worked for the HP Santa Clara Division during
the Smart Clock days and knew all the players.
In terms of holdover, the report cited mentions
temperature compensation and "learning" aging.
The temperature compensation was simply a crutch
for the 10811 to fix its tempco problems.  The
E1938A had much better tempco and eliminated the
need for this crutch.  As for the concept of
learning aging is concerned, there was definitely
no "secret sauce" I ever heard about in all the
Smart Clock powerpoints I sat through.  They
simply measured linear aging and possibly its
derivative and hoped that past performance would
predict future results.  It did to some extent,
but how well it worked depended on the particular
crystal.  A misbehaving crystal could not be
fixed by any cleverness in the algorithm.  Attempts
were made to screen crystals to get predictable
ones, and this was someone successful by getting
rid of bad actors.  Still, there was no way to
guarantee that a crystal in the future would never
have a jump or sudden change in aging.  What was
really needed was an ensemble of oscillators, but
that was not economically competitive with rubidium.

Rick

On 4/11/2014 3:06 AM, Ulrich Bangert wrote:

On 11/04/14 15:33, Tom Van Baak wrote:

I have spent a lot of time figuring a whole bunch of things out with the
firmware. Lot's of it is boring like identifying libc routines, others
is more interesting as figuring out the complete tree of SCPI commands
as well as all the pFORTH commands. For each round I make I discover
more, such as the minimum square loop that estimates the linear drift.

Tossing the code into a 68k emulation would be possible, but there is a
bunch of things to simulate in it which relates to the hardware.

There is a general lack of decompiling tools, but I have been able to
make more and more sense of what I got with the available tools.
Unforunatly I have not been able to get the new version of the tool do
anything useful without crashing on me.

Cheers,
Magnus