Hello!
We're looking for a way to sync up several peripherals surrounding a central.
Our idea was simple- have the central measure 'current time' as near to a connection as possible, report the 'current time' to the peripherals, and have the peripherals save the reported 'current time' and zero an RTC once this 'current time' char arrives. This way, from the reported 'current time' and the RTC value (+ number of times the RTC overflowed) each peripheral can calculate what time it is when any event happens.
Looking at the CTS service at Nordics' 17.02 softdevice, the BLE spec https://www.bluetooth.com/specifications/specs/current-time-service-1-1/
I don't see a guarantee of accuracy for this service. I see the 'exact_time_256_t ' struct which should imply a 1/256 second accuracy (4ms) but I'm not sure this is right.
Here is a diagram showing my concern:
It seems to me like there is some time gap between the central measuring 'Current time' and the point at which the Etag can be said to have received it and started using it. Can the gap of dT1 + dT2 + dT3+ dT4 be guaranteed to be smaller than 4ms, and so fall within the 4ms timeslot specified in the protocol?
Even if we set aside T1 since it is dependent on central implementation, which I'm not sure is a realistic thing to do, how can we possibly know how long the BLE transmission, plus saving of the new value plus resetting the RTC will take?
I'm assuming this might change if a higher interrupt will occur between, say, receiving the new timestamp and restarting the RTC, so that the RTC will only be restarted after X ms.
Can anyone shed light on this?
