Sync 2 or more ESP32 at milliseconds level

[alessandrv]

Hello, as the titles says I'm trying to figure out a way to sync 2 or more boards with perfect timing with at least 3 digit milliseconds.
I'm not sure which approach would be the best for this.
Trying to sync epoch time between 2 identical time grounding the pin at the same time gives random milliseconds from the ticks_ms() function where one has a bigger number first and maybe after 50ms the other one has the larger one for no reason, of course this doesn't fit my need.
What do you guys suggest? I read about gps modules but can I trust them to be synced perfectly? I need this setup to be portable, so no home network, the best that I could have with me is phone hotspot but I think syncing the time with wifi would cause other delays issues. Do any rtc modules keep track of milliseconds where grounding a pin at the same time would grant me them to be synced?
Thanks in advance.

[glenn20]

Are you using Pin.irq handlers to sample the grounding of the pin or are you polling in a tight loop? The former will have higher and more unpredictable latency than the latter.

[alessandrv]

Just using a while True to print the ms when button value Is true to see if button Is pressed, so that should be the latter i think

[plus10db]

This may help: https://www.reddit.com/r/embedded/comments/1pbp0az/esp32_s3_submicrosecond_time_sync_and_disciplined/

[CxZMoE]

maybe we can use one ESP32 as local time synchronization server, itself sync time from internet ntp server. then connect other esp devices to that ESP32 server like a mesh and receiving synchronized time info from it periodly by broadcast?

[robert-hh]

as I should not see any (logically speaking)

You should expect to see some. The numbers are expected to vary. The ticks timer is incremented every ms, and ticks_ms() just returns the actual value. If the first call of ticks_ms() is at the very end of one 1ms time slot, and the next call falls into the next or later time slot, then there is a difference between the two values. You cannot avoid that, unless you try to sync the calls of ticks_ms() with the internal ticks timer. And you should always expect that +/-1 error of the underlying time unit.

Edit: If you use ticks_us() in my above example and print the time difference, you get 5µs as the time difference between the calls, and thus with ms granularity in the test you can expect in the average 5 prints out of 1000 attempts.

[alessandrv]

Thank you, makes sense, but having 2 boards and checking the time at the same moment still gives me 2 different results which is not acceptable in sports timing unfortunately so I don't know what to do to avoid this still, 1ms doesn't sound like something huge but i cant provide something that gives wrong values even if only 1 ms

[robert-hh]

Maybe you can use ticks_us() as the base timer and round to ms(). With ticks_us() the intrinsic error of sampling is lower. But ticks_us() rolls over after 17 Minutes.

b.t.w.: ticks_us() calls internally esp_timer_get_time() returning a 64 bit quantity, which should not overflow in reasonable time (~584544 years). So you could consider adding an interface for that value, if the overflow cannot be handled differently.

[alessandrv]

From my tests using ticks_us() and dividing to get ms is working better (I wonder why, thought that ticks_ms() was just doing that), still they 2 boards are off as soon as the timer start and there's always the risk of one getting to the next ms before the other, but it looks better, I don't think there's any better way to do this? I find it strange there's no external module/rtc to keep track of ms reliably

[robert-hh]

Actually ticks_ms() returns esp_timer_get_time() /1000, and ticks_us() return esp_timer_get_time(). So there should be no major difference.

I find it strange there's no external module/rtc to keep track of ms reliably

What do you expect? The sampling problem will not disappear, the problem of delayed ISR will also stay. And if you work with buttons and switches, you'll have issues with bouncing.

[sosi-deadeye]

Maybe use for both ESP32 one 32_768 Hz square wave generator as the clock source. But then you have to change the settings in sdkconfig. You also need to know the right Pin on your ESP32-Dev-Board. If the 32kHz generator has a drift, both ESP32 should have the same drift in time.

[jonnor]

Are you trying to sync the RTC time, the internal clocks, or just synchronize an action (like sampling a sensor)? The available strategies will be quite different...

[alessandrv]

At the moment for my tests I was just trying to sync ms between 2 devices. When printing the ms value % 1000 + the RTC time I was getting inconsistent seconds with the ms but that makes sense because the rtc is not looking at the same ms I'm getting but that's not the issue. I need 2 devices to have the same ms mainly, syncing the seconds shouldn't be too hard. I was planning on using a GPS Module with a pps pin so that every impulse I get I can reset my timer so every second I have a new Timer that should say consistent during a single second, does it make sense? Also the gps would give me the right second from its nmea message. In my op I forgot to mention that what I'm doing is a sport timer, so I need to measure the time it takes to get from point A to point B and so they must have their time synced perfectly. So to answer your question I just need to have a local time that's the same on 2+ boards, no need it to be the real time just them to match, so any solution would be great that sync them like this

[NikolaPU]

Hi Alessandrv,
did you manage to sync 2 ESP devices ?
Did you use GPS to sync internal RTC ?

[alessandrv]

Hi Alessandrv, did you manage to sync 2 ESP devices ? Did you use GPS to sync internal RTC ?

I ended up using an external ocxo to have a lot of stability. Use the pcnt of the esp to count the pulses to get the time. To sync just start the pcnt at the same time with an interrupt on both caused by a pin grounded at the same time. Not the most precise solution but if using an ocxo at 10mhz with that high resolution having them off by like 100 pulses is like them being off about 10 microseconds, so would do for now. My solution is not this straight forward, I do some other stuff to reduce the pulse difference between devices but this is the general concept I'm trying at the moment.