Improved Experimental Pendulum

You could connect a large reservoir, like an old gas cylinder, to make the volume larger. It could be 30 ft away just as far as you can get a single copper pipe without joints.

Good idea, though I am trying to keep the clock small!

This morning's results are disappointing - looks like drift correction isn't working, possible because I 'improved' the code. The slope after correction last night is much the same.

The sharp drop down to zero before midnight is me resetting the clock to UTC. The 1 second leap this morning, right of graph, was due to cat jumping on the table. Cats and clocks aren't a happy combination.

Dave

My dining table being a poor platform, I moved the clock to a solid window-sill and have left it running to see how it performs undisturbed.

Meanwhile, I thought it would be useful to test the clock's software and measurement system with a perfect pendulum. The closest I can get to perfect pendulum is extremely good - it's the seconds pulse output of a GPS module, accurate within about 45nS.

I connected GPS pulses to my clock's pendulum input to see:

• how stable the microcontroller's ceramic resonator is, not expecting much.
• how well the clock beaten with a perfect pendulum keeps time compared with NTP.
• how much the transfer time over USB from clock to Raspberry Pi varies.

Stability of the ceramic resonator is poor, varying by about 38 microseconds over 13 hours. Most of the swing is due to temperature change, but stability between cycles is also poor, varying by about 1.23 microseconds on each beat. The nominal frequency of the resonator is 16MHz, its mean frequency in this run was 15.982708MHz

The weak performance of the resonator also shows up in the dispersion graph below. The graph should be a bell curve symmetric about the mean, and it's mangled. As the GPS pulse is near perfect, the mangling is caused by the resonator mismeasuring it, rather like checking gauge blocks with a 6" rule.

In this run the clock finished at 2023-05-08 13:19:00.0 whilst NTP reported 2023-05-08 13:19:00.031074, an error of 31.1mS Actually better than that because the synchronisation error (setting the Clock to NTP) was wrong by 0.030496s, making the actual error at the end of 578 microseconds.

However, graphing clock against NTP shows NTP bounces about!

Although NTP is never more than 30mS wrong, and is mostly closer, the graph shows each measurement varies by about 2.5mS. Part of the jitter is due to variations in transfer time - how long it takes the clock to resister a beat, assemble logging data, put the data on the line, and then for the Raspberry Pi to receive, decode and timestamp the data. More work needed, but transfer time appears to be fairly constant.

In short, although the clock and measurement system both work correctly, hurrah, feeding them a near perfect pendulum shows plenty of room for improvement! If my pendulum runs really well in a vacuum, I may find the measurement system needs to be updated. Fairly obvious steps include GPS disciplining NTP on the Raspberry Pi, and registering beats by signalling the event from clock to Raspberry with IO pins rather than USB serial.

Every step forward is harder to make, and the project is endless...

Dave

Edited By SillyOldDuffer on 08/05/2023 16:27:42

I take it you get NTP over the internet. is that cable modem, landline or mobile? You might like to run a parallel ping test to see how that is varying with your NTP data. The internet was never designed to send time critical data and is only kept vaguely in line because gamers whine so much about ping times,

edit - you could also mess your head up by comparing NTP from different servers, and mobile v other modem.

Edited By Bazyle on 09/05/2023 00:34:57

Dave, it's beginning to look as if the electronics measuring your clock's performance are possibly less accurate than your clock, making them unfit for purpose.

dave8

Yes, NTP over the internet, a deep subject in itself! How vague internet time is considered to be is relative! It's much better than most clocks.

The protocol works in a hierarchy, where Stratum 0 is a server connected directly to an atomic clock. These update a large number of nearby Stratum 1 servers, which in turn update Stratum 2 servers, which update more distant Stratum 3 servers on the internet. Each level is less accurate than the one above, but the protocol minimises this by constantly exchanging network latency timings to decide which of many servers are currently providing the most accurate time; the system automatically adapts to network performance.

Typically, an NTP time server on the internet available to Joe Public, is better than 10mS of UTC.

Accuracy suffers when connected to an ADSL consumer like me, but should still always be within 100mS of UTC. In my case, a further loss of accuracy occurs because my Raspberry Pi logger is WiFi connected. However, despite that, the results show the Pi's notion of UTC during the test was always within 30mS of GPS UTC. This is better than almost all clocks.

On boot Raspberry Lnux calls pool.ntp.org to get a list of NTP servers in the UK, and then runs an algorithm to select the best (which is usually the geographically nearest). Plenty of choice - there are 193 NTP servers available in the UK this morning. I might do temporarily better by selecting one manually, but allowing the system to adapt automatically does better in the long run. (Unless I happen to be sharing a building with a Stratum 1 server.)

It's possible to connect a GPS module to a Raspberry Pi and synchronise it to GPS UTC. In effect this eliminates network variability by promoting the Pi to Stratum 1-ish level. A GPS synchronised Pi keeps time within about 1mS of UTC. I may have to do this upgrade.

The operating system and how it's configured make a difference too. Bog standard Windows is a worse timekeeper than Linux and MacOS, because Windows corrects the computer's internal clock from NTP less often. Internal clocks are rarely awful, but the best are noticeably worse than a quartz wristwatch. Microsoft letting the clock drift doesn't matter for ordinary purposes, but it does in this application. If I was using Windows I'd reconfigure it to synchronise with NTP more often.

Am I getting the very best from what I have? Very doubtful - keep the suggestions coming!

Dave

Dave, your investigations are fascinating, but I forget now what you are aiming to achieve - a near perfect pendulum, or a near perfect way of measuring a pendulum's performance?

One thought: How do you know if the bob is swinging exactly beneath the suspension? i.e. you have securely fixed the razor blade element at both ends, but how do you measure that the bob is hanging exactly below that point and not held very very slightly off to one side? Ditto, how do you know that the razor blade will flex along a line exactly 90° across and not throw the pendulum bob slightly off to one side?

Do you not need one fixing to the razor blade arranged to allow sideways movement as well as movement in the plane of the pendulum swing? Otherwise the pendulum might be slightly skew, which would affect it's swing? Apologies if this has been mentioned - there are a lot of pages to read through now !

Dave, that you have a highly accurate time check is not in doubt. Surely the concern must be in the ability of the arduino based device to accurately apply the comparison with your clock and it's "wiring"

dave8

Edited By david bennett 8 on 09/05/2023 13:29:58

It is, and one of the reasons for testing the Arduino and Raspberry Pi Logger by feeding the clock with super-accurate GPS pulses was to make sure they stayed closely in step, and to get a feel for how big the variation is.

The experiment put the clock and logger between an ultra-accurate time-source (GPS), and an accurate time-source (NTP), making it possible to quantify the level of variation between the two, a good chunk of which must be due to the Arduino and Pi.

My clock and the Pi logger did well in terms of staying close to NTP UTC, differing by 578 microseconds after 13 hours. 578uS is excellent, an error of 0.00000124% , but I have to keep in mind that the NTP yardstick could be wrong by 30mS, an error up to 50 times worse than my claimed result. Nonetheless, the evidence suggests that the Arduino and Logger introduce a mostly constant error, a small fixed delay between the GPS triggering a tick and the Pi timestamping it. Mostly constant errors can be corrected mathematically by subtracting the average, with whatever jitter is left behind becoming the unfixable noise floor. I don't know what it is yet.

However, I conclude that the Arduino and Pi don't introduce an error bigger than ordinary NTP. Might be different after I lock NTP to GPS, because it increases NTP accuracy by a factor of about 30, and whatever the Arduino is doing becomes a larger proportion of the error sources.

Not worried yet. As my mechanical pendulum is definitely inferior to GPS as a time-source, I'm confident that the Arduino / Pi set-up is good enough to detect my mechanical pendulum errors. However, you're right - there's a point where the Arduino/Pi becomes a limitation, just as NTP already is.

Dave

Both - a pendulum that works well, plus proof that it really is good. The oscillator and measuring it are both difficult at high accuracy. Not difficult to make and measure a clock good to the nearest minute, but getting below 100mS requires effort, 100uS is hard going, and getting down to 100nS nothing but problems. Doing better than 100nS is high-tech.

In my case, with measurement in the milli/microsecond region, there's a lot of tail chasing going on. The measurements show pendulum faults, and then fixing the pendulum reveals bugs in the measurement system. Every improvement reveals there's more to do!

In the end, I'll run out of ideas or be unable to implement them. When that happens, most of the complexity disappears when the measurement system is disconnected, and the clock runs on its own.

In the previous version, I was sure that the bob wasn't hanging straight, and the statistics showed a mass of bad behaviour. In part this was due to the pendulum not flying in a straight line, producing numbers consistent with a twisted spring suspension. I asked for forum advice, and changed the design as a result:

To answer your question, on the top platform the pendulum now hangs from a self-levelling axle - see the Brass work, Silver Steel, and O-ring brakes. Not obvious are considerable improvements in the suspension itself, making sure the spring is held straight, firm, and flexes at a right-angle to the holder in both directions.

The rod is stiffer to reduce whipping, and the bob 5x heavier.

Finally, the heavy cast-iron base is fitted with 3 levelling screws, making it a doddle to level the whole clock. Not shown in the photo, but the screws have locknuts to stop them wobbling against the thread flanks.

Dave

Edited By SillyOldDuffer on 09/05/2023 15:06:14

Very impressive engineering.

Glad you think so John, but I can't honestly claim the credit. I've had enormous help from the forum, on and off-line.

Knowing my limitations, I chose to be open about the design and concepts, inviting comment, criticism and suggestions. The collaboration has been very fruitful. I've enjoyed experimenting, but end result isn't all my own work!

If the prototype proves the concept, I'm sure a competent team could build a better clock on the same principles: more rigidity, improved pendulum, suspension, rod and bob, the electronics are imperfect, the program inefficient, my maths are famously bad, and I doubt my vacuum design will be good enough.

Dave

Have you tried running your own NTP server on your local network..??

This would give a lot less jitter (due to using the greater internet..)

Seems to be fairly easily done on a Raspberry Pi

https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

is just one of many google hits on the subject....

I hope that I haven't sent you down another rabbit hole!!

Alan

A thought on the front-to-back axis. Bob Matthys points out that this may only hang at an angle where the restoring force is just less than the frictional force, which may be slightly off vertical. Ideally one wants viscous friction to damp it. I believe that Bateman's clock actually has the spring clamped in a ground steel bar that just rests on the bracket so there is no damping at all.

On the measurement front, I can't help thinking that a picPET type device would avoid many of the problems at least for analysing short-term motion of the pendulum in fine detail though the OCXO might not be quite on frequency - but at least you can calibrate that out. TVB says that if you run a picPET to measure GPS pulses you can essentially see the Adev of the OCXO.

Its a little surprising to see the online NTP being used as a timing reference. Surely the 60Khz signal from NPL in Cumbria is far more accurate (1 part in 10-12 - more data in Wikipedia)?. The 60Khz signal can be received almost everywhere in the UK and Western Europe., and it is very easy to build a simple receiver with ferrite rod antenna.

Back in the 60's, we built a receiver using a single CMOS Nand gate as a receiver for this signal (The A-series gates could be used in a linear mode, much like an op-amp).

At least it would not be subject to the vagaries of the internet.

Many other countries also operate a similar service.

Not yet Alan, but it's on my list. I have the necessary bits. I judge it to be a rabbit hole at the moment because my clock isn't accurate enough to challenge plain NTP yet. But if the clock improves as I hope, I will need to soup up NTP.

Worth repeating that althoughNTP isn't a good way of measuring individual beats, it is good for measuring pendulum clock performance over days, months, and years. From memory, I think the Shortt-Synchronome managed 8mS per year, compared with my Pi which in theory is always within 100mS, but in practice during the test run was within 30mS. In other words, over a year, NTP on an ordinary Raspberry Pi, is in the same ball-park as the best pendulum clock in the world. Further, synchronising NTP to GPS on the same Pi puts it into the 1mS region, roughly 8 times better than the best a Shortt-Synchronome could do.

I shall be pleased if I can get my clock to stay within 0.1s of UTC on a plain Pi, and ecstatic if the clock is good enough to force me to improve ordinary NTP. Unlikely I fear, but let's see.

As with all measurements, the tool should be about 10x more accurate than the object being measured.

Individual beat times are also interesting, and these are measured with a quartz crystal, which I can calibrate against to GPS once per second. Ordinary 100ppm Crystals are stable enough for indicative measurements down to about 0.1 microseconds, but poor over longer periods - worse than a cheap quartz kitchen clock.

Beyond what I'm up to, time nuttery gets even more exotic. Pendulums were surpassed as time-keepers in the 1930s by various electronic methods, each of which have in turn been surpassed by ever more accurate methods. Electronic oscillators took over from pendulums before pendulum clocks were fully developed, leaving the interesting possibility that an amateur could make a pendulum clock better than a Shortt-Synchronome, Reifler, Fedchenko, or similar high-end precision clock. It's a challenge!

Dave

Edited By SillyOldDuffer on 10/05/2023 11:49:45

Ho hum, another lack of progress report.

Although the pendulum is running well, Q a little under 14000 with low deviation, I've been bedevilled by a series of small software bugs, all due to 'improvements' made by me. They take an age to discover because it's necessary to let the pendulum swing undisturbed for at least 12 hours, ideally longer, to get meaningful statistics.

Each time I check the stats the pendulum is good, but the clock is wrong! The symptom is faulty drift correction, which is annoying because constant drift is the easiest compensation in the book. Trouble started when I switched from compensating in microseconds to compensating in 62.5nS ticks for more resolution (0.0625uS is 16x 1uS). Then I got plus and minus the wrong way round, and today's result shows drift compensation is ignored.

I blame distractions! I was rung up, tired, or rushing to go out every time I tweaked the code. So restarted the clock with compensation OFF to get a clean baseline, whilst I look for software bugs AGAIN.

Meanwhile, the parts needed to plumb the vacuum have all arrived apart from the vacuum gauge and its adaptor. next job is to check what's happened to the order. UK supplier, so I hope it's not stuck on a slow boat from China.

Dave

Dave.

I just came across my copy of Philip Woodward's book, My Own Right Time.

I see that he managed to achieve an accuracy of 1 second in 100 days without enclosing the pendulum in a vacuum chamber. However, what he did find to be important was to blend or radius the edges of the cylindrical bob to reduce air turbulence.

Martin.

Yes, I wasn't pleased to find that my cylindrical bob is worst aerodynamic shape!

I toyed with the idea chamfering it in this build, but didn't because I hope my vacuum plan will work. If if does, not removing metal is an advantage because the weight is helpful.

Bob design is more complicated than I realised, so at this stage I've kept it simple. There's a lot I don't understand. Just for starters, mild-steel isn't the ideal material either. In the event the vacuum idea fails, there are a lot of bob ideas to try. Tungsten, for example!

I did improve the bob over a simple cylinder in this version though. It's now suspended from the rod at its centre point, not at the bottom, and the rod is unconstrained at the top. If the rod lengthens due to warming, the top half of bob expands in the opposite direction, providing partial temperature compensation. Seems OK, I feared it would wobble.

Dave

There's some interesting and maybe pertinant stuff here in an article about Philip Woodward's W5 clock.

Martin.