CC2652P: Changing BLE tx power has no effect

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,

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:

        ...
        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);
        ...

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

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.

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:

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);

      Display_printf(dispHandle, SP_ROW_DEBUG, 0, "HCI_EXT_TX_POWER_5_DBM is set");
//      tbm_buttonLeft();
    }
  }
  else if (keys & KEY_RIGHT)
  {
    // Check if the key is still pressed. Workaround for possible bouncing.
    if (PIN_getInputValue(CONFIG_PIN_BTN2) == 0)
    {
      status = GapAdv_disable(advHandleLegacy);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
      status = GapAdv_disable(advHandleLongRange);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

      HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_MINUS_20_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);

      Display_printf(dispHandle, SP_ROW_DEBUG, 0, "HCI_EXT_TX_POWER_MINUS_20_DBM is set");
//      tbm_buttonRight();
    }
  }
}

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

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);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

      Display_printf(dispHandle, SP_ROW_DEBUG, 0, "HCI_EXT_TX_POWER_5_DBM is set");
//      tbm_buttonLeft();
    }
  }
  else if (keys & KEY_RIGHT)
  {
    // Check if the key is still pressed. Workaround for possible bouncing.
    if (PIN_getInputValue(CONFIG_PIN_BTN2) == 0)
    {
      status = GapAdv_destroy(advHandleLegacy);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
      status = GapAdv_destroy(advHandleLongRange);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

      HCI_EXT_SetTxPowerCmd(HCI_EXT_TX_POWER_MINUS_20_DBM);
      
      status = GapAdv_create(&SimplePeripheral_advCallback, &advParams1,
                             &advHandleLegacy);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);
      status = GapAdv_create(&SimplePeripheral_advCallback, &advParams2,
                             &advHandleLongRange);
      SIMPLEPERIPHERAL_ASSERT(status == SUCCESS);

      Display_printf(dispHandle, SP_ROW_DEBUG, 0, "HCI_EXT_TX_POWER_MINUS_20_DBM is set");
//      tbm_buttonRight();
    }
  }
}

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

Thanks. Looking forward to your reply.

Hello,

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

Regards,

Jan

Is there any new progress? Thank you.