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. /tvb ----- Original Message ----- From: "Ulrich Bangert" <df...@ulrich-bangert.de> To: "'Discussion of precise time and frequency measurement'" <time-nuts@febo.com> Sent: Friday, April 11, 2014 3:06 AM Subject: Re: [time-nuts] GPSDO & Crystal Aging > Hi Brooke, > >> HP had some way around SA that improved the timekeeping. > > HP called it the "Smartclock Algorithm" and you can find some very basic > information about it here: > > http://www.hpl.hp.com/hpjournal/96dec/dec96a9.pdf > > I have been trying months to find a reference on how it REALLY works but it > seems that this is one of the better kept secrets of HP. > > Best regards > > Ulrich > >> -----Ursprungliche Nachricht----- >> Von: time-nuts-boun...@febo.com >> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Brooke Clarke >> Gesendet: Donnerstag, 10. April 2014 22:56 >> An: Tom Van Baak; Discussion of precise time and frequency measurement >> Betreff: Re: [time-nuts] GPSDO & Crystal Aging >> >> >> Hi Tom: >> >> That makes sense because the GPS was just coming on line and >> not anywhere near a full compliment of satellites and SA >> was on. >> HP had some way around SA that improved the timekeeping. >> Has that ever been disclosed? >> >> Have Fun, >> >> Brooke Clarke >> http://www.PRC68.com >> http://www.end2partygovernment.com/2012Issues.html >> >> Tom Van Baak wrote: >> > Hi Brooke, >> > >> > True, except that in most cases the long-term frequency >> drift rate is >> > so tiny compared to all the short- and mid-term instability >> that it is >> > not worth worrying about. In other words, I agree it is >> modeled as a >> > "linear ramp", but the ramp, even at huge timescales, is so >> close to >> > flat, what's the point? >> > >> > Look at the output of a typical OCXO. Short-term the >> frequency varies >> > by tens or hundreds of ps/s; that's parts in 10^11 or 10^10. By >> > contrast, you have wait an entire day or week before you get that >> > level of frequency error due to drift. >> > >> > When you're in a rowboat outside SF bay, it's the 3 m waves >> every 5 to >> > 10 seconds that you need to steer against, not the 3 m tides that >> > occur gradually over 12 hours. >> > >> > Can someone show me a counter-example? Why is it better to include >> > aging rate into the PID. What quantitative improvement in >> performance >> > does this actually represent? I don't disbelieve it, I just >> have never >> > seen the numbers. >> > >> > One case where knowing the aging rate is important is during >> > multi-hour or multi-day holdover. Perhaps that's why HP >> included the >> > 128-hour circular record of frequency/aging into their firmware. >> > >> > /tvb >> > >> >> Hi: >> >> >> >> AFAICR the HP GPSDOs included the idea of measuring the >> aging rate of >> >> the crystal and applying that correction during holdover. This was >> >> also mentioned by Brooks Shera in relation to his GSPDO >> (there was a >> >> plot), but I don't think it was part of the firmware? >> >> >> >> So rather than just locking the control voltage to the last used >> >> value it would be much better to add a linear ramp. >> >> <http://www.rt66.com/%7Eshera/> >> > _______________________________________________ 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.
