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]

What does your main loop look like? It should call sd_app_evt_wait() directly or indirectly (through some idle_state_handle() function or something). If so, then the device should reach the low power mode that you can use while using the softdevice actively. Unless you are hanging in an interrupt somewhere, the main loop should be reached after any interrupt.

Best regards,

Edvin

[AllenS]

This is the entry into the main loop:

#ifdef dbg_UART_Msgs

printf("Starting Main Loop.\r\n");

#endif

// Enter main loop.
for (;;)
{
// #ifdef dbg_Time_Idle_Dly

// bsp_board_led_on(3);

// #endif

idle_state_handle();

// #ifdef dbg_Time_Idle_Dly

// bsp_board_led_off(3);

// #endif
}

When it went into Idle_State_Handle(), that was the function I showed in a previous post.  So you are definitely right about the execution going off somewhere else and upon a disconnect it will come back to the main loop and the Idle routine.  More investigation needs to be done to figure out way but at least now I have something to look for.

Anyway, the project spec changed and I am being asked to advertise every x seconds and send the battery level when the advertise is transmitted.  Any suggestions about that or should I close this discussion and start a new one.  I do have some ideas on things to experiment regarding this to see if it will work.

[Edvin]

AllenS said:

advertise every x seconds and send the battery level when the advertise is transmitted.

What do you mean by this? Do you intend to include the battery level in your advertisement, or are you connected to the device that you send the battery level to?

BR,

Edvin

[AllenS]

Based on my understanding of the new requirement, it would be to blindly send out the battery level and not require any type of connection from the cell phone app.  The cell phone app is looking for the MAC address of the remote device and just the battery level info.  They are now saying that with the 30 mAH battery, I would need to put the device into a System Off, No RAM retention, wake on GPIO mode.  That should get me to 0.3 uA over a period of 9 Secs will only draw 2.7 uA.  I would just need to figure out how much current would be needed to come up and send out the data and then go back into that deep sleep mode.  For the GPIO, I would just use a simple RC network for the delay.  Would it be easier for me to look at a different demo that is more targeted to this approach?  If so, which one would you suggest?

[Edvin]

Without connections and some battery info, this sounds like a typical beacon application. Just be aware that there is no way to guarantee that an advertisement is picked up, so the typical way here is to advertise more than once before going back to sleep. You should look into advertisement intervals and scan intervals and scan windows. You can read about it in this guide.

I also suggest that you look into the online power profiler.

Perhaps settings like this is something you are looking for:

I think you would want to look into the ble_app_uart example, as this is probably the closest you are looking for. Just be aware that this example is not using the advertising module, but setting up the advertisements manually. So perhaps just disable the scan response and set the advertising type from connectable to unconnectable in whatever ble_peripheral example is just as easy.

Best regards,

Edvin