Arduino Pendulum Clock Design - Comments Welcome

I can use the temperature compensation idea to allow for my steel pendulum, easier than converting to carbon fibre, what are you using to measure the temp? LM35 looks like a good start, LM35 but I've got some Thermistors.

In similar vein I have a project on the bucket list to remotely sense boiler pressure on a 5"g loco, and was thinking that measuring temperature is a lot easier, then convert temp to pressure with an equation, but I'm looking in the range 170C which is higher than most sensors. Anyone got any ideas? Got to be cheap!

Duncan, get one of the cheap thermistors used in the 3D printer extruders - they are good to 250/300degC.

There are some nice tools to calculate the Steinhart-Hart model coefs and it all works quite well, with just another resistor, reasonably accurate voltage reference and an A/D on an Arduino..

**LINK**

Joe

Use a BMP280 or BME280. First just does temp and pressure, second does humidity as well.

.

Great progress, Dave ... and I’m delighted to see that punch-line !

Could you please remind me : Have you reverted to the original [rod=spring] design, or are you now using the [burned-away epoxy] carbon filaments suspension ?

... I still have the spirit of Galileo whispering in my ear.

MichaelG.

For just temperature the DS18B20 works well; I'm using a BME280 on this project to get humidity & pressure as well.

Don't trust a word I say tonight - half-way through a bottle of Prosecco...

Just as an example of "error-correcting" I applied the method I described above to about 50 days' worth of data from my Arduinome up to 26th September, and got this.

The blurry blue wiggle at the bottom is the uncorrected period data, the orangy brown smudge at the top is corrected. Thick light blue curve is pressure (offset by 980 mBar), light orange is temperature, and hidden behind the corrected curve is the amplitude plot.

Clearly there is diurnal variation not accounted for in the model, what's causing that I don't know. But it does look as if, if the corrections were applied in real time, the period variation could be much reduced.

A while back you sent me a file of data for your pendulum - could you remind me what the columns are please?  It would be easy enough to try the same approach with that data.

Edited By John Haine on 01/01/2021 16:27:10

Nice graph, and I'm glad I'm not the only one seeing unexplained variations!

Re Diurnals, some of these are obvious on my latest graph showing the last 4 days :

HM is central heating coming on for a couple of hours in the morning, HO being switch off. Switches on again in the evening at HE and stays on until bedtime. The clock is on a south facing window and the solar gain is obvious even during English mid-winter. Relative Humidity varies with the weather, but the effect of heat can be seen, also spikes due to showering in the nearby bathroom. The big shower spike is when daughter and I both made ourselves beautiful in succession, and the clock room door was open.

If the file was 'a1000pt4.csv' the columns were:

• period in microseconds
• amplitude
• temp C
• pressure hPa
• relative Humidity %

If you fancy a go at more recent data, ubst40p16G.log , about 28Mb on Dropbox, is the last four days, It's columns are:

• period in tixels ( ie counts of oscillator resolution, here 1/16MHz, about 62.5nS each) As measured by the Arduino crystal & counter timer
• amplitude (target 0.4)
• pulse width (hex counter setting, equivalent to 1.6mS)
• power (0 or 1, where 1 means a pulse was applied to the electromagnet.)
• pressure in hPa
• relHumidity %
• temp °C
• clocktime since start of run in microseconds. ticked by average period, not arduino measured pendulum time. Next run will be ticked by temperature compensated period. Used to calculate clock hh:mm:ss
• UNIX timestamp added on receipt of serial update. Compatible with previous column in that the clock epoch is very nearly microseconds since the first timestamp. Thus, finishTimestamp - startTimestamp should be very nearly equal to finishClocktime - startClocktime.

Just started a temperature compensated run and will see what that looks like. Counting average ticks isn't much good, out by a couple of seconds over 4 days.

Dave

Edited By SillyOldDuffer on 05/01/2021 15:07:42

Hi Dave, sorry for slow response. I got the data last week and did the analysis but only just got round to posting the results - I hope they make sense. Back in Dropbox and you should have got a link by email. It's an Excel file (big!).

Good to see Peter has caught the bug too. Beware, it's addictive - how accurately does it keep time?

Sorted out a dropbox login problem and downloaded John's R Studio corrections, but not had a chance to look at it yet.

My own effort at temperature compensation on the live clock failed, making performance slightly worse, and producing an unexpected graph. Turned out to be a silly mistake - having adapted the Arduino to temperature compensate the clock, I forgot to supply the m and c parameters that switch it on. So the clock ticked at the default average. Fixed that and restarted the clock this morning, so time will tell.

More interesting is another anomaly in the data. This graph shows the pendulum varies with temperature in that the slope of the red and blue lines track each other: rising temperature causes the clock to slow down, and vice versa. This is true except for the peak circled in green, where the clock speeds up when the temperature peaks. The peak is due to solar gain - sunshine, warming the south facing clock room around noon.

Unusually high temperature causing the pendulum to speed up goes against the grain and suggests something else is going on. I believe solar gain is changing humidity, and the spring-rod pendulum (or 'sprod' ) is reacting to that in the opposite direction, as shown below:

To test this I've modified the clock so the pendulum is fully enclosed. Made a bulkhead penetrator to carry the wires through the top-cap. The plug is made of Nylon. Turned on the lathe with no problem but drilling it was painful. It clogs and grips the drill, and when the drill is extracted the hole shrinks. Quite hard to force the steel dress-making pins through it to take the jump-wire sockets.

The joints are sealed with vaseline but the clock hasn't been evacuated. There should be a silica-gel sachet inside, but guess what - it's gone walkabout. Anyway, tomorrow will show if temperature compensation and sealed running make any improvement.

General view of the clock.

Deliberately perched on a south facing window-sill in an unheated room as a way of exposing it to temperature change, but also so I can get a good signal if the GPS module is connected. The window-sill should be relatively vibration free. The electronics are shielded from direct sunshine, and the Arduino and RaspberryPi3B are balanced on a cardboard box to improve the wifi signal. The clock drainpipe is normally protected from sunlight with an aluminium kitchen foil shield, not in the photo.

MichaelG sent me some interesting notes about modal vibration which I'm going to follow up after going ffor my Covid constitutional. Is my 'sprod' modulated by frequencies other than the base period, and if so what are they? (Putting it another way, is my pendulum going twang?)

Dave

Edited By SillyOldDuffer on 05/01/2021 15:08:31

Dave, I just replied to your email but it got bounced - you should have got a link from Dropbox for the new spreadsheet?

Hmm...just got bounced again, error was:

a****[email protected]:

SMTP error from remote server for RCPT TO command, host: mx-2.dsl.pipex.com (62.24.139.42) reason: 550 5.1.1 x6QWkjD8UzqJT Recipient Undeliverable (TT512)

Edited By John Haine on 06/01/2021 10:55:21

Edited By SillyOldDuffer on 06/01/2021 17:09:31

Hi John. Got the Dropbox link OK - not looked at it properly yet - I've been out today.

Zapped my email address in your post to stop spammers picking it up, but the error looks like a temporary fault with my email provider. Just tested and it seems OK now.

Dave

Oops! Sorry, I should have thought. I'll try again.

Mix of good and bad news from the latest run. The pendulum is running inside a sealed container and is temperature compensated.

After some disturbance when the clock starts, the period holds steady and isn't responding obviously to either temperature or humidity. Hurrah.

The stats conform the good news, correlations are low.

Bad news, despite the good looking graphs the actual performance is worse! The clock drifts away from UNIX time, losing about 15 seconds per day which is poor. Not sure why because clock time measured by the Arduino crystal is only wrong by about 1.6 seconds. I suspect the error is due to floating point rounding error. Maybe temperature compensation is clipping corrected periods causing a rate to appear. Clipping is possible because Arduino floats are only 32 bit binary and limited to 6 or 7 digit precision. The error is equivalent to 0.00007773s per tick, which is suggestive. Linux, Mac and Windows typically provide 15 digits of precision, and there are a couple of 64bit floating point libraries for the Arduino I can investigate. )

I conclude carbon-fibre rod is sensitive to changes in relative humidity. Also that temperature compensation works, but there seems to be devil in the detail.

I also ran an FFT analysis which suggests the pendulum isn't twanging violently. Won't publish the graph because I'm not sure the calculation is right. There is a weak frequency comb, but the signal is mostly noise.

Lot's more to investigate, but I'm wondering if I ought to build a Pendulum Clock like John Haine's design. John's design includes much 'best practice' and it would be interesting to compare it's performance with my flirtation with adventurism.

A recurring theme in this endeavour is the fun caused when technology is pushed to the limit. My clock tribulations are akin to it being relatively easy to work to a thou on a lathe, and far more challenging to work in tenths. And when tenths are conquered it's almost impossible to get 0.00001" precision out of a lathe...

Dave

Ha, spotted a silly mistake. The temperature compensation values used in the last run were calculated before the the clock was sealed, ie when humidity and temperature both influenced the analysis and threw the temperature correction off.

When the clock is sealed the effect of humidity is much reduced, making the earlier compensation values wrong. Recalculated and back compensated, the clock is out by 1.5 seconds compared with NTP UNIX time, same as reported by the Arduino crystal. So the big 31 second error wasn't due to floating point rounding at all. Fixed that and restarted the clock to see if the accuracy holds up tomorrow.

No idea what's causing the 1.5 second error. It's not rounding.

Dave

.

Dare I mention some similarity with the ‘direct drive’ lightweight record player turntables ... which, despite all the clever technology, could never beat the performance of a heavy platter on good bearings ?

MichaelG.

Another lurch forward thanks to Michael Gilligan. One of the graphs I draw is of Allan Deviation, said to be the best way of expressing clock performance, except I didn't understand it,

Given a stream of data representing period it's easy to number crunch minimum, maximum, average, median, standard deviation and to graph rate.

Standard deviation and rate are the most interesting.

Rate describes how much a clock drifts over time, a few seconds per day, or scientifically in parts per million, or parts per billion. If the rate is known it can be corrected.

Standard deviation is a simple measure of stability - the range over which period varies. Although a clock can keep good time over days (low rate), might be because wild variations average out. OK over several hours but unreliable at seconds - not a good timekeeper.

Thanks to Michael finding this description, I think I've got a handle on Allan Deviation. It graphs how much a clock's variance varies, i.e. a measure of stability covering short & long-term effects. Allan insn't easy to interpret. Rawlings (Science of Clocks and Watches) says: 'There are so many influences on a clock that the study of performance records and stability charts seems more akin to the science of meteorology than physics or engineering.' Curve shape is as important as the values, but the shape is influenced by many factors.

Occurred to me Allan would be more obvious used to compare clocks. I have 6,

• My pendulum clock
• Same temperature compensated
• A UNIX program outputting times triggered by a per second timer. This depends on a not very stable clock corrected by the Network Time Protocol every 10 seconds or so. NTP is never wrong by more than 0.1s
• An SDG1062X Function Generator. This has a temperature compensated crystal oscillator; good rather than excellent.
• A GPS Module producing second pulses, ±10nS, the best I can do without spending big money.
• A 'Perfect' clock, i.e. a stream of computer generated numbers representing pure sensor readings. No noise, sensor errors, or drift. Mine is 64-bit precision floating point numbers.

This graph compares all six clocks:

Best at the bottom, worst at the top. Curves start top left with standard deviation and then how that varies. So standard deviation is a decent basic indicator of clock goodness, but not the whole story.

As expected the perfect clock (Brown) massively outperforms real clocks. But Allan Deviation shows imperfections. A gentle down slope is good, indicating white noise, but there are kinks. These I suspect are rounding error due to the limitations of floating point arithmetic.

My uncompensated pendulum (blue) is the worst clock. The middle dip is the lowest variation achieved and suggests this the best a compensated version can do. The rise out of the dip means rate drift. The orange line is from the same run, but temperature compensated. A considerable improvement, but the compensated clock now shows a distinct rate drift error. (Consistent with other data, and has me puzzled. Per-swing accuracy better, but long-term timing is worse, probably because other faults have emerged!)

Green UNIX time is a mix of good and bad. The down slope suggests this a good clock influenced mainly by white noise - no drift, but variation is high - worse than my temperature compensated clock. Fits in with how NTP works. The computer's internal oscillator isn't special, so drift is likely between NTP time updates. The exact timing of a second is influenced by whatever else Linux is doing and so is the way my program measures it. Although NTP is Atomic Time, it resets iffy computer clocks with a bang, with variance due to network & processing delay. Atomic time, but up to 0.1s off. Although my computer is usually within 25mS, Allan Deviation detects the imperfection. Truly excellent in the long term, not so hot close in.

Both electronic clocks do well. The purple and red curves track each other closely. GPS is better than the Function Generator. Short term both are better than UNIX but they drift off because they're never corrected. At this accuracy sensor error intrudes. GPS is significantly better than the Function Generator, but Allan doesn't highlight thst. Both curves are limited by the Arduino Pro-Micro's crystal oscillator. So the purple GPS line represents the best I can measure to, not the actual performance of the GPS module & I can't trust measurements below that line. On the plus side, the Arduino is good enough to detect how well or badly my pendulum does!

Assuming the scale's right, my compensated clock is slightly inferior to a marine chronometer circa 1795. Not bad, but disappointing for a super-timepiece! On this graph Shortt No 48, Rieffler 'E' & Fedchenko would all be a tad inferior to the GPS. No surprise, - the best mechanical time-keepers can't compete with electronics and atoms!

Very much feeling my way. Please say if it's wrong - I'm here to be educated.

Dave

Thanks Dave - that web page is a find, thanks Michael as well. I'm amazed to find that R can also calculate AVAR (though I shouldn't have been I suppose).

Progress indeed, Dave

The one thing that surprises me a little is that the best ones of your ‘real clock’ examples are not dipping down into the 10 exp -13 region. ... That top group of lines all looks more closely grouped than I would have expected.

This may be a condemnation of your measurement & analysis ... I’m not sure.

... If I can find any supporting evidence, I will be back.

MichaelG.

‘ere be evidence: **LINK**

https://www.researchgate.net/figure/GPS-Receiver-versus-UTC-NIST-during-15-day-interval-after-SA-was-set-to-0_fig2_269280303

[ Download full-text ] is available.

MichaelG.

Edited By Michael Gilligan on 11/01/2021 17:21:54

Not going well with the Duffer Clock and I'm pausing for thought.

But first, re Michaels 'This may be a condemnation of your measurement & analysis ... I’m not sure', I'm not sure either! One possibility is my sample time is too short, but I think Allan is telling the truth. With the exception of UNIX time (actually Network Protocol Time), all the real clocks are being measured by my imperfect Arduino. So Allan is seeing the Arduino drift, rather than GPS, and it's the Arduino that stops the result getting anywhere near 10E-13.   Left running long enough I think NTP would drop down much further.

Part of my depression is due to failing to find the missing TXCO's needed to improve the Arduino. Salt rubbed into the wound because I experimented with a 'not needed and not lost TXCO' to test my SMD soldering skills. Fiddly! The TXCO is the small square mounted on the red motherboard below.  Wrong frequency for what I need, but OK for a trial run.

I seem to have damaged the TXCO because it oscillates at 38.4, not 12.8MHz. Should have read the spec before powering up because the TXCO is voltage sensitive. Main power is 3.1V max and I fed it 3.3 plus I didn't realise the control voltage on line 20 is also critical. Oh dear.

Meanwhile the pendulum failed, and won't restart. Opening up showed debris:

And the sprod's mounting sleeve has slipped - the 5mm thickness where the rod emerges from the brass disc in the next photo. The debris on the rod can only be due to physical damage further up.

Q dropped badly over the last for or 5 runs, and the above seems to explain why. At first the pendulum did over 30 swings per impulse, but it degraded over a week to just one swing per impulse, and now it doesn't run at all. Root cause was probably me jostling the pendulum whilst adjusting the magnet and IR sensor positions.

Details are irritating but the big problem is persistent instability, which is obvious in almost all test runs. Worse than usual, but not untypical:

After starting the pendulum settles down to 0.9325s but then the variance gradually gets worse peaking at around midnight before gradually settling down at 5am. Although the most extreme variance is less than 0.1mS, this is hopeless in a precision clock. In a very long run, instability appears and disappears.

The cause isn't related to time of day, humidity, temperature or air pressure. I think it's more likely a design fault. My pendulum rod relies on the principle of least energy to keep it swinging in a straight line - in theory it should take the most direct path towards the electromagnet. I guess the bob actually behaves more like a raindrop trickling down a window pane. Raindrops don't run down glass in straight lines, rather they are prone to deviate right and left for no apparent reason. I suspect my pendulum occasionally swings off the straight and narrow which causes the bob to trigger the impulse at slightly different times and makes it worse. The impulse alters both period and path so the disturbance grows and subsides almost by chance and for no obvious reason. The extremely light bob and rod don't help!

Vibration could explain why my pendulum goes walkabout. Running the pendulum on a dining table showed variations due to people walking on the floor, which is hardwood parquet on concrete. My house clunks as the temperature varies - mainly the hot water pipes, but other things too. And there's a road not far away. Maybe the wooden windowsill the clock's sat on expands and contracts with a jolt. I planned to improve Q by removing resin so the bob would swing on Carbon Fibres only. Not sure that's a good idea now because it would allow the pendulum to deviate more easily.

Although the clock can keep good time it's proving too sensitive and fickle to be practical. I'm inclined to build a clock like John's and test that. I feel a heavy bob suspended by a flat spring would solve a lot of problems...

Dave

Edited By SillyOldDuffer on 21/01/2021 15:27:00