High current usage during Zigbee Joining

[iharyadi]

Hi Everyone,

I have been developing with nrf52840 for quite sometime using Arduino.  I would like to explore nrf5 Sdk for Zigbee and Thread because I want to use my nrf52840 with Zigbee.   I have custom board from ebyte.com E73-2G4M08S1C.

I took example from nrf5sdk 4.1.0 version.  I use the \nRF5_SDK_for_Thread_and_Zigbee_v4.1.0_32ce5f8\examples\zigbee\experimental\multi_sensor.  It is the non freertos version of multi sensor.  I modified the example as I just need the temperature reading.  I just remove the code related to the pressure.

The example work with the Zigbee hub( it is called hubitat).  This is not important.  I just want to give some context that the stack work as expected.

I do observe one issue.  When the nrf52840 start and has not join any hub (coordinator),  it consume 17 mA.  Once joined,  the current consumption is very acceptable for my need.  They are in the low micro Amp range.  On a nrf52840 that has joined (already in network),  during start up,  it consume the same 17 mA for a few seconds.   I do not clear the persistence storage on reboot.  I believe that again once the nrf52840 joined the Zigbee mesh,  it work properly as a sleepy end device.

I had worked on Zigbee on different platform.  I am aware during join or rejoin process,  the nrf52840 may need to have its radio active either sending beacon request or listening on beacon response.   My question is that during this time,  is there anyway in the stack where we can tune the joining process to minimize the current consumption.   I am using energy harvester.  The current generated is good enough to operate the nrf52840 once it got over the process that require the 17mA.   The harvester cannot supply 17mA continuously for a few seconds during this joining process. I also open to suggestion if this process can be spread out so that the nrf52840 have a chance to sleep.  It will give the harvester to accumulate enough power to run the next try of join/rejoin.

Thanks for your help in advance.  If you are aware of any solution,  I would appreciate it if you can share it with me.

br

Iman

[Kenneth]

iharyadi said:

However,  is there a way to reduce current consumption during this period?  Can the MCU be put to sleep while the radio stay on waiting for beacon response?

I expect you can save most current by enabling DCDC, can you try to call: 
nrf_power_dcdcen_set(true);

I will ask the team for future to also look into the receive window timing and cpu sleep during joining could be made more configurable.

[iharyadi]

Kenneth said:

I expect you can save most current by enabling DCDC, can you try to call: 
nrf_power_dcdcen_set(true);

Yes,  I actually did that.  I do not want to mentioned it prematurely.  With DCDC on,  the current consumption is down 8.8ma.  

I tested the board with simple nrf_delay_ms like below.

...

...

int main()

{

...

...

while(true)

{

  nrf_delay_ms(1000);

}

}

Mostly,  I disable all functions.  With DCDC enable.  The above use approximately 4 mA current.  This is consistent with my guess.  The MCU and radio is ON during bdb steering.  Is there opportunity to optimized it?    I believe I asked before.  Is it possible to put MCU to low power mode in between beacon request and "waiting for" beacon response?

This issue is not specific to energy harvester.   A battery powered end device will drain its battery if it lost connection to the parent/coordinator.   It will periodically reach its parent and consume 8.8mA of current for about 5 to 10 seconds.    I am a home owner with some home automation.  Power outage is rare but does happen.   When power outage happen,  battery powered end device will still be functional.  The parent (coordinator/router) will most likely be off unless a home owner have whole house UPS system.

For my case (used in energy harvester),  the 8.8 mA is a good improvement compare to 17mA.  However,  it still require me to use a big storage such as large super capacitor or small lithium battery.  It impacts the start up time.  Meanwhile,  the nrf52840 current consumption during idle time is extremely good for my case.  

Thanks

Iman

[Kenneth]

During this period the radio is scanning, so even if you call __WFE() to put the CPU in sleep while radio is active, I don't expect there will be much reduction in current consumption since the radio will in any case require most regulators and clocks being powered (this is a shared resource with the CPU).

I am a bit surprised you measure as long as 5-10 seconds, the light switch example I can see is up to 2.5seconds before next interval.

Maybe you can try to enable cache, this may reduce current consumption further:
NRF_NVMC->ICACHECNF = 1;

[iharyadi]

Thank you for your suggestion.  I will try the NRF_NVMC->ICACHECNF = 1.  I will report back to you.

My methodology of measuring the interval time is not very precise.  However,  the bdb steering period is on the order of seconds.  I can further investigate to get more precise measurement.  Basically,  this chunk of energy consumption will be the fundamental of how much energy storage I would have to give to my board.  The larger the storage,  it will be longer to start the device.

Kenneth said:

During this period the radio is scanning, so even if you call __WFE() to put the CPU in sleep while radio is active, I don't expect there will be much reduction in current consumption since the radio will in any case require most regulators and clocks being powered (this is a shared resource with the CPU)

 

I understand.  Based on my experiment with nrf_delay_ms(),  the MCU consume 4mA on my board.  Assuming the radio is using ~4.XX mA while it is listening to packets (I got this from datasheet) .  The 8.8mA that I am seeing can be reduce to approximately 4.XXmA while we are waiting for Beacon response.  That would help for saving the energy.  That was my initial guess.  My assumption on how it works was incorrect.  Now,  I understand that the Radio may share some resources with CPU.  Those resources cannot be turned off for the radio to function.

[iharyadi]

Hi Kenneth,

I have tried the NRF_NVMC->ICACHECNF = 1.  It does not really help.

In the meantime,  I have bought ppk.  I feel a little bad since the day I bought it,  PPK2 is announce.   Anyway,  that is different story.

Here is my result for PPK

I power down my board 2 times.   As you can see,  during the joining,  there is a long period of high power consumption.   I zoom on one of the segment.

During the joining,  there is roughly 8 to 10 seconds process that consume high current.  My multi-meter cannot catch the peak to peak voltage.  It measure 8mA which is pretty consistent.

You can see that the sleep current after joining is above and beyond very good.  A lot harvester can work with it.  However,  the joining process is very concerning.

You did mention the broadcast interval on your test was 2.5 seconds if I remember correctly.   If I can get that interval,  I think I can work with it.   But, 8 seconds is a bit long.   This is a code in zigbee library that I do not have access to.

Please let me know what you think.

Thanks

Iman