Experimental Pendulum Clock

[Michael GilliganParticipant @michaelgilligan61133]

Posted by duncan webster on 18/12/2022 11:56:56:

.

As requested, not carping

.

… and not even discussing, now that I’ve done the searching for you.

Oh well

MichaelG.

[John HaineParticipant @johnhaine32865]

Well I've had a go, using 3 Nanos, two implementing PPS generators with very slightly tweakable frequency and the third a modified version of the phase detector. Main mod is to Serial.print rather than using SPI to a Mega as I don't have one! What does "Tester()" do? So far I can't get sensible results so will have to shelve it for a few days – oh and them it's Christmas…!

[duncan webster 1Participant @duncanwebster1]

Instead of the GPS thingy, could one use the 1 second pulse from MSF (the ex Rugby time signal)

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 18/12/2022 17:02:26:

Well I've had a go, using 3 Nanos, two implementing PPS generators with very slightly tweakable frequency and the third a modified version of the phase detector. Main mod is to Serial.print rather than using SPI to a Mega as I don't have one! What does "Tester()" do? So far I can't get sensible results so will have to shelve it for a few days – oh and them it's Christmas…!

After an interruption I'm back on the case. There are some issues with the code as downloaded from github.

1. The Nano doesn't use SPI, so there's no need for the two #include statements or wire,begin() in setup(). Doesn't effect operation.
2. setup() declares the interrupt pins as INPUT, which isn't necessary. Doesn't effect operation.
3. sendToMega() uses a buffer, ltoa(), and Serial.write twice when the same could be achieved more easily with Serial.print(). Doesn't effect operation.
4. sendToMega() doesn't end the data with a newline, causing each number pair to concatenate. I don't know how the Mega decodes this, but delimiting with a newline is easier to parse when debugging.
5. sendToMega() is called from inside PPS_trigger(), which is an Interrupt Service Routine. This is bad practice because ISR functions should do minimum work to reduce the risk of itself being interrupted. Safer to set a flag causing sendToMega() to be called in loop(). Instead the calling function turns interrupts off whilst sendToMega() is running. This might cause problems, but the PPS interrupt is only called once per second.
6. loop() calls tester(), which should be commented out. tester() simulates a 1 second pendulum pulse in software so that the code can be tested without a pendulum or signal generator. Not noticing tester() was being called may have caused my strange numbers.

After commenting out tester() the program produces no output at all. For some reason

attachInterrupt(digitalPinToInterrupt(Pen_sw), Pendulum_rise, RISING);

isn't working, Pendulum_rise() is never called.

I'm not sure it's possible on a Nano to attach two different functions to the same pin at the same time. I think the second attach overwrites the first. In the past I've written a single ISR to process both rising and falling. It's attached as CHANGE, and starts by reading the pin (which has to be declared as pinMode INPUT). If the pin is HIGH, the interrupt was RISING, if LOW it's FALLING.

Dave

[Michael GilliganParticipant @michaelgilligan61133]

Permit me to say, Dave [ et al ]

I am very impressed, and way out of my depth, observing this discussion.

MichaelG.

[Martin KyteParticipant @martinkyte99762]

Posted by SillyOldDuffer on 18/12/2022 19:40:18:

Posted by John Haine on 18/12/2022 17:02:26:

Well I've had a go, using 3 Nanos, two implementing PPS generators with very slightly tweakable frequency and the third a modified version of the phase detector. Main mod is to Serial.print rather than using SPI to a Mega as I don't have one! What does "Tester()" do? So far I can't get sensible results so will have to shelve it for a few days – oh and them it's Christmas…!

After an interruption I'm back on the case. There are some issues with the code as downloaded from github.

1. The Nano doesn't use SPI, so there's no need for the two #include statements or wire,begin() in setup(). Doesn't effect operation.
2. setup() declares the interrupt pins as INPUT, which isn't necessary. Doesn't effect operation.
3. sendToMega() uses a buffer, ltoa(), and Serial.write twice when the same could be achieved more easily with Serial.print(). Doesn't effect operation.
4. sendToMega() doesn't end the data with a newline, causing each number pair to concatenate. I don't know how the Mega decodes this, but delimiting with a newline is easier to parse when debugging.
5. sendToMega() is called from inside PPS_trigger(), which is an Interrupt Service Routine. This is bad practice because ISR functions should do minimum work to reduce the risk of itself being interrupted. Safer to set a flag causing sendToMega() to be called in loop(). Instead the calling function turns interrupts off whilst sendToMega() is running. This might cause problems, but the PPS interrupt is only called once per second.
6. loop() calls tester(), which should be commented out. tester() simulates a 1 second pendulum pulse in software so that the code can be tested without a pendulum or signal generator. Not noticing tester() was being called may have caused my strange numbers.

After commenting out tester() the program produces no output at all. For some reason

attachInterrupt(digitalPinToInterrupt(Pen_sw), Pendulum_rise, RISING);

isn't working, Pendulum_rise() is never called.

I'm not sure it's possible on a Nano to attach two different functions to the same pin at the same time. I think the second attach overwrites the first. In the past I've written a single ISR to process both rising and falling. It's attached as CHANGE, and starts by reading the pin (which has to be declared as pinMode INPUT). If the pin is HIGH, the interrupt was RISING, if LOW it's FALLING.

Dave

I'm not sure it's possible on a Nano to attach two different functions to the same pin at the same time. I think the second attach overwrites the first. In the past I've written a single ISR to process both rising and falling. It's attached as CHANGE, and starts by reading the pin (which has to be declared as pinMode INPUT). If the pin is HIGH, the interrupt was RISING, if LOW it's FALLING.

I have no doubt you are correct to assume you cannot attach two different functions to the same pin. On the ATmega328 the External Interrupts 0 and 1 act asychronously to set two independent flags, have separate interrupt vectors and are configured exclusively either rising/falling edge or logic low level. The interrupt on change function is synchronous and can take up to 4 clock cycles to set the relevant interrupt flag. The interrupt vectors for interrupt on change are different to the asynchronous vectors. I have no idea how the compiler for the nano handles things but on a hardware level External Interrupt Pins cannot be set to both a falling and a rising edge at the same time. So yes you have to use Pin Change Interrupts to detect rising and falling edges.

regards Martin

[John HaineParticipant @johnhaine32865]

I raised this question over on the Arduino forum and it seems that, no, you can't have 2 ISRs attached to the same pin! You would need either to use Dave's pin change interrupt or do an attachInterrupt in the ISR to attach the other one – messy!!

Looking at this and other issues in the posted code I wonder if this is an early version that hasn't been updated?

[Martin KyteParticipant @martinkyte99762]

It's not quite that you cannot attach two ISR's but cannot physically configure the hardware to do two jobs. There will be in the case of rising or falling edge anexclusive OR feeding the clock of a D Type Latch with the Rising/Falling Bit setting the function on one Pin of the XOR and the Pin input on the other. Detecting the Low state will be feeding the Pi signal to the Preset depeddent on that fuction bit being enabled. Whatever function is enabled creates an interrupt to the same vector. Reconfiguring within the ISR could be done but as you say it's messy.

regards Martin

[John HaineParticipant @johnhaine32865]

Thanks for the clarification Martin.

On the whole given that the code as published doesn't seem to work and has some errors, and if it did I don't think it will handle asynchronous pendulums (important for anyone whose clock doesn't use a seconds pendulum by accident or design), I don't feel inclined to spend any more time investigating the method. I may raise the issues with the authors if they ever reply to my email. Dave and Martin, many thanks for your input.

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 19/12/2022 14:26:47:

Thanks for the clarification Martin.

On the whole given that the code as published doesn't seem to work and has some errors, and if it did I don't think it will handle asynchronous pendulums (important for anyone whose clock doesn't use a seconds pendulum by accident or design), I don't feel inclined to spend any more time investigating the method. I may raise the issues with the authors if they ever reply to my email. Dave and Martin, many thanks for your input.

Thanks to Martin & John for confirming it's not possible to connect two different ISRs to the same pin at the same time. Switching interrupt type in an ISR is allowed, I agree messy. Another way on the bigger AVR chips to strap two external interrupt pins together and make one RISING and the other FALLING. Not enough pins on a Nano so last night I combined Chronova's two functions into one, and call it on CHANGE. Program produces output, but I don't know if it's right.

I think the code on github is a development version, not the final product, as John suggests. For example, looks like their debounce code has a bit missing. The code works on clean pulses, but it wouldn't debounce a dirty pulse.

Buglets aside, whether or not the logic correctly deals with John's scenario remains unproven.

Well worth looking at though – they've given me some useful ideas.

Not going well on my own project. I want to box up the OCXO properly and need a power supply and a divider IC. No problem with the PSU, I have loads of 7805 stabiliser chips, except they're all 7812. I've already had to order a new divider chip because the one I have is old-fashioned CMOS that barely does 10MHz even if extra volts are provided. Seems every time I need something my massive stock of electronic bits fails to provide. It won't be finished until after xmas now.

So, I've switched to making some software improvements, notably so that the analyser can work with either GPS or an OCXO or a DS3231 RTC (another awol part!) Good news, my workshop has warmed up so I could make the planned new suspension.

Dave

[John HaineParticipant @johnhaine32865]

Dave, if you have any PICs Tom's picDIV code is on his website. There's a version that does 1 PPS from 10 MHz.

[John Doe 2Participant @johndoe2]

I realise this is not the point of your investigations at all, and I applaud your curiosity and endeavours; but if you are using GPS or whatever reference, and micro controllers running at n MHz, and an IR beam etc. to detect and correct minute pendulum errors……….why not just feed the reference pulses into the clock, and not bother with a pendulum?

Clock makers used pendulums because they were the most accurate counters at the time. But they were only accurate to within minutes or seconds per day or week, and now of course, we have far more accurate and consistent crystal oscillators and "atomic" clocks.

Regarding pendulum suspension; what about a magnetic levitating bearing? Would that be able to hold a pendulum pivot point accurately enough?

Secondly, what about engineering a way of physically changing the length of the pendulum to adjust for average swing changes? That would give you accurate time keeping over, say a 24 hr period, rather than trying to correct for every discrete swing?

Just thinking aloud. 

.

Edited By John Doe 2 on 20/12/2022 11:12:23

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Doe 2 on 20/12/2022 11:11:27:

I realise this is not the point of your investigations at all, and I applaud your curiosity and endeavours; but if you are using GPS or whatever reference, and micro controllers running at n MHz, and an IR beam etc. to detect and correct minute pendulum errors……….why not just feed the reference pulses into the clock, and not bother with a pendulum?

Clock makers used pendulums because they were the most accurate counters at the time. But they were only accurate to within minutes or seconds per day or week, and now of course, we have far more accurate and consistent crystal oscillators and "atomic" clocks.

Regarding pendulum suspension; what about a magnetic levitating bearing? Would that be able to hold a pendulum pivot point accurately enough?

Secondly, what about engineering a way of physically changing the length of the pendulum to adjust for average swing changes? That would give you accurate time keeping over, say a 24 hr period, rather than trying to correct for every discrete swing?

Just thinking aloud.

…

Ah, John beware! You're being sucked into the fascinating world of time-keeping!

My downfall started with an Arduino software project, intended to measure mechanical pendulum clocks as a way of detecting mechanical faults. There are at least two commercial products that do this, but I had in mind a MEW article allowing an amateur clockie to build one. As Grandfather Clocks aren't portable, the idea was that the tester would be plonked next to the pendulum and do it's stuff based on comparing what the pendulum did with an ultra-accurate source, which was GPS. Didn't work out because a really good GPS signal is needed, and this is only possible in my house close to a south facing window. The MSF radio signal isn't reliable enough here either.

The tester worked well on my dining table where I'd set up a crude pendulum on a Meccano frame. I was surprised at how well it worked, which led me to wonder how good a pendulum clock I could make using modern techniques. Is it possible to replicate the extraordinary performance of a 1921 Shortt Clock, using 21st century techniques? I'm not trying to build an accurate timepiece, I'm exploring how good a result I can get with novel methods.

John, Duncan and others have all built successful electronic pendulum clocks based on 'best practice'. I'm trying something different: for example my clock is much smaller and less rigid than conventional. Results are promising, but the effort has led me into all sorts of interesting byways and complications! The subject is far from simple, and it gets more difficult with each improvement.

Dave

[duncan webster 1Participant @duncanwebster1]

Posted by John Doe 2 on 20/12/2022 11:11:27:

…..

Clock makers used pendulums because they were the most accurate counters at the time. But they were only accurate to within minutes or seconds per day or week, ……..

Secondly, what about engineering a way of physically changing the length of the pendulum to adjust for average swing changes? That would give you accurate time keeping over, say a 24 hr period, rather than trying to correct for every discrete swing?

Just thinking aloud.

.

Edited By John Doe 2 on 20/12/2022 11:12:23

Hmmm. Shortt clock was better than 1 second per year, Fedchenko was 0.2 ms/day, which is 1 second in 500 days. I haven't found figures for the Reifler, but it must have been pretty good, it was used as a standard in the USA until replaced by a Shortt.

0.2 ms/day is one part in 432,000. To get this change in period by altering the length of a 1 second pendulum you'd need to change its length by 1 part in 216,000. This is 0.0046 mm. A pretty tall order, which is why they added little weights to a heavy bob.

[duncan webster 1Participant @duncanwebster1]

Got my zeros wrong, 0.2 ms/day is 1 part in 432,000,000. I'd love to know how they measured this without an even more accurate clock.

[Martin KyteParticipant @martinkyte99762]

Posted by duncan webster on 21/12/2022 09:25:13:

Got my zeros wrong, 0.2 ms/day is 1 part in 432,000,000. I'd love to know how they measured this without an even more accurate clock.

I guess it's from long term tests, if you measure over six months or a year you end up with an error you can measure from astronomical observations. It could be that some of the figures quoted were obtained afetr the advent of atomic time keeping to find out what was actually achieved in the past. Harrison used a mix of astronomical observations and the use of several clocks measuring variations between them and gradually bringing them to agree (or keep step) over a long period of time. A bit, but not entirely like, the 3 surface plate meathod for flatness.

It's an interesting question.

I feel that the gold standard for mechanical clock would be to be able to detect the tidal variations which I understand needs a variation of no more than 3mS a day. Tidal errors account for about 8mS variation but are usually lost in the noise for any but the best timepieces.

I may go back and read up on Harrisons testing techniques, I'm sure I have forgotten much of the detail.

regards Martin

[John HaineParticipant @johnhaine32865]

Posted by Martin Kyte on 21/12/2022 09:56:28:

…….

I feel that the gold standard for mechanical clock would be to be able to detect the tidal variations which I understand needs a variation of no more than 3mS a day. Tidal errors account for about 8mS variation but are usually lost in the noise for any but the best timepieces.

I may go back and read up on Harrisons testing techniques, I'm sure I have forgotten much of the detail.

regards Martin

See this link for lots of info on clocks & tides:

http://leapsecond.com/hsn2006/

Shortt pendulums have been tested against atomic clocks using an electronic system to replace the Synchronome part, and post-analysis of the data showed that they could measure tidal effects.

[John HaineParticipant @johnhaine32865]

Posted by John Doe 2 on 20/12/2022 11:11:27:

Just thinking aloud.

.

Edited By John Doe 2 on 20/12/2022 11:12:23

"I realise this is not the point of your investigations at all, and I applaud your curiosity and endeavours; but if you are using GPS or whatever reference, and micro controllers running at n MHz, and an IR beam etc. to detect and correct minute pendulum errors……….why not just feed the reference pulses into the clock, and not bother with a pendulum?" – ah, that's the difference between a time nut and a pendulum nut!

"Regarding pendulum suspension; what about a magnetic levitating bearing? Would that be able to hold a pendulum pivot point accurately enough?" – Actually not much energy is lost in bending the spring, except perhaps at low amplitudes where air resistance has diminished. I did look at the magnetic possibility some years back – the problem is that you need a bearing that constrains the pendulum in all but the wanted direction of movement, and that isn't possible (I think) with permanent magnets – "Earnshaw's Theorem". All practical mag bearings have an active system that consumes energy to stabilise them, which would probably take a lot more energy than every other part of the clock! Bob Holmstrom in the US reported some experiments using an air bearing which IIRC performed well but of course needs a compressed air supply.

"Secondly, what about engineering a way of physically changing the length of the pendulum to adjust for average swing changes? That would give you accurate time keeping over, say a 24 hr period, rather than trying to correct for every discrete swing?" That is in effect exactly what Robertson did in his clock (see above), using adjustable tension in a spiral spring to apply a variable force acting against gravity, through a cunning linkage. Performance was limited because there was only one 10.00am reference pulse available at the time (1925), by telegraph from Greenwich, and the resulting "sampling rate" of his control loop was too low to follow barometric variations. It would be interesting to recreate his method now we have accurate time from GPS at least every second.

[John Doe 2Participant @johndoe2]

Posted by SillyOldDuffer on 20/12/2022 12:33:32

Ah, John beware! You're being sucked into the fascinating world of time-keeping!

My downfall started with an Arduino software project, intended to measure mechanical pendulum clocks as a way of detecting mechanical faults. There are at least two commercial products that do this, but I had in mind a MEW article allowing an amateur clockie to build one. As Grandfather Clocks aren't portable, the idea was that the tester would be plonked next to the pendulum and do it's stuff based on comparing what the pendulum did with an ultra-accurate source, which was GPS. Didn't work out……..

Ah right, I see.

Someone I once knew had a hand-held device to measure the time period of clock pendulums on domestic and church clocks, a device which presumably used an internal crystal oscillator reference, (and which did not need ultra accuracy).

If you are having trouble with GPS satellites, my approach might be to make an external receiving aerial to plug into your GPS device. The aerial could be clipped to a window or placed outside somewhere?

Edited By John Doe 2 on 21/12/2022 12:27:47

[SillyOldDufferModerator @sillyoldduffer]

Today's clock results are encouraging, but there's a new mystery!

The clock was adjusted to count 'nominal' on the previous run's average period, and I reduced the impulse again. The bob now gets kicked 80% of the time, which reduces circular error.

Result – after nearly 42 hours the clock, still uncompensated, is wrong by -0.174s:

ClockRun = 1 day, 17:45:16.825680 (150316.82568s)
ActualRun = 1 day, 17:45:17 (150317.0s)
Difference = -0.174s -0.000116% (-1.2ppm)
Nominal period vs Actual Error=-0.000121%

Tick Data
Nominal=823320us Real=0:00:00.823321s Mean=0.823321

However, I've added a new graph showing how the clock drifts relative to NTP time, which shows it's wandering!

So, the clock might be only -0.174s slow at the moment, but it slowed steadily for the first 100,000 beats down to -3.5s, not good, and then covered up the error by picking up speed again. Be interesting to see what it does next. I was going to tweak the impulse amplitude threshold, and reduce the impulse slightly, but I won't disturb it.

Whilst waiting for components to arrive, I've decided to improve how the clock is measured. At present, period is measured by a hardware counter; it's how many 16MHz crystal pulses are counted between events caused by the bob breaking the IR beam. This OK except Arduino crystals aren't particularly stable. The existing arrangement mixes pendulum temperature effects with temperature effecting the crystal, which could confuse the results.

So I've decided to upgrade from an Arduino Leonardo to an Arduino ATmega 2560. The 2560 has more hardware counters, making it possible to measure the crystal with GPS as well as the pendulum with the crystal. Knowing the crystals actual frequency eliminates temperature effects and significantly improves accuracy of pendulum measurements.

The upgraded set-up will be this:

Another potential improvement is to upgrade the Raspberry Pi3B to be an NTP Stratum 1 server. These use GPS second pulses to correct NTP.

Dave

[Martin KyteParticipant @martinkyte99762]

Perhaps a daft question but I suppose you have compared GPS to NTP and established that there is no drift between the two have you.?

regards Martin

[duncan webster 1Participant @duncanwebster1]

SOD's latest wheeze just blows my mind!

To return to temperature/density issues, I've remembered that quartz tube has a very low temperature coeff, and found that it is available up to 150mm diameter, so one could isolate a pendulum from ambient variations and still see it working. Slight snag is that it is very expensive.

[Peter Cook 6Participant @petercook6]

Dave, for your next project. Now that you have a highly accurate GPS reference signal, and a switching mechanism to deliver a power pulse to the pendulum, rather than complex (PID) math to adjust the pulse timing have you considered using the lack of isochronism in the pendulum as an inherent feedback mechanism.

I assume the pendulum characteristics are such that as the power increases, the amplitude increases, and the rate slows (slightly).

The diagram illustrates the idea in a somewhat exaggerated form. The top line is the highly accurate signal used to deliver a square wave pulse exactly at the pendulum’s ideal rate.

The next three lines show the drive pulses from your sensing/switching mechanism under various scenarios.

A illustrates the ideal position. On each swing, the reference signal goes high before the switching mechanism applies power to the pendulum. The switching mechanism then activates and applies power which is turned off by the reference signal going low. The red area represents the power supplied.

B is the situation when the clock gets a little slow. The pendulum switching will occur slightly later relative to the reference signal. That results in a lower power delivery to the pendulum. Therefore, the amplitude decreases, and the clock speeds up a bit. The feedback continues to increase the rate until we get back to A.

C illustrates the clock gaining slightly. The pendulum switching then occurs slightly earlier relative to the reference signal. The power delivered increases, as does the amplitude and the clock slows down again until position A is re-established.

If it all works as it should, the pendulum rate will inherently lock to the falling edge of the reference signal*.

This is the mechanism, based on an idea from Derek Roberts, which Bryan Mumford developed into his Governor product for Eureka, Bulle and other antique battery clocks. Frank Roetsky makes a similar device.

PS* If the pendulum characteristic is the other way round  – increased power increases the rate, and Bryan suggests there are  Eurekas that do this, then the mechanism still works except the the pendulum locks to the rising edge of the reference signal.

The method does work well. I have one of Bryan’s units and one of Frank’s on a couple of Eureka clocks and both keep time to within seconds per year.

 

Edited By Peter Cook 6 on 22/12/2022 12:39:04

[SillyOldDufferModerator @sillyoldduffer]

Posted by Martin Kyte on 21/12/2022 13:28:24:

Perhaps a daft question but I suppose you have compared GPS to NTP and established that there is no drift between the two have you.?

regards Martin

I haven't because – assuming I've understood correctly, always a big if – the two are closely related.

Both are based on the World Time Standard, which is the average of a group of high-end Atomic Clocks.

GPS satellites also contain Atomic Clocks, each of which is synchronised by a ground station, with due allowance for transmission and update time.

With an open sky the GPS receiver sees about 20 satellites, of which perhaps 15 provide clear solid signals. Which 15 or so varies with the earths rotation. The receiver gets time signals from all the good satellites it can, and uses a built-in ephemeris to compensate for each satellites space to receive position distance. After earth time is recovered, the time differences to each satellite allow the ground station to calculate it's latitude, longitude and height. Considerable effort is put into GPS time accuracy because positional accuracy depends on it. A GPS receiver with a good view of the sky is the best source of time available, but it works in 1 second increments. GPS second pips are synchronised to earth standard Atomic time within a few nanoseconds.

Network Time Protocol depends on time stamp signals distributed hierarchically across the internet by computers. Network delays vary somewhat and they get worse with distance. Although NTP compensates in various ways, the accuracy at a particular point varies. Worst case, NTP is never more than 100mS out, and most ordinary users are within 10mS. An individual computer won't get the best out of NTP unless set up to do so because the operating system runs on an internal clock, which is only periodically corrected to NTP. Microsoft time is paricularly poor because Windows checks NTP infrequently. Check your computers time here. My Ubuntu machine is 5mS fast at the moment.

The key advantage of NTP is self-correcting accuracy over long periods that just works with no need for special equipment. At worst it's "good enough" for most purposes.

The best way of improving NTP time is to get close to a server connected to a standard Atomic Clock. More practical, and nearly as good, is to set up your own NTP server receiving ordinary network time, and synchronise it to GPS seconds. Synchronising eliminates most of the error caused by network delays.

So NTP is always a bit wrong compared with GPS, but they don't drift apart. Unlike my clock, which is up to no good:

Ran slow for 100000 ticks, since when it's been running fast, and the rate is getting worse, cause unknown. I've decided to let it run for a few days to see what it does next in hope of identifying the issue.

Dave

[duncan webster 1Participant @duncanwebster1]

Here's a link to the Mumford Governor

I'd better say no more

[Author]

Posts