Measuring Clocks

[SillyOldDufferModerator @sillyoldduffer]

As this graph shows, my pendulum is also noisy but for different reasons to the Livermore.

The chart graphs the clock making a cold start.  The electromagnet pulls the bob on to the pole piece, and then releases it, causing a violent swing.  The microcontroller waits for amplitude to subside to a reasonable level before impulsing.   Takes about 80 minutes for the period and amplitude to settle.  Circular Error during startup is very evident: period changes as amplitude falls because pendula are not truly isochronous.  (Therefore a good clock should keep the bob swinging at constant amplitude.)

The graph is misleading in that temperature doesn’t obviously affect period, a naughty fib.  It’s there if you look closely enough. Partially hidden because the microcontroller’s uncompensated crystal oscillator moves the other way from the clock’s uncompensated pendulum, so they cancel.  Two bads don’t make a good.

The clock’s temperature sensor detects the electric fire I had on instead of the central heating.  The zigzag is the fire’s thermostat kicking in and out.

The pendulum is noisy, standard deviation 8.5μS.  Slightly misleading because the microcontroller’s bog standard clock has a resolution no better than 4μS.  The Precision Event Timer code isn’t installed yet: it’s resolution is 64× higher.  Likely cause is mechanical defects in the pendulum and suspension, fixing which is work in progress.  The pendulum will be more sensitive to vibration after it’s been improved, and I’ll be very happy if it’s ever sufficiently sensitive to detect tides.   Like as not never will because my home vibrates so much that tides are buried by the racket.

Dave

 

,

[Michael GilliganParticipant @michaelgilligan61133]

Whatever the practical/environmental obstacles, Dave … that’s a great demonstration of your concept.

MichaelG.

[Ian PParticipant @ianp]

I know I’m out of my depth commenting on the physics of clocks, but if as you say the pendulum should swing at a constant amplitude then presumably a small impulse every swing would be better than a larger pulse every few swings?

If the electromagnet is at the bob end of the pendulum (and is of low force) I wonder whether it could be used to start the bob from stationary by impulsing it in a controlled manner so that it gradually builds up the swing.

When adding energy to the bob it seems to me that ‘little and often’ using an electromagnet of minimum strength for the shortest ‘on’ period would impart the least disturbance. An electromagnet that is ‘only just strong enough’ would also make the magnet on time period less critical compared to a magnet of high power.

If the red line on your graph is a temperature sensor mounted on the structure inside the PVC tube then is it just reading ambient albeit highly slugged, once you a running a near vacuum clock the room temperature should not get through to the pendulum and its support, still seems worthwhile though to have all the electronics in a temp controlled enclosure.

The above is just my Saturday afternoon ramblings based on snippets from the (four I think) threads on your clock/s. One small request for next time you show a graph, it would be good if you could increase the font size please. Ian P

[John HaineParticipant @johnhaine32865]

Two data points. The Shortt clock impulses both pendulums once every 30 seconds. Fedchenko once every second. Both capable of detecting tides, though the second was better.

[Ian P]

On Ian P Said:

Welcome to the dark side Ian!  Good questions, and I think you should build one too.

I know I’m out of my depth commenting on the physics of clocks, but if as you say the pendulum should swing at a constant amplitude then presumably a small impulse every swing would be better than a larger pulse every few swings?

The answer is unknown.  Some clocks get good results by impulsing lightly on every beat, others by impulsing strongly once every ‘n’ beats and then letting the pendulum swing freely.   I think which is best depends how much the impulse disturbs the pendulum, which depends on the design.   My Mk1 clock worked best with a light impulse on every beat.

The Mk2, being what Tom van Baak calls a Digital Pendulum, isn’t constrained by a mechanical escapement, so it can be commanded at any time to impulse:

1. On Every Beat.
2. When Amplitude Falls Below A Target Value.
3. After Every Nth Beat
4. On Every Beat, With Impulse Power Regulated To Maintain A Target Amplitude
5. On Every Beat Unless Amplitude Is Exceeded

These options are available so I can try them all to find out which works best with my pendulum.  I can command the clock to methodically step through the range of amplitudes to find which works best . Early days, but an amplitude of 70mS behaves well (about 4°)  John Haine has made some interesting suggestions resulting from his study of Burgess Clock B that I hope to follow up.

If the electromagnet is at the bob end of the pendulum (and is of low force) I wonder whether it could be used to start the bob from stationary by impulsing it in a controlled manner so that it gradually builds up the swing.

Yes, that works, and is the first method I tried.  It’s slightly unreliable because the pendulum might already be swinging, in which case out-of-phase starting impulses brake the bob. I found it more reliable to measure amplitude when starting; if zero, or the pendulum is swinging very slowly, grabbing the bob and dropping it gets the pendulum going for sure.  The cost is having to wait for it to recover from the shock.  A resonant starter is more gentle, and can be made to work with a bob that’s too heavy for a small electromagnet to grab.  I might go back to it.

When adding energy to the bob it seems to me that ‘little and often’ using an electromagnet of minimum strength for the shortest ‘on’ period would impart the least disturbance.

That’s my experience.

 

An electromagnet that is ‘only just strong enough’ would also make the magnet on time period less critical compared to a magnet of high power.

Exactly so.  I go to considerable trouble to control how much power is applied to the electromagnet.  A precision timer delivers pulses of up to 262ms with 4μS resolution and if that’s not good enough I can impulse with 500nS resolution.

If the red line on your graph is a temperature sensor mounted on the structure inside the PVC tube then is it just reading ambient albeit highly slugged, once you a running a near vacuum clock the room temperature should not get through to the pendulum and its support, still seems worthwhile though to have all the electronics in a temp controlled enclosure.

Yes, it’s part of the design.  An advantage of swinging the bob from a tower in a vacuum means heat can only reach the rod via the heavy cast-iron base.  It should insulate the pendulum from rapid changes of temperature, good thermal properties, poor rigidity.  If I hang the pendulum from an Aluminium tube, I get good rigidity and a thermal problem.  May not matter because the way temperature compensation is applied to whole structure, not just the rod.

The electronics inside the vacuum are trivial. A BME280 pressure/temp/humidity sensor, a switching transistor, two resistors and a diode.  Old computer nerdism:  “the big iron is in the basement”

The above is just my Saturday afternoon ramblings based on snippets from the (four I think) threads on your clock/s. One small request for next time you show a graph, it would be good if you could increase the font size please.

Sorry about that, I’ll try.  Partly because the forum shrinks images to make them web-friendly. What appears after I hit send is smaller and more blurred than the original.

 

[SillyOldDufferModerator @sillyoldduffer]

In parallel with battling to improve the mechanical clock, I’m also fighting the software.  Three tricky problems:

1. Making sure the bob is never impulsed on the backswing by ensuring the electronics stay in phase with the pendulum. Fixed, fingers crossed.
2. Fixing the code that finds the impulse power needed to achieve a given amplitude.  Problem was the algorithm sometimes overshot and hunted unsuccessfully forever.  Reason, inertia: the bob takes time to respond to impulse changes.  Fixed with an algorithm that homes in more slowly as the bob approaches the target amplitude.
3. Setting the clock accurately to UTC given that pendulum ticks cannot be synchronised with UTC ticks.  The pendulum is always part way through a swing when the clock is set.

Setting to UTC is done numerically by noting the time in microseconds when the set UTC command is received, and applying a correction relative to UTC on the next pendulum tick.   It nearly works:

This is another form of measurement.   A Python program reads the clock’s output and, after allowing the bob to settle, orders the clock to set UTC.  The clock is sent a UNIX timestamp, which uses it to set the clock’s counter seconds part, and zeros the microsecond count after noting the last value.  Then, on the next tick, the microcontroller applies the maths needed to align the clock to UTC.

In the example above, the clock started by being wrong by 17billion seconds compared with UTC, which reduced to 0.245s after the clock was set.  0.245s is still a massive error, but the error is constant.  The maths is wrong rather than the logic, and it’s the logic I was struggling with.

The clock can be set by sending it UTC from the PC, or by telling the microcontroller to get UTC from a GPS Module.  GPS is much more accurate than the PC.

Dave

 

[Joseph Noci 1Participant @josephnoci1]

Can you show a chart of Flag vs the temp curve in you chart above?

[Joseph Noci 1Participant @josephnoci1]

Can you show a chart of Flag vs the temp curve in your chart above?

[Joseph Noci 1]

On Joseph Noci 1 Said:

Can you show a chart of Flag vs the temp curve in your chart above?

Hi Joe.  What’s Flag?

Dave

[Joseph Noci 1Participant @josephnoci1]

The interrupter that passes between the pillars of the photogate – with a measurement in us of the interrupt time ( ‘velocity’)

 

[SillyOldDufferModerator @sillyoldduffer]

Of course it is!  I call it the vane.

Can’t graph a longer run at the moment because I’m testing a different log format that doesn’t include amplitude.  I’ll do another graph tomorrow.

Dave.

[Joseph Noci 1Participant @josephnoci1]

Dave, I would hazard to say that graph shows some issues..

You have around a 250us variation for a 0.15degC Temp delta – that is rather large, like in huge…

My pendulum currently gives around 20us change 1degC delta – and the objective is to get amplitude a stable as possible.

Your top graph shows a 1.4degC variation – The flag measurements would change by more than 2ms… Thats massive!

Are you sure this chart is correct?

I also find it odd that Velocity increases with falling temp – I have to think about that one.

 

[Joseph Noci 1]

On Joseph Noci 1 Said:

Dave, I would hazard to say that graph shows some issues..

You have around a 250us variation for a 0.15degC Temp delta – that is rather large, like in huge…

My pendulum currently gives around 20us change 1degC delta – and the objective is to get amplitude a stable as possible.

Your top graph shows a 1.4degC variation – The flag measurements would change by more than 2ms… Thats massive!

Are you sure this chart is correct?

Whoops, wrong log file.   Highly misleading – it’s from a very different test run.  This looks right.

At this stage I’m not too worried about graphs because the clock is incomplete and has several known bugs.  As I’m still developing and debugging the time-keeping functions aren’t effective yet.  And much of what I’m attempting is  experimental and speculative.

About 18 months ago I took the Mk1 version of this clock apart ready for a major upgrade just before becoming horribly ill.  Feeling better a month ago I opened the box of parts and notes and found it empty!  The real box is ‘somewhere safe’ and I can’t find it.

Now I’m relying on faulty memory rather than an informed plan and the project has become messy!  Order is slowly being restored from chaos!   Not all bad because I’ve taken the opportunity to ask questions and am getting plenty of  help.

Dave

 

 

[Joseph Noci 1Participant @josephnoci1]

Can you plot that again, but from starting at 10000 on X scale

[Joseph Noci 1Participant @josephnoci1]

Also, why the big delta in amplitude between the two graphs? ( 69000us vs ~83000us)? Different Flag size, or much lower amplitude?

[Joseph Noci 1Participant @josephnoci1]

It has been my ‘experience’ that my initial wish/aim of 1sec/100days came from a complete lack of knowing what I don’t know about pendulum’s – I now know that I know almost nothing…

Chasing good timing has literally been a waste of time – the aim should have been achieving really, really good amplitude control and above all, stability. Good timing is then another mission, but can be approached with less extraneous contamination. Structural clicks and twinges, wobbles, temperature hysteresis, tilt and its influence on your chosen method of amplitude measurement , etc – many many issues that you need to master before bothering what the time is..

[Joseph Noci 1]

On Joseph Noci 1 Said:

Also, why the big delta in amplitude between the two graphs? ( 69000us vs ~83000us)? Different Flag size, or much lower amplitude?

The microcontroller has 5 different strategies that the operator can apply to manage amplitude, or not. Don’t take the graphs too seriously because the build is incomplete, I’m still wrinkling out mechanical and software issues, and the test runs aren’t consistent.   The trials meet development needs, and aren’t representative.

The two test runs used different strategies.  In the first test the clock ran with a fixed impulse, set experimentally for reliable running.  In the second, the clock was set to run at a lower amplitude to reduce circular error, but is more prone to stop.  Stoppages are due to known mechanical and adjustment faults, for which reason the pendulum is being rebuilt.

Too early to say but it appears the best strategy is to maintain amplitude within a range.  Below about 4° the range can be quite big without before circular error intrudes.  But the Precision Event Timers aren’t installed yet and the clock is otherwise unready for a controlled experiment.  Debugging and development have priority.

Dave

[Joseph Noci 1]

On Joseph Noci 1 Said:

It has been my ‘experience’ that my initial wish/aim of 1sec/100days came from a complete lack of knowing what I don’t know about pendulum’s – I now know that I know almost nothing…

Me too!

Chasing good timing has literally been a waste of time – the aim should have been achieving really, really good amplitude control and above all, stability. Good timing is then another mission, but can be approached with less extraneous contamination. Structural clicks and twinges, wobbles, temperature hysteresis, tilt and its influence on your chosen method of amplitude measurement , etc – many many issues that you need to master before bothering what the time is..

Agreed.  It’s why my clock isn’t time-keeping yet.

I believe I can achieve good amplitude control though.  Results with the simpler Mk1 clock, were encouraging and it had a PET and GPS.

So far tilt hasn’t emerged as a problem here.   Your clock being on the sea-shore may be the issue.  Not because it reacts directly to lunar and solar gravity, but because millions of tons of sea-water move in and out on your doorstep, and the whole foreshore could be tilting under the weight.  I’m about 30km inland.  My problem is vehicles on nearby roads.

If it was easy it wouldn’t be worth doing!   If it’s any consolation others have failed too.   Vannevar Bush didn’t make it in the 1940s and he was a top-engineer and millionaire.   Professor Hall got close, but no coconut.

I’m doing attempting this as an interesting hobby challenge.  If I really wanted accurate time the rather ordinary navigational GPS module I’m using is orders of magnitude more accurate than the very best pendulum clock and costs about £20.  Since I bought mine, it’s been replaced by a better unit that’s a couple of pounds cheaper…

Dave

 

[Joseph Noci 1Participant @josephnoci1]

The mainstay I found is to focus of specifics and get those sorted as best can, and move to the next – to many variables result in nothing gained.

I leave it to you..

[Ian PParticipant @ianp]

In another thread Dave (sod) said this,

‘Keen readers of my clock thread may remember John and I worrying about LEDs losing power over time.  Shouldn’t affect an intermittently used remote, but if the designer over-amped the LED to increase range, and then the controller got stuck twixt cushion and armrest with all the buttons pressed, then the LED may have got warm.’

It reminded me that I meant to ask about what the service life of the clock is?

In other words, how long is the clock intended to operate before it needs some intervention, like new LED, suspension spring replacement, re-vacuuming or some other maintenance tasks that stop the clock. I’ve no idea how long the Shortt operates continuously for, but maybe the slave pendulum covers short breaks. (pun intended)

Ian P (fascinated by the whole project)

[John HaineParticipant @johnhaine32865]

I’m working on a clock at the moment where the LEDs had been operating for nigh on 50 years and were hardly generating any light at all. If a clock is to have any longevity and bearing in mind the need for future maintenance, a good idea to design for component degradation. LED lifetime is of the order of 20000 to 100000 hours but emissivity degrades during that period so better design around that. AFAIK Shortts ran indefinitely.

[Ian P]

On Ian P Said:

… how long is the clock intended to operate before it needs some intervention, like new LED, suspension spring replacement, re-vacuuming or some other maintenance tasks that stop the clock. I’ve no idea how long the Shortt operates continuously for, but maybe the slave pendulum covers short breaks. (pun intended)Ian P (fascinated by the whole project)

More good questions!

As this is an experimental clock, I’ve only paid lip service to reliability, often no more than noting “this needs attention”  rather than fixing it.  Having said that:

• the design deliberately replaces as many mechanical functions as possible with electronics and software, mostly software.  There’s no escapement, bearings, temperature or barometric compensators, gear-train, remontoire, mainspring, or weight motor.  Only a lightly loaded suspension spring that should last for centuries.  And the pendulum is enclosed – no dirt or solar damage.   There’s no gear-train, so no arbours to gum up or wear out. All good because mechanical mechanisms are unreliable; and they have to be taken out of service for maintenance.
• Microcontrolling the clock eliminates human cack-handedness.   No need for me to approach the clock, let alone open it up.  (Just as well, I’m a clumsy oaf).   The clock is configured remotely with a PC.   If I had a cellar, the clock would be locked away in it to minimise vibration and accidents
• Apart from the microcontroller, the electronics are deliberately simple.  Very little to go wrong.  A transistor, two resistors, a photointerrupter and pressure/temperature/humidity sensor.   The transistor is operated well within ratings.  The pressure/temp sensor is a tough automotive component – designed to work in a hot vibrating engine compartment. I could fit two.
• The photointerrupter is more delicate, and the data-sheet says “In the case of long-term operation, please take the general IRED degradation (50% degradation over 5 years) into the design consideration.”  That’s a problem! I think it will cause a phase error that can be compensated for by the micro-controller, but at some point the interrupter will fail.  Options:
  • replace it with something more reliable
  • only turn the LED on when needed.  (About 100mS per second, so 50% degradation would take 50 years)  Time critical because the LED has to be on when the vane/flag sweeps past, and the clock has to tell the difference between “that’s a beat” and “that’s OFF to save power”.  Careful Programming needed.
• The microcontroller is good: 25 years @ 85°C, 100 years @ 25°C.  Arduino boards are expected to last 10 to 25+ years in real world applications.  They’re killed by environmental and electrical extremes.  In this application the board is very lightly loaded, so I expect better than 25 years.
• The display is an optional external plug-in module that can be hot-swapped.
• The electronics are vulnerable to power cuts and surges.   Max power consumption is 214mA @ 5V, so I could extemporise a UPS with a 6V battery.    But I have a commercial unit.
• The software has to be performant and reliable.  Depends on me getting it right.  The code is aggressively high-performance, so very little error checking in it.  I spent yesterday afternoon chasing a new bug that crashed the serial interface every so often.  I’d added a log option to report everything interesting in a single efficient packet, about 130 bytes for debugging.   As the serial transmit buffer on an Arduino is only 64bytes long, ramming 130 bytes into it was causing the dreaded “undefined behaviour”.  Stuff works for yonks and then fails for no obvious reason.  Nothing wrong with my code, except I’d inadvertently ignored the limitations of a little microcontroller.  Quite likely more bugs of that type are lurking.   The code has to be thoroughly reviewed and tested.
• I have no faith whatever in my ability to maintain a vacuum!  As discussed the PVC pipe idea is badly flawed, necessitating a Mk3 redesign with a metal chamber.  Many problems and no practical experience.  Time will tell.

Shortt-Synchronomes had relatively short service lives – about 25 years. Most were replaced in the mid-1950s, either becoming display items or back-ups. Edinburgh ran two until 1978, though they stopped being standard time-keepers in the 1960s.   Fedchenkos lasted into the 1980’s in the Soviet Union, mostly because they didn’t have western technology or the foreign currency needed to buy it.  Service lives about 35 years.

I’ve never seen any figures for pendulum clock maintenance downtime, but being mechanical they would not have run continually.

Thanks for asking the question. The Design document should have addressed Reliability and didn’t.  Now it will!

Dave

 

[John HaineParticipant @johnhaine32865]

More correct to say that Shortts were in service for about 25 years, Fedchenko for 35 – they were switched off rather than breaking.

[SillyOldDufferModerator @sillyoldduffer]

I’ve implemented the clock’s two built-in Precision Event Timers.  They and GPS are only used to establish the temperature and pressure compensation coefficients when the clock is in learning mode.  They, and the microcontroller’s quartz crystal are not used when the clock is time-keeping.

1. PET1 counts the number of pulses the Arduino’s crystal oscillator outputs per GPS second, which reveals it oscillates near 15998503Hz rather than nominal 16000000Hz,  Not a surprise, CPU oscillators don’t normally need to be accurate so the crystals are just bunged on the board, no finesse.
2. PET2 counts the number of CPU crystal pulses per pendulum beat, and this needs to be accurate.  So the crystal’s actual frequency is determined by GPS, which also covers frequency drift due to temperature change.

To test the PETs are working, I measured and graphed crystal frequency vs temperature and got an odd result!

With a bit of imagination the graph shows a loose correlation between temperature and frequency, but that frequency changes before temperature.  Appears the clock is controlling the weather, which can’t be right!   Noticed this delayed correlation before and put it down to coincidence.  Not so!

The Mk1 and Mk2 clocks are different.  Mk1 had the microcontroller and sensor exposed to open air, i.e at the same temperature.   The Mk2 clock encloses the sensor inside the vacuum chamber and locates the microcontroller  inside the cast-iron base.  They are at slightly different temperatures and out-of phase.  Both matter:

• The sensor lags behind changing room temperature because it’s insulated inside the PVC tube
• The microcontroller is warmed above room temperature because it’s in a cosy cavity inside the base.

So I need two sensors: one to measure the temperature of the pendulum so it can be compensated when time-keeping, and a second to measure the temperature of the crystal oscillator so it can be compensated whilst learning.  I guess the difference is a degree or two.

Second problem:  I’d “fixed” an earlier issue whereby the pendulum occasionally got out of phase with impulses apparently because the photo-interrupter was triggering incorrectly on the backswing.  Should have looked closer!  PET2 showed the same fault, due to a code omission.  To ensure clean signals the photo-interrupter needs a pull-up resistor.  Could be part of the electronics inside the vacuum chamber, but I intended to implement it inside the microcontroller by setting the microcontroller’s pendulum detect pin as INPUT_PULLUP.  Except I left the line out, leading to slightly erratic triggering, reducing the accuracy and reliability of the period and amplitude measurements.

Fingers crossed the photo interrupter works properly now, but it means the code I painfully wrote last week to fix the backswing problem is an unnecessary complication.  Removing it is more work!  Three steps forward and two back.

Arghh!

Dave

 

[John HaineParticipant @johnhaine32865]

Dave, I seem to remember using quite a low value of pullup on the opto, an internal Arduino pullup is ~20k IIRC, for fast rise time I used something much lower, possibly 1k or less.

[Author]

Posts