How to set transmit power for BLE in nRF Connect SDK?

[bmcdonnell-npm]

How can I adjust the BLE transmit (Tx) power, up to and including +8 dBm? I'm using nRF Connect SDK (NCS) on an nRF52840-DK.

I modified the throughput sample to reverse the roles (GAP central becomes GATT server; GAP peripheral becomes GATT client), added timeslots and radio notifications.

I've tried 2 different approaches so far, neither of which fully works. I'm testing by running the code on one nRF52840-DK, pressing Button #2 to make it the peripheral (advertising), and scanning with an nRF52840-Dongle (with "nRF Connect for Desktop Bluetooth Low Energy Standalone v4.0.0") on my PC to see its Rx signal strength.

I see a possible 3rd approach, but the code doesn't make sense to me, and I'm not sure if it applies.

Approach #1a - mpsl_tx_power_channel_map_set(), NCS v2.0.2

This seems to work up to 0 dBm, i.e. I get higher Rx signal strength at the Dongle when DK is set to 0 dBm compared to -20 dBm. But there is no difference in Rx signal strength comparing Tx power set to 0 and 8 dBm.

Approach #1b - mpsl_tx_power_channel_map_set(), NCS v2.1.0-rc1

Doesn't work. No difference in Rx signal strength, regardless of Tx power setting.

Approach #2 - mpsl_tx_power_radio_supported_power_adjust(), NCS v2.1.0-rc1

Doesn't work. No difference in Rx signal strength, regardless of Tx power setting.

Note, this is the first tag where mpsl_tx_power_radio_supported_power_adjust() is provided.

Possible Approach #3 - Imitate HCI Power Control Sample

I haven't tried this. Does this fit my situation, since I'm not using the HCI in my application?

Also, the set_tx_power() function looks like it's setting values (members of the cp struct) as if to use them to control the tx power, but it never uses them. How does this even work?

throughput_mod__no_tx_pwr_ctrl.zip

throughput_mod__approach_1a.zip

throughput_mod__approach_1b.zip

throughput_mod__approach_2.zip

[Hung Bui]

Hi Brendan, 

Do you use MPSL (Multi Protocol Service Layer) in your application ? You only need MPSL when you have other protocol than BLE and want to run it concurrently with the main protocol then you should use MPSL. 

If you only use BLE, then actually using HCI command to control TX power is the preferred way. 

You can find my example here:  How to set TX power to maximum +8dbm for advertising as well as when connected 

Actually any BLE example would use HCI. It's the communication between the host and the controller in BLE. 

The issue here is that there isn't an API from the application to the host to control TX power and the application has to access the controller directly to set the TX power. 

[bmcdonnell-npm]

Hung Bui said:

Do you use MPSL (Multi Protocol Service Layer) in your application ? You only need MPSL when you have other protocol than BLE and want to run it concurrently with the main protocol then you should use MPSL. 

I am using MPSL for timeslots, to ensure that the radio is not in use for some small periods of time. So controlling the radio power for just BLE, or for all protocols, should be fine for my purposes. As long as it covers BLE in both connected and non-connected (i.e. advertising/scan) states.

... I see that your function set_tx_power() is identical to the one in the HCI Power Control sample. (So to tie this back to my original post, you're suggesting my proposed option #3.)

I tried adding those set_tx_power() and get_tx_power() functions to my code, and calling them like this:

static int tx_pwr_cmd(const struct shell *shell, size_t argc,
			char **argv)
{
	if (argc == 1) {
		shell_help(shell);
		return SHELL_CMD_HELP_PRINTED;
	}

	if (argc > 2) {
		shell_error(shell, "%s: bad parameters count", argv[0]);
		return -EINVAL;
	}

	int8_t tx_pwr = (int8_t)strtol(argv[1], NULL, 10);
	int8_t txp_get = 0;
	set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, tx_pwr); //TODO: also set power when connected...
	get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, &txp_get);

	shell_print(shell, "Tx Power set to: %d", (int)txp_get);

	return 0;
}

but it doesn't work. I get this output on the console:

Why isn't this working, or what am I doing wrong?

Also, should my approaches #1 and #2 work? If so, why aren't they? If not, why not?

BTW, I forgot to include the boards/nrf52840dk_nrf52840.overlay file in my previous attachments:

0407.nrf52840dk_nrf52840.overlay

[Hung Bui]

Hi Brendal, 

Have you tried my example  ? 

Please take note that you need this in the prj.conf file: 

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y

If it doesn't work, could you attach your application for approach #3 ? 

[bmcdonnell-npm]

Hung Bui said:

Have you tried my example  ? 

It's not clear to me how to modify it to get it to run on my board (nRF52840-DK).

Hung Bui said:

Please take note that you need this in the prj.conf file: 

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y

When I add CONFIG_BT_CTLR_ADVANCED_FEATURES=y, it tells me that depends on setting BT_LL_SW_SPLIT (as pictured below). When I add that, the build warns me that it is an experimental symbol. And when I run the program, it repeatedly assert fails and restarts.

Hung Bui said:

If it doesn't work, could you attach your application for approach #3 ?

throughput_mod__approach_3.zip

[Hung Bui]

Hi Brendal, 

I'm not so sure what you meant by "how to modify it to get it to run on my board  (nRF52840-DK)."

You can build it without any modification for your board. Just select the board and it should be built normally out the box. 

Regarding 

CONFIG_BT_CTLR_ADVANCED_FEATURES=y 

You are right that it requires BT_LL_SW_SPLIT.  It's because the feature is for Zephyr controller not Nordic Softdevice controller. Zephy controller doesn't support MPSL btw. 

So if you can just keep

CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y and remove CONFIG_BT_CTLR_ADVANCED_FEATURES=y 

and it should work. 

I would suggest to try testing on my example where MPSL is not used first before moving to test on your code. 

But as far as I understand if you only use BLE the HCI command 

BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL is what you should use. 

[bmcdonnell-npm]

Hung Bui said:

I'm not so sure what you meant by "how to modify it to get it to run on my board  (nRF52840-DK)."

It does not build.

Hung Bui said:

So if you can just keep

CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y and remove CONFIG_BT_CTLR_ADVANCED_FEATURES=y 

and it should work. 

OK, I tried this. Judging by the Rx power level at the dongle, this seems to be working now for advertising. I further modified the code (attached below, "approach 3.1") to attempt to set the power level for other situations. Judging by console feedback (pictured below), it seems to be working for scan responses, but not after the connection is established. (The console output is the same regardless of whether a connection has been established.)

Am I correct in thinking that these are the 3 states (advertising, scan responses, and connected) for which this set_tx_power() function sets power levels? And am I setting set_tx_power() params correctly? How do I get it working for the connected state?

throughput_mod__approach_3.1.zip

Thanks.

[Hung Bui]

Hi Brendal, 

Could you show how you configure the project ? 
You should add build configuration and select the nRF52840 DK like this: 

On the side it should be like this after you configured the project: 

Then when you build you should see this: 

In the screenshot you provided it seems that the nRF51dk_nrf51422 was selected instead of nRF52840 dk: 

Regarding your question about txpower when connected, if you had a look at the case I pointed to you can find that you need to call  set_tx_power() with BT_HCI_VS_LL_HANDLE_TYPE_CONN in order to set the txpower when in connection. 

BT_HCI_VS_LL_HANDLE_TYPE_ADV is only applied for advertising. 

[bmcdonnell-npm]

Hung Bui said:

You should add build configuration and select the nRF52840 DK like this: 

That allowed me to build your example, thanks.

I modified your example's main for loop to set_tx_power() with all values repeatedly. It works for BT_HCI_VS_LL_HANDLE_TYPE_ADV and BT_HCI_VS_LL_HANDLE_TYPE_CONN, but not for BT_HCI_VS_LL_HANDLE_TYPE_SCAN.

My modification of your example's loop:

	printk("Advertising successfully started\n");

	for (;;) {
		dk_set_led(RUN_STATUS_LED, (++blink_status) % 2);

		if ((blink_status % 4) == 0)
		{
			printk("\nset_tx_power():\n");
			printk("\n - BT_HCI_VS_LL_HANDLE_TYPE_ADV...)\n");
			set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
							0,
							8);

			printk("\n - BT_HCI_VS_LL_HANDLE_TYPE_SCAN...)\n");
			set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_SCAN,
							0,
							8);

			printk("\n - BT_HCI_VS_LL_HANDLE_TYPE_CONN...)\n");
			set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_CONN,
							0,
							8);

			printk("\n");
		}

		k_sleep(K_MSEC(RUN_LED_BLINK_INTERVAL));
	}

Console output (same whether connected or not):

set_tx_power():

 - BT_HCI_VS_LL_HANDLE_TYPE_ADV...)
Actual Tx Power: 8

 - BT_HCI_VS_LL_HANDLE_TYPE_SCAN...)
W: opcode 0xfc0e status 0x12
Set Tx power err: -5 reason 0x00

 - BT_HCI_VS_LL_HANDLE_TYPE_CONN...)
Actual Tx Power: 8

That is similar to how in my previous reply ("approach 3.1"), set_tx_power() works for 2/3 of the handle_types (but it fails for BT_HCI_VS_LL_HANDLE_TYPE_CONN, not BT_HCI_VS_LL_HANDLE_TYPE_SCAN like here).

Why are these not working for all handle_types?

[Hung Bui]

Hi Brendan, 

What do you expect when control the BT_HCI_VS_LL_HANDLE_TYPE_SCAN ? Which activity you are looking at ? 
As far as know BT_HCI_VS_LL_HANDLE_TYPE_SCAN only applied if you are doing active scanning in observer (scanner) role. 

[bmcdonnell-npm]

Hung Bui said:

What do you expect when control the BT_HCI_VS_LL_HANDLE_TYPE_SCAN ?

I expect to be able to set the power for any given mode before I enter that mode, so that specified power level is always used in that mode, unless/until it is commanded otherwise. Is this not how it works?

Hung Bui said:

Which activity you are looking at ?

I'm not sure what you mean. The device is a GAP peripheral and GATT client, if that's relevant.

... Zooming out, going back to my original post: will I be able to use this set_tx_power() function for dynamic power control, and also use the MPSL for timeslots? If these will not work together, then shouldn't we be working on getting my "Approach 1 or 2" working instead of this (which I called "Approach 3")?