CCS/CC1352R: Achieving low power consumption with code based on the sensor 2.4GHz example with TI 15.4 stack

Did you previously evaluate with the LAUNCHXL-CC1352R1 LaunchPad to observe current consumption with POWER_MEAS tests?  What SDK version are you using?  What changes have been made to the board files for your custom hardware?  At first glance this doesn't seem related to radio power, it's possible that you are draining current from initialized LED/UART pins.  http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_30_00_03/docs/ti154stack/html/ti154stack/example-applications.html 

Regards,
Ryan

Hi Ryan,

Thanks for your response.  I'm using SDK version 3.30.  I was able to enter a low-power state by closing the UART driver and the RF driver I was using to generate CW RF signal as well as shutting down the TI15.4 stack with the ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, false) call, and the current consumption went down to 0.8mA.  When I press the reset button on my board to reset the MCU, I get 0.5mA, so from this I conclude that my MCU is only drawing 300uA after I enable power savings.  Just wanted to confirm that I'm on the right track with shutting down the TI15.4 radio stack and maximizing the power savings on the radio by calling the above mentioned ApiMac_mlmeSetReqBool() function.  Or does the 15.4 stack have any other API functions for low-power states?

Thanks!

Michael

Hey Michael,

You're on the right track. During the commissioning, you should see the sensor wake and consume more power, but once this is done you should see rx off on idle, resulting in lower power consumption.

I belive RxOnWhenIdle is set to false by default in our examples which sets the sensor node to be a sleepy end device. You can verify this in the generate ti_154stack_config file and check that CONFIG_RX_ON_IDLE is set to false.

I don't believe there are any other api functions regarding low-power states, but I will confirm this and follow up soon.

Hi Ammar,

Thank you so much for your feed back!  In my application, I need to periodically send a CW signal with duration of about 200us every 100ms.  It looks like I can make my board go to 0.8mA current consumption when this process is not running, but when it is, I see about 4mA on average current consumption at a minimum as measured with an oscilloscope with a current probe and confirmed with a ammeter in true RMS averaging mode.  When the task wakes up to generate a CW signal, current consumption goes up to about 6mA (which doesn't seem to contribute much to the overall average current consumption since the duration of high current consumption is relatively short - about 2% of the total time).  What I'm mostly wondering about is why do 100ms periods between the signals take so much power relative to the idle power?

Again, if the periodic signal is not being generated, I'm seeing 0.8mA, but if I'm running the task generating a periodic signal, I see an average of 4mA that I cannot attribute to signal generation alone, and the current never goes below 4mA according to my oscilloscope.  I'm suspecting that TIRTOS knows that it needs to power up the HF crystal oscillator in less than 100ms and decides to just keep it running instead of switching to the slow RTC oscillator when going to sleep.  Could you confirm this could be the reason?  Is there a workaround to lower the power consumption in this case?

Thanks,

Michael

Hey michael,

some questions for you.

Can you share all of your network settings, such  as reporting, polling, and tracking intervals? Mode of operation?

Also, how are you generating this CW for 200us every 100ms?

Can you show me how you are measuring the power of this board?

Regards,

AB

Hi AB,

Here's the CW generation code, which starts executing when we receive a specific command over the radio by unblocking an RTOS task:

handle = RF_open();  // only executed if the driver has not been opened
RF_runCmd(); // Frequency synth command
RF_runCmd(); // Tx test command to generate a CW

This repeats 10 times, then we call ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, true) to enable TI15.4 stack for data communication for a few milliseconds until we receive a command to repeat the sequence above.  Once we receive the command, we call ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, false) to disable the TI15.4 stack and lower the power consumption and proceed with CW generation.

I've tried closing the RF driver after executing the second RF_runCmd() call, but that didn't result in additional power savings.

We're running with the following network settings:

ApiMac_init(tiMacTaskId, CONFIG_FH_ENABLE);  // Frequency hopping disabled
ApiMac_registerCallbacks(&Sensor_macCallbacks);  //  We're only registering data confirmation and data indication callbacks
ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, true);  // Rx on to wait for the command described above
ApiMac_mlmeSetReqUint8(ApiMac_attribute_phyTransmitPowerSigned, (uint8_t)CONFIG_TRANSMIT_POWER);  // Set output power to 0dBm
ApiMac_mlmeSetReqUint8(ApiMac_attribute_logicalChannel, chan);  // Set comm channel
ApiMac_mlmeSetReqUint16(ApiMac_attribute_panId, BROADCAST_PAN_ID);  // Set PAN ID

We put the task generating CW into standby by calling Task_sleep for about 100ms between CW transmissions, and we don't see the current going below 4mA.  We would expect to see 0.8mA or something close to it, just like when we normally call ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle, false) without doing CW or any additional code execution.  The current was measured with a multimeter and oscilloscope from our 3.3V regulator to the rest of our board that includes the MCU.

Thanks,

Michael