Improved Experimental Pendulum

Grasshopper impulses every time, so it falls into my 'doesn't matter what you do as long as it's the same every time' category. I do realise this is a generalisation!

I used to have a copy of 'the science of clocks and watches', but I let it go. This explained very well best position of impulse.

I wouldn't presume to comment on statistics. I once proved beyond doubt hat the 2 test rigs we had for testing production machines were giving consistently different results. The boss of development took 2 machines and tested them on both rigs. No difference. Lies, damn lies and statistics!

I wouldn't presume to comment on statistics. I once proved beyond doubt hat the 2 test rigs we had for testing production machines were giving consistently different results. The boss of development took 2 machines and tested them on both rigs. No difference. Lies, damn lies and statistics!

Breaking news: the clock is running!

No celebrations because I made two silly mistakes with the in vacuo circuit board.

• A connector plug rises vertically from the board, no problem until the female is attached and doesn't leave enough room to slide the soil pipe on. This can be fixed with a right-angled connector.
• Worse, I completely forgot about the pressure/temperature sensor! Hope there's enough room for it on the existing board and I don't have to make another one from scratch. Doh.

Meanwhile I'm letting it run until there's enough period data in the log file to measure the standard deviation.

Dave

So, how did you make it run? Give it a bash? tilt it? Or is it not in vacuum yet?

Edited By Joseph Noci 1 on 25/04/2023 22:36:45

.

Sorry, Dave … but I think you might have missed the ‘philosophical’ point I was trying to make:
If there is any form of feedback being usefully involved, then the pendulum is an ‘agile’ device in a constant state of jitter … ergo the amplitude cannot be constant.

MichaelG.

Not in a vacuum yet. I altered the chariot (the 3D-print assembly that holds the magnet and IR sensors) to move the magnet closer to the bob. Not entirely happy with the geometry because it means the bob is impulsed later than I would like, so I'll have to print another one, which moves the sensors closer to BDC.

Ideally the chariot would allow the sensors and electromagnet to be adjusted independently relative to bob BDC, but I'm trying to keep the build simple.

I've ordered the pipe and fittings needed to exhaust the container, but I need to correct some silly physical mistakes on the veroboard before the soil-pipe can be installed. I forgot the BME280 and positioned a connector so the soil-pipe can't get past it to bed in the base.

Dave

Progress report. I'm running the clock without compensation to see how much impulse the revised pendulum needs - the bob is nearly 5 times heavier than the Mk 1.

A few problems:

• Self-start isn't totally reliable (failed once)
• Despite being mounted in a brass tube, the IR receiver was still sensitive to ambient light entering from the rear. Even though it shouldn't be necessary when the container is fitted I've added a shroud, which ensures good behaviour whilst testing the uncovered clock in daylight.
• Software bug in my code, where compensation was applied even when told not too. As the temperature sensor isn't fitted yet, the compensated period was wrong.
• Had to write new code to report on reduced data (no temperature etc.) Made more mistakes!

However, results are promising:

Nice straight line comparing my clock with NTP: it's consistently slow, which is easy to correct.

Dispersion is good (Q nearly 4000), but has two peaks, which is consistent with over-impulsing. I found balancing impulse so amplitude stays constant (approximately - see MichaelG's comment!), to be tricky. 18 is too low, 20 is too high, and the stats show 19 is slightly too high. The hardware timer's resolution is a little too coarse.

Something odd with the waveform, which displays a comb effect. Values that jump much further from the mean. The comb exaggerates the error - 88 times in 43153 is 0.2%, and it's not that big - standard deviation is 0.27uS

The wild jumping about at the end is due to me eating breakfast next to the clock and vibrating it.

Annoyingly have to go out now, because I have several changes to make!

Dave

That’s great progress, Dave

… good to see.

MichaelG.

you could put some small variable resistance in line with your magnet coil, then fine tune the impulse with that

" The wild jumping about at the end is due to me eating breakfast next to the clock and vibrating it. "

The size of the jump in the graph seems to indicate you had a 'Full English' for breakfast.

Martin.

Except the clock is remote controlled! What I actually did was go to the program and alter the counter/timer pre-scaler to provide 4x more precision. It's a single bit in TCCR2B:

So instead of a choice of 3 impulse lengths between 0.001088 and 0.00128s I have 12, which should be good enough.

I intend to try a regulator where the bob is impulsed slightly too lightly on every beat, so it gradually loses amplitude, but is topped when it drops below a certain threshold. The topping up can be finely adjusted to minimise shocking the bob.

Next job is to check last nights run. I deliberately set the impulse high and now have to tune it down to find the minimum constant impulse that's not quite enough to keep the pendulum swinging permanently.

I've also implemented John Haine's self-start, which pulses a stopped bob 'n' times at the right frequency to get it swinging. Moving the electromagnet closer to the bob also worked, but I'm not quite close enough because it fails to grab the bob about 1 in 15. John's method is better for another reason - it swings the bob gently compared with a violent grab/release after which the pendulum takes at least 10 minutes to settle.

Today's worry is whether there will be enough room for the vacuum pipe work as well as an AT Mega under the base. Hoping to get a battery in there too!

Dave

Edited By SillyOldDuffer on 29/04/2023 11:16:47

Edited By duncan webster on 29/04/2023 11:32:52

More fun and games!

During the day, I connect the clock (which is on my dining table so I can fiddle with it), to my workstation computer, making it easy to change the software. At night, I connect it to a RaspberryPi 3b, which wastes much less electricity and can be left running all the time. The clock failed to self-start on the Pi, odd because it worked before. Turned out to be due to me using a different USB cable: presumably the wires inside it are too thin and the volts drop enough to prevent sufficient amps reaching the magnet. Swapping the cable fixed it.

Lesson learned. not only does the amount of power actually available from a USB socket vary, but not all USB cables are equal!

Good result from last night's run:

Periods (in 62.5nS ticks): min 14914516.0 mean=14949452.289 max=15017427.0
dev = 3586.463 ticks
Clock Mean Period = 0.934341s
Actual Mean Period = 0:00:00.934465
std = 0.224us
Q = 7048

clockStart = 2023-04-29 20:05:42
ClockEnd = 2023-04-30 09:18:22.578480
ActualEnd = 2023-04-30 09:27:20.791752
ClockRun = 13:12:40.578480 (47560.57848s)
ActualRun = 13:21:38.791752 (48098.791752s)
Difference = -538.213s (-1.118975% -11189.746ppm)
Drift Constant Correction = 10453.0

The uncompensated clock ran nearly ten minutes slow after 13 hours, but the drift is constant, trivial to compensate, this lovely straight line graph:

I've sussed out what's causing the comb on the waveform graph:

I noticed the comb peaks follow the true waveform and seem to be the same size. They are! The raw data shows they are close to 65536 above normal, 2^16, which happens to be the value added when the program tests for a near miss counter overflow:

// Correct if just missed an overflow
if (TIFR1 & bit(TOV1) && pendulumCountAtEventEnd < 128) {
pendulumOverFlowCount++;
}

I copied the code from my hero Nick Gammon, but have always been suspicious of it. I believe it's meant to deal with the counter overflowing at about the same time a pendulum event is received. I shall have to study the datasheet again. Although the comb looks bad, it doesn't matter much in practice. Determined to understand and fix it though.

Another potential cause of noise on the pendulum is under investigation. It's the delay between the microcontroller detecting the bob and firing the electromagnet. I wondered how big the delay is, and if it varies much. This is typical:

Pendulum in yellow, magnet power in blue. The electromagnet is energised 60 microseconds after the bob breaks the IR beam. My test sample is very small, about 30 example, but the 60uS delay doesn't seem to vary. The main thing that would delay the magnet further is the clock receiving a command just before the beam is broken. Not likely because commands are sent at start of run to configure the clock and shouldn't be necessary after it's set.

Does anyone know how long a mechanical impulse takes between trigger and energy reaching the pendulum? It's not instantaneous.

I guess several tens of milliseconds in a Shortt Synchronome where the second pendulum operates a ratchet wheel, that releases a gravity lever dropping a small weight on the pendulum, operating a mechanical electric switch on the way. The switch releases another gravity lever that drops a weight on the first pendulum. Much slower than 60uS I suggest, plus variation due to the switch contacts, inertia and friction.

However I suppose the delay, whether mechanical or electronic, doesn't matter provided it's always the same-ish.

Dave

Great progress [again] Dave, but I wouldn’t worry too much about trying to compare your impulse-delay with that of the Shortt/ Synchronome … because that one only occurs once every [nominal] 30seconds, and yours is more ‘agile’

MichaelG.

My simple mind would use 2 processors, one to keep the pendulum swinging at a controlled amplitude, the second to do all the clever stuff

Dave, that lovely straight line graph must have been worth a "whoopee" or two!

dave8

.

Some useful notes about the history of USB power are included here: **LINK**

https://www.onlogic.com/company/io-hub/usb-type-c-and-usb-3-1-explained/

MichaelG.

Fixing the electronic mistakes took most of Sunday afternoon and didn't work when reconnected to the clock, so lashings of despair. Another silly mistake.

I'm not happy with the board - the layout was flawed, before I messed up! Had to mount the pressure/temperature module close to the switching transistor, not far from the cast-iron base, comparator chip, two LEDs, and the electromagnet coil. These the main sources of heat inside the vacuum containment, and may cause trouble.

A test run with the pressure/temperature module showed it works, but the log contains a high rate of false break readings, due to the beat counter occasionally triggering on both rising and falling edges. Not sure what causes this. As the input waveform is clean, it may be software: reading the pressure/temperature module, or maybe the extra time spent transmitting their numbers to the raspberryPi (which logs them).

Previously I was going to attach the electronics to the sensor chariot. It's easier to tie it to the pillars:

Didn't bother to tidy-up the wiring: saving that joy until I have a neat way of getting it through an airtight seal to the microcontroller under the base.

A few more changes:

• Removed old code from previous experiments.
• Pendulum now only impulsed when amplitude drops below a threshold. (The threshold is set experimentally and is probably too high. The impulse is also set experimentally, currently so an impulse is issued every other beat or two.
• Reduced the number of self-start beats from 20 to 6. 20 crash the bob into the electromagnet.

Vacuum parts have started arriving, so I'm adding them to the model. Or would if I could remember how to do pipes in Solid Edge. Fitting the vacuum stuff is going to be fiddly - tight space.

Dave

Edited By SillyOldDuffer on 01/05/2023 13:51:37

Pleased to report, fingers crossed, that I've fixed an intermittent problem that's been annoying me for ages. It's that,rarely and apparently randomly, the clock registered a double beat. The false beat occurred on the FALLING edge of the beam break, when the microcontroller was programmed to repond only to RISING edges. Should be impossible, and I've been chasing all manner of esoteric and unlikely causes - many hours wasted.

Seems the actual cause was electrical noise on the input. Microcontroller inputs are vulnerable because they're high-impedance, making it possible for them to pick up glitches on long wires, or even from adjacent pins. The cure is to tie the input either HIGH or LOW with a resistor, about 10kΩ. It stops static and soaks up short spikes. Looking very good so far, zero false triggers in over 12 hours.

At the moment I'm running the pendulum uncompensated to determine it's characteristics. Nice straight line on the drift graph, and period only varies up to 80 microseconds per beat, much better than the Mk 1 clock, with a sharp evenly balanced distribution, hurrah!

Annoyingly, the good weather is failing to provide the variety of big temperature and air pressure changes needed to calibrate the pendulum: correlations are identified, but not strongly, meaning compensation values based on them won't cover winter and summer confidently.

The spiky green graph shows something is still wrong with the amplitude code or electronics. (I hoped the resistor would fix it, nope!) Even though the error rate is only 0.5%, and the affect of each error on the pendulum trivial, I want to fix it.

Comparing last night's run with actual time this morning showed the the clock should be set to an average period of 0.935266s rather than 0.924012s. Period was set to 0.935266s and the clock reset to UTC this morning. If that works, the clock should run close to UTC, but is still uncompensated. However, weather permitting, it will collect enough tempertature and pressure changes to enable compensation.

Progress is promising enough for me to tackle the vacuum containment problem, difficult enough for it to be worth it's own thread. The parts needed to plumb it have started to arrive.

First attempt at plumbing was this:

Rubber hose from vacuum pump attaches to a nozzle connected to a valve, connected to T-coupler. Vacuum gauge on the end. Unfortunately, this configuration requires a ⌀ 6-8mm hole 100mm deep to be drilled accurately straight into the block. If it drifts, there's a high risk it will break out into the lower cavity.

Second attempt avoids the need for deep drilling, but more pipe and joints. The vacuum gauge can be upright at the front:

The more I think about how to contain the vacuum, the more difficult is seems. I'm after a deep vacuum, and yonks ago Roger Atkinson said of my Edwardes EB3A pump "Specification seems to be 26" Hg / 133mB", about 86% vacuum. Not bad for a home clock, but ideally the vacuum has to be held steady for years. The container holds about 2 litres of nothing, so a leak of only 1cc air per day is cause for concern.

Leaks are less worrying if the pump is in poor condition and can't get that low a vacuum, but then the clock won't achieve it's best.

Dave