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.

  • Resolved

CCS/TIDA-00489: Power reduction for TIDA-00489 using sensor/collector example

Genius 3205 points

Replies: 13

Views: 964

Part Number: TIDA-00489

Tool/software: Code Composer Studio

Hey guys,

I have tried the TIDA Firmware, but I need a star network code since I have around 50 sensors in a network. I adapted the code from the sensor/collector example, to make it work with the TIDA sensor. Today I made my first rough power consumption tests and I am not amused so far. However, I was using a FLUKE multimeter and this is not state of the art current measurement tool. I will use a shunt+SRF650 ultra low noise amplifier + DAQ card to log power consumption more precisely over a bigger time. The sensor data I send is the number of movements, every 10s as interval.

  1. Sensor is not connected to network: approx. 2mA
  2. Sensor is connected and "idling": 0,08mA
  3. Sensor has a "pre-send" burst: 1,2mA
  4. Sensor is sending: 3-9mA
  5. Sensor has a "post-send" burst: 1,2mA

I have a few ideas on my own:

  1. Increase send intervall
  2. Decrease tx transmit power
  3. Decrease payload (is this possible or clever? does the collector need all data send for the network?)

Do you have any further suggestions, or can you tell me what you're consumption approximately is?

kind regards

Slev1n

  • Expert 8475 points
    Stefan,

    I would recommend this reference design: TIDA-01476. It is the sensor-to-cloud version of TIDA-00489. To optimize the power, there are a number of tweaks that can be applied. For example, disable frequency hopping, increase polling interval, and decrease transmit power. If you would like to reduce the payload, you can control it by configuring the configSettings.frameControl data structure. By using frameControl, you can set only the fields you want to send.

    As reference, you can find example code for TIDA-01476 here: git.ti.com/sub1ghz-sensor-to-cloud

    --Christina


    If your question has been answered, please click  Verify Answer .

     

  • In reply to clam:

    Thank you christina. I will have a look at the firmware, though I guess it is based on the sensor collector TI 15.4 Stack example: http://dev.ti.com/tirex/content/simplelink_academy_cc13x0sdk_1_13_01_05/modules/154-stack_01_sensor_collector/154-stack_01_sensor_collector.html

    Looking at the firmware control chart, I am pretty sure that except for the way I measure the number of movements, the rest is quite the same. I am also glad for your tweak hints. I will try them.

    But so far, I am really wondering, why my multimeter shows me 2mA consumption when it hasn't joined a network (doesn't matter if the sensor is orphan or has never joined a network before) and when it is connected, my sensor is always active counting the movements and sends the number of movements with a certain interval. During this active "idle" or "standby" time, it still consumes 70-80µA according to the multimeter, though I am not trusting the device here anymore...Could this have something to do with J3 being shorted I just noticed, that it is always shorted, though the PDF says it shouldnt. Is this a problem?

    kind regards

    Stefan

  • Expert 8475 points

    In reply to Slev1n:

    Stefan,

    I am assuming you are using the sensor/collector from the TI 15.4 stack. When the sensor is not connected to a collector, it will continuously scan for a network to join. Therefore, if you see higher current draw when the sensor is not part of a network, then this might be the reason why.

    J3 shorts a GPIO pin to VDD. In the original code, the firmware has an if statement checking the "Board_Mode" pin. If J3 is shorted (e.g., GPIO pin is high), don't run the code for debugging purposes. If J3 is not shorted (e.g., GPIO pin is low), do normal firmware operation. If you remove this snippet of code from your firmware, then J3 is a don't care. However, it would be best to determine how you are configuring this pin. If by default, this pin is internally pulled low and J3 is shorted (pulls the pin high), this will result in a higher current draw.

    --Christina


    If your question has been answered, please click  Verify Answer .

     

  • In reply to clam:

    Hmm, regarding J3, which is connected to IOID_3, looks like that in my code it is used for UART Tx:
    #define CC1350_LAUNCHXL_UART_TX IOID_3 /* TXD */

    I guess, I could take out all the UART functions, since I dont need them on the board.
  • In reply to Slev1n:

    So, I‘ve downloaded the git repository and took a closer look into the sensor code. As expected I am facing problems building the project. Note, that I’ve also downloaded the simplelink_cc13x0_sdk_1_30_00_06 software package.

    Before building, I made the following changes:

    1. I set TEMP_SENSOR to MOTION_SENSOR under the predefined symbol section.
    2. I configured the CC1310F128.ccxml target configuration

    I checked the general properties:

    • SimpleLink CC13x0 SDK 1.30.0.06 is checked
    • XDCtools: 3.50.1.12_core is used
    • Compiler version is TI v18.1.2.LTS

    I used „build project“ and „build all“ and I also tried the „original v0-version“ without any changes. Both do have errors, though different.

    EDIT: By adopting the code to my own desires, the errors vanished, though I have no idea why.

    Errors for „build project“

    • #10010 null: errors encountered during linking; "TIDA01478_sensor_cc1310lp_v1.out" not built   TIDA01478_sensor_cc1310lp_v1
    • 10234-D null: unresolved symbols remain   TIDA01478_sensor_cc1310lp_v1            
    • gmake: *** [all] Error 2   TIDA01478_sensor_cc1310lp_v1
    • gmake[1]: *** [TIDA01478_sensor_cc1310lp_v1.out] Error 1   TIDA01478_sensor_cc1310lp_v1
    • unresolved symbol Board_Pir_initialize, first referenced in <whole-program>   TIDA01478_sensor_cc1310lp_v1

    Warning

    This project was created using a version of compiler that is not currently installed - 16.9.2.LTS [ARM]. Another version of the compiler will be used during build - 18.1.2.LTS.

    Questions:

    1. Any idea what else I have to change, to be able to build it?
    2. Should I make another thread for this issue?
    3. I looked into the board.h file noticing the following:
    #if defined(CC13XX_LAUNCHXL)
    
    /* CC1350 board file will be used for both CC1310 and CC1350 */
    
    #include "boards/CC1350_LAUNCHXL/Board.h"
    
    #elif defined (TIDA00758) || defined(TIDA00488)
    
    #include "LaunchPad/TIDA00488_TIDA00758_Board.h"
    
    #elif defined(TIDA00489)
    
    #include "LaunchPad/TIDA-00489_Board.h"
    
    #else...

    Should I add „TIDA00489“ to the predefined symbols?

  • Expert 8475 points

    In reply to Slev1n:

    Stefan,

    There are pre-built configurations in the project to set the correct project settings.

    After you import the project, right click and go to "Properties". Click on "Build". On the top, you should see configuration section. On the right of the drop down, click on the "Manage configurations..." button. Highlight TIDA-00489 and click the "Set Active" button. Click "OK" and then "Apply and Close" to close the properties window.

    Afterwards, you should see it mention TIDA-00489 in the project explorer (e.g., sensor_cc1310lp [Active - TIDA-00489]). Clean the project and rebuild. The project should build without any errors.

    --Christina


    If your question has been answered, please click  Verify Answer .

     

  • In reply to clam:

    Hey, I didn't know that option, thank you! It indeed builds without errors afterwards, only 2 warnings regarding declared but never referenced and set but never used functions.

    Regarding the current consumption:
    When I was trying the new TIDA 001476 firmware for the sensor (I used the old for the collector) I measured again, around 70µA in idle.
    When I flashed the original TIDA 00489 firmware and only changed the code from detecting a movement to counting the movements for a certain time and then just send the package via the "sendpacket(XX)" function I could see the 1-3µA in idle though with many fluctuations to 0.8µA and up to 30µA so in average I would say 10µA.

    I still don't understand the discrepancy between the 70µA and 10µA in idle, could you tell me further actions to get the idle current down, because with 70µA + transmit peaks, the sensor won't last longer than 2 months, and we need a few years. At least this test demonstrates, that there is no hardware issue like current leakage.

    Advises are appreciated.

    And of course, thank you for your help so far!

    kind regards
    Stefan
  • Expert 8475 points

    In reply to Slev1n:

    Stefan,

    Can you also try testing with the collector from git repository? When the sensor starts, it sets its own default polling, transmit power, and other configurations. After the sensor connects to the collector, the collector will modify the sensor configurations to its own network requirements.

    --Christina


    If your question has been answered, please click  Verify Answer .

     

  • In reply to clam:

    Hey Christina,

    here an update from my side:

    The collector firmware from the TIDA 01476 works so far and if I combine it with the sensor firmware and choose "sensor_cl1310lp" it works fine. Changing it to TIDA 00489 is also possible and the current consumption is in the single digit µA region which is acceptable.

    But when I re-write the code so that it is not sending if a movement was detected or the timer expired the collector does not receive the messages. Debugging, I can see, that the "readSensor();" function is executed three times and afterwards it stops trying and idles. The collector shows me, that the sensor joined and then waits for some time and then says: !Responding: 0x1.

    The default config time is actually set to 100ms but the collector seems not to be able to config the device.

    I had to make a few changes to get the sensor firmware trying to send. E.g. I enabled the readingTime in the Ssf_setReadingClock(), adapted the Board_pir.c and changed the MotionSensor-Msg.

    • Do you have any idea why the collector is not receiving the messages and cannot configure the device?(the polling and reporting intervall are set to 5s and 6s.) Solution: -> SMSGS_SENSOR_MOTION_LEN has to be 2 instead of 1!
    • And why are the code blocks inside #ifdef FEATURE_MAC_SECURITY greyed out though in feature.h it is defined?
    • And why is it consuming 7mA if there is no collector after startup (factory set)? Scan duration is 2s and the backoff and orphan scan intervals are set to 10s each?!

    kind regards

    Stefan

  • Expert 8475 points

    In reply to Slev1n:

    Stefan,

    Just to confirm, the sensor and collector work when the TIDA-01476 code is unmodified.

    Were you able to get it to work with the modification? If you change the motionsensorfield packet, then you'll also need to update SMSGS_SENSOR_MOTION_LEN. Both these changes will also need to be done on the collector side, or else the collector will not know how to decipher the packet that was sent by the sensor.

    For the scan and orphan backoff, what value did you use? The value is the duration in millseconds. By default in config.h, the scan backoff is 5 seconds (5,000) and orphan backoff is 300 seconds (300,000). It looks like the duration you mentioned are much more frequent, which could lead to the higher consumption.

    --Christina


    If your question has been answered, please click  Verify Answer .

     

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.