Ages ago I built a pendulum clock with a bob on the end of a short thin carbon rod with no suspension, the idea being that the rod would act as a spring that's not temperature sensitive. Didn't keep good time, partly because the rod tends to swing in an ellipse, with low Q, and partly because it's sensitive to humidity. (I guess the plastic matrix is effected and humidity alters it's springiness, nothing to do with the fibre.)

Bit of reinventing the wheel because I can't find the notes describing where I'd got to, but I've made a start by adding a suspension:

Zooming in on the suspension, I'd welcome comments on the design:

The spring, 0.1mm thick, is cut from the blade of a disposable razor, edge blunted to avoid spilling blood. It's clamped between brass cheeks, with about 2mm free to flex. The 0.8mm diameter carbon fibre rod is superglued into the cone, which is 10mm long. Is this a good design?

The results are odd. The graph is a run of about 25 hours,

The top graph shows tick times vary and that the variation is slowly getting worse. A perfect pendulum would graph as a straight line. Worse than expected; the average tick is 13369412 Arduino Clock Cycles, which has a 16MHz quartz crystal, actually averaging 15998101Hz. However the fastest tick took 13275269 cycles, and the slowest 13471208. The range is 195939 cycles, about 0.012s, which I feel is too much.

The second graph is a moving average of the first. It shows that the pendulum is gradually speeding up, and its not related to temperature, air pressure or humidity.

Most confusing is the third graph, which is the wrong shape! It counts the number of beats in each of 20 buckets across the range of variation and shows the slow and fast tick counts, both outnumber the average. I'd expect the distribution to be concentrated in buckets closest to the average. Instead, the graph implies the pendulum has two modes of oscillation.

Any ideas what might cause a pendulum to display these symptoms?

Dave

Good questions. The microcontroller is a Sparkfun Pro Micro, a miniaturised version of an Arduino Leonardo. It comes with a quartz crystal rather than a cheap unstable ceramic resonator. However, the crystal is an ordinary 50 – 100ppm type, there's no capacitor, and I've made no attempt to stabilise the temperature.

The microcontroller measures the number of crystal ticks per swing and for best resolution this is mostly done in hardware. The 16MHz system clock feeds a hardware counter triggered on/off by the pendulum blocking an IR beam. The counter is zero at start and on overflow, it clocks another counter. When the off signal is received both counters are frozen and a simple sum gives the total number of crystal pulses per swing. As the counters run at 16MHz, the pendulum is measured in ticks of about 0.0625 microseconds, considerably better than doing the same in software (worse than 4 microsecond resolution.) Accuracy depends on the quartz crystal, which of course could be wrong by 100 parts per million, and is temperature sensitive.

The same counter technique can be used to measure the actual frequency of the crystal. Substituting the seconds pulse output of a GPS module for the pendulum, the microcontroller counts the number of oscillations made in one second. This can be repeated and averaged.

In the clock, during the 0.8s between swings, environmental data is read, and everything logged to a Raspberry Pi3B.

The data is:

13432949 0.7461 200 0 994.76 81.29 14.87 836040 1669630663 148802507

Tick Count – 13432949
'Amplitude' – 0.7461 (actually a measure of how fast the pendulum is swinging, used to decide if an impulse is needed)
Pulse – 200 How long the magnet is switched to impulse the bob
Power – 0 (false) Whether or not the magnet was impulsed.
Pressure – 994.76mb
Humidity – 81.29% Relative
Temperature – 14.87°C
Nominal Clock Period – 836040uS. The uncompensated period used by the stand-alone clock. (Should be 835650)
Clock Time as UNIX Timestamp – 1669630663. Number of seconds since 00:00:00GMT 1/1/1970
Clock Time UNIX subseconds – 148802507. Fractional part of UNIX timestamp.

In the current set up I'm measuring the crystal's average frequency by comparing it with Network Time. The Raspberry Pi3B is connected to the internet and synchronises using NTP every 38 minutes. It timestamps log data on receipt, making it possible to compare pendulum clock time with network time, but otherwise has little else to do that might interfere. The arrangement isn't brilliant, but the Pi3B's notion of time is always better than 0.1s accurate, making it suitable for long-term comparisons. The number of crystal ticks counted over several accurate hours gives the frequency. I should also analyse the data by time slots, to see how the average frequency alters hour by hour.

Until this morning, results suggested the experimental clock wasn't sensitive to the environment, but today suggests it could be tracking air-pressure. In the graphs below, the moving average falls with the millibar line until this morning when both lift together. Far from conclusive! I need to let the clock run for a lot longer.

I'm flummoxed by the shape of the 'Ticks by Bucket' graph. Next job is to check my code for the fifth time! Maybe I've misunderstood matplotlib or messed up the analysis. Otherwise I can't imagine how a pendulum's period could vary like that.

Robert's point about this being the first period of running is good. Although the clock has been run several times to test it and the software, they were all short runs. This is the first long one and perhaps it's shaking down. If so, it's taking a long time!

Let Robert's confession to being a 'time-nut' be a dire warning to others. The pursuit of accuracy time is addictive. I'm wasting lots of time on this and lust after Rubidium too…

Dave

Guilty. It's in an unoccupied north facing bedroom, and mostly safe from the cat. Where's the best place in an ordinary semi for a sensitive clock? Under stairs?

Dave