• State Not Answered
  • Replies 7 replies
  • Subscribers 75 subscribers
  • Views 3485 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 212461
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Nordic Clock Drift with Internal LFCLK when trying to synchronize with an external client or another Nordic clock (Nordic -nRF52840)

Akhil Bhargav Josyabhatla

Hello,

I am using a nRF52840 with SDK 14.2 and I am trying to synchronize my "app timer" which uses the RTC1 with respect to an external client which is connected over TCP protocol.

Hardware Setup: nRF52840 is connected to a Wi-FI module over UART and the TCP connection is established between the Wi-Fi module(Server) and a client program on a PC.

I send a command to the Nordic from client to start the timer, also start a timer at the same time on the client.
When I receive a packet(with the timestamp in mS) at the client side, I compare the timestamps of Nordic and MAC client and expect the difference= (time_at_client - time_from_nordic) to be positive but it's negative and grows very large every second.
I am assuming it's because of the clock drift on the nRF52840. I want to solve this issue as I want to synchronize time between nRF52840 - Client and also synchronize between 2 nRF52840 modules eventually.

Anyone faced this issue before and know of any software solution?

Thanks in advance,
Akhil

Notes:
1) Tried comparing TICKS and converted mS. See this issue with both values.
2) All calculations are taken care of.
3) I understand that external Crystal could increase accuracy and help in this scenario but there's a hardware limitation.

Parents
  • 0
    1. How much drift are you experiencing? 
    2. Are you calibrating the LFRC at regular intervals?
    3. How are you synchronizing the clocks?
    4. An external crystal will reduce the drift by quite a lot. 
  • 0 in reply to haakonsh

    Hello,
    1) I am noticing a 2-3% drift and it increases gradually with time.
    2) I am calibrating my LFRC at 4 Seconds interval.
    3) I am confused about this and would like help with this.
    4) Yes, But we have hardware limitation. Cannot add the external crystal now.


  • 0 in reply to Akhil Bhargav Josyabhatla
    1. If the drift is increasing with time then something is terribly wrong, the drift should be fairly constant given that you're calibrating the RC oscillator that often. 
    2. Calibrating at 4 second interval should be more than enough to keep the drift at ~500ppm
    3. You've got two different systems that you want to synchronize the time between, one is the nRF to Client and the other is nRF to nRF.

      In the first system it makes sence to use a UNIX timestamp taken from some generic timestamp server and share that with the nRF device periodically in order to update its calendar. It will have limits to its accuracy due to the fact tha the Client-to-nRF communication is non-deterministic since we cannot control the wifi stacks in the computer and module. You will always get a delay from the time your client want to update the clock of the nRF device until the nRF device has updated its clock, and this delay will have a significant variance over time. 

      In the second system you have nRF-to-nRF communication and this enables you to have very accurate time synchronization because you can control both radio stacks. This means the you can have fairly deterministic delays from the time one nRF device wants to update the clock of anothe nRF device and to the time when the other nRF device has updated its clock (low variance). This in turn enables you to predict this delay and add it to the timestamp used to update the second nRF device's clock, thereby reducing the two clocks time difference. 

      See https://devzone.nordicsemi.com/b/blog/posts/wireless-timer-synchronization-among-nrf5-devices for details.
    4. That's ok. 
Reply
  • 0 in reply to Akhil Bhargav Josyabhatla
    1. If the drift is increasing with time then something is terribly wrong, the drift should be fairly constant given that you're calibrating the RC oscillator that often. 
    2. Calibrating at 4 second interval should be more than enough to keep the drift at ~500ppm
    3. You've got two different systems that you want to synchronize the time between, one is the nRF to Client and the other is nRF to nRF.

      In the first system it makes sence to use a UNIX timestamp taken from some generic timestamp server and share that with the nRF device periodically in order to update its calendar. It will have limits to its accuracy due to the fact tha the Client-to-nRF communication is non-deterministic since we cannot control the wifi stacks in the computer and module. You will always get a delay from the time your client want to update the clock of the nRF device until the nRF device has updated its clock, and this delay will have a significant variance over time. 

      In the second system you have nRF-to-nRF communication and this enables you to have very accurate time synchronization because you can control both radio stacks. This means the you can have fairly deterministic delays from the time one nRF device wants to update the clock of anothe nRF device and to the time when the other nRF device has updated its clock (low variance). This in turn enables you to predict this delay and add it to the timestamp used to update the second nRF device's clock, thereby reducing the two clocks time difference. 

      See https://devzone.nordicsemi.com/b/blog/posts/wireless-timer-synchronization-among-nrf5-devices for details.
    4. That's ok. 
Children
Related
Terms of service