Feedback

Exercise 1 – Optimizing power consumption during Bluetooth LE advertising

In this exercise, you will configure the different advertising types discussed in Bluetooth LE advertising parameters and power consumption and using the Power Profiler Kit II, measure the power consumption on your device.

Exercise steps

In the GitHub repository for this course, go to the base code for this exercise, found in l4/l4_e1.

1. Define the advertising parameter for non-connectable advertising.

Define the advertising parameter for non-connectable advertising with an interval of 1 – 1.2 seconds by adding this line to the code:

Remember that BT_GAP_ADV_SLOW_INT_MIN = 1000 ms and BT_GAP_ADV_SLOW_INT_MAX = 1200 ms.

const struct bt_le_adv_param *param = BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE, \
							BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL);

Copy

const struct bt_le_adv_param *param = BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE, \
							BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL);

2. Define the advertising packet.

Define the advertising packet by adding the following code snippet:

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
};

Copy

static const struct bt_data ad[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),
	BT_DATA(BT_DATA_NAME_COMPLETE, DEVICE_NAME, DEVICE_NAME_LEN),
};

Include the mandatory flag BT_LED_AD_NO_BREDR to indicate that classic Bluetooth is not supported. Also include an optional parameter for the device name, making the advertising packet 18 bytes, which is larger than the minimum packet size.

3. Build and flash the application to your DK.

In the nRF Connect extension for VS Code, select Add a build configuration and add the board target for the device you are using (make sure to build without TF-M to minimize power consumption, this is the board target without /ns at the end). Then select Generate and Build.

When the build has completed select Flash in the Actions window.

4. Connect the Power Profiler Kit II to your DK.

Connect the PPK2 to your DK just like in the previous exercise.

5. Open and configure the Power Profiler.

5.1 Open the nRF Connect for Desktop and launch the Power Profiler application.

5.2 Select the PPK2 in the drop-down menu under Select Device.

Make sure your PPK2 is connected to your computer through a micro-USB cable and turned on.

Use the USB DATA/POWER line to power up the device.

5.3 Select source meter mode, set the supply voltage to 3000 mV, and enable power output.

5.4 Press Start in the Power Profiler app to start the measurements, then press the RESET button on your DK.

In the Power Profiler app, you should now see something similar to below. The spikes are the advertising events. Turn off Live View by toggling the switch in the upper right corner. Then zoom in to two of the spikes, hold down shift and drag your mouse between the two spikes to measure the time between them, which should be between 1 s and 1.2 s, like you set in Step 1.

Also take note of the average power consumption, which should be around 10 µA.

Zoom in further to have a closer look at one of the advertising events.

Notice the three main spikes. This is the device transmitting the advertising packet on the three default channels, 37, 38 and 39.

Note

As we did in Lesson 2- Exercise 1, you could use the nRF Connect for Mobile app on Android to view the content of the Bluetooth LE advertising and the raw data of the packets.

If you tap RAW, you get the raw data in the advertising packet.

6. Advertise on a subset of primary advertising channels.

To minimize the power consumption, configure your device to only advertise on a subset of the primary advertising channels 37, 38 and 39. In this example, disable advertising on channel 39.

6.1 Define the Bluetooth advertising parameter for disabling channel 29, and set the advertising interval to 1 – 1.2 s.

Add the following line to your code:

const struct bt_le_adv_param *param = BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE | BT_LE_ADV_OPT_DISABLE_CHAN_39, \
                                      BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL);

Copy

const struct bt_le_adv_param *param = BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE | BT_LE_ADV_OPT_DISABLE_CHAN_39, \
                                      BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL);

Note

It is recommended to use all three primary advertising channels (default).

The channels (37, 38, 39) are spread across the 2.4 GHz band to avoid Wi-Fi interference on channels 1, 6, and 11, providing redundancy against co-band interference. Only reduce to a subset of channels if power consumption is critical and the RF environment is well-controlled.

6.2 Comment out the code from Step 1, so that there is only one definition of the advertising parameter param.

6.3 Build and flash the application to your DK.

In the Power Profiler, zoom in to one of the advertising events and notice that one of the peaks is gone. This shows that the device is only transmitting the advertising packet on channels 37 and 38.

The average consumption has now dropped to 8 µA.

7. Minimize the advertising packet.

To lower the power consumption, minimize the advertising packet by removing the payload.

7.1 Define the minimum advertising packet.

To make the advertising packet as small as possible, only define the mandatory flags.

Add the following code snippet:

static const struct bt_data ad_min[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),
};

Copy

static const struct bt_data ad_min[] = {
	BT_DATA_BYTES(BT_DATA_FLAGS, BT_LE_AD_NO_BREDR),
};

7.2 Start advertising with the minimal advertising packet.

Comment out the line in main() with bt_le_adv_start() and add the following line to use the new, minimal advertising packet instead:

err = bt_le_adv_start(param, ad_min, ARRAY_SIZE(ad_min), NULL, 0);

Copy

err = bt_le_adv_start(param, ad_min, ARRAY_SIZE(ad_min), NULL, 0);

7.3 Build and flash the application to your DK.

In the Power Profiler, notice that the average consumption has now dropped to around 7 µA. This is because the radio is transmitting for shorter time, due to having less data to send because you reduced the size of the advertising packet. You can also see this if you zoom in to one of the advertising intervals. Notice that the spikes are now narrower than previously, because the radio is transmitting for a shorter time on each channel.

8. Observe the different advertising types.

Press a button on the DK to enable the different advertising types discussed in the previous topic:

Connectable & scannable
Connectable & non-scannable
Non-connectable & scannable
Non-connectable & non-scannable

Note

Introducing button pushes in the application is a way to easily switch between the different modes and compare. However, it also increases the average power consumption of the application, as button presses prevent the CPU from entering a low-power state.

8.1 Define the advertising parameters for connectable and non-connectable advertising.

Add the following code snippet:

#define APP_BT_LE_ADV_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONN, BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL)
#define APP_BT_LE_ADV_NONCONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE, BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL)

Copy

#define APP_BT_LE_ADV_CONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_CONN, BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL)
#define APP_BT_LE_ADV_NONCONN BT_LE_ADV_PARAM(BT_LE_ADV_OPT_NONE, BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL)

8.2 Define adv_type enumerator to keep track of advertising types.

enum adv_type {
	ADV_CONN_SCAN = 0, //connectable and scannable
	ADV_CONN = 1, //connectable
	ADV_NONCONN_SCAN = 2, //non-connectable, scannable
	ADV_NONCONN = 3, //non-connectable
	NONE = 4
};

Copy

enum adv_type {
	ADV_CONN_SCAN = 0, //connectable and scannable
	ADV_CONN = 1, //connectable
	ADV_NONCONN_SCAN = 2, //non-connectable, scannable
	ADV_NONCONN = 3, //non-connectable
	NONE = 4
};

8.3 Define a variable to keep track of the current advertising type.

static int current_adv_type = NONE;

Copy

static int current_adv_type = NONE;

8.4 Define the scan response.

When advertising in scannable mode, you must pass the scan response packet when starting the advertising.

Add the following code to declare the scan response packet:

static unsigned char url_data[] = { 0x17, '/', '/', 'a', 'c', 'a', 'd', 'e', 'm',
				    'y',  '.', 'n', 'o', 'r', 'd', 'i', 'c', 's',
				    'e',  'm', 'i', '.', 'c', 'o', 'm' };

static const struct bt_data sd[] = {
	BT_DATA(BT_DATA_URI, url_data, sizeof(url_data)),
};

Copy

static unsigned char url_data[] = { 0x17, '/', '/', 'a', 'c', 'a', 'd', 'e', 'm',
				    'y',  '.', 'n', 'o', 'r', 'd', 'i', 'c', 's',
				    'e',  'm', 'i', '.', 'c', 'o', 'm' };

static const struct bt_data sd[] = {
	BT_DATA(BT_DATA_URI, url_data, sizeof(url_data)),
};

8.5 Define the button_handler() function to enable different advertising types upon button presses.

When a button is pushed, the button handler should check that the current advertising type is not the one that is selected, then call bt_le_adv_stop() to stop advertising and use bt_le_adv_start() to start advertising with the selected type. Depending on whether the advertising is scannable or not, the fourth and fifth parameters of bt_le_adv_start() will be filled.

Add the following function definition to the application to define the button handler:

static void button_handler(uint32_t button_state, uint32_t has_changed)
{
	int err;
	uint32_t button = button_state & has_changed;

	if (button & DK_BTN1_MSK) {
		if (current_adv_type == ADV_CONN_SCAN) {
			return;
		}

		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
		if (err) {
			current_adv_type = NONE;
			return;
		}
		current_adv_type = ADV_CONN_SCAN;
	}

	if (button & DK_BTN2_MSK) {
		if (current_adv_type == ADV_CONN) {
			return;
		}
		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), NULL, 0);
		if (err) {
			current_adv_type = NONE;
			return;
		} 
		current_adv_type = ADV_CONN;
	}

	if (button & DK_BTN3_MSK) {
		if (current_adv_type == ADV_NONCONN_SCAN) {
			return;
		}
		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_NONCONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
		if (err) {
			current_adv_type = NONE;
			return;
		}
		current_adv_type = ADV_NONCONN_SCAN;
	}

	if (button & DK_BTN4_MSK) {
		if (current_adv_type == ADV_NONCONN) {
			return;
		}
		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_NONCONN, ad, ARRAY_SIZE(ad), NULL, 0);
		if (err) {
			current_adv_type = NONE;
			return;
		}
		current_adv_type = ADV_NONCONN;
	}
}

Copy

static void button_handler(uint32_t button_state, uint32_t has_changed)
{
	int err;
	uint32_t button = button_state & has_changed;

	if (button & DK_BTN1_MSK) {
		if (current_adv_type == ADV_CONN_SCAN) {
			return;
		}

		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
		if (err) {
			current_adv_type = NONE;
			return;
		}
		current_adv_type = ADV_CONN_SCAN;
	}

	if (button & DK_BTN2_MSK) {
		if (current_adv_type == ADV_CONN) {
			return;
		}
		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_CONN, ad, ARRAY_SIZE(ad), NULL, 0);
		if (err) {
			current_adv_type = NONE;
			return;
		} 
		current_adv_type = ADV_CONN;
	}

	if (button & DK_BTN3_MSK) {
		if (current_adv_type == ADV_NONCONN_SCAN) {
			return;
		}
		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_NONCONN, ad, ARRAY_SIZE(ad), sd, ARRAY_SIZE(sd));
		if (err) {
			current_adv_type = NONE;
			return;
		}
		current_adv_type = ADV_NONCONN_SCAN;
	}

	if (button & DK_BTN4_MSK) {
		if (current_adv_type == ADV_NONCONN) {
			return;
		}
		bt_le_adv_stop();
		err = bt_le_adv_start(APP_BT_LE_ADV_NONCONN, ad, ARRAY_SIZE(ad), NULL, 0);
		if (err) {
			current_adv_type = NONE;
			return;
		}
		current_adv_type = ADV_NONCONN;
	}
}

Notice the four different calls to bt_le_adv_start() depending on the advertising type you are configuring, using either APP_BT_LE_ADV_NONCONN or APP_BT_LED_ADV_CONN for non-connectable or connectable advertising, respectively, and passing the scan response packet bt_data sd for scannable advertising.

8.6 Register the button handler.

Add the following code snippet to register the button handler you defined:

err = dk_buttons_init(button_handler);
if (err) {
	return -1;
}

Copy

err = dk_buttons_init(button_handler);
if (err) {
	return -1;
}

8.7 Comment out the snippet with bt_le_adv_start() in main() so that you do not start advertising until a button is pressed.

8.8 Build and flash the application to your DK.

Press the different buttons on the DK and observe in the Power Profiler.

The following table presents measurements taken once for each advertising event using the PPK2 and the nRF54L15 DK.

The Power Profiler shows that the non-connectable advertising event is the shortest one and consumes the least amount of charge because the radio does not have to receive at all, since it neither has to listen for connection requests or scan requests, just transmit the advertising packet.

Button	Advertising type	Total charge	Time
Button 0	Connectable, scannable	6.94 µC	4.230 ms
Button 1	Connectable	6.93 µC	3.880 ms
Button 2	Non-connectable, scannable	6.93 µC	4.150 ms
Button 3	Non-connectable	5.62 µC	3.250 ms

Bluetooth LE PHY: 1 M

TX Power: 0 dBm

Data:

Advertising Data: ad[]

AD Structure	Length Byte	Type Byte	Data	Subtotal
Flags	`0x02` (2)	`0x01` (FLAGS)	`0x04` (NO_BREDR) — 1 byte	3 bytes
Complete Name	`0x0E` (14)	`0x09` (NAME_COMPLETE)	`Nordic_Beacon` — 13 bytes	15 bytes
				Total: 18 bytes

Scan Response Data: sd[]

Structure	Length Byte	Type Byte	Data	Subtotal
URI	`0x1A` (26)	`0x24` (URI)	`url_data` — 25 bytes	27 bytes
				Total: 27 bytes

Connectable, scannable

Connectable

Non-connectable, scannable

Non-connectable

9. Enable and configure extended advertising.

Enabling extended advertising uses a different API and the method is slightly different.

9.1 Enable extended advertising in the prj.conf file.

Add the following lines to prj.conf to enable the extended advertising libraries in the application and set the maximum extended advertising data length to 255.

CONFIG_BT_EXT_ADV=y
CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=255

Copy

CONFIG_BT_EXT_ADV=y
CONFIG_BT_CTLR_ADV_DATA_LEN_MAX=255

Kconfig

9.2 Define the advertising parameters for extended advertising.

You are still using BT_LE_ADV_PARAM() as before, and setting the option for extended advertising: BT_LE_ADV_OPT_EXT_ADV.

Add the following line:

#define APP_BT_LE_EXT_ADV_PARAM BT_LE_ADV_PARAM(BT_LE_ADV_OPT_EXT_ADV, \
                          BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL)

Copy

#define APP_BT_LE_EXT_ADV_PARAM BT_LE_ADV_PARAM(BT_LE_ADV_OPT_EXT_ADV, \
                          BT_GAP_ADV_SLOW_INT_MIN, BT_GAP_ADV_SLOW_INT_MAX, NULL)

9.3 Declare the callback struct.

You must declare a callback structure bt_le_ext_adv_cb to pass to the function creating the advertising set, but leave it empty.

Add the following code snippet:

const static struct bt_le_ext_adv_cb adv_callbacks = {};

Copy

const static struct bt_le_ext_adv_cb adv_callbacks = {};

9.4 Create the advertising set and start extended advertising.

Declare the advertising set of type bt_le_ext_adv and pass it to bt_le_ext_adv_create(), along with the advertising parameter and callback you defined in previous steps.

Then set the advertising set’s advertising data, by passing it to bt_le_ext_adv_set_data(), along with the advertising packet ad_ext. The extended advertising packet is defined in the ad_ext_data.c file in the src folder and is 255 bytes long.

Start extended advertising using bt_le_ext_adv_start().

Add the following code snippet in main():

static struct bt_le_ext_adv *adv_set;

err = bt_le_ext_adv_create(APP_BT_LE_EXT_ADV_PARAM, &adv_callbacks, &adv_set);
if (err) {
	return 0;
}

err = bt_le_ext_adv_set_data(adv_set, ad_ext, ad_ext_size, NULL, 0);
if (err) {
	return 0;
}

err = bt_le_ext_adv_start(adv_set, BT_LE_EXT_ADV_START_DEFAULT);
if (err) {
	return 0;
}

Copy

static struct bt_le_ext_adv *adv_set;

err = bt_le_ext_adv_create(APP_BT_LE_EXT_ADV_PARAM, &adv_callbacks, &adv_set);
if (err) {
	return 0;
}

err = bt_le_ext_adv_set_data(adv_set, ad_ext, ad_ext_size, NULL, 0);
if (err) {
	return 0;
}

err = bt_le_ext_adv_start(adv_set, BT_LE_EXT_ADV_START_DEFAULT);
if (err) {
	return 0;
}

9.5 Build and flash the application to your DK.

In the Power Profiler, zoom in to one of the advertising events and notice that the device is now sending on the three channels as usual, but it is only sending the header of the advertising packet. The last spike is the radio sending the extended advertising data on a secondary channel.

Nordic Developer Academy Terms of Service

1. Introduction

‍These terms and conditions (“Terms of Use”) apply to the use of the Nordic Developer Academy, provided by Nordic Semiconductor ASA, org. nr. 966 011 726, a public limited liability company registered in Norway (“Nordic Semiconductor”). ‍

Nordic Developer Academy allows the user to take technical courses related to Nordic Semiconductor products, software and services, and obtain a certificate certifying completion of these courses. By completing the registration process for the Nordic Developer Academy, you are agreeing to be bound by these Terms of Use.

These Terms of Use are applicable as long as you have a user account giving you access to Nordic Developer Academy.‍

‍2. Access to and use of Nordic Developer Academy

‍‍Upon acceptance of these Terms of Use you are granted a non-exclusive right of access to, and use of Nordic Developer Academy, as it is provided to you at any time. Nordic Semiconductor provides Nordic Developer Academy to you free of charge, subject to the provisions of these Terms of Use and the Nordic Developer Academy Privacy Policy.

To access select features of Nordic Developer Academy, you need to create a user account. You are solely responsible for the security associated with your user account, including always keeping your login details safe.

You will able to receive an electronic certificate from Nordic Developer Academy upon completion of courses. By issuing you such a certificate, Nordic Semiconductor certifies that you have completed the applicable course, but does not provide any further warrants or endorsements for any particular skills or professional qualifications.

Nordic Semiconductor will continuously develop Nordic Developer Academy with new features and functionality, but reserves the right to remove or alter any existing functions without notice.

‍3. Acceptable use

You undertake that you will use Nordic Developer Academy in accordance with applicable law and regulations, and in accordance with these Terms of Use.‍ You must not modify, adapt, or hack Nordic Developer Academy or modify another website so as to falsely imply that it is associated with Nordic Developer Academy, Nordic Semiconductor, or any other Nordic Semiconductor product, software or service.

You agree not to reproduce, duplicate, copy, sell, resell or in any other way exploit any portion of Nordic Developer Academy, use of Nordic Developer Academy, or access to Nordic Developer Academy without the express written permission by Nordic Semiconductor. You must not upload, post, host, or transmit unsolicited email, SMS, or \”spam\” messages.

You are responsible for ensuring that the information you post and the content you share does not;

contain false, misleading or otherwise erroneous information
infringe someone else’s copyrights or other intellectual property rights
contain sensitive personal data or
contain information that might be received as offensive or insulting.
Such information may be removed without prior notice.

‍Nordic Semiconductor reserves the right to at any time determine whether a use of Nordic Developer Academy is in violation of its requirements for acceptable use.

Violation of the at any time applicable requirements for acceptable use may result in termination of your account. We will take reasonable steps to notify you and state the reason for termination in such cases.

‍4. Routines for planned maintenance

‍Certain types of maintenance may imply a stop or reduction in availability of Nordic Developer Academy. Nordic Semiconductor does not warrant any level of service availability but will provide its best effort to limit the impact of any planned maintenance on the availability of Nordic Developer Academy.

5. Intellectual property rights

‍Nordic Semiconductor retains all rights to all elements of Nordic Developer Academy. This includes, but is not limited to, the concept, design, trademarks, know-how, trade secrets, copyrights and all other intellectual property rights.

Nordic Semiconductor receives all rights to all content uploaded or created in Nordic Developer Academy. You do not receive any license or usage rights to Nordic Developer Academy beyond what is explicitly stated in this Agreement.

‍6. Liability and damages

‍Nothing within these Terms of Use is intended to limit your statutory data privacy rights as a data subject, as described in the Nordic Developer Academy Privacy Policy. ‍You acknowledge that errors might occur from time to time and waive any right to claim for compensation as a result of errors in Nordic Developer Academy. When an error occurs, you shall notify Nordic Semiconductor of the error and provide a description of the error situation.

You agree to indemnify Nordic Semiconductor for any loss, including indirect loss, arising out of or in connection with your use of Nordic Developer Academy or violations of these Terms of Use. ‍Nordic Semiconductor shall not be held liable for, and does not warrant that (i) Nordic Developer Academy will meet your specific requirements, (ii) Nordic Developer Academy will be uninterrupted, timely, secure, or error-free, (iii) the results that may be obtained from the use of Nordic Developer Academy will be accurate or reliable, (iv) the quality of any products, services, information, or other material purchased or obtained by you through Nordic Developer Academy will meet your expectations, or that (v) any errors in Nordic Developer Academy will be corrected.

You accept that this is a service provided to you without any payment and hence you accept that Nordic Semiconductor will not be held responsible, or liable, for any breaches of these Terms of Use or any loss connected to your use of Nordic Developer Academy. Unless otherwise follows from mandatory law, Nordic Semiconductor will not accept any such responsibility or liability.

‍7. Change of terms

‍Nordic Semiconductor may update and change the Terms of Use from time to time. Nordic Semiconductor will seek to notify you about significant changes before such changes come into force and give you a possibility to evaluate the effects of proposed changes. Continued use of Nordic Developer Academy after any such changes shall constitute your acceptance of such changes. You can review the current version of the Terms of Use at any time at https://academy.nordicsemi.com/terms-of-service/

‍8. Transfer of rights

‍Nordic Semiconductor is entitled to transfer its rights and obligation pursuant to these Terms of Use to a third party as part of a merger or acquisition process, or as a result of other organizational changes.

‍9. Third Party Services

‍‍To the extent Nordic Developer Academy facilitates access to services provided by a third party, you agree to comply with the terms governing such third party services. Nordic Semiconductor shall not be held liable for any errors, omissions, inaccuracies, etc. related to such third party services.

‍10. Dispute resolution

‍‍The Terms of Use and any other legally binding agreement between yourself and Nordic Semiconductor shall be subject to Norwegian law and Norwegian courts’ exclusive jurisdiction.

Designing Low-Power Bluetooth LE Products

Exercise 1 – Optimizing power consumption during Bluetooth LE advertising

Exercise steps

Note

Note

Note

Connectable, scannable

Connectable

Non-connectable, scannable

Non-connectable

Switch language?

Change summary

What's new in the latest version

General updates

Bluetooth LE updates

MCUboot & Partition Manager