RTC Inaccuracy

[Dave_couling]

I'm finding fairly large lags with the RTC2 I'm using. I use an app_timer to sample the current RTC count value as a timestamp (MM:SS:Hundredth-of-a-second) and send it out via an HVX. However I'm noticing after about 2mins the RTC is lagging a reference time by almost a second. I have set the prescalar to 327 (to get ~10msec resolution), to capture fractions of a seconds. I don't use the interrupts except for on overflow, so I know its not an interrupt lag from a BLE event. Could the BLE traffic really interrupt my RTC counter get function enough to cause this drift?

I'm really at a loss how to get accuracy (millisecond) timestamps for HVX transmissions, almost seems impossible on this chip.

[endnode]

It should be more related to LF CLK source. Do you have external 32kHz crystal and is it used during SD enabling? Once it runs there should be no interference between RTC HW peripheral and MCU activity... also question how exactly you "display" the RTC counter from main FW (because there might be delays between your read of counter and when you "look" at it from the outside;)

[RK]

No the BLE traffic doesn't impact the RTC2 counter in any way. It's hardware. So what's your LF clock source for a start, how accurate is that? Given your use of 327 you should be lagging about 1/4 second after 2 minutes. So how accurate is your 'about 2 minutes' and how accurate is your 'almost a second'? Because if it's really 4 minutes and it's really 1/2 second .. that's about to be expected.

You should set up a bare board test of your clock source outputting to a GPIO using hardware, PPI whatever you have and measure with some kind of signal analyser. In fact you could fairly easily add the PPI GPIO toggle to your current implementation and count rollover times or something, that will give you a reasonable way of determining what the RTC is counting.

You seem to have inordinate difficulties with something very simple, both using the RTC and the HF clock (I saw the last post). It really shouldn't be hard at all.

[Dave_couling]

I do use an external crystal. Its a Rigado BMD300 module. I've initialized it in FW. I am disaplaying both on the Central receive side and via UART logging.

[Dave_couling]

It shouldn't be ;) though to be fair the PPI module is quite under documented for usage without GPIOTE. Its fairly straight forward for connect to GPIOs, but not for internal time keeping usage

[RK]

don't really know what else you can say about PPI, you choose any EVENT register you like which you would check with if( NRF_XX->EVENT_YY != 0 ) and put that in the source and any TASK register you'd usually set with NRF_AA->TASK_BB=1 and put that in the destination. Then enable it.

The occurrence of your EVENT will then trigger your TASK. It's as if you had your own little hardware thread going

while(true)
{
    if(NRF_XX->EVENT_YY)
    {
        NRF_XX->EVENT_YY=0;
        NRF_AA->TASK_BB = 1;
    }
}

in the background.