• TI Thinks Resolved

CCS/LAUNCHXL-CC1310: Frequency Hopping: High current consumption before joining

Genius 3410 points

Replies: 7

Views: 108

Part Number: LAUNCHXL-CC1310

Tool/software: Code Composer Studio

Hey guys,

maybe I got something wrong regarding the concept of FH. However, I just measured the current consumption of our sensor module (TIDA-00489) and if I use FH instead of non-beaon, the current consumption prior to joining fo the sensor is continuously 6.6mA which is pretty high. Timings (dwell, pan advertisement etc) are standard. We use ETSI LRM mode.

Is there any way to reduce the power consumption of the sensor before a network has been opened?

kind regards

Slev1n

  • Genius 15235 points

    Hello Slev1n,

    I would recommend you update the code supplied in TIDA-00489 to the latest SDK.

    Regards,

    AB

  • In reply to AB:

    Hey AB,

    thanks for the response. However, I was unclear about the firmware version. I am already using SDK 3.20. Is the consumption maybe that high, because the sensor is always listening to receive network information to get the information to join?

  • Genius 15235 points

    In reply to Slev1n:

    It seems like the device is always listening according to your numbers.

    This might be the issue, if your device is set up as a sleepy device this should not happend. Regardless that is the reason why, your current numbers say that.

  • In reply to AB:

    Yes, I think you are right. Hmm, I cant remember making any setting to indicate that the device is sleepy. I only activated the POWER_MEAS macro. Is there maybe anything else I overlooked?

    kind regards

    Slev1n

  • Genius 15235 points

    In reply to Slev1n:

    That is the only thing I can think of. Make sure the RX_ON_IDLE is set ot false.

    Or in syscnf make sure the SLEEPY END NODE is true.

  • In reply to AB:

    In config.h "CONFIG_RX_ON_IDLE" is set false. I did not find the "syscnf" or any "Sleepy end node" variable. Maybe you could give me a hint were to look.

    Besides, I went through the code looking for ApiMac_mlmeSetReqBool(ApiMac_attribute_RxOnWhenIdle,...)

    JDLLC_INT: I noted, that in jdllc_init RX is activated and only set to false if CONFIG_FH_ENABLE is false (which is obviously not the case).

    JDLLC_JOIN: Again, if CONFIG_FH_ENABLE is true, the RxOnWhenIdle attribute is set to true.

    JDLLC_REJOIN: As before, the attribute is set to true.

    scanCnfCb: Here, the attribute is set to false, however, only if not in FH mode.

    assocCnfCb: Here is the first time, that independent of the mode (beacon, non-beacon or FH) the attribute is set to false.

    So what I see from this, is the fact, that during jdllc_init RX is activated and only deactivated if a !successful! association occurs.

    from here

    The sequence to start the sleepy and non-sleepy devices is the same until they join a network. A sleepy device is configured to be sleepy by setting the MAC PIB (macRxOnWhenIdle) to zero only after it joins the network (see Network Join). In other words, the sleep mode operation uses low-power mode only for data exchange after successfully joining the network.

    Please feel free to correct me but to me it looks like this high consumption is due to the principle of FH.

    kind regards

    Slev1n

  • In reply to Slev1n:

    Any further comment on that statement?