Precision pendulum techniques

[david bennett 8Participant @davidbennett8]

Dave, glad to see you have this well in hand. I was concerned the noise was making it hard to differentiate clock noise from test noise, but de-coupling sensor electronics resolves that.

dave8

[John HaineParticipant @johnhaine32865]

I have been chasing the source of what seemed like excessive noise in my pendulum measurements and here's a quick summary.

1. There is definitely a problem with the rod being slightly bent by the initial impulsing method (recall that there is a small bar magnet in the top of the rod that twists in a transverse magnetic field produce by a pair of coils). This seems to be a sort of "double bass string" mode. The 6mm rod is too flexible.
2. Even when not impulsed run-down measurements were rather noisy. Trying to cure this I first replaced the rod with a 10mm dia FC tube, then replaced the slotted vane used by the sensor with a plain 5mm pin – this inverts the logical sense of the sensor signal so a suitable adjustment was needed in the measuring system.
3. Eventually I think I have established that the irreducible uncertainty of the time measurement is a few microseconds – I was getting about 5us rms variation in daylight reducing to ~3.5us in darkness, clearly the sensor is somewhat affected by daylight.
4. Knowing the amplitude of swing we can estimate the rms position error sensing by the opto, which comes out to ~0.25 microns in the light or 0.16 microns in darkness. This is the same order as I actually measured on these devices and mentioned here in a previous post.

So I think my conclusion is that one will get an irreducible measurement error of the order of a few microseconds rms using the Sharp optos. To put that in perspective the expected time error over a year due to that would be about 14ms which is probably insignificant compared to other time errors for a pendulum clock.

[Michael GilliganParticipant @michaelgilligan61133]

Posted by John Haine on 10/04/2023 22:57:57:

[…]

3. Eventually I think I have established that the irreducible uncertainty of the time measurement is a few microseconds – I was getting about 5us rms variation in daylight reducing to ~3.5us in darkness, clearly the sensor is somewhat affected by daylight.
4. Knowing the amplitude of swing we can estimate the rms position error sensing by the opto, which comes out to ~0.25 microns in the light or 0.16 microns in darkness. This is the same order as I actually measured on these devices and mentioned here in a previous post.

.

I’m sure you must have mentioned it before, John … but could you please remind me of the part number for that Sharp device … I’m not currently in a position to do any useful mechanical tinkering, but I would like to have a look at the optical side of things.

Thanks

MichaelG.

[John HaineParticipant @johnhaine32865]

Michael, it's the GP1A57HRJ00F.

[Michael GilliganParticipant @michaelgilligan61133]

Thanks, John

I had ‘just now’ found the previous reference, and was coming back to edit my post

… but it’s good to have your confirmation.

MichaelG.

.

Edit: __ Data-sheet courtesy of RS, in case anyone else is interested:

https://docs.rs-online.com/7a93/0900766b81327ada.pdf

.

Edit: __ I note that there is another version which employs a light modulation system:

https://global.sharp/products/device/lineup/selection/opto/receiving_light/opic/index.html

depending on its other characteristics, that may be the way to avoid the ambient light issue.

Edited By Michael Gilligan on 11/04/2023 08:50:33

[Michael GilliganParticipant @michaelgilligan61133]

Posted by Michael Gilligan on 11/04/2023 08:30:59:

.

Edit: __ I note that there is another version which employs a light modulation system:

**LINK**

depending on its other characteristics, that may be the way to avoid the ambient light issue.

.

I have just been looking at its data-sheet, and I suspect/fear that the light modulation system might bring its own problems. … the tolerance for the GL output is rather wide.

MichaelG.

.

Ref. __ https://docs.rs-online.com/f56e/0900766b81327ae3.pdf

Edited By Michael Gilligan on 11/04/2023 09:35:54

[John HaineParticipant @johnhaine32865]

Thanks for that Michael, as you say the response time at ~0.5ms is rather long and also variable which would increase the "escapement deviation". I think in practice it will be easier to just shield the opto from too much ambient light.

[Michael GilliganParticipant @michaelgilligan61133]

Unsurprisingly … I haven’t read it yet, but

This looks a useful book, and the download is very speedy: **LINK**

http://bitsavers.informatik.uni-stuttgart.de/components/sharp/_dataBooks/1994_Sharp_Application_Notes.pdf

OPTOELECTRONICS starts on P463 of the pdf

MichaelG.

[BazyleParticipant @bazyle]

If you are, say, using the leading edge of the pulse is it possible to measure both leading and trailing edges and computer the centre to offset ambient light bias?

[John HaineParticipant @johnhaine32865]

Posted by Bazyle on 11/04/2023 14:11:16:

If you are, say, using the leading edge of the pulse is it possible to measure both leading and trailing edges and computer the centre to offset ambient light bias?

I already use all the edges.

[Michael GilliganParticipant @michaelgilligan61133]

My brain is feeble this morning, so I am just linking this page in case anyone can make use of it: **LINK**

Ballistic Chronograph MK2 #DIY

The salient point being that his ‘light gates’ have a very fast response.

MichaelG.

[david bennett 8Participant @davidbennett8]

Has anyone added up the irreducible timing errors for every line of code read ( and acted upon ) by arduino/pi devices in this context ? Or at least an average ?

dave8

Edited By david bennett 8 on 14/07/2023 22:00:57

Edited By david bennett 8 on 14/07/2023 22:02:38

[SillyOldDufferModerator @sillyoldduffer]

Posted by david bennett 8 on 14/07/2023 21:52:13:

Has anyone added up the irreducible timing errors for every line of code read ( and acted upon ) by arduino/pi devices in this context ? Or at least an average ?

…

I've dabbled a bit, and taken high-level timings to identify slow code, also measured the variance of the USB link. (Serial interface times vary much more than Arduino code.)

The datasheets of most microcontrollers give how many clock cycles each machine instruction takes. Following clipped example is from Section 29, Page 292 of the ATMega16U2 datasheet, a CPU is used by many Arduinos.

The last column shows how many clock cycles a particular instruction takes. On this type of processor most instructions execute in only one cycle. As the Arduino is clocked by a 16MHz oscillator, they take 62.5nS each. Other instructions take 2 or more cycles, and their times are multiples of 62.5nS. Though best to write a program to do the analysis and counting, these instructions are easy to sum and time predict, but read on…

However, other instructions, such as the Branch group, take 1 or 2 cycles depending on a TRUE or FALSE condition. Their timings depend on the input and cannot be predicted exactly. They average somewhere between 62.5 and 125nS depending on the input.

May have noticed in the table that subroutine calls are expensive, costing 5 cycles each (312.5nS). They often occur in conjunction with Branch calls: if TRUE then CALL subroutine, making the average time cost vary even more depending on the input.

Input can be data or events, often a mix. Events are often handled by Interrupts, which also make it hard to predict exact execution times. Interrupts are hardware driven. When one occurs, the processor is stopped mid-flight and it saves current state to memory. Then a special subroutine is executed to manage the event. That done, normal operation resumes: after resetting the previously saved state, the processor carries on. Difficult to predict how long any section of code will take to execute when random events can interrupt and delay it.

More timing uncertainty when the microcontroller exchanges data with another machine. For efficiency reasons, it's usual to send data in blocks rather single bytes, and the other end may not be ready. Time variations caused by Input-Output are typically large – tens of milliseconds rather than nano-seconds.

The language, compiler and compiler settings add more uncertainty. 'C' is rather close to the hardware and tends to produce efficient machine code without the programmer doing anything special, hurrah. However, the Arduino compiler (g++) is set to produce space efficient rather than speed efficient code, not so good for time critical work. It can be changed. There are a bunch of optimisations that can be adjusted case by case but the programmer has to understand how appropriate these are to his problem. The machine code produced by the compiler varies, so all timings have checked after changes.

In practice, most microcontroller code isn't time critical, and performance can be measured 'on average'. Simple code is usually predictable, and the error caused by 1 second pendulum events is small. Not worth getting into deep analysis and micro-efficiencies unless an application really is time critical. My experimental clock pays moderate attention to timing – mainly ensuring the code doesn't dither.

Truly time-critical code is difficult to write and debug. There are techniques and tools, but they're all advanced. A fair bit can be done with the Arduino compiler by going backstage and altering the configuration. Also, code can be timed accurately by flipping pins start and end of critical sections and measuring with an oscilloscope. Professionally, there are profilers and other tools that help.

Dave

[david bennett 8Participant @davidbennett8]

Dave, wow – most of that is beyond me. I just didn't know by how much. I was looking at this in broad terms, such as is the drift being seen caused by the relatively poor arduino ceramic based clock,making it unsuitable for the job. Even the pi clock couldd be lower performing than what you need to convert your pendulum timing to true seconds in a timely fashion to make appropriate adjustments. A microscopically small ( I almost said minute  ) variance to seconds recording could put your clock below the best. Could that variance exist?

dave8

damn smiley removed.

Edited By david bennett 8 on 15/07/2023 13:23:00

Edited By david bennett 8 on 15/07/2023 13:23:29

[S KParticipant @sk20060]

To add another data point to the noise of the Sharp opto: I measured 5.5 us RMS noise using an old HP counter in muted daylight. That was with me stomping around the pendulum during the measurement, making material contributions to the noise. Relative to the fall time of the opto (about 20 ns, and I was only using this edge), I consider this to be poor.

It's possible that the mechanics of the pendulum contributes substantially, but given the two quite disparate pendulums and measurement methods, the above-mentioned 3.5-5-ish us RMS noise is likely irreducibly intrinsic to the opto itself.

 

Edited By S K on 15/07/2023 16:22:30

[SillyOldDufferModerator @sillyoldduffer]

Posted by david bennett 8 on 15/07/2023 13:20:58:

… I was looking at this in broad terms, such as is the drift being seen caused by the relatively poor arduino ceramic based clock,making it unsuitable for the job. Even the pi clock couldd be lower performing than what you need to convert your pendulum timing to true seconds in a timely fashion to make appropriate adjustments. A microscopically small ( I almost said minute ) variance to seconds recording could put your clock below the best. Could that variance exist?

Maybe, ceramic resonators are exactly the sort of device that hop about, which is worse than steady drift. For measuring, best to use an Arduino with a crystal oscillator such as the Leonardo or Pro-Micro, though even these are relatively poor timekeepers.

'Could that variance exist?' you ask. Absolutely it does, and there are many causes, including those due faulty measuring as you suggest.

A noisy pendulum is one where the period varies beat by beat. An ideal seconds pendulum would be spot on every time, but high precision measurements show they vary quite a lot. In so far as I trust my measuring system, this histogram shows my pendulum is fairly good in that its period clusters tightly around the mean:

Q is an oscillators Quality factor – basically a measure of how much it wobbles. Q=9896 is satisfactory, a bit noisy, with considerable room for improvement. Another measure is Standard Deviation: my pendulum's period varies, aka noise, by up to about 80 microseconds per beat, error range about 0.00857% Again, must do better!

Many causes of variation apart from faulty measurements. Changing air pressure and temperature cause predictable variations that can be compensated. Other causes can be traced and minimised: mechanically imperfect mechanical escapements; loose suspension; wear; shake; resonances; rod stretching and contracting; underground water movements; bob stirring the air etc.

Part of the fun is making improvements that reduce variability, even though we know pendula remain slightly noisy for mysterious reasons whatever is done. The challenge includes finding or making tools precise and accurate enough to see what a pendulum really does in fine detail. There could be fame in it. As pendulum clock technology was never fully developed because electronics took over, it's possible that the best pendulum clock ever could be made by an amateur. Tantalising!

Dave

[S KParticipant @sk20060]

I'd like to hear any commentary on the philosophy of efforts in pendulum projects.

I've paused my own considerations for a second pendulum project because I can't quite figure out what my goal should be. I've seen some aiming at the highest precision, e.g. "can I beat Harrison's Clock B?" That's a perfectly fine goal with many learning opportunities, but it's the how of that goal that seems less tied down, philosophically, other than "whatever it takes!"

For example there's a certain range of extremities that can be taken:

• Make a simple, "pure" pendulum, e.g. a pendulum that is not compensated, but uses the most stable materials one has available, e.g. Invar, carbon fiber, quartz, etc.
• Use traditional temperature compensation techniques.
• Add the reduction of buoyancy and air friction effects by placing it in a partial vacuum.
• Use optical measurements and electronic impulsing instead of a traditional escapement.
• Use other electronics to measure temperature and/or air pressure, and compensate for these computationally.
• Electronic compensation of errors, e.g. by periodic comparison to a known-accurate time source.
• Use an ultra-high-quality time source and modulate the pendulum's motion to match.
• And, these days, everything is automatically "better" if you throw in some AI somehow. 😉

In the realm of traditional clocks using escapements, and even in the electromechanical Synchronome-type clocks, it's the very maintenance of those traditions that seem to be an important, if unspoken, goal. There's a laudable beauty in those finely-made efforts in brass, etc.

But with the all-out addition of electronics, something feels lost. With all that, saying "it's a pendulum clock" is dandy, but now it's so far removed from the pendulum clocks of old that it's only true in a technical sense. One just winds up with a clock that, for all the surrounding gizmos, might as well use a quartz oscillator instead of a mechanical one.

Of course, all this is fair as it's a hobby and an opportunity to learn as you play. But what would Plato think? 🙂

[S KParticipant @sk20060]

Q is an oscillators Quality factor – basically a measure of how much it wobbles.

Isn't it a measure of the energy loss per unit of oscillation?

Edit: Eh, there's probably a connection to noise in there somewhere, as for a pendulum the loss is via friction.

Edited By S K on 15/07/2023 18:30:28

[david bennett 8Participant @davidbennett8]

S K, I couldn't agree more with your philosophy re. traditional clocks. And isn't it ironic that chasing mechanical friction has been replaced by chasing "electronic friction"

I think Plato has had a giggle or rwo.

dave8

Edited By david bennett 8 on 15/07/2023 20:22:55

[Martin KyteParticipant @martinkyte99762]

My comment on SK’s question would be that the goal would be to construct a near as perfect detached pendulum (oscillator). That way everything that contributes to the environment of the oscillator is fair game and can be electrical mechanical or electronic. The rules should be that the frequency of oscillation should be solely dependent on the physics of the pendulum and not any external time reference. I would say that the compensation either has to be “built in” like temperature compensation of the rod etc. and barometric compensation using bellows and weights etc.

The other approach of an environmental chamber kept at constant temperature and pressure is also valid.

Interesting though Dave’s approach is I have to say I think it fails in one significant way. In order to learn the characteristics of his pendulum under changing environmental conditions he needs a borrowed “better” clock to teach the software. This I consider a cheat. Harrison used identical clocks running under different environments to fine tune his compensating mechanisms until they showed no variation. This is not a technique that lends itself to Dave’s clock.

Having said all that Dave’s journey has taught us all so much and we are free to play by our own rules after all. I’m certainly not criticising Dave’s amazing work at all.
Regards Martin

[SillyOldDufferModerator @sillyoldduffer]

Posted by S K on 15/07/2023 18:18:00:

Q is an oscillators Quality factor – basically a measure of how much it wobbles.

Isn't it a measure of the energy loss per unit of oscillation?

Edit: Eh, there's probably a connection to noise in there somewhere, as for a pendulum the loss is via friction.

Read all about it on Wikipedia! Their explanation starts:

The Q factor is a parameter that describes the resonance behavior of an underdamped harmonic oscillator (resonator). Sinusoidally driven resonators having higher Q factors resonate with greater amplitudes (at the resonant frequency) but have a smaller range of frequencies around that frequency for which they resonate; the range of frequencies for which the oscillator resonates is called the bandwidth.

Deeper into the article, it's explained there's a bandwidth definition (which I'm using) and a stored energy definition (as per SK's comment).

My experimental pendulum is measured and logged and the numbers are analysed statistically. Given the data I have, it's trivial to calculate Bandwidth Q. In comparison, the stored energy method is tedious. After the pendulum is pushed once, the number of swings it takes for the amplitude to decay by a certain percentage is noted. (I can look it up if anyone wants full details.) Before computers made logging easy, pendulum Q was always calculated by observing decay. The method gives a reasonable estimate after a few hundred swings, but I note measuring decay ignores what happens to Q when the pendulum is impulsed, inputting negative friction as it were!

In contrast, the bandwidth method calculates Q from many observations, in my latest run 1.6 million of them, and impulsed and decaying swings are both included. Other advantages. Calculating Q from a large dataset means I can answer questions like 'does the Q of a pendulum vary?' I think it does, perhaps with temperature and pressure. I'll write some code to find out. Watch this space!

Friction is multi-faceted: I daren't think about what it does to a timekeeper.

Dave

[SillyOldDufferModerator @sillyoldduffer]

Posted by Martin Kyte on 15/07/2023 21:03:28:

…

Interesting though Dave’s approach is I have to say I think it fails in one significant way. In order to learn the characteristics of his pendulum under changing environmental conditions he needs a borrowed “better” clock to teach the software. …

I worry about cheating too. But I must point out that all clocks before the Quartz era were checked against a better clock – the solar system. First noon was detected with a staff or giant sundial, later other events more accurately by observing star transits with a telescope. There are lots of highly accurate clocks in the sky – lunar, planets, Jupiter's Moons, and the earth ticking equinoxes and solstices as it orbits the sun.

Not all the ways of approaching pendulum clocks listed by SK are fair game in my book. My rule is that, once a clock is configured and set going, only the pendulum is allowed to tick it. For any comparison to be valid, the clock must be independent. Therefore I forbid myself to synchronise the pendulum to a better clock, such as GPS, and then claim my pendulum clock is keeping time. That would be a naughty fib!

Dave

Edited By SillyOldDuffer on 15/07/2023 21:32:25

[Martin KyteParticipant @martinkyte99762]

Hi Dave

Not quite my point. I don’t really have any problem with testing a clock using more modern technology but because you are using it to characterise the compensation curves you are in effect building it into your clock even though once the compensation has been ‘learned’ the clock runs on its own. If for instance you used a Shortt clock as your compensating time reference you could not expect to achieve any better accuracy than the Shortt. By definition your compensation could only be known to the limits of the Shortt clock. To exceed that you need to go to atomic/gps references which invokes more modern technology in the workings (compensation) of your clock.
As I say no criticism intended you are doing a good thing and your clock has certainly been the most interesting thread on the forum for years.

regards Martin

[S KParticipant @sk20060]

Posted by david bennett 8 on 15/07/2023 20:17:51:

S K, I couldn't agree more with your philosophy re. traditional clocks. And isn't it ironic that chasing mechanical friction has been replaced by chasing "electronic friction"

I think Plato has had a giggle or rwo.

dave8

 

That's a neatly-summarized insight!

My meandering thoughts concerning the practical philosophy of a new project of my own include:

• It should be a functional clock rather than a lab experiment.
• Mechanical design and execution choices should lean more old-school and favor simplicity and elegance, even at the cost of some accuracy. Few mortals expect a pendulum clock to be super accurate anyway, and bragging about it isn't going to impress anyone except – or especially – a very few clock gods.
• Electronic time-keeping, including the rating of an arbitrary-period pendulum, is OK.
• Decent-enough temperature accuracy can likely be obtained via use of an Invar shaft on its own (I have one on-hand), or perhaps one plus a brass compensator.
• Compensation for air pressure can remain beyond the scope of the project.
• Optical sensing of the swing is OK.
• I'd really rather do electro-mechanical (e.g. Synchronome-type) impulsing than electro-magnetic, despite – or perhaps because of – the added mechanical complexity.
• A commercial clock mechanism could be hacked to run the dial. Otherwise, the dial could be operated by a few small servos or steppers running each hand separately without gearing.
• Some artistic design, including of the dial's face, would be nice. I'm thinking a watercolor scene, perhaps of a sun surrounded by stars.

I'd hope that it would keep time well enough for long-term use without fussing over it. So I'm actually not adverse to periodic (e.g. once daily) corrections, such as off a high-precision real time clock module. Or, in a cunning if fatally-flawed plan to dodge the sin of directly correcting to a reference time, the use of a PID could merely chase the "real" time.

Plato would still roll his eyes. 😉

Edited By S K on 16/07/2023 00:06:25

[S KParticipant @sk20060]

Posted by SillyOldDuffer on 15/07/2023 21:31:41:There are lots of highly accurate clocks in the sky – lunar, planets, Jupiter's Moons, and the earth ticking equinoxes and solstices as it orbits the sun.

It's fun to note that monitoring Jupiter's moons is not necessarily a good way of time-keeping. Why? Because of the finite speed of light, monitoring their positions, e.g. by eclipses, delivers times that vary based on the distance between Jupiter and Earth. Indeed, the error can be quite a few minutes worth as the planets move relative to each other.

In fact, the observation of varying times of eclipses inspired and delivered perhaps the first estimate of the speed of light, and quite a decent one at that!

[Author]

Posts