4.2.2 BLE Throughput

This document describes in detail the example of PIC32CXBZ3/WBZ35 BLE throughput evaluation using Microchip MBD APP and the factors affecting the BLE throughput.

Introduction

The purpose of this document is to illustrate the BLE_THROUGHPUT Application for PIC32CXBZ3/WBZ35. The BLE_THROUGHPUT Application is designed to demonstrate several functionalities including:

Note: 0xFEDA is a 16-bit Service UUID which is purchased by Microchip from Bluetooth SIG.

Scan Response Data

The device name is put in the scan response. the device name is set as "BLE_UART_XXXX". (XXXX are the last two bytes of the device address.)

Supported Services and Profiles

The supported service and profile are listed in the following section.

Profiles

• Transparent Profile (TRP)

  MCHP proprietary profile, see Reference [4] for the detail.

  LED Indication

Scanning and Connecting the Device

The steps to scan and connect to the device via MBD app are described as follows:

• Tap "BLE UART" in MBD App

• Tap PIC32CXBZ

• Tap "START"

• Tap "BLE_UART_XXXX" (XXXX are the last two bytes of the device address)

- Firmware Version

After LE is connected, tap the setting button:

The firmware version is displayed as the following image:

Select Transparent Profile

There are two profiles supported by the MBD "BLE UART" APP but "BLE_THROUGHPUT" firmware supports TRP only.

1. Legacy Transparent Profile (TRP)

   This is supported by "BLE_THROUGHPUT" firmware.

2. Transparent Credit Based Profile (TRCBP)

   This is NOT supported by "BLE_THROUGHPUT" firmware.

Select GATT WriteType

TRP profile supports both "Write with Response" and "Write without Response", which is much higher than the former.

Demo Modes

There are two demo modes: Burst Mode and Text Mode. Burst Mode is designed for the throughput evaluation via massive data transmission. Text Mode is designed for the simple text typing.

Burst Mode

There are four data transfer modes supported in Burst Mode:

1. Checksum mode

   MBD App to the device (Uni-direction).

2. Fixed pattern mode

   Device to MBD App (Uni-direction).

3. Loopback mode

   MBD App → Device → MBD App (Bi-direction).

4. UART mode

   MBD App → Device → UART output to PC ; UART input from PC → Device → MBD App (Bi-direction). This mode is NOT supported by "BLE THROUGHPUT" firmware.

B. Text Mode

There are two data transfer modes supported in Text Mode:

1. Loopback mode

   MBD App → Device → MBD App (Bi-direction).

2. UART mode

   MBD App → Device → UART output. This mode is NOT supported by "BLE THROUGHPUT" firmware.

Work with Android MBD App

The operation of Android MBD App is quite the same as the iOS version MBD App.

Throughput Evaluation

In this section, we will describe the throughput evaluation steps and a list of throughput figures tested with a list of phone models for reference only. Finally, we also discuss the factors affecting the throughput.

Throughput Evaluation Steps

1. Connect a USB cable to a WBZ351 CURIOSITY board

2. Download the BLE_THROUGHPUT firmware

3. Run a terminal tool like "Tera Term"

   Open the serial port connecting to WBZ351 CURIOSITY and configure the setting as below:

   

4. Press the reset button on the WBZ351 CURIOSITY board and the initialization string will be displayed as illustrated in the following image .

   

5. Connect the "BLE UART" of MBD APP to WBZ351 Curiosity board

6. Select Burst mode

7. Select Demo Mode in setting page. Except the UART mode, all the other modes are supported by "BLE_THROUGHPUT"

8. Select Text file size in the Setting page

9. The TRP profile is automatically selected

10. Select GATT WriteType

    "Write without Response" will achieve much higher throughput.

11. Tap Done and back to the previous page

12. Tap START

    After sending the file, the throughput is evaluated and shown as below:

    

Throughput Test Report

The following tables describe the throughput test result with iOS and Android devices with the configuration as

• Profile

  TRP

• GATT Write Type

  Write without Response

• Downlink

  Tested with "Checksum" data transfer mode

• Uplink

  Tested "Fixed pattern" data transfer mode

1. iOS Devices

   

2. Android Devices

   

Factors Affecting Throughput

In BLE_THROUGHPUT example, the WBZ351 is the GATT server while the MBD App is the GATT client. There are 7 main factors affecting the throughput. Some factors are negotiated and determined by the BLE stack of the GATT client and server. And some factors can be modified or requested by the user level application code using the APIs exposed by underneath BLE stack.

1. ATT MTU size

   Larger MTU size achieves higher throughput. Assuming the MTU size is x, then the Max application data payload in one operation is of x minus 3( excluding 1byte of GATT operation code and 2 bytes of the attribute handle ).

   In PIC32CX5109BZ31048 BLE stack, the Max MTU is set to 247 bytes. The final MTU used by the GATT client and server will depends on the negotiation initiated by the GATT client. For iOS, the MTU size is determined by the underneath BLE stack while the user level application can use API to learn the determined MTU. For Android, the MTU size can be requested by the user level application code using API of "requestMtu (int mtu)" and the user application code should observe the result from "onMtuChanged " callback.

2. Operation Type

   For downlink operation, the "Write without Response"(Write Command) is always faster than the "Write with Response"(Write Request).

   For uplink operation, the Notify operation is always faster than the Indication operation which requires a confirm from peer device.

   It's the responsibility of BLE_THROUGHPUT firmware to define the property of the GATT characteristics. The property in turn defines the permitted operation type.

3. Data Length Extension(DLE)

   Link layer data packet length by default is 27 bytes. From BLE 4.2 onward, the link layer data packet length can be extended to as long as 251bytes. This feature is called Data Length Extension(DLE). Note that some phone models might not support DLE while PIC32CX5109BZ31048 BLE stack supports it. DLE negotiation is conducted by underneath BLE stack of both the client and the server. User level application code has no API to modify the link layer data packet length.

4. Connection Interval(CI)

   The CI defines the frequency of the Connection Event. Shorter CI causes higher frequency of the Connection Event. Certain number of data packets can be sent during one connection event. It is obvious that the shorter CI the lesser number of data packets can be sent in one Connection Event. In contrast, the longer CI the higher opportunity to send larger number of data packets in one Connection Event. The iOS device might limit the CI parameter according to the peripheral type. See reference[6] for more details.

   PIC32CX5109BZ31048 BLE stack provides API of "BLE_DM_ConnectionParameterUpdate" to update the connection parameter. The final connection parameter is decided by negotiation of both the client and the server stack.

   On Android the equivalent API is "requestConnectionPriority" while there is no such similar API available on iOS.

5. Number of Data Packets per Connection Event

   The number varies from iOS to Android and from revision to revision. There is no direct API available on either iOS or Android to define this number. User can fine tune the CI to get ideal value and verify the result in the air log.

6. PHY Selection

   From BLE 5.0 onward, LE 2M PHY is introduced. It is 2x faster than the former LE 1M PHY. Gradually the phone models in the market will embrace this new feature. Either the GATT client or server might request to update the PHY to LE 2M according to PHY Update Procedure defined by SIG, see reference [7] for details. WBZ351 is born to support this feature and the API of "BLE_GAP_SetPhy" is available to user level application code to change the PHY selected.

   • PHY Update Procedure

   In BLE_THROUGHPUT example, the API "BLE_GAP_SetPhy" is called on writing the handle of TRP TX characteristic CCCD(Client Characteristic Configuration Descriptor) operated by peer device illustrated as below image. For more details on TRP, see reference[1].

   

   A event of BLE_GAP_EVT_PHY_UPDATE will be generated on the completion of this procedure then the user can check the result in this event. This event is handled by APP_BleGapEvtHandler( ) of GAP handler in this example.

7. The RF Factor

   The noisy RF environment can decrease the throughput. The well designed RF circuit can achieve higher throughput. Finally, the casing condition of the end product containing the BLE device can also affect the throughput.

4. The BLE_THROUGHPUT Example Firmware Diagram

The BLE_THROUGHPUT firmware is designed for WBZ351 CURIOSITY board. The firmware is based on TRP service. There are 3 data transfer modes supported by the BLE_THROUGHPUT firmware, including Checksum mode, Fixed pattern mode and Loopback mode. To simplify, the UART mode is not implemented in this example. The firmware diagram below illustrates the main part of the firmware.

References

[1] Microchip Transparent Service_v1.1

[2] Microchip Transparent Credit Based Service v1.0

[3] https://www.bluetooth.com/specifications/gatt/

[4] Microchip Transparent Profile_v1.1

[5] Microchip Transparent Credit Based Profile_v1.0

[6] developer.apple.com/accessories/Accessory-Design-Guidelines.pdf

[7] www.bluetooth.com/specifications/specs/core-specification-5-3/