Arduino Pendulum Clock Design – Comments Welcome

[Michael GilliganParticipant @michaelgilligan61133]

Posted by SillyOldDuffer on 06/11/2020 13:48:53:

Posted by Michael Gilligan on 06/11/2020 11:12:30:

I’m probably being thick, Dave … but I have to ask :

Why do you need to check short-term and long-term performance concurrently ?

MichaelG.

Not thick at all, a good question. It's because some, but not all, short-term errors accumulate to influence the rate. Which? By comparing short and long-term I can separate out random fluctuations from systemic changes due to temperature, barometric pressure, or whatever.

[…]

.

Fair comment, Dave

My thinking was that you could concentrate on super-accurate measurement [and counting] of individual swings, and then calculate Standard Deviation to predict likely long-term variability.

Checking the long-term [smoothed average] accuracy is, obviously, a simple matter of checking against the Stars, or whatever reference you choose.

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Trouble at t'mill.

Although there is a problem displaying high precision floating point numbers, it's not causing my timing anomalies. Hope of an easy numeric fix is in the dustbin.

It seems the results are genuine: Linux time is erratic below 1 second. Next graph is drawn with a lograrithmic scale to emphasis small values rather than big ones.

Whilst most time values are concentrated near 1 second resulting in the average being wrong by only 700 nano seconds, the graph shows large numberd of singleton outlier values scattered up to 1mS either side. It means Pi pps time is only trustworthy on average, and – although statistically unlikely – individual timestamps could be 1mS out. That's a lot of error for the type of measurements I'm taking. I don't understand what causes the variations, which bunch together. Possibly the network glitches so NTP is applying delayed corrections intermittently to the master clock.

Letting the Pi measure GPS seconds for 24 hours to see if any clues appear in a long log.

Why is nothing ever easy!

Dave

[Michael GilliganParticipant @michaelgilligan61133]

It’s probably not of any practical help in this project, Dave; but I just came across:

**LINK** https://time.is

It includes some pretty nifty options and customisations

… a UNIX clock displaying milliseconds, etc. etc.

MichaelG.

[Michael GilliganParticipant @michaelgilligan61133]

Posted by SillyOldDuffer on 06/11/2020 13:48:53:

[…]

In 2020 can I keep better time with a pendulum than Reifler, Shortt and Fedchenko? (Probably not, but it's interesting!)

.

I certainly don’t want to discourage you, Dave [you're on a magnificent mission] … but here’s a frightening reality-check:

The best of those Observatory clocks were keeping time to 20 to 30 seconds per year

So, for convenient and convincing demonstration, you are looking at somewhere around 0.4 seconds per week.

MichaelG.

[John HaineParticipant @johnhaine32865]

According to Wikipedia, the Shortt was keeping around a second a year.

[Michael GilliganParticipant @michaelgilligan61133]

Posted by John Haine on 09/11/2020 09:01:02:

According to Wikipedia, the Shortt was keeping around a second a year.

.

… and according to an account contemporaneous with Dave’s date-range:

.

I just wanted to suggest a reasonable ‘stretch target’ for a man who stated:

“ I want to know if my simple carbon fibre swinger is a good time-keeper despite imperfections, or if it's a step beyond what was possible in the 1930's before electronics took over. ”

MichaelG.

[Michael GilliganParticipant @michaelgilligan61133]

Here’s one from Hope-Jones ‘Electrical Timekeeping:

.

.

Keep up the good work, Dave

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Many thanks to John and Michael for providing data on the Shortt clock. Now I know what to aim for!

My experiences with all the advantages of 21st Century technology make me realise just how clever Harrison, Shortt and many others were. For instance, easy for me to log hours of clock data and analyse it with a computer. They must have taken notes for months, drawn conclusions from the data, come up with cunning mechanical corrections, built them into a precise clock and then gathered data for months before finding out if there was any improvement. Amazing.

I did a long run with a Pi3B measuring time against an inexpensive GPS Reference. My GPS module is far more accurate and handy than Shortt's reference provided by painstaking Astronomical observations. I'm able to show the Pi is good, but not excellent, and I think unsuitable for my purposes unless I run the test clock for a year and more. So be it if necessary.

These graphs show good and bad together. Top graph shows the vast majority of Pi seconds are close to GPS, averaging 1.000000385s which is an error of 33mS per day or 12 seconds per year. However, the log shows a difference of over 6mS between maximum and minimum readings, which is enormous when nanosecond accuracy is wanted.Top and centre graphs show the same data, but the centre graph is drawn with a log scale to highlight low readings. A large number of single event outliers suggest individual seconds are unreliable: the Pi isn't good as a reference unless many samples are averaged, say hourly.

The lower graph is upsetting because it shows the pi measuring seconds accurately for hours, but with periods of turbulence when 'seconds' bounce about, apparently unpredictably, cause unknown. Not good.

Now testing a Nucleo F446RE. The clock part was easy but I had trouble getting the BME280 sensor working and persuading the latest version of mbed to print floating point numbers. All working now, and being tested to see how much temperature effects the Nucleo. Nucleo being faster than Arduinos has potential, but I'm not sure it's actually more accurate than an Arduino.

Measuring this simple pendulum clock is more difficult than building it! The Pi diversion was intended to prove the pendulum is better than 1 minute per day, and I still can't prove it without increasing the test runs by a few days. Millisecond accuracy is a doddle, but getting below ±10uS isn't going well.

Dave

[SillyOldDufferModerator @sillyoldduffer]

Long gap since my last report because I've been experimenting with various platforms and software techniques in hope of finding a cheap way of improving the accuracy and precision of my time measurements. My pendulum works a treat, but I got into trouble proving how accurate it is. Or not!

• In the short-term, how much does the period of each swing vary? I can easily measure swings to within about 10µS, but an Arduino can't resolve below 4µS with the technique I was using. And although the same method gets down to about ±2µS on a faster Nucleo microcontroller, it can't resolve below 1µS either. Not good enough – I'm after nanoseconds. A RaspberryPi3B is promising because it's much faster processor and Linux has nanosecond resolution, but not as it turns out nanosecond accuracy. At less than 0.000100s my Raspberry 3B+wobbles more than Arduino and Nucleo, probably because Linux is multitasking, and although I was able to reduce the problem it couldn't be eliminated.
• How well does my pendulum keep time in the long run, over days, weeks, months, years? For that purpose Raspberry is fine. As standard Linux synchronises to UTC over the internet an ordinary installation will always be within 0.1s of actual time. And if the Raspberry is disciplined with a GPS seconds pulse, which is quite easy to do, Raspberry time will be correct within a few tens of microseconds. Shame about the untrustworthy nanoseconds!

So throwing faster computers at the problem didn't work.

John Haine gets credit for pointing me at a better solution. John's used picPet timers for accurate timing. Delightfully cheap and off-the-shelf. The picPet uses a counter/timer as described below, getting good results from a processor distinctly less powerful than a Nano, let alone a Nucleo. Unfortunately, picPet doesn't do the other things I need.

Is the picPet a special timing device? I thought not, and got stuck into programming an Arduino Nano to pull the same trick. Hard at the beginning because I couldn't find any close examples on the web and was led astray by a few that aren't quite right. However, after sweating over the Datasheet, it's straightforward enough. Another 'easy when you know how' jobbie.

The trick is to use the microcontrollers counter/timers to generate timestamps. Counter/Timers are hardware that runs at full clock speed independently (mostly) of the processor and software. So whereas an Arduino CPU and a program can't see below 4µs, its counter/timers clock at about 16MHz, and can count ticks down to 62.5nS, a 40x improvement. Pin 8 is 'special' for this.

Another related feature. Pin 5 can feed the counter/timers with an external clock, such as a TXCO, rather than the system clock. Annoyingly the external clock is speed limited, max 6.4MHz on an Arduino – less resolution.

The code:

Link to source on Dropbox if anyone wants to try it on an Arduino. Tested on a Nano so should be OK on a Uno.

Ought to mention I'm not too happy with the maths. It generates huge integers which are multiplied by a tiny float making rounding errors and overflow likely. Special thanks to anyone suggesting improvements.

A plain Arduino isn't quite fit for purpose because the built-in oscillator is low-quality, either a grotty crystal or a nasty ceramic resonator. I intend to hack a board by fitting a TXCO instead.

Next job is to see if I can code a Nucluo in the same way because it's about 3x faster than an Arduino and the extra resolution would be nice. Another fight with a Datasheet!

Then upgrade my existing clock code to use counter/timer measurement, and back to the statistics. What I really want is a week's worth of high-accuracy measurements, taken from an undisturbed clock.

Slowly slowly catchee monkey1

Dave

[Michael GilliganParticipant @michaelgilligan61133]

Thanks, Dave … grabbed it

Definitely one to try

MichaelG.

[John HaineParticipant @johnhaine32865]

Excellent Dave! Could the maths be avoided by just outputting the huge integers and letting the post processing deal with them?

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 19/11/2020 17:30:23:

Excellent Dave! Could the maths be avoided by just outputting the huge integers and letting the post processing deal with them?

Doh! Certainly could!

Overflow probably isn't a problem if I use long long (64bit) arithmetic to hold the intermediate results

unsigned long on the Arduino is 2^32 (4,294,967,295) and 2^16 * 2^32 is 281474976710656 x 62.5nS ticks which I think is about 35000 years. Except I always get sums wrong!

Dave

[Michael GilliganParticipant @michaelgilligan61133]

Posted by SillyOldDuffer on 19/11/2020 15:37:45:

[…]

Another related feature. Pin 5 can feed the counter/timers with an external clock, such as a TXCO, rather than the system clock. Annoyingly the external clock is speed limited, max 6.4MHz on an Arduino – less resolution.

[…]

.

I’m out of my depth here, Dave … so this is just pondering:

I think I would rather have a very accurate and stable 6.4MHz as a reference, than a less predictable 16MHz

Lower resolution, but smaller uncertainty

MichaelG.

[John HaineParticipant @johnhaine32865]

I'm not sure, but I think it's better to clock the counters synchronously with the processor clock to avoid any relative jitter – this is what the picPET does. It should just mean removing (or not fitting) the 16 MHz crystal/resonator and bringing in a feed from an OCXO or TCXO.

[duncan webster 1Participant @duncanwebster1]

Speaking in complete ignorance, rather than hacking about with the Arduino can't you just use an AVR chip and program it via a pro mini adaptor. You can get them in DIP28 format, and I might have a spare socket somewhere

[SillyOldDufferModerator @sillyoldduffer]

Posted by John Haine on 19/11/2020 20:51:05:

I'm not sure, but I think it's better to clock the counters synchronously with the processor clock to avoid any relative jitter – this is what the picPET does. It should just mean removing (or not fitting) the 16 MHz crystal/resonator and bringing in a feed from an OCXO or TCXO.

I was expecting to clock it Michael's way and was surprised to find the input is cleaned up between input pin and counter and limits the clock rate. Mr Nyquist gets the blame!

Might spoil synchronisation as John suggests too. I don't think so, but the data sheet isn't an easy read. I wouldn't bet on it.

Duncan's quite right about programming chips directly, which would be best approach if a few of these were to be made as per his railway signalling and other big projects. I mess about with prototypes so it's easier for me to bodge ready made modules, or at least I think of doing that first!

Been reading STM timer documentation. Packed with goodies, including a 32 bit counter, and up to 180MHz clocking. Be good if I had an accurate 180MHz precision oscillator, but that's another challenge! On the downside, even harder to understand and John's synchronisation issue is a worry because external inputs are linked to the system clock. It might mean synchronisation is a problem on a Nucleo, or not. I don't understand and will have to experiment.

Dave

[John HaineParticipant @johnhaine32865]

Yes, I think that would be preferred, would save hacking about with an SMD PCB.

[Michael GilliganParticipant @michaelgilligan61133]

Just been having a quick look at crystal oscillators

The oven controlled ones are still pretty pricey, but I was impressed by these two: **LINK**

https://uk.rs-online.com/web/c/passive-components/crystals-oscillators-resonators/tcxo-oscillators/?applied-dimensions=4294490860,4294742312

[At first comparison, the cheaper one appears to be the same thing in a smaller package]

12.8MHz seems a useful starting point if you want 6.4MHz at pin_5

… and the claimed performance looks adequate for checking the behaviour of Dave’s pendulum.

MichaelG.

 

Edited By Michael Gilligan on 20/11/2020 12:28:24

[Michael GilliganParticipant @michaelgilligan61133]

Please permit another digression …

I’ve just been sorting some old reference documents, and found a copy of this [on the construction of an digital Sidereal Clock] from 1987 : **LINK**

http://articles.adsabs.harvard.edu/cgi-bin/nph-iarticle_query?1987JBAA…97..327W&classic=YES

Obviously there are alternative approaches to the construction, but the underlying principle may be of use.

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Posted by Michael Gilligan on 22/11/2020 14:53:39:

Please permit another digression …

…

MichaelG.

Thanks Michael, this note at the end did much for my morale!

Written in 1987 so some things never change. Glad I'm not the only one having trouble with hardware!

Today's report.

I've got a Nucleo64 measuring period using the same Counter/Timer technique as the picPet. Disappointing because the results are very unstable, ±20µS at least:

If picPet was a Spitfire the Nucleo would be a Eurofighter. Nonetheless, the superchip is inferior! Reasons include:

• Although the Nucleo clocks at 180MHz giving pulse resolution down to 0.06nS, it's derived from an ordinary 8MHz crystal. Any timing errors are multiplied by 22.5 (This may explain why the RaspberryPi is also poor in the Nanosecond region. Fine resolution comes from a slightly wobbly crystal oscillator that's been multiplied many times to get speed rather than accurate time.)
• Nucleo counter-timers favour versatility and functionality over straightforward counting. Due to the bells and whistles I'm not convinced input events can be accurately synchronised with the system clock by this chip.
• Rather than manage the complicated control registers directly I used a library, which might add jitter. It could be innocent – I haven't attempted to understand how the library works!
• Nucleo boards are programmed with an adjacent snap-off ST-Link bootloader . It's aother STM-microcontroller set up to appear to the PC as a USB connected folder. Copying an executable image to the folder causes the bootloader to install it on the target STM-microcontroller. Whilst the bootloader CPU is driven by the 8MHz crystal the main CPU is clocked by an ordinary output pin on the bootloader chip. As the bootloader provides an indirect clock the target CPU's timekeeping must be worse than the original crystal. Should be fixable because the main CPU can be fitted with it's own crystal, or a precision oscillator.
• Another possibility is Nucleo counter-timers will accept an external clock running up to 45MHz, which could be a precision oscillator. But if I read the datasheet correctly, the CPU synchronises external clocks with its own clock, which is unstable.

Copy of the program here if anyone's interested. Using it needs the STM32 environment to be installed on the Arduino IDE, and then plugged into a Nucleo64 board: I used an F446RE.

Still got some testing to do, but it appears Nucleo64 isn't good for this particular application. I could be wrong!

Dave

[Michael GilliganParticipant @michaelgilligan61133]

Posted by SillyOldDuffer on 22/11/2020 16:06:11:

[…]

Nucleo counter-timers will accept an external clock running up to 45MHz, which could be a precision oscillator. But if I read the datasheet correctly, the CPU synchronises external clocks with its own clock […]

.

Anything is possible, I suppose … But one would hope that its own clock is synchronised by reference to the external clock.

MichaelG.

[Michael GilliganParticipant @michaelgilligan61133]

Still rootling around for historic performance data … I’ve just found this from 1902

Reifler No.56

**LINK**

http://articles.adsabs.harvard.edu/full/1902AJ…..22..159H

I think the method of fine-adjustment for rate tells us a lot.

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Sorry about the delay. Although I've been busy on this project, the latest phase has been time consuming, with more fussy detail than most forum members would care to know.

Back in November I hit a problem in that my pendulum is more accurate than my ability to measure it. Makes it difficult to prove the ideas I'm testing have any merit. As I'm hoping for better performance than most good pendulum clocks, it's important the measurement be accurate. For the same reason micrometers are calibrated with slip gauges, my clock measurer should 10x better than the clock.

My first attempt with an Arduino Nano used external interrupts and the system clock: I guestimate this to be accurate to about 40 microseconds. John Haine drew my attention to Tom Van Baak's picPet, a precision timer good down to sub-microseconds. picPet uses a hardware timer to count individual oscillator pulses – faster, better precision and much less risk of other activity messing up timings. I wrote a version of this for Arduino, which led to various misadventures as I tried to remove bugs while increasing accuracy and precision. Most difficult was glitches caused when pendulum events coincide with timer overflow and the overflow is missed causing a 4.096mS error. Fixed thanks to Tom! John gave me a pP06 which was invaluable for confirming glitches were due to faulty inputs rather than my bad code. I was very pleased to see picPet and my effort reporting much the same: over 4 hours pP06 averaged a GPS second to be 1.0000007s while I got 0.9999999s.

Thanks to John Haine for putting me in touch with Tom de Baak who is being most helpful.

Testing involved porting my clock measurer from a 16MHz Arduino Nano to a 20MHz Leonardo, and then to a Sparkfun Pro-Micro. Most Arduino's are clocked by wobbly ceramic resonators, but the latter have more stable crystal oscillators albeit not temperature compensated. Improved performance revealed a new problem; faster microcontrollers reacting to jitter on rising and falling edges due to internal reflections.

Now waiting to upgrade to an Arduino Nano Every, a powerful new member of the Arduino clan, which appears easy to clock with an external 20MHz TXCO. The combination should give me about 10 times more stability and reliable tick measurement a shade better than 0.1 microsecond.

Next problem is soldering a 20MHz TXCO. Sub Miniature Devices are ridiculously small: 4 connections on a 1.5×2.0mm box I can barely see. Until now I've avoided them! Not sure how best to approach this job.

Clock now on a long test run. I'm letting it tick until Sunday. 72 hours to glorious victory or humiliating defeat? No idea, but my track record ain't encouraging!

Dave

[Peter BellParticipant @peterbell11509]

Dave, Good to get the report on your clock., that TCXO looks a challenge.

I'm interested in seeing how you get on with the Nano Every. I bought a couple last year but I've never managed to get them to run anything more than Blink.

Just plugged it in to remind me of what the problem is and got a message saying I needed a download into the library for the Every etc. Did this but still no good after configuring boards in tools etc. Gave one to a very knowledgable friend but he gave up as well so I'm looking forward to finding out what I've got wrong when yours works!

Peter

[Adrian Smith 6Participant @adriansmith6]

Hey Dave,

it is good to hear from you again. Hope this works out for you, even though this looks like a challenge.

Regards Adrian

[Author]

Posts