About BLE advertising and sleep system ON mode in Ble_App_Uart

[John12]

 I am build an application with features : When I not used nRF it imediately in sleep mode and be wake up by BLE events to send some text, and return to sleep mode ( the reson why I choose system On sleep mode).

1. So I think my nRF make sure

-> advertising continuosly in sleep mode (because my phone will connect to nRF anytime to wake nRF up and send text)

2. To make nRF advertisin continously I did

- set the flags   // init.advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE => BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE; to disable advertising timeout
- in BLE_ADV_EVT_IDLE  I commented sleep_mode_enter();, and call ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST); to restart advertising

static void on_adv_evt(ble_adv_evt_t ble_adv_evt)
{
    uint32_t err_code;

    switch (ble_adv_evt)
    {
    case BLE_ADV_EVT_FAST:
        err_code = bsp_indication_set(BSP_INDICATE_ADVERTISING);
        APP_ERROR_CHECK(err_code);
        break;
    case BLE_ADV_EVT_IDLE:
        NRF_LOG_INFO("call idle");
        //sleep_mode_enter();
        ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
        break;
    default:
        break;
    }
}

3. To wake up nRF I debug the NRF_LOG_PROCESS() in debug terminal this is 'true' when I connect to device or send some data from  mobile phone to nRF
-> so I think nRF was wake up in these BLE events

4. What is the different between ble_idle and ble_timeout ?  In idle mode can nRF advertising and my phone can connect to it ?
5. Does such continuous advertising make nRF consume a lot of energy? Can you suggest me some another ways ?
my main loop()

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
        NRF_LOG_INFO("%d", NRF_LOG_PROCESS());
        nrf_delay_ms(200);
    }

the rest of code is similar ble_app_uart ().
Please answer for me 5 above questions. Thank you !

[Karl Ylvisaker]

Hello,

1. So I think my nRF make sure

-> advertising continuosly in sleep mode (because my phone will connect to nRF anytime to wake nRF up and send text)

I am not sure if I have understood you correctly here, but I can confirm that you can stay in SYSTEM_ON sleep - like demonstrated in our examples - since the SoftDevice will wake the device when an advertising is upcoming, perform the advertising, and then go back to SYSTEM_ON sleep.

2. To make nRF advertisin continously I did

- set the flags   // init.advdata.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE => BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE; to disable advertising timeout
- in BLE_ADV_EVT_IDLE  I commented sleep_mode_enter();, and call ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST); to restart advertising

Your flag change to general discoverability is correct, and must be set to general since your advertisings does not time out. However, you should not restart the advertisings as part of the BLE_ADV_EVT_IDLE event handler, but instead just set your advertising duration to 0, which means 'no timeout'.
This happens during the advertising init / configuration.

3. To wake up nRF I debug the NRF_LOG_PROCESS() in debug terminal this is 'true' when I connect to device or send some data from  mobile phone to nRF
-> so I think nRF was wake up in these BLE events

You do not need anything else than idle_state_handle in your main loop - the SoftDevice will make sure to wake the device from the SYSTEM_ON sleep before any upcoming BLE events. There is no need for you to do this manually. Furthermore, I would not recommend using the nrf_delay_ms function anywhere in a finished product if it can be avoided, since it just estimates the number of NOP instructions needed to be performed for the specified time to have elapsed - it is not very accurate, and it keeps the CPU awake unnecessarily which wastes power.

4. What is the different between ble_idle and ble_timeout ?  In idle mode can nRF advertising and my phone can connect to it ?

Could you elaborate what you mean by this question?
If you are referring to the BLE_ADV_EVT_IDLE it is usually used to put the device into SYSTEM_OFF sleep because the advertising has finished without any peers connecting.

5. Does such continuous advertising make nRF consume a lot of energy? Can you suggest me some another ways ?

In general, yes: advertising without a timeout will consume a lot of power - but this heavily depends on your application as well. If your device will spend most of its time in a connection then advertising without a timeout does not really matter. If your device very seldom will enter into a connection and it is feasible for the user to press a button or otherwise wake the device prior to use, then it is wasteful to advertise without a timeout.
The power consumption of your advertising also heavily depends on your advertising configurations, such as advertising interval and advertising payload.
You can estimate the power consumption of your advertising using the Online Power Profiler to better see how the different configurations affect the power consumption.

Best regards,
Karl

[John12]

Hi Karl, Thank for your clearly answers

Karl Ylvisaker said:

4. What is the different between ble_idle and ble_timeout ?  In idle mode can nRF advertising and my phone can connect to it ?

Could you elaborate what you mean by this question?

1. I means when my nRF call idle BLE_ADV_EVT_IDLE event, my phone can not scan nRF and when my nRF timeout I can not scan too. so what is the different. Or can you explain for me more detail about idle ble mode

Karl Ylvisaker said:

5. Does such continuous advertising make nRF consume a lot of energy? Can you suggest me some another ways ?

In general, yes: advertising without a timeout will consume a lot of power

2. My application need to wake up remotely. So I think wakeup by BLE is the unique way.
So can you optimize or suggest some type of advertising to save enegy. With my basic knowlegde about nRF.  I think nRF have to advertising contiously to my phone can connect at any time and call the event BLE_GAP_EVT_CONNECTED to wake nRF up (call event BLE_GAP_EVT_CONNECTED generate an interrupt ? ) and receive data through nus_data_handler.

I build an application that when I need to find my nRF, my phone will ping the signal by BLE to nRF and nRF will ring the bell. 

[Karl Ylvisaker]

John12 said:

Thank for your clearly answers

No problem at all, I am happy to help!

John12 said:

I build an application that when I need to find my nRF, my phone will ping the signal by BLE to nRF and nRF will ring the bell. 

Thank you for the additional detail, this makes it easier to understand your project and use-case.

John12 said:

1. I means when my nRF call idle BLE_ADV_EVT_IDLE event, my phone can not scan nRF and when my nRF timeout I can not scan too. so what is the different. Or can you explain for me more detail about idle ble mode

True, the ADV IDLE event is meant to signify that advertising has ended, and that the advertising module now is in idle state. This means that the device is no longer advertising, and so it can not be found by any scanning device.
Advertising duration is the parameter that determines how long a certain type of advertising will last.
The GAP connection supervision timeout parameter determines how long the device will keep trying to reach its peer in a connection if the peer stops responding.
The connection is not considered broken / terminated until the timeout occurs, even if the peer stops responding entirely.

John12 said:

2. My application need to wake up remotely. So I think wakeup by BLE is the unique way.
So can you optimize or suggest some type of advertising to save enegy. With my basic knowlegde about nRF.  I think nRF have to advertising contiously to my phone can connect at any time and call the event BLE_GAP_EVT_CONNECTED to wake nRF up (call event BLE_GAP_EVT_CONNECTED generate an interrupt ? ) and receive data through nus_data_handler.

Yes, it if needs to wake up remotely then it must be in SYSTEM_ON sleep mode and advertising. The SYSTEM_OFF sleep mode will require an external interrupt in order to wake, so this is then not an option. Furthermore you must be advertising as connectable for the device to be receptible for connection requests.

In general, to reduce power consumption you can space out your advertisings as much as possible. If you for example use longer advertising intervals (longer time between each advertisements) you will see a lower average power consumption than if you advertise at a higher frequency.
The BLE events does generate interrupts for your device, yes. While in SYSTEM_ON sleep the CPU will wake up to handle any interrupt or event, and the SoftDevice will always wake it up when there is an upcoming BLE event.

Best regards,
Karl

[John12]

Hi Karl, please confirm for me this information

int main(void)
{
    bool erase_bonds;
    log_init();
    bsp_board_init(BSP_INIT_LEDS);
    // Initialize.
    uart_init();
    timers_init();
    buttons_leds_init(&erase_bonds);
    power_management_init();
    ble_stack_init();
    gap_params_init();
    gatt_init();
    services_init();
    advertising_init();
    conn_params_init();

    // Start execution.
    printf("\r\nUART started.\r\n");
    NRF_LOG_INFO("Debug logging for UART over RTT started.");
    advertising_start();

    // Enter main loop.
    for (;;)
    {
        idle_state_handle();
        //NRF_LOG_INFO("%d", NRF_LOG_PROCESS());
        //nrf_delay_ms(200);   
        bsp_board_led_invert(2); // toggle LED_2 P0.14
        nrf_delay_ms(100);

    }
}

in for (;;)  loop

I call  idle_state_handle();  in line 26 and toggle led and delay  (100ms). This delay to make sure I can realize the led change status.When I test on my nRF
step1. My nRF will blink once time and stop (turn on)

step2: I scan and connect to my nRF -> my led blink once time and stop (turn on)
I think when I wake up my nRF it imediately execute the first line in for (;;) loop that is idle_state_handle(); (line26) = > check NRF_LOG_PROCESS  == true, and execute the rest of lines of for (;;) loop until return line 26 and back to sleep.

1. So is this principle right for all basic applicaiton (I means need to put idle_state_handle(); at  the first of for(;;) to make sure another feature is all executed and return to sleep.)

2. What is NRF_LOG_PROCESS(). Is it unique signal to check are there any interrupt or event to wake nRF up ? Because I found in idle_state_handle() only check status of NRF_LOG_PROCESS() == false to call nrf_pwr_mgmt_run();

3. In sleep system ON mode, nRF is still advertising BLE continously.Timout was counted => there are at least a timer working. So what is actually "sleep" mode here ?( what are actually sleep ?). I'm not sure about this sleep systemON mode so it's  too hard to handle other perpheral or clock. Because I'm using libuarte in my application so if libuarte is working whn nRF in sleep system ON mode or not ? and more I'm using MPU6050 sensor also to detect motion If in sleep mode can I disable this peripheral that this sensor connected and when my nRF move MPU6050 will generate interrupt to wake nRF up.

4. I'm using nRF52833 chip on custom board. Can you suggest for me some link to measure current consumption. I follow many threads but it too hard to understand.

5. if my application advertise continously and use 1000maH battery . How long do you think the nRf will live?

Sorry about my expression. Because English is not my mother language ^^

[Karl Ylvisaker]

Hello,

John12 said:

Sorry about my expression. Because English is not my mother language ^^

No need to apologize! I do my best to understand what you have meant, and if I am unsure I will ask you to clarify, it is no problem at all :) 

John12 said:

I call  idle_state_handle();  in line 26 and toggle led and delay  (100ms). This delay to make sure I can realize the led change status.

You do not really need this delay here, the LED will be toggled without it as well. 100 ms is an ocean of time in the context of the nRF52833, so you will spent a lot of power in the 100 ms delay.

John12 said:

I think when I wake up my nRF it imediately execute the first line in for (;;) loop that is idle_state_handle(); (line26) = > check NRF_LOG_PROCESS  == true, and execute the rest of lines of for (;;) loop until return line 26 and back to sleep.

1. So is this principle right for all basic applicaiton (I means need to put idle_state_handle(); at  the first of for(;;) to make sure another feature is all executed and return to sleep.)

This is not quite correct - when the CPU is awoken from SYSTEM_ON sleep by an event it will complete the processing of that event before it moves on to the main for(;;) loop. The main loop has the lowest priority of the application, which means that it will only return there once all other events are processed. This ensures that the device goes into low power SYSTEM_ON whenever it has nothing else that needs processing.

John12 said:

I think when I wake up my nRF it imediately execute the first line in for (;;) loop that is idle_state_handle(); (line26) = > check NRF_LOG_PROCESS  == true, and execute the rest of lines of for (;;) loop until return line 26 and back to sleep.

No, it will first process the event that woke it and any other event that is generated during the handling of the first event. It only goes back to the main context once it has finished all its other work, which is why the main for(;;) loop should only contain the idle_state_handler, since this puts it into SYSTEM_ON sleep.

John12 said:

2. What is NRF_LOG_PROCESS(). Is it unique signal to check are there any interrupt or event to wake nRF up ? Because I found in idle_state_handle() only check status of NRF_LOG_PROCESS() == false to call nrf_pwr_mgmt_run();

No, this just checks if there are any logs that needs processing before it goes to sleep. Processing logs thus also has a very low priority.
Any event is able to interrupt the main() context at any time.

John12 said:

So what is actually "sleep" mode here ?( what are actually sleep ?)

The crucial difference here is between SYSTEM_OFF sleep and SYSTEM_ON sleep. In SYSTEM_OFF sleep the whole device is shut off, while in SYSTEM_ON sleep it is only the CPU who is put into a low-power sleep state (called 'idle').
When the device is in SYSTEM_ON sleep it means that the CPU is in the low-power sleep, but able to wake up to process any incoming events (like an upcoming advertising event), while peripherals may still function as usual. That is to say, the SAADC can for example be sampling while the CPU is sleeping since it does not require CPU interaction to do so. Likewise peripherals like TIMER and RTC can still run while the CPU is sleeping and the device is in SYSTEM_ON sleep.

John12 said:

and more I'm using MPU6050 sensor also to detect motion If in sleep mode can I disable this peripheral that this sensor connected and when my nRF move MPU6050 will generate interrupt to wake nRF up.

An event from the external sensor can be used to wake the nRF device from both SYSTEM_ON and SYSTEM_OFF sleep, yes.

John12 said:

4. I'm using nRF52833 chip on custom board. Can you suggest for me some link to measure current consumption. I follow many threads but it too hard to understand.

You could for example use a Power Profiler Kit in order to measure your power consumption.
I do not know anything about your custom board, but does its layout enable you to measure the power consumption of the nRF device alone, or will you be measuring it for the whole board?

John12 said:

5. if my application advertise continously and use 1000maH battery . How long do you think the nRf will live?

This is impossible for me to estimate since it depends on what else the device is doing and how you have configured your advertising.
I would suggest that you input your advertising configuration into the Online Power Profiler to see how much the estimated consumption is, and then calculate how long it would take to deplete a 1000 mAH battery.

Best regards,
Karl