Setting Tramsmission-Power but current Consumption Peaks doesn't change

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

Hieu — Tue, 06 Feb 2024 14:06:04 GMT

Hi Quirin,

Don't worry, I have been out of office as well, and still am partially, actually.

I still suspect that is the PPK producing that sharp overshoot towards the left side of every peaks. If you can add the dynamic TX Power control to the Bluetooth: Throughput sample, where the TX peak should be kept longer, it should show more clearly.

The advanced equipment should help even faster, if you plan to do that already.

Best regards,

Hieu

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

qrn — Tue, 06 Feb 2024 10:15:22 GMT

Hi Hieu,

Thanks for your help.

Sorry for the late reply I was out of office.

[quote userid="9456" url="~/f/nordic-q-a/107689/setting-tramsmission-power-but-current-consumption-peaks-doesn-t-change/466951"]

Those short spikes are likely due the PPK2's limitation, rather than there actually being a spike. We have seen such cases before.

If you use more advanced equipment, there ought to be no irregularity like that.

qrn said:

[/quote]

I will test everything with advanced equipment to see if it's indeed a problem with the PPK2.

[quote userid="9456" url="~/f/nordic-q-a/107689/setting-tramsmission-power-but-current-consumption-peaks-doesn-t-change/466951"]1. The current peak was too short for the PPK2 to measure properly. Try turning the sampling rate of the tool to the highest possible to mitigate this.[/quote]

I don't think that could be the Problem I'm always testing with the highest possible sampling Rate of 100,000 samples per Second

[quote userid="9456" url="~/f/nordic-q-a/107689/setting-tramsmission-power-but-current-consumption-peaks-doesn-t-change/466951"]2. The connection TX Power was not changed to 0dB at all. This should not be the case, because the connection should be established with the same TX Power that was used for advertising. Could you please try printing NRF_RADIO->TXPOWER repeatedly to see if the number is ever -40 or 8 during a connection? Note that outside of the radio TX time, the register value can go back to 0.[/quote]

I tested the TX Power with the HCI Power Control Sample I modified the Dynamic TX power setting during Connection to a cycle like in the Advertising and read the TX_Power from the Register like you said.

Here are my results

The TX_Power is changing every 4s for 8dbM there is a huge difference but for the other dBm Values it's pretty much the same.

I did some close ups for the values.

I left 8dBm out because it's clearly different.

0dBm:

-8dBm:

-20dBm:

-40dBm:

All of them look pretty much the same. Every Peak within a TX_POWER value looks a bit different so I could look out for Peaks of different dBms to look even more similar.

Here is the Console Output the TX_POWER REGISTER is printed in unsigned int but I see that its in Fact changing

I only changed some txpower values, the modulate_tx_power function and added the some code to the main loop the rest is the same.

I put it together for you here:

static const int8_t txpower[DEVICE_BEACON_TXPOWER_NUM] = {8, 0, -8,
							   -18, -23, -40};

void modulate_tx_power(void *p1, void *p2, void *p3)
{
	int8_t txp_get = 0;
	uint8_t idx = 0;

	while (1) {
		// if (!default_conn) {
			printk("Set Tx power level to %d\n", txpower[idx]);
			set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
				     0, txpower[idx]);
			set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_CONN,
				     0, txpower[idx]);

			k_sleep(K_SECONDS(5));

			printk("Get Tx power level -> ");
			get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_ADV,
				     0, &txp_get);
			get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_CONN,
				     0, &txp_get);
			printk("TXP = %d\n", txp_get);
			printk("TX_POWER FROM REGISTER: %u\n", NRF_RADIO->TXPOWER);

			idx = (idx+1) % DEVICE_BEACON_TXPOWER_NUM;
		// } else {
		// 	int8_t rssi = 0xFF;
		// 	int8_t txp_adaptive;

		// 	idx = 0;

		// 	read_conn_rssi(default_conn_handle, &rssi);
		// 	printk("Connected (%d) - RSSI = %d\n",
		// 	       default_conn_handle, rssi);
		// 	if (rssi > -70) {
		// 		txp_adaptive = -20;
		// 	} else if (rssi > -90) {
		// 		txp_adaptive = -12;
		// 	} else {
		// 		txp_adaptive = -4;
		// 	}
		// 	printk("Adaptive Tx power selected = %d\n",
		// 	       txp_adaptive);
		// 	set_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_CONN,
		// 		     default_conn_handle, txp_adaptive);
		// 	get_tx_power(BT_HCI_VS_LL_HANDLE_TYPE_CONN,
		// 		     default_conn_handle, &txp_get);
		// 	printk("Connection (%d) TXP = %d\n",
		// 	       default_conn_handle, txp_get);

		// 	k_sleep(K_SECONDS(1));
		// 	printk("TX_POWER FROM REGISTER: %d\n", (int)NRF_RADIO->TXPOWER);

		// }
	}
}

// in main //

	while (1) {
		hrs_notify();
		printk("TX_POWER FROM REGISTER MAIN: %d\n", NRF_RADIO->TXPOWER);
		k_sleep(K_MSEC(200));
	}

Best regards Quirin

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

Hieu — Wed, 31 Jan 2024 13:27:08 GMT

Hi Quirin,

[quote user="qrn"]As seen there is a noticable difference between 8dbM and -40dbM, which is great. But even at -40dbM there s a peak to 15mA I can't explain?[/quote]

Those short spikes are likely due the PPK2's limitation, rather than there actually being a spike. We have seen such cases before.

If you use more advanced equipment, there ought to be no irregularity like that.

[quote user="qrn"]

As seen there is a noticable difference between 8dbM and -40dbM, which is great. But even at -40dbM there s a peak to 15mA I can't explain?

To test the TX power during a Connection because thats the state where the device is primally in, I tested this: Exercise 3 – Nordic Developer Academy (nordicsemi.com) because it was the lowest possible Connection Example I could think of.

That are the results tested during Connection:

I changed the TX-power through the prj.conf file as before in the beacon example.

...

As seen there is no noticable difference in Current Consumption is this the normal behavior, because I somehow thought the Current Consumption should be way lower when the TX power is set to -40dbM.

[/quote]

I have two guesses regarding this:

1. The current peak was too short for the PPK2 to measure properly. Try turning the sampling rate of the tool to the highest possible to mitigate this.

2. The connection TX Power was not changed to 0dB at all. This should not be the case, because the connection should be established with the same TX Power that was used for advertising. Could you please try printing NRF_RADIO->TXPOWER repeatedly to see if the number is ever -40 or 8 during a connection? Note that outside of the radio TX time, the register value can go back to 0.

Besides that, please test with this sample and see if there are clear differences when changing the TX Power while running the same application: Bluetooth: HCI Power Control.

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

qrn — Tue, 30 Jan 2024 09:28:13 GMT

Hi Hieu,

I hope you had a great Weekend.

I did some testing with the nrf sample for beacon Advertising.

I manually changed the TX-Power in the prj.conf from 8dbM to -40dbM and made some screenshots.

As the sample only shows non connectable advertising here are some screenshots of the peaks during Advertising. I also turned of Logging and Seriel output to reduce the idle consumption from around 750uA to around 1uA

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

CONFIG_BT_CTLR_TX_PWR_MINUS_40=y

As seen there is a noticable difference between 8dbM and -40dbM, which is great. But even at -40dbM there s a peak to 15mA I can't explain?

That are the results tested during Connection:

I changed the TX-power through the prj.conf file as before in the beacon example.

CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

CONFIG_BT_CTLR_TX_PWR_MINUS_40=y

As seen there is no noticable difference in Current Consumption is this the normal behavior, because I somehow thought the Current Consumption should be way lower when the TX power is set to -40dbM.

For reference here is the Code from the Link shown above:

main.c:

/*
 * Copyright (c) 2023 Nordic Semiconductor ASA
 *
 * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 */

#include <zephyr/kernel.h>
#include <zephyr/logging/log.h>
#include <zephyr/bluetooth/bluetooth.h>
#include <zephyr/bluetooth/gap.h>
/* STEP 3.2.1 - Include the header file of the UUID helper macros and definitions */
#include <zephyr/bluetooth/uuid.h>
/* STEP 4.1 - Include the header file for managing Bluetooth LE addresses */
#include <zephyr/bluetooth/addr.h>

#include <dk_buttons_and_leds.h>

/* STEP 5.1 - Create the advertising parameter for connectable advertising */
static struct bt_le_adv_param *adv_param = BT_LE_ADV_PARAM(
	(BT_LE_ADV_OPT_CONNECTABLE |
	 BT_LE_ADV_OPT_USE_IDENTITY), /* Connectable advertising and use identity address */
	800, /* Min Advertising Interval 500ms (800*0.625ms) */
	801, /* Max Advertising Interval 500.625ms (801*0.625ms) */
	NULL); /* Set to NULL for undirected advertising */

LOG_MODULE_REGISTER(Lesson2_Exercise3, LOG_LEVEL_INF);

#define DEVICE_NAME CONFIG_BT_DEVICE_NAME
#define DEVICE_NAME_LEN (sizeof(DEVICE_NAME) - 1)

#define RUN_STATUS_LED DK_LED1
#define RUN_LED_BLINK_INTERVAL 1000

static const struct bt_data ad[] = {
	/* STEP 3.1 - Set the flags and populate the device name in the advertising packet */
	BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),

};

static const struct bt_data sd[] = {
	/* STEP 3.2.2 - Include the 16-bytes (128-Bits) UUID of the LBS service in the scan response packet */
	BT_DATA_BYTES(BT_DATA_UUID128_ALL,
		      BT_UUID_128_ENCODE(0x00001523, 0x1212, 0xefde, 0x1523, 0x785feabcd123)),
};

void main(void)
{
	int blink_status = 0;
	int err;

	LOG_INF("Starting Lesson 2 - Exercise 3 \n");

	err = dk_leds_init();
	if (err) {
		LOG_ERR("LEDs init failed (err %d)\n", err);
		return;
	}

	/* STEP 4.2 - Change the random static address */
	bt_addr_le_t addr;
	err = bt_addr_le_from_str("FF:EE:DD:CC:BB:AA", "random", &addr);
	if (err) {
		printk("Invalid BT address (err %d)\n", err);
	}

	err = bt_id_create(&addr, NULL);
	if (err < 0) {
		printk("Creating new ID failed (err %d)\n", err);
	}

	err = bt_enable(NULL);
	if (err) {
		LOG_ERR("Bluetooth init failed (err %d)\n", err);
		return;
	}

	LOG_INF("Bluetooth initialized\n");
	/* STEP 5.2 - Start advertising */
	err = bt_le_adv_start(adv_param, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
	if (err) {
		LOG_ERR("Advertising failed to start (err %d)\n", err);
		return;
	}

	LOG_INF("Advertising successfully started\n");

	for (;;) {
		dk_set_led(RUN_STATUS_LED, (++blink_status) % 2);
		k_sleep(K_MSEC(RUN_LED_BLINK_INTERVAL));
	}
}

prj.conf:

#
# Copyright (c) 2018 Nordic Semiconductor
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# Logger module
CONFIG_LOG=y

# Button and LED library
CONFIG_DK_LIBRARY=y

# Bluetooth LE
CONFIG_BT=y
# STEP 1 - Include the Peripheral Role support
CONFIG_BT_PERIPHERAL=y
# STEP 2 - Change the Bluetooth LE device name to Nordic_Peripheral
CONFIG_BT_DEVICE_NAME="Nordic_Peripheral"

# Increase stack size for the main thread and System Workqueue
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_MAIN_STACK_SIZE=2048

#when testing 8dBM
#CONFIG_BT_CTLR_TX_PWR_PLUS_8=y

#when testing -40dBM
#CONFIG_BT_CTLR_TX_PWR_MINUS_40=y

# Logger module to lower idle consumption
CONFIG_LOG=n
CONFIG_STDOUT_CONSOLE=n
CONFIG_SERIAL=n
CONFIG_CONSOLE=n

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

Hieu — Fri, 26 Jan 2024 15:31:11 GMT

Hi Quirin,

My best guess for the peak current differences is other resources being run at the same time. A quick glance into the DTM source code shows that it makes use of some high-power consumption peripherals such as the TIMER and GPPI. The CPU That might explain the issue.

Can you retry with some very basic samples such as a BLE beacon sample and see if the peaks look more reasonable?

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

qrn — Fri, 26 Jan 2024 12:34:17 GMT

Hi there Hieu,

thanks for clarifying whats the TX-Peak, I do see a difference when zooming in.

Then I do have the question what the other peaks is it should be the RX peak but I don't understand why it's so heigh?

left 0dbM, right -40dbM

I did the OPP-tool and my current consumption with Power Profiler Kit II is higher then excpected with the OPP. The Idle Consumption is higher which can be due to the Fact that I'm not using the nrf52840 DK but the PAN1780 EVB so I see no problem there. (only a few uA)

But I really don't understand why the current peaks are that high even when I'm adding RX and TX for -40dbM the peak shouldn't be over 7,1mA. I would excpect a Peak behavior more ore less like shown in this github post:

Tx power levels are not similar on ADV and CONN modes when set manually (nRF52) · Issue #32212 · zephyrproject-rtos/zephyr · GitHub

Is there any way to achieve the behavior he is having because at the moment the avg. consumption doesn't really change noticable.

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

Hieu — Thu, 25 Jan 2024 13:04:40 GMT

Hi Quirin,

You need to zoom in even further, and identify which peak is a TX peak.

Here is a copy of your screenshot with the TX peaks highlighted.

For your power optimizing interest, you might want to know we have a few articles/blogs on the topic:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf52-designs
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/test_and_optimize/optimizing/power.html
https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/optimizing-power-on-nrf53-designs (the guide is for the nRF5340, but many tips are applicable to the nRF52832).

The Online Power Profiler I linked in my previous reply is also a handy tool for the job.

Best regards,

Hieu

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

qrn — Wed, 24 Jan 2024 13:30:30 GMT

Hi Hieu,

first of all thanks for your fast reply.

I did the testing again to do some screenshots to get some with a closer look.

Somehow I noticed that in the DTM that the current peaks, when I am using 8dbM, are slightly higher now, despite everything else being the same, but I still don't understand why the peaks are that high especially at -40dbM.

left: 8dBm, right: -40dBm

Because in the Specification sheet of the PAN1780 the power consumption of the TX at -40dBm should be around 2.3mA and the one of the RX around 4.3mA.

The other test is also very interesting to me because I am trying to set the tx-power based on the function given in the hci example

static void set_tx_power(uint8_t handle_type, uint16_t handle, int8_t tx_pwr_lvl)
{
	struct bt_hci_cp_vs_write_tx_power_level *cp;
	struct bt_hci_rp_vs_write_tx_power_level *rp;
	struct net_buf *buf, *rsp = NULL;
	int err;

	buf = bt_hci_cmd_create(BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL,
				sizeof(*cp));
	if (!buf) {
		printk("Unable to allocate command buffer\n");
		return;
	}

	cp = net_buf_add(buf, sizeof(*cp));
	cp->handle = sys_cpu_to_le16(handle);
	cp->handle_type = handle_type;
	cp->tx_power_level = tx_pwr_lvl;

	err = bt_hci_cmd_send_sync(BT_HCI_OP_VS_WRITE_TX_POWER_LEVEL,
				   buf, &rsp);
	if (err) {
		uint8_t reason = rsp ?
			((struct bt_hci_rp_vs_write_tx_power_level *)
			  rsp->data)->status : 0;
		printk("Set Tx power err: %d reason 0x%02x\n", err, reason);
		return;
	}

	rp = (void *)rsp->data;
	printk("Actual Tx Power: %d\n", rp->selected_tx_power);

	net_buf_unref(rsp);
}

But there is still no difference in the consumption peak or only a slight one within the margin of error.

left: 0dbM, right: -40dbM

The thing I am trying to accomplish is the lowest possible power consumption during a BLE Connection between my the PAN and my MobileDevice, which are maximum 3 meters apart from each other with no obsticals in the way, thats why the dbM value doesn't have to be this high.

Best regards,

Quirin

RE: Setting Tramsmission-Power but current Consumption Peaks doesn't change

Hieu — Wed, 24 Jan 2024 11:42:11 GMT

Hi Quirin,

In each advertising/connection interval, there will be a window of TX and a window of RX. What you might be seeing is the TX and RX current peak being so close together that they are indistinguishable. In your setup, the current peak during RX is always the same and higher than the one during TX, and therefore you cannot discern any difference.

Could you try to zoom in more and see if you can observe two separated current peaks, with the TX one decreases as TX Power decrease?

You might also want to try using the Online Power Profiler to see what you can expect.

Best regards,

Hieu