Category Archives: Precision Timing

Electronic Master Clock: a huge train station clock is ticking again

Recently, I have been asked how an old slave clock could be controlled, it was saved from being scrapped, when a local train station closed down. It is really big and heavy. Eventually, I checked it out and it can be operated from 12 V, 24 V, or higher voltages by adding a resistor. We decided to operate it on 12 V, simply because one of the slides (this is two-sided slave clock) had already been set to this value.

In order to control the slave clock, we have to send a 1~2 second long voltage pulse, every minute, in alternating polarity. Then the minute hand will advance minute by minute. There is no second hand on this slave clock.

The control board is fairly simple, to test it all out, I soldered it on a piece of prototype board. Main control is by an ATMEGA8 microcontroller. This is using its own clock, from a Kyocera HC1 crystal oscillator to derive a 1 minute time interval, and and auxiliary 1 second output, for calibration purposes.

The actual adjustment of the clock is done in software, because the oscillator is pretty stable, and this is just a test circuit. If the slave clock will be a minute off, or two, nobody will mind.

The clock drive is completely separate from the controller, isolated by optocouplers. I used a small transformer, with dual 12 V output (because it is small current only, the output voltage is high enough, but you may use a 15 V transformer if it is handy).

Seems we are about 25 ppm out. After correction, the clock was running well within 1 ppm, fractions of a second per day.

To make the contraption a safe and useful thing, I put it in a little box, with some cables and feed-throughs.
Now it is up for some long term test, let’s see if it needs any modification.

Siemens Electric Master Clock: after some years, a little repair

My trusty Siemens master clock, after some years of service without any trouble, it needed repair. The electromagnet coil that charges the weight, it is triggered by contacts that got dirty over time. So I cleaned all well with contact cleaner and some ultrafine abrasive paper.

With these little repairs complete, the clock showed another issue. It just stopped after some random time, and that is no good for a Master Clock. Generally speaking, pendulum clocks that stop oscillation randomly are difficult to fix. It may be dirt in some gears or bearings, it may be incorrect adjustment of the escape wheel, it may be some local disturbance.
Fortunately, the full clockworks can be removed without touching the Invar pendulum.

There are connectors at the top, well large in size, and with some silk spun wire.

Upon closer inspection, one of the main gears, which also drives the minute hand, showed issues. It is not fixed in position, but moved in and out. How can it be? When it gets out too far, there won’t be any reliable force transmitted to the pendulum, so it will eventually stop.

There is a washer, brass, on the back side of the movement, and this is supposed to hold the axle in a fixed position, while allowing it to spin freely.

Somehow, this washer had worn out. So I just rotated it.

Giving the clockworks a good clean and oil (only special clock oil made for medium-heavy clocks supposed to be used!), but without a full disassembly.

Now it is ticking away again, and showing the time, day and night.

Digital Delay Line: sawtooth corrections of an ultra-precise GPS-reference 1 pps signal, and thermal effects

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.

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.


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.


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.


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.


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.


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.


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.


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.



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.


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


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


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).


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).



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.


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.



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.

TIC4 Logger5 Clock Monitor (“TIC4LOG5”): update and test data

A quick update on the clock monitor/time interval counter project, TIC4 Time Interval Counter. Main objective is to have a clock analyzer that will keep track of every tick of mechnical clocks and watches, in particular, of one of my precision pendulum clocks operated in Germany. These clocks are pretty accuarate, but are impacted by air pressure and temperature fluctuations. Ideally, rather than the air pressure, it would be great to measure the air density directly, but there aren’t any easy ways to do this (might be considered for a project later).

The TIC4, we have already discussed, it is based on an AVR Atmega32L, which eventually will be running of a 10 MHz OCXO ultra-stable clock, provided by a Trimble OCXO, more on this to come. For now, the circuits are running on ordinary crystal oscillators, fair enough.

The TIC4 circuit has now been combined with another Atmega32L, which I call the “controller”, aka “Logger5” here. Its only function is to wait for a TIC event to happen (timestamp received), and the the determine (room/clock) temperature, air pressure, and real time (from a real time clock, which is not very accurate, just for the purpose of keeping track of actual time and date, UTC time plus minus a few seconds, e.g, to correlate clock issues with events like earthquakes or sun storms…).

This setup represents the temporary “TIC4LOG5” wire rats nest, which will be put into a proper case once all has been tested thoroughly.
tic4log5 scheme

For the TIC4 and Logger5 Atmegas to work together, they need to run on the same serial baud rate. With the desire to run the logger at 16 MHz, and the TIC4 at 10 MHz, this leaves 38400 baud as a good compromise.

baud rates

Some small console programs are used at the host PC to gather the data, and store them in files, about 4 Mbyte a day, for 1 s pendulum, or 40 for the 10 Hz clock under test now.
All has been designed for clocks up to about 10 Hz, but the circuit can work up to 100 Hz no problem, provided that the pressure measurement (which takes about 10-25 ms, depending on the resolution mode – selected the ultra high mode, 25 ms per sample).
A note on the BMP085 – this is a quite common part, and pretty ordinary to program and work with – typical accuracy is +-1 mbar, with max. 2.5 mbar specified. Typical noise is about 0.05 mbar, but can be significantly reduced with averaging (there aren’t any fast second-time-scale pressure changes anyway).

That’s how the console works away: recording RTC (in unix time seconds, counting the events, recording the timestamp, temperature and pressure). Two files are generated, one the has the full data, and a second one that only records to event numer (TIC events recorded- and reconstructed to actual clock ticks in case a few ticks are missed) and the absolute clock deviation (time gained or lost, in seconds). For those more familiar with electronics engineering, this time gained or lost is nothing else than the phase shift of the clock under test vs. the 10 MHz precision ultra-stable OCXO, measured in seconds.

For test purposes, and to get a lot of TIC events, a 10 Hz clock source is in use as the test clock. This will be replaced by a pendulum clock, or mechanical watch, eventually.

tic4log5 clock
The boards and cables…

tic4log5 assys

…and their output, one data package, 29 bytes, every 100 ms.


Some records of the last few days (pressure is as-measured, no corrections, location is Westfield, NJ, USA) – all working pretty well with no hick-ups or restarts so far!






Also the Allan Deviation looks ok, and plenty accurate to measure the drift of even the most precise pendulum clocks, or similar. From the temperature effect, it seems that the test clock is speeding up a bit, with increasing temperature, but overall the effects seems to be just some random drift. Hope you also notice that the workshop here is nicely thermostated at about 22.3+-1 degrees centigrade.

allen dev 1

With the software now pretty much established, it is time to look at the precision clock source. Sure, it would be best to run this of a hydrogen maser or caesium clock, but all a bit too much for the given purpose, und consuming too much electricity. So I settled for a Trimble 65256 OCXO (oven controlled xtal oscillator), having a few of these on hand. They run at 12 V (note: which needs to be well stabilized, otherwise you will get a good amount of phase noise – not relevant for this application, but for others), consuming about 0.3 Amps, chiefly, 4 Watts.

tic4log5 trimble 65256

The output of the Trimble is a sinewave, about 3.6 V p-p when terminated with a few kOhms (no need to terminate such osciallators in 50 Ohms). This signal can’t drive the Atmega32L directly, it needs to be properly squared up. This is acomplished by a 74HCU4, which also generates an auxilliary output 10 MHz signal, handy for other uses, and for alignment of the Trimble vs. a GPS or DCF77 frequency standard.
The OCXO may drift about 10e-8 per 10 years, 10e-10~10e-9 per day. This is 10 to 100 microseconds drift per day. Not sure about the Trimble units, but they seem pretty good based on past observations.

tic4log5 trimble squared

Everythings squared up properly, x axis is 10 ns per div. Well, this is close to to the limits of the 60 MHz BW scope used here.

tic4log5 trimble risetime 10 ns per xdiv

Some data on the Trimble 65256 units – interestingly, they have a 2.6 V reference, but the VFC (variable frequency control) needs to be set to about 3.2 for this unit, to get exactly 10 MHz.

tic4log5 trimble 65256 serial 12315-10040 connectors and data

Here are some of the key source files, for those interested:

tic4 avrgcc tic4_10mhz_stable160423

logger5 avrgcc logger5_stable160430

console data logger log5_main_stable160501

USB control program log5usb_main_stable160430

tic5eval R script to make the daily plots

TIC4 Time Interval Counter: 64 bit timestamps – 100 ns resolution

A time interval counter – this little device, based on an Atmel AVR ATMega32L assigns 64 bit time-stamps to events (event being a rising edge on INT1 interrupt), based on a 10 MHz OCXO, a Trimble 65256 10 MHz double oven oscillator. So, 100 ns resolution. The main purpose: precise monitoring of pendulum clocks – in combination with a temperature-air pressure-real time clock data logger.

Why TIC4 – well, there are several other (earlier designs), some with better resultion by interpolation (via a clock synchronizer and interpolation circuit). But for the given purpose, there is no need for any more than a few microseconds of resolution, because it is really hard to detect the zero-crossing of a mechnical pendulum to any better resolution.

For test purposes, I had the circuit running on a 16 MHz clock, with ordinary (not very precise or phase locked) 20 Hz, and 2 Hz signals at the input – running overnight to check for any glitches.

tic4 allan dev 50 ms

tic4 allan dev 500 ms

The Allen deviation plots show that for single events, the timing accuracy is about 150-200 ns, close to what is theoretically possible for a 16 MHz clock.

The AVR program code, it looks simple, but believe me, it isn’t. There are quite a few pitfalls, because for any timing of the interrupt, there needs to be a precise time-stamp generated, and transmitted to the host. Maximum time stamp rate is 100 Hz nominal (1 timestamp every 10 ms), but will work up to about 150 Hz, without missing any events. Timestamps are transmitted with every 16 bit timer overflow, chiefly, every about 6.6 ms (65535 x 100ns). Each timestamp and control info is 120 bit long (12 bytes, 8N1 protocol, 57600 baud) – 2.1 ms.

tic4.c AVR code

For test purposes, the serial data is sent to a PC, via a MAX3232 TTL to RS232 converter. Alavar is used to process the information into Allan deviation plots.
Test showed absolutely no glitch in about 1.3 million events – fair enough!

More details to follow.