Clarification about nrf-calaendar example

RE: Clarification about nrf-calaendar example

ovrebekk — Fri, 28 Aug 2020 08:57:02 GMT

[quote user="nordev"]Why? What are the downsides to doing so?[/quote]

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.

[quote user="nordev"]Hypothetically, is it reasonable to call the set_time() function each time the BLE device connects with the central (phone)?[/quote]

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

RE: Clarification about nrf-calaendar example

nordev — Thu, 27 Aug 2020 09:24:41 GMT

[quote userid="2116" url="~/f/nordic-q-a/53902/clarification-about-nrf-calaendar-example/266422"]it is not meant to be run repeatedly as a part of normal operation[/quote]

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.

RE: Clarification about nrf-calaendar example

ovrebekk — Wed, 26 Aug 2020 09:36:28 GMT

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

RE: Clarification about nrf-calaendar example

nordev — Wed, 26 Aug 2020 06:37:16 GMT

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?

RE: Clarification about nrf-calaendar example

ovrebekk — Thu, 07 Nov 2019 10:04:10 GMT

It is a simple linear correction that is intended to detect if the internal clock is running consistently too slow or too fast.

When you adjust the time in the calender library it will detect if the internal clock ran faster or slower than the 'real' time provided through the nrf_cal_set_time(..) function, compared to the last time nrf_cal_set_time(..) was called.

For this to work properly it assumes that clock inaccuracies are consistent (don't vary over time), that you don't call nrf_cal_set_time(..) very often, and that you don't call nrf_cal_set_time(..) with an outdated time stamp.

It's worth mentioning that this function hasn't been tested very extensively either, so please use it at your own risk ;)

If you need good clock accuracy I would strongly recommend using an external LF crystal rather than relying on the calibration.

Best regards
Torbjørn

RE: Clarification about nrf-calaendar example

RO — Wed, 06 Nov 2019 15:50:22 GMT

Can I get a clarification about the calibration logic : nrf_cal_get_time_calibrated(void)

Thanks

RE: Clarification about nrf-calaendar example

ovrebekk — Mon, 04 Nov 2019 14:01:04 GMT

Yes, this is exactly how I implemented it.

If you take a look at this line in nrf_calendar.c you will see that I trigger the callback in the RTC compare event.

Best regards
Torbjørn

RE: Clarification about nrf-calaendar example

RO — Fri, 01 Nov 2019 14:17:27 GMT

Thanks.

I'm trying to convert the code to using the RTC driver.

So I can replace the callback function with an RTC COMPARE event?

RE: Clarification about nrf-calaendar example

ovrebekk — Fri, 01 Nov 2019 13:29:10 GMT

All it does is allow you to get a callback at regular intervals, what to do in the callback is entirely up to you.

It's convenient if you want to do something with the time information at a regular rate (such as display it somewhere, or store it to flash), but you could also use the app_timer library for the same purpose.

Best regards
Torbjørn