Arduino Pendulum Clock Design - Comments Welcome

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

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

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.

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

.

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

MichaelG.

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.

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.5x2.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

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

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

I'm finding the Every a bit fussy for various reasons!

Although the pin-out is the same as a Nano, the Every has a different microcontroller. Before it can be programmed from the Arduino IDE, it's necessary to install 'Arduino mega AVRBoards' with the IDE's Boards Manager and select Arduino Nano Every from the list.

Once the board is installed it may be necessary to select 'Registers Emulation' to ATMega328 in the Tools menu to get some libraries to work. Other libraries don't work at all. It's because the ATmega4809 microcontroller is different from the ATMega328. I'd expect libraries to start working as their owners gradually bring them up to date.

Otherwise, most ordinary programming works as expected, except where a hardware difference gets in the way. Compared with the basic Nano, the Every has multiple improvements but these may not be useful, and some of them get in the way. Good news, it's faster, has more memory (apart from eprom), all pins handle external interrupts, it has several clock options (speed vs power saving), more serial connections, faster USB, and more timers, which are smarter too. Bad news, not all pins are identical to the Nano, and code that gets down and dirty with the hardware will need modification. This includes my clock program, which uses a Timer and Input Capture.

Another negative, downloading code to the Every is a little fragile, at least on my Ubuntu 20.04. The loader sometimes loses the serial port, making it necessary to unplug the Every and/or restart the IDE to restore order. Seems best to close the Serial Monitor before uploading program changes. (Both claim the same serial port, with a possibility of confusion.)

The loader outputs an alarming message about flash and boot memory that looks nasty but is irrelevant.

So, nice bit of kit, but not 100% compatible, and the differences can be hard to understand. The ordinary Nano is easier to use because everything 'just works'.

Two reasons I want an Every for my clock. The Every makes it straightforward to connect an external 20MHz clock, and I need a good TXCO for stability and accuracy. The ATmega4809's more advanced timers were expected to be an advantage too but it looks like I've blundered. Reading the data sheet (over 500 pages), I can't see how to get a timer set up to do Input Capture Counter to do overflow interrupts as well. One or the other only. Easy on an ordinary Nano, but it appears the ATmega4809's hardware doesn't support that particular combination. Loads of clever counter-timer features I don't want, but not the one simple thing I need. Argh!

Dave

Could be worth a post on the Arduino support forum Dave?

I think I've found a way John. The ATmega4809 has four 16 bit counter/timers, and there's no reason why I shouldn't use two of them for this. I've programmed one to do Input capture, which gets time within a 2^16 clock tick slot. Each tick is 50nS if I can get 20MHz external oscillator working. At the same time a second counter reports when it reaches 65536, which is the same as counter overflow. Seems to work.

Got as far as connecting my signal generator to the chip as an external clock but it didn't work. By the time a 20MHz square wave reaches the end of my connecting coax, it's not square! I need to bite the bullet and solder up an SMD TXCO.

Meanwhile doing some long test runs on the pendulum with mixed results. Keeping time within 0.5s of NTP per day, but the logs contain anomalies. Judging by the regular peaks on this log scale histogram (which amplifies small counts), the pendulum is modulated:

Another interesting possibility from the night before last. Generally Relative Humidity and Temperature track each other closely, and I assumed temperature disturbed the Arduino's oscillator. The Pro-micro I'm using now has a crystal and is less effected by temperature. Sunday night RH changed independent of temperature and it showed up as a correlation. I think my carbon fibre thread is sensitive to humidity. Be good to seal the clock and prove it.

Dave

Edited By SillyOldDuffer on 15/12/2020 18:32:13

Dave, just wondering how you are getting on, especially with soldering down the TCXO? I discovered these when looking at using another SMD device:

https://uk.farnell.com/schmartboard/204-0003-01/ic-adaptor-sc70-soic-sot-to-dip/dp/2483414

I think there are others around too.

Misadventures galore!

Done a series of overnight runs with the clock in a safe place, an unheated bedroom. The purpose was to test the effect of altering impulse size, and to confirm the bob would detect reliably after reducing the power of the IR transmitter. (Problems caused by internal reflections inside the clock.)

According to the logs, reducing impulse improved Q - unlikely! Traced last night to a software bug that meant the impulse size wasn't actually being altered by parameter changes. Bodged a quick fix with this result:

Reducing IR transmit power cleaned up some bonkers results almost certainly due to false triggering due to internal reflections inside the clock. Although fitting a black cardboard shield and painting the PVC pipe blue on the inside helped, the IR sensor module I'm using runs a IR LED flat out - too powerful. Slits would be a good idea too.

A few points of interest;

• Clock is about 1 second fast over 18 hours - worst result ever, even though the standard deviation is better!
• The histogram isn't symmetric.
• There's a mild positive correlation between air pressure and period.

Good news about the microcontroller is it measures OK down to about 0.1uS and using a board fitted with a real crystal has improved temperature stability and reduced jitter. Though the IR sensors need more work I'm confident I'm seeing genuine clock problems rather than computing artefacts.

I've experimented clocking a Nano Every from a signal generator and learned it's not possible to drive a counter timer directly at 20MHz; rather the whole CPU has to be accelerated. It's a little dangerous. Coding the chip to use an external clock risks bricking it if the clock fails so I need to be sure the TXCO is working. Rather than solder one up today, I've been working on another software upgrade. Last nights bodge causes impulses to vary erratically around 2mS and may be jittering the pendulum. Fingers crossed, I can now do it properly!

Here's last night's Allan Deviation. No idea what it means, good or bad!

Can't complain this projects isn't keeping me amused during the lock-down!

Dave

So far my pendulum was only being measured; now I've upgraded it to keep time itself. Time is set by the PC; it reads NTP time until a seconds roll-over is detected and then sets the Duffer Clock to HHMMSS. Thereafter the clock is incremented by the pendulum, one average period per tick.

Of course I couldn't resist tidying up the rest of code, and promptly broke it! Moving the pendulum to test it with the aid of an oscilloscope had an interesting result when it was replaced. I levelled the clock more carefully and got a a dramatic reduction in the amount of power needed to maintain the pendulum at the same amplitude (40%). From 3 to 5 swings per 1.6mS impulse up to about 35 swings per impulse.

This, I suspect, is a design problem. As the rod is its own suspense spring, failure to level the frame must bend the rod, causing impulses from one side to do more work than the other:

A second problem was spotted when the clock was running with the shield off. The IR beam is interrupted by the bob, and internal reflections have already been identified as causing false triggering. I noticed the bob doesn't clear the beam at amplitude 40%, so 'normal operation' must involve a reflection, probably like this:

I'll claim this to be a clever design feature if it works! Otherwise, expect a moderator to revise history by deleting this blunder!

After setting the clock going for another long run, I decided to attempt soldering an SMD TXCO ready for the next stage. Bought four in various frequencies and distinctly remember putting them somewhere safe. Now I can't find them. Argh!

Dave

Edited By SillyOldDuffer on 22/12/2020 21:26:28

This might be worth a look : **LINK**

https://www.researchgate.net/publication/332543537_BUILDING_A_RASPBERRY_PI_ZERO-W_GPS_NETWORK_TIME_SERVER_FOR_UNDER_50

The Author’s credentials are good.

MichaelG.

.

Edit: See also https://lastminuteengineers.com/neo6m-gps-arduino-tutorial/

Edited By Michael Gilligan on 26/12/2020 22:52:04

It is! Thanks, I'll give that a try.

Latest report, over the holiday I've rushed through various changes designed to improve clock monitoring over at least 24 hours. And silly mistakes bit me on the bum every time!

At present, the clock is set up to measure time in three ways:

1. The clock measures each tick internally using the Arduino's 16MHhz crystal oscillator (which will be replaced with a TXCO when I remember where I left it.)
2. The clock outputs HHMMSS.ssssss based on counting ticks, where each tick is assumed to be of average length (as determined from a previous run)
3. Both of the clock's notions of time are compared with UNIX time (set and updated by NTP)

The graphs from last night show a few problems:

The top graph, showing period measured by Arduino crystal, looks fairly stable apart from 4 glitches, until about 9am when the pendulum runs wild eventually stopping at 11:10am. Cause of stoppage unknown, but it may be due to rising temperature, or this morning's bright sunshine confusing the sensor. Zooming in on the period graph shows more trouble in the detail:

This graph shows the pendulum to be stable at first, except it gradually speeds up. Then period settles at about 0.9324s except it bounces ever more wildly until midnight, then gradually calming down until it stabilises somewhat unpredictably at about 5:15. Again, cause unknown.

Zooming in on one of descending glitches shows these are odd too:

It isn't a single event, rather the pendulum speeds up, does about 40 quick ticks, and then returns to the average. I've no idea what would cause a pendulum to do that!

My next problem is mathematical and although I'm sure the answer is easy I've failed utterly to do the algebra.

At the moment, the Arduino calculates HHMMSS by assuming every tick is average, which isn't true. Apart from the wildness noted above, according to the data the pendulum reacts to heat, air pressure and humidity. (Still to be proven, but I'm fairly certain the Arduino responds to heat, not the pendulum.) A little difficult to disentangle the two, but there's strong evidence the pendulum is influenced by both air-pressure and humidity. Higher air pressure reduces the weight of the bob and increases air resistance slightly. To make a rod, carbon-fibres are embedded in a resin matrix and it's likely the matrix is sensitive to humidity.

As the clock knows what temperature, air pressure, and humidity are, I want to correct the average tick by applying a compensating formula. Linear Regression gives the following y = mx + c values:

ticks = x, temp = y : -19.98002063 35.27297589

ticks = x, humidity = y : 52.18719052 16.32451551

ticks = x, pressure = y : 81.65298034 901.6873213

How do you convert a y = mx + c slope into the corresponding correction? For example, given the period of a tick tick at a known temperature, how do you calculate value of tick for any other temperature?

I thought this was easy until I tried to do it . Brain refused to cooperate as soon as I put pencil to paper...

Dave

Edited By SillyOldDuffer on 27/12/2020 14:16:19

Edited By SillyOldDuffer on 27/12/2020 14:18:16

I think you need the multivariate regression coefficients first of all. Then if you assume that the period P is given by something like:

P = P0 + a x temp + b x pressure + c x humidity

then you just subtract the last 3 terms from the measured P to get P0. Excel or R can calculate the multivariate coefficients,

I agree, but baby steps first.

Problem reminder: I'm trying to measure how good or bad my novelty Pendulum Clock is to a high level of accuracy, microseconds or better. The current set-up uses a Sparkfun microPro (much like an Arduino Leonardo) , which - most important - comes with a 16MHz crystal oscillator rather than a cheap wobbly ceramic resonator. But, although considerably better than a resonator, the ordinary quartz crystal isn't temperature compensated. So I'm attempting to detect period variations due to temperature in a carbon fibre pendulum specifically chosen to have a low coefficient of expansion with a reference that's obviously temperature sensitive itself. A hardware cure for this is in the pipeline but I put the components somewhere safe and can't find them now! Hence this post is about temperature compensating the Arduino's crystal in software in hope of moving forward.

By establishing the relationship between frequency and temperature, it's possible to mathematically correct measured timings. But how?

First step is to measure the crystal's frequency over a range of temperatures and collect several hours worth data for analysis. Frequency and temperature are logged together. Next understand the necessary mathematical gymnastics and apply them to the data. The apparatus is:

The inputs measured are high accuracy one second pulses (11nS) from a GPS tracker module. These trip a hardware counter-timer inside the microcontroller that continuously counts pulses directly from the quartz crystal. The snapshot count is accurate to about ⅒ of a microsecond. A 16MHz crystal should output 16000000 pulses each second, but it won't be spot on, and it will drift as temperature changes.

Rather than leave a laptop on all night, the data is logged by a headless raspberryPi which can be left running in a corner for months if necessary. As the raspberry is network connected, the data it collects can be copied at any time to a big computer for independent number crunching.

Results. About 50000 seconds worth of frequency / temperature pairs are presented graphically.

The top two 'mirror image' graphs show there's a clear relationship between temperature and frequency: falling temperature causes the quartz crystal to speed up and a variation of 4°C shifts the crystal by about 30Hz. In this sample the crystal ranged from 15997857Hz to 15997888Hz.

Back to the theory. Assuming the variation is linear, the relationship between temperature and frequency is represented as a straight line graph obeying the standard formula y = mx + c

If the values of 'm' and 'c' are found the frequency of the crystal at any temperature can be predicted, allowing temperature compensation to be applied. In a mechanical clock, compensation is done by carefully selecting and dimensioning suitable materials to alter the length of the pendulum: not easy to design! In an electronic clock no need to change the mechanics because numbers can be corrected by formula. The microcontroller eliminates a tricky mechanical issue by doing a sum.

Extracting 'm' and 'c' from a dataset turns out to be a well-known problem and the Python numpy module I'm already using has a polyfit function that does the job in a blink. m=-5.21113 and c=15997975.666. The bottom graph shows applying the formula reduces drift from about 30Hz to about 6Hz, a worthwhile improvement.

The python program needed to crunch the numbers is another easy when you know how job!

Next step is to test what happens when the Arduino is coded to output temperature corrected values. Hopefully, temperature compensating the crystal will clear enough numeric fog to show any temperature sensitivity in my pendulum. If I can detect changes in period, then they're likely to be caused by my clock, not shortcomings in the electronic measurements.

Longer term John's comment about multivariate regression needs attention. The issue is my pendulum is almost certainly reacting to changes in humidity and air-pressure as well. Struggling with the maths! I know how to extract the coefficients but not how to separate them or how to apply them as corrections. (The goal is to understand what causes the pendulum to misbehave, not to create an accurate clock by numerically correcting the effect of unknown causes.)

Dave

Edited By SillyOldDuffer on 31/12/2020 14:50:06

Well, two problems: how to separate them, then how to apply "in reverse".

The multivariate regression algorithm takes care of the first, it assumes a relationship something like my formula between the variables and computes the separate coefficients for you.

To correct a value, say a period measurement taken at a particular temp, pressure, and humidity reading, I think you just calculate corrections by multiplying each reading by the negative of the coefficient and add it to the observed period. I've got no shortage of readings, I'll give it a try...