Timekeeping techniques

[david bennett 8Participant @davidbennett8]

Before the “great upheaval” (improvements) on these forums, there were several  advanced timekeeping techniques put forward using arduinos, computers etc. They seem to have stopped. Have any firm conclusions been arrived at regarding the merits or otherwise of these techniques?

dave8

[SillyOldDufferModerator @sillyoldduffer]

Stalled rather than stopped in my case, mainly due to lack of time. My mum broke her hip In Nov22 and returned home in a frail condition needing lots of support.  So a good part of my day is spent travelling and caring, I’m tired out in the evenings, and have my own domestics to sort out.   Pretty much anything that takes more than an hour to finish is on the back burner.

Anyway, my clock project is in stages:

1. Debug mechanical, detector and software issues, then accurately time each beat of pendulum over a few months whilst logging temperature, air pressure, and humidity.  During this phase, the pendulum’s period is measured at about 62.5 nanosecond resolution, and long term drift obtained from with GPS or NTP time standards.   Getting the measurements right is more challenging than I expected, as is deriving the mathematical formula that relates period to temperature, pressure, and humidity!
2. Then,  knowing how the pendulum behaves when temperature, pressure, and humidity vary, should allow the clock’s microcontroller to compensate for environmental changes by applying the formula, with results hopefully more accurate than a mechanical clock.

Having got a formula yonks ago, test results were disappointing.  My compensated clock wandered relative to NTP time, apparently randomly.  It’s accuracy is no better than an ordinary uncompensated pendulum, and worse in the sense that it wanders unpredictably.  Something was wrong!

Looking at the statistical data, I realised that the previous data collection phase was flawed, and I needed to reconnect GPS and do it again properly.  Also, discovered that the Arduino’s ceramic resonator was unexpectedly unstable in the short term, and needed to be replaced with a crystal.  As Michael Gilligan had most helpfully found me a 20MHz TCXO, I took the opportunity to upgrade an Arduino from 16MHz to 20MHz.   More too it than a bit of re-soldering – the software has to be upgraded as well, but better stability and higher resolution.

That done, I restarted the pendulum, only to find it stops after several minutes or hours.   Almost certainly because I moved the clock to test it and the new software on my comfy dining table, and have disturbed the suspension or the wiring.   Not had time to suss out the problem and fix it.   When I can get it going, it will take a few months to collect the data needed to calibrate the compensation, and then another few months to test it.  I’m hoping to maintain accuracy better than 100mS per year, and it takes at least that long to prove it.

A bunch of other improvements have been delayed too:

• The pendulum is supposed to run in a vacuum, which needs some plumbing and a container.  I planned to use a length of plastic soil pipe as the vacuum container, but testing off the clock suggests PVC is unsuitable.  I can’t pull or hold a deep vacuum is a plastic pipe, and suspect that the plasticiser is gassing  (evaporating under the vacuum), and maybe the PVC is porous too.   A metal or glass tube may be essential.
• The basic Arduino module I’m using to detect the pendulum is probably too simple.   Period measurements show surprisingly high variations per beat in the hundreds of microseconds.  Possibly this is because the beam is insufficiently collimated, the basic comparator is too slow, and it doesn’t have a stabilised reference voltage.  I should replace the module with one designed for beam break work.  Not difficult other than I have to cough up for one and find time to install it.

Shortage of time is very frustrating, especially as my poor old brain doesn’t cope well with working in short blocks with long gaps between.  Doing anything complicated, I need peace, quiet and no interruptions for a good few hours solid.   I’ve had to drop most moderation*, and make fewer posts too.

Dave

* Re moderation, big thanks to Jason who does almost all the work!

 

[John HaineParticipant @johnhaine32865]

The very interesting work that Joe Noci is doing has migrated to the HSN forum.  There are other familiar names there too.

My tungsten pendulum clock is on hold at the moment – I’m working with a friend to build a tavern clock “model”, and having got interested in “Barycentric pressure compensation” (BPC) I’m wondering if I can implement this in a clock.  This might involve transplanting the tungsten bob into my “Arduinome”.

People interested might like to know that the HSN forum is free to join and you can get “Horological Science News” free on request including back issues.  Full disclosure: I have become joint editor.  The latest edition of HSN, 2024-1, has just been published and includes an article on BPC.

[Robert Atkinson 2Participant @robertatkinson2]

I’m a timenut, but the electronic sort not mechanical clocks. I have several GPS disciplined oscillators (normally 3 running at any time), multiple oven controlled oscillators, a few atomic standards, 3 high resolution (ps) counters plus other specialised stuff.

The though of usng an Arduino, never mind one with a ceramic resonator, as a time measurement device makes me shudder…

May I suggest that you look at low cost hardware designed for this task by people who really know what they are doing (I’m a novice by comparison). Specifically the PICPET and PICTIC. As the name suggests these use the PIC series of microcontrollers (RISC before it was called that) with highly deterministic firmware.
The PICPET uses a 8 pin PIC costing couple of pounds.
Information here:
http://www.leapsecond.com/pic/picpet.htm

Code and descriptions of specific versions here:
http://www.leapsecond.com/pic/

The pic dividers Tom  wrote code for are really good too. And his website http://www.leapsecond.com is a great resource.

PICTIC is a little more complex. Details here:
http://www.ko4bb.com/doku2015/doku.php?id=precision_timing:pictic
Again Didier’s site is a great resource http://www.ko4bb.com/getsimple/

Robert G8RPI.

[david bennett 8Participant @davidbennett8]

S.O.D., sorry to hear about your mum’s problems. You have all my best wishes.

dave8

[david bennett 8Participant @davidbennett8]

Some of the problems listed do make me kind of wonder whether Heisenberg’s uncertainty principal is poking it’s nose in!

dave8

[duncan webster 1Participant @duncanwebster1]

Speaking from a fairly low standard of knowledge and less understanding, but SOD has replaced the resonator/crystal on his Arduino with a TCXO, which should transform its performance. Can’t see why it wouldn’t be at least as good as a PICPET.

[John HaineParticipant @johnhaine32865]

The picPET runs completely deterministically, so there is no variation of the measured time of an event other than the basic “clock” period which is essentially 4 edges of the input clock that runs normally at 10MHz. Essentially it samples the time of an input event to a resolution of 250nS.  I guess one might write assembler for an AVR processor such as used in an Arduino to do the same but it probably wouldn’t be able to do much else.  The picPET is basically an 8-pin component pre-programmed to do just one task extremely well, and send measurements over a serial link to something like an Arduino or Pi.

[Robert Atkinson 2Participant @robertatkinson2]

Thanks John, that is it exactly.

The PIC has only 35 instructions, most with a fixed execution time in clock cycles. The Atmel (now owned by Microchip the makers of PICs) processors in Ardunios have around 150. Add on a programming language, libaries written by who knows etc and you really can’t know for sure what is going on at low level.

What about acrylic (Perspex) for the vacuum chamber? No plasticisers and you can see the pendulum. Not too expensive either.

Robert.

[Robert Atkinson 2]

On Robert Atkinson 2 Said:

I’m a timenut, but the electronic sort not mechanical clocks. I have several GPS disciplined oscillators (normally 3 running at any time), multiple oven controlled oscillators, a few atomic standards, 3 high resolution (ps) counters plus other specialised stuff.

The though of usng an Arduino, never mind one with a ceramic resonator, as a time measurement device makes me shudder…

May I suggest that you look at low cost hardware designed for this task by people who really know what they are doing (I’m a novice by comparison). Specifically the PICPET and PICTIC. As the name suggests these use the PIC series of microcontrollers (RISC before it was called that) with highly deterministic firmware…

Thanks to John Haine I have a p06 picPET so have been able to compare it with my equivalent, an ‘ARDPET’.   Both depend on the stability and precision of the oscillator,  which in order of loveliness could be a resonator, quartz crystal, TCXO, OCXO or GPS Disciplined oscillator.

I wanted to implement a Precision Event Timer (PET) on Arduino rather than PIC for several reasons, notably:

• If anyone wants to copy what I’ve done, the Arduino family is far more beginner friendly:  the no-soldering needed boards do not require a separate hardware programmer, just a USB cable; compile and link intricacies are largely hidden; the free IDE is straightforward; and there’s a massive support community.   Almost all the code is open source, many cheap add-on modules are available, and the electronics are affordable.
• I wanted to implement a PET inside my clock, not as a separate utility.   Makes it easy to log temp, pressure and humidity at the same time as period is measured.
• If necessary, because I wrote the code, ARDPET can be extended.   For example, picPET is only programmed to count oscillator ticks between two events, whereas ARDPET can count ticks between 2 or more events, to average frequency/period over many cycles.

The instruction set of PIC vs Atmel is irrelevant in this application.   The timing is done in hardware with a Counter/Timer in Input Capture Mode.  A hardware peripheral counts the number of clock cycles between two input events, saves the result, generates an interrupt, and starts again.  The Counter/Timer runs continually irrespective of whatever the software is doing.   All that’s necessary is for whatever the  software is doing to finish before the next interrupt, in my clock about 0.8 seconds.

An advantage of the Arduino processors over PIC (at least the CPU used by picPET), is that they run at 16MHz off-the-shelf, and can be driven at 20MHz.   So a picPET has a resolution of 100nS, whilst an Arduino does 62.5nS, or 50nS at 20MHz.   Further, depending on the chip, Arduino’s come with two or more counter timers that can do Input Capture at the same time.

My clock uses two PETS:

• One measures pendulum period in local clock ticks (accuracy depends on the Arduino’s oscillator)
• The other, optionally, measures the number of local clock ticks per GPS second.

This measures the actual frequency of the Arduino’s oscillator, counted over 1 second, allowing the pendulum period to be measured relative to GPS.   Or it would if the Arduino’s oscillator were stable within the 1 second period!   My mistake was assuming a ceramic resonator would drift predictably, and it turns out they don’t.  Although mine stay close to 16MHz, the actual frequency jumps unpredictably by up to 1.5kHz, and then saw-tooths back to average, where it might or might not stabilise briefly.

My initial testing was done with an Arduino Leonardo, which is fitted with a crystal oscillator, and behaved well.   I switched to an Arduino 2560 with a ceramic resonator because it has more counter/timers and it was useful to have another one generate pendulum pulses whilst bench testing the software.  Unfortunately I didn’t realise just how unstable the 2560’s ceramic resonator was until I looked at the statistics produced by a long run.

ARDPET and picPET produce much the same result when used to time the same event – they both work the same way by counting clock pulses between events in hardware.   Both count 1000000 when a 10MHz OXCO is gated by a GPS second; however gating the Arduino over 100 gps seconds suggests the OXCO isn’t quite spot on.   Having a faster oscillator means the Arduino has higher resolution.

I’ve looked at Nucleo and other chips in hope of finding a seriously fast microcontroller that can also do hardware input capture, perhaps with an external clock.  So far the answer is a lemon!  I’ve not found anything general purpose that combines high frequency, high stability and Input Capture.

Dave

[duncan webster 1Participant @duncanwebster1]

That’s a very good description thanks. Just one last question. John Haine says resolution of PICPET is 250nS, SOD says 100nS.

[duncan webster 1Participant @duncanwebster1]

According to this PICPET has 400nS granularity, whatever that means. Looking at the timing formula for pics there is always a factor 4.

[Peter BellParticipant @peterbell11509]

Dave,

I’m no Arduino expert but have you got round to trying  the ESP 32—seem arduino compatable and faster—at least to me!

 

Peter

[duncan webster 1Participant @duncanwebster1]

Missing http://www.leapsecond.com/pic/picpet.htm

[John HaineParticipant @johnhaine32865]

Originally I thought the picPET resolution was 100nS as it uses a 10MHz clock.  However the internal logic is 4-phase clocked so the instruction time is 250nS which is the resolution or “granularity”.

[duncan webster 1Participant @duncanwebster1]

This

Says the clock going into a pic timer is divided by 4, which would mean an increment of 1 is actually 400nS for a 20 Mhz crystal

[John HaineParticipant @johnhaine32865]

Oops yes, can’t divide now…

 

[Robert Atkinson 2Participant @robertatkinson2]

Most PICs use a minimum of 4 clock cycles per instruction. Thats 200ns resolution (nS is a measure of conductivity) if counting instructions. The input to timers is not pre-scaled (divided) unless specifically selected. The timers in a pic have various conditions on clock rate but a more recent chip like the 16F88x is at least 20MHz without prescaling. They will typically run to twice that.

SOD, Fine on the use of hardware timer(s) as long as the gating is also determined by hardware. I don’t know the Atmel hardware counter architecture so can’t comment further.

Robert.

[duncan webster 1]

On duncan webster 1 Said:

This

Says the clock going into a pic timer is divided by 4, which would mean an increment of 1 is actually 400nS for a 20 Mhz crystal

and I can’t type, should have said an increment of 1 is actually 400nS for a 10 Mhz crystal.

[Peter Bell]

On Peter Bell Said:

… have you got round to trying  the ESP 32—seem arduino compatable and faster—at least to me! 

Peter

Yes, but not for this particular application (accurate timing).    The ESP modules are a ‘System on a Chip’, based on a fast 32bit controller.  They come with General Purpose Input Pins and a built-in WiFi, but lack a hardware counter/timer that does Input Capture.  They’re a good choice if fast GPIO and wifi are needed, but are otherwise a bit lacking.

The Nucleo range is another fast alternative.  They’re based on the tasty STM32 microcontroller, which does have hardware counter-timers, but they don’t do Input Capture.  (Unless anyone knows different!)   They have pretty much everything else though, including a hardware floating point accelerator – but Wifi needs an extension board.

Robert and John have already pointed out another potential problem with fast microcontrollers used for time measurement, which is they’re not time consistent.  The picPET and 8 bit Arduino chips have straightforward electronics that execute instructions in a predictably fixed time.  Modern chips increase average speed by pulling a variety of fancy tricks, such as pipelining, or altering clock speed on the fly,  but these methods reduce predictability – the same instructions execute in slightly different times.  It makes design tricky – necessary to be certain time critical functions perform in all circumstances.

Though super-fast, the microprocessors used in PCs are even worse.  They pull every trick in the book to increase speed, and are built to supporting mutli-tasking and strong security, not home electronics.  They’re even less time predictable than fast microcontrollers and usually don’t have any accessible GPIO or simple internal peripherals that can be used for simple projects.   Instead, they communicate through various buses, like USB, PCI, SATA etc, which talk to complex  peripherals at a high-average speed.   Blindingly fast, but the timing isn’t accurate or precise.

Boards like BeagleBone and RaspberryPi are an interesting possibility.  Although built with a PC-like bus focussed microprocessor, they also have limited microcontroller capability, so a multi-tasking program can talk to individual pins, and a few internal peripherals.  Again, not time predictable, and these boards have limited control features compared with a dedicated microcontroller.

For most hobby purposes ESP, Arduino, BluePill, Nucleo and others are often interchangeable.  But when something unusual is afoot,  some chips are better suited than others.  Their datasheets can be hundreds of pages of heavy reading, and life is short.

Texas sell a development board which appears good for what I’m doing, except it’s expensive and would be a steep learning curve.   I think the Arduino Due is a strong candidate – a 96MHz board with a 32 bit counter/timer and Input Capture.   Not had time to check the data-sheet carefully yet, and it’s nearly £40 down the drain if misunderstand it!

Dave

 

[John HaineParticipant @johnhaine32865]

pi Pico?

[Robert Atkinson 2Participant @robertatkinson2]

The Pico does at least have a datasheet for the microprocessor unlike the Broadcom basied Pis.
There is no dedicated hardware counter though. There is a 64 bit timer but it uses an internally derived 1us clock. There is a 16 bit counter in each of the PWM channels which can count external signals but they seem to have at least a divide by 4 prescale. I won’t be buying a pico so have no motivation to dig further into the capabilites or limitations of the PWM module.

Robert.

[John HaineParticipant @johnhaine32865]

Next clock will have Pico rather than Arduino.  Lower power consumption and using the PicoW get Bluetooth and WiFi.  On-board power management much better designed for battery operation, runs from 1.8 – 5.5V with on-board buck/boost converter.  And it doesn’t have that pesky permanent-on power LED which is only useful for about 10s when you get your first Arduino!

[John Haine]

On John Haine Said:

Next clock will have Pico rather than Arduino. …

The Pico is powerful and amazingly cheap!  I had high hopes it would do what I need, but seems not:

• ARM based chips don’t come with a standard set of peripherals.  ARM are odd in that they don’t make chips themselves: instead they license the ARM core to chip manufacturers who surround the core with their peripherals.   Makes it hard to find out what’s inside an ARM based microprocessor, and they’re all different!
• The RP2020 is no exception.  pi have put two ARM cores on one chip, plus GPIO, USB, Serial, and some other common stuff.  There’s also a PIO containing 4 independent state machines, that can each be programmed to produce other interfaces.
• The Timer appears to be very simple:  any of several different system clocks drives a 64 bit counter, and one of them is already available as the system clock.  So if you want to time a pendulum, program a GPIO pin with an interrupt that subtracts the previous interrupt time from the current interrupt time.   Trouble is, as Robert says, the timer increments in microseconds, giving less resolution than an Ardiuno, grrr.    On the other hand,  the pico micros() function is 4x better than the ordinary Arduino boards, which count time in 4uS ticks.
• I’ve an idea the PIO could be programmed to do precision timing, except I don’t understand it!!!   The state machines are programmed with only 13 instructions, but how they work is beyond me.  So different from anything I’ve done before that the manual might just as well be written in Martian!

🙁

Dave

[Author]

Posts