No more "cheating" than any other mechanism used to get the pendulum to accurately match a GPS derived time signal.
As you said a few posts further back in the discussion about PID control to deal with long time constants, "The clock compensates on every beat". So every beat you are adjusting the power to keep the pendulum in sync with the time standard. I was just suggesting a different (and possibly simpler) way to do that.
…
Ah, a misunderstanding! Here's a block diagram of a clock:
Typical oscillators are the earth's rotation, pendulums, balance wheels, quartz crystals, and the vibration of certain atoms. The perfect oscillator is stable, it doesn't drift, jitter, and it maintains a steady output no matter what. There is no perfect oscillator. Pendula are sensitive to temperature, air pressure, vibration, tidal effects, and possibly humidity. All friction is bad, as is any physical change in the bob, rod or suspension.
The counter is any device that counts beats and divides them into something useful such as Hours, Minutes, and Seconds. It also allows the clock to be set to a particular time. In a mechanical clock the counter is a fixed ratio gearbox.
The display is any device that converts the counter output into human useful form – the hands of a clock, or a digital display.
It's important to isolate these stages from each other. The Display mustn't effect the Counter, and the Counter mustn't effect the Oscillator. This is quite difficult to do in a mechanical clock, and pendula are very sensitive to outside influences, especially impulses, temperature and air pressure.
My clock minimises impulse problems by removing all physical connections to the pendulum. The escapement is replaced by an Infra-red beam and an electromagnet. I have accurate control over when the pendulum is impulsed, and impulse strength. In practice so far, these have been reduced manually to the point where the clock runs reliably. They could be used synchronise the pendulum to GPS, but aren't.
A conventional pendulum clock compensates for temperature mechanically in the pendulum, usually by exploiting the different expansion rates of two metals. One way is to partially fill the bob with Mercury. When the temperature rises the rod expands and would alter the timing, except the Mercury also expands, lifting the bob's centre of mass by rising inside it, and counter-balancing whatever the rod does. I'm not doing anything like that.
Instead of compensating the pendulum, I correct it's errors in the counter. My counter is a microcontroller, where the ratios are implemented in software. In addition to counting pendulum beats, it also reads temperature, pressure and humidity. After testing the clock over a long period, I know what the pendulum's period should be at any given temperature, pressure and humidity, and can compensate for them in the counter, not in the oscillator.
For this scheme to work the pendulum has to be reasonably well-behaved, which it isn't yet. I can compensate for reliable changes, but not for variations caused by unknown factors. This graph is giving me grief, it shows my clock is drifting and is fast compared with NTP:
What I don't understand is why the clock drifted slow at first, and then switched to drifting fast. It's not temperature or pressure related. If the rod were stretching or something like that the drift would be constant in one direction, not a tick shaped curve.
Forum friends have suggested improvements to my over simple suspension design, which could be buckling the suspension spring. When I get the chance I'll make a new one, but xmas and a family crisis are taking priority.
Dave
That all sounds very satisfactory. Essentially you are testing the pendulum to determine the rate under all conditions.
If you know the rate and can measure the conditions you can keep track of the time by integrating the ticks with a variable rate co-efficient. No different to any other precision clock including Harrison’s where the rate was measured and the time calculated from the time of running since setting the clock and the going rate.
This thread has 2 closely related components, how to make a super accurate pendulum clock allowing for changes in ambient conditions, and how to make an even more accurate electronic clock to measure the first. My clock has not been corrected since the clocks changed in the spring, it is currently 2 minutes slow against BST. I can only measure to 30 seconds as it drives a gents silent slave. To answer Michael's question, that's sufficient for me at present, especially as I set it to lose, it has a fast advance button for correction. I set it up using the clock on my phone. Once a design for a cleverer electronic whizbang is finalised I'll make one, but vacuum chamber is a step too far. Buying a Microset isn't a challenge (except to my pocket).
Now for a Xmas brain teaser, why do clocks run more slowly at night, and it's nothing to do with ambient temperature etc. And it is a very small difference, that should be a clue
Ah, a misunderstanding! Here's a block diagram of a clock:
Thank you Dave, now I am a little clearer about what you are attempting. What confused me was the digression into PID control – a technique I learned (and forgot about) long ago, but all in the context of closed loop feedback control. So I assumed you were trying to close the loop electronically.
I will now drift away into silence to finish putting new springs into and cleaning a small Maji era Japanese clock. Its oscillator is a hairspring balance wheel, it's counter is clockwork as usual but the indicator and strike mechanism a little complex as they cater for the changing length of the "hours" with the time of year.
Good luck with the project, I will follow with interest.
Please don't do that. All contributions are welcome. Ideas are as interesting as the technology especially as I don't entirely know what I'm doing! Anything that gets me thinking helps.
Now for a Xmas brain teaser, why do clocks run more slowly at night, and it's nothing to do with ambient temperature etc. And it is a very small difference, that should be a clue
Assuming you are sticking to pendulum clocks in keeping with this thread
I think they should run faster! Gravity is stronger at night. The sun is on the opposite side of the earth to the clock, so It's pull is additive to the earth's gravitational field. During the day the sun's field should subtract from that of the earth as perceived by the clock.
As the period T = 2π*Square root of L/g as G increases, the period T decreases. So at night T should be shorter than during the day.
Although that ignores the effect of the moon, tides and other variables. But the effect will be small!!
I seem to remember that because the moon is much closer the tidal effects of sun and moon are about the same, so it must depend on the moon's position too? In any case the effect is too small to measure except with Fedchenko's clock. But I agree with Peter it should run faster when gravity is higher.
My clock has not been corrected since the clocks changed in the spring, it is currently 2 minutes slow against BST. I can only measure to 30 seconds as it drives a gents silent slave. To answer Michael's question, that's sufficient for me at present, especially as I set it to lose, it has a fast advance button for correction. I set it up using the clock on my phone. […]
.
That seems a very sensible arrangement for a domestic timepiece, Duncan
… I suppose that the ideal would be for it to be negligibly adrift between each six-monthly re-set.
I seem to remember that because the moon is much closer the tidal effects of sun and moon are about the same, so it must depend on the moon's position too? In any case the effect is too small to measure except with Fedchenko's clock. But I agree with Peter it should run faster when gravity is higher.
Good point about gravity. I'd better rephrase the question, what effect makes clocks run more slowly at night than they would have.
I seem to remember that because the moon is much closer the tidal effects of sun and moon are about the same, so it must depend on the moon's position too? In any case the effect is too small to measure except with Fedchenko's clock. But I agree with Peter it should run faster when gravity is higher.
Good point about gravity. I'd better rephrase the question, what effect makes clocks run more slowly at night than they would have.
Is it because they're tired out after running all day?
Umm, a clock on the night side is on the ‘outside’ orbitally so it’s travelling faster than a clock on the day side or inside of the orbit. Relativity tells us that faster moving clocks run slower. (but only to outside observers)
As has been stated the gravity change with the earth and the sun on the same side of the clock will cause a shortening of the period (assuming a pendulum clock) but not perhaps if it’s at sea.
Umm, a clock on the night side is on the ‘outside’ orbitally so it’s travelling faster than a clock on the day side or inside of the orbit. Relativity tells us that faster moving clocks run slower. (but only to outside observers)
…….
regards Martin
Edited By Martin Kyte on 23/12/2022 21:53:29
Give that man a coconut. I make the difference 0.32 parts per billion, even Fedchenko might struggle with that
The effect is much more serious on GPS satellites and as far as I know there are a team of Americans who manually (remotely) adjust the satellite clocks to keep the system in synch. I read that doing it by calculation is beyond practical.
regards Martin
Why not make a clock that is driven from a GPS locked 1 second pulse, easy enough to do.
The 1 second pulse could also impulse a pedulum to keep it swinging, there does not need to be any connection between the pedulum and the clock mechanism and most people would not know.
Bobs your uncle, an accurate(ish) clock with a swinging pendulum, or it that too simple?
Why not make a clock that is driven from a GPS locked 1 second pulse, easy enough to do.
…
Ho!Ho!Ho!
merry Christmas everyone
Oh! Oh! Oh! is the sound of Santa retreating. This idea has already been denounced. Howi's punishment is to read the whole thread from the beginning and there will be an exam at end. I can't imagine a worse way of spending Christmas!
Incidently I never eat Turkey at xmas. I like lamb because it says "Baa, baa, humbug" just before it gets the chop.
Umm, a clock on the night side is on the ‘outside’ orbitally so it’s travelling faster than a clock on the day side or inside of the orbit. Relativity tells us that faster moving clocks run slower. (but only to outside observers)
…….
regards Martin
Edited By Martin Kyte on 23/12/2022 21:53:29
Give that man a coconut. I make the difference 0.32 parts per billion, even Fedchenko might struggle with that
But did you also take into account the difference due to gravity? I was only thinking about pendulum clocks, but general relativity also says that time shifts not only with speed, but also gravitational potential.
Last night watching a boring film on telly, I tackled the problem of extracting Q from my clock's data log. It contains nearly half a million records, including an accurate measure of the pendulums period.
Pendula have a number of characteristics, most obviously how long each swing takes. Nearly as important is 'Q', which is a measure of the pendulum's "goodness". It's the ratio between power stored and power consumed.
Q = 2π × storedEnergy ÷ energyLostPerSwing
An ideal pendulum would lose no energy and swing forever after a single impulse. Real pendulums lose energy stirring air and in the suspension. After building a low-loss suspension, running the pendulum in a vacuum increases the Q by a factor of about 5.
One way of measuring Q is to set a pendulum swinging and measure how long it takes to the amplitude to halve, the time being multiplied by 4.5 The method is tedious and not particularly accurate unless special care is taken. Another way, when a log is available, is to determine the signal's bandwidth from the distribution of tick times. Then:
For my purposes, coding in Python with the numpy (Numeric Python) module, the calculation is rather easy because numpy comes with a percentile function. Given a list of periods, the resonant frequency is the 50% percentile and the bandwidth is the difference between the 70.7 and 29.3 percentiles. In python:
# Q
h, l, r = numpy.percentile(ticks, [70.7,29.3,50] )
b = h – l
q = r / b
print('Q',q)
Bandwidth of the tick distribution shown graphically, green lines, below:
Thus my pendulum has a Q of 9496. This is in the range Q=3000 to 15000 given by Rawlings for Regulator pendulums in Air. It suggests the suspension spring I made from a disposable safety razor blade is acceptable.
Sharp-eyed clock-aficionados will have noticed not all is well with graph above. The distribution, which should be balanced around the red-line is skewed in favour of fast periods. Coupled with the rate graph, it appears my pendulum is speeding up. The clock is now 29 seconds fast after 4 days 15 hours (poor). The drift probably explains why Q is dropping, last night it was nearly 9600, now it's 9350. I think the apparent bandwidth increases as the clock drifts.
On the plus side the new clock software is working well on my dining table. GPS measures the Arduino crystal once per second, and the calculated correction measures pendulum period more accurately than before.
Next job is to find an undisturbed place for the clock in my house with a good GPS and Wifi signal. This is difficult!
Umm, a clock on the night side is on the ‘outside’ orbitally so it’s travelling faster than a clock on the day side or inside of the orbit. Relativity tells us that faster moving clocks run slower. (but only to outside observers)
…….
regards Martin
Edited By Martin Kyte on 23/12/2022 21:53:29
Give that man a coconut. I make the difference 0.32 parts per billion, even Fedchenko might struggle with that
But did you also take into account the difference due to gravity? I was only thinking about pendulum clocks, but general relativity also says that time shifts not only with speed, but also gravitational potential.
So the solar gravitational effects will also impact the timings – even of a balance wheel clock!
I suggest when Dave is having to apply these corrections in his counter logic we can consider that he has almost succeeded.
From what I have read, at least for, GPS satellites velocity dominates over gravity in terms of time dilation for the gravity fields experienced. Do feel free to check it was a while ago since I read anything about it.
Posted by Michael Gilligan on 24/12/2022 12:14:37:
Great progress, Dave
… I am very impressed [and genuinely surprised] by that Q
Looks like you are heading for stardom !
…
The result assumes I understood the maths and wrote the code correctly! I'm not entirely surprised it's that good because the design is so simple. Provided it's hanging straight, and the spring is about the right boing, there's not much to go wrong. I took your advice last time the suspension was apart by exposing more spring. In the next version I plan to make a new spring longer and thinner as you suggested ages ago.
Moved the clock and installed the new software with GPS. A few bugs!
Tick Amptd Triggr IM Period ClockUNIX ClockHMS NTP UNIX
The amplitude (blue) is much too high, way above the trigger threshold, and despite that the bob is being impulsed on every beat.
The orange pair should be a UNIX timestamp, seconds and microseconds, set to current NTP time when the clock is started. Didn't happen, it started at zero. It is incrementing correctly and the HH:MMS decode looks right too. 127.321327 was 00:02:07 GMT on Thursday 1st January 1970.
Temperature, Pressure and Humidity are missing, probably because I turned the sensor off whilst testing the new version.
Good news though is that the GPS corrected period measurement appears to be working. This was the main reason for upgrading the clock.
So far GPS is holding up. The antenna now looks out of a west facing window, and the GPS module locked immediately rather than taking an age to find enough satellites, always a good sign. But, the availability of good signals might change as the earth rotates and the satellites in view change. A disadvantage of using GPS is poor signals cause my period correction to go potty. When the parts arrive an OCXO will be substituted; less accurate than GPS, but doesn't depend on an indoor antenna.
Why not make a clock that is driven from a GPS locked 1 second pulse, easy enough to do.
…
Ho!Ho!Ho!
merry Christmas everyone
Oh! Oh! Oh! is the sound of Santa retreating. This idea has already been denounced. Howi's punishment is to read the whole thread from the beginning and there will be an exam at end. I can't imagine a worse way of spending Christmas!
Incidently I never eat Turkey at xmas. I like lamb because it says "Baa, baa, humbug" just before it gets the chop.
Dave
I know, but I could not resist it, it's Christmas, we need to chill out more.
Set the clock up in a mad rush yesterday and after frantically fixing a few software bugs, I left it running.
Ran the statistics just now and had a heart attack because the results are so good! After nearly 17 hours, my clock is 0.039 seconds fast, an error in the same ball-park as Shortt №48, which wobbled about 0.02 seconds per day when measured with an Atomic Clock.
Of course it's a false dawn. I've inadvertently created a GPS locked pendulum of the type suggested by Peter and Howi. I added GPS to the apparatus to measure pendulum period more accurately, and didn't notice that the real value was fed into the clock's counter. So the clock counts in GPS measure, not natural pendulum beats. The figures show that GPS and NTP are accurate, not that my clock is wonderful, sob!
The circular error graph confirms the lie. The distribution is badly skewed, and Q has dropped to 1709:
Two likely reasons. A known error in the Impulse logic is walloping the bob too hard, but mostly I moved the clock to another room. and the suspension is easily upset by being moved. An improved suspension is already on my 'To Do' list – need to get on with it.
On a positive note, a potential source of measurement error is eliminated. The GPS enhancement confirms the clock's temperature drift is mainly due to the pendulum, not the Arduino crystal.