This morning's results are disappointing even though the time-keeping was closer to reality: 36 seconds slow after 22 hours. The run was intended to test reduced impulses, 0.48mS rather than 1.6mS.
Sadly the Tick Time graph shows bursts of wild pendulum behaviour. Not good.
![clock12ticks.jpg clock12ticks.jpg](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==)
And the Tick distribution shows three modes, which skew the average well away from the mode, and a high standard deviation of nearly 3mS, yuk:
![clock12dist.jpg clock12dist.jpg](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==)
I think the fault is due to moving the clock physically to apply software upgrades. Not much stops the bob bouncing about in any direction. As already pointed out my suspension design is flawed, and I think mechanical issues are more likely to explain major misbehaviour than me tweaking the software:
![pendulmsprwocheeks.jpg pendulmsprwocheeks.jpg](data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==)
- Nothing stops the whole spring moving right/left other than the clamp force. Better I think to solder it as well.
- The spring will buckle unless the clock is exactly vertical. An arrangement allowing the suspension to tilt is needed to prevent this. (See John's photo earlier in the thread.)
- As the pendulum is delicate, some way of stopping it flying about during transit is needed
- Better to update the clock's software without physically moving it.
Next step is to make a better suspension.
Meanwhile, how the clock is meant to work may be of interest.
Assuming a low error pendulum, the idea is to count the total number of ticks timed accurately over several days by NTP or GPS. Air pressure, temperature and relative humidity are also logged, so the clock's environment is available.
By statistical analysis this data gives the pendulum's average period and identifies any correlation between period and environmental changes. And as correlations are measurable, it's possible to derive correction formulae, that can be applied on the fly by the clock's microcontroller to the average period.
Thus, when the clock is free-standing, and counting beats, its gear train function takes the average period and adjusts the number to what it should be given the current measured temperature, pressure and humidity levels. This replaces physical temperature compensation methods, and the rather complex mechanism needed to correct a pendulum for barometric change. In addition, the clock is intended to run in a vacuum, hopefully making the software tweaks tiny.
All this depends on me making a decent pendulum! So far no coconut…
Dave