• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 56 subscribers
  • Views 1232 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/CC1310: Sensor scan behavior in Sensor/Collector Stack

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

Tool/software: Code Composer Studio

Hey guys,

I want to minimize the power consumption when the sensor is not connected to a network. (currently 2mA using the TIDA 00489 design)

I want the sensor to search every 15 mins for 3 times, if no network is found, I want to delete the NV memory. For the latter one I use Ssf_clearAllNVItems();

  • What settings do I have to change therefor?
  • Do you have an idea how to detect the 3 unsuccessful scans?
  • What does the function RX_ON_IDLE mean? Can I set it on false for power savings?
  • What is the difference between "active scan", "passive scan" and "orphan scan"?

Thanks for your help

Stefan

  • 0
    Guru 735455 points
    Do you build your own PCB based on TIDA 00489?According user guide, the reference design has Low Standby Current of 1.65 μA (PIR Sensor Remains Active in Standby). I suppose there are current leakages on your IO pins.
  • 0 in reply to YiKai Chen
    Genius 5680 points

    Hey Chen,

    we used the exact same design and send it to a manufacturer. I would suspect that it has something to do with the code.

    Maybe I should check the behavior of more of the modules and figure out if there are leakage currents. Any idea where to look exactly? Have you tried the Sensor/Collector stack code and measured the consumption with this module?

    kind regards

    Stefan

  • 0 in reply to Slev1n
    Guru 735455 points
    I suppose you have to refer to TIDA-00489_Board.c and TIDA-00489_Board.h to do porting to TI 15.4 Stack sensor example.
  • 0 in reply to YiKai Chen
    Genius 5680 points

    Well, porting itself is not the problem, this worked pretty good. All the basic functionality I want with the TIDA Board works with the Sensor/collector example fine after some minor changes. But I am wondering why the power consumption is so high when the sensor is not connected to a network. When it has found a host and connected itsself, the power drops to around 80µA, here the sensor is active all the time I guess and counting the movements. When it is passing the data to the collector the current increases of course. Since the measurement equipment was not the best choice for this purpose, I will make these consumptions measurements again, but I want to see, if my proposed improvements can lower the consumption. Thus I need some help to get them working. And I would be pleased if others could share their consumption to have a better comparability.

  • 0
    TI__Genius 12415 points
    Hi,
    are you using beacon, non-beacon or frequency hopping mode?

    When you say that the sensor is not connected to a network are you referring to the sensor being "factory new" and has never attached to a network or a sensor that somehow has lost connection to the network and it is trying to join it again?

    - If you want to configure how often the device scans when it is "factory new"(never joined any network before) you can modify the value of "CONFIG_SCAN_BACKOFF_INTERVAL". If you want to modify how often the sensor scans to try to find the network that it was paired with then you have to modify the value of "CONFIG_ORPHAN_BACKOFF_INTERVAL"(by default this value is set to 5 minutes)

    - You can check for failed scans in "scanCnfCb" in the file jdllc.c, you can add a counter there to check how many times an scan failed

    - CONFIG_RX_ON_IDLE should be set to false if you want to save power. What this means is that your sensor device will be configured as a sleepy device. If you set CONFIG_RX_ON_IDLE to true then the device will never turn of the receiver off and will consume more power

    - Active scan: is used in non-beacon mode by both collector and sensor to to start and join a network respectively. Active Scans consist of sending a beacon request in a channel and then listening for incoming beacons to see if any of those networks is the one that we want to join. Active scans are also used in beacon mode by the collector only to start a network
    Passive scan: this is used in beacon enabled mode by the sensor. passive scans open the receiver and listen for incoming beacons until the desired beacon is found and the sensor synchronizes and joins the network
    Orphan scan: used by the sensor when they loose connection with the collector. this scans are used to find the network that the sensor was paired with previously
  • 0 in reply to Hector_r
    Genius 5680 points

    Hey,

    thank you for the elaborate answer.

    I am not sure what mode I use, I checked the "collector -> config.h" file. I guess it is "non-beacon" mode because "config_fh_enable" = false and CONFIG_MAC_BEACON_ORDER = 15. And I found in the sensor settings, that CONFIG_RX_ON_IDLE = false. Well, that seems to be pretty low power consuming, or is the "beacon" mode less power consuming?

    Thank you a lot for the explanation regarding: CONFIG_ORPHAN_BACKOFF_INTERVAL and CONFIG_SCAN_BACKOFF_INTERVAL (interestingly, both are set to 5s in sensor-> config.h) as well as pointing out the "scanCnfCb". Is there a more elaborate explanation of the different things being set in the config.h files and the functions used? Because sometimes the comments are enough, but often I do not exactly know what is meant.

    Regarding the state the sensor was in, I think it wasn't an orphan when I measured the 2mA but I can't remember exactly though. Hence, I will try to make more accurate measurements with detailed comments and different scenarios. The 2mA would be a big issue, because we would insert the battery, before sending our final device to the customer and this can take some time and then the battery is already empty before it reaches the destination. Another problem is the fact, that if it connects to any network before reaching the final destination, it would not connect to the final network, thus if it doesnt find its previous network, I will reset it to factory new after some time, allowing it to connect to a new one.

    Since I am most likely in "non-beacon" mode, I am using the active or orphan scans...ok.

    I will now try to make more precise current consumption measurements using high precision resistor, ultra low noise voltage amplifier and a daq-device and will report back.

    kind regards

    Stefan

  • 0 in reply to Slev1n
    Genius 5680 points

    Hey guys,

    I do now have access to a pretty good source meter, allowing me to check the idle current. Currently, I cannot log the peaks, but maybe I have the time in the future to write a software logging data from the device.

    However,

    • Connected - idle: it consumes around 73µA
    • Connected - ???: it increases to around 100-250µA shortly without a pattern, not sure what it is doing here.
    • Orphan: Drawing 2.22mA at the beginning and then switching to the 73µA
    • Orphan: Scanning (2s) 7mA, I can see the scan peak and since it has a 2s duration, it stays on the 7mA shortly.
    • Factory new: Now it has the same behavior as orphan. First 2.22mA, than 73µA.

    In all three states, I see quick rises to 100-250µA (3-5 times per 10s) but most of the time it stays at 73µA.

    I reduced the transmit power of the sensor and changed the intervals for reporting, config, polling etc. and changed the scan duration to 2s. Although I can not measure the peaks quantitatively correct I can detect them qualitatively, demonstrating, that the number of peaks per time interval decreased massively, like expected.

    So, changing the intervals and lowering the scan time as well as the transmit power are working. However, 73µA idle and the 100-250µA fluctuations are not acceptable for our application. When I flash the TIDA Firmware (with my minor changes) I have 7µA consumption still higher than 2.65µA but much more acceptable.

    Further questions:

    1. Can switching off security save current also for idle or only for send periods?
    2. POWER_MEAS option, is this an option for me and how does it work?
    3. Where is the high idle current and the 100-250µA coming from? Any idea? After initialization, my PIR sensor only triggers a HwI where a variable is incremented and then resumes to the general program flow. This should not cause such a high current.

    If you tell me, that with this code example, a single digit µA is not possible during idle, I will try implementing the TIDA-01476

    Kind regards

    Stefan

  • 0 in reply to Slev1n
    Genius 5680 points

    UPDATE: I just noticed, that in feature.h the mode is set to: #define FEATURE_ALL_MODES

    So I guess, all modes are basically allowed but due to other settings, only "non-beacon" is used?! Or how can I interpret "Feature all modes"?

    UPDATE 7th November:


    Flashing the TIDA board with the TIDA 00849 Firmware and changing the code to count movements (thus it is always active) gives me an idle-current of approx. 10µA. Hence, it has something to do with the code, not any hardware current leakage or whatsoever. The TIDA-01476 advertises a low current consumption while active like the TIDA-00489 at around 2.65µA. I changed the TIDA-01476 firmware from movement detection to movement counting and I kept the collector code as before. I still have 73µA idle current and I dont think it is because the sensor is always active.

    I am at a lost right here, any assumptions and suggestions are more than welcome.

    Kind regards

    Stefan

  • 0 in reply to Slev1n
    TI__Genius 12415 points
    If you want to learn more about the different configurations I encourage you to take a look at the documentation provided in the SDK. here is a link to the configuration documentation dev.ti.com/.../example-applications.html

    Turning security off will not reduce your idle current just your tx power and I don't think it will do much of a difference.
    From your description it looks like you are in non-beacon mode(I suggest reading the documentation which should clarify all different modes)

    For this case I recommend testing everything in parts, usually the best approach is to have a board with no sensors or other components other than just the CC1310, the scential components for it to startup and the antena. Load your firmware on that and test the power consumption. You should also be able to do this with a CC1310 launchpad if you remove or make sure to turn off the external flash, you can define "POWER_MEAS" in the default examples and this should take care of shutting down the external flash.
  • 0 in reply to Hector_r
    Genius 5680 points
    Thank you for the link. I will study this page closely and come back if I still have issues understanding the code.

    Regarding the testing. I currently have a lot of TIDA 00489 boards and a few Launchpads, thus I will proceed with the Launchpads. I will play a little bit with the "POWER_MEAS" and see what I can do. Since it is definitely possible to lower the current as can be seen by my TIDA 00489 Firmware I suspect that there is something wrong with the power mode settings during idle.
  • 0 in reply to Slev1n
    Genius 5680 points
    Ok, so to close this topic. You can use the Sensor/Collector Project Zero example and get low current consumption. You just have to set POWER_MEAS active under the pre-defined symbols. I do now have 1-2µA with few fluctuations + sending current peaks.

    Also great is the fact, that if there is no network or collector around, it doesnt consume more current (except for the search periods). But watch out, if you misuse the "ReadTempSensor()" function to return your move value as I do uncomment the macro within this function, that if POWER_MEAS is enabled the function always returns 0 :)

    Thanks for your help so far.