Improved Experimental Pendulum

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

Don't we all.

Martin.

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

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

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

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

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

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

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

MichaelG.

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

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

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

Thanks Michael!

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

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

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

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

Perhaps the clock is alarmed by your tidiness?