This is a subproject: I’m building an experimental precision clock in hope modern techniques and materials might let me exceed the performance of a 1921 Shortt-Synchronome. The Shortt represents the ultimate pendulum clock, further development of the type being rendered unproductive by electronic clocks.  But development of pendulum clocks being stopped means it might be possible to outperform Shortt.  Always smart in engineering to define what good looks like, so this table puts numbers on expectations. To beat Shortt I need better than 0.003s per day.

Before Quartz and Atomic Clocks, time was set by observatories fitted with a transit telescope accurately aligned North-South, so the astronomer could detect the moment a known star passed directly overhead.  Fairly accurately!  The information was used to set the observatories pendulum clock, the best money could buy, and then to determine it’s rate (of drift).   The clock was left well alone, and the actual time signal was calculated as an offset from the pendulum dials.   At noon Greenwich would fire a cannon and drop a ball down a flagstaff so ships in the Thames could set their chronometers.  Around the world, other observatories expressed their time relative to Greenwich Mean Time. The GMT standard was based on a mean, by calculating the average of many measurements.  Meticulous hard work and lots of sums I don’t have time for!

Anyway, though my main project isn’t going well, I need a method of measuring it. Not done by watching the hands or listening to time pips! I need to measure short-term stability in the microsecond region, or even nanoseconds, and long-term stability over months and years.  And my system needs to be tested too – I may have blundered in the implementation and my maths are famously bad.

A four part problem:

• How much does the period of a pendulum vary swing by swing,
• How much does period vary over millions of beats?
• What causes the errors? Many, many errors!  Pendulum clocks are vulnerable to outside influences, notably temperature and air pressure, but also vibration, draughts, turbulence, friction, mechanical defects, gravity, impulse disturbance, amplitude variation and other defects. A precision clock builder has to identify and fix as many issues as possible. It gets exponentially more difficult, and Shortt got close to the mechanical limit.
• What can be done to eliminate or compensate for the errors?

Just as toolroom or metrology lab tools have to be about 10x better than what they’re measuring, so do my methods. The table above lists the levels of accuracy achieved by clocks through the ages.

One goto tool for microsecond measurements is the delightfully cheap PicPET, which, when fed with a 10MHz oscillator, measures pendulum period down into microseconds. A Precision Event Timer can also be implemented on some Arduinos, with various pros and cons.  In both cases accuracy depends on the oscillator.  An OCXO beats a TXCO, which beats an ordinary crystal, which beats a Ceramic Resonator.

For long-term measurements, ordinary Network Protocol Time on a Linux Box is never wrong by more than 150mS, usually much better, and accuracy can be enhanced. Though Windows time is comparatively lackadaisical it too can be configured to perform well.

GPS is superior to NTP: it emits super-precise seconds, and a serious player would use GPS to discipline his local NTP time, thus getting closer to atomic clock accuracy.  Ideally with a GPS receiver that specialises in time rather than the cheaper navigational types.

Roughly speaking, the Shortt clock is just accurate enough to detect astronomical time varies. A good Quartz clock circa 1945 definitely sees planet earth is wobbling, and an atomic clock sees more discrepancies.

Anyway, having built an Arduino PET, and able to exploit NTP, I thought it worth testing both against a moderately good electronic clock, one I built using another Arduino fitted with a Temperature Compensated Crystal Oscillator.  No data-sheet for the TXCO, but it turned out to be fairly good. Gained 5.3 seconds over 108 days, noticeably better than my domestic quartz clocks and wristwatch. The wristwatch  keeps good time because body heat keeps it close to constant temperature and they all come with a specially ground crystal.

Why is my TXCO clock drifting? I don’t know! It ran without significant drift for about a month, and then began to gain at a roughly constant rate.  There may be a correlation with temperature, but if so it’s slow acting. The yellow temperature line shows temperatures peaking at 37C during July, and then the average slowly dropping as the planet tilts away from the sun as we approach the winter solstice. Average 30°C down to average 18°C, and falling!  Sadly, I had to stop the test before the central heating was allowed on to keep the TXCO cosy.   Ideally the test would have run for more than a year. Might set it going again in an unheated spare room on a UPS and come back to it in a year or three. You can’t hurry time measurements.

Here’s the graph, plotting temperature and time:

The yellow temperature line shows wide daily swings that don’t seem to affect the TXCO at all, so the effect may not be temperature related. Maybe the crystal is aging due to mass transfer (dirt inside!) or stress. Stress includes movement of the structure supporting the crystal and the crystal itself due to temperature changes, and these would accumulate consistent with the graph.

My electronic clock’s error is about 0.049s per day, twice as good as anything made before Reifler’s 1889 Free Pendulum clock,  But that expensive beast beats me by a factor of 5.  The reason Quartz ousted pendula is that they’re immune to vibration, gravity, air-pressure, mechanical problems and other factors that upset pendulums. And can be improved in many ways not limited by mechanical difficulties.

So there we have it: an electronic clock that outperforms most pendulum clocks is defective!

In the month before it started to drift, I doubted NTP time was fit for purpose. NTP shines in the long term by resetting the computers internal clock periodically, but that means the computer’s clock can wander between NTP corrections. Some are better than others.  Less frequent synchronisation is one reason raw Windows is more likely to be off than raw Linux. Linux isn’t perfect: the NTP software is being replaced by chrony, which I have yet to evaluate.   Also, the clock I’m measuring doesn’t do leap-seconds, whilst I’m comparing it with one that does; Unix CLOCK_REALTIME is UTC. Maybe I should switch to CLOCK_TAI, which ignores the planet entirely and just counts seconds. Except the last leap second was added in 2016, so not that!  And TAI currently differs from UTC by 37 seconds.

Any ideas about what might be causing the drift or spoiling the measurement?

A warning to prospective precision clockmakers!  Let my ship-wreck be your sea-mark. As can be seen making and testing precision clocks is difficult.  And it gets progressively worse.  Every improvement reveals more problems, and every fix is harder than the one before.  Wish I was a masochist!

Dave