Measuring Clocks

[SillyOldDufferModerator @sillyoldduffer]

Back to measuring, some thoughts on errors.  In no particular order:

• Although the pendulum design is very simple:
  • Build quality is highly suspect. The suspension spring, rod, and bob should all be straight, and they aren’t.  Nor are the rod and bob perfectly concentric because I skewed the die slightly when threading the rod.  These defects reduce accuracy because the pendulum will twist in flight.   More care, and maybe a jig is needed.   Or get a good machinist to make a better version!  I’m clumsy and only my mother thinks I’m semi-skilled…
  • Design not rigid enough.   The clock is free-standing and will sway as the bob swings, causing energy loss and varying the period.
• The opto-sensor has to be shielded from ambient light.   I can stop the clock by shining a bright halogen lamp at the sensor.  More subtly, extraneous light alters the sensitivity of the sensor, causing it to trigger at slightly different times.   Best keep the sensor in the dark.  Shields.
• Pendulum is sensitive to draughts too, so shield them too.   Enclosing causes other problems.  More turbulence as the bob stirs air in an enclosed space, plus thermal currents circulating when the room warms.  More reasons for a vacuum!
• Location is important: the previous version of this clock detected vibration due to people moving in the house and traffic outside. Obvious when testing on a dining table that period is erratic compared with clock on a concrete floor.  Ideally, temperature shouldn’t vary. The ideal location appears to be a deep cellar inside solid rock, miles away from people.   As a pendulum clock gets more ccurate, it detects micro-gravitational changes, as when the water level changes in an aquifer.  And the earth bends due to the tide coming in near the coast.  Earthquakes too.  My home is built on made ground, with wet limestone under, and a nearby road.  Assuming I can fix all the technical problems, getting the best out this clock requires me to move home…
• GPS accuracy must be high compared with the pendulum in order to determine corrections, but GPS time varies depending on the number of satellites in view.  My antenna looks out of a south facing rear window, and is deaf to northern satellites.   Mitigated because the module detects GLONASS (Russian) and Galileo (European) satellites as well as US GPS, but an external antenna needed!   Also, the affordable module I’m using is designed for navigation, not time accuracy. Time optimised GPS receiver are   a bit pricey.  Maybe fussing because bog-standard GPS is easily 10x better than a Shortt-Synchronome.
• Add exterior test points for an oscilloscope or PICPet.  Helps pin down problems.
• Software improvements.
  • For ordinary purposes, Arduino provide beginner friendly functions. They apply error checks, which slows them down.  Worth changing to unchecked read/write IO for speed.
  • Other efficiency savings.  All functions have to finish between beats, about 0.9s.   Best to get keep them as fast as possible.  Not critical, the log function is probably the most expensive, and it only takes about 30mS.
  • At present, the code measures period using the micros() function, cos it’s easy!   Unfortunately, precision is only ± 4uS and accuracy depends on a plain 16MHz crystal.  The crystal isn’t temperature compensated or calibrated. Need to add Precision Event Timing capability, which is nearly 40x better than micros().  The code is written and tested, have to install it.
  • Fix starter, it’s too powerful!
  • Add 3-colour status LED
  • Add a plug-in LCD Display.
  • Add a rolling average function to period.
  • Add drift, temperature, and pressure compensation
  • For fun, add complications.  Day name, calendar date, alarms, time zones, summer time, sun rise, solar time, and moon phases etc.  All easy with a microcontroller.
  • Change the impulse timer to improve resolution.  To get 80mS pulses I pre-scaled the timer clock to divide by 64 to get a max pulse length of 0.26s, resolution 4uS.  Now the clock runs with 1.8mS pulses, the / 64 scale is cramped – 450 of 62358.  Dividing by 8 provides the necessary pulse length (max 32.768mS), and increases resolution to 0.5uS.  Finer resolution may be overkill but it’s easy to do, and may get better optimised pulse length.
  • Fix bugs.  I’m baffled by the erratic beat flash LED.  Annoying even though it doesn’t affect the clock.
  • Tidy up – the code is messy and needs more comments.

Capturing pendulum’s rolling average period is another way of improving accuracy.  A mechanical escapement can only tick in fixed increments.  This clock has memory, and could smooth out anomalies, potentially reducing errors due to my indifferent build.  The clock’s counter (equivalent to a mechanical gear-train) can be ticked by average period,  thus reducing random error.  Actually this is cheating, because the average is derived from the GPS disciplined crystal, not the pendulum.  But I think analysing rolling average might reveal a behaviour that can compensated with a coefficient, and that isn’t cheating!

Another experiment to do: this topic started by comparing a TCXO ticked Arduino to Network Time Protocol.  The TXCO is better in the short-term than NTP, but NTP beats Be interesting to compare an Arduino ticked by GPS seconds with NTP.  The Arduino will be have near GPS accuracy allowing me to assess how accurate NTP is.

I looked at the TXCO drift graph to see if the error is caused by 20MHz not dividing down exactly to 1 second.   I set a 16 bit timer to divide the TCXO frequency by 1024, and then triggered the timer at count = 19530.  This gives 0.9999872s, an error of 12.82uS per second, so the clock should drift by 1.107648 seconds per day.  Drift should be much worse than the graph shows.    By chance the TXCO is off-spec in just the right way to correct the error.  It’s period averages 0.999999274s, not the expected 0.9999872s, suggesting the TXCO is running at 20.00001452MHz.   I couldn’t find a specification for the device, an ACT1015, but AI did.  The frequency is nominal, so the user should trim it to 20MHz, and I didn’t.  The high performance is accidental.    The reason it’s drifting is still a mystery.  Robert’s suggestion is likely, if only I could prove it!  Another possibility is it’s a 3V3 device, and I’m feeding it 5volts.  Ignorance is bliss!

I’m also uncertain how to trim a TXCO or OCXO exactly to frequency.   I set my OCXO to 10Mhz by modifying my ArdPET to count OCXO pulses over a 100 seconds, and then tweaked it as close to 1,000,000,000 as I could.  The OCXO is trimmed with a multi-turn pot provided by a kind forum friend.  Takes for ever, lots of waiting to see what effect the last tweak had.  Fiddly!

Dave

 

 

 

[John HaineParticipant @johnhaine32865]

Regarding your last paragraph Dave, have a look at this GPSDO thread.

If you have a a picPET or equivalent, use it to measure the time between GPS pps pulses timed off your OCXO, subtract 1 and use the difference to steer the OCXO.

[Martin KyteParticipant @martinkyte99762]

Regarding your clocks ‘memory’ you cant use the electronics to adjust. I do get it get you want to post adjust the clock after measuring variations due to temperature and barometric pressure but you have to use the pendulum as your time keeper ?

[Martin Kyte]

On Martin Kyte Said:

Regarding your clocks ‘memory’ you cant use the electronics to adjust. I do get it get you want to post adjust the clock after measuring variations due to temperature and barometric pressure but you have to use the pendulum as your time keeper ?

Yes, that’s why I mentioned cheating.  I think it was who you spotted that evil during the SMEE meeting over a year ago and I took note.   Using it to refine the compensations is OK though, I hope.  Really useful to have feedback that keeps me honest!

Not going well, poor progress.

• The 3D-printer filament snagged in the reel and jambed, so the extruder gummed up.   Has to be stripped down to clear it.
• microcard to USB-A adaptor failed, needed for 3D printing the LCD display box.  And the spare is missing!  Both Xmas cracker quality so I’ve ordered an expensive new one.
• The flashing LED problem isn’t software, it’s faulty wire-wrap! When installing the revised magnet holder pulled on the wires, it left red and yellow touching intermittently.  Red is 5V to the opto sensor, yellow is it’s output, chaos!  Really annoying, I’ll have to rewire the lot.   Perhaps a good thing – was forced to use some too short pins, and have longer ones on order.  And a few other mods need the clock to be dismantled.

 

🙁

Dave

[SillyOldDufferModerator @sillyoldduffer]

As the 3D-printer is going to take at least an hour to fix, I’ve concentrated on the clock.

Problems:

• Clock ran reliably overnight but period was erratic and it stopped this morning.  Traced to a plastic thread attached to the bob, that was dragging and snagging on the structure.  Not much bigger than spider web.  A left-over from me using hot-glue in a confined space.   Hot glue is great except it tends to leave tendrils.   A magnifying glass found loads of them, now cleaned up.
• Starter still too strong or too weak, depending on what the bob is doing.  If stopped, the starter is a little too aggressive.  If already swinging,  and impulsed when the  bob is near the electromagnet, the action is far too aggressive.   If impulsed when the bob has swung far from the electromagnet, the action isn’t powerful enough.   I’ll try to stop the bob swinging before running the starter by sending a random sequence of off-resonant pulses in hope they will baffle the bob.
• The mild-steel bob retains enough residual magnetism to stick to the electromagnet!  Only happens if the bob bumps into it gently.  If it sticks, the clock can’t be restarted!  After a while the bob releases, presumably because the residual magnetism decays.  Might try gluing a paper disc to the pole piece to weaken the grip.

Observations confirmed.

Dim daylight affects the sensor’s detect position, overcast today.  Putting a sheet of paper between clock and window reduces per beat period variation (differences) by a factor of about 4×.  Presumably extraneous light shining on the detector alters the sensors trigger point.   Won’t be a problem when the pendulum is enclosed in it’s tube.   Though the effect probably averages out, it means pendulum clocks with exposed IR sensors won’t be regular in the short term.    Anyone know how electronic and mechanical escapements compare in terms of time accuracy?  Neither are instantaneous.  Gut feel is electronics are faster and more precise, because no mass moves and there is zero friction.  There is latency.    Gravity escapements are brilliant but there must be friction at the pallets, and difficult to ensure the action is perfectly symmetric.  Nonetheless, the Shortt-Synchonome is excellent.   I suspect though, that it’s short-term stability may vary.  I don’t think that aspect has been closely studied.   May not matter: errors that average out can be tolerated!

The pendulum is very sensitive to vibration.  Detects me gently pressing this computers ctrl key when I’m not otherwise touching the table.  May be a fundamental flaw in my design: pendula have to be rigidly mounted, ideally bolted to a solid wall.  Not free-standing in a frame.

Improvements.

Program now measures how long it takes the rod to pass the sensor.  I believe the transit time, narrow yellow notch below, is proportional to amplitude.

When the bob is losing energy, swinging at a smaller angle, it takes longer to pass the sensor.  When swinging at a large angle, it travels faster past the sensor.   Next step is to use transit time to maintain the pendulum at near constant amplitude.  When transits take longer, the impulse will be increased:  when transits speed up, impulse power is reduced.   In this clock, the pendulum’s amplitude will be governed, hopefully improving time-keeping.  Please let me know if this is wrong!

Dave

 

 

[duncan webster 1Participant @duncanwebster1]

Using transit time is cheating as it relies on the processor clock. That’s why I measure amplitude direct.

[John HaineParticipant @johnhaine32865]

Transit time is inversely proportional to amplitude.

I’ve come to the view that opto-interrupter type photogates using devices such as the Sharp “GPA…” (which I have recommended in the past) are actually not that good because of the ambient light problem and the rather large gap. A better approach in my view is to have a deep narrow horizontal slot in a block with emitter and detector below and above – the narrow slot helps to keep ambient light out, and having the detector look down minimises direct ambient light falling on it.  Then use a horizontal blackened vane attached to the pendulum with a narrow slot in it to let light through at BDC.  Again the vane helps to keep ambient light out.  The IR LED and IR photodiode mounted in holes in the block with small apertures.  The slot in the vane then can also be sensed by another emitter/detector pair offset from the first to sense when the amplitude gets too high and inhibiting the impulse.  Or better perhaps, reducing the impulse amplitude until the amp sensor is triggered on alternate swings.

Gravity escapements don’t have to have pallet friction – Arnfield’s gravity detached escapement shows how it can be done.  Though I’m “locked in” to magnetic impulsing for current clocks, I think you have to use amplitude control based on actually sensing the pendulum amplitude for precision (rather than the photogate time). There’s too much variation in drive current and magnet strength with temperature otherwise. I’m toying with the idea of a gravity escapement on Arnfield lines but using opto sensing  and a stepper to reset the arm.

[duncan webster 1Participant @duncanwebster1]

Apart from having the vane blackened, that’s pretty much what I’ve got. The vane is a bit of ally soft drink can, slot width is 3mm I think, but it’s a long time ago. I make no pretence to precision, but it only gets put right when the clocks change. If I make another I’ll make sure both LEDs are pointing up, I think less likely to be affected by outside light. I used thin ally as less likely to damage the sensors if the suspension gives way, but it’s ben running for 20 years or so. First attempt was plasticard, but it didn’t seem to interrupt the beam.

[duncan webster 1]

On duncan webster 1 Said:

Using transit time is cheating as it relies on the processor clock. That’s why I measure amplitude direct.

Is it cheating?

I argue that the processor’s clock is only used to detect relative amplitude changes, and using the information only alters the force applied by the impulse, not the periof. Impulse force doesn’t affect the pendulum’s period, other than stabilising it by governing amplitude. There is no synchronisation.

When running normally, clock-time only comes from the pendulum.  It doesn’t use the period it measures electronically.  Wouldn’t be a good cheat either because the bog standard crystal in an Arduino is a poor time-keeper, well below the accuracy I hope to get from the pendulum.

How the clock works is confusing because it runs in two different modes:

• When finding compensation values, it sets and measures itself using GPS.  In this mode, GPS is the reference clock, no different in principle than you setting your pendulum clock from a wrist-watch, and then using the watch to check the pendulum is keeping good time.
• Once calibrated, the compensations are set and the GPS is disconnected.  Thereafter, clock time is only incremented when the opto-sensor is ticked by the pendulum.   Apart from being electronic the gear-train is conventional.  It converts the counts into hh:mm:ss.sssss.

Have to be careful not to mix the two modes up though.  Techniques allowed in calibration mode aren’t allowed when the clock is running, and I’ve done it a few times!   Very helpful to have reviewers watching for infringements.

I think detecting changing amplitude is OK though?  Or do I need a good lawyer…

🙂

Dave

 

 

[John Haine]

On John Haine Said:

Transit time is inversely proportional to amplitude.

That’s really helpful.  I’m struggling to code the governor logic clearly and have thoroughly confused myself with which way up the comparisons go, making the logic hard to understand.  Had it working, and broke it by clarifying the code.  I think using the inverse should be more readable.

The governor code isn’t in the clock yet.  Instead a Python program on my PC reads the log and decides if amplitude is increasing or decreasing.  Should be simple:  reduce impulse if amplitude increases above a high limit, and increase if amplitude falls below the low limit.  The Python program sends ‘change impulse’ commands to the clock, which works.  When the logic is right in Python, I’ll implement in C so the clock can govern itself.

I’ve come to the view that opto-interrupter type photogates using devices such as the Sharp “GPA…” (which I have recommended in the past) are actually not that good because of the ambient light problem and the rather large gap. A better approach in my view is to have a deep narrow horizontal slot in a block with emitter and detector below and above – the narrow slot helps to keep ambient light out, and having the detector look down minimises direct ambient light falling on it.

Cruel world, this upgrade uses a Sharp GPA… on your recommendation! Performs better than my first implementation, a modified Arduino distance detector plus narrow slots!  But I’m sure you’re right, a deep narrow slot would be better again.  For the time being I’ll stick with the Sharp.  Might be accepytable – ambient light isn’t be a problem in my clock because the pendulum swings inside a light-proof pipe.

 

 

Then use a horizontal blackened vane attached to the pendulum with a narrow slot in it to let light through at BDC.  Again the vane helps to keep ambient light out.  The IR LED and IR photodiode mounted in holes in the block with small apertures.  The slot in the vane then can also be sensed by another emitter/detector pair offset from the first to sense when the amplitude gets too high and inhibiting the impulse.  Or better perhaps, reducing the impulse amplitude until the amp sensor is triggered on alternate swings.

Similar to my thinking, which is a relief.  I have a blackened vane, and the clock is ‘levelled’ to trigger at BDC, or at least as close as I can get with an oscilloscope.  The clock is first levelled with a bubble, but then tilted slightly on the adjusters so the rod plumbs BDC.

Gravity escapements don’t have to have pallet friction – Arnfield’s gravity detached escapement shows how it can be done.  Though I’m “locked in” to magnetic impulsing for current clocks, I think you have to use amplitude control based on actually sensing the pendulum amplitude for precision (rather than the photogate time). There’s too much variation in drive current and magnet strength with temperature otherwise.

 

Noted thanks.  I’ll carry on with the photo-gate approach to see how stable I can get, but this may be next.

Must read ‘My Own Right Time’ again.

Many thanks,
Dave

 

[duncan webster 1Participant @duncanwebster1]

But controlling amplitude controls period at least to some extent. That’s how Mumford tamed a Eureka clock, so using the processor’s clock to control amplitude contravenes my self imposed rules. Others might have different rules.

https://www.bmumford.com/clocks/eureka/

[duncan webster 1]

On duncan webster 1 Said:

But controlling amplitude controls period at least to some extent. That’s how Mumford tamed a Eureka clock, so using the processor’s clock to control amplitude contravenes my self imposed rules. Others might have different rules.

https://www.bmumford.com/clocks/eureka/

Mmmm, what do others think?  I’ll carry on for the moment. Done in software so easily switched off if the jury find me guilty.

The goal is minimising the difference between beats, requiring two steps:

• Finding the optimum amplitude (not done yet – I guessed)
• Writing a governor that maintains amplitude near optimum by tweaking impulse power. The governor works.  Here’s the flowchart:

The governor samples 20 amplitudes and then compares the rolling average is within the target range (60000 ±1000uS).  If the rolling average is below the lower limit (amplitude falling), the clock is ordered to increase impulse by 0.08mS.   If above the upper limit (amplitude rising), the clock is ordered to decrease amplitude, also in 0.08mS steps.

The log shows a 2.2mS impulse keeps amplitude within range for  240 beats, but it’s not strong enough.  So the governor increases impulse over 120 beats up to 2.68mS.  It finds that to be too strong after 280 beats, and then reduces impulse in 6 steps over 120 beats down to  2.36mS.  Changes highlighted in green and red.   Considerable hysteresis.

At present all the parameters are arbitrary.  Target range, impulse increment, and sample size, all guesses.  I don’t know how to set them logically.    Inappropriate settings cause the governor to hunt or fail to get a lock, or to respond too violently, or too slowly. Needs more thought.

As implemented, gut feel is it’s too slow.

It’s behaviour is analogous to a mechanical governor, where the balls are replaced by the bob mass, gravity by a magnetic field, the drive shaft by a rolling average,  the operating point adjuster by a target range, and the throttle valve by impulses.

Does anyone understand how to design governors?  I’ve exceeded my understanding and have no experience.  More swotting, and I’d rather watch telly.   Doesn’t help that James Watt was much smarter than me!!!

Dave

 

 

[Michael GilliganParticipant @michaelgilligan61133]

As one from the loose cohort of “others”

I think you are coming close to modernising the basic concept of Hipp’s toggle !

It has long been my opinion [despite some derision on this forum, from SK] that simply governing the swing of a pendulum, to tight-enough limits, would result in excellent time-keeping.

MichaelG.

[John HaineParticipant @johnhaine32865]

Certainly governing the swing contributes.  Bateman’s clock, which used a simple amplitude comparator to detect if the swing was too large and inhibited the next impulse, kept the amplitude constant to a second of arc or less IIRC.  To all intents and purposes there was no “circular error”.  However it is still subject to temperature effects (so has an invar rod and additional compensation) and buoyancy so has an aneroid compensator.

[duncan webster 1Participant @duncanwebster1]

Hipp detects low amplitude and gives the pendulum a big push every now and again. I impulse every swing unless high amplitude detected, when an impulse is missed out. About 1 in 10 in my case

[Robert Atkinson 2Participant @robertatkinson2]

Dave SOD,

On references I just remembered that a have some Rubidium oscillators with an unusual 800kHz output frequency. One of these might better fit to measurement scheme. They were originally used as references for Have Quick frequency hopping UHF radios.

Robert.

[duncan webster 1]

On duncan webster 1 Said:

Hipp detects low amplitude and gives the pendulum a big push every now and again. […]

…  and [merely a thought-experiment at this stage] ; what would happen if we could get that detection down to a level of [say] 10 microns ?

All other variables become subsumed !

Just need to work out the method of giving very small pushes

Mmm … that’s where my tiny brain has been stuck for the last few years

MichaelG

[blowlampParticipant @blowlamp]

I don’t think you will achieve your aim of beating or even getting close to the precision of a Shortt clock if you insist on regulating the pendulum.

 

Martin.

[John HaineParticipant @johnhaine32865]

What do you mean by “regulating”?

[blowlampParticipant @blowlamp]

Regulating the pendulum by varying the impulse it receives.

 

Martin.

[blowlamp]

On blowlamp Said:

I don’t think you will achieve your aim of beating or even getting close to the precision of a Shortt clock if you insist on regulating the pendulum.

 

Martin.

Can you explain why not please?  I’m not the first to design a clock mechanism that reduces circular error, which is what this does. Reducing circular error is desirable because pendulums aren’t isochronous; circular error varies with amplitude.

Maybe a misunderstanding?  I’m not regulating the pendulum’s period, I’m keeping it’s amplitude steady by adjusting impulse power.  The governor does not synchronise the pendulum with anything else, I hope!

Ta,

Dave

 

 

 

 

[blowlampParticipant @blowlamp]

Doesn’t adjusting the impulse power change the circular error?

 

Martin.

[duncan webster 1]

On duncan webster 1 Said:

Hipp detects low amplitude and gives the pendulum a big push every now and again. I impulse every swing unless high amplitude detected, when an impulse is missed out. About 1 in 10 in my case

I experimented with impulse-every-swing versus occasional impulsing on the Mk 1 version of my clock and found a carefully minimised impulse-every gave the steadiest result.

I suspect which approach works best depends on the pendulum.  My bob is distinctly lightweight, hence more disturbed by occassional big impulses than a big heavy bob would be.

I started pendulum experiments with a whippy rod, essentially a bob suspended on a very long suspension spring.  Behaved oddly, explained by the impulse causing the whole pendulum assembly to vibrate.  A heavy bob on a stiff rod suspended on a short spring at the top, is  less likely to go twang.   My pendulum worked best with delicate constant impulses, yours works best with huff-and-puff.   If I get the Mk2 clock running in a vacuum, I’m going to try the different methods again.

Or you could test the two methods on your clock – the Arduino can be programmed to impulse it with either method.

Dave

[blowlamp]

On blowlamp Said:

Doesn’t adjusting the impulse power change the circular error?

 

Martin.

Yes, reduces it.  Is there an objection to that?

Dave

[blowlampParticipant @blowlamp]

Within reason, circular error won’t matter as long as it is constant. As soon as the circular error changes then so does the period of the pendulum and is important if you want to surpass the performance of a Shortt clock.

Martin.

[Author]

Posts