olba gravatar image

Posted 2017-02-28 16:48:25 +0200


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.


mtailor gravatar image

Posted March 2, 2017, 10:21 a.m.

Neat demo.

By any chance is the code for driving for the display available as a self contained package of 'C' code?

I am assuming the display is driven from I2C or SPI

We would love to bundle that into our smartBASIC based firmware for our nrf52 based BL652 module so that our customers can use high level BASIC api calls to create neat user interfaces for their end products.

mtailor gravatar image

Posted March 2, 2017, 10:29 a.m.

The post concludes with the max throughput figures of 1365/775/128/21.3 kbps.

Would you be able to do a quick test and see what speeds you get if you change the connection interval to say 30ms (I think that is the lowest that an iOS device will allow).

Just trying to manage expectations of real use case involving smartphones :-)

mtailor gravatar image

Posted March 2, 2017, 12:39 p.m.

With 1365kbps can I assume that the data is not forwarded over the uart, so are you discarding the data as it arrives without validation?

ovrebekk gravatar image

Posted March 9, 2017, 1:22 p.m.

Hi Mahendra

The problem right now is that the display is not available for purchase anywhere. It was made internally, and as it is quite expensive to produce it is not something we plan to produce in large numbers.

The interface to the display is SPI.

As for testing with phones we are thinking about implementing something similar for phone testing, but for it to be realistic we would need to connect the phone directly to the kit, using an app of some sort to transfer the data.

The data is not used for anything, that is correct. It is stored in RAM obviously, but is ignored by the application ;)

Best regards

MANGO gravatar image

Posted March 14, 2017, 3:39 a.m.

Hi, I really really really wanted to buy that display shown in the demo video. Bad luck for me.

Anyways, can the nRF52840 select the protocol; BLE (Bluetooth 4) and Bluetooth 5?

johnny gravatar image

Posted March 21, 2017, 3:33 a.m.

Hi, We care about the power consumption.

May I ask about the power consumption at BLE 5 Long Range.

At BLE 5 Long Range mode use the 8 times of symbols to transfer the data.

How many power consumption increase from short range to BLE Long Range to transfer the same data?


daoming gravatar image

Posted March 26, 2017, 4:16 a.m.

Hi, I think you only demonstrated the data throughput, not long range. The answer to this post https://devzone.nordicsemi.com/question/115753/easiest-way-for-two-nrf52x-devices-to-ping-each-other/ says that "The SoftDevice does not support long range advertising at the moment." If a connection can be established at 1Mbps data rate, why would I need to reduce the data rate? Anyway I don't think it is long range demo because it is not using coded PHY (125kbps) for connecting.

DM2017 gravatar image

Posted March 29, 2017, 1:03 p.m.

"Opening and closing a connection event adds a lot of overhead"

how much is the overhead and where can i look this up?

vincent.golle gravatar image

Posted March 30, 2017, 1:50 a.m.

MANGO, You should have a look at the Sharp 2.7" memory display: LS027B7DH01

ls-ash gravatar image

Posted June 12, 2017, 1:04 p.m.

Hello, why does this example only achieve ~1365 Kbps in 2 Mbps mode? Is that the max limit in practice? Or does this example not allow configurations to push throughput to the max?


ls-ash gravatar image

Posted June 13, 2017, 12:07 p.m.


This post answers my question I guess

ls-ash gravatar image

Posted June 15, 2017, 6:05 p.m.

Hi, I tried running some range test with this demo in an open area and was getting strange behaviour. When I set the module to transmit using the 125Kbps mode the transfer would start and then fail after transmitting somewhere between 50-250Kbytes. The board printed a disconnect message to the associated terminal and returned to the menu. However, transfers would work perfectly in the high data rate mode, 2Mbits/s up to a range of 400m, with the same settings! Has anyone experienced this behaviour before or knows of a potential cause and/or fix?


Here are the full settings used during the testing:

Single transfer
BLE version:            BLE 5 long range
Preferred PHY:        125Kbps
conn. interval:        400ms
ATT MTU size:         247bytes
Data length ext:      ON
Conn evt ext:          ON
Tx Power:               8dBm
Transfer data size:  1024Kbytes
Link Budget:           111dBm
trexx50 gravatar image

Posted June 22, 2017, 2:56 p.m.


I have tried the example but I have a pretty bad troughput of 262Kbps... I'm using a nRF52840-Preview-DK and a nRF51832. My config:

APP:INFO:Time: 31.993 seconds elapsed. APP:INFO:Throughput: 262.23 Kbps. APP:INFO:=============================

APP:INFO:Sent 1048712 bytes of ATT payload.

APP:INFO:Retrieving amount of bytes received from peer...

APP:INFO:Peer received 1048712 bytes of ATT payload.


APP:INFO:Current test configuration:


APP:INFO:ATT MTU size: 247

APP:INFO:Conn. interval: 6 units (1.25 ms per unit).

APP:INFO:Data length extension (DLE): ON

APP:INFO:Preferredy PHY: 2 Mbps

May be something wrong in the configuration? (I have all tried)

Do you have an idea? Thank you,

mafaneh gravatar image

Posted Sept. 11, 2017, 5:50 p.m.

The Sharp LS027B7DH01 display doesn't seem to be in stock anywhere online! Are there other alternatives? What should I look out for when choosing one?


Stanley20150727 gravatar image

Posted Oct. 3, 2017, 3:49 a.m.

Hello,I bought a piece of LS027B7DH01 LCD from Mourser.Can you tell me how to connect to PCA10056?

Thank you

Sign in to comment.

User menu

    or sign up

Recent questions

Related posts by tag