Yet another Arduino clock thread!

This is correct, see:

https://academic.oup.com/book/9250/chapter-abstract/155957399?redirectedFrom=fulltext

**LINK**

Paper by Robert Matthys

Very interesting. The "free machining" variant would be most welcome!

A quick update after 5 days running. I think it's time the clock was moved to a better location now it doesn't need much fiddling. Being in the workshop and with the shop vac living right next door I've notice that it's prone to being jolted and sometimes as a result its amplitude reduces and it can get into a mode where it "forgets" which way it's supposed to be impulsing - then it impulses the pendulum the wrong way and brakes it instead! As long as there are occasional swings that exceed the amplitude set point it is reminded of which way is which so them I have to give it a nudge to get it above the line again. So it can go back on the wall of the cold studio where it should have been, I moved it into the warm! It will then have a more rigid mounting so I hope the Q will be larger. I also want to do some mods to the electronics to improve the power supply arrangements.

Meanwhile I've been working further on the dial, adding a mounting for the chapter ring, mounting the printed chapter ring I bought on a rigid and strong backing, adding some attachment points for the dial to the case when I eventually get round to that.

If you had a second opto right alongside the centre one it might be possible to have a sort of quadrature set up so it knows which way it's going. Probably not worth the effort

I used a second sensor in my clock - partly for that purpose and partly as a means of determining the duration of the impulse.

My first clock ("Arduinome" used a single sensor which is quite offset from the centre so tghe processor can work out which side the pendulum is - the actual impulse position is completely determined by the mechanics so a central sensor position isn't needed. And I used blocking "delay" statements liberally in my code in a way which meant that I never actually had to work out where the pendulum was.

Back on the wall. Actually much quicker than I expected. It does seem to be happier with a more solid mount, one can see from this.

Top trace is the pendulum sensor, which is also the drive pulses if enabled.  Bottom trace the amplitude sensor, each blue pulse is where it just catches the amplitude peak.  When that happens the following two drive pulses are disabled.  In this trace you can see that the 4th and 5th pulse are disabled, also the 6th and 7th, then there are two where there will be drive pulses (then it's actually the previous trace...).  So more or less the control system is doing hit/miss alternately.  This is doing significantly better than when screwed to the bench as I hoped.  Now to rebuild my time measuring system...

Also I can now walk round the workshop without having to carefully avoid the thing.

Edited By John Haine on 27/01/2023 17:16:15

Edited By John Haine on 27/01/2023 17:18:21

John - your use of core-less coils to drive the pendulum prompted me to unearth a couple of coils that I had to hand that were bought as components for a loudspeaker crossover. Thes kinds of coils can be readily purchased from the usual electronic supply suspects, are beautifully wound, and come in a wide variety of sizes. An easy solution that avoids the need for coil winding. The ones I unearthed are wound from 0.4mm copper wire, and have about a dozen layers of 25 turns.

Edited By Tony Jeffree on 29/01/2023 17:05:51

Would be good to know where they came from Tony*. But HH coils are quite easy to make and you have the advantage then of a predictable flux density so the current needed can be calculated. But if I ever make another one I might well buy two of those coils...

* https://willys-hifi.com/collections/audio-inductors-air-core ?

As it's been a couple of weeks I thought a quick progress report was due.

• I finished the time logging system and got some initial Pi logging software working the w/e of the 4/5 Feb. That was logging the time of each swing, i.e. every second, but the results were difficult to process since the two swings are slightly different lengths as measured. Anyway the results were good enough to see the effect of the Turkey earthquake on amplitude and rate.
• New logging software installed last Tuesday and ran for nearly 5 days but I found the pendulum nearly stationary early in the morning of the 5th day. I'd noticed before that occasionally when I was working near the clock it would "forget" which side was left, which meant that the impulse actually slowed the pendulum down! This time I also found that there were no pulses coming from the optos and finally found the bad contact in the DC supply to the LEDs.
• As I had to restart the clock anyway I made another software update. Now the Pi for each cycle generates a record that has the acquisition time based on a "paper clock" that has the average period of the real clock; the error between the "clock time" based on the integrated measured period and the paper time; the period itself; amplitude averaged over the two opto pulse lengths; temperature, pressure, and RH.
• The reason for choosing the parameters and format is so I can directly read the data into either of two free software packages for analysis: TimeLab and Stable32. Both easy to find on the web, and recommended in Tom Van Baak's writings. I can't say I'm anything more than a novice with either, but they seem reasonably easy to use and can compute things like Alan Variance with a button push. I'll also use R-Studio to extract regression data. So far there hasn't been much variation in atmospheric conditions against which to correlate! I think I'll also add an LDR to look at ambient light levels to see if there's any systematic affect on the opto precision. Would also be good to log supply volts!
• I did manage to get a nice plot of time drift out of Stable32 from the week's worth of data but now I can't work out how to get it back!

I don't recall where those particular ones came from John, but Willys would be one of the places I would look, also Mouser and RS Components.

I don't recall where those particular ones came from John, but Willys would be one of the places I would look, also Mouser and RS Components.

John , not sure if I missed it, but did you describe your measurement method/process? I did not see a clear reference in your posts?

Timelab/Stable32 process data that is in essence the result of a determination of variation of data samples in a accurate, fixed time interval - a Time interval Counter that has a very accurate and stable clock being gated or counted by the pendulum period. The clock count variation can then be processed by these software. Is that what you have implemented? If so, your source clock drift / variation/accuracy can mask the true Allen Variance if it's not good...

Hi Joe, no I don't think I did. I use one of Tom's picPETs (a pP07) to time both edges of the pulses from the BDC opto. The pP is clocked from a 10MHz OCXO, non-disciplined but likely to be a lot more accurate than my clock!

On the subject of ‘reference oscillators’ …

I was intrigued by this ebay offering : **LINK**

https://www.ebay.co.uk/itm/283982709540

There appear to be contradictory ‘stability’ figures in the description, and its easy screwdriver adjustability seems rather counter-intuitive for something intended as a reference device.

… Grateful for comments from those better-informed.

MichaelG.

A useful reference for CB radio's maybe... else its just an exercise in frustration! All high quality Ref oscillators will have some form of adjustment but with limited range - the NDK osc you reference can be changed by 500Hz typ with that trimmer, which is a ceramic trim cap, with its own poor temp performance and mechanical stability. Would not touch it with a trimmer screwdriver - or a barge pole for that matter..

One of the OCXO's I use as an example:

And the test sheet:

John, I believe from some previous interaction with you that you are a time-nut? At the risk preaching to the converted, here are some useful reads - ( I cannot post pdfs, etc, so the google should find them for you)

A very good ppt presentation by a master in the field:

**LINK**

A veritable bible on the subject: Handbook of Frequency Stability analysis.

**LINK**

Some measurement systems:

**LINK**

And Misc good stuff:

**LINK**

**LINK**

WJ Riley is a master in this field...

Obviously you will have the Stable32's manual...

Edited By Joseph Noci 1 on 15/02/2023 06:13:53

.

Thanks, Joe … My instinctive caution about it seems to have been appropriate.

Much appreciated

MichaelG.

Thanks for the links Joe. Some I had seen, they all look useful. I am trying hard not to get sucked in to being a time-nut any more than I have to, I'm mainly interested just in making accurate pendulum clocks - but how do I know how accurate?! I assume my cheap eBay OCXO is a lot better than my pendulum but how to check?

The same problem is on my list! John pointed me at a cheap source of ex-equipment OCXO, CTI Type OSC5A2B02, which is a 10MHz 200ppb device. Although this is a low-end OCXO, it's a better frequency standard than anything else I have.

But, the frequency is not 10MHz out-of-the-box, the user is expected to adjust a pot to tune it in. The question is, how to tune it in accurately. I need a more accurate frequency standard and a way of comparing the two.

Possibilities open to me are:

• I have GPS seconds pulses, which could be used with a precision event time to get close to 10MHz
• With much more bother, one of the radio time signals could be used:
  • WWV (10MHz. weak, noisy and not always audible),
  • RWM (9.996MHz, louder than WWV here)
  • MSF (60kHz, weak in my location),
  • DCF77 (77kHz, bit louder than MSF)
  • BBC R4 longwave (198kHz, very strong but amplitude modulated),
  • ALS162 (Allouis, France 162kHz, good signal and not amplitude modulated)

My plan is to divide the OCXO by two because an Arduino timer can only be externally clocked below 6.4MHz and programmed to count pulses over several seconds to get the average frequency. Alternatively, do similar with a picPET at 10MHz, noting that the picPET can't be programmed to average counts, but this could be done externally.

I'm not expecting the GPS/PETmethod to do a brilliant job because the resolution of 5MHz into a binary counter is ±1Hz. Is this good enough, given that I think that 200ppb at 10MHz is 2Hz? True confession : my maths are untrustworthy.

Initial experience watching an OSC5A2B02 power up with an oscilloscope is that stability is very poor at first - the waveform visibly increases in frequency from cold for about 10 seconds. The specification says don't trust it for at least half an hour after power on. The device is not meant to be switched on and off rapidly. I'd expect operating it in the open air to reduce stability compared with mounting it in a closed box that slows down heat loss and minimises convection.

Getting a 'near enough' 10MHz signal is easy, but getting an accurate, stable 10MHz signal and proving it's right seems horribly difficult!

I've toyed with measuring frequency from first principles with a Lecher line, but that seems to require measuring a 15 metre-ish long line with sub millimetre accuracy, also a serious challenge!

Dave