Arduino Pendulum Clock Design – Comments Welcome

[SillyOldDufferModerator @sillyoldduffer]

Posted by Peter Bell on 10/12/2020 21:14:51:

…

I'm interested in seeing how you get on with the Nano Every. I bought a couple last year but I've never managed to get them to run anything more than Blink.

Just plugged it in to remind me of what the problem is and got a message saying I needed a download into the library for the Every etc. Did this but still no good after configuring boards in tools etc. Gave one to a very knowledgable friend but he gave up as well so I'm looking forward to finding out what I've got wrong when yours works!

Peter

I'm finding the Every a bit fussy for various reasons!

Although the pin-out is the same as a Nano, the Every has a different microcontroller. Before it can be programmed from the Arduino IDE, it's necessary to install 'Arduino mega AVRBoards' with the IDE's Boards Manager and select Arduino Nano Every from the list.

Once the board is installed it may be necessary to select 'Registers Emulation' to ATMega328 in the Tools menu to get some libraries to work. Other libraries don't work at all. It's because the ATmega4809 microcontroller is different from the ATMega328. I'd expect libraries to start working as their owners gradually bring them up to date.

Otherwise, most ordinary programming works as expected, except where a hardware difference gets in the way. Compared with the basic Nano, the Every has multiple improvements but these may not be useful, and some of them get in the way. Good news, it's faster, has more memory (apart from eprom), all pins handle external interrupts, it has several clock options (speed vs power saving), more serial connections, faster USB, and more timers, which are smarter too. Bad news, not all pins are identical to the Nano, and code that gets down and dirty with the hardware will need modification. This includes my clock program, which uses a Timer and Input Capture.

Another negative, downloading code to the Every is a little fragile, at least on my Ubuntu 20.04. The loader sometimes loses the serial port, making it necessary to unplug the Every and/or restart the IDE to restore order. Seems best to close the Serial Monitor before uploading program changes. (Both claim the same serial port, with a possibility of confusion.)

The loader outputs an alarming message about flash and boot memory that looks nasty but is irrelevant.

So, nice bit of kit, but not 100% compatible, and the differences can be hard to understand. The ordinary Nano is easier to use because everything 'just works'.

Two reasons I want an Every for my clock. The Every makes it straightforward to connect an external 20MHz clock, and I need a good TXCO for stability and accuracy. The ATmega4809's more advanced timers were expected to be an advantage too but it looks like I've blundered. Reading the data sheet (over 500 pages), I can't see how to get a timer set up to do Input Capture Counter to do overflow interrupts as well. One or the other only. Easy on an ordinary Nano, but it appears the ATmega4809's hardware doesn't support that particular combination. Loads of clever counter-timer features I don't want, but not the one simple thing I need. Argh!

Dave

[John HaineParticipant @johnhaine32865]

Could be worth a post on the Arduino support forum Dave?

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 12/12/2020 17:14:43:

Could be worth a post on the Arduino support forum Dave?

I think I've found a way John. The ATmega4809 has four 16 bit counter/timers, and there's no reason why I shouldn't use two of them for this. I've programmed one to do Input capture, which gets time within a 2^16 clock tick slot. Each tick is 50nS if I can get 20MHz external oscillator working. At the same time a second counter reports when it reaches 65536, which is the same as counter overflow. Seems to work.

Got as far as connecting my signal generator to the chip as an external clock but it didn't work. By the time a 20MHz square wave reaches the end of my connecting coax, it's not square! I need to bite the bullet and solder up an SMD TXCO.

Meanwhile doing some long test runs on the pendulum with mixed results. Keeping time within 0.5s of NTP per day, but the logs contain anomalies. Judging by the regular peaks on this log scale histogram (which amplifies small counts), the pendulum is modulated:

Another interesting possibility from the night before last. Generally Relative Humidity and Temperature track each other closely, and I assumed temperature disturbed the Arduino's oscillator. The Pro-micro I'm using now has a crystal and is less effected by temperature. Sunday night RH changed independent of temperature and it showed up as a correlation. I think my carbon fibre thread is sensitive to humidity. Be good to seal the clock and prove it.

Dave

 

 

Edited By SillyOldDuffer on 15/12/2020 18:32:13

[John HaineParticipant @johnhaine32865]

Dave, just wondering how you are getting on, especially with soldering down the TCXO? I discovered these when looking at using another SMD device:

https://uk.farnell.com/schmartboard/204-0003-01/ic-adaptor-sc70-soic-sot-to-dip/dp/2483414

I think there are others around too.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 18/12/2020 14:47:30:

Dave, just wondering how you are getting on, especially with soldering down the TCXO? …

Misadventures galore!

Done a series of overnight runs with the clock in a safe place, an unheated bedroom. The purpose was to test the effect of altering impulse size, and to confirm the bob would detect reliably after reducing the power of the IR transmitter. (Problems caused by internal reflections inside the clock.)

According to the logs, reducing impulse improved Q – unlikely! Traced last night to a software bug that meant the impulse size wasn't actually being altered by parameter changes. Bodged a quick fix with this result:

Reducing IR transmit power cleaned up some bonkers results almost certainly due to false triggering due to internal reflections inside the clock. Although fitting a black cardboard shield and painting the PVC pipe blue on the inside helped, the IR sensor module I'm using runs a IR LED flat out – too powerful. Slits would be a good idea too.

A few points of interest;

• Clock is about 1 second fast over 18 hours – worst result ever, even though the standard deviation is better!
• The histogram isn't symmetric.
• There's a mild positive correlation between air pressure and period.

Good news about the microcontroller is it measures OK down to about 0.1uS and using a board fitted with a real crystal has improved temperature stability and reduced jitter. Though the IR sensors need more work I'm confident I'm seeing genuine clock problems rather than computing artefacts.

I've experimented clocking a Nano Every from a signal generator and learned it's not possible to drive a counter timer directly at 20MHz; rather the whole CPU has to be accelerated. It's a little dangerous. Coding the chip to use an external clock risks bricking it if the clock fails so I need to be sure the TXCO is working. Rather than solder one up today, I've been working on another software upgrade. Last nights bodge causes impulses to vary erratically around 2mS and may be jittering the pendulum. Fingers crossed, I can now do it properly!

Here's last night's Allan Deviation. No idea what it means, good or bad!

Can't complain this projects isn't keeping me amused during the lock-down!

Dave

[SillyOldDufferModerator @sillyoldduffer]

So far my pendulum was only being measured; now I've upgraded it to keep time itself. Time is set by the PC; it reads NTP time until a seconds roll-over is detected and then sets the Duffer Clock to HHMMSS. Thereafter the clock is incremented by the pendulum, one average period per tick.

Of course I couldn't resist tidying up the rest of code, and promptly broke it! Moving the pendulum to test it with the aid of an oscilloscope had an interesting result when it was replaced. I levelled the clock more carefully and got a a dramatic reduction in the amount of power needed to maintain the pendulum at the same amplitude (40%). From 3 to 5 swings per 1.6mS impulse up to about 35 swings per impulse.

This, I suspect, is a design problem. As the rod is its own suspense spring, failure to level the frame must bend the rod, causing impulses from one side to do more work than the other:

A second problem was spotted when the clock was running with the shield off. The IR beam is interrupted by the bob, and internal reflections have already been identified as causing false triggering. I noticed the bob doesn't clear the beam at amplitude 40%, so 'normal operation' must involve a reflection, probably like this:

I'll claim this to be a clever design feature if it works! Otherwise, expect a moderator to revise history by deleting this blunder!

After setting the clock going for another long run, I decided to attempt soldering an SMD TXCO ready for the next stage. Bought four in various frequencies and distinctly remember putting them somewhere safe. Now I can't find them. Argh!

Dave

 

Edited By SillyOldDuffer on 22/12/2020 21:26:28

[Michael GilliganParticipant @michaelgilligan61133]

This might be worth a look : **LINK**

https://www.researchgate.net/publication/332543537_BUILDING_A_RASPBERRY_PI_ZERO-W_GPS_NETWORK_TIME_SERVER_FOR_UNDER_50

The Author’s credentials are good.

 

MichaelG.

.

Edit: See also https://lastminuteengineers.com/neo6m-gps-arduino-tutorial/

Edited By Michael Gilligan on 26/12/2020 22:52:04

[SillyOldDufferModerator @sillyoldduffer]

Posted by Michael Gilligan on 26/12/2020 22:47:39:

This might be worth a look : **LINK**

MichaelG.

It is! Thanks, I'll give that a try.

Latest report, over the holiday I've rushed through various changes designed to improve clock monitoring over at least 24 hours. And silly mistakes bit me on the bum every time!

At present, the clock is set up to measure time in three ways:

1. The clock measures each tick internally using the Arduino's 16MHhz crystal oscillator (which will be replaced with a TXCO when I remember where I left it.)
2. The clock outputs HHMMSS.ssssss based on counting ticks, where each tick is assumed to be of average length (as determined from a previous run)
3. Both of the clock's notions of time are compared with UNIX time (set and updated by NTP)

The graphs from last night show a few problems:

The top graph, showing period measured by Arduino crystal, looks fairly stable apart from 4 glitches, until about 9am when the pendulum runs wild eventually stopping at 11:10am. Cause of stoppage unknown, but it may be due to rising temperature, or this morning's bright sunshine confusing the sensor. Zooming in on the period graph shows more trouble in the detail:

This graph shows the pendulum to be stable at first, except it gradually speeds up. Then period settles at about 0.9324s except it bounces ever more wildly until midnight, then gradually calming down until it stabilises somewhat unpredictably at about 5:15. Again, cause unknown.

Zooming in on one of descending glitches shows these are odd too:

It isn't a single event, rather the pendulum speeds up, does about 40 quick ticks, and then returns to the average. I've no idea what would cause a pendulum to do that!

My next problem is mathematical and although I'm sure the answer is easy I've failed utterly to do the algebra.

At the moment, the Arduino calculates HHMMSS by assuming every tick is average, which isn't true. Apart from the wildness noted above, according to the data the pendulum reacts to heat, air pressure and humidity. (Still to be proven, but I'm fairly certain the Arduino responds to heat, not the pendulum.) A little difficult to disentangle the two, but there's strong evidence the pendulum is influenced by both air-pressure and humidity. Higher air pressure reduces the weight of the bob and increases air resistance slightly. To make a rod, carbon-fibres are embedded in a resin matrix and it's likely the matrix is sensitive to humidity.

As the clock knows what temperature, air pressure, and humidity are, I want to correct the average tick by applying a compensating formula. Linear Regression gives the following y = mx + c values:

ticks = x, temp = y : -19.98002063 35.27297589

ticks = x, humidity = y : 52.18719052 16.32451551

ticks = x, pressure = y : 81.65298034 901.6873213

How do you convert a y = mx + c slope into the corresponding correction? For example, given the period of a tick tick at a known temperature, how do you calculate value of tick for any other temperature?

I thought this was easy until I tried to do it . Brain refused to cooperate as soon as I put pencil to paper…

Dave

 

Edited By SillyOldDuffer on 27/12/2020 14:16:19

Edited By SillyOldDuffer on 27/12/2020 14:18:16

[John HaineParticipant @johnhaine32865]

I think you need the multivariate regression coefficients first of all. Then if you assume that the period P is given by something like:

P = P0 + a x temp + b x pressure + c x humidity

then you just subtract the last 3 terms from the measured P to get P0. Excel or R can calculate the multivariate coefficients,

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 27/12/2020 15:37:08:

I think you need the multivariate regression coefficients first of all…

I agree, but baby steps first.

Problem reminder: I'm trying to measure how good or bad my novelty Pendulum Clock is to a high level of accuracy, microseconds or better. The current set-up uses a Sparkfun microPro (much like an Arduino Leonardo) , which – most important – comes with a 16MHz crystal oscillator rather than a cheap wobbly ceramic resonator. But, although considerably better than a resonator, the ordinary quartz crystal isn't temperature compensated. So I'm attempting to detect period variations due to temperature in a carbon fibre pendulum specifically chosen to have a low coefficient of expansion with a reference that's obviously temperature sensitive itself. A hardware cure for this is in the pipeline but I put the components somewhere safe and can't find them now! Hence this post is about temperature compensating the Arduino's crystal in software in hope of moving forward.

By establishing the relationship between frequency and temperature, it's possible to mathematically correct measured timings. But how?

First step is to measure the crystal's frequency over a range of temperatures and collect several hours worth data for analysis. Frequency and temperature are logged together. Next understand the necessary mathematical gymnastics and apply them to the data. The apparatus is:

The inputs measured are high accuracy one second pulses (11nS) from a GPS tracker module. These trip a hardware counter-timer inside the microcontroller that continuously counts pulses directly from the quartz crystal. The snapshot count is accurate to about ⅒ of a microsecond. A 16MHz crystal should output 16000000 pulses each second, but it won't be spot on, and it will drift as temperature changes.

Rather than leave a laptop on all night, the data is logged by a headless raspberryPi which can be left running in a corner for months if necessary. As the raspberry is network connected, the data it collects can be copied at any time to a big computer for independent number crunching.

Results. About 50000 seconds worth of frequency / temperature pairs are presented graphically.

The top two 'mirror image' graphs show there's a clear relationship between temperature and frequency: falling temperature causes the quartz crystal to speed up and a variation of 4°C shifts the crystal by about 30Hz. In this sample the crystal ranged from 15997857Hz to 15997888Hz.

Back to the theory. Assuming the variation is linear, the relationship between temperature and frequency is represented as a straight line graph obeying the standard formula y = mx + c

If the values of 'm' and 'c' are found the frequency of the crystal at any temperature can be predicted, allowing temperature compensation to be applied. In a mechanical clock, compensation is done by carefully selecting and dimensioning suitable materials to alter the length of the pendulum: not easy to design! In an electronic clock no need to change the mechanics because numbers can be corrected by formula. The microcontroller eliminates a tricky mechanical issue by doing a sum.

Extracting 'm' and 'c' from a dataset turns out to be a well-known problem and the Python numpy module I'm already using has a polyfit function that does the job in a blink. m=-5.21113 and c=15997975.666. The bottom graph shows applying the formula reduces drift from about 30Hz to about 6Hz, a worthwhile improvement.

The python program needed to crunch the numbers is another easy when you know how job!

Next step is to test what happens when the Arduino is coded to output temperature corrected values. Hopefully, temperature compensating the crystal will clear enough numeric fog to show any temperature sensitivity in my pendulum. If I can detect changes in period, then they're likely to be caused by my clock, not shortcomings in the electronic measurements.

Longer term John's comment about multivariate regression needs attention. The issue is my pendulum is almost certainly reacting to changes in humidity and air-pressure as well. Struggling with the maths! I know how to extract the coefficients but not how to separate them or how to apply them as corrections. (The goal is to understand what causes the pendulum to misbehave, not to create an accurate clock by numerically correcting the effect of unknown causes.)

Dave

Edited By SillyOldDuffer on 31/12/2020 14:50:06

[John HaineParticipant @johnhaine32865]

Posted by SillyOldDuffer on 31/12/2020 14:49:23:

Posted by John Haine on 27/12/2020 15:37:08:

I think you need the multivariate regression coefficients first of all…

………….. I know how to extract the coefficients but not how to separate them or how to apply them as corrections. (The goal is to understand what causes the pendulum to misbehave, not to create an accurate clock by numerically correcting the effect of unknown causes.)

Dave

Edited By SillyOldDuffer on 31/12/2020 14:50:06

Well, two problems: how to separate them, then how to apply "in reverse".

The multivariate regression algorithm takes care of the first, it assumes a relationship something like my formula between the variables and computes the separate coefficients for you.

To correct a value, say a period measurement taken at a particular temp, pressure, and humidity reading, I think you just calculate corrections by multiplying each reading by the negative of the coefficient and add it to the observed period. I've got no shortage of readings, I'll give it a try…

[duncan webster 1Participant @duncanwebster1]

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!

[Joseph Noci 1Participant @josephnoci1]

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

[John HaineParticipant @johnhaine32865]

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

[Michael GilliganParticipant @michaelgilligan61133]

Posted by SillyOldDuffer on 31/12/2020 14:49:23:

[…]

(The goal is to understand what causes the pendulum to misbehave, not to create an accurate clock by numerically correcting the effect of unknown causes.)

Dave

.

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.

[SillyOldDufferModerator @sillyoldduffer]

Posted by duncan webster on 31/12/2020 19:55:09:

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

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…

[John HaineParticipant @johnhaine32865]

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

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 01/01/2021 16:23:52:

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…

…

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.

… could you remind me what the columns are please? It would be easy enough to try the same approach with that data.

 

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

[John HaineParticipant @johnhaine32865]

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!).

[SillyOldDufferModerator @sillyoldduffer]

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

[John HaineParticipant @johnhaine32865]

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****6@dsl.pipex.com:

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

[SillyOldDufferModerator @sillyoldduffer]

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

[John HaineParticipant @johnhaine32865]

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

[SillyOldDufferModerator @sillyoldduffer]

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

[SillyOldDufferModerator @sillyoldduffer]

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

[Author]

Posts