I'm writing an application for the nRF54L15 that periodically receives the local time via bluetooth and keeps track of time on its own between syncs. I'm using a 10ppm external oscillator as LFCLK for the GRTC. I'm following the date-time lib docs like this:
int64_t uptime = k_uptime_get(); date_time_uptime_to_unix_time_ms(&uptime); // At this point `uptime` contains the unix timestamp in milliseconds.
This works, but I'm experiencing an unexpectedly high (I think!) drift in time. After around 8 hours of runtime, the nRF54L15-computed clock is already ahead of the external reference by over 3 seconds. I'm trying to understand why this could be the case and if there's something I could try doing to improve it. I suspect the `k_uptime_get()` may be the culprit, returning uptimes that are larger than expected.
In my autoconf.h, I have:
// I believe this means the LFCLK is set to use the external 32 kHz oscillator.
#define CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL 1
- I understand the GRTC automatically switches between HFCLK and LFCLK. Could this switching impact the accuracy?
- Would directly using the INTERVAL feature of the GRTC potentially improve my situation?
- I notice that in my autoconf.h, I have #define CONFIG_SYS_CLOCK_TICKS_PER_SEC 31250. I'm not 100% what is the impact of this config in this specific context, but should this be 32768? I came across this question & answer about the potential impact of rounding errors due to CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC and CONFIG_SYS_CLOCK_TICKS_PER_SEC: RE: k_uptime_get() drift way too much using LFXO. . In my build I currently have:
#define CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC 1000000 #define CONFIG_SYS_CLOCK_TICKS_PER_SEC 31250
The author answers with the suggestion of changing CONFIG_SYS_CLOCK_TICKS_PER_SEC to 1024, but from what I understand, that does not make sense in my case, as 1000000 is already a multiple of 31250.
Please let me know if there's any idea on how to better debug this.
Thanks!