BLE operation and run low power RTC/Calendar?

[benkokes]

Hello,

I have a project where I wish to have BLE operation while active and use RTC1 as a calendar keeper while in low power mode. So far as I have seen, the softdevice is interacting with a piece of Nordic code to handle the connection (I am on a peripheral, connecting to a central). I have 2 questions:

1. Are there any example projects that handle the BLE connection while keeping RTC1 free to use as a low-power calendar keeper? I want to sleep the part most of the time, keeping calendar time while needing the BLE radio once a day. I am trying to use RTC1 as a calendar keeper regardless of the chip being in active or sleep mode. Is that possible?

2. What profile should I use to transmit/receive a payload from an always-on central device? I will transmit ~4bytes of status data, and would like to receive a 4byte time synch message. Ultimately I want it to autoconnect, transfer, then disconnect with no need of human interaction. if no connection is available, then merely go to sleep.

I would appreciate a nudge in the right direction!

Thanks -Ben

[MartinBL]

Hi

1. Unfortunately there are no examples with calendar functionality. As you might know the Softdevice use RTC0 which leaves RTC1 (+ RTC2 on nRF52) free to use in your application. If you use one of our BLE examples though, then most likely RTC1 is used by the app_timer library. However that doesn't mean you can't use the app_timer as well to implement your calendar. It should be straight forward to add a new timer and make it keep the time for you. The only thing you need to be aware of is that the Softdevice might take control of the CPU once in awhile which might affect your timer interrupt. If the interrupt occur while the Softdevice is in control the interrupt handler will not be executed before the Softdevice has released control of the CPU again. However, this should only be a problem if you have a timer that triggers very frequently. You also need to take into account the clock drift, which might be a little high when using the nRF5. It might be a better solution to have a dedicated RTC chip to do this, unless you are synchronizing the time with your central on every connection?
2. What exactly do you mean by "profile"? Maybe the Current Time Service (CTS) is a good place to start. If you want to transmit data only once every day to an always-on central, then I guess the most power conservative solution would be to have your peripheral sleep all day long and just wake it up and start advertising for a short period of time once per day. Then your central can connect, get its data, and disconnect again. The other option would be to stay in connection, but use very long connection intervals and high slave latency. However, maintaining a link like this will probably consume more current than the first option. Have a look at this great tutorial for more tips on connection parameters and other current saving techniques.

Here are a couple of relevant RTC threads from devzone.