Wake on any Event Low Power Mode Using a timed event

[AllenS]

I am really new at working with Bluetooth and the various protocols contained within.

I am using SDK 17.0 and drivers 2.7.  I am working on a DK-52 board.

I am working with the HRM Demo.  In particular with the battery service timed event.  I came across the place in the code where the device will go in to sleep mode.  The comments say it should not come back until a button is pushed to wake it up or a reset / powerup occurs.

//---------------------------------------------------------------------------
/**@brief Function for putting the chip into sleep mode.
*
* @note This function will not return.
*/
//---------------------------------------------------------------------------
static void sleep_mode_enter(void)
{
ret_code_t err_code;

err_code = bsp_indication_set(BSP_INDICATE_IDLE);
APP_ERROR_CHECK(err_code);

// Prepare wakeup buttons.
err_code = bsp_btn_ble_sleep_mode_prepare();
APP_ERROR_CHECK(err_code);

// Go to system-off mode (this function will not return; wakeup will cause a reset).
err_code = sd_power_system_off();
APP_ERROR_CHECK(err_code);
}

I never use the buttons on the DK board and from what I am seeing the battery service sends out battery information every couple of seconds.  After so many bursts of information, it appears the device somehow just resets itself and continues the process all over again.

If I wanted to keep the system on, full ram retention and wake on any event, which sd function would I need to call so that I could go into Ultra-low power mode and not lose the bonding information with the client app?  Is there a demo that demonstrates this type of low power mode that I could look at?

Is there a good method that I could use to determine if the client app was bonded with the device and not send battery level info but wait until a bond occurs and then send that battery info across so as not to waste much battery power as well?

Thanks in advance.

Allen Shea

[Edvin]

Hello,

it appears the device somehow just resets itself and continues the process all over again.

What observations do you do that supports this scenario? Do you see anything in the log? Does it disconnect from the connected device? What do you connect to? A phone?

Is there a good method that I could use to determine if the client app was bonded with the device and not send battery level info but wait until a bond occurs and then send that battery info across so as not to waste much battery power as well?

Yes, but this isn't really saving much power. Bonding is used for encryption. If you wanted to, you could wait until the link is encrypted, but in reality this will save less than one battery message on average. It will not conserve much power.

If I wanted to keep the system on, full ram retention and wake on any event, which sd function would I need to call so that I could go into Ultra-low power mode

If you go to the "ultra low power mode", it basically means turning off the chip. The only way to wake it up from this state is by a button press. You can't use any timers in this system-off mode (which is why the comments say that you need a button press to wake up.). 

System off mode, which is the lowest power mode you can use is typically used if you are advertising, but noone tries to connect. When the advertisements time out after 180s (configurable in your application), the device will go to system off mode. 

Then there is system on mode, which is what we use when you are in a connection, advertising or scanning. If you look in your main() loop, you should see a sd_app_evt_wait(), which basically puts the device to sleep, but wake up on any event (timer, softdevice radio event, peripheral event or whatever you have set up). 

So I am not completely sure what you are looking for (perhaps you are not so sure yourself). Do you see a current consumption that is too big for what you can tolerate? If so, what is the current consumption, and what current consumption do you need? Or are you concerned with security? Or are you curious about that the application seemingly resets? Did you try to monitor the log from the nRF? (UART log?) Does it say anything when the device resets?

Best regards,

Edvin