Reducing power consumption for ble mesh sensor server node using LPN mode

[harid]

Hi, 

I am using nrf mesh sdk v5.0.0 and am using sensor server model example to build our own application on top of it. SOC we are using is  nRF52832.  I have enabled the LPN mode in the example and I am also able to establish friendship with a nearby friend node. And am also receiving messages intended to the LPN node when the LPN node polls its friend node. The purpose for LPN node is to reduce battery consumption by disabling the scanner. But the device is consuming a solid 5 - 8 mA after establishing friendship. Is it possible to reduce the battery consumption in the micro amperes range. Any guidance on how to achieve it would be really great. I am also interfacing an LED, I2C sensor and a switch with the SOC. Before and after establishing friendship, I am seeing same amount of current being consumed. 

[Hung Bui]

Hi Hariharan, 

Could you describe how did you do the test ? How did you do provisioning ? 

Have you tested with the LPN example with no modification ? In the example the power consumption should drop down to few uA after it provisioned and get a friendship. 

Which current do you see exactly after you establish friendship ? Have you verified that the CPU was not being kept awake by other modules ? 

[harid]

I am provisioning the sensor node using an ESP32(acting as a provisioner). Once the provisioning and model configuration is done, I am initiating the friendship establishment procedure. The current consumption goes as low as 150ua after establishing friendship. But it increases to 3ma after publishing data once. And it should return to low power consumption mode right? But its not. The sensor node is constantly consuming 3ma after publishing. I dont know why this is happening. Can you please guide me?

[Hung Bui]

Hi Hariharan, 
I would suggest to continue on the other cases. It's important that you narrow down the issue to see where the current is from. Please try to test the code without mesh and see if you can achieve lower current. So that we know if it has anything to do with mesh or not. And to know which exact peripheral causing the problem. 

[harid]

Hi hung,

I was able to reduce the current consumption to upto 20ua. The current consumption was due to some known errata. Once the workaround is implemented, it was resolved. Thank you so much for your time and quick responses. Appreciate it much!

[Hung Bui]

Hi Hariharan, 
I'm glad to know that you solved the issue. It's good that you created new cases for each peripheral. Kenneth and Einar have much more experience with those peripherals than me that they can easily spot the 400uA issue :D 

[harid]

Yes, Hung. It worked. 

Now I am stuck at somewhere which is completely unexpected: I have explained the issue in this ticket - link . Can you help me with this? No engineer is assigned to it yet!

[Hung Bui]

Hi Hariharan, 
An engineer has been assigned to your case. He will reply you shortly. 
My suggestion for you is to try to debug on both sides. 
You need to verify that the ESP has sent the composition data get to the right node, and the actual packet is getting out of the radio. 

Then on the nRF52's side you need to check if it receive the packet correctly and if handle_composition_data_get() is triggered on the nRF52. 
After that check if the nRF52 send the data out. 

[harid]

ESP is sending it properly and a timeout happens each time it is trying to get the composition data. In nRf side, the api which you mentioned is not triggered.