Put BLE Mesh node in deep sleep

Hi,

We are working on BLE MESH using nRF52840. We are trying to put nRF52840 into deep sleep mode. The deep sleep current is about 210 micro Amp. Further, the current is continuously increasing approx. by 1 micro Amp after every 60 sec.

My setup:
nRF SDK ver : nRF5_SDK_17.0.2_d674dde
BLE MESH ver : nrf5_SDK_for_Mesh_v5.0.0
Hardware : BT840 based custom board

The functions used for putting the nRF52840 into deep sleep -
nrf_mesh_disable()
nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_STAY_IN_SYSOFF);

We also tried sd_power_system_off() but result are no better.

We are able to achieve deep sleep current of 500 nano Amp on same hardware, using Thread protocol. We are not sure how to achieve it using BLE Mesh.

It would be a great help if you could suggest a solution or give us a direction.

Kind Regards,
Rajendra

Parents
  • Hello Rajendra,

    Well first of all, if you are developing a new product for Mesh I would recommend you to use the nRF Connect SDK. That is the SDK that will be worked on going forward. 

    Secondly, even though Bluetooth 'low energy' is being used, Bluetooth Mesh isn't the most power efficient alternative. Continuous relaying and radio use is the backbone of Mesh, so for Bluetooth Mesh to pay off, you'd normally want at least one of the nodes being connected to the mains. Thread nodes can be configured to be very power efficient however, so its hard to compare Bluetooth Mesh and Thread.

    You can however use what are called Low Power Nodes along with Friend nodes with Mesh, which can be very power efficient. Is this what you are trying to do? If so, see here.

    Regards,

    Elfving

  • Hi,

    I am coming back to my original question on Mesh Leaf Node deep sleep current.

    Using BLE Mesh Friend Functionality I am able to achieve Leaf node running with average current consumption around 235 microA. Without Friend Functionality it consumes average current around 11.6 mA. So there is some improvement on current consumption but not enough if we want to operate the device on battery. Even if the device is being put into deep sleep mode, the current consumption remains around 220 microA. Is there any limitation of BLE Mesh stack preventing the device from Deep Sleep mode?

    What is the minimum possible achievable average current consumption with BLE Mesh Node? Are there any known examples/references I can refer to?

    Note: For measuring "average current", the average current in 1 minute is considered.

    Best Regards,
    Rajendra

  • Hi Christoph,

    I'm sorry for the late response. HĂĄkon is travelling and I will take over the case. 

    220uA when in sleep current is not normal. 


    We will need to take a look to see if it's the mesh stack causing the issue or it's the hardware on your custom board making that issue. 

    I would suggest to do the following: 

    - Test the same software on a Nordic Dev Kit and measure the current consumption as the reference. 

    - Test a very simple software on your board that put the device to  sleep mode and measure the current consumption. This is to rule out the issue with the mesh stack. You can try the rtc example in nRF5 SDK v17.1 . The current consumption should be around 3-4 uA. 

    The mesh lpn example when in sleep mode shouldn't consume more current than what you see in the rtc example. When in sleep mode it just puts the CPU and all peripherals to sleep and only keeps RTC running. 

  • Thank you for the information. I will discuss it with the Harman team next week.

  • Hi,

    We have migrated from nrf5_SDK_for_Mesh_v5.0.0 to nRF Connect SDK v2.1.2. We are referring to samples -
    nrf\samples\bluetooth\mesh\light_switch
    nrf\samples\bluetooth\mesh\light

    Using light_switch we are trying to produce DEEP SLEEP scenario. 225 uA is the lowest current value we are able to achieve. We tried following things.
    Trial 1: Try to make Friendship between light_switch and light server using friendship configuration settings.
        In light_switch
            CONFIG_BT_MESH_LPN_ESTABLISHMENT=y
            CONFIG_BT_MESH_LOW_POWER=y
            CONFIG_BT_MESH_LPN_AUTO=y
    In light
            No change
    Check the current on light_switch node. Average current observed = 6.4 mA (Too high)

    Trial 2: Put light_switch in deep sleep using power configuration settings and power management calls. There is NO Friendship between light_switch and light.
        light_switch prj.conf
            CONFIG_UART_CONSOLE=n
            CONFIG_GPIO=n
            CONFIG_LOG=n
            CONFIG_SERIAL=n
            CONFIG_PM=y
            CONFIG_PM_DEVICE=y
        light_switch main.c
            bt_mesh_prov_disable(BT_MESH_PROV_GATT | BT_MESH_PROV_ADV);
            bt_mesh_suspend();
            nrf_power_system_off(NRF_POWER);

    In light
            No change
    Check the current on light_switch node. Average current observed = 225 uA (Still High)


    Trial 3: Combination of trial 1 and 2. (We are not much confident about this trial).
    Put light_switch in deep sleep using power settings and power management calls.
    Try to make Friendship between light_switch and light server using friendship configuration settings.
        light_switch prj.conf
            CONFIG_UART_CONSOLE=n
            CONFIG_GPIO=n
            CONFIG_LOG=n
            CONFIG_SERIAL=n
            CONFIG_PM=y
            CONFIG_PM_DEVICE=y

        light_switch main.c
            bt_mesh_prov_disable(BT_MESH_PROV_GATT | BT_MESH_PROV_ADV);
            bt_mesh_suspend();
            nrf_power_system_off(NRF_POWER);

    In light
            No change
    Check the current on light_switch node. Average current observed =  225 uA (High)

    Trial 4: We used blinky app to check and verify the current consumption. We used following calls in main.c.
        In main.c
            nrf_power_system_off(NRF_POWER);
    Using blinky and power management call Average current observed = 660nA

    light_switch and blinky use same hardware settings on our BT840F based custom hardware.

    So from above trials it seems that BLE Mesh Node current consumption always higher even in DEEP sleep and is 221 uA. We are expecting much lower value. Can you please verify above settings and let us now if we are missing anything?

    Best Regards,
    Rajendra

  • Hi Rajendra, 

    Before you test with any mesh sample, please follow my suggestion in my last reply: 

    - Test a very simple software on your board that put the device to  sleep mode and measure the current consumption. In NCS SDK please try testing with the nrf\samples\boards\nrf\system_off sample. The current consumption should go down to ~1uA when the log says "Entering system off; press BUTTON1 to restart"

    - If you still see high current consumption, please test the same software on a Nordic Dev Kit and measure the current consumption as the reference. 

  • Thank you for suggestion. I did not find nrf\samples\boards\nrf\system_off. I found v2.1.2\nrf\samples\nfc\system_off. I will try this and share the results.

    Rajendra

Reply Children
  • Hi Rajendra, 
    My bad, please look for \zephyr\samples\boards\nrf\system_off 
    It's in Zephyr, not in nrf

  • Hi,

    Further update on Deep Sleep node. We used \zephyr\samples\boards\nrf\system_off sample and measured the deep sleep current. The measured average current was 498 nA. So this example gives us the expected Deep Sleep current.


    We then used similar code/settings in \nrf\samples\bluetooth\mesh\light_switch and measured the current. The measured current was 225 uA, similar to what we observed earlier. I was curious how this function - pm_state_force() behaves with BLE Mesh examples. Unfortunately it behaved the same way as nrf_power_system_off(NRF_POWER).
    So it seems that it is not possible to put the nRF52840 BLE Mesh device in Deep Sleep. Once the BLE Mesh stack is initiated there appears to be no way to cut off its power.
    I also tried to check if we could turn OFF the Bluetooth radio using any available function call on nRF52840 but it looks like there is no method to do so. There are a few references to this on Nordic Dev Forum.

    Any further suggestions on this?

  • Hi Rajendra, 

    I tried to reproduce the issue here but I couldn't see it. 
    Attached you will find the project I modified light_switch to enter deep sleep mode. 
    It worked in both cases before and after provisioned. 


    I attached the video when I tested here. You can see that when I pressed button 0 , I will call this: 

    		bt_mesh_prov_disable(BT_MESH_PROV_GATT | BT_MESH_PROV_ADV);
            bt_mesh_suspend();
            nrf_power_system_off(NRF_POWER);

    And the current consumption went down to about 2uA. The example is from NCS v2.1.2

    3107.light_switch_sleep.zip

    My suggestion is to get hold of a DK and use it as the reference. 

  • PS: After further testing I found that I also got 200uA. But only when the serial port is open. 
    Could you try to test with 

    CONFIG_SERIAL=n
     in prj.conf ? 
    if you still need logging, I think we need to disable UART before enter sleep mode. 
    Or you can use RTT for logging but you also need to disconnect RTT if you want to have low power consumption. . 
  • Hi,

    We are able to achieve deep sleep current on DK board. It came down to ~18.5 uA. Now we trying current measurement on BT840 based custom board. The difference between your current measurement setup and ours is - 

    • We are using DK H/W ver 2.0.1 2020.38 and you are using DK HW ver 1.0.0
    • We are taking a hard reset before current measurement. Are you also taking a hard reset?

    One interesting thing we noticed, when we download the firmware and do not take hard reset, the deep sleep current measured is ~3.3 uA. But when we take a hard reset after download, deep sleep current is ~18.5 uA.

    Thank you for your quick support. We will now checking this on our BT840 based custom board.

Related