Arduino Pendulum Clock Design – Comments Welcome

[Martin KyteParticipant @martinkyte99762]

Posted by John Haine on 27/10/2020 10:04:58:

Posted by Martin Kyte on 27/10/2020 07:58:12:

John Harrisons RAS regulator also had the pendulum suspended on a knife edge.

regards Martn

Actually no. Key to that clock, as also to Clock B, is the use of circular chops round which the suspension spring wraps to give partial compensation of circular deviation. This is obvious from the published descriptions of the RAS clock (The Lost Science of John "Longitude" Harrison), Clock B and the series on the RAS Regulator replicas in HJ at the moment. They do use knife-edge suspension, hard brass on glass blocks, for the crutch but that carries much less load than the main suspension, and arguably friction doesn't matter since the crutch is driven by the train.

Obviously my faulty memory. I did recall reading about the inclusion of a knife edge running on agate in the description of the RAS and just assumed it was the pendulum suspension. Just looked it up agin and seeyou are correct in it's use on the crutch.

regards Martin

[SillyOldDufferModerator @sillyoldduffer]

Two problems with the clock in it's latest state, which was run with reduced impulse as suggested by Duncan, and also at reduced amplitude. Should be possible to do more of the same for even better performance. One problem is how long measurements take, ideally taking at least 24 hours without disturbance. Second issue is once temperature corrections are applied to the Arduino, accuracy is similar to that of my 2ppm Real Time Clock module, which doesn't indicate fractions of a second. The most recent run illustrates the problem:

After temperature corrections are applied to the Arduino oscillator my pendulum is within 1 second of the electronic Real Time Clock over 18 hours, so I can't detect the difference. Although the calculation suggests 0.325 seconds error over 18hrs 20minutes, it's not valid because I don't know exactly when RTC seconds occur: I need to improve the reference clock. There's weak correlation between between air pressure and period, and the reference clock has to be improved to prove that's real as well.

Encouraging levels of accuracy over 18 hours aside, the pendulum is far from perfect. Amplitude and period occasionally glitch for no apparent reason. Whatever causes glitches isn't temperature, pressure or humidity – some happen when the house is empty or asleep. Of even more concern is the degree of spread around the average period: this pendulum is a noisy oscillator, cause unknown. The spikes on the bell-curve may indicate secondary oscillations or elliptical pendulum paths.

For what's worth, Allan Deviation. I don't know what the graph means!

Another long run with further reduced impulses next while I decide how to improve the reference clock. John Haine mentioned using a serial terminal to timestamp records as they arrive from the Arduino, and noted inaccuracies due to Linux multi-tasking, ie other processes delay the timestamping program. This appears to be fixable in code because it's possible for a linux program to select a scheduler profile giving itself near real-time characteristics. From the spec, it appears possible to effectively allocate a CPU core almost 100% to one process, minimising scheduler delays by forcing everything else running on the computer on to the other cores. I've written a time-stamper that gives itself top priority, but not proved it makes any difference to data capture. (It relies on the scheduler to wake it up whenever the serial port is activated, and the scheduler may be a bottleneck.)

Dave

 

Edited By SillyOldDuffer on 29/10/2020 18:18:13

[SillyOldDufferModerator @sillyoldduffer]

Graphed pendulum period against air pressure not expecting anything and instead got a clear positive result:

For periods near the average it appears there is a linear relationship between period and barometric pressure.  The pendulum speeds up as air pressure rises. I think unusually high and low periods aren't affected by air-pressure, suggesting something else is going on as well.

Why the pendulum is effected by air pressure is another question. Rawlings 'The Science of Clocks and Watches' suggests:

• Buoyancy changes – the weight of the bob (but not it's mass) falls when air becomes denser.
• Friction between bob and air increases with pressure
• Varying resistance as the bob causes an alternating wind inside the clock, the size of which depend on the shape of the bob and whatever else is nearby. As my bob runs in a channel, partially blocked at one end by the electromagnet, turbulence could be a problem.

Oddly, I'd expect all three effects to slow the pendulum down as air pressure increases. The graph shows my pendulum doing the opposite.

More mysteries!

Dave

 

Edited By SillyOldDuffer on 30/10/2020 11:19:38

[Swarf MakerParticipant @swarfmaker85383]

Another parameter for you to consider regarding unexpected perturbations – earth tremors?

[John HaineParticipant @johnhaine32865]

Hmmm.

• As I read that graph, as pressure increases the period gets longer so the clock slows down! As the buoyancy increases with pressure so the effective weight decreases, or in effect "g" decreases and the period gets longer. Have you compared the slope of your curve with the theoretical value (which I can't remember offhand)? The effect of pressure variations is reduced in proportion to the air density/bob density, my impression is that your coefficient is rather large, it seems to be about 40uS/mbar. From my last analysis, my clock (which has a 7 Kg CI bob) has a coefficient of ~0.4 uS/mbar (with no explicit attempt at compensation).
• A related effect is "access to inertia" caused by air carried along by the bob which increases its effective mass but not its weight – normally this is reckoned to be about equivalent to the buoyancy effect.
• Denser air has greater resistance so amplitude ought to decrease (unless you are controlling it), which would decrease the period through circular deviation (but that does depend on escapement deviation as well). Do you have a plot of amplitude vs, pressure?

[duncan webster 1Participant @duncanwebster1]

I think you still have a fairly light bob, could the odd spikes be related to passing motor traffic causing mini ground vibrations?

Intuitively a light pendulum is more affected by air resistance than a heavy one as it's mass/area is smaller

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 30/10/2020 12:04:03:

Hmmm.

• As I read that graph, as pressure increases the period gets longer so the clock slows down! …

Doh! This is why I value the forum so much – good people correct my mistakes. I read it the wrong way round.

I can do pressure vs amplitude – watch this space.

Dave

Edited By SillyOldDuffer on 30/10/2020 13:45:17

[John HaineParticipant @johnhaine32865]

Posted by duncan webster on 30/10/2020 12:24:30:

I think you still have a fairly light bob, could the odd spikes be related to passing motor traffic causing mini ground vibrations?

Intuitively a light pendulum is more affected by air resistance than a heavy one as it's mass/area is smaller

Yes, assuming it is the same physical size and shape its density will be lower.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 30/10/2020 12:04:03:

…

• Denser air has greater resistance so amplitude ought to decrease (unless you are controlling it), which would decrease the period through circular deviation (but that does depend on escapement deviation as well). Do you have a plot of amplitude vs, pressure?

Another correlation:

I am controlling amplitude: in this run the bob gets 1mS impulse when amplitude falls below 0.4 On average the bob does nearly 39 swings per impulse.

Not looked at last night's run yet. It's doing 500µS impulses.

Dave

[John HaineParticipant @johnhaine32865]

Dave, if you could let me have a full set of results I could run a multivariate regression on them? Ideally a csv file of

<period>,<amplitude>,<temp>,<press>

Though the order doesn't matter (except that period should be the first).

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 30/10/2020 13:55:51:

Dave, if you could let me have a full set of results I could run a multivariate regression on them? Ideally a csv file of

<period>,<amplitude>,<temp>,<press>

Though the order doesn't matter (except that period should be the first).

Yes please! I'll produce a CSV and send you a dropbox link.

Dave

[SillyOldDufferModerator @sillyoldduffer]

Posted by SillyOldDuffer on 30/10/2020 14:38:36:

Posted by John Haine on 30/10/2020 13:55:51:

Dave, if you could let me have a full set of results I could run a multivariate regression on them? Ideally a csv file of

<period>,<amplitude>,<temp>,<press>

Though the order doesn't matter (except that period should be the first).

Yes please! I'll produce a CSV and send you a dropbox link.

Dave

This Dropbox Link is to a 2.4Mb CSV with fields:

Period – integer, microseconds
Amplitude – float, ratio
Temp – float, degrees C
Pressure – float, hPa
RelHumidity – float, %

Many thanks,

Dave

[John HaineParticipant @johnhaine32865]

This is the R-Studio session:

> a1000pt4 <- read.csv("D:/John Haine/Documents/Personal/ME website/Dave's clock/a1000pt4.csv", header=FALSE)
> View(a1000pt4)
> Ard_dave <- lm(a1000pt4)
> Ard_dave

Call:
lm(formula = a1000pt4)

Coefficients:
(Intercept) V2 V3 V4 V5
922805.44 4035.47 -38.02 13.76 -23.56

> summary(Ard_dave)

Call:
lm(formula = a1000pt4)

Residuals:
Min 1Q Median 3Q Max
-6632.8 -100.9 -7.5 89.1 2285.3

Coefficients:
Estimate Std. Error t value Pr(>|t|)
(Intercept) 9.228e+05 3.148e+02 2931.72 <2e-16 ***
V2 4.035e+03 8.417e+01 47.94 <2e-16 ***
V3 -3.802e+01 1.602e+00 -23.74 <2e-16 ***
V4 1.376e+01 3.718e-01 37.01 <2e-16 ***
V5 -2.356e+01 1.137e+00 -20.73 <2e-16 ***
—
Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1

Residual standard error: 213.4 on 69996 degrees of freedom
Multiple R-squared: 0.05846, Adjusted R-squared: 0.05841
F-statistic: 1087 on 4 and 69996 DF, p-value: < 2.2e-16

Which means I think that: Period (us) =

922805 + 4035.47xAmplitude -38.02xTemp +13.76xPressure -23.56xRelHumid.

[duncan webster 1Participant @duncanwebster1]

Posted by John Haine on 30/10/2020 13:35:59:

Posted by duncan webster on 30/10/2020 12:24:30:

I think you still have a fairly light bob, could the odd spikes be related to passing motor traffic causing mini ground vibrations?

Intuitively a light pendulum is more affected by air resistance than a heavy one as it's mass/area is smaller

Yes, assuming it is the same physical size and shape its density will be lower.

I meant a heavy bob of the same density, it still has more mass per unit area whether that is cross section or total surface area. Air resistance must be down to area.

[John HaineParticipant @johnhaine32865]

Sorry, I got confused between air resistance and buoyancy. It's slightly counter-intuitive but for a given impulse and a bob with a given air resistance, as the bob mass gets bigger and the Q increases, the amplitude nevertheless stays the same, it just takes longer to get there.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 30/10/2020 17:32:20:….

Which means I think that: Period (us) =

922805 + 4035.47xAmplitude -38.02xTemp +13.76xPressure -23.56xRelHumid.

Many thanks John. Linear regression is one of the many mathematical tools outside my reach. I'm out most of today but I think the next step is to have the Arduino apply the corrections and see what happens.

Interesting humidity has appeared as a factor. Is humidity affecting the carbon fibre rod directly, or is relative humidity itself a function of temperature and air pressure? I don't know. Correlation is not causality.

More fun tomorrow, hurrah!

Cheers,

Dave

[John HaineParticipant @johnhaine32865]

Regression is a bit foreign to me too! I just use the software – apart from the strange syntax R Studio is very easy once you get used to it, and is used for heavyweight statistical analysis (such as epidemiological data…), not to mention free!

Supposedly CF road does absorb water from the air into the resin which affects the weight (not the length) but the amount is tiny and the effect usually insignificant compared to the bob – I estimated about 3 uS total for my pendulum IIRC. May be more if the rod weight and springiness is more significant. I have seen some analysis of the effect of humidity on Clock B (since it was measured) and as far as I recall it is very small:

**LINK**

That also has some useful information about "computer compensation".

Something I'm not clear about in my mind is just what correlation we should be looking for. Buoyancy and amplitude depend on density, but density is a function of both pressure and temperature. So should one normalise each pressure reading to absolute temperature to allow for this? There's also a small effect of temperature on viscosity which Harrison is said to have allowed for.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 31/10/2020 11:29:55:

Regression is a bit foreign to me too! I just use the software – apart from the strange syntax R Studio is very easy once you get used to it, and is used for heavyweight statistical analysis (such as epidemiological data…), not to mention free!

Supposedly CF road does absorb water from the air into the resin which affects the weight (not the length) but the amount is tiny and the effect usually insignificant compared to the bob – I estimated about 3 uS total for my pendulum IIRC. May be more if the rod weight and springiness is more significant. I have seen some analysis of the effect of humidity on Clock B (since it was measured) and as far as I recall it is very small:

**LINK**

That also has some useful information about "computer compensation".

Something I'm not clear about in my mind is just what correlation we should be looking for. Buoyancy and amplitude depend on density, but density is a function of both pressure and temperature. So should one normalise each pressure reading to absolute temperature to allow for this? There's also a small effect of temperature on viscosity which Harrison is said to have allowed for.

I'm not sure what's going on after looking at last night's run. I added "Haines Seconds" to the Arduino, which now calculates ticks as: 922805 + 4035.47xAmplitude -38.02xTemp +13.76xPressure -23.56xRelHumid and upgraded the stats program. Result of graphing Haines ticks rather than pendulum measured ticks:

Big reduction in stdev, hurrah, but the result over nearly 15hrs is 47 seconds out, which is worse than my simple correction based on averaging the arduino clock to align it with GPS seconds. I believe linear regression should do better than my method, so something's adrift. Below, uncompensated pendulum is 6.9 seconds out, and crudely recalibrating the Arduino clock brings the error over 15 hours down to under a second.

One difference is Haines seconds (from linear regression) have stronger correlations with temp, humidity and pressure when the stats are generated from them rather than pendulum measurements. I expected the regression formula to have that effect but note the correlation with pressure is more amplified. It may indicate the formula is over-compensating for pressure.

Not blaming the formula at all. It assumes the clock was set up as it was in the data file I sent, which may not be true.

Having swotted up on Linear Regression I reckon I can apply it with the software I'm using (Python Numpy & SciPy). Nothing against R except I'm not familiar with it and I'm fluent in Python. I'll be a happy man if I can get the same answer as you from the log.

Meanwhile preparing to move the clock from Arduino to Raspberry. Only necessary to get decent sub-second clock measurements, possible because the Raspberry has NTP. No need for a Raspberry once the clock has been analysed. Although Raspberries are much faster than Arduinos they don't support user-level interrupts. Not having interrupts makes coding a fast response to pendulum events harder, but I'm sure I can make it work. Transferring to Raspberry is almost a complete re-write.

Also trying to come up with a way of detecting vibration, which may be causing the time anomalies I see in the data. No luck so far, and – unlike Arduino – the Raspberry doesn't even have the basics!

Many thanks for the link to 'Clock B' – fascinating, and I clearly have a long way to go. Also been reading through your other thread, which shows I'm not a pioneer!

Cheers,

Dave

[John HaineParticipant @johnhaine32865]

Ah, the regression won't remove the rate, it just evaluates the sensitivity of the period to the other variables.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 01/11/2020 16:55:48:

Ah, the regression won't remove the rate, it just evaluates the sensitivity of the period to the other variables.

I've gone a step too far again!

Ta,

Dave

[SillyOldDufferModerator @sillyoldduffer]

Spent a massive amount of time getting a Raspberry Pi3B to drive and measure my pendulum directly. Lesson learned, when writing to GPIO pins in 'C' make absolutely certain it's the right pin. Wring to the wrong pin crashes the Pi .

Anyway the expected advantage of using a Pi instead of an Arduino was the Pi has nanosecond precision timing and good long-term stability because it regularly synchronises with GMT over the network.

I expected timing inaccuracies due to the Pi swapping my clock program in and out depending on other activity on the system (like resynchronising time!). To avoid that I programmed the clock program to have top priority on one of the 4 CPUs.  Whatever other tasks the Pi has to do run on the other three CPUs.

This works, ardclock almost flat out at priority -71, with everything else queued behind:

Alas all is not well and I don't understand it! I connected the pi to a GPS module emitting ultra-high accuracy second pulses expecting the Pi to be measure seconds to within at least a tenth of a microsecond or better. And it mostly does, but not reliably!

Although the vast majority of measurements are close to the average 1.000002784s, stdev only 0.000111703, the graph shows bursts of instability and excursions of up to nearly 1mS. Although Arduino measures with a higher standard deviation, it's less wild.

The pi is underperforming in an unexpected way – I don't know why it should wobble at the beginning, then measure well for about two hours, before throwing another wobbler.

John Haines provided source code of a different approach to measuring pps accurately with a Pi, so I shall try that. Fingers crossed.

Dave

Edited By SillyOldDuffer on 05/11/2020 15:03:19

[John HaineParticipant @johnhaine32865]

A wild thought, it couldn't be the GPS wobbling could it?

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 05/11/2020 17:16:24:

A wild thought, it couldn't be the GPS wobbling could it?

Possibly! The GPS module flashes continually when it loses the number of satellites needed for high-precision time and it just lost sync for about a minute. Could be unreliable because the antenna isn't well positioned – balanced on a window sill next to metal framed double glazing.

Meanwhile Mike's Code is working, ta. Extremely useful because it doesn't work as I expected and it revealed another approach entirely. While Mike reads a device, it's not the simple solution I had in mind. Instead he uses a device interface to an official kernel module, which I didn't know existed. Should be good because the module is designed to improve on NTP by comparing it with an accurate external time source, like a GPS module. One purpose is to let a Pi be used as a Tier 1 NTP Server rather than a bog standard client; quite an improvement.

Collecting data at the moment. I'll graph it when there's a couple of hours in the bag.

Cheers,

Dave

[Michael GilliganParticipant @michaelgilligan61133]

I’m probably being thick, Dave … but I have to ask :

Why do you need to check short-term and long-term performance concurrently ?

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Posted by Michael Gilligan on 06/11/2020 11:12:30:

I’m probably being thick, Dave … but I have to ask :

Why do you need to check short-term and long-term performance concurrently ?

MichaelG.

Not thick at all, a good question. It's because some, but not all, short-term errors accumulate to influence the rate. Which? By comparing short and long-term I can separate out random fluctuations from systemic changes due to temperature, barometric pressure, or whatever.

Comparing short and long term pendulum times has already shown an effect I'd bet money applies to most pendulum clocks. It's that many sources of pendulum error tend to cancel out, making it possible for a relatively imperfect clock to keep good long-term time. However, I want to know if my simple carbon fibre swinger is a good time-keeper despite imperfections, or if it's a step beyond what was possible in the 1930's before electronics took over. In 2020 can I keep better time with a pendulum than Reifler, Shortt and Fedchenko? (Probably not, but it's interesting!)

Current problem is I want a Raspberry Pi to timestamp pendulum events more accurately than Arduino, which the Pi should do. Unfortunately test comparisons between Pi time and GPS seconds show the Pi to be too erratic for my purposes. Although mostly consistent, Pi time has strange unpredictable variations I don't understand. I'm hoping the error is in my software rather than hardware.

Dave

[Author]

Posts