A Well-Tempered Hybrid Pendulum Clock Project

[John HaineParticipant @johnhaine32865]

"limited by the 32kHz frequency of its output. This would yield about a 3us least count per second"

32kHz is a period of 31.25us?

[S KParticipant @sk20060]

Posted by John Haine on 19/09/2023 21:47:05:

"limited by the 32kHz frequency of its output. This would yield about a 3us least count per second"

32kHz is a period of 31.25us?

Thanks. Fixed above. Any other mistakes?

[S KParticipant @sk20060]

So while the long-term accuracy of the DS3231 is likely better than my pendulum, now I'm feeling unhappy about the resolution. The issue is that the pendulum + Sharp opto is good for 3-5 us, but a 32kHz clock only delivers 31 us. I liked it a lot better when my eyes misread a spurious extra zero and came up with 3us!

Curses! What to do now? I guess I really do have to consider John's Picpet+OCXO.

Edited By S K on 19/09/2023 22:51:51

[Martin KyteParticipant @martinkyte99762]

If you have a fast clock that drifts slowly and a slow clock that is accurate counting the oscillations of the fast clock using the slow accurate clock gives you a correction factor for when you use the fast clock to measure pendulum period. For example if you had a very accurate 1 sec marker and counted the transitions of a nominal 1 MHz clock and got say 1000007 then your measurement of your pendulum period using the nominal 1 MHz would require a correction of 1000000/1000007. Doing this for every measurement corrects for drift in the fast clock. Would this not be a way of achieving high resolution and accuracy. Just thinking out loud really. Depends really on the way the fast clock varies.

regards Martin

Edited By Martin Kyte on 19/09/2023 22:57:44

[S KParticipant @sk20060]

Posted by Martin Kyte on 19/09/2023 22:55:58:

Would this not be a way of achieving high resolution and accuracy.

regards Martin

 

Yes, I think that's what Dave does or proposes to do. But there might be a technical problem: It requires managing two clocks with high precision instead of one.

In the scheme I proposed above, the 32kHz clock (high accuracy, low resolution) is sampled using the processor's 16 MHz clock (low accuracy, high resolution) and counted in hardware. But there is no need for the 16 MHz clock itself to be timed or counted, as it has virtually no bearing on the result as long as it's generically "fast."

In the scheme you described, you need accurate timing of both the 32kHz clock and the 16 MHz clock. Otherwise you might not know the fast clock's result well enough to calibrate it adequately.

In one possibility, the "micros" command might be good enough to time the fast clock – I think that gives either 4 or 8 us of resolution (can't remember), but you do have to call it manually, e.g. once per period. This may not be of deterministic latency in that it could be delayed by other code or interrupts (the precision counter's overflow is handled by interrupts, for example). Some experimentation would be needed to verify that it's good enough, and odds are that it wouldn't be perfect. And, in addition, that isn't even all that fast: One really wants it to be faster than the 3-5us that the opto seems to deliver in practice.

Between the two approaches, using a faster high precision clock might be the better solution for an Arduino. So take a 10 MHz oscillator, and divide it down say by a factor of 4, until the counter's input is happy (e.g. about 2.5 MHz). Then you get the long-term precision at 400 ns resolution. (Or "just get a picpet" – sigh.)

 

Edited By S K on 20/09/2023 02:49:42

[Martin KyteParticipant @martinkyte99762]

Not really what I was suggesting. If you set up two counters to run concurrently clocked by the ceramic oscillator of your processor the first of a period defined by your pendulum opto sensing and the second by the GPS time interval you end up with two numbers. The first is the uncorrected period of the pendulum and the second is a number from which you can determine the rate of the processor clock (count over accurate) time period. The second value can then be used to correct the result of the first to give a high resolution high precision pendulum period. It relays on the processor clock having drift but being stable over periods of 10s of seconds.
Forgive me if this is already being done and I’ve missed it.

regards Martin

[SillyOldDufferModerator @sillyoldduffer]

Posted by Martin Kyte on 20/09/2023 08:04:53:

Not really what I was suggesting. If you set up two counters to run concurrently clocked by the ceramic oscillator of your processor the first of a period defined by your pendulum opto sensing and the second by the GPS time interval you end up with two numbers. The first is the uncorrected period of the pendulum and the second is a number from which you can determine the rate of the processor clock (count over accurate) time period. The second value can then be used to correct the result of the first to give a high resolution high precision pendulum period. It relays on the processor clock having drift but being stable over periods of 10s of seconds.
Forgive me if this is already being done and I’ve missed it.

…

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

[Martin KyteParticipant @martinkyte99762]

I’m sure someone was already doing it.😊

[S KParticipant @sk20060]

Posted by SillyOldDuffer on 20/09/2023 13:10:18:

Posted by Martin Kyte on 20/09/2023 08:04:53:

Not really what I was suggesting. If you set up two counters to run concurrently clocked by the ceramic oscillator of your processor the first of a period defined by your pendulum opto sensing and the second by the GPS time interval you end up with two numbers. The first is the uncorrected period of the pendulum and the second is a number from which you can determine the rate of the processor clock (count over accurate) time period. The second value can then be used to correct the result of the first to give a high resolution high precision pendulum period. It relays on the processor clock having drift but being stable over periods of 10s of seconds.
Forgive me if this is already being done and I’ve missed it.

…

This is what my clock does in measurement mode. The number of pulses output by the Arduino's oscillator per GPS second are counted.

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

[duncan webster 1Participant @duncanwebster1]

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.

[SillyOldDufferModerator @sillyoldduffer]

Posted by S K on 20/09/2023 15:38:24:

Posted by SillyOldDuffer on 20/09/2023 13:10:18:

Posted by Martin Kyte on 20/09/2023 08:04:53:

…

…

This is what my clock does in measurement mode. The number of pulses output by the Arduino's oscillator per GPS second are counted.

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).

…

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

[Martin KyteParticipant @martinkyte99762]

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

[S KParticipant @sk20060]

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.

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

Dave

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

[S KParticipant @sk20060]

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

[S KParticipant @sk20060]

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! 🙂

[Martin KyteParticipant @martinkyte99762]

Posted by S K on 20/09/2023 21:44:15:

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

[S KParticipant @sk20060]

Posted by Martin Kyte on 20/09/2023 22:38:42:

Posted by S K on 20/09/2023 21:44:15:

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.

 

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

[Martin KyteParticipant @martinkyte99762]

Ah you are proving software, my mistake.

👍

[John HaineParticipant @johnhaine32865]

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).

[SillyOldDufferModerator @sillyoldduffer]

Posted by S K on 20/09/2023 22:59:45:

Posted by Martin Kyte on 20/09/2023 22:38:42:

Posted by S K on 20/09/2023 21:44:15:

…

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.

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?

…

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

[S KParticipant @sk20060]

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.

[Author]

Posts