Arduino Pendulum Clock Design - Comments Welcome

And as if by magic latent modes may well explain this graph, taken last night after reassembling the clock on my dining table to upload & test the software upgrade:

Just flung together to make the clock run with no attempt to level it or adjust the electromagnet. Had to replace the pendulum rod again due to clumsiness. Red line is the average and the orange line is the rolling average. Pendulum in blue, and not only are the spikes fairly regularly spaced, they trace a wave along the top. Zooming in on one of the humps confirms symmetry:

My guess is the electromagnet was twanging the pendulum rod and the bob was swinging elliptically. I was concentrating on the computer upgrade and didn't look, shame.

Clock in bits while I redesign the magnet holder. Could take a while because I can't run the 3D printer without tidying up first.

Dave

Latest report, I've not been idle. Mk2 upgrade now operational and been the target of much experimentation. Physically the clock has a new electromagnet holder, with the magnet fixed to one side and the wiring has been routed to allow the shield to be mounted, but not evacuated yet.

Software upgrades include a general tidy-up, auto start, determination of amplitude and a primitive amplitude regulator.

Experimentation focussed on when best to trigger the impulse. The idea was to minimise the amount of disturbance by minimally pulsing the magnet close to top of swing. Although the software allows me to impulse the bob at any time, working out exactly when is a little difficult. Thanks to Michael, Duncan and John I put this diagram together. (First attempt at this involved extrapolating a sine wave from the circle, but this is clumsy and unnecessary. Woodward's "My Own Right Time" describes the method in the chapter on Disturbed Harmonic Motion, which I read after painfully re-inventing the wheel. Woodward calls it a Phase Diagram.)

The time taken by the pendulum to move between any two points can be found. It takes about 0.883mS for the pendulum to swing from one side to the other in back, which is 360° around the circle. The horizontal line represents the distance travelled by the pendulum; mine swings about 4°. Could be graduated in millimetres. Anyway, my beam break sensor is mounted about 1.5° off swing centre. This corresponds to an angle of about 112° from extreme right so:

time from right to sensor = 112/360 * 0.883 = 0.27mS

So if I decide to fire the impulse when the pendulum is at -3.5°, the Phase Diagram shows this to be 39° past sensor, or 39/360 * 0.883 = 0.096mS. The analysis reveals a problem: the maximum pulse must fit into the time between 'fire' and 'left'. Fussy to set-up.

By analogy I expected the pendulum to behave like a child's swing. There would be a resonance. However, impulsing at various times between 'sensor' and 'left', failed to find a sweet spot. I believe the analogy is false: the amount of energy needed to overcome losses and keep the bob swinging is constant. Further, provided the bob is travelling towards the magnet, it doesn't matter when the impulse is applied. As theory suggests the bob should be impulsed when it's travelling at maximum speed (centre), it's best to pulse at sensor as soon as the beam is broken. Doing this also eliminates any need for complicated timing calculations.

Although the magnet holder could be modified to hold the beam breaker sensor at 'centre', I decided to leave it offset. This is based on another unproven notion, which is that changes in amplitude can be detected by comparing the time spent by the bob on each side of the sensor. I believe time spent left of my offset sensor decays faster than time spent right of it. So the mark space ratio can be used to detect if amplitude is increasing or decreasing, and used to regulate impulse strength. A high-amplitude pendulum is closer to 50:50 than this example:

Last night's test run is promising, and has spawned some new ideas. The clock is on the dining table in my south facing radiator about 1m away from the window and central heating radiator. Shield off.

Weakish correlations are detected between period and both humidity and temperature. There's a major disturbance just after 7am. My first thought was it's due to temperature resulting from my central heating firing up. However, as I've had bother with the beam breaker sensor, I think it's more likely to be daylight. The vertical blue and red lines show civil twilight and sunrise respectively. I suspect increasing light falling on the sensor alters the impulse trigger point.

My simple amplitude regulator is akin to the hit and miss device used on old single cylinder oil engines, and amplitude gradually decaying overnight shows it's not quite set right. A more linear algorithm would help, but I need to re-test with the shield in place first. Also, an IR level sensor should be added to log ambient brightness.

Dave

Edited By SillyOldDuffer on 19/10/2020 12:22:17

Good progress Dave.

I assume your time units are seconds, not ms? To be pedantic, the "phase diagram" plots velocity vertically, the units being scaled so it is a circle, and normally rotation is taken to be anticlockwise.

You can measure amplitude using an offset sensor as you suggest - this link describes how but refers also to a copy of HSN where the method was first described. I do something slightly similar though my main reason for using an offset is so the Arduino "knows" which side the pendulum is.

Keep up the good work, Dave

... Meanwhile: I have been trying [and inevitably failing] to tidy-up the Toy Room

MichaelG.

More progress. Running the clock shielded eliminated nastiness caused by the rising sun, and improved amplitude control much reduces bob jitter. (The algorithm allows amplitude to settle naturally at whatever level requires least change: the bob isn't forced to maintain a particular amplitude.)

Although the graphs show turbulence when the heating comes on and people crash about in the morning, the effect on period is much lower than when the IR sensor was being lit up by the sun too.

Sunshine eliminated, there is detectable negative correlation between air pressure and period, and a much stronger negative correlation between temperature and period. Temperature correlation was a disappointment until I realised the link may be due to the Arduino's uncompensated crystal oscillator rather than the carbon fibre pendulum rod. Another point to be proved.

Looking at the stats:

The pendulum is 6.7 seconds fast over 15 hours compared with a DS3621 Real Time Clock, which claims ±2ppm accuracy over my test temperature range.

The Arduino reports ticks averaging 865248µS, whereas to match the RTC they should be 865144µS. This error could be due to the uncalibrated Arduino. (Another proof required!)

The spikes at tick 9000 and those after tick 58000 are due to me wobbling the dining table. The pendulum's sensitivity to vibration is a serious flaw.

Now the clock is running reliably next job is to measure Q. At last. Bet it's low.

Dave

One way to get a more precise calibration is to get the Arduino to do a println(something) on each swing and log this with the serial monitor on a PC which has its internal clock slaved to NTP. For example my Ubuntu laptop (which I don't mind dedicating to the task) gives a high resolution timestamp on each record, which you can copy/paste into Excel (or other) for analysis. (This is easier if you switch off autoscroll.)

I'll give that a try thanks.

Latest report. I measured Q. Between 80 and 140, which is dreadful! The implication is my carbon fibre pendulum is a spring, and not a good one either. As the problem is almost certainly the matrix rather than the fibre, I experimented with removing it. No luck with chemicals but a blowlamp does the job. Although carbon might be expected to catch fire, it glows white hot in a reducing flame and survives.

The Mk3 clock will suspend the rod by clamping the fibres at one end, allowing the pendulum to swing on a short length of them. Fingers crossed, removing spring from the rod at the suspension point should improve Q.

I was able to get a feel for the stability of the Arduino's clock relative to accurate seconds from a GPS module by using micros() to measure the time taken between the rising edges of GPS second pulses. One Arduino Nano measures the second as about 1001400 microseconds, the Nano in my pendulum clock is closer - it averages 1 second as 1000090.4 microseconds. Nanos are clocked by Ceramic Resonators, only about ±0.5% accurate and temperature sensitive.

The rig makes it easy to test for correlation between frequency and temperature. The graphs clearly show the relationship with mirror image curves and the Pearson Correlation is -0.962, where 1 is identical.

Would be a result except there's no correlation between Period and Temperature!

Also been looking into Allan Deviation and Variation. Thick fog ahead!

Dave

Edited By SillyOldDuffer on 23/10/2020 21:28:38

Apologies if this is old hat Dave (SOD).

I haven't been taking much notice of your thread, but I spotted this from Big Clive.

**LINK**

I trust it has some relevance.

Regards,

Sam

.

Learning has been seen to take place

MichaelG.

According to bob shape best shape for a bob is like a pointed rugby ball. Difficult to keep the point going in the direction of swing with SOD's rod, next best is spherical. Dense is good, so tungsten or copper/tungsten alloy, which is machine-able. According to wikipedia tungsten is magnetic, not sure about the alloy

I suggest the best approach to the stranded rod is to cut away a lot of the fibres then splay the remainder out like a ribbon. This will prevent fibres rubbing on each other and dissipating energy, I think a well known French clock (Bulle?) had a silk ribbon suspension

Edited By duncan webster on 23/10/2020 23:52:32

Edited By duncan webster on 24/10/2020 00:12:40

Edited By duncan webster on 24/10/2020 00:14:25

Hello Dave,

is your arduino cristal temperature compensated ? I have an electronic watch programmed for switch purpose of my central heating and i noticed time differences over temperature.

Werner

That must be annoying having your central heating come on few microseconds off target time

Mike

Been there, still there, and the more I learn the more I realise that mostly I learn how little I know...

My GPSDO, which was to be an 'accurate' 10MHz reference for my frequency counter and signal generator, has since taken over my life and become the prime focus...Accuracy of 10^-9 was easy to achieve, 10^-12 took more effort and 10^-13 has been seen…But all in the confines of my own mind, so how to measure and prove. Google a lot, read lot, and join the TimeNuts forums, and then you are done for...Allen Deviation becomes the Holy Grail, and when you go down that road, you end up being a collector of all things that oscillate..As in all things, to measure accurately , the ruler ( or reference oscillator) has to be better than the thing being measured. So now I am collecting Expensive surplus OCXO's, trying to find 'reasonable' Rubidium references, and have contracted the TimeNuts disease..the subsequent cure for which seems to be a whole room dedicated to housing shelves filled with oscillators, frequency counters, Rubidium, Cesium and Hydrogen Maser references...

And it does not stop just with the oscillator - now it degenerates to wrestling with the air conditioning and climate control of the study ambient, studies into ambient temp control within a chamber that I could fit the oven controlled oscillator into, etc. And all this time, I still cannot use the GPSDO as a reference for my counter, cause the GPSDO is always in bits for some or other refinement..I need a Hobby..

The one major discovery has been where the 'Nuts' comes from in the Forum name..

Sorry, nothing to add that helps you Dave, but beware of the road ahead!!!

Joe

Sorry for the unconventional reply format above!

Werner, the Arduino as Dave says doesn't even use a crystal let alone a temperature compensated one!

No comfort from Joe, I have all the symptoms of TimeNut Syndrome albeit on a smaller scale!

My set-up at the moment is this:

Supported with a Frequency Counter, oscilloscope and computer with an extensive scientific maths capability doing the statistics and graphs. Chief flaw is me, because the gap between what I'm doing and understanding it is much larger than expected. As you say 'the more I learn the more I realise that mostly I learn how little I know' : exactly!

Made some progress with Allan though. I've found a Python software module that does the hard work provided I can understand it! I was able to graph white noise and brownian motion.

I understand White Noise to represent a perfect pendulum, one influenced only by truly random variations due to natural noise at the atomic level. The ideal slope is a nice straight diagonal line falling 45° to the right, shown in Blue.

Real oscillators suffer other effects. For example, Invar alloy is unstable over time in that microscopic structural changes cause tiny increases and decreases of rod length. These movements alter the period of each swing causing the clock to go on a random walk that frequency modulates the period, oh dear. The orange line demonstrates Brownian motion which is characteristic of random walk error. Compared with white noise the slope and shape is different.

This and other defects can be detected by taking many samples from the test clock and comparing them statistically with a better one. A promising technique, except toddlers need to learn to walk properly before trying to sprint! At the moment my pendulum has more serious defects.

One thing Joe or another expert might know the answer to? In so far as I understand it, Allan requires me to generate a list of phase differences between the test clock and its reference. The Allan examples assume test and reference are both outputting 1 pulse per second (so calculating small phase differences is easy). Unfortunately my GPS reference is 1 pulse per second while the pendulum is about 0.883 pulses per second. How do I normalise the data-sets?

Dave

Edited By SillyOldDuffer on 24/10/2020 13:18:47

No, Allan compares the test clock with itself. If you use the TimeLab package you just give it a big file list of successive period readings and it does the rest (IIRC).

Here is an Adev plot of my "Arduinome" clock I just generated to remind myself.

It takes the whole file of which only the first column are period measurements and ignores the rest. So far I haven't really worked out what it means but generally the trend is sort of diagonally downwards though with some flattening off. What the little wiggles result from I don't know. Good explanation here. If you explore that site you can read about Tom's adventures testing General Relativity on a camping trip.

John, you are my hero. I had the fixed idea Allan analysed phase differences between clocks and managed to spin my reading of the documentation to cement the misunderstanding. Might have taken me weeks to get back on track. Thanks to you sorting me out it's easy to to apply any of the methods provided in Python's Allantools module.

Interpreting the graphs is another walk in the dark, but I read your Arduinome chart thus:

• The line generally falls from left to right, which is good.
• The wave like wiggles in the first 100 seconds could be settling errors, maybe due to the pendulum vibrating after start-up, or the clock being bumped whilst the measurement was set up.
• Y axis values are small, which I think indicates good stability.

My clock's chart:

• The tick shaped line is bad - rising to the right indicates a consistent rate error. Sharp falls are characterised by Rowland as observation error. In my case, pretty certain the observations are OK, and the real cause is pendulum bounce due to restarting the clock from scratch for each test.
• Y-axis values are big, which I think indicates poor stability.

Could be wrong!

Meanwhile, I broke the pendulum rod again. I frayed the rod and made a brass clamp to hold the fibres OK but got clumsy reassembling the clock. Showstopper - looks like I've run out of 0.5mm rod and will have to order more.

Dave

John, please explain..Allen deviation is re result of a mathematical/statistical process applied to a set of data that comprises the sample interval and the phase difference between the measured clock time interval and the reference clock time interval. It cannot be the phase delta in the interval between the measured clock and itself...Then there will never be a phase delta...

Eg, A total of N time interval measurements are taken at a 1 second rate. That is, the time (aka phase) of an oscillator is compared against the time (aka phase) of a reference standard once a second for NX1s . That data is then used to determine the Allan Deviation and Variation.

Joe

Edited By Joseph Noci 1 on 24/10/2020 17:39:44

The comparison to a reference is already done by measuring the period. AV is a measure of how the period varies with time.

Agreed, but somewhere in there is an accurate 'clock' is required - and that is the clock that is used to measure the period. THAT clock has to be stable, accurate, etc. So there is the accurate reference...You cannot get away from that - the comparison is not with the clock itself, it is the variation of the clock period against an accurate reference - the timebase used to measure the period.