I have done several GPSDOs using the NAVMAN receiver, so I add a few comments to the discussion: 1. Both the G3RUH ([1]http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm) and I2PHD ([2]http://gpsdo.i2phd.com/) designs use 74HC390 divider chips; I also tried them. What I found was that the 74HC390 dividers had very strong temperature sensitivity, amounting to well over 100 nsec with a mild diurnal room temperature change. Of course this is due to the 'HC390s being a cascaded series of ripple counters. To go from 10 MHz to 10 kHz, you end up with 12 CMOS stages being cascaded. My solution was to replace the 'HC390 change with the elegant PIC-based divider chain invented by Tom van Baak. This uses the 10 MHz signal as the PIC's clock, and the tight code based on a fixed number of wait states makes a fully synchronous divider. I was unable to measure ANY temperature effects. The PIC requires less real estate than the 'HC390s and is also quite cost effective. 2. I did a lot of work to optimize the integrator time constants. What ended up dominating the stability was the "hanging bridges" that result from "zero beats" when the sawtooth error on the timing pulses is NOT dithered for several seconds. I ended up with best performance with a "lag" analog time constant of ~10 seconds and a "lead" of ~1 second. This required the use of an op amp in the analog feedback leg and high quality polystyrene capacitors in the RC network. 3. My design was also made more complicated because the long time constant led to a very long lock-up time. So I developed a simple phase/frequency lock detector that included a "gear shift" between the fast and slow time constant states. This made use of the fact that TvB's divider could be repeatably reset to acquire approximate time lock before the phase steering clicked in. 4. TvB asked about the properties of the Jupiter-T 10 kHz output. Here's what I remember: * The 10 kHz output shows the same ±~13 nsec nsec sawtooth "dither" because timing pulses are synchronous with the edges of a ~40 MHz clock in the GPS receiver. The older ONCORE had ± 52 nsec dither because it came from a ~9.5 MHz clock. The newer M12+ is like the Jupiter-T with a ~40 MHz clock. * The Jupiter-T receiver, when operating in the position hold (that I often call the "Zero-D Timing") mode works quite well. The Jupiter-T was made to be a FFF (Form, Fit & Function) replacement for the older 8-channel Oncore, and it supports most of the Motorola (@@Xy) instructions. It is a 12 channel receiver which will use all the satellites it can find. Rick Hambly's TAC-32 software properly drives the Jupiter-T, and my old TAC-2 board will properly mount a Jupiter-T (except that the 10 kPPS output needs to be added on the 10-pin header). * A major difference from the ONCORE is that the Jupiter-T does NOT return the timing error on the next pulse (in the @@Ea message), so the dither cannot be removed in software. This is because the Jupiter-T achieves its timing output by twiddling the rate of a numerically controlled oscillator (NCO) to make the next pulse be as correct as possible; the ONCORE counts the integrated pulses . This then results in the Jupiter-T not knowing its constant of integration, and hence it is not able to predict the error.
In short -- The Jupiter-T is a good timing receiver. Hope these factoids helped -- Tom References 1. http://www.jrmiller.demon.co.uk/projects/ministd/frqstd.htm 2. http://gpsdo.i2phd.com/ _______________________________________________ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts