NCS Mesh: TX Power register value does not change when changing TX Power via HCI

[mesh777]

I am trying to control TX Power of Mesh using sample code from here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/samples/bluetooth/hci_pwr_ctrl/README.html

I call set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, (int8_t) 4);

Function does not return with error, however value in TXPOWER register does not change.

Calling get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, &tx_power); afterwards, returns expected value of 4.

Chip nRF52832.

prj.conf contains the following settings which might be related to issue:

CONFIG_BT_OBSERVER=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_SETTINGS=y

CONFIG_BT_LL_SOFTDEVICE=n

CONFIG_BT_LL_SW_SPLIT=y

CONFIG_BT_CTLR_ADVANCED_FEATURES=y

CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y

CONFIG_BT_EXT_ADV=n

Mesh is also enabled and communication functions properly.

Could you please advice what can be wrong?

[Hung Bui]

Hi mesh777,

I noticed that you uses

CONFIG_BT_LL_SW_SPLIT=y

Is there any reason you want to use Zephyr controller instead of Nordic controller ? 
If you use Zephyr controller, maybe the issue related to this: https://github.com/zephyrproject-rtos/zephyr/issues/28653

This can fix it https://github.com/zephyrproject-rtos/zephyr/commit/1723e479ab6c1dfb6a18db0d908e31903fb34ba0

[mesh777]

Hi Hung,

Thanks for very fast response.

These changes seems to be already in NCS version we are using (2.4.0).

Reason why we went for Zephyr controller - it has smaller RAM footprint, which is critical for nRF52832.

Any other ideas how to resolve the issue?

[Hung Bui]

Hi, 
It's strange that even after the fix it doesn't work for you. 
Since it's Zephyr controller, you will have to create an issue on github or use Discord as we don't have much experience with the controller. 
My suggestion is to try step into the code to see why when you set the new TX Power it doesn't take any effect. The benefit of using Zephyr controller is that you can step into the stack and debug. 

[mesh777]

Hmm seems that build with SoftDevice controller does not change TXPOWER register neither.

Maybe it has something to do with Mesh, or this sample in the link provided above should change TX Power also when running Mesh?

[Hung Bui]

Could you try to test the sample without mesh ? 

[mesh777]

Ok, for Mesh seems that both have to be set:

set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV, 0, (int8_t) 4);

set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_SCAN, 0, (int8_t) 4);

There is no description on these handle types in code, can you please add some comment why both needs to be set?

And second question is about Extended Advertising, when we enable it will each advertising set use same TX Power or I have to configure each separately, if yes how you would suggest to do it?

Thanks in advance.

[Hung Bui]

Hi, 
As far as I know if you don't set the exact tx_power for a specific extended advertising set it will use the default one. 
So if you want to have the same tx_power on all extended advertising you can simply set it with  set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,..)

Please double check with actual test if my understanding is correct.

This command set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_SCAN, 0, (int8_t) 4);  will set the txpower for the scan request packet. I'm not 100% sure why it's needed for mesh as mesh usually don't use scan request. 

[mesh777]

Its not very clear the default one is the one which is the same as set for the first advertising set, or you mean it will set the default TX Power for other sets?

set_tx_power has also handle as an argument, how to obtain that handle of every enabled advertising set (in specific for extended advertising sets used for Mesh)?

[Hung Bui]

From what I can see from the code (for Zephyr controller but should be similar on Softdevice controller) https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/bluetooth/controller/ll_sw/ll_tx_pwr.c#L153

It seems that set_tx_power() will take into account the handle when you do extended advertising. It's only ignored when you do normal advertising. 

So my suggestion is to try to set the tx_power on each of the set of extended advertising, just to be sure.