This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Set "TX Power" of nRF52833, using Zephyr

As mentioned in this question: https://devzone.nordicsemi.com/f/nordic-q-a/69533/set-tx-power-on-zephyr-device , there is a sample to change the tx power using some HCI commands. But when "extended advertising" has enabled, the approach that has used in the above example doesn't work. For example it is not possible to change the tx power of this example: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/direction_finding_connectionless_tx/README.html

I found that on each system tick, the tx power is updated:

zephyr/subsys/bluetooth/controller/ll_sw/nordic/lll/lll_adv_aux.c

static int prepare_cb(struct lll_prepare_param *p)
{
...
#if defined(CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL)
	radio_tx_power_set(lll->tx_pwr_lvl);
#else
	radio_tx_power_set(RADIO_TXP_DEFAULT);
#endif /* CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL */
...
}

But I can't find any method to update the "lll->tx_pwr_lvl" variable outside of this function. Always it uses the default value that has been set by kconfig. Is there any way to update "TX Power" when extended adverting is enabled?

Top Replies

Marjeris Romero over 3 years ago in reply to Saleh +1 verified

Hi Saleh , I am sorry for the late reply. There is a PR posted some days ago that seems to fix this problem: https://github.com/zephyrproject-rtos/zephyr/pull/41133

0 Marjeris Romero over 3 years ago

Hi,

The DF samples hasn't got enabled CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL by default. Could you check if you are able to control the TX power via Kconfig?

But when "extended advertising" has enabled, the approach that has used in the above example doesn't work

From an implementation perspective you should be able to use HCI commands to set the TX power both for extended and periodic advertising if enabled. If its still isn't working, could you explain more in detail what have tried and what are you having problems with specifically?

Best regards,

Marjeris
Cancel
Vote Up 0 Vote Down

Cancel

0 Saleh over 3 years ago in reply to Marjeris Romero

Thanks for your reply!

I've made these changes to the "direction finding tx" example:

Appending configuration needed for dynamic tx.

prj.conf

....
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y

And appending these lines of code to the source of the project, it switches the tx power from +8 to -20 repeatedly every 60 seconds:

main.c

...
#include <bluetooth/hci_vs.h>
...
void main(void)
{
    ...
    printk("Started extended advertising as %s\n", addr_s);
    
    int8_t txp_get = 0;
	while (1)
	{
		/* set power to -20 dBm */
		printk("Set Tx power level to -20\n");
		set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
					0, -20);

		printk("Get Tx power level -> ");
		get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
					0, &txp_get);
		printk("TXP = %d\n", txp_get);

		k_sleep(K_SECONDS(60));

		/* set power to 8 dBm */
		printk("Set Tx power level to 8\n");
		set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
					0, 8);
		printk("Get Tx power level -> ");
		get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
					0, &txp_get);
		printk("TXP = %d\n", txp_get);

		k_sleep(K_SECONDS(60));

	}
}

And "set_tx_power" and "get_tx_power" are defined as (it has been copied from hci_pwr_ctrl sample):

static void set_tx_power(uint8_t handle_type, uint16_t handle, int8_t tx_pwr_lvl)
{
	struct bt_hci_cp_vs_write_tx_power_level *cp;
	struct bt_hci_rp_vs_write_tx_power_level *rp;
	struct net_buf *buf, *rsp = NULL;
	int err;

	buf = bt_hci_cmd_create(BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL,
				sizeof(*cp));
	if (!buf) {
		printk("Unable to allocate command buffer\n");
		return;
	}

	cp = net_buf_add(buf, sizeof(*cp));
	cp->handle = sys_cpu_to_le16(handle);
	cp->handle_type = handle_type;
	cp->tx_power_level = tx_pwr_lvl;

	err = bt_hci_cmd_send_sync(BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL,
				   buf, &rsp);
	if (err) {
		uint8_t reason = rsp ?
			((struct bt_hci_rp_vs_write_tx_power_level *)
			  rsp->data)->status : 0;
		printk("Set Tx power err: %d reason 0x%02x\n", err, reason);
		return;
	}

	rp = (void *)rsp->data;

	net_buf_unref(rsp);
}

static void get_tx_power(uint8_t handle_type, uint16_t handle, int8_t *tx_pwr_lvl)
{
	struct bt_hci_cp_vs_read_tx_power_level *cp;
	struct bt_hci_rp_vs_read_tx_power_level *rp;
	struct net_buf *buf, *rsp = NULL;
	int err;

	*tx_pwr_lvl = 0xFF;
	buf = bt_hci_cmd_create(BT_HCI_OP_VS_READ_TX_POWER_LEVEL,
				sizeof(*cp));
	if (!buf) {
		printk("Unable to allocate command buffer\n");
		return;
	}

	cp = net_buf_add(buf, sizeof(*cp));
	cp->handle = sys_cpu_to_le16(handle);
	cp->handle_type = handle_type;

	err = bt_hci_cmd_send_sync(BT_HCI_OP_VS_READ_TX_POWER_LEVEL,
				   buf, &rsp);
	if (err) {
		uint8_t reason = rsp ?
			((struct bt_hci_rp_vs_read_tx_power_level *)
			  rsp->data)->status : 0;
		printk("Read Tx power err: %d reason 0x%02x\n", err, reason);
		return;
	}

	rp = (void *)rsp->data;
	*tx_pwr_lvl = rp->tx_power_level;

	net_buf_unref(rsp);
}

When the application is running, I can see that it reports changes of the tx power:

*** Starting Direction Finding Bluetooth initialization...success Advertising set create...success Update CTE params...success Periodic advertising params set...success Enable CTE...success Periodic advertising enable...success Extended advertising enable...success Started extended advertising Set Tx power level to -20 Get Tx power level -> TXP = -20 Set Tx power level to 8 Get Tx power level -> TXP = 8 Set Tx power level to -20 Get Tx power level -> TXP = -20 Set Tx power level to 8 Get Tx power level -> TXP = 8 Set Tx power level to -20 Get Tx power level -> TXP = -20 Set Tx power level to 8 Get Tx power level -> TXP = 8 Set Tx power level to -20 Get Tx power level -> TXP = -20 Set Tx power level to 8 Get Tx power level -> TXP = 8

Booting Zephyr OS build v2.7.99-1442-gf527a81dcf35 *** periodic advertising Beacon Demo as FA:6B:09:33:B5:E6 (random)

But using the "nRF Connect" application on an Android phone, I can't see any noticeable changes at the measured RSSI.

To ensure the problem is not from Android mobile's side, I set the static tx power to the values same as what was used in the above code.

First I'd set it to -20 dBm by using this config:

prj.conf

...
CONFIG_BT_CTLR_TX_PWR_MINUS_20=y

Then it was set to +8 dBm:

prj.conf

...
CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

Obviously, different values were reported for each of them by "nRF Connect" application.

Regards,

Saleh

0 Marjeris Romero over 3 years ago in reply to Saleh

Hi,

I am sorry for the late reply. I wonder if you have a corresponding RSSI logs together with the debug output logs you could attach as well?

I need some time to try to test doing the same on my end so I can see if I manage to change the tx power dynamically on this example, so it's better if I can come back to you on Monday after I have tried this myself.

Have a nice weekend.

Best regards,

Marjeris
Cancel
Vote Up 0 Vote Down

Cancel

0 Saleh over 3 years ago in reply to Marjeris Romero

Thank you!

Here you can find the log that has generated by this example:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/bluetooth/direction_finding_connectionless_rx/README.html

It shows the RSSI of each extended advertising packet:

TX side log:

*** Booting Zephyr OS build v2.7.99-1442-gf527a81dcf35  ***
Starting Direction Finding periodic advertising Beacon Demo
Bluetooth initialization...success
Advertising set create...success
Update CTE params...success
Periodic advertising params set...success
Enable CTE...success
Periodic advertising enable...success
Extended advertising enable...success
Started extended advertising as FA:6B:09:33:B5:E6 (random)
Set Tx power level to -20
Get Tx power level -> TXP = -20

RX side log (a long history, only a section has copied, other lines are similar):

...
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -320                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -30, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -300                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -30, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -300                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -33, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -330                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -32, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -320                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -34, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -340                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -33, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -330 
...

Then after switching to a higher power of tx (after one minute)

TX side log:

*** Booting Zephyr OS build v2.7.99-1442-gf527a81dcf35  ***
Starting Direction Finding periodic advertising Beacon Demo
Bluetooth initialization...success
Advertising set create...success
Update CTE params...success
Periodic advertising params set...success
Enable CTE...success
Periodic advertising enable...success
Extended advertising enable...success
Started extended advertising as FA:6B:09:33:B5:E6 (random)
Set Tx power level to -20
Get Tx power level -> TXP = -20                                                                                             
Set Tx power level to 8                                                                                                     
Get Tx power level -> TXP = 8

RX side log (a long history, only a section has copied, other lines are similar):

...
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -37, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -370                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -31, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -310                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -33, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -330                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -31, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -310                          
PER_ADV_SYNC[0]: [DEVICE]: 0A:12:31:86:77:93 (random), tx_power 127, RSSI -33, CTE AOD 2 [us], data length 0, data:             
CTE[0]: samples count 45, cte type AOD 2 [us], slot durations: 2 [us], packet status CRC OK, RSSI -330
...

0 Saleh over 3 years ago in reply to Saleh

Hi

Is there any update regarding this issue? Marjeris Romero
Cancel
Vote Up 0 Vote Down

Cancel