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

Adrian Godwin artgodwin at gmail.com
Sat Oct 8 15:46:28 EDT 2016


Yes, they're at
http://www.ko4bb.com/getsimple/index.php?id=manuals&dir=02_GPS_Timing/Lucent_KS-24361/KS24361-Z3812A-KR92830585-X98_4-A

On Sat, Oct 8, 2016 at 12:00 PM, Magnus Danielson <
magnus at rubidium.dyndns.org> wrote:

> Hi Adrian,
>
> Except what Tom published on the Z3801A there is no more published notes
> as far as I know. I can see what of my project is easy to share though.
>
> Is the images uploaded somewhere?
>
> Cheers,
> Magnus
>
>
> On 10/07/2016 10:06 PM, Adrian Godwin wrote:
>
>> 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.
>>>
>>> _______________________________________________
>> 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.
>


More information about the time-nuts mailing list