Throughput and long range demo

The new Bluetooth 5 specification promises twice the speed and 4 times the range. Doubling the speed is achieved by increasing the on-air datarate to 2Mbps, while quadrupling the range is achieved by lowering the bitrate to increase the sensitivity of the receiver. We at Nordic have made a demo showing these features with our newest SoftDevice(s) and specifically our newest chip, the nRF52840. It was showcased at CES 2017 in January.

Here is a more in depth description of the demo.

The demo is based on the ATT_MTU throughput example in SDK 13.0.0-1.alpha, which allows you to configure various Bluetooth low energy (BLE) parameters to test out the impact on throughput and range. This demo adds some configurations and can be used either with a display or a terminal program on the computer.

Hardware requirements:

  • Two nRF52840 Preview Development Kits (PDK) or nRF52832 Development Kits. A combination of the two different kits can also be used. Notice that if the nRF52832 Development Kit is used, the long-range feature will not work as this is only possible with the nRF52840.
  • A computer with a terminal program. Since the display shield is just an internal prototype and not publicly available, a PC with a terminal program should be used to control the demo.
  • A micro USB cable or a battery to power the kits.

Software requirements:

  • Demo firmware, found here. The same firmware runs on both kits.
  • Terminal program running on your computer. Tera Term or Putty is recommended. Note: Termite cannot be used as it does not accept ANSI escape characters.

If you flashed the firmware correctly and connected the terminal program or the display shield to one of the boards, you should see a screen telling you to press button 1 on that kit (from now on called the master) and button 2 on the other kit (from now on called the slave). During the transfer the master will set the configurations for the link, connect to the slave and send data to it using notifications.

There are many parameters that can be adjusted before running the test. Here is a description of the different settings and what they do:

  • Run single transfer: This will establish a connection between the master and slave using the current settings and send a specified amount of data between them. During the transfer the throughput will be displayed continuously along with a progress bar, the link budget and a range multiplier. The range multiplier gives the user an indication of how much further he should be able to bring the kits apart (assuming the same amount of obstacles between them). After the transfer is done the average throughput will be displayed along with the elapsed time, how many bytes were transferred and the average RSSI.
  • Run continuous transfer: This is almost the same as the single transfer. The difference is that a new transfer will be automatically started after the last one is completed. It will also show the average throughput of the previous transfer.
  • BLE version: This is a “quick configuration” option to set the different parameters to what is/was possible with the different Bluetooth versions and our chipsets/SoftDevices. Four options are available: BLE 5 High Speed, BLE 5 Long Range, BLE 4.2 and BLE 4.1.
  • Preferred PHY: This is the on-air or physical layer data rate that the master will try to use. Three options are available (for nRF52840): 2Mbps, 1Mbps, 125Kbps (also called coded PHY). nRF52832 does not support 125Kbps, so if the slave is a nRF52832 DK, then the data rate used will fall back to 1Mbps. Also note that this will be the data rate used in the connection. During advertising 1Mbps will be used.
  • Connection interval: Connection interval used in the connection. Three options are available: 7.5ms (lowest possible in BLE), 50ms and 400ms. Why these options are used will be described later.
  • ATT MTU size: ATT Maximum Transmission Unit is the maximum length of an ATT packet. A write, read, notification or indication packet will have a 3-byte header including the OP-code (operation, 1 byte) and the attribute handle (2 bytes). The rest will be attribute data. The default size of the ATT MTU is 23 bytes, but the SoftDevice allows for sizes up to 512. In this demo you can choose between 23 bytes, 158 bytes and 247 bytes. A larger packet will have less overhead (header per effective data) and will therefore lead to higher throughput. If the ATT packet cannot fit in a single on-air packet, it will be split up into multiple on-air packets. The size of the on-air packet is determined by the Data Length Extension (DLE) setting.
  • Data length extension (DLE): This will set the on-air packet size. The maximum on-air packet size is 255 bytes. If we take away L2CAP header (4 bytes) and Link Layer header (4 bytes) we are left with an ATT packet of 247 bytes. For simplicity in this demo, you can turn DLE either on or off. If DLE is on, the size will be set to the ATT packet size plus the header bytes. This will avoid fragmentation of the ATT packet into several on-air data packets, to increase data throughput. DLE will affect the throughput greatly as larger packets will lead to more time sending actual data.
  • Connection event length extension: Setting this to “ON” will allow the SoftDevice to continue sending packets until the next connection event is scheduled. Opening and closing a connection event adds a lot of overhead. For this reason, a higher connection interval will give higher throughput if this option is enabled. This is different compared to older Nordic BLE devices and stacks, where you wanted the connection interval to be as short as possible for maximum throughput. One drawback here is that if there is a lot of interference and packets start getting lost. If a packet is lost, the device needs to wait for the next connection event before sending more packets (after resending the lost packet). The wait time can be anywhere from close to zero to the length of the connection interval. In other words a long connection interval will improve the throughput when the link quality is good, but could reduce the throughput when there is a lot of interference or when the distance between the devices is large.
  • TX power: The output power set. This is useful if range is to be tested. Options are 0, 4 or 8 dBm. If nRF52832 DK is used as the master, then 8 dBm is not possible. The slave will use the maximum output power available.
  • Transfer data size: The amount of bytes that will be transferred. If the test is set up for lower throughput this can be adjusted to reduce the overall test time.
  • Link budget: The difference between TX power and receiver sensitivity. This is not adjustable and will be determined by the TX power and the physical data rate (determines receiver sensitivity).

The throughput measured may vary depending on the environment, but the maximum throughput should be around 1365 Kbps for BLE 5 High Speed, 775 Kbps for BLE 4.2, 128 Kbps for BLE 4.1 and 21.3 Kbps for BLE 5 Long Range. Be aware that there may be some inaccuracies in the measurements.

Anonymous
  • Hey,

    when I run this example from SDK 14.2.0 on two nRF52840 DKs with (att_mtu: 23, conn_interval: 7.5, dle: on, phy: 1M) I am getting a throughput of nearly 86 kbps. My calculated throughput is (1000ms/7.5ms) * 20bytes * 8bits/byte = 21,3 kbps and assuming a number of 4 transferred packets per connection interval this gets very close to the measured value with 85.3kbps. Now one question: Why should I assume 4 and not 6 transferred packets? The theoretical throughput could also be calculated by taking the empty and full loaded packet transmission time + the interframe spacing T_IFS into account and then calculating the maximum amount of packet that could be transmitted in one connection interval. This will be higher than 6, which is stated in the SoftDevice specifications. Is this a result of the Connection Length Extension?

    As the Data Length Extension was set to "on", the on-air packet size will be set to ATT_MTU size + header size (= 27 bytes), but why is the throughput increased (250 kbps) when turning DLE "off" and keeping all other parameters the same?

    Thanks and regards, Björn

  • Hi

    That is correct.

    You can use the ble_app_att_mtu_throughput example to test the throughput between two Nordic kits: \nRF5_SDK_14.2.0\examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput

    Best regards
    Torbjørn

  • Hi,

    There is similar sample application in SDK 14. I can also try it to test throughput, right?

  • Hi Mohammad,

    What actually is the data being sent? And how would I go about setting my own custom data with this service?

    Thanks for your help, Greyed

  • Daniel,

    I had the same issue and spent a lot of time trying different solutions to get the menu to show up properly in macOS. In the end, I found that the best solution is to use the following program:

    ZOC Terminal.

    Hope this helps.

    -Mohammad

    Novel Bits, LLC