I would theoretically Need zero ms Lost in 12hour if that's not too much to ask on a budget.
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.
You need phase, not frequency.
...
-ability to sync 2 or more devices,
...
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.
Frequency precision could be much less, than phase - frequency error is not accumulated. CPU quarz frequency precision could be enough
...
-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.
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.
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?
Frequency precision could be much less, than phase - frequency error is not accumulated. CPU quarz frequency precision could be enoughWhat approach would you suggest?
I Just read the manual of the devices that we use right now. They claim a 0.5ppm precision.
Could someone explain to me why a gpsdo board with a microcontroller wouldn't fit my need?
And still from my tests I was losing with the esp hardware time 10/100ms randomly all at once which is the real issue,
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
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.