CC2652R: current consumption of the RF part

Hi Pits,

It could you provide some commented power traces, it would help us to understand the case?

Best regards,

Hi Clément,

i'm talking about the period between the two markers.

Best Regards,

pits

Hello pits,

pits said:

(the communication is not a standard Bluetooth communication)

Can you please further describe this?  What SIMPLELINK-CC13X2-26X2-SDK example are you working from? What are the send/receive operations captured?  As core MCU current consumption on the CC2652R is 3.4 mA in active mode it would seem that the device is processing the received information before transmitting.

Regards,
Ryan

Hello Ryan,

I'm using the SimpleLink CC13x2 26x2 3.40.00.02 SDK on a CC2652R1 and started from the rfPacketTx/Rx examples. We supply the CPU with 2.5V.

In the area between the markers is no processing necessary and the main CPU is sleeping, only the RF part is active but is not transmitting or receiving. I suspect that keeping the RF frontend ready (RF oscillator is running) will consume some power, but there is no info in the datasheet on how much. The timespan between the two markers depends on our radio system and we would like to know, if this current consumption is normal or if it can be reduced. We could power down the frontend in this timespan, but then we have to start it again and wait for RF oscillator to settle. In some cases this might be a problem in our radio system. 

For reference the right end of the graphic shows the current consumption after RF_yield, which is close to zero for the CC2652R1 (there is some other current consumption, which is constant over time and amount to 200uA). 

Regards,

  pits

You may consider evaluating with the newest v4.30 SDK and see whether the behavior changes.  Otherwise there is definitely something keeping the MCU active instead of going into an idle/standby mode.  Given the 44 ms delta this could involve switching from RX to TX, are you chaining commands and would you be able to provide a code excerpt showing how you accomplish this?  You could reference the Debugging section of the Proprietary RF User's Guide to utilize the ROV for the purposes of evaluating your task states, or use RFlib/ti.sysbios.knl.Clock timers to evaluate how long operations take to complete.  You might also find SWRA478 (measuring current consumption App Report) to have some useful information.

Regards,
Ryan

I'll try it and check the behavior with the new SDK.

I do not chain the commands, I use the RF_flush command right before the 44ms delta begin (so no new commands are pending) and at the end of the delta I send the TX command (short before the first peak in the right part in the graphic). I also tried putting the RF frontend into the sleep mode at the begin of the delta with RF_yield. In this case, the current consumption decrease to the same amount of current consumption as displayed in the most right part of the graphic. If I put the RF frontend in this 44ms down, there might be some problems with our radio system. I also do not find any information about the current consumption of the RF frontend while all operations are completed and the RF frontend is waiting for new commands. 

Regards,

  pits

I changed the SDK to the newest one, but the behavior did not change.

I think the RF core needs this amount of power, until I send it into the sleep mode. May I'm right?

Is there a way to reduce the power, instead of using RF_yield?

Regards,

  pits 

Thank you for your help and the information!

Regards,
   pits