Yet another Arduino clock thread!

Dave, check my post in your post re using a 1pps programmable GPS as a ref clock...

I thought it was about time I posted some results from the clock, so to start with here is an ADEV plot from the first extended run (nearly a week I think). (I also posted this on Dave's current thread.)

I'm not entirely sure what it means but TVB says it looks respectable, comparable so far with a good Synchronome except the 'nome plot would look awful below 30s averaging time from impulse noise whereas this is clean down to the 2s impulse period. Variation fllor at about 1000s then rises up again. Next step is to extract some timekeeping data from the numbers.

Well not going as well as I hoped - I feel for Dave in his frustrations! Looking more at the data to try to extract some regression coefficients I got increasingly concerned about the apparent noise in the time measurements and by extension in the amplitude calculations. After quite a lot of playing around there are a number of things to investigate.

• I think some of the problem may be accidental rounding in the Python code that reas the data from the picPET. The pP encodes each timestamp as a 13 digit BCD decimal with a decimal point, so 7 digits after the point and 6 before. The count rolls over at 100,000 seconds and the code has to detect a rollover between any two edges and adjust itself to add an appropriate number of 100,000 seconds. I was storing each measurement as a float but the precision of that in Python is limited in the number of decimal digits. When I looked at some of the recoded data I could see that though there were 7 decimal places the actual precision was more like 5 as some rounding took place. It seems that I should be using "Decimal" types rather than float which is the next thing to try.
• There's also electrical noise on the sensor and worse perhaps on the picPET. The whole thing is powered from a switched-mode 12v wall wart, with a buck converter to 5V for most of the electronics and boost to 18v adjustable for the drive coils. I'll see if I have a 12v transformer type wart and fit a linear regulator for the 5v.
• I'm also concerned that there could be some pendulum wobble, either in the spring compliance or the rod bending (or both!). Whether that matters I don't know - I think it would show in the ADEV plot so maybe not. But the measurement noise must be affecting the ADEV, of course the snag with electronic monitoring is making sure that I'm looking at the pendulum and not the tester!

Ho hum.

Welcome to my world! When a pendulum clock is tested in the ordinary way, I suspect a multitude of sins are covered up because many errors tend compensate out on average.

Collecting a lot of fine-grained data, especially with a Precision Event Timer watching individual swings through a statistical microscope reveals a multitude of anomalies, as does watching drift and amplitude vary over longer periods. Possibly many a clockmaker would be shocked to see just how variable clocks are when closely inspected. No shame in it, because even the world's best timekeepers have limitations. I found recently that Atomic Clocks don't have wonderful short-term stability, and are often complemented by an OCXO which do. The OCXO doesn't have excellent long-term stability, but that part of the problem is covered by the Atomic Clock. Team work!

Which picPET are you using? Tom provides a number of variants and one of the others may be more suitable. (An advantage of my ardPET is the source code being available allows a C-savvy user to program the output in any format.)

I've managed to avoid using 64bit floating point in the Arduino by working within the limits of long integers, for example using a pair of them to represent seconds and microseconds rather than a narrow float. Likewise, I've just avoided python Decimal, which is good because they're slow to compute and the numpy module is designed for speedy doubles. Special care is needed to avoid and spot underflow and overflow problems.

Electrical noise is a problem, but I'm pretty sure most of mine is coming from the pendulum and the beam break sensor. My pendulum is relatively poorly made. In particular, the suspension is prone to twist whilst the spring is also liable to be biassed by levelling and alignment errors. Most test runs after a mechanical adjustment show prolonged small changes that gradually disappear and different oscillation modes. I think these are due to the suspension 'running in'. The different oscillations appear when impulse is increased and are probably due to the rod 'twanging'.

Understanding "wos goin on" is interesting, but only important if the goal is a high-performance clock, one delivering high short-term and long-term stability. That can be built by me on the cheap!

Dave

pP07 - seems designed for pendulum clocks. I don't think computation speed will be an issue at 1 record/sec! We'll see how it goes with Decimal...

Actually after working out the syntax it was fairly easy and I'm now logging the data at full precision. Will see what the stats look like now...

If anyone is curious about what we're on about, it's limitations in the accuracy of computer arithmetic. How many digits they can manage, how fast sums can done, and booby traps - several.

The fastest comuter arithmetic is done with word sized integers, usually 64bits on a modern PC. These hold up to 2^64 bits, holding unsigned numbers up to 18446744073709551616 or signed numbers ±9223372036854775808 If the 64bit range is exceeded, 64bit numbers roll-over with strange results: 18446744073709551616 + 1 = 0 And because integers don't support fractional parts, 1 / 2 = 0

Floating point numbers support 1/2 = 0.5 but, in their fastest form, are also squeezed into 64bits. As a result, they are limited to 16 digits total. 1234567890123456.0 is ok, and so is 0.1234567890123456, but adding them together results in 1234567890123456.0 because all 16 digits have been used. The range of numbers they can hold is odd too: 1.7976931348623157e+308 to 2.2250738585072014e-308

Programmers have to be careful to keep calculations within the limits of integers and floats, which is tricky when working with lots of seconds and microseconds, or nanoseconds.

Other ways of computing big numbers exist but there's no such thing as a free lunch! Python3 integers are limited only by the amount of memory available and can be as long as a telephone line! Python also supports a Decimal type in which numbers are held precisely. Default precision is 28 digits, and this can be increased as required. The downside of unlimited precision is the numbers take up memory and calculations are relatively slow. These speed and space considerations become ever more important as the dataset grows.

It's one of the many things software engineers are paid to get right! And sometimes they don't...

Dave

I was thinking of the clocks used on GPS satellites rather than the best that can be done on the ground.

As I understand it, GPS satellites contain an OCXO disciplined by a practically sized Atomic Clock, not itself capable of the best possible Atomic accuracy, or short term stability. So an OCXO provides sub-second time, whilst the Atomic clock keeps the OCXO accurate in the long term.

As the combination still isn't stable enough, the Atomic Clock's drift is measured by ground-stations who send it error corrections. I don't think the frequency of the Atomic Clock is tweaked, rather the corrections are applied mathematically as necessary to keep the OCXO and long count on target. A GPS satellite OCXO is unlikely to be the modest device I bought off ebay. The catalogues show high-end OCXO's get very expensive!

I think the architecture is typical: a low quality oscillator does the day job, but is periodically corrected by a higher-standard, itself part of a hierarchy of time-standards,each of which gets more expensive and specialised as they struggle to deliver the best time technology can currently achieve.

It's a fascinating subject and everything I thought I knew about it turns out to be wrong. What fun!

Dave

Tweaking atomic clock frequency must be a bit hard by definition!

Well, as expected the wall wart (switched mode type) was horribly noisy and there were spikes all over the power rails, so I replaced my internal 5v regulator with a good old-fashioned linear type and ran the whole thing from a bench power supply. That didn't help much! Then I connected the 1pps from my GPS (same type as Dave has) into the picPET input rather than the opto signal from the pendulum - this gave a rock-solid set of readings that showed my OCXO frequency was 10Hz low... One more thing to try is feeding the 1pps signal into the emitter of the opto pickup in case the noise is getting in at the sensor (clutching at straws here...). But I'm coming reluctantly to the conclusion that my impulsing method is exciting "rod wobble"...! The rod being 6mm carbon fibe tube is a bit bendy, and the spring suspension pivot doesn't provide very strong lateral constraint - I was always concerned that my "clever" technique would give this problem, it's something that plagues synchronomes too. Have to think of a way to impulse close to the bob. Back to the drawing board...

Possibly the piCPET has the same bug I've just fixed in my ardPET.

Yesterday I replaced the horrible trimmer in my OCXO with a decent multi-turn type, thanks Duncan, and tested it.

Noticed something odd. The latest version of my ardPET optionally allows counts to be taken over 'n' GPS seconds, and I noticed that the 10x setting allowed the OCXO to be trimmed to 50000000, but the maximum count at x1 was always several Hz low. The x1 setting was missing some counts.

The only difference in the code between x1 and x10 was how often the counter is zeroed as a fraction of the total count; that suggested a logic error. In the program I reset the counter because doing so simplified the logic and maths, but engaging brain showed it's a bit too simple. Zeroing the counter loses any counts arriving immediately after an input capture event and before the next count cycle starts, plus counts that arrive whilst the zero instruction is being executed.

I've refactored the code so that the overflow and counter are only read by my code. The maths and logic needed to calculate the number of pulses between events is a little more complicated, but now the OCXO trims properly and 1x and 10x agree.

In an earlier comparison picPET and ardPET produced the same low result from the OCXO, which is why I thought the OCXO was wrong. It's possible picPET has the same logic flaw. I didn't realise anything was wrong with ardPET until measuring an OCXO pushed it to the limit. The error is only about 0.0001%, and unlikely to be spotted measuring a pendulum!

Corrected version of ardPET available on dropbox.

Dave

A bit more experiment seems to confirm that I have a case of the dreaded wobbly rod. I modified the logging code to just compute and print successive periods, or rather the deviation of the period from the mean, that latter being slowly updated as a moving average over 100 periods. Then used the plot function in the Python Shell to see what the result is.

A typical plot showing how the period varies by +/- 25us between periods. What I think is happening is that because the rod is rather flexible, the impulse torque "winds it up" since the bob can't be instantly accelerated - the actual impulse is then delivered late and the rod probably has a flexure oscillation mode as well that will create additional measurement error. So I've decided I need to change tack and will make a kind of "yoke" that fits at the top of the bob with "wings" at either side in which will be mounted neo bar magnets. I've bought a couple of the "crossover coils" that Neil mentioned to use as the impulse electro-magnets. I have a scrap bit of tufnol that will do the job, just drawn it up in Cambam for the CNC mill. A side benefit is that I can try using a thinner pendulum rod - I have some 3mm CF tube which should have a smaller aerodynamic profile.

Just an aside, as it slightly irritates me: What's with the "Precision Event Timer" talk, capitalized and all like it's a Very Real Thing!?

The long-accepted term for such a device is "time to digital converter" or TDC. 😉

(In a prior career ages ago, I designed a TDC with 500 ps resolution.)

Edited By S K on 06/03/2023 21:20:35

.

Many on this forum would assume the TLA ‘TDC’ to mean Top Dead Centre

… so where does that leave us ?

MichaelG.

It leaves you Totally in the Wrong (capitalized!) until you submit to the proper terminology! Lol.

It's NBG if you don't know your TLA's 😂

It's a nod to Tom van Baak, who made a handy PIC based timer available many yonks ago. Tom describes it thus: 'The picPET is a one-input time stamping counter (TSC), not the more familiar two-input time interval counter (TIC). '

What's in a name? That which we call a rose
By any other name would smell as sweet;

Confucius believed that failure to rectify names would lead to the collapse of society. This could be the beginning of the end!

Dave

It can certainly lead to Confucion...

I'll get my coat.

Just to say that there's a new forum at

**LINK**

This is set up for discussion related to articles in HSN and related topics, so I have started a thread there to describe progress on this clock. Registration is free.