> It is automatic. Apparently it uses shorter time constants when > first switched on, but lengthens them once it has settled down. The > 8192 period I just discovered by examining the output log data. It > can also be switched into manual mode, whereby the DAC control value > is set from the console. The DAC is fed with a 16-bit control word - > although I don't know if the DAC uses all sixteen bits. > Experimenting with that this weekend, the step-size appears to be > about 6.67 x 10^-14.
In general it's really nice when a GPSDO implements a variable binary windows like this. But, yes, the steps do seem a little large once it settles down. You guessed the step size by manually setting the DAC to a couple of extreme values, right? Can you tell from the insides what GPS engine is used? > I have measured it with a 53132A counter, initially just comparing 10 > MHz outputs from two identical oscillators, but subsequently also > comparing against free-running crystal and rubidium oscillators. The > 1 pps can also be output from these units, and I now have a second > counter comparing that against my free-running rubidium so that I can > indirectly compare the disciplined rubidium against GPS, and cancel > out any wanderings by the free-running ruby. > > Thanks again for your help, > > Peter One other thing you could try, since you have other GPS references and counters available is see if you can find the 1PPS from inside. This will tell you if the GPS engine is working right or not. Did it auto-survey correctly? The lat/lon/alt look OK? Also, another trick to isolate GPSDO problems is to pull the antenna and see if the output gets a lot more stable. By looking at the raw GPS 1PPS, the locked performance, and the holdover performance you get a clue if the problem is with the GPS engine, the phase comparator system, or the LO itself. /tvb _______________________________________________ time-nuts mailing list [email protected] https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
