Ms resolution timer using dev board

[alepagliaccio]

Hello, as the title suggest I need help with a ms resolution timer. The main goal here is building a sport chronometer. I've done some tests with an esp32 running: micropython, arduino and freertos and was not satisfied by the results. Here are my requirements:
-at least 2 ms digit.
-can work with low and high temperature (under zero in winter and under the sun in summer maybe?)
-ability to sync 2 or more devices, as of know the devices we use can be synced at the begining before we setup all the wires to register the times and stuff, I want something like that, no need to sync wireless. As of now using a ds3231 1hz wave to sync the second is not helping because I can't find a way to reset the wave to make sure all devices have the same second scanning, so proably will have to replace also that with maybe a gps to make sure the pps is always synced without needing more setup

As of now what I tried:
Using a ds3231 1Hz wave to sync the 1 second mark and reset the timer every 1 second, from my tests I often got 999 ms instead of 1000 with all software solutions I tried, using both software and hardware timer, and also 1 wrong ms when pressing the same button connected to 2 devices, it looks like their timer is highly unprecise. I'm starting to think that the 1hz wave may be the unreliable one? Unfortunately I do not have an oscilloscope to test that, maybe I should get a cheap one at least? With arduino as I already mentioned when pressing the same button I was getting the last ms digit wrong more often than not so that still without the 1hz wave was no good. I think I will try now doing the same test with freertos hoping to get maybe something different but I doubt it. I'm trying to find a solution for more than a month now.

With my last implementation using the ds3231 32k crystal as external clock with esp-idf I get reliable results until it just after some time loses 10ms with no real reason, 1hz wave being the bad one? Not sure.
I've read a lot about gpsdo here on the forum and know it may be overkill, but that looks super reliable and I found many cheap solution that promise great resolution, should I go that way? I was looking in particular to Andrew's stm32 gpsdo which relies on a board I have + a ocxo that should allow me a good operation on a wide of temperatures.
Thanks in advance for anyone that takes the time to read this.

[xvr]

It is not clear how you plan to use multiple devices? You want to measure time intervals between different devices? Start interval on one and end it on another?
In this case you need some form of communication between them, not only synchronized timers.

As for timer synchronization - you should use hardware facility for this, not software. For example, you can start hardware timers (high speed, not Hz) on all devices at once (by some hardware/software means) and get they current counter in future. But not stopping them.
You can feed timers from OCXO if you need high precision.

[alepagliaccio]

Sorry for bad explanation. I need to start the timer at the same time on multiple devices at the beginning so they are in sync, then they will be placed in different spots, and at the end I will compare logged timestamp to calculate the differences that took people to get from one to the other.

How would I go on about using an external ocxo and configure a board to use that as reference for a timer? I have Arduino, esp and stm32 so any solution would be great if there's resource I can study/follow to understand what to do and what I'm doing. I've been on this for 2 months but I still feel lost on how to do this because I can't really find anyone trying to accomplish a ms timer where precision is a must, probably I'm bad at searching for it. Using a gpsdo would be overkill? That would also sync with local time that would be a plus and assure that over time it would maintaing time accurately but the competition lasts max 12hours + maybe I'm misunderstanding what a gpsdo for and has nothing to do with counting time but only for hz accuracy which is related but is for something else? Sorry for the dumb questions, I'm trying to learn but coming from a computer science environment the hardware part is not well known to me. Thanks in advance

Edit: the devices Will log the timestamp with an interrupt. I wanted then tò send the log via lora to then upload everything on a database. That part Is already working. The issue is Just the timer as of now

[shapirus]

How long are the measured time intervals expected to be?

2 ms error on a 1 second interval and 2 ms error on a 5 hour interval mean quite different precision and accuracy requirements.

[BennoG]

How long are de devices separated before you join them again to compare the timers.
If for more than 10 second (what is almost certain), The boards are probably battery powered.

I would go for a X-tall oscillator for the CPU and a timer interrupt at 10 or 20 kHz. (at the interrupt increment a counter and check the trigger input). If the input changes from low to high record the value of the counter (have a table so you can record at least double the amount of rising flanks than you expect)
At the start sync pulse reset all counters to 0 zo all counters are reset at exactly the same time (you will have a jitter on this for the interrupt frequency)

Then calibrate the different boards to see how far every board drift over the period you expect the boards to be separated.
Use this drift to compensate the final results afterwards (don't do it on the board)

Benno

[alepagliaccio]

I would theoretically Need zero ms Lost in 12hour if that's not too much to ask on a budget. I still don't get if a gpsdo would help in this or that's for another purpose, from my understanding Is used tò stabilize a Crystal so that in my mind would be what i Need

[alepagliaccio]

I tried using a timer interrupt with only the internal timers of the board that I think make use of a xtal, i have registered random 100/10ms Lost once in a while which Is not optimal. Maybe an external ocxo would fix that? It may be my 1hz square wave from the ds3231 which is causing my measurement to fail also...

[shapirus]

I would theoretically Need zero ms Lost in 12hour if that's not too much to ask on a budget.

That's too much to ask on any budget, because there can't be zero, really.

A deviation of +/-1 ms per 12 hours is about +/-25 ppb. This already takes you into the TCXO area. And on top of that you will need a clock reference that other clocks will synchronize with.

It doesn't sound like an easy task. One idea would be to have a GPSDO receiver whose 1 pps output would be fed into a computer (an SBC will do) running an NTP server using that 1 pps signal as a disciplining reference (e.g. https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html), and then have all of your branch devices run their own ntp servers synchronizing to the central one. Synchronization, however, is the tricky part, as network may be slow and/or unstable. It may not give the required short-term accuracy.

Another way, I think, a more feasible one, would be to run NTP servers on all the devices and distribute the 1 pps signal from the GPSDO to all of them. That should keep them in sync as far as the wall clock setting goes and provide the required stability (even with regular crystals I think), both short and long term. One problem here is how to distribute the 1 pps signal. Radio? What latency and jitter will it have? That would definitely need testing.

Yet another problem is how do you validate your setup, once everything is ticking? How do you tell that two clocks e.g. one kilometer apart from each other are actually in good sync? Send a pulse over a wire or radio and make both record their current timestamps, then compare them? That might work, as long as it doesn't take too long for the signal to get from source to destination (1 ms per 300 km in air, ~200 km in copper).

Then you also need to care about your trigger hardware and software latency. Whatever it is, it must have a consistent delay between the trigger signal and the moment of acquiring the current timestamp. That's a big deal on its own, independent of the time sync problem.

[alepagliaccio]

I would theoretically Need zero ms Lost in 12hour if that's not too much to ask on a budget.

That's too much to ask on any budget, because there can't be zero, really.

A deviation of +/-1 ms per 12 hours is about +/-25 ppb. This already takes you into the TCXO area. And on top of that you will need a clock reference that other clocks will synchronize with.

It doesn't sound like an easy task. One idea would be to have a GPSDO receiver whose 1 pps output would be fed into a computer (an SBC will do) running an NTP server using that 1 pps signal as a disciplining reference (e.g. https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html), and then have all of your branch devices run their own ntp servers synchronizing to the central one. Synchronization, however, is the tricky part, as network may be slow and/or unstable. It may not give the required short-term accuracy.

Another way, I think, a more feasible one, would be to run NTP servers on all the devices and distribute the 1 pps signal from the GPSDO to all of them. That should keep them in sync as far as the wall clock setting goes and provide the required stability (even with regular crystals I think), both short and long term. One problem here is how to distribute the 1 pps signal. Radio? What latency and jitter will it have? That would definitely need testing.

Yet another problem is how do you validate your setup, once everything is ticking? How do you tell that two clocks e.g. one kilometer apart from each other are actually in good sync? Send a pulse over a wire or radio and make both record their current timestamps, then compare them? That might work, as long as it doesn't take too long for the signal to get from source to destination (1 ms per 300 km in air, ~200 km in copper).

Then you also need to care about your trigger hardware and software latency. Whatever it is, it must have a consistent delay between the trigger signal and the moment of acquiring the current timestamp. That's a big deal on its own, independent of the time sync problem.

I read about some gpsdo here on the forum also on a budget that claim 1 ppb (stm32 gpsdo), if all devices had a gpsdo in them, wouldn't that allow me to count ms pretty reliable as they also would be synced to the GPS itself?? We are already using some devices that track ms over many hours, they claim to be reliable but they all use wires so need more people to operate them. 12hours was an exaggeration. Also I would need high precision of the first 2ms, the third digit would be great but as of now the devices we use also do not include that. Sorry if I'm repeating myself. Connecting to an ntp server would not feasible if the mobile data has no network that may happen. So they should be able to operate on their own reliable. For validating tests I would first do extensive tests with the devices close to each other to see if there's some drifting or something happening over the course of hours.

[xvr]

No. gpsdo will lock for frequency, not phase. You need phase, not frequency.

[shapirus]

You need phase, not frequency.

Actually both, if there is more than one device or absolute time measurement accuracy is super important.

Syncing frequency between the devices can be done using the 1 ppb signal emitted by a master device and received by slaves or using an individual GPSDO unit per each device.

Syncing phases is another task. NTP over LAN could probably be a solution. Needs testing.

[xvr]

Frequency precision could be much less, than phase - frequency error is not accumulated. CPU quarz frequency precision could be enough

[ledtester]

...
-ability to sync 2 or more devices,
...

Here's an idea I got from reading the docs of a GPS device which might give you some ideas...

You have a one device which is responsible for keeping the true time - call this the master clock. All of the other devices (client devices) are keeping their own clocks (like through a microsecond / millisecond counter). To synchronize a client with the master clock the following happens:

1) the client signals the master through a GPIO line
2) the master clock captures the time stamp of when step 1 happened
3) the master clock transmits this time stamp to the client

The latency in step 2 can be reduced to perhaps a few CPU clocks through DMA or an input capture interrupt and step 3 is not time critical.

The client knows when step 1 occurred (according to its internal clock) and then can adjust for the time difference between its clock and the master clock.

This is very much like an SPI interaction with step #1 being the pulldown of a /CS line.

Also, the master and client don't have to connected all the time - they only need to be connected for this interaction which is useful if the clients are in physically different locations.

[alepagliaccio]

You need phase, not frequency.

Actually both, if there is more than one device or absolute time measurement accuracy is super important.

Syncing frequency between the devices can be done using the 1 ppb signal emitted by a master device and received by slaves or using an individual GPSDO unit per each device.

Syncing phases is another task. NTP over LAN could probably be a solution. Needs testing.

Won't phases stay synced if they get synced at the beginning? Lan could hardly because they could be placed pretty far away.

[alepagliaccio]

Frequency precision could be much less, than phase - frequency error is not accumulated. CPU quarz frequency precision could be enough

What approach would you suggest?

[alepagliaccio]

...
-ability to sync 2 or more devices,
...

Here's an idea I got from reading the docs of a GPS device which might give you some ideas...

You have a one device which is responsible for keeping the true time - call this the master clock. All of the other devices (client devices) are keeping their own clocks (like through a microsecond / millisecond counter). To synchronize a client with the master clock the following happens:

1) the client signals the master through a GPIO line
2) the master clock captures the time stamp of when step 1 happened
3) the master clock transmits this time stamp to the client

The latency in step 2 can be reduced to perhaps a few CPU clocks through DMA or an input capture interrupt and step 3 is not time critical.

The client knows when step 1 occurred (according to its internal clock) and then can adjust for the time difference between its clock and the master clock.

This is very much like an SPI interaction with step #1 being the pulldown of a /CS line.

Also, the master and client don't have to connected all the time - they only need to be connected for this interaction which is useful if the clients are in physically different locations.

That could be an idea but doesn't fix the drifting issue that I faced when testing a single unit without even taking syncing into consideration. I was thinking of gpsdo because like that all devices where having a really good clock on their own without needing an external device that may be far away so hard to reach without delays or such

[Old Printer]

As of now what I tried:
Using a ds3231 1Hz wave to sync the 1 second mark and reset the timer every 1 second, from my tests I often got 999 ms instead of 1000 with all software solutions I tried, using both software and hardware timer, and also 1 wrong ms when pressing the same button connected to 2 devices, it looks like their timer is highly unprecise. I'm starting to think that the 1hz wave may be the unreliable one? Unfortunately I do not have an oscilloscope to test that, maybe I should get a cheap one at least? With arduino as I already mentioned when pressing the same button I was getting the last ms digit wrong more often than not so that still without the 1hz wave was no good. I think I will try now doing the same test with freertos hoping to get maybe something different but I doubt it. I'm trying to find a solution for more than a month now.

Most of this is above my pay grade, and sorry if this is a given… are your “buttons” properly denounced either in hardware or software?

[alepagliaccio]

As of now what I tried:
Using a ds3231 1Hz wave to sync the 1 second mark and reset the timer every 1 second, from my tests I often got 999 ms instead of 1000 with all software solutions I tried, using both software and hardware timer, and also 1 wrong ms when pressing the same button connected to 2 devices, it looks like their timer is highly unprecise. I'm starting to think that the 1hz wave may be the unreliable one? Unfortunately I do not have an oscilloscope to test that, maybe I should get a cheap one at least? With arduino as I already mentioned when pressing the same button I was getting the last ms digit wrong more often than not so that still without the 1hz wave was no good. I think I will try now doing the same test with freertos hoping to get maybe something different but I doubt it. I'm trying to find a solution for more than a month now.

Most of this is above my pay grade, and sorry if this is a given… are your “buttons” properly denounced either in hardware or software?

Just button on a breadboard attached to an interrupt on both board that just prints the timer value. I made it so it doesn't trigger multiple times within less than a second if that's the software debounce you refer too but still printing the timer value with the 1hz I had a lot of 999, maybe need to debouce also that? Hardware wise I mean, not sure if that would give me better resoults.. Sorry as you can see I'm new to hardware stuff and it sees

[alepagliaccio]

I Just read the manual of the devices that we use right now. They claim a 0.5ppm precision. So I guess I just need that kind of precision if not better. Not sure how to measure that precision tho. And still from my tests I was losing with the esp hardware time 10/100ms randomly all at once which is the real issue, if it was once after some time that would for sure a better thing... But I do not understand why that's happening either

We have also some newer devices that claim 1ppm with GPS Sync.

Could someone explain to me why a gpsdo board with a microcontroller wouldn't fit my need? I keep not understanding why not, in my mind it does just that

[xvr]

Frequency precision could be much less, than phase - frequency error is not accumulated. CPU quarz frequency precision could be enough

What approach would you suggest?

All devices have free running high speed counters, feed from main CPU frequency. Master device will send periodically his own counter to all slave (in sequence) using the same procedure as NTP synchronization. So all slave has virtual copy of master counter and can use it to measure time stamps.
To attach absolute time to master timestamp it use NTP to any time server and synchronize its free running counter with NTP time (time also send to all slaves as part of sync packets).

So absolute precision of all slave frequencies is not important at all (they should guaranty minimal accumulated time error between sync intervals). Precision of clock of master device will define precision of time measurement between 2 sequential point. I guess that these points will be much more close to each other that 12h - OP says about competition and I assume that human been can't compete for 12h+ without break. 

But OP says that he can't use LAN (including wireless), so only available option is frequency generator with stability 25ppb 

I Just read the manual of the devices that we use right now. They claim a 0.5ppm precision.

This is not enough, you need 0.025ppm

Could someone explain to me why a gpsdo board with a microcontroller wouldn't fit my need?

gpsdo board will provide 1pps pulses with very high precision but with unknown phase jitter. Start phase of 1pps signal also not known - 2 board could generate they 1pps pulses at different time.
You need to synchronize initial phase of ALL 1pps signals from all boards. And still we don't know jitter of these signals. It must be less than 1ms to fit to your requirement. And as far as I remember gpsdo has quite long time to lock to sync, may be even not specified - you need to take a look in specification.
If you will provide all of above you can use gpsdo boards.

And still from my tests I was losing with the esp hardware time 10/100ms randomly all at once which is the real issue,

You use wrong way to measure time on ESP32. You should use hardware counter, not software clock in FreeRTOS.

[alepagliaccio]

I do understand what you mean. In my head i thought the pps from the GPS was synced between all GPS at the same time so that was generating the initial phase of all devices like that, but i was wrong. 12 hours was an  exaggeration, as I said the device we use right now (which are approved for these kind of competition by the events organisations) have just a 0.5 ppm. This means that precision would be enough for me to achieve, for now at least. what's that frequency generator with 25ppb you talking about? I mean how do I get on with that or that's just an expensive way of doing this that may not be worth it. (Of course better accuracy would be better)

Also I'm indeed using an hardware timer for my tests. I had then an interrupt on the 1hz wave and printing the timer value, after some time I was randomly losing 10/100 ms, I started to think that maybe the 1hz is the inaccurate one because I was expecting to lose 1ms after some time not 10+ just in one time. Maybe I should get a cheap oscilloscope to check also this?

The gpsdo doesn't use the pps Just to make the oscillator stay within it specification? Why do I need the PPS to sync with others? Wouldnt I then use the ocxo for timer anyway? There's no way to then start the oscillator phase when I need it?

Also wanted to thank you all for all these kind replies I am getting that make me understand more even if I thought I had already understood what I needed I was so off.

[xvr]

25ppb is a requirement of frequency precision to achive 2ms of time shift for 12h. It can be archived by OXCO, but quite expensive.

10/100ms of hardware timer drops are not normal. It should not be. Something in experiment was definitely wrong. May be time measurement was interfering by task switch in FreeRTOS. May be some other reason - this is required some investigation

> Why do I need the PPS to sync with others?

You need to get some signal simultaneously on all devices which need to synchronize. Just to get time stamp equal on all devices. 1pps signal seems a natural way to represent this. It can be some other signal, but it shoud be. Just a synchronized frequency is not enough - you need starting point.

Synchronizing of different gpsdo boards could help, but they not designed to support such procedure (IMHO). You should modify them heavily to allow this (not shure that it will be easy)

[alepagliaccio]

25ppb is a requirement of frequency precision to achive 2ms of time shift for 12h. It can be archived by OXCO, but quite expensive.

10/100ms of hardware timer drops are not normal. It should not be. Something in experiment was definitely wrong. May be time measurement was interfering by task switch in FreeRTOS. May be some other reason - this is required some investigation

Thank you, Will check on that then.

Will then a gpsdo with ocxo be good for this then in the end? From my understanding the GPS Just helps the ocxo to stay in the said frequency and using an ocxo with GPS or not would still have phases not synced but if that's the better I can get I think that would still be good enough if the device we use right now claim 0.5 ppm

[xvr]

You can use gpsdo as a very good ocxo. Or just use ocxo that good enough without gpsdo.
If you can achive frequency stability that will be enough for your requirements (25ppb for 2ms per 12h, or 0.5ppm for 21ms for 12h or 2.1ms for 1.2h) you can use it.
Gpsdo 1pps output is just one of the way to extract precise frequency. You can use other means to extract it - may be directly from ocxo of gpsdo board, if it has one (I don't know)

BTW. If you can provide wireless connectivity between devices all problems will gone away. What distance between boards? ESP32 can connect to each other without any external network.

[alepagliaccio]

You can use gpsdo as a very good ocxo. Or just use ocxo that good enough without gpsdo.
If you can achive frequency stability that will be enough for your requirements (25ppb for 2ms per 12h, or 0.5ppm for 21ms for 12h or 2.1ms for 1.2h) you can use it.
Gpsdo 1pps output is just one of the way to extract precise frequency. You can use other means to extract it - may be directly from ocxo of gpsdo board, if it has one (I don't know)

BTW. If you can provide wireless connectivity between devices all problems will gone away. What distance between boards? ESP32 can connect to each other without any external network.

The boards could be Place up to 2km but with other esp32 between them. So maybe a mesh network could be an idea. Im still not sure how wireless wouldnt affect delay or such, didnt understand the Logic you explained well. Also the devices Will be used in different spots but Need them to work without an intensive setup each time. As of now what i was doing was having a main device and other slaves that had the timers. When the interrupt triggered One of them It would send via lora to the main device the time and storie It/upload on a database.