Setting RTC from another board using time_ns()

[krishnak]

I am trying to synchronise clocks between two ESP32 boards to microsecond level.

I tried sending utime.time() from Board A to B and on Board B , I do this

                        tm = utime.localtime(t)
                        tm = tm[0:3] + (0,) + tm[3:7]
                        machine.RTC().datetime(tm)
                        Logger.Log(tag,"Time Set",Logger.DEBUG)
                        RTCSet = True    

this works if I send value from utime.time() but when I send utime.time_ns()

OverflowError: overflow converting long int to machine word

Is there a way to achieve this?

[krishnak]

Instead of my above approach, I am now passing the value from machine.RTC().datetime() of board A as a ujson string and reading it back as a list in board B. I get microsecond sync, which is good enough for my requirement

[krishnak]

I still have an issue, I get time from Board A and set that value on board B - this should mean board B's clock will be slightly slower than Board A due to network/processing time. Both the boards operate at the same frequency, however Board B which should be slower, gains about 500ms.

After setting the clock, if I send a time stamp from B to A - the time is around 500ms in the future with respect to A, i.e ahead of A's clock.

Any suggestions

[puppet13th]

lets use client server approach
A - server
B - client

client request time from server with these procedure:

ticks = ticks_us()
server_time = (request time update from server code)
ticks_delta = ticks_us() - ticks
set local time to (server_time + ticks_delta)

[krishnak]

Thanks for the feedback, if I was not clear in my earlier message, let me re-explain without even adding any DELTA - the time on the client is 500ms ahead of Server

…

On Wed, 12 Oct 2022 at 09:18, Rinaldi Jandrinata ***@***.***> wrote: lets use client server approach A - server B - client client request time from server with these procedure: ticks = ticks_us() server_time = (request time update from server code) ticks_delta = ticks_us() - ticks set local time to (server_time + ticks_delta) — Reply to this email directly, view it on GitHub <#9576 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJTPN3QH5GYKTLWYCTEI2DWCYYHXANCNFSM6AAAAAARCER2UI> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>

[puppet13th]

sure that is weird one.
have you tried to sync json time to local( A to A) to see if there is time drift.
example code:

from machine import RTC
from time import sleep_ms
import json

rtc= RTC()

past = rtc.datetime()

dumps = json.dumps(past)
loads = json.loads(dumps)

sleep_ms(1000) # some delay

current = rtc.datetime()
rtc.datetime(loads)
print(past)
print(rtc.datetime())
print(current)

output:

(2022, 10, 12, 2, 11, 24, 30, 952009) # time to sync
(2022, 10, 12, 2, 11, 24, 30, 952291) # time after sync
(2022, 10, 12, 2, 11, 24, 31, 952708) # time before sync

[krishnak]

It is my fault, thanks for spending your time on this. I was trying to make ujson loads twice - the generic message from the server is a string which has been already converted into objects elsewhere in the code. Instead of accessing the time object which is a list, I was trying to convert a string once again - this was throwing an exception which seems to have been missed and no time synchronization has occurred. Please consider this as resolved.

…

On Wed, 12 Oct 2022 at 10:03, Rinaldi Jandrinata ***@***.***> wrote: sure that is weird one. have you tried to sync json time to local( A to A) to see if there is time drift. example code: from machine import RTC from time import sleep_ms import json rtc= RTC() past = rtc.datetime() dumps = json.dumps(past) loads = json.loads(dumps) sleep_ms(1000) # some delay current = rtc.datetime() rtc.datetime(loads) print(past) print(rtc.datetime()) print(current) output: (2022, 10, 12, 2, 11, 24, 30, 952009) # time to sync (2022, 10, 12, 2, 11, 24, 30, 952291) # time after sync (2022, 10, 12, 2, 11, 24, 31, 952708) # time before sync — Reply to this email directly, view it on GitHub <#9576 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJTPNZK2NJKJXZRGSRI46DWCY5Q5ANCNFSM6AAAAAARCER2UI> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>