Sleep Immediately after Beacon Advertisement

[Kenny]

I'm using the following code to make the beacon sleep:

static void on_ble_evt(ble_evt_t * p_ble_evt)
{
    uint32_t        err_code;
    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
        {
            break;
        }
        case BLE_GAP_EVT_TIMEOUT:
        {
            if (p_ble_evt->evt.gap_evt.params.timeout.src == BLE_GAP_TIMEOUT_SRC_ADVERTISING)
            {
                sd_ble_gap_adv_stop();
                ble_fsm_set_state(Ble_Fsm_State_Idle);
            }
            break;
        }
        default:
        {
            break;
        }
    }
}

Once the state is set to idle, the nrf51 chip goes to sleep and the current draw drops to the order of uA. My only problem here is that the minimum timeout value is 1s and this means that the chip is burning power for 1s. Ideally, I would like the beacon to just advertise once and then go to sleep immediately. What is the best way to do this? Adding a synchronous delay of 5 ms? Any callback that I can use instead?

[endnode]

What do you mean by "sleep"? I assume that nRF5x chip is going to POWER ON SLEEP (wait for event/interrupt) always when nothing is running on MCU so even between adv. events. If you mean POWER OFF state then sure you can do it but no BLE activity can be running during that time, you need to manage wake-up by some external GPIO interrupt line (button or some RTC capable chip if you expect to wake-up periodically).

[endnode]

Oh no, you can be sure that by calling thse SD function you would cause radio to be turned ON all the time (and Rx wouldn't make any sense!). That's not how BLE works, the "low energy" is achieved exactly by that trick of time synchronized Tx/Rx events and long times of complete "silence" when MCU is in deep power saving mode unless it does something else then serving BLE radio. You can turn Rx for continuous time but that's only in GAP Central/Observer role where you scan for advertisements. The connection Rx window happens exactly 150us after each connectable ADV_xxx packet and it doesn't need to be longer then few microseconds (if there is nothing detected) so no, SD is not listening for incoming CONNECT_REQ all the time;)