Precision pendulum techniques

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.

.

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.

Michael, it's the GP1A57HRJ00F.

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

.

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

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.

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.

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.

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

https://td0g.ca/2020/04/19/ballistic-chronograph-mk2-diy/

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

MichaelG.

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

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

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

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

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

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

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

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

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

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