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 < mag...@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" <mag...@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" <mag...@rubidium.dyndns.org> >>>> To: <time-nuts@febo.com> >>>> Cc: <mag...@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@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@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.