[time-nuts] GPSDO & Crystal Aging
magnus at rubidium.dyndns.org
Sat Apr 12 18:09:53 EDT 2014
On 11/04/14 15:33, Tom Van Baak wrote:
> 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.
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.
More information about the time-nuts