CC2652R: The current in the rejoining process of the device is large

Hi,

Can you confirm if the device has rejoined successfully?

Can you share a sniffer log which captures the join and rejoin process?

Thanks,
Toby

Hi Toby,

Since I power off the coordinator, the device has been performing network rejoin but failed to rejoin successfully.
The peak current during network scanning when the device is rejoining is significantly higher than the wireless data transmission when the device is connected normally.

panid_0x52AE_nwkAddr_0x368f.zip

nwkKey is 31:42:DF:98:BD:5E:4B:14:09:3A:77:50:15:D6:63:4C

Thanks,

Howjie

What is your SAMPLEAPP_END_DEVICE_REJOIN_DELAY defined? If you change it to 10000 (10 seconds), what's the graph of power consumption captured in energy trace?

Hi YiKai,

I use the OOB zed_sw_CC26X2R1_LAUNCHXL_tirtos_ccs project,and I made the following changes:
1. Disable CUI.
2. If the device is a new device, start a timer that periodically calls commissioning.

The default value of SAMPLEAPP_END_DEVICE_REJOIN_DELAY is 1000, which can be seen from the sniffer log file.
If i change it to 10000 (10 seconds), the graph of power consumption captured in energy trace is as follows:

Thank,

Howjie

This looks good to me and I suppose you can use longer rejoin interval to improve power consumption.

thanks you reply.

The abnormal operation of our device is caused by the high current in the "Event1" position.

We currently do not know what happened at that time.

What do you mean "Event1" position?

During the rejoining process of the device, there will be a considerable current consumption "Evnet1" every 45 seconds, it can be seen in the first two screenshots.

If you set SAMPLEAPP_END_DEVICE_REJOIN_DELAY to 60000 (60 seconds), do you still see this "Evnet1" every 45 seconds?

I changed SAMPLEAPP_END_DEVICE_REJOIN_DELAY to 10000 (10 seconds), "Event1" appeared once within 5 minutes.It doesn't seem to disappear.
If i set it to 60000 (60 seconds), the interval for "Event1" may be longer.

In addition, if the rejoing interval is too long, it may conflict with other policies on the device, such as the WWAHu rejoin algorithm.

I tried to use the EnergyTrace++ function to learn more, but the time axis of the [Current] and [States] options has not been synchronized.

The rejoin process itself involves some more processing than the wireless data transmission when the device is connected normally.
(Follow code path from bdb_ZedAttemptRecoverNwk).

This is likely what results in higher avg current while device is attempting rejoin.

I am seeing similar current profile for rejoins.
I agree with YK, testing with higher rejoin delays is the right way to go for lowering current consumption during rejoin process.

YK's suggestions are for the average power consumption method.

At present, we are concerned about the excessive peak current consumption at the "event1" position during the rejoin process.

If we want to stop or bypass this "event1", is it possible to do?

If there is more explanation about the appearance of this "event1", that would be great.

Until now, I still don't have idea about what causes your "event1" exactly. Can you elaborate what is the peak current you see now?

At present, I also don't know what happened to the device in the "Event1" position.
According to our test situation, "Event1" seems to be a periodic behavior, but the time the first "Event1" appears is not fixed.

The peak current of "Event1" is about 21mA.

Maybe try to compare energy trace power consumption graph and power mode graph together to see if it is caused by TX or LED blink.

The LED connections are all disconnected.
Energy Trace is difficult to capture TX behavior.

In addition, what does "RX Wait" mean in the figure?

"RX Wait" means "the time to wait for start of frame. You can try to refer to Radio Control State Machine in www.ti.com/.../cc2520.pdf