[time-nuts] Measure GPSDO stability with minimum resources?

Fri Oct 7 16:06:12 EDT 2016

Recently, I dumped the ROM from a ks24361. I imagine it's the same or very
similar code. Are there notes published somewhere ? It would be useful to
compare them.

On 7 Oct 2016 7:52 p.m., "Magnus Danielson" <magnus at rubidium.dyndns.org>
wrote:

> Hi Tom,
>
> On 10/07/2016 06:02 PM, Tom Van Baak wrote:
>
>> 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).
>>
>
> 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.
>
> 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.
>>
>
> 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
>
> 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 at rubidium.dyndns.org>
>> To: <time-nuts at febo.com>
>> Cc: <magnus at 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:
>>
>>> 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 ….
>>>
>>
>> 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
>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/m
> ailman/listinfo/time-nuts
> and follow the instructions there.
>