• State
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 107 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

CC2340R5: current consumption during a single advertising event

bob frankel
Expert 2405 points
Part Number: CC2340R5

Tool/software:

the image above depicts a single advertising event, with current/time captured using my joulescope j220 analyzer....

the executing program is the basic_ble example shipped with the latest SDK....

the only changes i made were to specify 5dB as Tx Power and to specify "Non-connectable and Non-scannable undirected" as my Advertising Type....

looking at the capture, i was surprised by the >500us of active CPU time occurring **after** the last packet transmission....

what is the BLE stack doing here, as this represents a considerable amount of current/time????

also, can you explain the small "ledge" at the event of each adv packet TX???

the total time (~200us per packet) is consistent with the payload size....

i just don't understand why the step-down in current consumption???

also, doesn't this look a bit high for 5dB???  i would have expected a flat-line at ~8ma....

i'll be benchmarking basic advertising against other stacks (and other MCUs), and just wanted to put the cc2340 in the best light possible :-)

  • 0
    TI__Genius 9275 points

    Hello Bob,

    Thanks for reaching out.

    I would suggest to take a look at this section of the User Guide: Optimizing Bluetooth Low Energy Power Consumption.

    1. What is happening at the last part of the advertisement event is that the  Bluetooth Low Energy protocol stack processes the received packets and sets up
      the sleep timer in preparation for the next event, and then goes to Standby.
    2. The extra power consumption ("ledge") at each channel adv is due to the CPU walking up. To modify this, please follow specifically step # 5 of the guide I previously shared.

    Hope this helps.

    David.

  • 0 in reply to David
    Expert 2405 points

    hi david,

    your suggestion 2) did help with the "ledge"....

    but regarding point 1), i've set my advertising type to "non-connectible, non-scannable"; otherwise, you'd see a short RX window (at ~5mA) after each packet TX.... i'm not sure what "received packets" are being processed (as none are even expected!!!)....

    based on other power profiles i've captured using your rfPacketTx example, the time to "clean-up" in the RCL driver and then setup a suspend timer is usually <100us....  i'm actually able to single-step through the RCL code, where i don't see anything close to the 0.6ms seen here....  presumably this overhead is occurring inside the BLE stack itself (where i don't have access to sources)???

    bob.

  • 0 in reply to bob frankel
    TI__Genius 9275 points

    Hello Bob,

    Glad to see that helped with the Tx extra power consumption. As you mention the overhead is most likely comming from the BLE stack, which is not used in propietary RF examples (such as rfPacketTx). May I ask what is the use case or power consumption expectation to understand better how to provide help?

    BR,

    David.

  • 0 in reply to David
    Expert 2405 points

    hi david,

    i sent you a friend request about two weeks ago....

    i would like to message you privately about my use-case....

    bob.

  • 0 in reply to bob frankel
    TI__Genius 9275 points

    Hello Bob,

    I think all the questions should be better forward through this channel, I am unaware about the private internal one.

    If there is confidential information you would like to discuss about, I would suggest to reach out to your Texas Instruments reference to that he can initiate a internal query. Let me know what else I can help you with here.

    BR,

    David.