Improved Experimental Pendulum

[An OtherParticipant @another21905]

Its a little surprising to see the online NTP being used as a timing reference. Surely the 60Khz signal from NPL in Cumbria is far more accurate (1 part in 10-12 – more data in Wikipedia)?. The 60Khz signal can be received almost everywhere in the UK and Western Europe., and it is very easy to build a simple receiver with ferrite rod antenna.

Back in the 60's, we built a receiver using a single CMOS Nand gate as a receiver for this signal (The A-series gates could be used in a linear mode, much like an op-amp).

At least it would not be subject to the vagaries of the internet.

Many other countries also operate a similar service.

[SillyOldDufferModerator @sillyoldduffer]

Posted by Alan on 10/05/2023 10:24:42:

Have you tried running your own NTP server on your local network..??

This would give a lot less jitter (due to using the greater internet..)

Seems to be fairly easily done on a Raspberry Pi

https://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

is just one of many google hits on the subject….

I hope that I haven't sent you down another rabbit hole!!

 

Alan

Not yet Alan, but it's on my list. I have the necessary bits. I judge it to be a rabbit hole at the moment because my clock isn't accurate enough to challenge plain NTP yet. But if the clock improves as I hope, I will need to soup up NTP.

Worth repeating that althoughNTP isn't a good way of measuring individual beats, it is good for measuring pendulum clock performance over days, months, and years. From memory, I think the Shortt-Synchronome managed 8mS per year, compared with my Pi which in theory is always within 100mS, but in practice during the test run was within 30mS. In other words, over a year, NTP on an ordinary Raspberry Pi, is in the same ball-park as the best pendulum clock in the world. Further, synchronising NTP to GPS on the same Pi puts it into the 1mS region, roughly 8 times better than the best a Shortt-Synchronome could do.

I shall be pleased if I can get my clock to stay within 0.1s of UTC on a plain Pi, and ecstatic if the clock is good enough to force me to improve ordinary NTP. Unlikely I fear, but let's see.

As with all measurements, the tool should be about 10x more accurate than the object being measured.

Individual beat times are also interesting, and these are measured with a quartz crystal, which I can calibrate against to GPS once per second. Ordinary 100ppm Crystals are stable enough for indicative measurements down to about 0.1 microseconds, but poor over longer periods – worse than a cheap quartz kitchen clock.

Beyond what I'm up to, time nuttery gets even more exotic. Pendulums were surpassed as time-keepers in the 1930s by various electronic methods, each of which have in turn been surpassed by ever more accurate methods. Electronic oscillators took over from pendulums before pendulum clocks were fully developed, leaving the interesting possibility that an amateur could make a pendulum clock better than a Shortt-Synchronome, Reifler, Fedchenko, or similar high-end precision clock. It's a challenge!

Dave

 

Edited By SillyOldDuffer on 10/05/2023 11:49:45

[SillyOldDufferModerator @sillyoldduffer]

Ho hum, another lack of progress report.

Although the pendulum is running well, Q a little under 14000 with low deviation, I've been bedevilled by a series of small software bugs, all due to 'improvements' made by me. They take an age to discover because it's necessary to let the pendulum swing undisturbed for at least 12 hours, ideally longer, to get meaningful statistics.

Each time I check the stats the pendulum is good, but the clock is wrong! The symptom is faulty drift correction, which is annoying because constant drift is the easiest compensation in the book. Trouble started when I switched from compensating in microseconds to compensating in 62.5nS ticks for more resolution (0.0625uS is 16x 1uS). Then I got plus and minus the wrong way round, and today's result shows drift compensation is ignored.

I blame distractions! I was rung up, tired, or rushing to go out every time I tweaked the code. So restarted the clock with compensation OFF to get a clean baseline, whilst I look for software bugs AGAIN.

Meanwhile, the parts needed to plumb the vacuum have all arrived apart from the vacuum gauge and its adaptor. next job is to check what's happened to the order. UK supplier, so I hope it's not stuck on a slow boat from China.

Dave

[blowlampParticipant @blowlamp]

Dave.

I just came across my copy of Philip Woodward's book, My Own Right Time.

I see that he managed to achieve an accuracy of 1 second in 100 days without enclosing the pendulum in a vacuum chamber. However, what he did find to be important was to blend or radius the edges of the cylindrical bob to reduce air turbulence.

Martin.

[SillyOldDufferModerator @sillyoldduffer]

Posted by blowlamp on 21/05/2023 12:11:36:

Dave.

I just came across my copy of Philip Woodward's book, My Own Right Time.

I see that he managed to achieve an accuracy of 1 second in 100 days without enclosing the pendulum in a vacuum chamber. However, what he did find to be important was to blend or radius the edges of the cylindrical bob to reduce air turbulence.

Martin.

Yes, I wasn't pleased to find that my cylindrical bob is worst aerodynamic shape!

I toyed with the idea chamfering it in this build, but didn't because I hope my vacuum plan will work. If if does, not removing metal is an advantage because the weight is helpful.

Bob design is more complicated than I realised, so at this stage I've kept it simple. There's a lot I don't understand. Just for starters, mild-steel isn't the ideal material either. In the event the vacuum idea fails, there are a lot of bob ideas to try. Tungsten, for example!

I did improve the bob over a simple cylinder in this version though. It's now suspended from the rod at its centre point, not at the bottom, and the rod is unconstrained at the top. If the rod lengthens due to warming, the top half of bob expands in the opposite direction, providing partial temperature compensation. Seems OK, I feared it would wobble.

Dave

[blowlampParticipant @blowlamp]

There's some interesting and maybe pertinant stuff here in an article about Philip Woodward's W5 clock.

Martin.

[SillyOldDufferModerator @sillyoldduffer]

Thanks Martin, I wish I had the skills to build a W5.

Just checked my own clock and it still wasn't keeping time. However, I reckon I've found the bug,so maybe the next run will make sense, fingers crossed.

Nothing wrong with the code, except 6 lines were run late, opening a window during which period could be mangled, basically because the pendulum was working before the clock was ready. Bug introduced after I changed the way the clock starts to allow for a heavier bob.

Dave

[blowlampParticipant @blowlamp]

Posted by SillyOldDuffer on 22/05/2023 18:36:11:

Thanks Martin, I wish I had the skills to build a W5…

Dave

Don't we all.

Martin.

[SillyOldDufferModerator @sillyoldduffer]

This morning's graph is looking much better:

To test the code I ran the clock with compensation switched off. In this state the graph should show straight-line drift with deviations due to changing temperature. The graph is consistent: it show rate of drift falling overnight as the temperature drops. (The pendulum should speed up when the rod shortens due to cooling.)

Too soon to break out the Champagne, so I'll leave it running for another day to make sure. If all good tomorrow, I'll switch the compensation on.

Meanwhile, a couple of bugs to sort out in the logging program. It crashes when sent an illegal empty command, and there's something not quite right with the way it calculates synchronisation times.

One of the two missing components needed to build the vacuum system turned up this morning. The vacuum gauge was accidentally missed off the order by guess who, so I had to start again.

Still dithering about sealing details, which reminds me, I'm nearly out of 1" Brass Rod.

Dave

[SillyOldDufferModerator @sillyoldduffer]

More distractions, big chunk of yesterday spent with a relative in hospital, visiting mum today, and I've been jabbed against pneumonia.

However, just looked at the clock, which is running with drift compensation only, that part now seems to be working OK.

Until after 19:00 yesterday the clock ran uncompensated on average period, drifting about 5 secs in 20 hours. The blue cliff-edge is me resetting the clock to UTC, about 0.2 out because I didn't bother to correct it closer. Then the clock gains slightly until dawn, when the temperature rises and it speeds up. Since about 8am it's been about 2 seconds fast. Very tempting to switch temperature and pressure correction on, but better to let the sensors collect more data whilst the weather happens to be providing some decent temperature and pressure swings for the statistics to chew on.

Although drift correction looks good now, I'm not sure why it's necessary at all. The analysis calculates the pendulum's average (and median) swing times, and compares them with a more accurate clock (NTP). That gives my clock's 'should be' average, which is fed back to the clock. As the pendulum's actual period doesn't vary much (stdev 0.000052s), and the distribution is balanced, I don't understand why the clock drifts in a more-or-less straight line away from NTP. Must be a constant error somewhere in the system and it needs to be identified.

Always more to do!

Dave

[John HaineParticipant @johnhaine32865]

I'm now worrying about how to design my own opto interrupter with lower ambient light sensitivity. IIRC someone referred, possibly in this thread, to a clockmaker that used thin tubes as collimators for photodiodes – if I'm right could someone point to the reference please?

[Michael GilliganParticipant @michaelgilligan61133]

Posted by John Haine on 26/05/2023 07:33:03:

I'm now worrying about how to design my own opto interrupter with lower ambient light sensitivity. IIRC someone referred, possibly in this thread, to a clockmaker that used thin tubes as collimators for photodiodes – if I'm right could someone point to the reference please?

.

It was me that mentioned it John, based on a brief conversation with Jim Arnfield

MichaelG.

.

Edit: __ see here https://www.model-engineer.co.uk/forums/postings.asp?th=171748&p=4

Edited By Michael Gilligan on 26/05/2023 14:02:41

[S KParticipant @sk20060]

Maybe use a laser instead of a puny LED, and then put a neutral-density filter in front of the detector. This should increase the signal to noise.

Edited By S K on 26/05/2023 15:42:50

[AlanParticipant @alan14594]

Just a thought…

Switch the LED on and off with a fast square wave (within the bandwidth of the opto devices…), and detect when the pulses disappear… the ambient light shouldn't then be a problem

[SillyOldDufferModerator @sillyoldduffer]

Couple of good ideas from Alan and SK, both of which I've tried!

• The Laser idea works, but the beam is incredibly bright compared with a LED, and it has to be filtered exactly as SK suggests. Though I didn't get it to work, I'm sure it's possible. I failed because the laser outputs a sharp frequency, which none of my photo-transistors were tuned to. It appears photo-transistors respond across a broad range of frequencies, either favouring visible light over IR or vice versa, but sensitive to both. They all detected the laser, but I couldn't find a filter material that attenuated the laser and blocked ambient light in a balanced way. I abandoned the laser because I couldn't get it working quickly, and because the tube idea was an instant success. I still think it has considerable merit because the beam is highly collimated.
• Alan's idea is used by TV remotes. The IR beam is switched at about 38kHz, so the receiver can filter the didger's control signal out from moderately bright sunlight. Works pretty well, but the disadvantage is 38kHz, reduces time resolution to ±26uS at best, actually worse because the detector takes several cycles to reliably detect the 38kHz signal, probably over 100uS. Too slow for my purposes, where I'm chasing 100nS, which is 1000 times faster. To get the speed I decided it was easier to detect an ON/OFF signal screened from ambient. Which isn't that easy either!

Meanwhile, pleased to report my clock is behaving at last. Running without compensation it's 1.3 seconds fast after 40 hours (8.3ppm). Q is 19549. Drift wanders about a horizontal line, which is good, and the wander correlates with pressure and temperature changes.

Few things need attention. Until now, it's been good enough to drive the gear train (which is mathematical) with a period of microsecond resolution, limited to ±1uS. The latest run brings the period correction to 9uS, meaning my maths are getting close to causing rounding errors. I think it's worth increasing resolution by 10 or 100 to avoid that.

Also now it's keeping better time, I ought to add an on-board HH:MMS display ready for when the clock runs free-standing.

Bug found in the synchronisation code, which only works if my clock and NTP differ by more than ±999999uS. Also, a logic flaw: transmission time needs to be allowed for when synchronising. Not sure how to fix this reliably and it may limit how close my clock can be set to NTP in the first place – at the moment setting can be up to 0.12s out, which is terrible.

This is the first time the improved pendulum has shown what it can do without a software or configuration mistake messing up the statistics. Two small beam break anomalies in 248903 beats, neither causing significant error. Something odd about the amplitude calculation too but it doesn't affect timekeeping. Fingers crossed it's not a false dawn!

Dave

[Michael GilliganParticipant @michaelgilligan61133]

John has already rejected the idea of using a modulated source.

MichaelG.

[Michael GilliganParticipant @michaelgilligan61133]

[ PostScript ]

I have just found the reference:

John’s comment towards the bottom of this page: **LINK**

https://www.model-engineer.co.uk/forums/postings.asp?th=184730&p=16

MichaelG.

[S KParticipant @sk20060]

Silicon photodiodes, if that's what you are using, don't function at all in the infra-red (i.e., longer than about 1100 nm). There isn't enough energy in those photons (Ge or GaAs and others do work lower down).

I don't quite follow your "tuning" point. A neutral density filter cuts all visual wavelengths equally, or it wouldn't be neutral – it would have a color. So it should cut all stray light (e.g. white light) as well as the source light of any color uniformly, without any tuning being needed. Something like a 3 or 4 stop (8x or 16x) ND filter should help a lot, and you can get much stronger ones too. I'd say this is a better approach, and certainly much cheaper, than seeking a matching narrow-band filter. Those wouldn't cut in-band stray light anyway, after all.

So then all you need is a source that is a lot stronger than ambient light. The color of that source, including if it's monochromatic or not, shouldn't matter much as long as it's bright. So a strong red or green or white or whatever LED or laser should be fine.

No?

[SillyOldDufferModerator @sillyoldduffer]

Posted by S K on 27/05/2023 05:37:25:

Silicon photodiodes, if that's what you are using, don't function at all in the infra-red (i.e., longer than about 1100 nm). There isn't enough energy in those photons (Ge or GaAs and others do work lower down).

I don't quite follow your "tuning" point. A neutral density filter cuts all visual wavelengths equally, or it wouldn't be neutral – it would have a color. So it should cut all stray light (e.g. white light) as well as the source light of any color uniformly, without any tuning being needed. Something like a 3 or 4 stop (8x or 16x) ND filter should help a lot, and you can get much stronger ones too. I'd say this is a better approach, and certainly much cheaper, than seeking a matching narrow-band filter. Those wouldn't cut in-band stray light anyway, after all.

So then all you need is a source that is a lot stronger than ambient light. The color of that source, including if it's monochromatic or not, shouldn't matter much as long as it's bright. So a strong red or green or white or whatever LED or laser should be fine.

No?

Yes. I don't disagree. I'm sure a laser can be made to work with advantage. But my trial didn't work out, and I hypothesised why not. I'm sure the issue was the mismatched components I happened to have at hand, for example my 'neutral density filter' was a bit of black plastic, exact properties unknown.

Dave

[Martin KyteParticipant @martinkyte99762]

Probably the most convenient way of isolating the system from much of the ambient light is to couple your optical receiver to a fibre optic cable which will typically have an acceptance angle of around 14 degrees. This allows the electronics to be mounted remotely too. As I see it the issue is that the variation in ambient light adds to the light from the transmitter and effectively shifts the threshold at which the receiver switches. As the apertures are of finite size the sensor will switch earlier or later accordingly.
Regards Martin

[John HaineParticipant @johnhaine32865]

Posted by Michael Gilligan on 26/05/2023 13:59:14:

Posted by John Haine on 26/05/2023 07:33:03:

I'm now worrying about how to design my own opto interrupter with lower ambient light sensitivity. IIRC someone referred, possibly in this thread, to a clockmaker that used thin tubes as collimators for photodiodes – if I'm right could someone point to the reference please?

.

It was me that mentioned it John, based on a brief conversation with Jim Arnfield

MichaelG.

.

Edit: __ see here **LINK**

Edited By Michael Gilligan on 26/05/2023 14:02:41

Thanks Michael!

[Martin KyteParticipant @martinkyte99762]

Post Script

I suppose if you really want to get clever you should build your own optical receiver and adjust your trigger point to vary according to the ambient light at the photodiode. Probably means turning the transmitter off for a short time each swing. The other thing to recognise is if there is hysteresis in the switching threshold, which there should be, the On and Off points will not coincide in space.

regards Martin

[SillyOldDufferModerator @sillyoldduffer]

Clock still performing well. After subtracting the synchronisation error, it's 1.128s fast at the moment. However, although drift is averaging near to zero, my clock and NTP differ by up to 2.5s, and my clock is always a bit fast. The variation in time difference mostly due to pressure and temperature changes, so turning compensation on and sacrificing a virgin should fix it. Not sure what's causing my clock to consistently run a little faster than NTP; I expect it to run 50/50 faster and slower than NTP. Could be because average temperature is rising as the UK moves from spring to summer, so the average period has changed slightly since calculated a few days ago. If so, the swiching compensation on should fix it.

Think I know what's wrong with my synchronisation code – I'm sending half the required value.

Dave

Edited By SillyOldDuffer on 27/05/2023 10:23:35

[duncan webster 1Participant @duncanwebster1]

Posted by Martin Kyte on 27/05/2023 09:00:25:

Post Script

I suppose if you really want to get clever you should build your own optical receiver and adjust your trigger point to vary according to the ambient light at the photodiode. Probably means turning the transmitter off for a short time each swing. The other thing to recognise is if there is hysteresis in the switching threshold, which there should be, the On and Off points will not coincide in space.

regards Martin

That's a good idea, 2 identical (not Schmidt) switches next to each other, use a comparator to sense when their outputs differ by a lot

edit: just dawned on me, in my clock I have 2 slotted optos one central to trigger the magnet, one offset to sense swing. I can compare the two of them if I swap to non Schmidt. It's on the list for next rebuild. 

Edited By duncan webster on 27/05/2023 11:33:04

[SillyOldDufferModerator @sillyoldduffer]

Ho, hum, bum!

Latest result not good:

As can be seen, the uncompensated clock kept reasonable time for 2.5 days with bumps explained by the weather, then at midday it started losing time in a near straight line, i.e. constant drift.

I have no idea why. Nothing happened at midday, and the drift isn't obviously related to temperature or pressure. The pendulum seems OK. Nor is NTP to blame. Possibly my logger program or the operating system is introducing a delay. Or drift correction has mysteriously turned itself off. (Thinks – overflow?)

Another oddity is ringed in red. Just after midnight the rate of drift slows until about dawn. Could be daylight or temperature related.

Although the parts needed to build the vacuum enclosure have all arrived, I see no point in sucking air until this latest problem is fixed.

About 25% into a giant tidy-up too. Tedious and tiring, and I haven't started on the workshop mess yet!!!

Dave

[Author]

Posts