A precision pendulum clock, and an even more precise time interval counter

Several years ago, I managed to get hold of a rather special piece, an electromechanical master clock, including an Invar temperature compensated precision pendulum. Such clocks were use to control various remote clocks at a train station, in large factories, or huge governmental offices, etc.

These clocks have long been superseeded by crystal oscillators, nevertheless, they are marvelous pieces of precision engineering, and it has been a long held thought of mine to measure how accurately this time-piece is performing, not only long-term (which can be easily timed by daily checks), but also short time, for each individual tic.

The pendulum has a 1/2 period of 0.75 seconds, which is quite common for such kinds of electromechanical clocks. Only the most wealthy businesses opted for a 1 m (full) pendulum, and the instrument is large enough anyway even with 3/4 lenght.

eclk-full-view

The dial is quite beautiful, and every piece appears to be hand-made. There is no date on the clock, but the age of the capacitor suggests 1920~1930 time-frame. I fully rebuild the mechanics about 3 years ago, all degreased, checked, and freshly lubricated with clock oil. There was no need for any other repair, all parts and bearings are still in good shape.

eclk-dial

The clock has a rewind mechanism that is activated once per minute, and also turns a polarity reversal switch, used to steer the remote clocks.

eclk-pickup

To get the signal out of the clock, a small light gate has been setup inside, and a 1 mm wire connected to the lower end of the pendulum (in a way to ensure virtually no movement of the wire). The wire interrupts the light gate approximate at the lowest point of the pendulum, i.e., when it has its highest speed – this is to ensure sharp edges of the signal.

eclk-setup

The setup, currently it is just a set of boards running the TIC4 and LOGGER5 software discussed earlier. A Dell OptiPlex FX160 is used to collect the data, but you can use any kind of computer that can handle RS232 input.

eclk-boards

Here, some first results – more to come. Phase is given in seconds, and horizontal axis shows the tick counts – about 115k ticks per day. The software uses narrow time gating to sort out any incorrect ticks, caused by electrical interference, or other random disturbances. There are no more than 1-2 of such events every day. The phase reconstruction algorithm also handles any missing ticks, and the measurement accuracy is not compromised if one or more tick events are not registered for any random reason.

eclk-phase-drift

Removing the linear part – not a lot of residual phase error left. Plus minus a fraction of a second a day. Now I have slightly slowed down the clock by removing a tuning weight from the pendulum.

eclk-drift-removed-residuals

As described earlier, the LOGGER5 setup also records real-time (not to a high degree of precision, just to keep track of time and day), and temperature/pressure. See earler post, LOGGER5, and TIC4.

eclk-temp

eclk-pressure

Below, and interesting feature of the data – with the re-loading of the clock every minute, there is some slight variation of the frequency. It is really not much considerable the notable “CLICK” with every re-wind, done by a large magnetic coil, actuating a lever mechanism.

minute-variation

The hourly variation, most likely, related to the travel of the minute hand – will check this later, simply by removing the hands!

hourly-variation

Some first correlation of frequency vs. pressure, but will need to collect much more data, and then correlate with pressure and temperature.

phase-res-vs-pressure

Finally, the Allan variation of the clock, determined from a few days worth of data. Short term stability is compromised by the bi-directional pick-up of the pendulum (detection is at the rising edge of the pulse, which corresponds to two different positions of the pendulum relative to the light gate – because of the discrete thickness of the wire).

eclk-allan

Perfect time: upgrade to a Motorola M12+ receiver, and new GPS antenna

For years, a Motorola UT+ GPS timing receiver has served me well as a frequency reference and source of accurate time (and location). While I primarily use a DCF77 locked 10 MHz OCXO, the GPS time is useful for various purposes, be it, to confirm that DCF77 is actually delivering the proper time.

One drawback of the Motorola UT+ is the rather large “sawtooth” error, which is caused by the quantization of the 1 pps signal derived from a 9.54 MHz clock. This results in a +-52 phase inaccuracy – which can be corrected, but only with further effort.

The later model, which is dated by now and available at low cost, the Motorola M12+, is much better in this respect, featuring a +-13 ns sawtooth, which is not a lot, and good enough for most purposes without any further corrections.

Below, some tests on an OCXO vs. GPS 1 pps pulses, for a OCXO under test (10 MHz, divided down to 100 kHz, and phase displayed in microseconds).

ocxo-vs-ut

ocxo-vs-m12-100ns

This is the small board, not a thing of beauty, but working. The only parts needed are +3.0 V and +5 V (actually using +4.4 V) voltage regulators: 3.0 V for the M12+, 4.4 V for the GPS antenna.
The 3.0 V also powders a MAX3232 TTL to RS232 converter.

m12plus-board

Also procured a second-hand GPS timing antenna – this one has a nice radome, a quadrifilar helix element, and a 26 dB amplifier to compensate any cable losses. The cable, LMR-195, features N to SMA connectors, and a considerable of PVC tape was used to protect the N-connector from the elements. Still it would be better to use some special outdoor N connectors, but, sorry, don’t have.

m12plus-antenna

m12plus-tac

A handy program to control the GPS – TAC32. Usual procedure is to carry out a location survey, which will take about 2-3 hours, and then continue in position hold/timing mode.

One drawback of my location – there is no way to get full 360 deg view, so reception is limited to the more southern satellites. But usually 6-8 satellites are in sight.

Still contemplating if it is worthwhile to put this in a larger box, together with a 10 MHz OCXO, and possibly a DS1023-50 delay line to implement a hardware sawtooth correction. Maybe a good project for winter time.

A Thermal Fuse, and HP 10811-60111 Repair

Usually, I don’t care much about high precision oscillator options being fitted to frequency counters, etc., because in the lab, any critical equipment is anyway connected to an external well-controlled 10 MHz reference, locked to DCF77. However, this time I need to install a OCXO (HP 10811) in a HP 5335A counter for service outside of the lab.

The only thing that needs to be done is to remove a jumper on the board of the 5335A (see red box in picture below), and mount the 10811 in the slot already prepared for the OCXO inside.

ocxo 5335a jumper

While such installation is fairly straightforward, it turned out to take more time than expected – simply because of the OCXO not showing any stable output signal.

ocxo 10811-60111

After a few quick tests, the cuprit was found, a defective (open) thermal fuse. This is apparently a quite common issue for the 10811 oscillators, and you might get away with just putting in a wire jumper. However, I didn’t want to take any risk of overheating in case of a failure of the 25+ years old OCXO circuits. An exact match for the thermal fuse could not be found, so just soldered in (very carefully, cooling the case and leads!) a 10 Amp 109 degC fuse.

ocxo fuse picture

This is the OCXO with the new fuse installed.

ocxo new thermal fuse

This style of fuse as a non-insulated outer shell, so a shrink tubing sleve serves as insulation.

ocxo insul sleve

Finally, a note found in a datasheet of a common thermal fuse – it clearly states that lifetime will be limited when operating the fuse to close to the cut-off temperature. So clearly, thermal fuses are not the best protective mechanism for the OCXO case. Maybe better would be a bimetallic switch (self-resetting, but at least no subject to any significant aging), or some other device like a PTC.

Sure, we can slightly blame the HP engineers, because it is stated on most thermal fuse datasheets, like the one below, that the operation temp limit should be about 30 degC less than the cut-off, which is not quite the case for the 10811 OCXO. 80 to 84 deg C operation, 109 degC fuse cut-off.

ocxo storage temp

ocxo thermal fuse