This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

synchronization between nRF52s

Hi, I'm developing some products and i need my all devices to synchronize within 10ms difference, using UTC Time standard

Here is basic concept that i want to do for my project.

And i know there must be time latency through BT so that nRF52 (A) is not able to get "exact" time compared with nRF52 (B)

So is any good idea to make them synchronized ? is my idea impossible to make it ?

Thank you.

  • Hi,

    This blog post may help you to create the idea.

    but you should know that there are multiple factors to degrade the performance such as distance, rf environment.

  • Hello,

    For starters, the blogpost suggested by Eugene is a very good place to start for this particular topic when you require high accuracy on the synchronization. This method will give you the highest accuracy of your synchronization in comparison to my following suggestion. However, I thought I should include the following suggestion as an option for a simpler implementation, albeit with less accuracy, since you have a 10 ms window you need to be synchronized within.

    And i know there must be time latency through BT so that nRF52 (A) is not able to get "exact" time compared with nRF52 (B)

    As an alternative to the approach detailed in the blogpost I suppose you could also consider using a 10 ms connection interval, and then making use of the Radio Notifications of the SoftDevice which will generate an event on both devices roughly at the same time. The lesser accuracy of this approach primarily stems from the drift of the low frequency clock source of the devices, and the fact that the SoftDevice itself accounts for the estimated drift by expanding the radio windows accordingly. The feasibility of this approach depends entirely on your application's real-time requirements.

    There will of course be some drift between the devices over time, but if you transfer the value of LFCLK ticks passed since the last Radio notification on device A to device B, you could do a comparison with the passed LFCLK ticks on device B for the same period, and then adjust it according to device A, for instance. If you do these comparisons while every so often pulling the UTC time from both sources, you should be able to stay well within the 10 ms synchronization window.

    The SoftDevice uses the clock accuracy config to determine how much it might have drifted since last connection event. The estimated drift is accounted for by increasing the radio window to encompass this drift.
    If minimizing this drift is of high importance for the application, you might also look into adding a higher-accuracy LFXTAL and use that your for your low frequency clock source (LFCLK).

    Best regards,
    Karl

Related