In an earlier post, I have already introduced the Motorola M12+ timing receiver, which is really a nice and affordable gadget for everyone who needs a precise and accurate time signal. Taking about nanoseconds here. All these timing receiver have something called a sawtooth error, linked to their internal clock. See earlier post: M12 perfect time.
Various methods exist to account for this sawtooth error, first and foremost, correction by software. However, I felt the need for a hardware solution here, to simplify the usage of the 1 pps trigger as a reference signal for phase measurements, and other purposes where the recording of sawtooth correction values would be rather troublesome.
With any such attempt at nanosecond scale, considerable thought needs to be put into the system to avoid introducing any errors larger than those we want to correct. In particular, thermal effects can lead to great long-term jitter, aka, randomly wandering phase.
How can we achieve compensation of the sawtooth error? Well, rather easily, by introducing a variable delay element in the signal chain, and adjusting its delay second by second, to the expected sawtooth error, in ns. Fortunately, the M12+ can be programmed to send out a message, called @@Hn TRAIM Status Msg, which provides, every second, the expected sawtooth error, of the next second. One single command is need to make the M12+ send out this message, very second, from now and forever, until other instructions received, or until the M12+ backup battery is taken out…
See below diagram, a AVR processor is tapping the TxD line, from the GPS receiver, to any host controller or PC (if connected), and whatever messages are send out are checked for the @@Hn message (and @@Ha message, just to display the current time, UTC, and date, on a LCD display connected to the AVR). Note that this works perfectly fine, even when another host, or PC is used to control/read/monitor the M12+. The M12+ uses 3 V logic, but an AVR input can easily handle this as a valid signal, even with the AVR running at 5 V.
Glad a processor is doing the decoding work… the GPS messages, a bit too cryptic for me:
Rather than implementing a discrete solution with various delay lines as coax cables, switches, etc, Maxim Integrated provides a marvelous chip, a silicon delay line, DS1023 series, at not marginal, but still acceptable cost, USD 8 per piece.
This chip comes in various versions, varying by the delay-per-set, and an 8 bit register, to set the actual delay. Sure, the minimum delay is not “0 ns”, but some odd number, corresponding to the delay of the signal before and after the actual delay line.
According to information found in the datasheet, this chip is trimmed for best accuracy, and high thermal stability. Further documents also say that the thermal drift is non-linear, and that no coefficient can be provided. Rather, the delay is specified as an absolute number, over the full temperature range. Well, fair enough, but what does this mean for our present case and actual device under test? With no information available anywhere, it seems, the only way to find out is to measure it. The datasheet maximum error would be a bit more than we want.
The schematic is nothing to write home about, a 74F04 is used to buffer the input signal, and a the same F04 is used as an output buffer, providing a nice and fast-rise (or, respectively, fast-fall) 1 pps signal.
The only specialty, a thermistor, and two resistors epoxy-glued to the DS1023-50 top surface! This can be used to heat up the device rather quickly, to 60 degC or more, by providing power from a regulated DC power supply.
Note the heating element and the thermistor (a rather small, fast response, 100 kOhm NTC) – red frame.
The test setup – to measure the temperature effects, is running without the GPS, but with a ~1 kHz fast rise-time pulse, from a HP 8012B pulse generator. Both input and output are connected to a HP 5370B Timer Interval Counter. The latter is a great device, single-shot accuracy of 20~30 ps, if you are into any precision timing tasks, very much worthwhile to get one of these, or a Stanford Research Systems SR620. Time intervals are then recorded as averages of 1k measurement, giving very stable readings with high resolution, certainly to 0.01 ns. For the test purposes, the AVR monitoring the RS232 signal can also be programmed via USB, to set any delay value from 0..255, corresponding to a 0..128 ns delay, plus any baseline delay of the gates and the DS1023-50.
All connected to a PC via GPIB, and recording the delay values at various settings.
Rather than many words, please inspect these diagrams, which will give you a feeling of the delay and drift to be expected with temperature cycling of the device at various rates (slow cooling, fast heating, slow heating, etc.). These were all recorded at the maximum delay, register set to 0xff, 255. Diagrams show delay, in ns, vs. time, as MJD.
In absolute numbers, 152.1~152.7 ns variation. Not much. About 1 step. So maybe good enough, and no need to apply any temperature compensation, or to put everything into a thermostated box.
