nRF NCS - Set radio TX Power

[Farhang]

Hi Nordic Team,

I am using a simple GPIO (tx/rx controlled via GPIO) FEM (PA/LNA) with connected to nRF52840.

I know I am allowed to crank up the TX power of nRF to +2dBm as per certification of the module.
I am using MPSL in nRF NCS to work with BLE and Thread in a time multiplexed fashion. (CONFIG_MPSL is set to yes, so is CONFIG_BT_LL_SOFTDEVICE)

How do I crank the gain of nRF52840 so it achieves maximum allowed gain for (+2dBm) for all radio activity (BLE adv, connection and all Thread activity)?

Should I directly set the TXPOWER register? Or is there a suitable sd_ call for this? 

There are a few Q/As around BLE but I thought this would be a different case when using multiprotocol.

2nd question: What are the max allowed tx power for Thread/BLE? I believe BLE is +20dbm but not sure about Thread.

3rd question: Is there a reason why sd_ interface allows setting BLE gain per role? in other words, are there difference limitations in TX power for each BLE role?

Thanks for your support.

[Einar Thorsrud]

Hi,

Should I directly set the TXPOWER register? Or is there a suitable sd_ call for this? 

The stacks have different API for setting Tx power. For BLE you use BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL (see this sample). For Thread you use otPlatRadioSetTransmitPower().

2nd question: What are the max allowed tx power for Thread/BLE? I believe BLE is +20dbm but not sure about Thread.

The maximum Tx power for BLE is +20 dBm but in much of the world (including Europe) the limit is 10 dBm, so in most cases that is what you need to relate to unless you make different devices for different regions.

3rd question: Is there a reason why sd_ interface allows setting BLE gain per role? in other words, are there difference limitations in TX power for each BLE role?

I assume you are referring to full SoftDevice BLE stacks here and not just the SoftDevice controller? That is not relevant in NCS context. But you are right, recent SoftDevice versions support that feature. In most case it is not useful, but you could think of situations where you would for instance want to have a different range for connections than for advertisements etc or that you are willing to spend more power to maintain a specific connection or simmilar.

[Farhang]

@eith Thanks for the response, the sample helped a bit.

However, due to my project requirements, I need to use MPSL as explained in this post and @joh2 responded in this post that this will be available in v1.5.1 of NCS. I went ahead and updated my nrfxlib to that commit (ef9e33)

I then used the same helper functions in the sample to set BLE power in my project, with the.conf params below.

CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_CONN_RSSI=y
CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y

The BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL command passes but when read via BT_HCI_OP_VS_READ_TX_POWER_LEVEL it doesn't match! The read tx power remains at 0.

Also BT_HCI_OP_READ_RSSI command returns -5 which I believe hints that is not supported.

Should I be using the MPSL API (e.g. mpsl_tx_power.h is available in the nrfxlib commit above) since I have CONFIG_MPSL=y?

Looks like i can set via mpsl_tx_power_channel_map_set() but can't read the tx power?

Or is the issue that softdevice BLE stack isn't supporting these command yet with MPSL?

[Einar Thorsrud]

Hi,

The mpsl_tx_power_channel_map_set() function just sets a maximum. You should use the APIs from the respective stacs to set Tx power. It seems to work on my end, by testing with NCS 1.5.0 and just slightly modifying the hci_pwr_ctrl sample like this (here I am including 2 dB and removing some power levels that are invalid for the nRF52840):

Fullscreen hci_pwr_ctrl.diff Download

diff --git a/samples/bluetooth/hci_pwr_ctrl/prj.conf b/samples/bluetooth/hci_pwr_ctrl/prj.conf
index a562348889..a42f896b92 100644
--- a/samples/bluetooth/hci_pwr_ctrl/prj.conf
+++ b/samples/bluetooth/hci_pwr_ctrl/prj.conf
@@ -1,11 +1,12 @@
 CONFIG_BT=y
 CONFIG_BT_DEBUG_LOG=y
 CONFIG_BT_PERIPHERAL=y
-CONFIG_MAIN_STACK_SIZE=512
-CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=768
+CONFIG_MAIN_STACK_SIZE=2048
+CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
 CONFIG_BT_HRS=y
 CONFIG_BT_DEVICE_APPEARANCE=833
 CONFIG_BT_DEVICE_NAME="Dynamic test beacon"
 CONFIG_BT_CTLR_ADVANCED_FEATURES=y
 CONFIG_BT_CTLR_CONN_RSSI=y
 CONFIG_BT_CTLR_TX_PWR_DYNAMIC_CONTROL=y
+CONFIG_MPSL=y
diff --git a/samples/bluetooth/hci_pwr_ctrl/src/main.c b/samples/bluetooth/hci_pwr_ctrl/src/main.c
index c52b950888..1749da5faf 100644
--- a/samples/bluetooth/hci_pwr_ctrl/src/main.c
+++ b/samples/bluetooth/hci_pwr_ctrl/src/main.c
@@ -31,13 +31,12 @@ static const struct bt_data ad[] = {
 
 #define DEVICE_NAME CONFIG_BT_DEVICE_NAME
 #define DEVICE_NAME_LEN (sizeof(DEVICE_NAME) - 1)
-#define DEVICE_BEACON_TXPOWER_NUM  8
+#define DEVICE_BEACON_TXPOWER_NUM  5
 
 static struct k_thread pwr_thread_data;
 static K_THREAD_STACK_DEFINE(pwr_thread_stack, 320);
 
-static const int8_t txp[DEVICE_BEACON_TXPOWER_NUM] = {4, 0, -3, -8,
-						    -15, -18, -23, -30};
+static const int8_t txp[DEVICE_BEACON_TXPOWER_NUM] = {4, 2, 0, -8, -20};
 static const struct bt_le_adv_param *param =
 	BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_USE_NAME,
 			0x0020, 0x0020, NULL);