Carl W’s “New Clock Maker” thread, #731352, started a discussion about the merits of Hall Effect Device versus Optical Detectors, which I thought worthy of some research.
A Hall Effect Device (HED) detects a magnetic field, such as a tiny magnet glued to a pendulum bob, whereas an optical sensor detects the breaking of an Infrared or visible beam of light as the bob swings. Other possibilities include inductive, capacitative, and disturbance of an electrical field by the bob in some way. A fairly popular method detects the current generated in the impulsing electromagnet coil as a bob mounted magnet flies past, and uses it to pulse the electromagnet. Only needs a couple of transistors.
The ideal detector is triggered instantly by the pendulum at exactly the same point in it’s flight, and this isn’t easy to engineer. Preferably it should avoid power supply and logic level conversion problems by working at 5V or 3.3V. Of these systems the Hall Effect and Optical methods are probably the easiest to build, but neither is foolproof.
Reading a selection of specifications I found most HEDs are slow operating, between 50Hz and 3000Hz (20mS to 0.3mS) which suggests they will cause significant detect errors, not much better than a mechanical switch, though less intrusive. Another problem is that magnetic fields are not sharply focussed unless the detector and magnet are very close, less than 2mm apart. Although possible to focus a magnetic beam electronically, quite complicated! There are HEDs which respond at microsecond speeds, but they’re not cheap, and have to be operated very close to the magnet. The specs suggest ordinary HEDs are fine for RPM counting and door switches, but inferior to optical sensors when speed is of the essence. In a 1 second pendulum, a 10uS detect error could translate into a 10ppm deviation, which is far from bad, unless it’s the main source of error and can be fixed with a better sensor. I’ve gone off using a HED to detect where the bob is in a clock, mainly because their precision is doubtful.
Optical sensors come with their own problems. They are often sensitive to ambient light, diffraction and reflections, and prefer a sharp beam, typically requiring collimation with a lens or slots. A sharp beam also has to be well-aimed, making the detail design a little fiddly.
From a raw sensor of any description, one would expect a bell-curve transition. The sensor starts to see the bob at low level some time before the peak, and can still see a diminishing signal for about the same time it took the signal to peak from nothing.

This begs the question, where is the best place on the bell-curve to trigger? Not sensible to trigger when the signal is very low, down in the noise, nor is it easy to detect a peak in real-time. The usual arrangement is to trigger at some fixed point on a rising or falling slope, perhaps 33, 50 or 66% of peak. Higher settings tend to blank out noise, and give the signal time to stabilise.
Another way of reducing trouble due to changing ambient light is to modulate the IR beam, and only trigger when the modulation is detected. This is a common built-in feature in many components, but I think best avoided. The beam is usually modulated at 38kHz, introducing a potential quantum error in units of 0.026mS, and although the detector won’t be triggered by sunlight alone, the 38kHz decode will be delayed until the signal is strong enough to blast past ambient. Although better than a mechanical switch, considerably inferior to an unmodulated detector operated in the dark.
I made a mistake in my clock! Looking to use only off-the-shelf components, I selected the cheap HW201 Arduino module as a short-cut. It contains an IR LED, phototransistor, sensitivity adjust pot and a comparator to clean up the output signal, almost ready to go. However I had a lot a trouble getting it to work reliably, and have only just realised the problem still isn’t fixed because the comparator circuit is too simple. At the very least it needs an extra 10M resistor, see ‘adds hysteresis’ on the diagram:

The HW201 circuit is arranged such that the output flips between 0 and 5V whenever the output of the phototransistor rises or falls below the sensitivity voltage controlled by the pot. Not good enough! As the noisy real-world phototransistor output traverses the trigger voltage, rising slowly at bob speed, about 0.1m/s, the much faster comparator flips rapidly between on/off, creating a shower of spikes over a very short period of time, only one of which gets through randomly as the trigger. My electronics are faulty. The cure is to modify the HW201 circuit by adding a 10M ohm feedback resistor between the comparator’s output and it’s + signal input. Then, the first decent spike during transition should be reinforced by the output, causing a clean flip. Oscilloscope traces show the difference, first without 10M feedback at high speed to show the zigzagging.

Next, cleaned up by 10,000,000 ohms worth of hysteresis:

My decision to misuse the HW201 without checking the circuit properly wasn’t smart, because this sort of mistake isn’t made by professional designers! John Haine recommends the Sharp GP1A57 opto-interrupter. The specification suggests this is a good choice, and buying one won’t break the bank, about £5! Typical rise time is quoted at 0.1uS, with a fall time of 0.05uS. The faster fall time suggests it might be advantageous for beam break detectors to trigger on falling edge signals. (True of other detectors: some are faster on rise, others are faster on fall.) The Sharp includes built in voltage regulation, which fixes another significant source of error, and a Schmitt trigger, but no lens. A potential gotcha is a warning in the blurb that the IR detector will lose about 50% of it’s power over 5 years, which is likely to shift the detect point. Nonetheless I spent a couple of hours on the web trying to find a better device without success. I finally bit the bullet and ordered a couple!
Have I finally cracked my clock problems? I doubt it! This is a voyage of discovery, and I think there is a lot more to say on the subject. As it’s entirely possible my summary above of detect methods is mistaken, grateful for any comments!
Dave