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.
Cheers,
Magnus
_______________________________________________
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.
