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

Current measurements in low power modes

Hello, I am working on a project that uses nrf52832 and I need to put that device and in the system on mode. For that, I want to measure the current in the system on and system off mode which is 1-2 uA and 0.2 uA respectively, but I do not get these values. Can you provide me with the code for which I can measure the current in system on and system off mode to get the above values? I had used ble_app-pwr-profiling example to get the values but I did not get the desired values.

Parents
  • I do not get these values

    So what values do you get?

    And how, exactly, are you measuring?

    At these levels, you need to be very careful about how you take the measurements - and to ensure that you are actually measuring just the DUT, and not leakage to other parts of your system ...

  • I get 287.099 uA in system on mode. I am measuring using PPK and measuring only the DUT. I am using ble_app_pwr_profiling example.

    SDK used is 15.3.0 

  • I tried for the ble_app_pwr_profiling example and got the current between the peaks as 2.695 uA average current which I think is the system on mode current now next is how to get the system off mode? As even if I am not connecting the device I think it is entering the system on mode i.e idle state and not system off mode.

    If I am wrong then which current is it that I got as 2.695 uA between the advertising peaks? system sleep mode on or system sleep mode off current? Because if it was system off then current should be much lower than the measured current.

    And when I checked for the pwr_mgmnt example I got the system off current as 0.731 uA and system on current as 2.801 uA.

    Thank you Edvin for your time and support. I have got these readings because of your guidance. Waiting for your response for the question I have regarding ble_app_pwr_profiling example.

  • sara said:
    I tried for the ble_app_pwr_profiling example and got the current between the peaks as 2.695 uA average current which I think is the system on mode

     Yes. That is system on mode (as long as you call sd_app_evt_wait() in your main-loop).

    If you are using the softdevice, you can't be in system off mode, hence my conclusion that you are in system on mode. If you are in system off mode, you need a physical interrupt in order to wake up the device, so you can't do this in between advertisements or if you are connected.

    System off mode is not entered until you call sd_power_system_off(), which typically happens in:

    on_adv_evt() -> case BLE_ADV_EVT_IDLE: -> sd_power_system_off();

    In the ble_app_pwr_profiling example, the advertising timeout has a different name. It is the one called APP_ADV_DURATION, which is originally set to 30000*10ms. If you change the define to 500, it will time out after 5 seconds.

  • Thank you -for the clarification regarding the system off mode. I was a bit confused because of the condition given in ble_app_pwr_profiling example as below:

    if (!m_is_notification_mode && !m_is_non_connectable_mode)
    {
    // The startup was not because of button presses. This is the first start.
    // Go into System-Off mode. Button presses will wake the chip up.
            nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);
    }

    I had changed APP_ADV_DURATION to 500 but still continues advertising. 

    Because even if I am not connecting via nrfConnect application then also it remains in the system on mode I mean advertising and not in system off mode. 

  • It should start in system off, as it says there.

    I wouldn't worry too much about this example if I were you. You can focus on your application, and use the PPK to determine whether the current consumption is too high there.

    This example is set up a bit different from the other BLE examples. 

    But if you need to measure on this example, you can see that depending on what button that is pressed it will advertise in a different mode. Both modes uses the APP_ADV_DURATION timeout. Maybe something connects to your device, so that the device resets the advertisement timeout. Or does it time out after 30 seconds? If it never times out, are you sure that you have flashed the example correctly?  I have tried this example a lot on my desk now, and it behaves like it should, and like it is explained in the description of the example

    If it doesn't maybe we are using different versions of the SDK? Either way, I suggest you try another example that has logging enabled, so that it is easier to see what's going on. 

    It is possible to see what's going on here as well, but it is a bit more work to get the logger up and running in this example. Feel free to try, but in my opinion, it's not worth it. And it is easier to measure the system off current in a project using the softdevice just by reducing the advertising timeout in the other examples.

  • "If it doesn't maybe we are using different versions of the SDK? Either way, I suggest you try another example that has logging enabled, so that it is easier to see what's going on. " 

    Yes for that I am trying ble_app_uart example and will let you know what I get.

    And again of I failed at it then will reduce the advertising timeout.

    Thanks.

Reply
  • "If it doesn't maybe we are using different versions of the SDK? Either way, I suggest you try another example that has logging enabled, so that it is easier to see what's going on. " 

    Yes for that I am trying ble_app_uart example and will let you know what I get.

    And again of I failed at it then will reduce the advertising timeout.

    Thanks.

Children
Related