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.
Part Number: LAUNCHXL-CC1310
Tool/software: Code Composer Studio
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?
I would recommend you update the code supplied in TIDA-00489 to the latest SDK.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to 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?
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.
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?
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 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.
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.
Any further comment on that statement?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.