Measuring Clocks

[John Haine]

On John Haine Said:

Dave, I seem to remember using quite a low value of pullup on the opto, an internal Arduino pullup is ~20k IIRC, for fast rise time I used something much lower, possibly 1k or less.

Good call.  Switching on input_pullup hasn’t quite cured the problem.  Looking it up, I find the internal resistor is a much higher value than I expected. 40 – 50k, when I expected no more than 10k.  I’ll try an external 4k7 tomorrow.  Right pain, the clock is on the floor and I have to lay flat in a tight space to work on it. Might not be able to get up again!

Ta

Dave

[SillyOldDufferModerator @sillyoldduffer]

Tale of woe!

I stupidly connected the 4k7 input pullup resistor from the pin to ground instead of 5V.  The red wire was a clue, but no, I did a numpty anyway.  No damage, but it stopped the clock and had me baffled for an hour.  Reconnecting the resistor properly requires me to crawl on the floor in great discomfort, positively dangerous at my age, and it didn’t fix the problem.  Very odd, because the same signal is applied to two pins, one of which always detects correctly whilst the other sometimes misses a pulse.    As far as I can tell with my oscilloscope, the signal is clean: it should work.

Much worse,  the microcontroller crashes intermittently, yesterday taking 22 hours to fail.  Annoying because the Mk1 clock ran for several months with no bother.  This is new.  Chief suspect. I added a log option containing full debuggiing information, much larger than the normal log.   No clues, it just stops, except a hint the BME280 pressure sensor might be faulty.   More likely, a bad statement in my code is overwriting memory, putting garbage into unrelated variables.  Something nasty in the woodshed.

Fixing this is blocking 6 software upgrades, 3 electronic changes, and all the hardware changes.

One of the delayed upgrades is GPS timestamping.   Off-the-shelf, u-blox GPS modules output 1 second pulses and a stream of NMEA messages containing navigational information, salted with time, altitude, satellite and other information.  Useful, but possible to do better.

A u-blox GPS can be told:

1. it’s not mobile, causing it to accurately fix it’s position and improve time accuracy.
2. to accept an external interrupt
3. to generate a timestamp on the rising or falling edge of the pulse. Accurate to about 30nS.
4. what the line delay is (a fine compensation in nanoseconds)
5. to send the timestamp to the microcontroller by I2C or Serial

So, I’ll connect the pendulum’s photo-interrupter to the GPS, and update the microcontroller to configure the u-blox and add the resulting timestamps to the log.  All being well, the clock’s performance can be compared directly to GPS in both short and long-term accuracy.    GPS time leaves all pendulum clocks in the dust, it’s about a million times better.

Measure                           GPS                        Shortt-Synchronome
per Day of UTC            10–100 ns                               1–10 ms
precision                     10⁻⁹ to 10⁻⁸s                          10⁻³s

That a £30 GPS module is an excellent clock is disheartening in a way.  I’m struggling to get anywhere near Shortt-Synchronome performance from my pendulum!  If I’d realised how difficult this was going to be, I would have taken up knitting.

Dave

[John HaineParticipant @johnhaine32865]

Dave, I seem to recall that there is a bug either in the bme library or possibly its firmware, I have a vague memory of seeing mention of it.  As I recall it results in it dropping comms over the i2c link and the library didn’t handle the exception. I think there’s a rather ugly fix where you reset the chip for every reading.  I seem to recall it being mentioned on the r-pi user forum if you want to dig.

[John HaineParticipant @johnhaine32865]

Or maybe reinitialise it every few minutes.  I do recall having some crashes where the Thonny log said something like “failed to find BME280” which just hung my logging program but left the RPi running.  I think the chip sets up pretty quickly so if you are reading even every second it probably wouldn’t hurt to reset it just before each reading.  I did find a few references to the device giving silly readings just before the crash too.

[blowlampParticipant @blowlamp]

Here’s an idea for you Dave. 😉

Martin.

[SillyOldDufferModerator @sillyoldduffer]

As I’m making agonisingly slow progress, Martin’s video was just what I needed for a laugh.   Never take a hobby too seriously, it’s meant to be fun!

The BME280 was innocent.  Problem was 3 bad connections.   The clock was on the floor in a tight corner, and, rather than lift it out so I could see what I was doing, I crawled in and badly wire-wrapped the duff joints by feel.  They were all loose, yuk.   If a job’s worth doing, it’s worth doing well.

Now working on a GPS timestamper, and just getting to the exciting bit – will it work?

uBlox GNSS chips can be configured to output timestamps rather than navigational data.

When a signal is received on the EXTINT pin, the uBlox sends a timestamp to the serial interface.   The signal comes direct from the photogate, which is also connected to the microcontroller.  The microcontroller uses the input to measure amplitude, to trigger impulses, sensor readings and to log results.  The GPS timestamp will be added to the log record, allowing period to be measured ≈30ns, and the pendulum clock’s timekeeping to be compared directly to a UTC clock accurate within 30ns at all times.

I’m struggling to get anywhere near Shortt performance from my pendulum and it’s mildly dispiriting that a £40 GPS module is about a million times better than a Shortt.  Shortt is good for about 30ms per day, compared with 30ns from GPS.  And GPS doesn’t drift, and isn’t upset by vibration or changing temperature and air-pressure.

Is it simple?  No.

🙁

Dave

 

 

 

 

 

[Michael GilliganParticipant @michaelgilligan61133]

Don’t be dis-spirited, Dave

Remember that the £40 GPS is only a receiver !!

The really clever stuff is at the other end, and was “reassuringly expensive” by anyone’s standard.

MichaelG.

[SillyOldDufferModerator @sillyoldduffer]

Still slogging away at this, with a major delay caused by uBlox introducing a two layer security check that stops me activating their uCenter application (used to set the GNSS), reading their documentation, or contacting support to be let in manually.  A smart phone is needed, which I don’t have.  Can’t think why ublox have introduced extra tough security – seems OTT for protecting an ordinary account.

Not having access to ublox meant wasted time looking at modifying available code for earlier GNSS modules, before finding an Arduino library that does the job.  Unfortunately, too big to fit on the AT-Mega 2560 that’s in my clock.  So I switched to a Teesny4.1, which is new-to-me, and ported the code.  Many differences: Teensy is a 32-bit computer, and the 2560 is 8-bit, resulting in many changes.   Then I struggled with the code needed to capture timestamps due to a 3-way bug.   Had to write a simplified timestamp program to pin down the causes, which were simple fixes – just had to do all of them at the same time.

The Teensy is by far the most powerful microcontroller I’ve worked with, but has disadvantages.  Quite expensive and being physically long and thin makes it hard to fit inside the clock with the GPS module and other electronics.  So, having got the code straight on a Teensy, I ported it to a raspberry Pi Pico, which is much cheaper and, being shorter, will be easier to fit into the clock.

The pico port was straightforward except I typed a 1 instead of 4, causing a strange timing error I assumed was interrupt related. I painfully investigated several obscure possibilities, before noticing a simple typo had throttled the GPS.

Results good.  Fed the Pulse Per Second output of a Optronics M8Q GPS module into a pi Pico and Sparkfun MAX10S arranged to timestamp every other second.

_                          Min                Mean                           Max                 Range   STDDEV
GPS Period:       1.999999969  2.000000000026845   2.000000025  56.0ns  11.4111ns

I.e. timestamping measures a 2 second GPS period correct ±28nanoseconds with a standard deviation of 11.41ns.   The numbers aren’t entirely trustworthy because they’re pushing the limits of floating point representation.  Most calculators and spreadsheets think 0.000000000026845 is zero.

Also prepared for the clock’s physical rebuild.  Obtained another vacuum pump, bought soft-iron rod to make a new bob that won’t have magnetic remanence, replaced broken EnderPro 3D printer with a Bambu A1, and I think I have everything needed to tackle the vacuum chamber, apart from replacing the PVC pipe, and that’s in hand.   First have to build the new electronics, 3D CAD a holder, and print it.

Progress painfully slow.  When not off-colour, I have many outstanding domestic duties.   Wish I was a boy of 60 again!

As Michael said: the really clever stuff is at the other end.  All that’s needed is 75 years of high-tech development, 99.999% of it done by someone else!

🙂

Dave

[Author]

Posts