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.

  • Hi

    The sd_app_event_wait function will put the device to System On low power mode. When an event occurs, the device will enter normal mode again.

    The sd_power_mode_set function determines the power mode (submode) for the System On low power mode. There are two possible settings NRF_POWER_MODE_CONSTLAT and NRF_POWER_MODE_LOWPWR, defined in nrf_soc.h. These modes are described on this thread.

  • Hi,

    Thanks a lot,but still there are some problems puzzle me. 1.How to go out from the sub power mode,or is this like the function sd_app_event_wait that can go out automatically? 2.I don't know where to find the electric current cost of the Low Power mode. 3.what's the period of the sd_app_event_wait function?or can I consider it as a while(1) and it can scan over and over again till a event come out? 4.Recently I use the ant to test the value of RSSI,it says it's about 200,I don't know if it's normal?or is there some kind of translation I missed?

  • About the quetion 4,can I say that the data is the twos complement?And the really value is -56dbm?

  • 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

  • Hi Birnir,

    Thanks a lot,about question 4,I use the way:

    /* Enable RSSI level for received messages */ sd_ant_lib_config_set(ANT_LIB_CONFIG_MESG_OUT_INC_RSSI);

    Then each time you receive a payload, byte 13 in event_message_buffer will contain the RSSI value, when reading out the event by: /* Fetch the event */ return_value = sd_ant_event_get(&ant_channel, &event, event_message_buffer);

    and the event_message_buffer[13] is the RSSI . Is this right?or can you tell me the difference between what you told me and what I do.Also,the value 200 I got should be pocess from twos complement to true form?

Related