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.

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.

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.

The boards and cables…

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

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.

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.

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.

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.

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