This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

About sleep mode

Hi,

I'm confused with the functions (sd_power_mode_set and sd_app_event_wait). 1.I think there are described with the same function.I can't tell the difference between this two.And I can't find the function that is used to wake up the chip. 2.Can someone tell me where I can find the define of the Constant Latency and Low Power.

Thank you.

Parents
  • Hi Mahone

    1 and 3. When sd_app_event_wait is called, the chip will enter System On low power mode. What actually happens is that code execution is stopped and the CPU is turned off. For most of the BLE examples in the nRF51 SDK, the sd_app_event_wait function is called in the main loop. More precisely, in the main loop of most BLE SDK examples, you will find function call power_manage which calls the sd_app_event_wait function in turn.

    The BLE peripheral device and the BLE central device aggree on when to turn on the radio and communicate, in a so called connection event. This is how data is exchanged and how the connection is maintained. In between connection events, the radio of the peripheral device is inactive and the peripheral device only needs to keep track of time in order to know when to enable the radio for the next connection event. So in between connection events, the peripheral device (nRF51822 with S110 peripheral softdevice) will enter System On low power mode to save power. The only thing normally running in between connection events is the RTC0 timer and the 32kHz low frequency clock which is required to operate the RTC0.

    The RTC0 keeps track of time and generates an event momentarily for the next connection event. This will make the peripheral device exit System On low power mode and enter normal mode. This means that the CPU will be enabled and start code execution in the RTC0 interrupt handler (performed internally in the softdevice). When the radio event has passed, the code execution will fall back to the main loop (which has lower priority than interrupts) where sd_app_event_wait is executed again, making the peripheral device enter System On low power mode until the next connection event.

    2. When the S110 softdevice is enabled, the current draw should be around 3.1uA in between connection events. The System On low power mode draws 2.6uA, RTC0 0.1uA and the 32kHz low frequency crystal draws 0.4uA, accumulating to the 3.1uA. You can read more about how it works and how to figure out different current consumption numbers in the following threads:

    Current consumption guide 1 Current consumption guide 2 Low frequency clock guide

    4. To use RSSI when the S110 softdevice is enabled, use the sd_ble_gap_rssi_start() and sd_ble_gap_rssi_stop() functions. The RSSI value will be reported back to the application in the form of an event, and as soon as you call sd_ble_gap_rssi_start() you should start seeing the events coming in.

    You can process the events by adding the following case in the on_ble_evt() function:

    case BLE_GAP_EVT_RSSI_CHANGED: current_rssi = p_ble_evt->evt.gap_evt.params.rssi_changed.rssi; break;

    The current_rssi variable should be defined as int8_t

Reply
  • Hi Mahone

    1 and 3. When sd_app_event_wait is called, the chip will enter System On low power mode. What actually happens is that code execution is stopped and the CPU is turned off. For most of the BLE examples in the nRF51 SDK, the sd_app_event_wait function is called in the main loop. More precisely, in the main loop of most BLE SDK examples, you will find function call power_manage which calls the sd_app_event_wait function in turn.

    The BLE peripheral device and the BLE central device aggree on when to turn on the radio and communicate, in a so called connection event. This is how data is exchanged and how the connection is maintained. In between connection events, the radio of the peripheral device is inactive and the peripheral device only needs to keep track of time in order to know when to enable the radio for the next connection event. So in between connection events, the peripheral device (nRF51822 with S110 peripheral softdevice) will enter System On low power mode to save power. The only thing normally running in between connection events is the RTC0 timer and the 32kHz low frequency clock which is required to operate the RTC0.

    The RTC0 keeps track of time and generates an event momentarily for the next connection event. This will make the peripheral device exit System On low power mode and enter normal mode. This means that the CPU will be enabled and start code execution in the RTC0 interrupt handler (performed internally in the softdevice). When the radio event has passed, the code execution will fall back to the main loop (which has lower priority than interrupts) where sd_app_event_wait is executed again, making the peripheral device enter System On low power mode until the next connection event.

    2. When the S110 softdevice is enabled, the current draw should be around 3.1uA in between connection events. The System On low power mode draws 2.6uA, RTC0 0.1uA and the 32kHz low frequency crystal draws 0.4uA, accumulating to the 3.1uA. You can read more about how it works and how to figure out different current consumption numbers in the following threads:

    Current consumption guide 1 Current consumption guide 2 Low frequency clock guide

    4. To use RSSI when the S110 softdevice is enabled, use the sd_ble_gap_rssi_start() and sd_ble_gap_rssi_stop() functions. The RSSI value will be reported back to the application in the form of an event, and as soon as you call sd_ble_gap_rssi_start() you should start seeing the events coming in.

    You can process the events by adding the following case in the on_ble_evt() function:

    case BLE_GAP_EVT_RSSI_CHANGED: current_rssi = p_ble_evt->evt.gap_evt.params.rssi_changed.rssi; break;

    The current_rssi variable should be defined as int8_t

Children
Related