This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: Saving Power from MSP430 ZAP

Part Number: CC2530
Other Parts Discussed in Thread: Z-STACK, MSP430F5529

Hi team,

My customer need assistance.

System description:
Using TI MSP430F5529 and CC2530, where the Z-Stack is 2.5.1a. The end device application runs on the MSP430 device. When the application is up and running and sending data to the coordinator via the CC2530 the end device consumes about 160 uA most of the time. ZNP message is sent to the CC2530 device every 100 seconds.

Problem description:
The battery operated Zigbee end device loses connection to the parent or does not find a parent device (Router or Coordinator) for different reasons; and the end device can suffer undesirable excessive current drain on the battery for long period of time. I have recorded current consumption of about 54 mA while the CC2530 has lost or can’t find the parent device. When this condition occurs the battery will drain rapidly to a point the end device does not have enough power to operate the CC2530 radio circuitry.

I am looking for a way to reduce the current consumption to 100 uA for long period of time (determined by MSP430 firmware algorithm) and then try to initialize the CC2530 after a period of time (say 4 minutes). Meanwhile the application running on the MSP430 continues to run while the CC2530 taken offline.

Solution 1:
My initial attempt to reduce current consumption of the end device when the Zigbee parent is not found is to assert hard reset to the CC2530. When this solution is tried, I see the current consumption is about 8 mA.

I am seeking a better solution where I can reduce the current consumption from 8 mA to 100 to 200 uA when the CC2530 is taken offline. Is there a set of ZNP commands the MSP430 firmware can send to the CC2530 to reduce current consumption further?

Regards

  • Hi Chong,

    It is likely that the ZED will stay awake and constantly send Beacon Requests (to recover its network connection) while in the orphan state, thus quickly draining the battery.  The customer should implement a backoff timer from within the application which forces the device to sleep for a given amount of time before attempting to reconnect again.  Behavior will continue even after a hard reset since the ZED retains its network information from the NV memory.  If the customer desires for the ZED to forget its previous network and re-start the joining process then a factory reset should be performed.  Here is some relevant information from E2E threads.

    Support of Z-Stack is 2.5.1a will be limited since this software solution is deprecated and has been removed from TI.com for over a decade.  If possible, the customer should consider migrating to newer software solutions.

    Regards,
    Ryan