A Well-Tempered Hybrid Pendulum Clock Project

Tim: I like the idea of putting the compensator at the hinge, though it would probably complicate the hinge itself. But my main problem is that I have only found a reasonable source for Invar at 36" lengths. I did contact a few other dealers in the U.S. (purported, I think they really only drop-ship from somewhere else), but they both asked for about $500 for a longer length. So, if my total length is constrained, it doesn't matter much where the compensator is, and the bottom is easier. Maybe for next time! Thanks!

Dave: Thanks for the comments. I've been wondering what "good enough" is or should be. And I still wonder about the philosophical question of what is marking time, the pendulum or a large assembly of electronic bits with a pendulum at the side? I thought I'd try for a mostly "pure" approach, with the electronics only doing rating and timing the impulsing. Other electronics, such as temperature monitoring, would be for examining performance, but not for correcting the pendulum (hence my attempt at mechanical compensation).

I envisioned the DS3231 as an inexpensive and easy to use medium-performance part prior to going nuts with GPS disciplined oscillators, etc. Its TCXO has about the same performance as any other TCXOs, and should yield about +/- 0.17 seconds a day. If I obtained close to that with my modest pendulum operating in open air I'd be pretty happy.

I've been researching the Arduino's hardware timer capabilities, but I want to avoid using the Arduino's own oscillator as the time basis. Not unless I can bash an external clock into it, anyway, and I have no idea how or if hacking it would work.

It seems the code you pointed to does use the internal oscillator. Using that requires continuously calibrating it against yet another time source, which is cumbersome. How are you monitoring / counting both the system clock and your external clock?

Documentation is a bit lacking, but I see that pin 5 (T1) can be used as an external clock input for Timer1 (16 bits). I'm not sure how fast it can go, but I'd like to hope for 16 MHz still. If that's possible, then an external 16 MHz OCXO, with a few parts per billion, could be used. That, I think, would simplify things by not having to calibrate the internal clock with an external clock, e.g with a 1Hz GPS reference.

Edited By S K on 05/09/2023 17:18:45

Just like to remind you of the benefits of a picPET with an oxco...

That would be too easy! I'd rather spend a few weeks tearing my hair out programming an FPGA! 😄

(But what's with the "100 ns resolution" claim when it appears to actually be 400ns?)

Edited By S K on 05/09/2023 17:33:20

The resolution is 100ns because the thing is clocked at 10MHz. Tom quotes the "granularity" as 400ns and I have to admit I don't understand what that means! Here's a sequence of numbers from a run.

6725.56415040000
6727.55243760000
6729.54073600000
6731.52902880000
6733.51731360000
6735.50559720000
6737.49386360000
6739.48219080000
6741.47048760000
6743.45877480000
6745.44706960000
6747.43536440000
6749.42366040000
6751.41195520000
6753.40024800000

So far as I can tell the digits after the 6th decimal place are all even so multiples of 200ns, I'm not sure where the 400 comes from. I'll ask him. Whatever, it's at least an order of magnitude better than the resolution needed for my purposes!

I've only checked a few numbers, but it looks like the minimum output step and hence resolution is 400ns. Still, 400ns is 10x better than the 3-5us that the opto seems to deliver.

Oh no! The ATMega data sheet section 17.3 describes how pins T0 and T1 can be used as an external clock for the timer/counter registers clkt0 and clkt1. But it's not a direct input, it's actually sampled by the normal system clock! Apparently this is just part of the system-wide I/O synchronization. That being so, you can't have a genuinely independent external timer clock. Bummer!

Extract from response from Tom.

"The PIC chip that I use has an internal four-phase architecture so a 10 MHz external clock becomes a 2.5 MHz internal clock and that translates to a 400 ns instruction cycle time. Thus any numerical result from a picPET is a multiple of 400 ns, which is 0.4 us. [1]

For mechanical timing, even for the best ever pendulum clock, 0.4 us is plenty good enough since measurements are usually limited by the sensor or the pendulum itself."

I may be overlooking some mathematical subtlety here [it wouldn’t be the first time], but that level of granularity would seem to suggest that a substantially large count of seconds-pendulm swings would need to be accumulated before the uncertainty-of-measurement fell to a usefully low level.

In a single swing, 0.4 of a micro-second only represents one part in 2,500 doesn’t it

Feel free to ignore me, but preferably educate me

MichaelG.

This is not a random error so not subject to the "root-n" type of averaging if that is what you mean Michael? Anyway 0.4us is one part in 2.5million compared to a second.

.

1. No, that wasn’t quite what I meant

2. Apologies … stupid brain-fade milli vs micro … I really shouldn’t have done that

MichaelG.

Edited By Michael Gilligan on 06/09/2023 11:01:43

True of the AVR 8-bit chips, not sure it applies to other microcontrollers though. On the AVR's it limits the external clock to 6.8MHz, which is why my 10MHz OCXO has a divide by 2 output as well - I could clock the timers at 5MHz. Not tried it yet because it limits resolution to 200nS.

Much better to replace an Arduino's on board 16MHz crystal or ceramic resonator with a stable external oscillator, ideally 16MHz so micros(), millis() and other time functions work normally.

The CPU chip has an internal oscillator connected to two pins across which a SMD crystal or resonator is bridged to set the frequency. The chip pins aren't available to the user - instead two short tracks lead to the crystal, which would have to be removed and the new source soldered on.

Neither pin is earthed, so the source has to float. Apart from that, I think feeding a signal to the oscillator pins will cause it to work as an amplifier with no complications. Not tried it though.

Another possibility is the Arduino Uno, because the CPU is a DIP chip plugged into a socket, making the oscillator pins more accessible.

Dave

Interesting: that isn't true of the Arduino chips. They pulse the counter/timers at 16MHz, straight off the system clock, so the resolution really is about 62.5nS. Accuracy is less satisfactory.

The Arduino's Achilles Heel is its oscillator. Most Arduinos are fitted with a 16MHz ceramic resonator - rather unstable. The Uno, Leonardo and Pro-Micro all have crystal oscillators - considerably better, but not temperature compensated, so much inferior to an OCXO.

The big advantage of Arduino vs PICpet is that the Arduino can be programmed to do more than just timing - reading sensors, logging to Serial or an SD card, driving the electromagnet, and displaying HHMMSS etc. I expect the more powerful PIC chips could do the same but I fell out of love with PIC way back when it was hard to upload firmware. Since then I've forgotten everything!

Dave

Thinking out loud about timing resolution and accuracy:

The DS3231's 32kHz TCXO (and TCXO's in general) is good to +/-2ppm, or about +/-0.17s per day. I think this is adequate for my purposes, at least for the moment, since I'm not expecting my relatively-light pendulum operating in open air to be much better than that. For comparison, Bateman claimed +/-0.5s per day for his heavier and enclosed pendulum. If I did bump up against the TCXO's limit, an OCXO could be used instead.

Now, if the Arduino samples that asynchronously at 16MHz, an uncertainty of +/-32ns per sample is added that can be nullified to below the TCXO's native stability by counting say 1000 32kHz ticks. This is easily done well within the ~1.8s period my pendulum has (about 57k ticks). So for basic timing measurements (e.g. for the purposes of operation as a clock) I think the combination should be fine.

Note that this delivers the relatively-high long-term accuracy of the TCXO (over that of the native Arduino), but not extreme resolution. For the DS3231, that is limited by the 32kHz frequency of its output. This would yield about a 31us least count or under 0.002% for a 1.8s period, which doesn't sound especially bad for my purposes either.

To obtain more resolution requires a faster clock. At that point, an OCXO could be used. For convenience, a CMOS or TTL output is preferred, and these are available down to about 5ppb. However, prescaling would be needed for use with an Arduino, since the 10 MHz+ frequencies of these OCXO's (from what I've found) are too fast. Prescaling down to maybe 1MHz should be OK to drive an Arduino's hardware counter. But to realize the higher accuracy, the amount of averaging would need to be about 16,000 times higher too, and realistically some other solution (e.g. picpet) would be better over-all.

Since I have it wired up already, I think I'll try the DS3231's 32kHz clock feeding the Arduino's hardware counter, and average the asynchronous sampling over the pendulum's period. The advantage of this is that there would be no need to explicitly calibrate the Arduino's internal clock against an outside one (e.g. a 1 pulse per second clock).

The Arduino has so little memory that it can't do much more than tell time. Logging may also be problematic, as Dave pointed out, but I'll probably try it. Maybe I could implement a single-pass running S.D. calculation on the period, too. What else would be useful or interesting that could be displayed in real time?

(Eh, I probably won't be able to resist getting an OCXO anyway. 😉 )

Edited By S K on 19/09/2023 22:07:57

"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?

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

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

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

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