In this exercise, you establish a connection between your Nordic DK and your smart phone, using the nRF Connect for Mobile application. Then you experiment with different connection parameters discussed in Bluetooth LE connection parameters and power consumption and observe how they change the power consumption of the application.

Exercise steps

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

1. Build and flash the application to your DK.

1.1 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.

2. Set up the power measurement.

2.1 Connect the Power Profiler Kit II to your DK as you did in the previous exercise.  

2.2 Open and configure the Power Profiler.

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

In the Power Profiler, you should see the DK advertising with an advertising interval of 1 – 1.2 s.

3. Establish a connection to your Nordic board.

3.1. Download and open the nRF Connect for Mobile application on your smart phone.

3.2 In the nRF Connect for Mobile app, tap the Play/SCAN icon, in the upper right corner. Your smartphone will now act as a central device, scanning for any Bluetooth LE devices that are advertising in its presence.

3.3 Several Bluetooth-enabled devices around you start appearing.

Choose the one called DevAcademy_L4E2and tap Connect.

Observe the connection in the Power Profiler application. Note a connection interval of around 30 ms, consuming on average around 74 uA.

4. Configure the preferred connection parameters.

Change the connection parameters, particularly the connection interval, to be much slower, to reduce the power consumption on your peripheral device (your Nordic DK).

Although the central ultimately determines the connection parameters, the peripheral can send a connection parameter update request to the central. The central can then choose to accept or reject.

Enabling the Kconfig option CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS will automatically send a connection parameter update request five seconds after the connection is established. The time is determined by the CONFIG_BT_CONN_PARAM_UPDATE_TIMEOUT Kconfig option that has a default value of 5000 ms.

Since the CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS Kconfig option is already enabled by default, you just need to set the preferred connection parameters.

Add the following lines to the prj.conf file:

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=800
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=800
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=400

CONFIG_BT_PERIPHERAL_PREF_MIN_INT=800
CONFIG_BT_PERIPHERAL_PREF_MAX_INT=800
CONFIG_BT_PERIPHERAL_PREF_LATENCY=0
CONFIG_BT_PERIPHERAL_PREF_TIMEOUT=400

• CONFIG_BT_PERIPHERAL_PREF_MIN_INT and CONFIG_BT_PERIPHERAL_PREF_MAX_INT set the peripheral preferred minimum and maximum connection interval (in 1.25 ms units). Set this value to one second (800 * 1.25) to see activity between the connection intervals, and to decrease the overall power consumption.
• CONFIG_BT_PERIPHERAL_PREF_LATENCY sets the peripheral preferred connection latency (peripheral latency).
• CONFIG_BT_PERIPHERAL_PREF_TIMEOUT sets the peripheral preferred supervision timeout (in 10 ms units).

5. Build and flash the application to your DK.

Build and flash the updated application to your DK.

6. Establish a connection to your Nordic board.

In the nRF Connect for Mobile application, scan for devices and connect to your Nordic DK, just like in the previous step.

Observe the connection in the Power Profiler application. Notice that the connection begins with the same connection interval as before, 30 ms. After around five seconds, the connection parameter update request is sent and the connection events are less frequent.

The connection interval should now be one second and the application should be drawing around 5-6 µA, a decrease of 92% from the previous.

7. Define functions to update the data length and MTU.

Increase the MTU size without increasing the data length to observe what happens to the transmitted data packet.

7.1 Enable updating data length and MTU.

Add the following lines to the prj.conf file:

CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=247

CONFIG_BT_GATT_CLIENT=y
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_BUF_ACL_TX_SIZE=251
CONFIG_BT_BUF_ACL_RX_SIZE=251
CONFIG_BT_L2CAP_TX_MTU=247

• CONFIG_BT_GATT_CLIENT enables support for the GATT Client role. This is enabled to allow the peripheral to initiate an MTU exchange with the central device. Even though this is a peripheral (GATT Server), it needs the GATT Client API to call that specific function bt_gatt_exchange_mtu().
• CONFIG_BT_USER_DATA_LEN_UPDATE enables the application to initiate the Data Length Update Procedure.
• CONFIG_BT_CTLR_DATA_LENGTH_MAX sets the maximum data length of PDU supported to 251.
• CONFIG_BT_BUF_ACL_TX_SIZE sets the maximum supported ACL size of data packets sent from host to controller to 251.
• CONFIG_BT_BUF_ACL_RX_SIZE sets the maximum supported ACL size of data packets sent from controller to host to 251.
• CONFIG_BT_L2CAP_TX_MTU sets the maximum L2CAP MTU for L2CAP TX buffers to 247 (251 – 4 bytes for the header).

7.2 Define the function to request a data length update.

Update the connection transmit data length parameters using bt_conn_le_data_len_update(). Set the number of bytes and the amount of time to the maximum, by using the defined values BT_GAP_DATA_LEN_MAX and BT_GAP_DATA_TIME_MAX, which are set to 251 bytes and 17040 µs, respectively.

static void request_data_len_update(struct bt_conn *conn)
{
    int err;
    struct bt_conn_le_data_len_param my_data_len = {
        .tx_max_len = BT_GAP_DATA_LEN_MAX,
        .tx_max_time = BT_GAP_DATA_TIME_MAX,
    };
    
    err = bt_conn_le_data_len_update(current_conn, &my_data_len);
    if (err) {
        return;
    }
}

static void request_data_len_update(struct bt_conn *conn)
{
    int err;
    struct bt_conn_le_data_len_param my_data_len = {
        .tx_max_len = BT_GAP_DATA_LEN_MAX,
        .tx_max_time = BT_GAP_DATA_TIME_MAX,
    };
    
    err = bt_conn_le_data_len_update(current_conn, &my_data_len);
    if (err) {
        return;
    }
}

7.3 Define the function to request an MTU exchange.

After the connection is established, initiate an MTU exchange with the central to negotiate the highest possible MTU size supported by both sides. Use the bt_gatt_exchange_mtu() function.

7.3.1 Create the variable that holds the callback for MTU negotiation.

Add the following lines:

static struct bt_gatt_exchange_params exchange_params;
static void exchange_func(struct bt_conn *conn, uint8_t att_err, struct bt_gatt_exchange_params *params){};

static struct bt_gatt_exchange_params exchange_params;
static void exchange_func(struct bt_conn *conn, uint8_t att_err, struct bt_gatt_exchange_params *params){};

7.3.2 Define the function request_mtu_exchange() to initiate an MTU exchange.

static void request_mtu_exchange(struct bt_conn *conn)
{
    int err;
    exchange_params.func = exchange_func;

    err = bt_gatt_exchange_mtu(current_conn, &exchange_params);
    if (err) {
        return;
    }
}

static void request_mtu_exchange(struct bt_conn *conn)
{
    int err;
    exchange_params.func = exchange_func;

    err = bt_gatt_exchange_mtu(current_conn, &exchange_params);
    if (err) {
        return;
    }
}

8. Upon a successful connection, request only an MTU exchange.

Request only an MTU exchange but not a data length update to see what happens to the radio packets when the MTU is larger than the data length.

Add the following line in connected():

request_mtu_exchange(current_conn);

request_mtu_exchange(current_conn);

9. Send a data packet intermittently.

Configure the application to send a data packet every 900 ms using a timer.

9.1 Define a large data packet.

Add the following lines:

uint8_t large_data[244] =
    "a_NordicSemiconductor_NUS_LargePacket_ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
    "abcdefghijklmnopqrstuvwxyz_0123456789_ABCDEFGHIJKLMNOPQRSTUVWXYZ_ab"
    "cdefghijklmno_0123456789_ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
    "Nordic_Developer_Academy_NordicSemiconductor_EndOfPacket";

uint8_t large_data[244] =
    "a_NordicSemiconductor_NUS_LargePacket_ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
    "abcdefghijklmnopqrstuvwxyz_0123456789_ABCDEFGHIJKLMNOPQRSTUVWXYZ_ab"
    "cdefghijklmno_0123456789_ABCDEFGHIJKLMNOPQRSTUVWXYZ_"
    "Nordic_Developer_Academy_NordicSemiconductor_EndOfPacket";

9.2 Define a function to send a large data packet over NUS.

Use bt_nus_send() to send the large data packet. Increment the first character of the data packet to observe from the central that it is in fact sending new packets.

Add the following code snippet:

static void send_large_data(struct k_timer *timer)
{
     large_data[0]++;
     if (large_data[0] > 'z') {
          large_data[0] = 'a';
     }
 
     if (bt_nus_send(current_conn, large_data, sizeof(large_data))) {
       return;
     }
}

static void send_large_data(struct k_timer *timer)
{
     large_data[0]++;
     if (large_data[0] > 'z') {
          large_data[0] = 'a';
     }
 
     if (bt_nus_send(current_conn, large_data, sizeof(large_data))) {
       return;
     }
}

9.3 Define the timer loop_restart_timer, with the expiry function being the function to send data that was defined in the previous step.

Add the following lines in the main.c file:

static void send_large_data(struct k_timer *timer);
K_TIMER_DEFINE(loop_restart_timer, send_large_data, NULL);

static void send_large_data(struct k_timer *timer);
K_TIMER_DEFINE(loop_restart_timer, send_large_data, NULL);

9.4 Start the timer to begin sending data packets.

You cannot start sending packets to the central before it has subscribed to notifications, in which case bt_notif_enabled_cb will be called.

Start the timer only when notifications are enabled by the central, and stop the timer if notifications are disabled.

Add the following code snippet to bt_notif_enabled_cb:

switch (status) 
{
    case BT_NUS_SEND_STATUS_ENABLED:
        k_timer_start(&loop_restart_timer, K_NO_WAIT, K_MSEC(LOOP_PERIOD_MS));
        break;
    case BT_NUS_SEND_STATUS_DISABLED:
        k_timer_stop(&loop_restart_timer);
        break;
    break;
}

switch (status) 
{
    case BT_NUS_SEND_STATUS_ENABLED:
        k_timer_start(&loop_restart_timer, K_NO_WAIT, K_MSEC(LOOP_PERIOD_MS));
        break;
    case BT_NUS_SEND_STATUS_DISABLED:
        k_timer_stop(&loop_restart_timer);
        break;
    break;
}

LOOP_PERIOD_MS is set to 900 ms to queue/prepare the packet for sending every 900 ms. Packets are sent at the connection interval.

10. Build and flash the application to your DK.

Build and flash the updated application to your DK.

Ignore the build warning: request_data_len_update is defined but not used.

• Android
• iOS

11. Establish a connection to your Nordic board.

11.1 In the nRF Connect for Mobile application, scan for devices and connect to your Nordic DK, just like in the previous step.

Observe the connection in the Power Profiler application. Notice that the connection begins with the same connection interval as before, 30 ms. But after around five seconds, the connection parameter update request is sent and the connection events are less frequent.

11.2 Subscribe to notifications.

To subscribe to notifications from the peripheral, tap on the three arrow symbol next to the TX Characteristic.

11.3 Observe the connection in the Power Profiler application.

Switch back to the Power Profiler application and observe the connection. The average power consumption is around 20 µA.

Zoom into one of the connection events. Observe that the packet has now been split into several small chunks, so the radio is switching between TX and RX several times during a single data transmission.

This is because the MTU is set to 244 bytes while the data length is still the default 27 bytes, so the package is split into 27-byte chunks to be sent over the air.

When notifications are enabled, the following two activities occur:

• The smaller pulse (~2.5 mA) is the CPU waking up to process the timer expiry (loop_restart_timer) and queuing the notification data. This is purely CPU processing. No radio is involved.
• The larger pulse (~5mA) is the actual radio connection event where the notification packet is transmitted over the air to the central. This involves powering up the radio, transmitting the data, and receiving the link-layer ACK.

11. Establish a connection to your Nordic board using the Bluetooth Low Energy app.

Using the nRF Connect for Mobile application as the central in these steps will not give the desired result, as the central will automatically update the data length and the PHY to improve efficiency.

Instead, use the Bluetooth Low Energy application in the nRF Connect for Desktop, and any of the development kits nRF52840 DK, nRF52840 Dongle or nRF52 DK as the Bluetooth LE radio for your computer.

11.1 Install and launch the Bluetooth Low Energy application from the nRF Connect for Desktop.

11.2 Click Select Device in the upper left corner and select your second DK.

Make sure it is plugged into your computer and turned on.

For the nRF52840 Dongle, make sure to put it into DFU mode first by pressing the RESET button that is on the far side of the board from the USB connector. Push it from the outside in, towards the USB connector.

The RGB light turns red with a fade pattern, indicating that the dongle is in DFU mode.

11.3 Program the device.

Click Yes in the prompt that pops up to program the device with the correct firmware

11.4 Start scanning and connect to the peripheral.

Under Discovered devices, select Start scan and connect to DevAcademy_L4E2 when it shows up.

Observe the connection in the Power Profiler application. Notice that the connection begins with the same connection interval as before, 30 ms. After around five seconds, the connection parameter update request is sent and the connection events are less frequent.

11.5 Subscribe to notifications.

Subscribe to notifications from the peripheral, so that it can begin sending packets.

In the rows under DevAcademy_L4E2, click on UART over BLE and then click the Play icon next to UART TX.

11.6 Observe the connection in the Power Profiler application.

Switch back to the Power Profiler application and observe the connection. The average power consumption is around 20 µA.

Zoom into one of the connection events. Observe that the packet has now been split into several small chunks, so the radio is switching between TX and RX several times during a single data transmission.

This is because the MTU is set to 244 bytes while the data length is still the default 27 bytes, so the package is split into 27-byte chunks to be sent over the air.

When notifications are enabled, the following two activities occur:

• The smaller pulse (~2.5 mA) is the CPU waking up to process the timer expiry (loop_restart_timer) and queuing the notification data. This is purely CPU processing. No radio is involved.
• The larger pulse (~5mA) is the actual radio connection event where the notification packet is transmitted over the air to the central. This involves powering up the radio, transmitting the data, and receiving the link-layer ACK.

11.7 Disconnect from the peripheral before proceeding.

Before proceeding to the next step, click on the cogwheel next to DevAcademy_L4E2 and select Disconnect to disconnect from the device.

Enable the Data Length Extension and observe how it improves the power consumption.

12. Upon a successful connection, request a data length update.

Add the following line in connected() to request a data length update upon a successful connection:

request_data_len_update(current_conn);

request_data_len_update(current_conn);

13. Build and flash the application to your DK.

Build and flash the updated application to your DK.

14. Establish a connection to your Nordic board.

In the Bluetooth Low Energy application, start scanning for devices, connect to DevAcademy_L4E2, and subscribe to notifications just like in Step 11.

Switch back to the Power Profiler application and zoom into one of the connection events.

The connection event now takes around five seconds because the full packet can be sent in one transmission and consumes around 13 µC charge.

The highest cost with the link layer packet size set to 27 (without Data Length Extension) is not just extra header bytes; it is the radio on-time. Each LL packet requires a TX (data) and RX (ACK) event with 150 µs Inter Frame Space (IFS) between them. Without DLE, you get 10 TX/RX pairs instead of one, resulting in ~10× the radio active time for each notification, clearly visible as ~10 peak groups on the PPK2 seen in Step 11.6.

When you observe the full connection, the average power consumption is around 13 µA, a 35% decrease from before, by increasing the data length.

If you select just the TX part, it takes about two ms to transmit the full packet.

15. Request a PHY update to 2M PHY.

The base code of this exercise has the PHY request enabled already, to request a 1M PHY upon a connection for educational purposes. This is because some centrals (specifically nRF Connect for Mobile on iOS) will negotiate a 2M PHY to optimize the connection without the peripheral requesting it.

In the prj.conf file, the CONFIG_BT_USER_PHY_UPDATE Kconfig option is enabled, which allows the application to initiate the PHY update procedure. Note that the CONFIG_BT_AUTO_PHY_UPDATE option is enabled by the stack by default (unless CONFIG_BT_USER_PHY_UPDATE is enabled, which it is in this case), and will initiate the PHY update procedure on a connection establishment.

In the main.c file, with the function request_phy_update(), you request a PHY update using bt_conn_le_phy_update(). In this case, with the preferred PHY to 1 M.

Set the preferred TX and RX PHY to 2M PHY through pref_rx_phy and pref_tx_phy.

Replace the two lines with the following in request_phy_update():

.pref_rx_phy = BT_GAP_LE_PHY_2M,
.pref_tx_phy = BT_GAP_LE_PHY_2M,

.pref_rx_phy = BT_GAP_LE_PHY_2M,
.pref_tx_phy = BT_GAP_LE_PHY_2M,

Upon a successful connection, this function is called from connected() to request a PHY update.

16. Build and flash the application to your DK.

Build and flash the updated application to your DK.

17. Establish a connection to your Nordic board.

In the nRF Connect for Mobile (Android) or the Bluetooth Low Energy application (iOS), start scanning for devices, connect to DevAcademy_L4E2, and subscribe to notifications just like previously.

Switch back to the Power Profiler application and zoom into one of the connection events.

The data transmission now takes around one second with 2M PHY, instead of two seconds with 1M PHY. Because the throughput doubled, the time it takes to transmit the same amount of bytes is cut in half.

Looking at the full connection, the average power consumption is also reduced to around 13 µA.