NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Wed, 07 Aug 2024 10:02:27 GMT

Hi mesh777,

A colleague found a way to configure TX Power during run-time. It isn't exactly dynamic configuration, but maybe it can help.

Before we go into the details, please know that this method is not tested thoroughly, and does involve using internal Mesh stack structures that were not intended for application.

First, define the stack-internal struct bt_mesh_ext_adv in your application:

enum {
  /** Controller is currently advertising */
  ADV_FLAG_ACTIVE,
  /** Advertising sending completed */
  ADV_FLAG_SENT,
  /** Currently performing proxy advertising */
  ADV_FLAG_PROXY,
  /** The proxy has been start, but maybe pending. */
  ADV_FLAG_PROXY_START,
  /** The send-call has been scheduled. */
  ADV_FLAG_SCHEDULED,
  /** The send-call has been pending. */
  ADV_FLAG_SCHEDULE_PENDING,
  /** Custom adv params have been set, we need to update the parameters on
   *  the next send.
   */
  ADV_FLAG_UPDATE_PARAMS,

  /* Number of adv flags. */
  ADV_FLAGS_NUM
};

struct bt_mesh_ext_adv {
  uint8_t tag;
  ATOMIC_DEFINE(flags, ADV_FLAGS_NUM);
  struct bt_le_ext_adv *instance;
  struct net_buf *buf;
  uint64_t timestamp;
  struct k_work_delayable work;
  struct bt_le_adv_param adv_param;
};

Then, after the mesh stack is initialized (at the end of bt_ready), you can set the TX Power here:

/* Hack into the mesh stack, due to lack of proper API */
STRUCT_SECTION_FOREACH(bt_mesh_ext_adv, adv) {
  LOG_INF("adv: %8p", (void *) adv);

  if (adv->instance) {
    adv->instance->tx_power = txp_lvl;
  }
}

Where txp_level is any valid int8_t (signed) value for a given chip. For example: 0/4/-4/-8, etc.

This will basically find all declared advertiser instances in the stack and directly set the power. Subsequently, when new Network PDUs or Beacons or GATT advertising start, they will start using the power configured here. If advertisings are disabled and enabled again, this will have to be redone at that time.

This should work with at least Mesh packets with ADV bearer. Once again, this isn't fully tested, so please perform additional testing, if you want to use this.

Hieu

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 13:31:00 GMT

Yes, we have recorded them. I can see how reading TX Power and seeing 0 would be concerning. I will talk with the documentation team to find a way to present the fact more clearly.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Fri, 28 Jun 2024 13:17:50 GMT

Please forward both findings, also the one that with static configuration its confusing to see that register is switched back to 0 all the time without any good reason.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 12:57:22 GMT

Do you mean dynamic/run-time control of TX Power for Bluetooth Mesh? If so, we have registered it 🙂

As for other regular BLE activities, I believe the dynamic TX Power control works fine.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Fri, 28 Jun 2024 12:52:07 GMT

Ok, ill try to search for similar topic regarding my last question at first.

Final thoughts -> such basic feature as TX Power control still causes issues, maybe it should be brought forward to Softdevice/NCS developers as this is not first time I am working on resolving TX Power control:)

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 12:41:38 GMT

I'm happy to help. I also learn new things and refresh a lot of the rusty bits of knowledge while answering your questions too. 🙂

[quote user="mesh777"]We need to perform spurious emission testing, maybe there are any Nordic guidelines upon that especially related to test firmware?[/quote]

This is a rather different topic. May I ask you to open a new case for this? 🙂

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Fri, 28 Jun 2024 12:36:52 GMT

Ok I see. Thanks again for rapid and informative responses.

We need to perform spurious emission testing, maybe there are any Nordic guidelines upon that especially related to test firmware?

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 12:36:36 GMT

I also notice previously I use misleading words in this sentence:

[quote user="vthieu"]For Mesh, I tweak the logic a little like below and I can observe TXPOWER being 8 all the time.[/quote]

I mean "all the time" as in "in a lot of instances," not "always". My apology if that confused you. I will edit it so that it doesn't confuse any future readers.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 12:32:05 GMT

[quote user="mesh777"]

But why to reconfigure it always back to 0dBm then?

Or it is related to not retained register value due transceiver power modes or something?

[/quote]

TXPOWER-set-to-0 is just a known state to make it simpler to support multiple TX Power for different activities. Examples include but not limited to other BLE activities, or user application's MPSL timeslot API use, or Power Envelope Control.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Fri, 28 Jun 2024 11:55:41 GMT

But why to reconfigure it always back to 0dBm then?

Or it is related to not retained register value due transceiver power modes or something?

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 11:45:59 GMT

No, it isn't necessarily contradicting, if you consider that the radio only transmits for a little time overall. In Bluetooth Mesh, the radio needs to be on receive as much as possible to not miss messages.

Remember that there is a limit of 100 Lower-Transport PDU per 10-second moving window, too. So even if your node has a lot it wants to send, it can't transmit all the time.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Fri, 28 Jun 2024 10:08:44 GMT

[quote userid="9456" url="~/f/nordic-q-a/112210/ncs-softdevice-mesh-ext-advertising---tx-power-control/491259"]CONFIG_BT_CTLR_TX_PWR_ANTENNA and the CONFIG_BT_CTLR_TX_PWR configuration line sets the default TX Power for all activities.[/quote][quote userid="9456" url="~/f/nordic-q-a/112210/ncs-softdevice-mesh-ext-advertising---tx-power-control/491259"]Yes, I too find that it is 0 for the absolutely vast majority of the time[/quote]

These two things sounds contradicting in my opinion, if all activities set to happen with 8dbm, then why most of the time register is set to 0dBm?

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Fri, 28 Jun 2024 09:01:19 GMT

CONFIG_BT_CTLR_TX_PWR_ANTENNA and the CONFIG_BT_CTLR_TX_PWR configuration line sets the default TX Power for all activities.

Therefore, without a runtime reconfiguration, the SoftDevice Controller should use the configured default.

Also note that the CONFIG_BT_CTLR_TX_PWR choices depends on CONFIG_BT_CTLR_TX_PWR_ANTENNA being not set. If the _ANTENNA configuration is set, it takes priority.

[quote user="mesh777"]In your sample code you do not print value of 0 by the way, otherwise it is 0 most of the time.[/quote]

Yes, I too find that it is 0 for the absolutely vast majority of the time and can't figure out a good way to see the few "8\n" among the hundreds of "0\n," so I set up that logic instead.

I guess if we really want to, we could also set a logic to get the statistic on how often and for how long TXPOWER stays in a particular value.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Wed, 26 Jun 2024 15:49:22 GMT

Many thanks for clarification.

I noticed that most of the time TX Power register is 0dBm, with the static config set which mentioned above.

Does it mean that TX power setting is applied not to all handles? To which it is applied then?

In your sample code you do not print value of 0 by the way, otherwise it is 0 most of the time.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Tue, 25 Jun 2024 10:16:17 GMT

[quote user="mesh777"]1. Can you please explain why Softdevice is altering TX Power on its own, after its configured by the user once?[/quote]

It makes more sense if you think of it as "the user requests the SoftDevice Controller to use this TX Power for that connection/advertising handle; and the SoftDevice then serves that request appropriately by changing TX Power when it's time to serve that handle."

At no point does the SoftDevice change this requested power. When the radio transmits, the TX Power will be raised to the appropriate value.

If you configure request different handles to different TX Power, the Controller will also get that done.

[quote user="mesh777"]2. Dynamic setting would allow user to reconfigure TX Power, this is not a must but nice to have feature. Also dynamic setting allow to have chip dependent configuration, e.g. 52832 does not have 8dbm, therefore its configured for 4dbm in our case.[/quote]

Thank you. This is a very reasonable feature. We have registered it and will look into it. Unfortunately, it is quite tricky to realize this with the way the mesh layers interact, so it might be difficult.

[quote user="mesh777"]

3. Static configuration does not work neither. It sets expected value to the register once, and later 0dBm is read back from the register all the time. I tried following conf:

CONFIG_BT_CTLR_TX_PWR_ANTENNA=8

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

So we are stuck with 0dBm at the moment :(

[/quote]

I just tried with the Mesh Light sample, and it does work. I do see that just printing out TXPOWER rapidly doesn't work nearly as well as I once remember. Perhaps it worked better with BLE applications where the radio time is longer.

For Mesh, I tweak the logic a little like below and I can observe TXPOWER does get set to 8. You could also use debugging to stop the execution at certain point to confirm the register value.

int main(void)
{
	int err;

	printk("Initializing...\n");

	err = bt_enable(bt_ready);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
	}

	while (1)
	{
		int txpower = NRF_RADIO->TXPOWER;
		if (txpower > 0) printk("TX power: %d\n", txpower);
		static int cnt;
		if (cnt > 50000)
		{
			static int cnt2;
			printk("cnt2: %d\n", cnt2++);
			cnt = 0;
		}
		k_sleep(K_MSEC(1));
	}

	return 0;
}

If you want absolute proof that it works, I recommend using a spectrum analyzer and look into the radio output directly.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Tue, 25 Jun 2024 07:15:19 GMT

Thanks for rapid response.

1. Can you please explain why Softdevice is altering TX Power on its own, after its configured by the user once?

2. Dynamic setting would allow user to reconfigure TX Power, this is not a must but nice to have feature. Also dynamic setting allow to have chip dependent configuration, e.g. 52832 does not have 8dbm, therefore its configured for 4dbm in our case.

3. Static configuration does not work neither. It sets expected value to the register once, and later 0dBm is read back from the register all the time. I tried following conf:

CONFIG_BT_CTLR_TX_PWR_ANTENNA=8

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

So we are stuck with 0dBm at the moment :(

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Mon, 24 Jun 2024 13:29:53 GMT

For general legacy and extended advertising, you can use https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1-1/include/zephyr/bluetooth/hci.h#L91-L98.

But for Mesh, there is no way to get the advertising handle, unfortunately. Sorry that we ended up at this dead end after my suggestions.

May I ask why you wish to have dynamic TX power control with mesh?

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Thu, 20 Jun 2024 12:19:02 GMT

Is there a way to determine which handles are available? With Zephyr controller it worked 0-3 for 4 sets, but with Softdevice looks that it does not work that way. For last 3 sets I get such error: "Set Tx power err: -5 reason 0x00"

EDIT: Also I tried to print value of NRF_RADIO->TXPOWER each 200ms, it always returns 0, despite that tx power was reconfigured for 8dBm using functions from the sample project.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Thu, 20 Jun 2024 12:15:01 GMT

[quote user="mesh777"]What is the reason of such behaviour? Does it mean that TX Power needs to be reconfigured continuously or it is handled by Softdevice automatically?[/quote]

The SoftDevice will handle the TX Power on its own. The Host only needs to request once.

[quote user="mesh777"]The reference sample does not take into account multiple AVD sets, when EXT ADV is enabled. Maybe Conn Handle somehow can be determined to configure each set?[/quote]

I believe that the sample take into account ADV sets as well. Notice that you can set TX Power with an advertising set handle: https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1-1/samples/bluetooth/hci_pwr_ctrl/src/main.c#L239-L240.

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

mesh777 — Thu, 20 Jun 2024 11:56:41 GMT

[quote userid="9456" url="~/f/nordic-q-a/112210/ncs-softdevice-mesh-ext-advertising---tx-power-control/489470"]Please note that the SoftDevice Controller only raise the TX Power momentarily for the radio action, and then will set it back to 0[/quote]

What is the reason of such behaviour? Does it mean that TX Power needs to be reconfigured continuously or it is handled by Softdevice automatically?

The reference sample does not take into account multiple AVD sets, when EXT ADV is enabled. Maybe Conn Handle somehow can be determined to configure each set?

RE: NCS: Softdevice+Mesh+Ext. Advertising -> TX Power Control?

Hieu — Wed, 19 Jun 2024 09:53:20 GMT

Hi mesh777,

You should be able to control the TX Power following the method demonstrated in the Bluetooth: HCI Power Control sample.

Please note that the SoftDevice Controller only raise the TX Power momentarily for the radio action, and then will set it back to 0. A crude way I used to confirm things are working is to repeatedly print out the content of the TXPOWER register.

Hieu