Put BLE Mesh node in deep sleep

[Rajendra]

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

[Elfving]

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

[Rajendra]

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

[Hung Bui]

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. 

[Hung Bui]

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. . 

[Rajendra]

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.

[Hung Bui]

Hi Rajendra, 

Thanks for the information. Have you found why it was around 200uA before with your code ? 

Regarding the issue with 18.5uA. How did you measure the current consumption ? Did you use a multimeter ? Could you try to measure the current with a PPK2 ? 

Could you explain which hard reset you used ? Was it a power reset or pin reset ? 

When you see the current consumtion to 18.5 uA , could you try calling "nrfjprog -r" to trigger a soft reset ? and check if the current consumption when entering system off still the same or go down to 3.3uA ? 

I would suggest to try testing on other board as well because the DK has a programmer chip on it and may cause extra current. 

[Rajendra]

Hi,
In earlier trials we never tried it on DK board. We were always checking it on custom board. 225 uA was observed on custom board.
We used multimeter to measure current on DK board that came to 18.5 uA. We also have advanced current meter where we can see the current value on waveform.
We are not using PPK2 kit since we have advanced current meter but definitely it would be one of the best options to measure the current.
We used power reset to hard reset the board.
We have not used nrfjprog -r to trigger soft reset, will check it.

[Hung Bui]

Hi Rajendra, 

So with the same firmware do you still see the high current consumption (225uA) on the custom board ? 
If you still see that you may want to isolate the current measurement so that it only measure the current draw on the nRF52840 chip, not anything else. I am suspecting there could be something else on the custom board drawing the current ? 

Also did you write anything to UICR ? Have you tried to do a nrfjprog --recovery ?  There could be a chance that the UICR configuration of GPIO pins can be the issue here (reset pins and NFC pins). 

Regarding the issue with 18.5 uA. We need to double check here to see why that happens.