RTC Inaccuracy

RE: RTC Inaccuracy

Dave_couling — Tue, 07 Nov 2017 18:45:18 GMT

Yes, an I've verify similar inaccuracy with the RTC. However the inaccuracy is affected by BLE traffic. Testing with different connection parameters and data transfer rates, sampling the RTC rarely so as to not be affect by BLE interrupts, I see variance between 1-4sec per minute. Worse with high BLE data thru put.

RE: RTC Inaccuracy

RK — Tue, 07 Nov 2017 03:20:57 GMT

no Dave I meant absolutely nothing of the sort. Going back to my original answer have you actually measured the accuracy of your RTC using a GPIO yet and how accurate were your 'about 2 minutes and about almost a second' which I asked way back at the start.

RE: RTC Inaccuracy

Julie H — Tue, 07 Nov 2017 02:27:44 GMT

Dave - Yes, you can use PPI so that when the RTC's EVENT is triggered some TASK is started. But I'm more concerned with why this seems to have become so complex. The first issue is that you can't get 10ms times from a 327 pre-scaler value. For that matter, you can't get 1.000ms anything from a 32,768Hz clock. You can get a 1/1024th of a second, or 10/1024ths of a second, but those aren't even multiples of 1.000ms. One solution would be to count 1/1024ths of a second, and convert that to 1ms approximations. If you multiply by 1,000 and then divide by 1,024, you'll get something that's pretty close. If you wrap your counter at 1,024, so that you never have more than 1,024 "mibiseconds", the ((mibiseconds * 1000) / 1024) will never overflow and life will be just fine.

RE: RTC Inaccuracy

Dave_couling — Tue, 07 Nov 2017 01:09:08 GMT

Sorry, this just isn't very clear to me. Does this mean I could assign an RTC timeout to sample the value in a TIMER? Since the TIMER values are abstracted this is all seems overly complex.

RE: RTC Inaccuracy

RK — Wed, 25 Oct 2017 21:38:14 GMT

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.

RE: RTC Inaccuracy

Dave_couling — Wed, 25 Oct 2017 21:09:27 GMT

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

RE: RTC Inaccuracy

Dave_couling — Wed, 25 Oct 2017 18:30:24 GMT

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.

RE: RTC Inaccuracy

RK — Wed, 25 Oct 2017 09:53:48 GMT

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.

RE: RTC Inaccuracy

endnode — Wed, 25 Oct 2017 08:18:18 GMT

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;)