A Well-Tempered Hybrid Pendulum Clock Project

This is what my clock does in measurement mode. The number of pulses output by the Arduino's oscillator per GPS second are counted. Provided the temperature doesn't change much per second, the result is accurate to about 0.25 parts per million. The method automatically compensates for slow temperature changes.

Arduinos fitted with 16MHz quartz crystals are significantly more stable than those clocked with ceramic resonators, so for this purpose better to use a Duemilanove, Uno, Leonardo or Pro-micro rather than a Nano or Mega. Arduino crystals are ordinary - nominally about 100 parts per million, so worth considering alternatives.

I'm using a Mega at the moment for other hardware reasons. A kind friend sent me some temperature compensated 25ppm 20MHz clock oscillator modules, and I hope to replace a Mega's 16Mhz resonator with one. Off the shelf Megas are clocked at 16MHz for compatibility reasons, but they can be reprogrammed to run at 20. Fair bit of work, for a worthwhile improvement in stability, accuracy and resolution.

I measure pendulum beat at high-resolution for three reasons:

1. High variation between beats indicates mechanical problems including external vibration, suspension issues, beam position errors, and electromagnet problems, including over and under impulsing. Also software bugs and shortcomings in the sensors and electronics generally. All stuff that needs to be fixed. High accuracy is helpful.
2. To determine the effect of temperature, pressure and humidity changes on period so they can be compensated. High accuracy is needed because the compensation needs to be good.
3. Impulses can be governed by detecting the small change of period caused by rising or falling amplitude. There are many impulse strategies to explore, such by varying impulse frequency, timing, power, and pulse shape. Impulsing on every beat is common, but many high-precision clocks allow the pendulum to swing free between infrequent impulses. High resolution is more important than high accuracy.

All three measurements are used to detect errors and set-up the clock before the clock is activated. They aren't used for operational time-keeping : that depends on the pendulum.

Over much longer periods my clock's performance is compared with NTP or GPS time. Bog standard NTP is always within 0.1s of atomic time - good enough for most purposes - and GPS is available when better is needed. Long term measurements detect long term drift, slow instability, and compensation errors.

Dave

I’m sure someone was already doing it.😊

Actually, that was my understanding of your proposal, and it's fine in principle. But it's the means of doing that that I'm unsure about. The problem is the lack of sufficient counters with sufficient flexibility in an Arduino. There is only one 16 bit hardware counter and one possibly-suitable 8 bit counter. It's easy enough to time one external signal (e.g. a 1 pps clock) using the Arduino's 16 MHz crystal as the time base via using the 16 bit counter plus interrupts to handle the overflow. But using a puny 8 bit counter for the second timing job feels like trouble, generating interrupts every 16us. But maybe it would work fine?

Dave, any chance you might post your code?

My Arduino (Adafruit Metro Mini V1) appears to have a crystal, though I'm not 100% sure since the part number isn't noted. Properly changing from a crystal to an external oscillator is possible, but unfortunately it requires blowing fuses (I've wondered if simply jamming in a clock would work, though - let us know if you try it!).

Going back to the use of an external high-accuracy counter clock as I suggested earlier, I note that the hardware counters can be clocked externally at half the system clock's speed (i.e., the Nyquist limit), but the documentation suggests lowering that to 1/2.5 of the system clock as a safety margin. Therefore, up to a 6.4 MHz external clock is viable, e.g. dividing a 10 MHz counter by 2 for 5 MHz (200 ns least count).

If using an external counter clock, there is no need to time two external signals (the period and an external reference), and only the period needs to be measured, which can be done pretty easily with the 16 bit counter and a modest overflow interrupt rate. There remains the problem of the +/-32ns uncertainty due to pin synchronization, but counting over a ~2s period thoroughly solves this.

Edited By S K on 20/09/2023 15:45:26

How about gluing a thermistor to the Xtal of the Arduino, then a little bit of code could compensate for temperature without using up the 16 Mhz counter.

Means first. The number of counter/timers available depends on the chip.

• The ATmega16U4/ATmega32U4 used in the Uno, Nano and others including your METRO-327 has an 8 bit counter/timer, two 16 bit counter/timers, and a 10bit counter/timer. Of these, the 8 bit counter is mostly don't touch because it's used by the Arduino for micros() and the 10 bit counter isn't useful for this application because it doesn't do input capture. However, both 16 bit counters are available with Input Capture so GPS and the pendulum can both be timed.
• The ATmega 2560 has two 8 bit counter/timers, one available, plus four 16 bit counter/timers with ICP, all available. I use a third counter/timer to simulate the pendulum when testing software changes.

Code: Having bother with dropbox but try this:

• ardPET.ino Like a picPET except can optionally average over 10 cycles. Grounding a pin switches to the external clock input pin, but note this is just a demonstrator because my code expects 16MHz.
• AMegaClock7.ino Latest version of my clock, runs on a 2560. Also requires: clockInterrupts.h hhmmss.h and sus.h

According to Adafruit's documentation, the METRO has a CSTCE 16M0V53-R0 Murata Ceramic Resonator

The METRO looks like a nicer version of the Uno/Nano so ardPET.ino should run on it OK.

Dave

Fair do’s SK I was just describing the general principle. How you implement it is a matter of choosing the right hardware. Several microcontrollers allow tuning of oscillator frequencies nothing to stop you setting up something like a Pi Pico for instance to run alongside your main processor to just manage the oscillator frequency.

regards Martin

I have a "Metro Mini" (not a "Metro" ) that uses the ATmega328P. This has 2x 8-bit and only 1x 16 bit counters (and yes, the same resonator). I hadn't realized there were so many minor variations of what are purportedly all "Arduinos." Perhaps I should purchase a different board.

Edit: I found that I do have a (non-mini) "Metro 328" lying about, but that presumably uses the same ATmega328. Hmm, am I missing something? Must investigate this further.

Thank you for the code. I'll take a look. I'm still interested in doing away with the need to calibrate the high speed clock, though.

Edited By S K on 20/09/2023 20:12:46

Success! 🙂

I managed to use an external clock (5 MHz from a function generator) to measure periods, using the single 16 bit counter.

Now I have to validate the precision somehow, as I'm not yet 100% confident that the technique really does give me as high precision as I hope for at that high resolution. I'm also not certain of the function generator's noise or stability, so I'll probably switch to the 32kHz RTC clock output for now. But if that works out, I can get a good oscillator and move onward with the pendulum.

Edited By S K on 20/09/2023 21:02:32

OK, I used two channels on my function generator, one at 5MHz for the high-speed clock, and one at 0.1 Hz for the period, and the output is quite stable to 1 LSB (200 ns), which is the minimum error I'd expect to be possible.

Awesome! 🙂

Sounds suspiciously like your function generator synthesises the two channels from the same master clock in which case it’s not surprising they stay in synch.

Sorry to rain on the party.

regards Martin

It almost certainly does, but I don't believe that's an issue.

My concern is about whether the Arduino accurately counts at 5 MHz, or whether it misses clocks, etc., and also if the interrupt for the period registers the time promptly and correctly, i.e., within one 200ns clock, or whether it's noisy in the time domain. A stable output would appear to verify both of these, wouldn't it?

But I should ask: What process would best show that the timing of a period is being recorded accurately?

One fear I still have is that there may be beats or some other bizarre interactions between the 16 MHz Arduino clock and the 5 MHz clock. I think so long as the Nyquist criteria is satisfied there should be none, but how to prove that?

Edited By S K on 20/09/2023 23:25:09

Ah you are proving software, my mistake.

👍

But I should ask: What process would best show that the timing of a period is being recorded accurately?

If you have a GPS 1pps source, use your measurement system to log a few days periods and compute the Allan Variance (using Timelab or Stable32).

I think a stable output is proof of pudding! The Arduino CPUs come with various built-in peripherals including a few counter/timers. Being hardware peripherals makes them mostly independent of the computer.

When set up to do input capture, a hardware counter is clocked by the computer's oscillator, a direct connection unlikely to go wrong.

The Input Capture pin is triggered with the usual logic rules, so provided the rise time and voltages are within spec, that should be reliable too.

An Input Capture event causes the counter value 'now' to be copied. The counter doesn't stop, but the 'now' count is frozen. The event also triggers an interrupt. The interrupt pauses whatever the computer was doing, runs a short user program to process the event, and then restarts the main program. Provided the 'short user program' finishes before the next event, all should be well. With a pendulum period or GPS unit, the events are about a second apart, which is a long time for a computer.

I think the best test is to feed the counter with a known accurate frequency, such as an OCXO. However, Joe put me on to the UBLOX range of GPS Modules, and I bought a MAX M8. These can be programmed to output frequencies other than 1 Hz, not all equally stable, but mostly locked to GPS. I set my M8 to output 10MHz and measured that with an ArdPET fed with GPS seconds from an Adafruit module: it averaged 10MHz over 10 seconds. Then I used the ArdPET to calibrate my OCXO, and watched the OCXO and M8 lissajous on my oscilloscope. This test also showed the frequencies to be identical. The OCXO has to warm up for about 25 minutes before it's stable enough.

Dave

Actually, I'm using an external oscillator, not the Arduino's oscillator. A fast oscillator is preferred in this configuration, and I've tested up to 6 MHz.

I could use the DS3231's 32 kHz TCXO, which though slower would work just fine for most purposes. But I'm also looking at 10 MHz oscillators, divided by two, yielding 200 ns resolution. Some TCXOs have quite good ppb's, and they have low power requirements. Faster ones are all surface mount, though, which is an inconvenience that nearly requires making a board. OCXO's typically consume a few W, but some are available with pins. I'm not looking at GPS or atomic clocks, etc., for this project.