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

[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")?