This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Best way to implement system clock on nRF51

Hi everybody,

a while ago I used the approach proposed here devzone.nordicsemi.com/.../ to keep the date and time on a NRF51822 device while using Softdevice S110 and the Timeslot advertiser-scanner (github.com/.../nRF51-multi-role-conn-observer-advertiser).

In practice I created an app_timer timer that executes every 250 milliseconds (this is the resolution I wanted) and inside the handler I incremented some variables accordingly to keep date and time. The problem is that I noticed that the time was not accurate, it was wrong, sometimes of several seconds, already after 1 hour. Here is the first question: I think that the time was wrong mainly because the app_timer handler gets delayed by the BLE stack, am I correct?

My idea to improve this is to connect an RTC1 COMPARE event to the TIMER1 COUNT task through PPI. The RTC1 will be configured to fire the event every second. This way I could keep the time in TIMER1 as a Unix timestamp (seconds since 1970-01-01) and I could read the number of milliseconds from RTC1 (I will use the number of ticks together with the prescaler to compute the milliseconds). This way there is no software handler involved and therefore it could not get delayed, is it correct? Is this going to be more precise than the solution using the app_timer? Will this solution consume more power? Do I need to keep on the 16MHz clock?

The implication of this solution is that I cannot use the app_timer library anymore or I could modify it to connect the RTC COMPARE event with the TIMER COUNT task and this should not interfere with the normal operation of the library, right?

I could try to implement the solution but since I am not sure it will work I would like some feedback from you.

Thanks a lot. Alessandro

Parents
  • Yes, this should be fine, but I had in mind a different thing. At the link is the code I wrote to modify app_timer.c, it is a bit speculative because I cannot try it until tomorrow :)

    Code

    Then I call ppi_init() and timer1_init() before rtc1_init(prescaler) and don't clear the COMPARE[1] event in RTC1_IRQHandler.

    I receive the base_time from an andorid phone but I don't use CTS, from the phone I advertise a packet that contains the current unix time in the manufacturer data. Probably it's not the best solution but it was quick to implement :)

    UPDATE 19/10/2015: I have tried it on the hardware and it works fine. I had to use PPI channels 3 and 7 because these are the only available when using the SoftDevice and Timeslot advertiser-scanner library. The problem of course is that the app_timer module cannot manage timers with a period greater than 1 second because the RTC1 is cleared every second in order generate the COMPARE1 event. This means this is not a good solution because it limits the app_timer module a lot.

    The solution proposed by Clem is probably the best, you don't need to update the CC[1] register or clear the RTC1 every second and from the number of overflows and ticks you can extract seconds and milliseconds. Of course the RCT1 cannot be stopped in this case so all the calls to rtc1_stop() should be commented.

Reply
  • Yes, this should be fine, but I had in mind a different thing. At the link is the code I wrote to modify app_timer.c, it is a bit speculative because I cannot try it until tomorrow :)

    Code

    Then I call ppi_init() and timer1_init() before rtc1_init(prescaler) and don't clear the COMPARE[1] event in RTC1_IRQHandler.

    I receive the base_time from an andorid phone but I don't use CTS, from the phone I advertise a packet that contains the current unix time in the manufacturer data. Probably it's not the best solution but it was quick to implement :)

    UPDATE 19/10/2015: I have tried it on the hardware and it works fine. I had to use PPI channels 3 and 7 because these are the only available when using the SoftDevice and Timeslot advertiser-scanner library. The problem of course is that the app_timer module cannot manage timers with a period greater than 1 second because the RTC1 is cleared every second in order generate the COMPARE1 event. This means this is not a good solution because it limits the app_timer module a lot.

    The solution proposed by Clem is probably the best, you don't need to update the CC[1] register or clear the RTC1 every second and from the number of overflows and ticks you can extract seconds and milliseconds. Of course the RCT1 cannot be stopped in this case so all the calls to rtc1_stop() should be commented.

Children
No Data
Related