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.

CC2652R7: EnergyTrace and Radio ON/OFF control

Part Number: CC2652R7
Other Parts Discussed in Thread: ENERGYTRACE

Good day,

I am using the CC2652R7 launchpad, and I have a function defined below called "configureSED()" that sets the data poll period for a sleepy end device to every 10 seconds.

I then utilized the EnergyTrace in CCS, and below is a screenshot of data captured for a duration of 60 seconds.
Now the radio turns ON around 14 seconds, then at 24 seconds and so on....

Now in between the switching ON of the radio, there is a constant current consumption spike of around 4.6mA.

Questions:
1. I read that it still requires a power analyzer to get an accurate current consumption reading. Is this current consumption between these intervals in relation to the Energy Trace circuitry onboard or possibly the MCU running a task such as the Radio that could be consuming this amount of current.

2. During these intervals I am able to send COAP messages to the COAP server.
How is that possible? Should the radio not be OFF? And are there flags I read to see when the radio is OFF or ON.

3. How do I determine how long the radio can be ON for? I am a bit unclear on that matter.

// Sleepy End Device Setup
void configureSED(uint32_t aPollPeriod)
{
    otError error;

    otLinkModeConfig LinkMode;
    LinkMode.mDeviceType    = 0;    // MTD
    LinkMode.mNetworkData   = 1;    // Network Data
    LinkMode.mRxOnWhenIdle  = 0;    // SED

    error = otThreadSetLinkMode(OtInstance_get(), LinkMode);
    if(error != OT_ERROR_NONE)
    {
        // Error Handle
    }

    error = otLinkSetPollPeriod(OtInstance_get(), aPollPeriod);
    if(error != OT_ERROR_NONE)
    {
        // Error Handle: Invalid poll period
    }
}

  • Hi,

    Now in between the switching ON of the radio, there is a constant current consumption spike of around 4.6mA.
    1. I read that it still requires a power analyzer to get an accurate current consumption reading. Is this current consumption between these intervals in relation to the Energy Trace circuitry onboard or possibly the MCU running a task such as the Radio that could be consuming this amount of current.

    These are likely the pulses from the on-chip DCDC, which is expected behavior.
    More details can be found here, for a device using similar DCDC: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/601988/cc1310-short-bursts-of-current-consumption-in-standby-mode

    The steady current you see (between 1.1 and 1.7 mA) is likely from the debugger side of the board.
    Can you try removing all jumpers except for the 3v3 and GND?
    Similar to what is shown here: https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_10_00_98/docs/thread/html/energy-trace/energy-trace.html#id15 

    2. During these intervals I am able to send COAP messages to the COAP server.
    How is that possible? Should the radio not be OFF? And are there flags I read to see when the radio is OFF or ON.

    When your application calls the function to send the COAP message, that function will initiate the right sequence of steps to setup the radio, then transmit the packet.

    To check state of radio in the context of Thread, you can check this variable/enum in the radio.c/h:

    /* state of the RF interface */
    static volatile platformRadio_phyState sState;
    typedef enum platformRadio_phyState
    {
        platformRadio_phyState_Disabled = 0,
        platformRadio_phyState_Sleep,
        platformRadio_phyState_Receive,
        platformRadio_phyState_EdScan,
        platformRadio_phyState_Transmit,
    } platformRadio_phyState;

    3. How do I determine how long the radio can be ON for? I am a bit unclear on that matter.

    The radio can be ON for as long as its "controller" decides. In this case, the controller is the OpenThread stack (i.e. the application should never have to interface with the radio directly -- it will always call the right API (such as for sending COAP messages).

    For a SED, usually low power is desired, so the OpenThread stack would keep radio ON time to a minimum.

    Thanks,
    Toby