Precision pendulum techniques

Is it really necessary to synchronise the pendulum with the ref. I may be misunderstanding your requirements though.

Could you use the pendulum sensor to set an offset value in your hardware. You then know the initial phase offset from NTP. “You may have already said that”.

The other way is possibly using the hit and miss synchroniser as per Shortt Synchronome style. Possibly you could use a modified impulse to achieve the same thing.

Just vague thoughts really. Ignore me if you think it’s all a non starter.

regards Martin

I'm a bit confused about what you wish to do, including what you mean when you write "clock" or "pendulum clock."

Is your pendulum an accurate seconds one? Or does the "clock" convert its beats to seconds via math? Do you mean a clock circuit driven by the pendulum, meaning that the pendulum is the thing that actually needs to be synchronized? If so, obviously the pendulum will start out of phase and it may take considerable effort over time to coax it into synchronization, if that's even possible.

A possible approach for initial synchronization would be to capture the bob with an electromagnet or some other sort of electro-mechanical trigger, and release it electronically on a beat. One would want to move the electromagnet, etc., out of the way after the release. (I thought about trying that for starting a genuinely-free pendulum's swing at a fixed amplitude for repeatable tests.)

Or do you mean you just wish to synchronize the "clock" (sans pendulum) to reset simultaneously with the external time source without a significant delay, but thereafter be incremented by an out-of-phase (and possibly not even seconds) pendulum? If so, you may need a faster circuit (e.g. an FPGA) or else yes, a repetitive correction in the fashion of a PLL sounds needed.

Of course confusing, unless you've read the other threads describing what I'm up to! Life is too short. Briefly a high accuracy pendulum clock, built with modern techniques, designed to run in a vacuum with various novel features. The pendulum period is arbitrary and I only need to know it accurately. A good chunk of the project is about accurately measuring the pendulum, happened to be a noisy 0.823456s in the last iteration.

The oscillator is a pendulum, and the counter/impulser is an Arduino. Together they are a clock, specifically a pendulum clock.

What needs to be synchronised is time, and there are various ways of doing that, including building a fixed seconds pendulum and releasing it to coincide with GPS seconds. Not attempting that, not least because my Mark 1 pendulum took over 15 minutes to settle after a cold start!

So, I have an Arduino counting pulses, and doing the maths needed to increment a counter which can be converted into human time. The counter keeps Unixtime, (ie UTC seconds since 00:00:00.0 1 Jan 1970) which the Arduino can decode into yyyy mm dd hh mm ss.s

The problem is how to get the pendulum clock's counter aligned accurately with NTP (or GPS).

I mentioned the possibility of applying a second phase correction to the complicated method I described and Martin asking 'Is it really necessary to synchronise the pendulum with the ref' crystallised my thinking. As the answer to Martin's question is 'no', I added the code necessary to correct the counter by comparison. Basically, the clock sends it's notion of time to a raspberryPi on every tick. It's a unix timestamp that the pi compares with NTP, and then sends the difference in microseconds back to the clock, which tweaks the counter as required. This looks to be setting my clock to within 20 to 100uS of NTP, hurrah. Difficult to tell exactly how well it's working because my test clock uses the Arduino's ceramic resonator, which drifts quickly and isn't compensated.

I'm rebuilding the pendulum support and vacuum chamber and can't test the software with a real pendulum at the moment.

Dave

As a lift once said “Pleased to be of service”

regards Martin

.

I may have touched on this before, Dave … but I think the important underlying difference between a traditional observatory clock and yours is the short-term stability. They are demonstrably very stable, whereas your is like a nervous race-horse.

As you have clearly discovered, It is much easier to check the relatively long-term rate of a conventional clock than the short-term rate of yours … and even checking at the most granular level; a given star only transits once per sidereal day.

If the observatory clock is within [say] one second in ten days, then it is reasonably safe to interpolate that accuracy down to short durations … but what is the comparable ‘reasonably safe’ thing you can do with yours ?

… I don’t know.

MichaelG.

I think part of my confusion is due to the lack of context; the "why" part. Why is it important to you to synchronize the two clocks? Just don't want to be off by up to a second? Do you expect to hold accuracy of <1s for very long?

I want to set my pendulum clock to UTC from NTP so that my clock starts within 1mS of UTC or better. Not unusual - as I write almost all the clocks round here are set to UTC, more or less inaccurately. Millions of them!

Yes it has to hold accuracy - my target is to approach the performance of a Shortt-Synchronome which kept time to within 8mS per year.

My clock steps in units of pendulum period, so it's not continually synchronised with NTP, but on each tick my clock and NTP should be in close agreement.

Dave

Seems to me you know how to calculate most of the correction and are just worrying about getting the system delay offset right. You need to find a way to measure that accurately, including the jitter, preferably in hardware. If it's solid, then no problem. Otherwise, it will limit the accuracy. Perhaps running a PID for a while would help dial it in, but you can't leave it running or it will subvert the reason for the pendulum.

Edited By S K on 24/03/2023 00:38:22

Do you really need to do this? Sounds a bit like trying to synch the OCXO of a gpsdo to utc at switch on. Surely what you need to do is know the period of your pendulum oscillator and its dependence on any environmental variables you want to compensate for. But it's the counter that converts frequency to phase (time) that needs synchronising to ntp surely? One thing you can guarantee is that even if you synchronise the pendulum to an ntp tick it's phase will immediately start to drift away. Unless of course you phase lock it, but that's cheating!

Yes that's right - I don't need to do what I described. It's the counter that needs synchronising, not pendulum.

I asked the question because my logic and solution both felt overcomplicated. Now I've explained my thinking, and seen the responses, I realise my approach was muddled, and it is overcomplicated. I fixated on using the clock's ability to predict bob position.

Martin got in first by asking 'Is it really necessary to synchronise the pendulum with the ref.', at which point my mental model collapsed because the answer is 'NO'.

Proof of the pudding is in the eating. Took me about 10 hours cursing to write and debug the code for my complicated approach that only set the clock with 0.025s. Abandoning that, the alternative took under 10 minutes to write and test - it's much simpler.

What it does now is:

• On receiving a set-clock command, the raspberryPi spins as before to get just past the next whole NTP second.
• The second value is sent as a UNIX timestamp to my clock, with microseconds zeroed.
• My clock loads the timestamp into the counter
• On the next beat, the counter is incremented by one period, and the result, also a UNIX timestamp, is sent back to the raspberry
• The raspberry calculates the difference between my clock's time stamp and NTP time. The difference is sent back to my clock which applies it as a correction to the counter.

Needs more work because the protocol makes no allowance for transmission and processing delays. I'm going to write code to test these further: the exchange over USB serial takes about 0.0002s, which can be compensated out, but I don't know how much the exchange time varies. It's not an exact constant.

Michael's got me thinking about sub-second accuracy. Hopefully the rebuild will improve my frisky pendulum - i's not supposed to be all of a twitch! Assuming I can get it to swing reliably, I plan to use the pendulum's compensated period to set a counter timer to generate a 1s NTP aligned pulse at the next second point. Say the clock ticks and increments the clock's counter to a value like 1679653264.750020 . That means the Arduino has to output a seconds pulse 0.24998s later. I propose to do that with another counter/timer, setting it with numbers in which the Arduino's oscillator frequency is calculated from the pendulum. Not sure how accurately it's possible to set the counter to multi-digit delays like 0.24998s. As the counter is binary, the worst case error might be horrible. If the method works at all, should be possible to generate 0.1s pulses in the same way.

Dave

No idea how good/bad the chip is … but I thought I would mention this, just advertised by the PiHut

**LINK**

https://thepihut.com/products/pi-rtc-ds1307

Very reasonably priced, and could come in handy

MichaelG.

.

Edit: data-sheet for the DS1307 chip

https://www.mouser.co.uk/datasheet/2/256/DS1307-99500.pdf 

Edited By Michael Gilligan on 24/03/2023 17:31:33

It's about as accurate as a domestic quartz clock, so not bad. However, for a bit more money, modules using the DS3231 are 2ppm. A notch more accurate because the crystal is embedded inside the chip and is temperature compensated. About 3x the price of a 1307, Pi Hut sell them too.

Something I've been thinking about:

An "invertible" pendulum that has the same period hung either way (see my "precision gravity pendulum" project) has its centers of oscillation right at its pivots. This configuration should therefore result in a minimum of motion of the support structure and hence less energy loss, etc.

Achieving that balance is fairly easy to within say 0.1%, as long as you are willing to tune the pendulum's basic parameters. In the end, it wouldn't have to actually be invertible, it would just have to be balanced as such.

It may be worth considering, especially for attempts that would benefit from higher Q.

Edited By S K on 25/03/2023 00:38:49

I'm not sure why the lateral force at the pivot should be minimised by doing this?

.

Maybe worth considering how the two versions would behave on a wheel-balancing machine at your favourite tyre depot.

MichaelG.

If the invertable pendulum has an effective length l equal to the distance between the pivots then is it not effectively identical to a pendulum of mass m at length l. Why then would you say that the centre of oscillation is at the pivot.?

Certainly the centre of mass isn’t.
Regards Martin

PS I thought the point of it was to make the measurement of l easy so as to measure local gravity.

Edited By Martin Kyte on 25/03/2023 12:46:39

Edited By Martin Kyte on 25/03/2023 12:48:52

I was in error - not sure what I was thinking.

There is at least one configuration that does have zero influence on the stand: a type of pendulum with an infinite period. But that's not very practical for a clock.

Edited By S K on 25/03/2023 17:05:36

I don't think there has been any mention of humidity, perhaps ignored because bad weather goes along with low pressure, but does anyone try to seal their case and put desiccant into it? Perhaps the effect is too small to matter.

Don’t sweat it I jump to false conclusions all the time but then those who never dream up daft ideas never come up with anything new. The trick is identifying the daft idea with a spark of brilliance in it. Realising why a daft idea is daft is useful too. Viva le daft idea. (Nothing to do with Vauxhalls)

regards Martin

Duncan Webster was going to try and calculate how much humidity changes air density. Might cause an error by altering the bob's buoyancy. He's not reported back, so maybe the maths is horrible. None of my books worry about humidity, but they all agree removing air is a good thing.

Wooden pendulum rods are sometimes used because they don't change length much with temperature. Although wood is humidity sensitive, I've not seen it mentioned directly, through Grimthorpe recommends keeping church tower pendulums well ventilated, not boxed in.

When I used carbon-fibre as a combined spring/pendulum, it was markedly sensitive to humidity. However, the effect disappeared when I fitted a steel spring. I'm pretty sure humidity affected the spring of the plastic matrix, but not the length of the rod, which is controlled by the carbon fibre innards. Same might happen to wooden-rods, which run with the grain, where humidity might alter diameter much more than length. Changing the diameter of a pendulum rod wouldn't make much difference to the period.

As far as I know, what humidity does to pendula is still mysterious, but any effect on metal rods must be tiny.

Dave