Nordic Calendar example (https://github.com/NordicPlayground/nrf5-calendar-example) related issue

[Yogeshwar]

I wanted to implement a time sync feature on nRF-52840 DK. I took a reference from this example, but there were certain things unclear to me.

Can somebody explain to me what is calibrated and uncalibrated time here? and what exactly are we doing here in this example?

[haakonsh]

In this example, a calendar is periodically synced with an outside time-stamp. It does not cover how you obtain the outside time-stamp, just how you can use it to update the calendar. 

As the calendar uses the RTC as it's base clock, it will experience a fair amount of drift, +/- 10-20ppm at best, and will need to be periodically calibrated/synced. 

I believe the uncalibrated time is the current time of the calendar, and the calibrated time is the provided synchronization time-stamp.

[Yogeshwar]

haakonsh I flashed this example on an nRF52840 DK and I got this output on serial

when I use the get function(option g) to get the time, I get this as the output where the calibrated and the uncalibrated time is the same.

next, when I use the run continuous-time updates (option r), I get a time difference of 4 seconds every time and I just don't get it that why is there such a big difference.

Later I set time to current time and then tried to run continuous-time updates (option r) and still there is a time difference of 4 seconds.

can you please explain this behavior?

[haakonsh]

Hmm, I'm at a loss.

A colleague in tech support made that example, but he's away until Monday, can you wait until then? 

[Yogeshwar]

okay,

but please get back to me when he comes back.

[ovrebekk]

Hi

I will take over this case since I wrote the example in question. 

The calibrated time function doesn't really work well unless the call to the set time function happens at exactly the time you indicate. 

This is hard to do when inputting the time manually from the terminal, but should work better if you set the time programatically in the code. 

The idea is that if you set the time twice from some accurate external source, and there is some constant drift in the timers in the nRF52, the calibrated time will take this into account. 
Please be aware that this library is not an official library, and just something I wrote to illustrate how to read date and time. The calibrate function has never been tested properly in a real use case, so I can not guarantee that it works very well in practice ;)

Best regards
Torbjørn

[manikandan]

i too using this nrf calendar example my problem is i want to set time like this

1) if i connect the  board with mobile using bluetooth time should be set at that particular time.

2)example if i connect at 7,30 pm the time should start at 7,30 and then keeps on printing time and data

3)can i achieve this using nrf calendar or should i go with other example

[ovrebekk]

Hi 

For the future please open a new ticket rather than wake up an old one, unless it is directly related to the current one. The devzone is not designed for long running questions covering multiple topics ;)

You can use the nrf_calendar example for this, but all the BLE integration is something you will have to add on your own. 

The nrf_calendar example only gives you the nrf_cal_set_time(..) function, and it is up to you to integrate the code for acquiring the timestamp over BLE. 

Unfortunately I don't know of any examples from us that do this, but if you are developing your own app it is possible to get a timestamp in the app and send it over a proprietary service to the nRF52 device every time you connect. 

Best regards
Torbjørn

[manikandan]

Can i add milliseconds to the nrf calendar ??

[ovrebekk]

Hi

The RTC timer doesn't have the accuracy to count milliseconds, since it is running off of a 32.768kHz clock. 

If you modify the calendar example to use a TIMER module instead of the RTC then you can count milliseconds also, but this requires a fair bit of changes to the example.

This will also increase the sleep current significantly, so if power consumption is important to you it might not be the best solution.  

Best regards
Torbjørn