Clarification about nrf-calaendar example

[RO]

Hello,

I'm trying to integrate the nrf Calendar example here with Current Time Service client implementation on a nRF52840 DK.

I'm trying to understand the logic of the Calendar example.

Can someone explain the nrf_cal_set_callback function in nrf_calendar.c and what it does?

Thanks,

[nordev]

I have another clarification question about this example. 

What is the purpose of the second to last line here:
(https://github.com/NordicPlayground/nrf5-calendar-example/blob/master/nrf_calendar.c#L110)

void CAL_RTC_IRQHandler(void)
{
    if(CAL_RTC->EVENTS_COMPARE[0])
    {
        CAL_RTC->EVENTS_COMPARE[0] = 0;
        
        CAL_RTC->TASKS_CLEAR = 1;
        
        m_time += m_rtc_increment;
        if(cal_event_callback) cal_event_callback();
    }
}

Are you trying to keep time updated by updating m_time every time the RTC runs out (which happens every m_rtc_increment seconds, in this case 1m), instead of calling nrf_cal_set_time() the next time you want m_time to be updated? Why don't you just call nrf_cal_set_time() if you want to update m_time? It seems like you would only do it once a minute here-- or do you consider that "too often," and if so, why?

[ovrebekk]

Hi

This line makes sure that the time is updated once RTC is cleared, yes, to make sure that you can keep track of time over a longer period. 

Without this line you would not be able to keep track of time over minutes, hours and days, unless you used a very high increment value. 

The nrf_cal_set_time() function is intended to be used by the application whenever you want to change the time in the nRF52, it is not meant to be run repeatedly as a part of normal operation. 

Best regards
Torbjørn

[nordev]

ovrebekk said:

it is not meant to be run repeatedly as a part of normal operation

Why? What are the downsides to doing so?

Hypothetically, is it reasonable to call the set_time() function each time the BLE device connects with the central (phone)? This might be at most 1x/h, but under normal operation, the user would connect and stay connected. I can plan to have a timeout as well to correct for the deviation due to the internal oscillator in case the user stays connected too long. 

[ovrebekk]

Hi 

nordev said:

Why? What are the downsides to doing so?

There are no downsides per se, but the idea of the library is for it to keep track of time for you, not the other way around ;)

Say you use a 20PPM external 32k crystal, then the worst case time drift is 1.7 seconds pr day. If you correct the time from some external source (like a smart phone) every day you should only be off by a second or two at the most, and depending on how accurate time you need you might be able to set it even more rarely, like every week or two.  

nordev said:

Hypothetically, is it reasonable to call the set_time() function each time the BLE device connects with the central (phone)?

I would say it depends on how often you expect the customer to connect to the phone. If this happens 'once in a while' then I agree it makes sense to set the time on every connection, as you might not know how long time it will be until the next time the user connects the app. 

Best regards
Torbjørn