Thoughts on Detecting Pendulums!

[John HaineParticipant @johnhaine32865]

As I’m measuring to 0.25us resolution it is even harder!  The approaches you have mentioned have been considered, one issue is that the packaged devices such as the Sharp don’t provide access to the raw photo detector signal.  As the response is also dependent on the light spectrum, one would ideally exclude all ambient light but then you might as well run in the dark!

Overall as I said I’m coming to the view that it’s best to use the detector to arm a gravity escapement which is actually mechanically unlocked, such as the Shortt pendulum used (a refined version of the Synchronome method).  Then “noise” from the detector, whether optical or HED, may affect measurement but will not be in the actual “oscillator loop”.

[John Haine]

On John Haine Said:

Actually I don’t think I did say that!……

No, you didn’t, it was Neil (Wyatt). My memory glitch – apologies to both !

[S KParticipant @sk20060]

I think one of the keys to low-noise and high resolution timing is using a fast sensor. The popular Sharp device, and the TT one, are in the microsecond-level delay times and can have fairly slow rise and fall times.

Better should be possible. I just submitted a tiny PC board for fabrication using a fast (20MHz) op-amp plus Schmitt trigger. It should have a propagation delay as low as 50ns and rise/fall times of maybe 3 ns (depending on the load).

It can be used with an inexpensive PIN photodiode (about $1) that looks like it has about the same performance characteristics as the expensive ($50) Thor Labs diode I tried earlier.

It should arrive within a week, so obviously I haven’t proven that it works yet. But assuming it does, I’ll have a spare or two if anyone is interested in comparing it with other options.

[John HaineParticipant @johnhaine32865]

Yes please, that sounds very interesting!

[S KParticipant @sk20060]

Here are the “fast” detector boards, along with a 5mm IR diode for comparison. It may take me a while to get around to testing them. If they work, I’ll start a new thread to discuss them and their performance.

 

[Michael GilliganParticipant @michaelgilligan61133]

Nice !

… I wish you joy

MichaelG.

[S KParticipant @sk20060]

I couldn’t resist making a quick, ugly hack of a test. It works.

Its input to output delay is longer than expected (I’m not sure why yet), but I’m getting about 600 picoseconds RMS jitter.

That’s quite possibly better than the noise in a typical physical pendulum. Both John and I were measuring about 3-5 microseconds jitter if I remember correctly. His pendulum is way better than my miniature gravity one, while I was using a faster Agilent counter, so I had presumed that the similarity in measurement was due to the Sharp sensor we were both using rather than noise in the pendulum itself or in the subsequent measurement apparatus. I’m going to try the same sort of measurement with the Sharp to see where that stands as a baseline.

But anyway, ~600 picoseconds? I’m pretty happy with that! 🙂

[John HaineParticipant @johnhaine32865]

That’s impressive – but how do you measure it?

At the opposite extreme, looking for a sensor for the Robertson Clock that could be “hidden” behind the pendulum I have come across an inductive proximity sensor with a nominal range of 5mm which should do the job.

https://www.fotek.com.tw/en-gb/product/335

Characteristics broadly similar to the Hall-effect devices I’ve previously investigated.  The timing errors and hysteresis are not really an issue as it is used simply to reset a gravity escapement.

[BazyleParticipant @bazyle]

Does the delay matter if it is consistent and can be allowed for?

[John HaineParticipant @johnhaine32865]

Well it can do if the sensor pulse is used for example to generate the impulse.  The delay manifests itself as a phase lag of the impulse which causes a losing rate.  If only impulsed in one direction it can be corrected by slightly offsetting the sensor but the lag is still slightly sensitive to amplitude.

[S KParticipant @sk20060]

My scope measures the delay and computes an RMS value over hundreds or thousands of waveforms. It’s not a very high performance scope, so at 1 GS/s it can’t actually measure time differences to ps levels. Instead, it presumably models the captured waveforms as it ordinarily does in order to display them smoothly (rather than as sparse dots), and then computes time differences from interpolated 50% values.

Anyway, while the “600 ps RMS” measurement is certainly open to suspicion, it’s probably decent. It does at least match my eyeball’s estimate, which is that there’s essentially zero jitter.

I’m stimulating the LED electronically using pulses, and I note that increasing the current through the illuminating diode decreases the delay in the rise time direction (LED turns on), but increases the delay in the falling (LED turns off) direction.

Given the above, I’d use the rising edge, and the delay for that at a reasonable LED voltage and current is about 250 ns.

 

[S KParticipant @sk20060]

Here’s a scope photo. The top (yellow) trace is the power to the illuminating LED. The bottom (pink) trace is the circuit’s output. There’s some ringing due to the slap-dash setup, or it might benefit from an additional decoupling capacitor at the power connection.

Near the bottom, it shows a delay of 278 ns and a standard deviation of the delay time of 551 ps after processing 1930 waveforms. Not too bad.

 

 

[S K]

On S K Said:

…

Given the above, I’d use the rising edge, and the delay for that at a reasonable LED voltage and current is about 250 ns.

 

Thanks for the explanation.  In fact, that may be a pessimistic estimate of delay since I guess an ordinary LED has some turn-on and turn-off delay which wouldn’t be seen if the LED was constantly illuminated and the light path occluded by a vane?

[S KParticipant @sk20060]

I did a similar measurement of the Sharp device as a baseline. As above, this test stimulates it via pulsing the illumination, which of course is not the normal operating procedure.

With a 100 Ohm current-limiting resistor on the diode and no extra pull-up resistor on the output, the rising-edge delay is 1.8us with 3.7ns jitter (and a quite poor rise time), and the falling-edge delay is 9us with a 22ns jitter. The fall time of this device is far faster, as has been noted before, but because of the longer delay, the jitter is greater. You might choose the rising vs. falling edge depending on whether the latency or the jitter is more important.

It’s not surprising that the latency and jitter times scale with each other – that would be expected, as faster response times almost always leads to lower jitter.

So, looking at the faster rise time numbers only, my device works out to be 6.5 times faster input to output latency with 6.7 times lower jitter.

 

[S KParticipant @sk20060]

The LED could be partly responsible for the unexpectedly longer latency. Naively, I’d expect the light output to follow the current pulse almost exactly, but some diodes do specify long rise/fall times. If a phosphor is employed, as in many LEDs, that could slow it down. I see what appears to be a strong “afterglow” effect going on when turning off the diode; higher currents lead to extended turn off times, so I suspect it does employ a slow-ish phosphor.

Of course, pulsing the LED is not useful in timing the pendulum, but an interrupting flag would be used instead. Then, as I’ve brought up in the past, the speed of the flag across the photo-sensitive area may become an important additional performance limitation.

[Robert Atkinson 2Participant @robertatkinson2]

A photo coupler will almost certainly use a infra-red diode. These do not use phosphors.
I did some work several years ago looking for a fast pulsed light source preferably white light. Just for completeness, because I though they would suffer from slow turn-off, I tested white phosphor LEDs I was very surprised to find that they were in fact very fast. Even faster in terms of “fall time” than a externally quenched Xenon short arc flash tube. Obviously there are different phosphors but I learnt not to write them off without testing.

Robert.

[Robert Atkinson 2]

On Robert Atkinson 2 Said:

A photo coupler will almost certainly use a infra-red diode. These do not use phosphors.

That was my understanding as well, hence my confusion over it. I am using an IR one that purports to have fast rise/fall times, but many quote slow times too.

Anyway, I’m unable to explain the long latency I see after turning off the LED. So, any other ideas about what might be the cause?

It’s difficult to probe the circuit while illuminating it too, but I suppose I could solder on a tiny stub of wire to gain access. A scope probe probably has as much capacitance as the rest of the circuit, though.

Edit: I’m not seeing a strong effect when I use a pulser in series with a large resistor as an electrical stimulus. Works fine and there isn’t a pronounced effect. Eh, maybe I am deluding myself that this should reveal anything. But nevertheless, there isn’t a pronounced effect.

[S KParticipant @sk20060]

Another update: I simply probed the photodiode itself, and realized that I have at times been applying WAY too much light. (I mentioned that I didn’t have a good grasp of how much light would be produced, and I certainly can’t see it!)

At anywhere near max brightness, I don’t need an amp at all. The capacitance at the input node is so small that I quickly get a full swing to the rail right at the diode. Only a tiny fraction of that amount is needed to trigger properly. So, it seems I was just saturating something so badly that it can take a while to eliminate the excess charge, hence the long turn-off tail.

Adding more light does make the circuit turn on a fraction faster, as expected, but it’s a weak effect. I’ll explore the low-light limits later, but there’s no good reason to use deliberately dim light as long as only the rising edge is used. Rather, my urging to use a narrow slit or pinhole over the sensor with a bright light is still preferred.

So the ~280ns turn-on latency and ~550 ps jitter stands as noted in the scope photo above. I’ll call the circuit a success.

I have 5, so if someone wants one for use or experimentation, message me privately and I can mail one at no charge. I can include two different types of photodiodes. Both have peak sensitivities at about 870nm, but one is clear and has a relatively broad input range, and one is “black” and is less sensitive to white light.

[Robert Atkinson 2Participant @robertatkinson2]

A CCD camera will see at least some of the IR light. Enough for setting up or checking operation. If you can remove the IR filter on the sensor of a digital camera it will work even better. This is sometomes refered to as a “full spectrum” modification. There is lots of info on the web e.g. http://www.infraredcameraconversions.co.uk

Robert.

[S K]

On S K Said:

On Robert Atkinson 2 Said:

A photo coupler will almost certainly use a infra-red diode. These do not use phosphors.

That was my understanding as well, hence my confusion over it. I am using an IR one that purports to have fast rise/fall times, but many quote slow times too.

Anyway, I’m unable to explain the long latency I see after turning off the LED. So, any other ideas about what might be the cause?

…

I have an ongoing uncomfortable medical problem that trashes my concentration into no better than 20 minute bursts, so all my projects are crawling.   One of them is an attempt to compare the basic Arduino collision detection module I repurposed to detect my experimental pendulum with the Sharp unit recommended by John Haine.

The set-up shown below is intended to establish the maximum possible performance of a photo detector by pulsing the LED electronically, not by breaking the beam with a pendulum.   By electronic standards a pendulum bob moves at the speed of a tranquillised snail on holiday!  I previously assumed that meant mechanical effects would be irrelevant.   Now I’m not so sure: as the bob crawls into beam breaking space, it’s not clear to me exactly when the shadow on the sensor will trigger the comparator, or if the trigger point is constant.   There must be some error, size unknown.

A shortcoming of the Arduino module is that it does nothing to manage the trigger point.   In contrast, the Sharp unit’s comparator trigger voltage is regulated.  I have high hopes fitting a Sharp detector to my clock will be a big improvement, even though the Sharp may not be the best of all possible beam break units!

Researching LEDs,

• Phosphor LEDs, almost all LEDs with colour, are about 10x slower than direct emission types.
• Almost all IR LEDs are direct emission types
• A direct emission LED should:
  • Turn ON in single digit nanosecond time, but
  • Turns OFF in tens of nanoseconds.
• By the time electronics have been added, expect 100s of nanoseconds.

The test rig will look something like this:

Nearly ready to go in that the driver and Sharp are wired up with a power supply, and the scope and generator are on the table next to it. My concentration failed at the point of reading my scope’s manual (Siglent 1102CML), to find out if it can log data points for external analysis.

Re, how bright the LED is run:

• Most important is the need to protect the LED and sensor from ambient light.   Ambient light changes continually, altering the sensitivity of the sensor, no matter how bright the LED.   Ideally the pendulum should be in a closed light and draught proof cabinet.
• My experimental clock is made of metal and the works are enclosed inside a shiny PVC pipe.   This caused problems due to internal reflections.  I found it necessary to:
  • reduce LED power to the minimum needed to reliably trigger the detector.  The Arduino module is rather sensitive, able to detect IR bounced off a wall about a metre away, so the LED can be wound well back in a clock where the sensor is a few centimetres away.
  • blacken the internal metal work and PVC tube
  • shield the LED and sensor:  front, back and sides
  • direct the beam with slits on both LED and sensor

Ought to mention again that the more I chase accuracy the nastier the problems I’ve found and then struggled to understand and fix.   Not too difficult to make a pendulum clock that keeps reasonable domestic time. But every improvement beyond that gets harder and harder, each fix revealing some new problem, each one getting more difficult to diagnose and compensate for.  Happy is the man with an escapement in a drop-dead sexy mechanical clock with only a minute hand to tweak once an month or so.   Time-nuts chasing better than 10 milliseconds per month live in a state of permanent disappointment.

I started believing I had a good understanding of pendula.   Now I know I don’t!

However, the latency observed by SK could be due to:

1. The slow switch OFF time of LEDs and photo-transistors.  Mostly it seems better to detect ON rather than OFF.
2. Comparators contain several active devices, each adding propagation delay, and making them relatively slow reporting OFF as well.   Working in the nano- and pico-second region really pushes the technology I have in my junk box!

Dave

[S KParticipant @sk20060]

Duffer:

The Sharp unit is inexpensive, quite easy to use, has a nice big gap (though that’s both a pro and a con), needs no adjustment (also a pro and a con) and it should be adequate for the job. It’s almost certainly better than your prior module, so if you have one I recommend just switching to it.

The setup you described for testing it electronically is pretty much what I did to measure its latency and jitter a few posts earlier. If you use the rising edge, which has lower latency, then you should add a pull-up resistor to the output as shown somewhere in the spec sheet. The falling edge has longer latency but a much faster fall time, so if you only use that edge, then no pull-up resistor is needed or desirable.

Previously, I recommended using only the falling edge, since it has a far faster fall time. The problem with a very slow edge is that whatever comes next in the electronics chain (let’s say a digital input pin on an Arduino) has some arbitrary and probably not particularly well controlled and certainly not noiseless threshold that, in combination with a very slow edge, can lead to noisy measurements.

In my above test, I measured 9us latency and 22ns jitter in the falling direction. I can’t say if the latency would bother you, but the jitter is maybe 5-10% of the resolution of your Arduino. That doesn’t seem terrible, so I’d probably still recommend the falling edge just to eliminate concern about its truly awful rise time.

Would my new detector module, with ~280 ns latency and ~0.55ns jitter, actually be better in practice? Probably not noticeably if it’s just followed by an Arduino or Picpet with say 200-400ns resolution. It’s nice that the latency would be down to about one least count, and that the jitter is low enough to be discounted, but to really take advantage of it, one would need to improve the resolution of whatever comes next too, e.g. with an FPGA operating with a 250-1000MHz OCXO or TCXO clock.

But even then, one has to back up and ask what resolution is actually needed? I’m not sure I’ve ever seen a good answer to this. Is there an accurate measure of the sheer mechanical noise in some of the worlds best clock pendulums? How about if my pendulum is, by necessity, mounted to a flimsy wall on a busy street?

[S KParticipant @sk20060]

I was pondering that last question of mine. To be clear, I’m wondering about short-term noise in the period, and not stability over days or years, etc. The point is to understand the level of noise one expects in the pendulum itself, before adding noise in the measurement apparatus.

I found some data on Harrison’s Clock B that, while not directly answering the question, at least suggests that it may have about 2ppm RMS noise in the period.

For a 2 second period, that would be 1us RMS. From memory, both John and I measured in the range of 3-5us RMS noise. Harrison’s clock has a mechanical escapement, whereas my measurements were made completely detached. Still, 3-5 times worse than Harrison’s doesn’t sound unreasonable.

My Arduino setup used an external higher-precision clock, and had a resolution (least count) of 200ns, which for a 2 second period would be 0.2ppm. That’s seemingly good enough for Clock B, though not by a large margin. For a pendulum operating sans electronics in the 3-5us RMS range, it’s more than enough.

 

[S KParticipant @sk20060]

An edit to my prior two posts:

Of course, 2s * 2/1,000,000 = 4us RMS, not 1.

I have doubts, but if true, then everyone seems to be in the same 3-5us RMS ballpark. (I think if you asked a quantum physicist, she would say that a few kg mass would have infinitesimally small RMS noise.)

Let’s say that’s the case. Then the Sharp* (or my own detector) plus a decent Arduino / Picpet setup should suffice.

I think where that leaves me is wondering about the flag vs. sensor size question. At least now I can see the sensor’s response directly if necessary (it’s hidden in the Sharp). But only if I ever get back to making progress on my new pendulum.

* About the Sharp: The rise time without a pull-up resistor is about 1 us vs. a fall time of 20 ns (from memory). If a pull-up resistor, perhaps even with a lower resistance than recommended, can get that down anywhere near 20ns, then using the rising edge would be the superior choice. A smaller value resistor would increase power consumption and raise the low-logic level above zero, but some amount of this should be fine.

It’s also worth considering what it’s connected to. If it’s only going into an Arduino, that has inputs that latch on every clock cycle, at 16 MHz. You really don’t want it to flip due to noise between clocks, even very rarely, but due to the 62.5 ns between samples, it’s less likely to be trouble than other circuits I can imagine.

 

[S K]

On S K Said:

…
But even then, one has to back up and ask what resolution is actually needed? I’m not sure I’ve ever seen a good answer to this. Is there an accurate measure of the sheer mechanical noise in some of the worlds best clock pendulums? How about if my pendulum is, by necessity, mounted to a flimsy wall on a busy street?

Pleased to see from SKs various posts that our thinking is similar.  We can’t both be bonkers!

I’ve not found much discussion of noise in mechanical pendulums other than steps taken to minimise it.   Bolting the suspension to a massive wall, installing the clock in a deep cellar, avoiding locations subject to earth tremors, and keeping well away from sources of man-made vibration like roads.

Most pendulum clocks are calibrated and assessed by comparing them over a long period with a more accurate time source.  Originally astronomical movements, but these turn out to wobble slightly compared with a good quartz clock, and are even more obviously imprecise compared with Atomic Clocks.   My observations suggest that pendula have measurable per swing inaccuracies, that average out over time making pendulum oscillators appear better than they actually are.

My experimental clock takes a different approach to calibration in that it depends on a statistical analysis of accurate per swing timings. If the per swing measurement is noisy, for whatever reason, then my statistics will produce skewed results.   My clock doesn’t need or measure accurate per swing time after calibration, but it depends on the collection of accurate per swing data whilst the pendulum is being assessed relative to my high-accuracy clock (GPS/NTP)    Improving the calibration should have a marked effect on the clock’s accuracy.

Looking at the calibration stats shows much more per swing noise than expected.   In the past, some of it was traced to design and build errors in the pendulum and frame.   Having nailed those, it became apparent that ambient light and reflections were causing trouble, so they had to be fixed  Most recent suspect is the Arduino module, which I failed to spot has no hysteresis.   It’s too simple for this job.

The stats also show the pendulum reacting to external vibration, and I had to move the clock to a quieter more solid part of my house.   It detected last years earthquake in North Africa, but not the one in Turkey, which John Haine’s pendulum saw.    Not sure why, possibly the orientation of the pendulum swing relative to the earthquake source or it’s period makes a difference.  Another mystery!

Nothing done today.  Dozed all afternoon after being forced into taking Codeine.   I dislike the drug-induced time-wasting almost as much as the pain,  but the flesh is weak!

Dave

[S KParticipant @sk20060]

I took a look at how light levels affect the sensor’s response.

As noted above, more light decreases the “on” latency because photo-charge quickly floods the op-amp’s input, while increasing the “off” latency because a larger amount of charge takes longer to remove.

Tuning the light input for the “off” transition results in the fastest performance by a small margin: 205ns delay and 522ps RMS jitter.

The two directions provide about the same performance relative to the 200-400ns Arduino/picpet-level time resolution, so perhaps the bigger question is which is more stable, e.g. under varying room-light conditions. For that, I’d suspect the “more light = good” direction is better.

I also realized that the op-amp is slew-rate-limited in this application, at least in the “lots of light” configuration.

Though this is plenty good enough, I’ve been thinking about what a Version 2 iteration could look like:

• Change to an op-amp with a higher slew-rate?
• Add a threshold control via a surface-mount potentiometer? This sounds useful.
• Add a second stage? This doesn’t feel necessary.
• More decoupling should be added at the Schmitt trigger.
• Add a small PCB for the light source too, including a potentiometer for controlling the amount of light? I’d make it the same size board and with matching positions for light and sensor, and maybe also with both boards having a position for a stand-off between the two.
• Add a small FPGA with an SMA input for a high-performance clock? 😈

Is there a realistic scenario where more performance is needed in a pendulum application?

 

[Author]

Posts