Set "TX Power" of nRF52833, using Zephyr

RE: Set "TX Power" of nRF52833, using Zephyr

Marjeris Romero — Mon, 20 Dec 2021 16:54:24 GMT

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

RE: Set "TX Power" of nRF52833, using Zephyr

Saleh — Tue, 14 Dec 2021 09:31:26 GMT

Is there any update regarding this issue? Marjeris Romero

RE: Set "TX Power" of nRF52833, using Zephyr

Saleh — Fri, 19 Nov 2021 15:56:44 GMT

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

RE: Set "TX Power" of nRF52833, using Zephyr

Marjeris Romero — Fri, 19 Nov 2021 12:56:28 GMT

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

RE: Set "TX Power" of nRF52833, using Zephyr

Saleh — Wed, 17 Nov 2021 17:28:57 GMT

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

RE: Set "TX Power" of nRF52833, using Zephyr

Marjeris Romero — Wed, 17 Nov 2021 16:21:51 GMT

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?

[quote user=""]But when "extended advertising" has enabled, the approach that has used in the above example doesn't work[/quote]

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