Reducing the LPN examples power consumption

[Heiner]

Hello,

I'm still a beginner with mesh so excuse me, if this might be a silly question or has been answered before. I did not find a post that quite resembled my problem.

So for my use case I want to power my sensor node and display multiple states. (For now implemented as on off server since I haven't wrote my own model yet)

Because the sensor node is supposed to be powered by a battery, I'm trying to use as less power as possible.


So far I have implemented the use case in both regular and LPN + Friend Node.


When I configured the low power node, I expected it to consume less power than the relaying switch application, but so far (even with the friendship established) the low power application shows no difference to the relaying switch application. In fact it even consumes more power than my optimized switch application.


I tried to change the parameters of the friend connection and disabling the LEDs, but it does not seem to make any difference.

#define FRIEND_REQUEST_TIMEOUT_MS (MESH_LPN_FRIEND_REQUEST_TIMEOUT_MAX_MS)
/** The upper limit for two subsequent Friend Polls. */
#define POLL_TIMEOUT_MS (SEC_TO_MS(30)) // changed from 10
/** The time between LPN sending a request and listening for a response. */
#define RECEIVE_DELAY_MS (10) // changed from 100


From my measurements it looks like the application is never entering low power mode, even though the poll timeout is set to 30 seconds.

You can see that the nRF module consumes more power for a short period of time to establish the friendship, but nothing is changing after that.

So my question is what might stop the application from entering low power mode and how to pause the application manually. (1)

And also: In this case the sensor only really needs to send data, not receive any. What is the best way to realize that type of sensor in a mesh? Would it be possible to set NRF52 to deep sleep mode and only wake up by toggling a GPIO, still keeping it a member of the mesh by keeping it al LPN? (2)

[bjorn-spockeli]

Hi Heiner, 

Which MESH SDK version are you using? V3.0.0 or v 3.1.0? 

Have you tested the unaltered Low Power node example (experimental) in the Mesh SDK? Does this have a lower current consumption than the regular switch example?

In this case the sensor only really needs to send data, not receive any. What is the best way to realize that type of sensor in a mesh? Would it be possible to set NRF52 to deep sleep mode and only wake up by toggling a GPIO, still keeping it a member of the mesh by keeping it al LPN? (2)

 Yes, if the sensor nodes do not need to relay mesh packets to other nodes, i.e.e you have a "backbone" of powered nodes that takes care of the relaying, then you should be able to put the sensor nodes in SYstem OFF and then wake them up with a button press. 

[Heiner]

Next, I tried the example from the v 3.1.0 MESH SDK,

with only few changes:

So first I changed this define:

#define FDS_PHY_PAGES_RESERVED ((FDS_VIRTUAL_PAGES_RESERVED * FDS_VIRTUAL_PAGE_SIZE) / FDS_PHY_PAGE_SIZE))

to

#define FDS_PHY_PAGES_RESERVED 0

because otherwise I would get the error, I described before.

Then I changed the feedback from the LEDs to only flash for a short period, instead of being constantly on.

This way the difference between friendship consumption and no friendship consumption is easier to see.

Still my problem remains. As you can see, the node still consumes a tiny bit more power in friendship node.

How is this possible? Is it, because of the polling process?

And in this case, wouldn't it be better to just use the low power node without a friend connection?

Again, thank you for helping me understand this topic better.

[bjorn-spockeli]

Hi Heiner, 

If the polling is the cause, then it would mean that the LPN node is constantly polling the Friend node, which sort of defeats the purpose of having a LPN in the first place. 

How often do you see the NRF_MESH_EVT_LPN_FRIEND_POLL_COMPLETE if you look at the log output from the LPN node?

I have asked the Mesh team to clarify what current consumption figures one should expect when using the example from the SDK as is. 

Best regards

bjørn

[Heiner]

Hi Bjorn,

thanks for the quick reply.

The polling completes about every 8 seconds. Looking at the image before, this confirms my guess, that the two big peaks that can be seen once the friendship is established are due to the polling process.

However, there still seems to be some other stuff going on there, which behaves consistent no matter if the device is in low power mode or not.

For now I cannot really see the difference in the two, besides the added peaks from the polling process.

Maybe the Mesh team can clarify what's going on here.

Sincerely,

Heiner

[bjorn-spockeli]

Hi Heiner, 

The Mesh time provided the following feedback:

The example was designed for demonstration purposes, and hence some of its features (namely, status LEDs and RTT input polling) cause a significant amount of power consumption when the example firmware is executing. For this reason, you must disable these features to obtain more accurate power measurements.

Apply the following modifications at the paths provided:

• \examples\experimental_lpn\include\nrf_mesh_config_app.h
  • Disable use of DK LEDs by setting SIMPLE_HAL_LEDS_ENABLED to 0.
  • Disable RTT Input by setting RTT_INPUT_ENABLED to 0.
• app_mesh_core_event_cb() in \examples\experimental_lpn\src\main.c
  • Disable proxy service advertising when NRF_MESH_EVT_FRIENDSHIP_ESTABLISHED event is received by calling the proxy_stop() API.
  • Enable proxy service advertising when NRF_MESH_EVT_FRIENDSHIP_TERMINATED event is received by calling the proxy_enable() and then the proxy_start() APIs.

After making these modifications, recompile the LPN example and flash this example and the Zephyr friend binary on two development boards. Provision the Zephyr Friend node into the network using nRF Mesh App.

Please perform the suggested modifications and see if you see a reduction in the current consumption of the LPN node. 

Best regards

Bjørn

[Heiner]

Thank you, that worked.