• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 54 subscribers
  • Views 434 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

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

Slev1n
Genius 5680 points
Part Number: LAUNCHXL-CC1310
Other Parts Discussed in Thread: TIDA-00489

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

  • 0
    TI__Mastermind 20015 points

    Hello Slev1n,

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

    Regards,

    AB

  • 0 in reply to AB
    Genius 5680 points

    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?

  • 0 in reply to Slev1n
    TI__Mastermind 20015 points

    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.

  • 0 in reply to AB
    Genius 5680 points

    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

  • 0 in reply to Slev1n
    TI__Mastermind 20015 points

    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.

  • 0 in reply to AB
    Genius 5680 points

    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

  • 0 in reply to Slev1n
    Genius 5680 points

    Any further comment on that statement?