Arduino Pendulum Clock Design - Comments Welcome

A wild thought, it couldn't be the GPS wobbling could it?

Possibly! The GPS module flashes continually when it loses the number of satellites needed for high-precision time and it just lost sync for about a minute. Could be unreliable because the antenna isn't well positioned - balanced on a window sill next to metal framed double glazing.

Meanwhile Mike's Code is working, ta. Extremely useful because it doesn't work as I expected and it revealed another approach entirely. While Mike reads a device, it's not the simple solution I had in mind. Instead he uses a device interface to an official kernel module, which I didn't know existed. Should be good because the module is designed to improve on NTP by comparing it with an accurate external time source, like a GPS module. One purpose is to let a Pi be used as a Tier 1 NTP Server rather than a bog standard client; quite an improvement.

Collecting data at the moment. I'll graph it when there's a couple of hours in the bag.

Cheers,

Dave

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.

Comparing short and long term pendulum times has already shown an effect I'd bet money applies to most pendulum clocks. It's that many sources of pendulum error tend to cancel out, making it possible for a relatively imperfect clock to keep good long-term time. However, 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. In 2020 can I keep better time with a pendulum than Reifler, Shortt and Fedchenko? (Probably not, but it's interesting!)

Current problem is I want a Raspberry Pi to timestamp pendulum events more accurately than Arduino, which the Pi should do. Unfortunately test comparisons between Pi time and GPS seconds show the Pi to be too erratic for my purposes. Although mostly consistent, Pi time has strange unpredictable variations I don't understand. I'm hoping the error is in my software rather than hardware.

Dave

.

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.

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

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.

.

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.

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.

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

.

.

Keep up the good work, Dave

MichaelG.

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

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

Thanks, Dave ... grabbed it

Definitely one to try

MichaelG.

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

.

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.

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.

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

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