Reducing power usage of the Light Switch Server

[SamTheMan]

Hello everybody,

I'm currently trying to create a Bluetooth Low Energy Mesh network of multiple nodes that I can control using a Bridge application.

I use a nRF52840 DK with the Serial Example (PyACI) for my Bridge and the nRF52840 DK's loaded up with the Light Switch Server example for my nodes.

Now my system seems to be working fine (With the bridge I can provision and turn nodes off/on remotely), however when I measure a node's current using the Power Profiler Kit 2 I get a power consumption average of ~13mA when not sending messages and ~15mA when receiving messages.

After more investigating this seems to be so, because the nodes are constantly scanning for messages, which seems to consume ~10mA and the BM-LPN node example seems to consume roughly 8mA?

Is there a way to reduce the power consumption of my nodes to be within the µA range if they're not sending messages?

Cheers,

Sam

[Kenneth]

A node will be in receive mode pretty much all the time waiting for messages or relaying them, typically drawing in the ~10mA range continously.

A low power node (LPN) can be in idle most of the time, and only intermittently poll data from a node that it has established a friendship with. In your case it sounds like the LPN node is not in a connection yet, and possible searching for a node to establish a friendship with.

Kenneth

[SamTheMan]

Hi Kenneth,

I have dropped the custom bridgeapp for now and implemented that the LPN Client node example can establish friendship with nRF Light Server Nodes.

The power consumption dropped to ~8mA on the Light Switch Server and to ~1mA on the LPN Client node example.

While it is progress, I think the power consumption on the Light Switch Server is still a bit high.

I'm trying to create a low power network where all Light Switch Server nodes run on as low power consumption as possible.

Do you know how what's the easiest way to implement LPN on the Light Server Nodes?

I've looked at Integrating Low Power node feature, however I'm still new at this and am unsure how to proceed.

Cheers,

Sam

Edit:

Made some small changes to the network.

Light Switch Server nodes (Friend nodes) consume same with or without friendship (~10mA in nRF only mode )

LPN Client example node (Low power nodes) consumes less now ( ~15µA. in nRF only mode )

[Hung Bui]

Hi Sam, 
I'm taking over the case from Kenneth. 

15uA current consumption for the LPN is about right the average current consumption depends on the wake up interval of the LPN node. 

10mA on the Light switch server is also correct. A normal mesh node (not LPN) is designed to do radio scanning all the time. It doesn't really matter if it's a friend node or not. The significant part of the consumption is radio scanning. 
At chapter 5 in the nRF52840 datasheet you can find the current consumptions: 

I'm not sure if you are using DCDC or not, but the number matched with radio receiving with no DCDC. 

If you use DCDC the consumption can be lowered down to 6.53mA. 

Bluetooth Mesh is not designed as a low power mesh. So I am not sure there could be an easy way to reduce the power consumption of the Friend nodes without affecting the performance of the mesh network. A connected mesh protocol (instead of flooding mesh) may have lower power consumption on the backbone nodes but it's more complex and has some drawback as well (for example dynamically and mobility)

[SamTheMan]

Hi Hung Bui,

Thank you for your time and sorry if I overload you with questions haha.

I will take a look at the DCDC that you suggested.

 

1) Let's say my mesh topology looks like this where devices are only connected to the ones that have an arrow drawn to them:

     LPN sensor 1 <---> Friend Light Server 1 <---> LPN sensor 2 <---> Friend Light server 2

If LPN sensor 1 triggers, would it be possible to turn on Light server 2 through the mesh?

 

2) Can only Edge devices implement the low power feature in a mesh network?

 

3) "The significant part of the consumption is radio scanning."

Would it be possible for nodes to interrupt its scanning in order to reduce power?

For example by syncing the scanning of friend nodes to the wake-up interval of LPN nodes?

 

cheers,

Sam

[Hung Bui]

Hi Sam, 
1) a LPN node can't talk to 2 friends node at the same time. So this part won't work: 

 Friend Light Server 1 <---> LPN sensor 2 <---> Friend Light server 2

But this work: 
  LPN sensor 1 <---> Friend Light Server 1 <---> Friend Light server 2  <---> LPN sensor 2

2) Correct

3) You can put the friend node / relay node to sleep mode to reduce current consumption but it will affect the mesh performance. It won't be able to relay mesh packet when it's sleeping. There is no synchronization between relay nodes. 

If you don't plan to have a large number of nodes, a better solution is to use Bluetooth LE as multiple of star networks. 
Each BLE node can handle up to 20 connections at the same time. And they will have much lower consumption compare to mesh. We are talking about a dozen of uA compare to 6mA. 

[SamTheMan]

Hi Hung Bui,

 

"Each BLE node can handle up to 20 connections at the same time."

Do you mean in-general for the Bluetooth specifications? Because it looks like the nRF52840 DK board loaded with the 'light switch server example' can only handle 2 friendships from "LPN Client node example" at the same time.

I get the NRF_ERROR_NO_MEM error whenever I try to establish a 3th friendship to a single Friend node (first 2 friendships establish successfully).

So I read on webpage https://www.bluetooth.com/blog/bluetooth-mesh-networking-series-friendship/

"The amount of RAM available directly affects how many LPNs a Friend node can support and how many messages it can buffer for associated LPNs." 

Which makes me believe the nRF52840DK boards have only enough RAM to handle 2 friendships at the same time. Is this correct? Or is there a setting I can change to be able to add more nodes?

 

I've managed to set up a good working network; Although that would be my only restriction at the moment.

 

Cheers and thanks for the help,

Sam