CCS/LPSTK-CC1352R: Large standby current consumption (1.7 mA) with LPSTK-CC1352R as sensor

Hey Mario,

My initial tests showed the current at a lower power consumption. How are you measuring the current?

Have you defined the Test Mode in SysConfig under TI 15.4 Stack > Test Mode > Power Test Mode?

Additionally, which SDK are you using?

Hello Ammar,

Thanks for the quick response. To measure the current consumption, I am simply using an ammeter connected in series to an external power supply. As power supply is connected to AAA terminals, we left the corresponding jumper fitted in LPSTK board. I know it is not the best approach to measure very low currents or transmission peaks, not as good as DC power analyzer for instance but, anyway, it provides us an undesirably large current value in standby.

Regarding Test Mode -> Power Test Mode in SysConfig, when making use of "Data and ACK" Power Test Profile the measurement also shows a value around 1 mA. If we set the Power Test Profile to "Sleep" then we obtain measurements of uA-nA as expected. For this reason, we think the CC1352R MCU might not be entering to sleep state between transmissions, producing large current consumption. Maybe we need to implement a Wake on Radio mechanism or similar? We do not think so, as in your case @Ammar the current consumption showed to be lower.

I am using Simplelink_CC13x2_26x2 SDK.

Regards,

Mario

Just to provide you more information, this is the tutorial I followed step by step: http://dev.ti.com/tirex/explore/node?node=AIKcHFRMmg0MRAyz1RySsg__pTTHBmu__LATEST

Everything is working fine but the current consumption is larger than expected. 

Same observation on my side, although with a different SDK used for fast prototyping.

The same Low Power Home Network Weather Monitoring application on the CC1350 SensorTagand the CC1352 LPSTK shows very different power consumption levels measured with EnergyTrace when the node without screen is in idle mode.

Board	Idle mode (mA)
CC1352 LPSTK	1.864
CC1350 SensorTag	0.014

Configuration

• Energia with EasyLink and Galaxia libraries
• EnergyTrace with USB XDS110 probe

I posted the issue at Higher than expected power consumption in idle mode #13

The LPSTK-CC1352R, has I2C sensors, SPI External Flash and UART open. So current consumption will be high even at standby mode. The example program has lots of codes to power down the I2C sensors, but I found out that all those are useless. 

Hi again,

Thank your for your answers. Referring to Markel Robregado response, I understand the LPSTK-CC1352R board may have larger current consumption when performing reading from sensors and using UART, however note that in my test I disabled those (I am not reading any data from any sensor and UART is disabled) and still current consumption is of mA order. By looking at the datasheets of the on-board sensors, the standby current consumptions are of 1.8 uA in the case of ambient light sensor (OPT3001), 100 nA for temp/humidity sensor (HDC2080), 1.6 uA for magnetic field (DRV5032) and 10 nA for accelerometer (ADXL362). From that, I cannot see how current consumption reaches mA when not transmitting. 

Moreover, Rei VILO user reports current consumption of uA for the case of CC1350 SensorTag, which by looking at its datasheet, has very similar features (it also has I2C sensors). 

I would appreciate any contribution to be able to lower the current consumption, as mA standby current consumption is too large for our target applications.

Thank you and regards,

Mario

Hi,

The solution to lower the power consumption for I2C sensors is to put the I2C sensors in sleep mode if its supported then close the I2C port. Same situation with the SPI External Flash. That is if you are not read/write the I2C sensors and SPI external flash. Lastly the UART should be closed if not used.

Also, at the example program, uses these pins to power on and power off the I2C sensors. When in fact those pins are not connected.

CONFIG_GPIO_OPT_PWR DIO29
CONFIG_GPIO_HDC_PWR DIO24
CONFIG_GPIO_DRV_PWR DIO26

With regards to I2C sensors the best way to really remove its current consumption even if it is in low power sleep mode is to put a mosfet switch circuitry that would enable/disable power to that I2C sensor.

-kel

Hi Markel,

Thanks for the quick response. I just reviewed your forum post referring to the CONFIG_GPIO_OPT_PWR issue (https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/t/886166?LPSTK-CC1352R-Sensors-Power-Enable-Pins-).  From that and reviewing the example code “dmm_154sensor_remote_display_oad_lpstk_app_CC1352R1_LAUNCHXL_tirtos_ccs” , I understand that there is no way of turning off the sensors as they are directly connected to VDD (lines similar to "GPIO_write(CONFIG_GPIO_OPT_PWR, 0);" are useless then?).

However, I am not sure that is the cause of the mA current consumption, as sensors have very low current consumption in sleep mode, reported by R.M user in your post.

I just tested a simpler project, rfWSNnode, performing only ADC reading and Tx (EasyLink) and I measured just 110 uA at standby. I would try to add LPSTK on-board sensors to measure current consumption and analyze if the mA power consumption is related with RF communication or sensors.

Regards,

Mario

The sensors are not put into sleep mode. 

-kel

Thanks again for your contributions. As you all say, sensors cannot be shut down due to hardware limitations. However, I tested “sensor_CC1352R” example with only the MCU integrated temperature sensor measurement in LPSTK-CC1352R and only measured around 2uA in standby. That means that, in some way, external sensors are in sleep for this example (but not shut down) as they do not contribute to current consumption. For our applications, setting sensors in sleep would be enough in terms of current consumption.

However, as previously stated, that is not the case for “dmm_154sensor_remote_display_oad_lpstk_app_CC1352R1_LAUNCHXL_tirtos_ccs”  example.

Currently, I am trying to add measurements of LPSTK external sensors to “sensor_CC1352R” example in order to check if it is possible to make them work in sleep and overcome the limitation of mA in standby. I will give any updates in this post as soon as I get results.

As this is a Evaluation Board, the current consumption is expected. So you just learn from that.  You can apply these leanings at your product design using LPSTK-CC1352R as reference.

-kel

However, I tested “sensor_CC1352R” example with only the MCU integrated temperature sensor measurement in LPSTK-CC1352R and only measured around 2uA in standby. 

Mario_7

The “sensor_CC1352R” example you are referring to, it is the Software > SimpleLink CC13x2 26x2 SDK (3.40.00.02) > Examples > Development Tools > CC1312R LaunchPad > TI 15.4-Stack > sensor > TI-RTOS > CCS Compiler > sensor project?

About the EasyLink library: maybe it doesn't handle idle mode correctly.

Hi Rei VILO,

In your path you wrote CC1312R LaunchPad, it is CC1352R LaunchPad instead. So the project I used is Software > SimpleLink CC13x2 26x2 SDK (3.40.00.02) > Examples > Development Tools > CC1352R LaunchPad > TI 15.4-Stack > sensor > TI-RTOS > CCS Compiler > sensor , and I obtained 2 uA measurement in standby.

Regards,

Mario

Thank you for spotting the typo! I'm obtaining results closer to those expected with the CC1352 example.

So the questions now are:

• What is the part of the example that triggers the low power mode, so we could reuse it on another project?
• Does EasyLink manages power correctly against the CC1312R / CC1352R as it does it against the CC1310 / CC1350 ?  

Could we have some help and guidance from a TI expert please? Thank you!

As the initial question is solved, I've opened a separate dedicated thread about Large standby current for EasyLink library on LPSTK-CC1352R.

Hi Rei VILO,

The measurements of 0.0081 mA you mentioned are for "sensor_CC1352R "project with measurements from OPT3001 and HDC2080 sensors? I am still getting current consumption in the mA range. I have already disabled UART, but by means of _pParams -> manageUart = false at cui.c, is it enough or there is a need of modifying a different section of the code? I would appreciate if you could share more details on this.

Here are my recent observations: I was using "sensor_CC1352R" project with only MCU integrated temp sensor (TEMP_SENSOR at defines) and I measured 2 uA in standby. Now, I added LPSTK definition to the project (LPSTK at defines) and measurements are around 1 mA again. However, testing examples from SAIL SDK, for OPT3001 sensor ("SimpleLink Sensor and Actuator Plugin (1.50.00.00)/Examples/Development Tools/CC1352R LaunchPad/SAIL/i2copt3001") I was also in the uA. For this reason, I am trying now to add on my own OPT3001 and HDC2080 sensors to sensor_CC1352R project to see if I am able to reduce current consumption.

Regards,

Mario

The examples provided at SimpleLink Academy are actually too complex to dig into, as they mix too many parameters and features.

I'm using the Energia SDK as rapid prototyping tool with three libraries:

• the Galaxia library (repository, documentation) for RTOS, 
• an C++ encapsulation of the EasyLink for the sub-1 GHz radio, and
• a last library for the weather sensors, SensorsWeather_Library.

About the ports:

• The UART port isn't used at all. Neither is the SPI port.
• The I²C port is opened before and then closed after the data acquisition.

Every ten minutes, the LPSTK-CC1352R node

• performs three measures from the OPT3001 and HDC2080 sensors: light, temperature and humidity,
• sends the frame to the central hub,
• waits ca 66 ms for either an acknowledgement or the time (epoch),
• tries 3 more times if the message back is not received.

Now, idle mode keeps the RTC running, as each node uses epoch to date the frames. All sensors are in sleep mode when the ode is idle.

You can find more details of this project at Updated Low Power Home Network Weather Monitoring. It is actually an update of the Low Power Home Network Weather Monitoring project was initially developed for the CC1350. 

The results I've obtained are consistent with those expected and roughly double the battery life.

The battery life for the same CR2032 almost doubles, reaching 22 months compared to more than a year from the previous generation, according to the EnergyTrace estimate.

This could be explained by two main factors:

• Idle mode requires 0.0267 mW, almost half of the 0.0505 mW from the previous generation.
• ​Active part, including acquisition and communication, only takes 350 ms, much faster than the 607 ms from the previous generation.

Last tip: ensure that VCC and VDD only are connected.

Hi Rei VILO,

I will try this approach to see if I can get the same results. I will let you know when I test it.

Thank you so much for your help!