Put BLE Mesh node in deep sleep

RE: Put BLE Mesh node in deep sleep

Florent243 — Wed, 05 Jun 2024 14:26:09 GMT

Hi Hung,

Thanks for that reference, for those who continue to check this topics, this solution still works.

I facing the same issue with ncs 2.3.0 ; when going in deep sleep, if the device was not provisioned I was able to decrease to 7uA (we have a TOF who consume around 5uA in off reset).

But when the device was previously provisioned the current remain at 500uA

Adding you code line remove the issue. Here is my code for those who wondering:

void go_system_off(){
	int rc;
	struct pm_state_info deep_sleep_param={PM_STATE_SOFT_OFF,0,0};


	printk("\n%s system off\n",CONFIG_BOARD);

	TOF_PowerDown();
	dk_button_handler_remove(button_changed); //Remove handler to avoid conflict
	

	/* Configure to generate PORT event (wakeup) on button 1 press. */
	nrf_gpio_cfg_input(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0),gpios),
		NRF_GPIO_PIN_PULLUP);
	nrf_gpio_cfg_sense_set(NRF_DT_GPIOS_TO_PSEL(DT_ALIAS(sw0),gpios),
		NRF_GPIO_PIN_SENSE_LOW);

	bt_mesh_prov_disable(BT_MESH_PROV_GATT | BT_MESH_PROV_ADV);
    bt_mesh_suspend();

	printk("Entering system off; press BUTTON1 to restart\n");

	pm_state_force(0u,&deep_sleep_param);

	k_msleep(2000);

	while(true){
		/* spin to avoid fall-off behavior */
	}
}

RE: Put BLE Mesh node in deep sleep

Hung Bui — Wed, 30 Nov 2022 12:46:01 GMT

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.

RE: Put BLE Mesh node in deep sleep

Rajendra — Wed, 30 Nov 2022 09:23:00 GMT

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.

RE: Put BLE Mesh node in deep sleep

Hung Bui — Tue, 29 Nov 2022 15:36:57 GMT

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.

RE: Put BLE Mesh node in deep sleep

Rajendra — Mon, 28 Nov 2022 06:28:20 GMT

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.

RE: Put BLE Mesh node in deep sleep

Hung Bui — Tue, 22 Nov 2022 09:12:33 GMT

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

RE: Put BLE Mesh node in deep sleep

Hung Bui — Tue, 22 Nov 2022 08:47:56 GMT

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.

devzone.nordicsemi.com/.../6646.20221122_5F00_093959.mp4
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

devzone.nordicsemi.com/.../3107.light_5F00_switch_5F00_sleep.zip

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

RE: Put BLE Mesh node in deep sleep

Rajendra — Tue, 22 Nov 2022 06:52:36 GMT

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?

RE: Put BLE Mesh node in deep sleep

Hung Bui — Thu, 17 Nov 2022 13:35:50 GMT

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

RE: Put BLE Mesh node in deep sleep

Rajendra — Thu, 17 Nov 2022 13:03:05 GMT

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

RE: Put BLE Mesh node in deep sleep

Hung Bui — Thu, 17 Nov 2022 12:00:59 GMT

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.

RE: Put BLE Mesh node in deep sleep

Rajendra — Thu, 17 Nov 2022 10:43:32 GMT

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

RE: Put BLE Mesh node in deep sleep

cgr — Wed, 26 Oct 2022 14:59:09 GMT

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

RE: Put BLE Mesh node in deep sleep

Hung Bui — Wed, 26 Oct 2022 09:10:49 GMT

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.

RE: Put BLE Mesh node in deep sleep

cgr — Thu, 20 Oct 2022 18:28:43 GMT

Hi,

I am working the team of Rajendra.
The big question is if there is a chance with a leaf node to reach similar sleep currents then with thread. That means below 1 uA. I mean to reach it with the NordIC SDK's.

As I understand are the leaf nodes in BLE mesh networks intended to run peripheral nodes on battery power. If we would like to run a node several years with the same battery, we need to reach that small sleep currents.

regards

Christoph Graf

RE: Put BLE Mesh node in deep sleep

tesc — Tue, 18 Oct 2022 12:38:01 GMT

Hi,

The following is for the nRF Connect SDK. I am sorry for jumping in on the discussion before double checking SDK version, but will leave the answer standing in case it is still relevant for someone reading this in the future.

For saving power outside of friendship, you can enable the CONFIG_BT_MESH_LPN_ESTABLISHMENT. Normal nodes (and LPNs outside of friendship) will have RX enabled at all times, leading to high power consumption. With the above "LPN establishment" setting on, it will have around 10 % RX duty cycle instead.

When powering the LPN, it will act as a normal node for an initial period of time, controlled by the CONFIG_BT_MESH_LPN_AUTO_TIMEOUT setting. Decreasing it will shorten the "active" period after boot, more quickly entering the the "LPN establishment" state of 10 % RX duty cycle.

The serial drivers draw a lot of power. If you don't need them, you can usually save a lot by disabling CONFIG_SERIAL.

With these settings, I have measurements of around 700 uA while not in friendship, and around 20 to 30 uA while in friendship.

Regards,
Terje

RE: Put BLE Mesh node in deep sleep

Rajendra — Tue, 18 Oct 2022 10:44:55 GMT

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

RE: Put BLE Mesh node in deep sleep

Rajendra — Wed, 12 Oct 2022 13:59:20 GMT

Please refer to this new case: devzone.nordicsemi.com/.../error-compiling-lpn-example-from-ble-mesh-v5-0-0

RE: Put BLE Mesh node in deep sleep

Elfving — Wed, 12 Oct 2022 13:13:39 GMT

Hi again Rajendra,

Could you open a new case for this, as it is a bit besides the main subject of the headline? I also want to note that you can go ahead with the nRF5 SDK as as it seems you have done, though I did recommend continuing with the nRF Connect SDK instead.

Regards,

Elfving

RE: Put BLE Mesh node in deep sleep

Rajendra — Tue, 11 Oct 2022 12:32:08 GMT

Hello,
I am tryting to compile lpn example from examples - nrf5_SDK_for_Mesh_v5.0.0\examples\lpn. It looks like the example needs some modification in order to compile. The example shows this error while compiling.

..\nrf5_sdk_17.0.2_d674dde\modules\nrfx\drivers\include\nrfx_power_clock.h:67:6: error: #error "This code is not supposed to be compiled when neither POWER nor CLOCK is enabled."
67 | #error "This code is not supposed to be compiled when neither POWER nor CLOCK is enabled."

POWER_ENABLED and NRFX_POWER_ENABLED is already 1 in the example code. So upon enabling macros NRF_CLOCK_ENABLED and NRFX_CLOCK_ENABLED or it shows further compilation errors. I was wondering if this is a right way to go about it.

nRF5_SDK_17.0.2_d674dde/external/segger_rtt/SEGGER_RTT_Conf.h:86:46: error: 'SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS' undeclared here (not in a function); did you mean 'SEGGER_RTT_MAX_NUM_DOWN_BUFFERS'?
86 | #define SEGGER_RTT_MAX_NUM_DOWN_BUFFERS (SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS) // Max. number of down-buffers (H->T) available on this target (Default: 3)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../nRF5_SDK_17.0.2_d674dde/external/segger_rtt/SEGGER_RTT_Conf.h:86:46: note: in definition of macro 'SEGGER_RTT_MAX_NUM_DOWN_BUFFERS'
86 | #define SEGGER_RTT_MAX_NUM_DOWN_BUFFERS (SEGGER_RTT_CONFIG_MAX_NUM_DOWN_BUFFERS) // Max. number of down-buffers (H->T) available on this target (Default: 3)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Kindly let me know the changes/modification required to compile lpn example.

Best Regards,

Rajendra

RE: Put BLE Mesh node in deep sleep

Rajendra — Wed, 14 Sep 2022 12:47:11 GMT

Thank you Elfving for response! Will certainly explore on Friend nodes.

Regards,
Rajendra

RE: Put BLE Mesh node in deep sleep

Elfving — Wed, 14 Sep 2022 11:03:47 GMT

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