Timekeeping drift with nRF54L15 + GRTC + Date-Time library

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

rba — Thu, 26 Jun 2025 06:32:52 GMT

Thanks for the pointers. I've marked the accepted answer.

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

Edvin — Wed, 25 Jun 2025 12:28:52 GMT

This is described here:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/chapters/oscillators.html#ariaid-title5

the CPin is described in the Electrical specification:

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/_tmp/nrf54l15/autodita/OSCILLATORS/parameters.low_frequency_crystal_oscillator.html

The equation from the first link can be simplified:

C = 2*Cxo - Cpin. Cxo is from the XO specification, and Cpin = 3pF. Let us say we have a 9pF XO, then C will be C = 2*9 - 3 = 15pF.

Why it is 15.5pF in our board files, I am not sure. I assume this is based on testing, and they found this to be the best value for the best accuracy.

Best regards,

Edvin

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

rba — Sat, 21 Jun 2025 06:45:10 GMT

That's a great find, thanks Edvin.

For future readers, indeed I double checked that the nRF54l15dk (0.9.3 BOM) and it has a 9pF LXFO:

The LXFO is connected directly without external caps, and also saw that the dts file sets the internal load capacitance for the DK as follows:

&lfxo {
	load-capacitors = "internal";
	load-capacitance-femtofarad = <17000>;
};

This has been recently changed from 15.5pF around a month ago.

It's more of an academic curiosity at this point, but I wonder how this value was chosen, and what's the impact of inherent tolerances or measurement imprecisions in the capacitance value. I.e.: in which scenario can I expect the GRTC to have the accuracy of my LXFO? And if the nRF54L15 "sees" a 17pF in the DK's LFXO, does it mean it's also out of spec?

Thanks once again!

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

Edvin — Fri, 20 Jun 2025 13:51:07 GMT

Hello,

The LFXO you are using seems to be out of spec.

https://docs.nordicsemi.com/bundle/ps_nrf54L15/page/_tmp/nrf54l15/autodita/OSCILLATORS/parameters.low_frequency_crystal_oscillator.html

The max Cl should be 9pF, while your is 12.5.

You may (! not sure) be able to get it to work by setting the load-capactors to 21pF, but the internal ones only go up to 18pF, so you would need some external capacitors. Or you need to change to another LFXO that is actually inside the specification.

So the load-capacitors in the dts file is not the same as the Cl of the XO. It is used to set the overall correct capacitance.

Best regards,

Edvin

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

rba — Thu, 19 Jun 2025 18:26:58 GMT

Thanks once again Edvin.

By this I meant I'm using an external 32 kHz LFXO XTAL. The crystal oscillator part number is Q13FC13500005 from Epson (datasheet). I am using the recommended 12.5pF load capacitors in my dts file as follows:

&lfxo {
	load-capacitors = "internal";
	// 12.5pF.
	load-capacitance-femtofarad = <12500>;
};

I think it could be a couple of things:

- Some misconfiguration on my part somewhere

- Things could be working as expected and my measurements are off. I'm using a simple method of comparing it with my phone (against which I did the original sync): right after the sync the minutes flip at the same time; in the next morning there is a visible 3 seconds offset when the minute flips on the phone to when it flips on the nRF54.

I will try to pipe the LFXO clock to a GPIO and measure it with an oscilloscope. Meanwhile, I was wondering if there's a more reliable test I could run. Let me know if you have something I can also run on the nRF54L15dk and on my custom nRF54L15 board. This would rule out any mistakes on my side.

Thanks!

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

Edvin — Wed, 18 Jun 2025 20:02:36 GMT

Hello,

Yes, we found your findings curious. Basically, the accuracy of the GRTC should be equal to the accuracy of the LFCLK (32.768kHz clock). If your external clock is 10ppm, this means that it will drift 10 seconds per 1 million seconds (or less). 8 hours = 28800 seconds, so you should expect a drift of 0.288 seconds or less per 8 hours. What you are seeing is roughly 10 times that, so that is 10 per 100 000 or 1/10 000, or 100ppm (if my math is correct)

What you could do is to set up a small application using DPPI, connecting the GRTC to a GPIO, and toggling it every given amount of time/ticks, and measure this GPIO using a logic analyzer, to see how long it takes.

[quote user=""] I'm using a 10ppm external oscillator as LFCLK for the GRTC[/quote]

Just to be sure, this means some sort of external signal generator, and not a 32kHz LFXO? Can you share the part number? (sorry if that is a dumb question, but this is new for the nRF54 series, and I am no HW expert).

Best regards,

Edvin

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

rba — Wed, 18 Jun 2025 18:51:29 GMT

Hey Edvin , thank you for your reply. Absolutely no need to apologize.

In my initial tests the phone is not connected, except for the initial time sync, after which the BLE connection is shut down. I wanted to really test the accuracy of the RTC timekeeping by itself.

I will repeat my tests for a longer period and see if the drift is somewhat linear like you suggested. In the end, I opted for doing a periodic time sync with the Current Time Service every one hour, which is more than fine for my use case.

I'm just now mostly curious to check if there's any easy wins to be even more accurate. I will report back as soon as I manage to collect the data.

Thanks!

RE: Timekeeping drift with nRF54L15 + GRTC + Date-Time library

Edvin — Mon, 16 Jun 2025 20:56:27 GMT

Hello,

I am terribly sorry for the late reply. We are a bit short staffed, and we are doing our best to keep the wait time down to a minimum. Sorry for the inconvenience!

During these 8 hours, are you connecting to your phone after the initial connection? Or does the nRF54L15 get the time from the phone after you started the 8h test?

If so, can you try setting up a timer, and print the value of the clock, e.g every 5 minutes, or 30 minutes? Just to see if the clock is drifting without being interfered by the phone?

I don't suspect that the phone's clock is drifting, but depending on your connection interval, the exact timestamp may be inacurate. Let us say that you have a connection interval of 4 seconds, then the time you receive from the phone may be everything from 0 to 4 seconds off, depending on when the phone queued the time message. It will first be sent after the next connection interval has passed, and that could have anything between 0 and 4 seconds remaining.

If you leave your test running even further. Does the clock keep drifting 3 seconds every 8 hours? So 9 seconds per 24h?

Best regards,

Edvin