• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 52 subscribers
  • Views 552 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.

CC2652P: Changing BLE tx power has no effect

yingtao jia
Expert 1280 points
Part Number: CC2652P
Other Parts Discussed in Thread: ENERGYTRACE

Hi, I use CC2652P, simplelink_cc13x2_26x2_sdk_4_40_04_04, CCS10.2.

My application is based on dmm example as below

In my application, I need to tx BLE extended Adv data using AUX_ADV_IND PDU, and now extended adv data works well.

I can use CC1352P-2 LaunchPad as a sniffer in Smart RF Studio and I can see aux adv data in Smart RF Studio.

And I can also use HCI_LE_SetHostChanClassificationCmd to set channels on aux_adv_ind PDUs.

Then , I want to change tx power on AUX_ADV_IND PDU, and to see RSSI on Smart RF Studio.

I use HCI_EXT_SetTxPowerCmd() with these values

My device is very colse to LaunchPad.

But whatever tx power I set, RSSI on Smart RF Stuidio is always about -30dBm.

Only I take my device away from LauchPad can RSSI drop to -40, -50, -60 dBm.

So I want to ask, maybe using HCI_EXT_SetTxPowerCmd to set aux_adv_ind PDU is incorrect?

How to make it right?

Thanks.

  • 0
    TI__Guru** 101450 points

    Hi,

    I would recommend to first run some tests without DMM - to do so you may want to leverage simple_peripheral example.

    In addition, makes sure the Tx Power is modified before the advertising set is enabled.

    If needed, I will ask a concerned engineer to help.

    Regards,

  • 0
    TI__Mastermind 39160 points

    Hello,

    I completely agree with Clement. I believe implementing a procedure for changing the TX power in simple_peripheral and then transferring that procedure over to the desired project may be the easiest way to go about this. I recommend calling the HCI_EXT_SetTxPowerCmd() function in the SimplePeripheral_processGapMessage() function within the GAP_DEVICE_INIT_DONE_EVENT before the GapAdv_create() function call as shown below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    ...
    BLE_LOG_INT_TIME(0, BLE_LOG_MODULE_APP, "APP : ---- got GAP_DEVICE_INIT_DONE_EVENT", 0);
    // Setup and start Advertising
    // For more information, see the GAP section in the User's Guide:
    // http://software-dl.ti.com/lprf/ble5stack-latest/
    // Set a different TX Power [ADDED]
    HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_5_DBM);
    BLE_LOG_INT_INT(0, BLE_LOG_MODULE_APP, "APP : ---- call GapAdv_create set=%d,%d\n", 0, 0);
    // Create Advertisement set #1 and assign handle
    status = GapAdv_create(&SimplePeripheral_advCallback, &advParams1,
    &advHandleLegacy);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    ...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    After making these modifications, I used EnergyTrace to quickly verify a change in current consumption. This change can be used to indicate a change in transmit power. However, dedicated testing equipment to verify the change would be ideal. Below you can see the current consumption reported by EnergyTrace before the modification:

    Below you can see what EnegryTrace reported after making the modification:

    Can you implement these changes and verify if you are able to see the desired behavior?

    Regards,

    Jan

  • 0 in reply to Jan
    Expert 1280 points

    Thanks to you.

    I have tested what you recommend mo to do.

    In simple_peripheral example, I delete legacy adv and keep only one extended adv set.

    Again, I use one CC2652P-2 LaunchPad to tx AUX_ADV_IND PDU, use another CC2652P-2 LaunchPad as a sniffer to observe RSSI.

    In the example, I use HCI_EXT_SetTxPowerCmd before GapAdv_create as recommended, when I change different power value in API, and flash the program into the tx LaunchPad, then, I can observe different RSSI on another LaunchPad. This makes sense.

    But this only shows fixed power in program running. I need to test dynamic tx power in program runtime.

    So I test more. And I find, when I use GapAdv_disable to disable adv set, then change tx power, then use GapAdv_enable to enable adv set, RSSI has no change.

    When I use GapAdv_destroy to destroy adv set, then change tx power, then use GapAdv_create to create adv set again, RSSI changes.

    So my test shows that changing tx power of AUX_ADV_IND PDU can only take effect after adv set is destroyed rather than disabled.

    So, in program runtime, if tx power of AUX_ADV_IND PDU need to be changed, adv set must be destroyed first, then, change tx power, finally, create adv set again.

    Is this correct?

    Thanks.

  • 0 in reply to yingtao jia
    TI__Mastermind 39160 points

    Hello,

    I was able to reproduce the behavior you have described. I did so by modifying the key press code to alter the TX power. I modified the code such that when the left button is pressed the HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_5_DBM); function call is made. If the right button is pressed then the HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_MINUS_20_DBM); function call is made.  I made two versions of the SimplePeripheral_handleKeys() function. The first one disables the advertisements, changes the tx value and then re-enables the advertisements. This version is shown below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static void SimplePeripheral_handleKeys(uint8_t keys)
    {
    bStatus_t status = FAILURE;
    if (keys & KEY_LEFT)
    {
    // Check if the key is still pressed. Workaround for possible bouncing.
    if (PIN_getInputValue(CONFIG_PIN_BTN1) == 0)
    {
    status = GapAdv_disable(advHandleLegacy);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    status = GapAdv_disable(advHandleLongRange);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_5_DBM);
    status = GapAdv_enable(advHandleLegacy, GAP_ADV_ENABLE_OPTIONS_USE_MAX , 0);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    status = GapAdv_enable(advHandleLongRange, GAP_ADV_ENABLE_OPTIONS_USE_MAX , 0);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The second version of the function would destroy the advertising sets and then recreate them. This version is shown below:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    static void SimplePeripheral_handleKeys(uint8_t keys)
    {
    bStatus_t status = FAILURE;
    if (keys & KEY_LEFT)
    {
    // Check if the key is still pressed. Workaround for possible bouncing.
    if (PIN_getInputValue(CONFIG_PIN_BTN1) == 0)
    {
    status = GapAdv_destroy(advHandleLegacy);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    status = GapAdv_destroy(advHandleLongRange);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_5_DBM);
    status = GapAdv_create(&SimplePeripheral_advCallback, &advParams1,
    &advHandleLegacy);
    SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
    status = GapAdv_create(&SimplePeripheral_advCallback, &advParams2,
    &advHandleLongRange);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    By setting up simple_central on a second LaunchPad and connecting to the modified simple_peripheral. I was able to observe that only the second version of the handleKeys function would cause a change in RSSI. I am not sure if this behavior is intended, so I will file an internal ticket and let the team know. I am glad to hear you were able to find a working workaround and that you provided this workaround to the community. 

    Regards.

    Jan

  • 0 in reply to Jan
    Expert 1280 points

    Thanks. Looking forward to your reply.

  • 0 in reply to yingtao jia
    TI__Mastermind 39160 points

    Hello,

    I have filed an internal ticket and the team will look into this as soon as they can.

    Regards,

    Jan

  • 0 in reply to Jan
    Expert 1280 points

    Is there any new progress? Thank you.

  • +1 in reply to yingtao jia
    TI__Mastermind 39160 points

    Hello,

    The issue has been accepted and the team will work on fixing this behavior for a future release. I have not received an update beside that. In the meantime, I believe the workaround you provided should work. 

    Regards,

    Jan