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]

Let me check with the developers, what is the maximum average current consumption you may tolerate during (re-)joining?

Kenneth

[iharyadi]

Hi Kenneth,

Thank you for looking into this.  

I like to give you some context.  It is hard to give you a single current rating that I need.   I will try to answer based on what I am experiencing. 

I am using thermopile to generate power.  The theoretical power output is 750mV and .125A.  It is about 90 milli Watt power.  I always get less than this rating.  However,  I use harvester IC that would be able to store (accumulate) enough power on capacitor or battery before it started.  Therefore there is a delay before the whole device started.  The net power that I got is less than the theoretical value.  However,  the harvester IC is very efficient. 

I have tested with larger 200mhA battery as storage.  This solve the issue of power consumption during rejoining on reboot.   It is not perfect since it takes about 30 to 60 minutes for my device to start.  It would not solve un-joined nrf52840 (virgin device).  

Please note,  on the device that has joined,  the 17mA happen only during a reboot until the device re-joined back to the mesh.  The re-joining process is only taking a few seconds which the 200mhA battery can handle.

I am wondering whether the zigbee stack is optimized to go to low power during join/re-join process.  I did not observe any burst of current usage.  It is continuously measure at 17mA.  Therefore,  I suspect that the device never goes to low power mode during this time.  I think, in joining process,  there should be opportunity to put the device to low power mode.  

Again,  thank you for the help.  I really appreciate it. 

br

Iman 

[Kenneth]

Thanks for the additional details, the team will look into what may be done. This can take some time, but I will  update if there is any suggestions or solutions.

Kenneth

[Kenneth]

I have looked at the light switch example in this case (sleepy end device, intended for battery powered operation, ), the multisensor example haven't really been considered for low power (it can run off mains).

"The switch does support the Sleepy End Device behavior, meaning that the stack can make the CPU enter the sleep mode, resulting in a significant conserving of energy and prolonged battery life as a result. The device shall automatically wake itself up on an event. Besides, the CPU will wake itself from time to time to ensure the correct processing of stack internals."
For the light switch example the following should help:

1. IDLE current can be lowered the if Sleepy behavior is enabled, for light switch sample, Button 3 should be pressed and held when device is booting or restarted. This will ensure zb_set_rx_on_when_idle(false).

2. Interval between beacon requests being sent can be modified - right now, for End Devices, interval is increased after each beacon request (1s, 2s, 4s, 8s, 16s ...) by the network rejoin procedure. This can be changed to fixed intervals by handling all signals responsible for the association/joining (FIRST_START, REBOOT, STEERING, LEAVE) in the application.

[iharyadi]

Thank you for the response.

I have studied the code especially on suggestion #2.  I understand the logic.   The example code for multi sensor has already done zb_set_rx_on_when_idle(false).

I think there is a mis-understanding.   My experience is that multisensor example has already fulfil the low power requirement once the device has joined a Zigbee Mesh.  The issue is the process of Joining.

I understand that bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING) will perform beacon request and wait for response.  Based on my observation this process will complete when the device joined or it failed to join any mesh with some timeout (approximately around 5 to 10 seconds).  In the case it failed,  the interval that you mentioned on suggestion #2 will be considered.

During bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING) time,  I suspect the device consume around 17mA.  The bdb_start_top_level_commissioning is in library.  I cannot learn about it.   Is there a way to control how long bdb_start_top_level_commissioning wait for response? 

or

Is there a way to optimize current consumption during the beacon request/waiting for beacon response? 

The #2 suggestion can help.  I can make a longer custom interval to retry the bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING).   This will allow the energy stored in my battery to recover until the next attempt of bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING).  It is not an issue on a device that just rebooting.

In a virgin device, having a long interval between the bdb steering could be impractical for joining a new device to a hub.  I uses Smartthings and Hubitat hub (think of it as Zigbee coordinator).  The joining of new virgin device is to issue permit join for 60 seconds.   If a virgin device unable to join on the first bdb steering,  a long interval to recover the storage energy for the next bdb steering attempt could be too late.  The permit joint condition may have expired.   Essentially,  a device may only have one chance of beacon request/response cycle during this paring process.

Yes,  a user can request the hub to permit a join request again.  It will be an inconvenient.   

In summary,  I do not have access to learn the bdb_start_top_level_commissioning(ZB_BDB_NETWORK_STEERING).  I understand the radio may need to be active during this cycle.  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?  We still need power for the radio.  However,  if the MCU is sleeping,  we can save some energy while waiting for a response.  Is there a way to control this period as well?  My observation is that it take somewhere about or more than 5 seconds.

Again, thanks for the help.  

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.