Feedback

Bluetooth LE connection parameters and power consumption

This section shows how Bluetooth LE connection parameters can affect the total power consumption of an application.

The focus is on a Bluetooth LE ACL connection, which is the standard link used for data exchanged between a central and a peripheral. Since Nordic devices are mostly used as peripherals, minimizing the power consumption from the peripheral point of view is the main topic.

Keep in mind that before a connection can be established, the peripheral must advertise. The techniques discussed in the previous lesson also apply here.

Bluetooth LE connection (ACL connection)

A Bluetooth LE connection provides a bidirectional communication channel between the peripheral and the central. They exchange packets during connection events at a defined interval, and sleep between connection events. Both the peripheral and central can connect to multiple devices at the same time (up to 20).

Connection interval

The connection interval determines how often the devices wake up during the connection to exchange data packets. A long connection interval decreases the overall power consumption by minimizing the radio activity, but will in turn lower the data speed and increase latency.

It is expressed in 1.25 ms units, so for example 0x0018 = 24 and 24 * 1.25 = 30 ms.

Connection latency (peripheral latency)

The connection latency (often called peripheral latency) determines how many consecutive connection events the peripheral is allowed to skip without the connection being considered lost. A higher connection latency saves power, while increasing the worst-case response time.

It is expressed as a number of connection intervals, so for example, a connection latency of 3 means that the peripheral can skip up to three connection events and only respond on the fourth one, while keeping the connection alive.

Supervision timeout

The supervision timeout determines the maximum amount of time allowed between two data packets before the connection is considered lost. A short supervision timeout gives you faster detection of a lost connection, but leaves the application prone to accidental disconnections. A long supervision timeout leads to a more stable connection but detecting a truly disconnected device is slower.

It is expressed in 10 ms units, so for example, a supervision timeout of 40 * 10 = 400 ms.

Configuring connection parameters

In a Bluetooth LE connection, the central sets the connection interval, connection latency, and supervision timeout when establishing a connection with the peripheral. During the connection, the peripheral can request changes to the connection parameters, but it is ultimately up to the central to accept or reject the change.

The following code example shows how to request different connection parameters from the peripheral, using bt_conn_le_param_update().

Use the helper macro BT_LE_CONN_PARAM() that takes the following four parameters:

int_min: 30 ms through BT_GAP_INIT_CONN_INT_MIN
int_max: 50 ms through BT_GAP_INIT_CONN_INT_MAX
lat: 0
to: 4 s through 400

static struct bt_le_conn_param *conn_param = BT_LE_CONN_PARAM(BT_GAP_INIT_CONN_INT_MIN, \
                                              BT_GAP_INIT_CONN_INT_MAX, 0, 400);

int err = bt_conn_le_param_update(current_conn, conn_param);
if (err) {
  LOG_ERR("Cannot update connection parameter (err: %d)", err);
  return err;
}
LOG_INF("Connection parameters update requested");

Copy

static struct bt_le_conn_param *conn_param = BT_LE_CONN_PARAM(BT_GAP_INIT_CONN_INT_MIN, \
                                              BT_GAP_INIT_CONN_INT_MAX, 0, 400);

int err = bt_conn_le_param_update(current_conn, conn_param);
if (err) {
  LOG_ERR("Cannot update connection parameter (err: %d)", err);
  return err;
}
LOG_INF("Connection parameters update requested");

PHY

PHY refers to the physical layer of the Bluetooth LE specification, defining different modulation and coding schemes that affect throughput, battery consumption, and communication range.

1 M PHY: Classic PHY supported by all Bluetooth LE devices with a throughput of one megabit in a second.
2 M PHY: Introduced in Bluetooth 5.0 with optional support. Doubles the data rate to two megabits in a second, meaning that the radio can stay on for less time, reducing power consumption. The tradeoff is slightly reduced receiver sensitivity and shorter range.
Coded PHY: Introduced in Bluetooth 5.0 with optional support. Enables longer range, but with significantly lower data throughput.

Since 2 M PHY transmits the same data in roughly half the time compared with 1 M PHY, this translates to reducing the power consumption by 50%.

Coded PHY increases the time on air, which means higher power consumption for each unit of data transferred.

TX output power

In the prj.conf file of the application, select the appropriate Kconfig option CONFIG_BT_CTLR_TX_PWR_MINUS_<X> or CONFIG_BT_CTLR_TX_PWR_PLUS_<X>.

See CONFIG_BT_CTLR_TX_PWR for the full list of choices.

Note: The supported range varies by board. On the nRF54L15 DK, it is -8 to +8 dBm.

For example, to set +5 dBm:

CONFIG_BT_CTLR_TX_PWR_PLUS_5=y

Copy

CONFIG_BT_CTLR_TX_PWR_PLUS_5=y

Kconfig

You can also set the TX output power at runtime. However, this is outside the scope of this course.

Connection subrating

Connection subrating is a Bluetooth LE feature introduced in Bluetooth 5.3, which enables fast switching between low and high duty cycle connections without changing the connection parameters directly. Before this feature was introduced, changing the duty cycle required a connection update procedure, which could take a while. With connection subrating, the switch happens immediately and dynamically.

Connection subrating introduces a parameter called the subrate factor, which allows both devices to skip a set number of connection events when there is no data to send.

Subrate factor: Specifies which connection events are effective. For example, a subrate factor of 10 in a connection interval of 10ms, means the central and peripheral will skip 9 empty connection events and only exchange packet every 100 ms (every 10th connection event).

So unlike permanently changing the connection interval, if the central or peripheral suddenly has burst data to send, they can instantly drop the subrate factor and resume communication at 10 ms intervals, without having to negotiate a new connection parameter update.

Continuation number: Defines how many additional underlying connection events the devices remain active for, after exchanging a Link Layer PDU with a non-zero length field. So a continuation number of 0 means the devices always skip the next subrated event, even if data was just exchanged, meaning no burst capability. While having a higher number means devices can remain active for more consecutive connection events after a data exchange, enabling longer bursts of data.

GATT operation

GATT operation types also have a significant impact on power consumption due to their different acknowledgement requirements.

Notifications vs. Indications

Notifications do not require an acknowledgement from the client. This means that the server can send multiple notifications for each connection event, maximizing the throughput and minimizing the time the radio needs to stay active.
Indications require a confirmation packet from the client before the next indication can be sent. This means that only one indication can be sent every two connection events (one to send, one to receive the acknowledgement), effectively halving the throughput and keeping the radio active longer for the same amount of data.

Prefer Notifications over Indications for server-to-client data.

Write Commands vs. Write Requests

Write Commands (write without response) require no acknowledgement, so up to six packets can be sent for each connection event, similar to notifications.
Write Requests require a response from the server before the next request can be sent. For example, at a 7.5 ms connection interval, only one packet can be sent every 15 ms, drastically reducing the throughput and increasing the time the radio must remain active to complete the same transfer.

Prefer Write Commands over Write Requests for client-to-server data.

Packet size optimization

The data length and MTU (Maximum Transfer Unit) are two different parameters that often go hand in hand.

MTU: The number of bytes that can be sent in one GATT operation (for example, a send operation). The default size is 23 bytes.

Data length: The Link Layer (LL) packet size that is the number of bytes that can be sent in one Bluetooth LE packet. The default size is 27 bytes.

When the MTU is larger than data length the data will be segmented into chunks of the data length’s size. This means that, for your application, it appears like one message is being sent, but on the air, the data is actually split into smaller packets, which is not ideal as it increases the radio active time.

Data Length Extension (DLE) was introduced in Bluetooth 4.2. It enables the data length to be increased from the default 27 bytes to up to 251 bytes. This made it easier to send all your data in one packet, reducing the radio active time. Packing everything together also reduces the number of bytes you need to transmit over the air, as every packet includes a three-byte header.

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

Bluetooth LE connection parameters and power consumption

Bluetooth LE connection (ACL connection)

Connection interval

Connection latency (peripheral latency)

Supervision timeout

Configuring connection parameters

PHY

TX output power

Connection subrating

GATT operation

Notifications vs. Indications

Write Commands vs. Write Requests

Packet size optimization

Switch language?

Change summary

What's new in the latest version

General updates

Bluetooth LE updates

MCUboot & Partition Manager