• State Verified Answer
  • Replies 3 replies
  • Subscribers 67 subscribers
  • Views 238 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328071
Options

ble time sync among nrf52840 devices high frequecy timer vs rtc

eleven-x_devteam

Hi,

I am trying to use BLE time sync code and it seems working well with 16Mhz timer and rtc as well.

Here is the previous ticket.

 ble time sync among nrf52840 devices with old SDK 

One thing I noticed is about after stopping the time sync by calling ts_tx_stop();

The timestamp with 16Mhz timer has much more time difference (time drift) between time synced devices like 14 s in 2 hour while the timestamp with RTC had only 40ms time difference.

I tested with 3 devices, 1 device is time sync master and 2 devices are time sync slaves.

Once the 2 slave devices get time synced, I stopped the time sync mode by calling ts_tx_stop() in the master device.

I believe the timers for timer value and counter value is still running and there is no change in the slave device except no more time sync data.

And I saved the log for a couple of hours with window system time and compare how much time difference they have from each other.

It seems odd to me but Is that big time diff expected after ts_tx_stop()? or Do I need something else to do to minimize the time drift in the slave devices?

Thanks!

Parents
  • +1

    Hi ,

    it should come down to the accuracy of the 32 MHz crystal on your board. The nRF5x-DKs typically use a 30 ppm crystal, which when comparing two devices would give you a worst-case drift of 60 ppm (or 60 microseconds per second). Over a two hour period this should still be less than one second, so there seems to be something else going on that affects the drift if you see 14 seconds over this period.

    One thing that would significantly affect accuracy is if the high frequency clock source switches from the crystal oscillator to the internal one. The internal one is relatively inaccurate by comparison. However, as long as you dont call ts_disable() or sd_clock_hfclk_release(), the crystal oscillator should still be providing clock for the TIMERs.

    Are you using the example code without modification in your testing?

    Best regards,

    Audun

Reply
  • +1

    Hi ,

    it should come down to the accuracy of the 32 MHz crystal on your board. The nRF5x-DKs typically use a 30 ppm crystal, which when comparing two devices would give you a worst-case drift of 60 ppm (or 60 microseconds per second). Over a two hour period this should still be less than one second, so there seems to be something else going on that affects the drift if you see 14 seconds over this period.

    One thing that would significantly affect accuracy is if the high frequency clock source switches from the crystal oscillator to the internal one. The internal one is relatively inaccurate by comparison. However, as long as you dont call ts_disable() or sd_clock_hfclk_release(), the crystal oscillator should still be providing clock for the TIMERs.

    Are you using the example code without modification in your testing?

    Best regards,

    Audun

Children
  • 0 in reply to Audun

    Hi Audun,

    Thanks for the quick reply.

    I was testing with my custom boards and F/W and it turned out that there was another sd_clock_hfclk control code for battery and temperature reading and that part was calling "sd_clock_hfclk_release(): so I verified that high frequency timer didn't have that much time drift even after ts_tx_stop() without any other sd_clock_hfclk control code.

    Thanks!

Related