Bluetooth 5 speed: How to achieve maximum throughput for your BLE application

Introduction

In this second post in the series on Bluetooth 5, we cover the new feature of improved 2x speed along with a general overview of throughput for a BLE application (the previous post went over Bluetooth 5’s new features in general and more specifically covered the increased advertisement capacity feature).

First, we need to understand that the speeds advertised (1 Mbps and the new 2 Mbps) are only theoretical and are cut down when it comes down to application throughput. This is due to multiple reasons which we’ll go over in the next section.

The Bluetooth 5 “2x speed” feature requires a hardware update so older devices/chips/modules will not support it. It is also important to note that in order to achieve this higher throughput you will need both BLE devices communicating with each other to support the new LE 2M PHY (which makes it possible to transfer data at this higher rate).

The new LE 2M PHY, as well as the original LE 1M PHY, are both called Uncoded PHYs since they use a 1-symbol representation per bit of data (in comparison to the new LE Coded PHY which uses a 2-symbol or 8-symbol representation per bit of data).

Another important thing to note is that when utilizing the higher speed PHY, you actually achieve lower power consumption (given that you transfer the same amount of data). This is because the radio-on time is reduced without the transmit power being increased. This in turn also improves coexistence with other wireless technologies within the 2.4 GHz spectrum (also due to the reduced radio-on time).

In this post, we will cover:

  • What’s the practical throughput to expect from BLE?
  • Bluetooth 5’s new 2M PHY for data transfer
  • What are the factors that impact/determine data throughput?
  • How do you calculate your application data throughput?
  • How do you maximize your data throughput?
  • Testing, measuring, and calculating data throughput using two nRF52 series development kits

Why is it impossible to achieve the theoretical speeds of BLE?

The data rates of 1 Mbps (LE 1M PHY), 2 Mbps (LE 2M PHY), 125 kbps and 500 kbps (both using the LE Coded PHY with S=8 and S=2, respectively) are the rates at which the radio transmits data, but this is not achievable for the application throughput due to the following reasons:

  • Limit on the number of packets per connection interval
  • Inter Frame Space (IFS) delay between packets (150 us)
  • Empty packets required to be sent from a device even if no data is available for transmission
  • Packet overhead – not all bytes in a packet are used for payload

In order to better understand these factors and understand what impacts application throughput, we have to take a deeper look at the packet format. The following figure shows what LE 1M PHY and 2M PHY data packets look like:

LE Uncoded Packet format diagram

The part we’re interested in (and the one that really defines the application data) is the ATT Payload. As you can see from the figure, there are a number of overhead bytes that are used by each layer in Bluetooth Low Energy.

  • In 4.0 and 4.1, the maximum ATT Payload is 20 bytes.
  • In 4.2 and 5.0, a new feature called Data Length Extensions (DLE) allows the ATT Payload to hold up to 244 bytes of data.

Bluetooth 5 speed : 2x speed utilizing the new 2M PHY

It is useful to understand the limitations of using the new LE 2M PHY in Bluetooth 5:

  • Cannot be used to transmit the primary advertisements (on the primary channels).
  • Can be used for the secondary “auxiliary packets” sent on the same channels as the data packets (37 channels: 0-36).
    To learn more about primary and secondary advertisements, refer to my previous blog post: Bluetooth 5 Advertisements: Everything you need to know.
  • LE 1M is mandatory, whereas LE 2M is optional. So, not all chips claiming Bluetooth 5 support can necessarily handle the higher throughput.
  • Advertisements and discovery can occur on the LE 2M PHY, and then connections occur on the secondary advertisement channel using the LE 2M PHY

Transfer of application data from one device to another usually happens during a connection between the two devices. The connected devices can negotiate the use of a different PHY via the PHY Update Procedure. It can be initiated by either slave or master after a connection is established, but the master will ultimately make the final decision on which PHYs are used for each direction (based on the slave’s request and the PHYs the master supports).

LE PHY Update Procedure sequence diagram

Factors that impact/determine the data throughput

There are a few factors that impact the data throughput of a BLE application. The most common are:

  • PHY being used (LE 1M vs. LE 2M vs. LE Coded (S=2 or S=8))
  • Connection interval
  • Maximum number of packets per connection interval
  • ATT Maximum Transmission Unit (ATT MTU)
  • Data Length Extension (DLE)
  • Operation type: Write with response vs. write without response, Indications vs. Notifications
  • Inter Frame Space (IFS): time gap between consequent packets (150 us)
  • Transmission of empty packets
  • Packet overhead – not all bytes, in a packet, are used for the application payload

Let’s go over each of these in more detail.

PHY

There are basically three PHYs in Bluetooth 5: the original 1 Mbps PHY, the new 2 Mbps, and the coded PHY (with S=2, or S=8). The PHY used will directly impact the maximum data throughput you can achieve since it determines the actual raw data rate in which packets are sent over the air.

Connection Interval & max packets per connection event

The connection interval effectively determines how many packets can be sent during one connection event. The higher the value, the more packets can be sent in one connection event (up to a certain limit for some devices).

Learn more about connection intervals: BLE connection intervals and events

However, the number of packets per connection event depends on the device and BLE stack so it is limited and differs between devices and stack versions on a specific device. This value also depends on the operation of the device, so the radio may have to attend to other events and the number of packets sent per connection events may not reach the max allowed by the stack. For example, the number differs between iOS and Android and also changes depending on the version of the OS running on the device.

Sometimes it is useful to dynamically update the connection parameters based on the use case. However, keep in mind that it is up to the master to accept these recommendations or update the parameters to accommodate them.

Data Length Extensions (DLE)

This feature allows the packet size to hold a larger amount of payload (Up to 251 bytes vs. 27 when disabled). This feature was introduced in version 4.2 of the Bluetooth spec.

ATT Maximum Transmission Unit (ATT MTU)

ATT MTU Determines the max amount of data that can be handled by the transmitter and receiver and which they can hold in their buffers.

The MTU value affects the amount of overhead data (specifically the ATT header which is 3 bytes). The minimum ATT MTU allowed is 27 bytes. This allows a max of 20 bytes of ATT payload (3 bytes are used for the ATT header, and 4 bytes for the L2CAP header).

There is no limit per the spec on how high the MTU value can be, but the specific stack in use may have its own limitations. For example, if you enable DLE then you can transfer up to 251 – 4 = 247 bytes (after deducting the L2CAP Header size). After taking into account the ATT header (3 bytes), we are left with 244 bytes for the actual ATT payload data. If the MTU is at least 247 bytes then the MTU will fit into one single packet. If the MTU is greater than 247 bytes, then the MTU will span multiple packets causing the throughput to go down (because of the packet overhead and timing in between the packets).

The effective MTU gets determined by the minimum value of ATT MTU that the client and server support. For example, if a client supports an ATT MTU of 100 bytes and the server responds that it supports an ATT MTU of 150 bytes, then the client will decide that the ATT MTU to be used for the connection from thereon is 100 bytes.

Operation type: Write with response vs. write without response, Indications vs. Notifications

If high throughput is desired then we can use Write without response or Notifications to transfer the data from the client to the server and from the server to the client. These operations remove the need for the other device to acknowledge receipt of the data and respond before the next block of data can be sent.

Inter Frame Space (IFS): time delay between consecutive packets (150 us)

From the Bluetooth specification:

4.1.1 Inter Frame Space

The time interval between two consecutive packets on the same channel index is called the Inter Frame Space. It is defined as the time from the end of the last bit of the previous packet to the start of the first bit of the subsequent packet.
The Inter Frame Space is designated “T_IFS” and shall be 150 μs.

Transmission of empty packets

If the device receiving data has no data to send back, it still needs to send an empty packet as per the Bluetooth specification.

Packet overhead

As we saw in the packet format figure, the packet includes some overhead data that doesn’t count towards your application data (ATT data). Basically, these bytes will consume part of your transfer data rate while not accounting for any bytes being sent as part of your application data.

Calculating your application data throughput

The big question is: how do we calculate our application throughput?

As we mentioned before, there are a few variables that impact the data throughput:

  • Bluetooth version & PHY used
  • DLE: Data Length Extensions – enabled or not
  • ATT MTU value
  • Connection interval
  • Maximum number of packets per connection event
  • Operation (writes with responses vs. writes without responses, and notification vs. indication)
  • Inter Frame Space (IFS): 150 microseconds

The Bluetooth version and PHY determine the raw data transfer rate. For example, if we are using Bluetooth version 4.2 and the LE 1M PHY, then the transfer rate is at 1 Mbps. If on the other hand, we are using the Bluetooth 5 LE Coded PHY with S=8, then the data rate goes down to 125 kbps.

The DLE, ATT MTU, connection interval, the maximum number of packets per connection interval, Operation, and IFS all determine the portion of the on-radio time that’s utilized for actual data transfer.

The packet format plays a big role in how much of the data being transferred is your actual application data. The LE 1M PHY and LE 2M PHY both have a similar packet format. The LE Coded PHY has a significantly different packet format, so we’ll be looking at these two cases separately.

LE 1M PHY and LE 2M PHY calculation

Referring back to the packet format for LE Uncoded PHYs:

LE Uncoded Packet format diagram

The amount of overhead for each PHY is slightly different. The Preamble is 1 byte in the case of the 1M PHY and 2 bytes in the case of the 2M PHY. The MIC field is an optional field that is used only for encrypted connections. For simplicity, we will only consider unencrypted connections – for the encrypted case, it simply adds 4 bytes of overhead.

For LE Coded PHYs, the packet format looks like this (from the Bluetooth 5.0 spec Vol 6, Part B, Section 2.2):

LE Coded PHY Packet Format Diagram

Steps for calculating the throughput (in Mbps):

For sake of simplicity, we assume the following:

  • Encryption is NOT enabled (MIC field is not included in the packet)
  • We are interested in the throughput for one direction (e.g. Master to Slave), so we assume the other direction only transfers empty packets
  • Writes without responses (which would help in maximizing the throughput when transferring large amounts of data
Steps:
  1. Determine the PHY being used and note down the rate of raw data transfer
    E.g. for 1M PHY -> 1 Mbps, for Coded PHY and S=8 -> 125 kbps
  2. Determine the time it takes to send one data packet and the empty packet from the receiver.
    connection interval packet diagramThe time during which one data packet can be sent will include the following:
    Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS.

    An empty packet transmission time can be calculated as follows:Time to transmit empty packet = empty packet size / raw data rateAn empty packet will contain the following fields: Preamble + Access Address + LL Header + CRC.For 1M PHY, Preamble will be 1 byte, and so the total size of the empty packet = 1 + 4 + 2 + 3 bytes = 10 bytes = 80 bits.

    (for 2M PHY, the size of an empty packet will be 88 bits since the Premable is 2 bytes instead of 1 byte).Based on this, the time to transmit an empty 1M PHY packet will be:Time to transmit empty packet = empty packet size / raw data rate = 80 bits / 1 Megabits per second = 80 micro secondsA data packet will contain all fields listed in the packet format diagram with the exception of the MIC field (encryption disabled).Time to transmit data packet = data packet size / raw data rateIf we have DLE enabled and the ATT MTU is equal to the maximum bytes allowed in one packet: 247 bytes, then we can calculate the data packet size as:Data packet size = 1 + 4 + 2 + 4 + 247 + 3 bytes = 265 bytes = 265*8 bits = 2088 bitsTime to transmit data  packet = 2088 bits / 1 Mbps = 2,088 micro secondsData_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 80 + 2*150 + 2088 = 2,468 microsecs

    For comparison, in the case of 2M PHY, it would be:

    Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 88/2 + 2*150 + (2 + 4 + 2 + 4 + 247 + 3)*8/2 = 1,392 microsecs

    When DLE is enabled and the ATT MTU is set to less than 247, we end up with more overhead (since now data larger than the ATT MTU gets split up into more packets). For example, say we have the ATT MTU set to 158, then in order to transfer 244 bytes of application data, we will need two packets instead of one, causing the throughput to go down due to the increased byte overhead as well as the increased IFS between the packets. In another scenario, we could have DLE disabled (Payload size up to 27 bytes) and the ATT MTU greater than 27 bytes. Here, this will also result in more packets needed to be sent for the same amount of data, causing the throughput to go down.

    Note: The same method for calculating the data and empty packet sizes that we used above can be used for the LE Coded PHY.

  3. Figure out how many packets can be transmitted during one connection interval
    This calculation is not always purely mathematical – you will need to take into account limitations of the stack and device being used. iOS and Android have maximums that change with OS version, so it’s not always easy to figure out. That being said, on an MCU, the vendor’s SDK usually lists the maximum in their documentation. It’s also helpful to do a trial and error and figure out what your specific device supports.

    Once you’ve figured out the maximum, you can calculate the maximum theoretical number of packets that would fit within a connection interval of choice. For example, if we had a connection interval of 7.5 millisecs (the lowest permitted by the spec), then for our example above (using 1M PHY, DLE enabled):

    Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] , where [ ] rounds to the highest whole number (integer)

    Maximum # of data packets per connection interval = [7.5*1,000 microsecs / 2,468 microsecs] = 3 packets

    Usually, this number is not realistic as there are timing delays between packets being sent on consecutive connection events. So, for our example, we will go with 2 packets instead of 3.

  4. Once we’ve figured out the maximum # of data packets that can be transferred per connection interval, we can calculate the data throughput:

    Data throughput = data per connection interval / connection interval = No. of data packets per connection interval * Data size per packet / connection interval
    = 2 * 244 * 8 bits / 7.5 millisecs = 520,533 bits/sec ~= 508 kbps

Testing and calculating data throughput between two nRF52 development kits

In this section, we will run multiple tests of data transfer, calculate the throughput using the procedure we described earlier, and then compare them with the measured throughput reported by the application running on the development boards. The tests are run based on the demo app provided by Nordic Semiconductor and featured in this blog post: Throughput and long range demo.

Source code for the example can be found at the GitHub page here.

Case 1 (PHY: 1 Mbps, ATT MTU = 23 bytes, DLE: enabled, Connection interval: 7.5 millisecs)

Data throughput reported by firmware:

Time: 36.11 seconds elapsed.
Throughput: 232.29 Kbits/s.
Sent 1048580 bytes of ATT payload.

Calculated data throughput:

With the MTU set to 23 bytes, DLE does not really affect the data throughput and packet sizes.
Time to transmit data packet = data packet size / raw data rate = 1 + 4 + 2 + 4 + 23 + 3 bytes / 1 Mbps= 37*8 bits / 1 Mbps = 296 microsecs
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 80 + 150 + 296 + 150 microsecs = 676 microsecs
Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] = [7.5 millisecs / 676 microsecs] = [11.09] = 11 packets
Total data transferred per connection interval = 11 * 20 bytes = 11 * 20 * 8 bits = 1760 bits
Data throughput = Total data transferred per connection interval/connection interval = 1760 bits / 7.5 millisecs = 234.67 Kbits/s
As we can see, the calculated value and measured value are pretty close.

Case 2 (PHY: 2 Mbps, ATT MTU = 23 bytes, DLE: enabled, Connection interval: 7.5 millisecs)

Data throughput reported by firmware:

Time: 27.23 seconds elapsed.
Throughput: 307.96 Kbits/s.
Sent 1048580 bytes of ATT payload.

Calculated data throughput:

Time to transmit data packet = data packet size / raw data rate = 2 + 4 + 2 + 4 + 23 + 3 bytes / 2 Mbps= 38*8 bits / 2 Mbps = 152 microsecs
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 44 + 150 + 152 + 150 microsecs = 496 microsecs
Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] = [7.5 millisecs / 512 microsecs] = [15.12] = 15 packets
Total data transferred per connection interval = 15 * 20 bytes = 15 * 20 * 8 bits = 2400 bits
Data throughput = Total data transferred per connection interval/connection interval = 2400 bits / 7.5 millisecs = 320 Kbits/s
As we can see, the calculated value and measured value are pretty close.

Case 3 (PHY: 1 Mbps, ATT MTU = 158 bytes, DLE: enabled, Connection interval: 7.5 millisecs)

Data throughput reported by firmware:

Time: 17.53 seconds elapsed.
Throughput: 478.36 Kbits/s.
Sent 1048730 bytes of ATT payload.

Calculated data throughput:

Time to transmit data packet = data packet size / raw data rate = 1 + 4 + 2 + 4 + 158 + 3 bytes / 1 Mbps= 172*8 bits / 1 Mbps = 1376 microsecs
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 80 + 150 + 1376 + 150 microsecs = 1756 microsecs
Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] = [7.5 millisecs / 1756 microsecs] = [4.27] = 4 packets
Total data transferred per connection interval = 4 * 155 bytes = 4 * 155 * 8 bits = 4960 bits
Data throughput = Total data transferred per connection interval/connection interval = 4960 bits / 7.5 millisecs = 661.33 Kbits/s

Case 4 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 7.5 millisecs)

Data throughput reported by firmware:

Time: 8.45 seconds elapsed.
Throughput: 992.07 Kbits/s.
Sent 1048712 bytes of ATT payload.

Calculated data throughput:

Time to transmit data packet = data packet size / raw data rate = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs
Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] = [7.5 millisecs / 1392 microsecs] = [5.39] = 5 packets
Total data transferred per connection interval = 5 * 244 bytes = 5 * 244 * 8 bits = 9760 bits
Data throughput = Total data transferred per connection interval/connection interval = 9760 bits / 7.5 millisecs = 1301.33 Kbits/s

Note: In the last two cases, the number of packets per connection interval is small and any difference between what we calculate and is measured will have a big impact on actual data throughput. For example, if the number of packets per connection interval end up being 4 instead of 5 in the Case 4, the calculated throughput becomes 1,041.1 Kbps instead of 1,301.33 Kbps (which is a big difference and could explain the discrepancy in numbers here).

Case 5 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 50 millisecs)

Data throughput reported by firmware:

Time: 6.34 seconds elapsed.
Throughput: 1322.33 Kbits/s.
Sent 1048712 bytes of ATT payload.

Calculated data throughput:

Time to transmit data packet = data packet size / raw data rate = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs
Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] = [50 millisecs / 1392 microsecs] = [35.92] = 35 packets
Total data transferred per connection interval = 36 * 244 bytes = 35 * 244 * 8 bits = 68320 bits
Data throughput = Total data transferred per connection interval/connection interval = 70272 bits / 50 millisecs = 1366.4 Kbits/s

Case 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 400 millisecs)

Data throughput reported by firmware:

Time: 6.11 seconds elapsed.
Throughput: 1371.82 Kbits/s.
Sent 1048712 bytes of ATT payload.

Calculated data throughput:

Time to transmit data packet = data packet size / raw data rate = 2 + 4 + 2 + 4 + 247 + 3 bytes / 2 Mbps= 262*8 bits / 2 Mbps = 1048 microsecs
Data_Packet_Time = Time to transmit empty packet + IFS + Time to transmit the actual data packet + IFS = 44 + 150 + 1048 + 150 microsecs = 1392 microsecs
Maximum # of data packets per connection interval = [connection interval / Data_Packet_Time] = [400 millisecs / 1392 microsecs] = [287.36] = 287 packets
Total data transferred per connection interval = 287 * 244 bytes = 287 * 244 * 8 bits = 560224 bits
Data throughput = Total data transferred per connection interval/connection interval =560224 bits / 400 millisecs = 1400.56 Kbits/s

Optimizing for maximum data throughput

Based on the factors we went over, we can note the following when optimizing for high data throughput:

  • Always enable DLE
    Obviously, if you’re using Bluetooth v4.1 or earlier, this is not a valid option. In general, however, make sure you enabled DLE to maximize your packet to application data efficiency
  • Use LE 2M PHY
    If you know that the devices on both ends support Bluetooth 5, then utilizing the LE 2M PHY is one of the best ways to maximize your application data throughput. Using the LE 2M PHY will also help reduce power consumption, so you hit two birds with one stone!
  • Use Notifications and Writes without Responses
    Utilizing these will help remove any unnecessary packets being transmitted (compared to Indications and normal Writes which require the receiving end to acknowledge each packet received).
  • Choose an ATT MTU value of at least greater than 247 bytes
    This will minimize any overhead in packet bytes.
  • Choose a connection interval that allows for the maximum # of packets per connection interval
    But keep in mind that the connection interval affects power consumption. The shorter the interval, the more power your device will consume because of the increased radio-on time. You also want to make sure you don’t choose an interval that’s too high, otherwise, it’ll compromise the user experience (higher connection interval results in higher latency). One last thing to make sure you account for is any limitations of the devices in your system in terms of the maximum number of packets per connection interval supported.

Summary & closing

The calculated values we listed above are still theoretical and may not align with the measured data throughput in practice and real-life environments, but they still are a good starting point and give a good indication of what to expect (at least for a maximum). Interference and transmission/reception errors also affect data throughput (retries, data loss, and closing of connection events result in lower throughput). These can be caused by the presence of other devices utilizing the same 2.4 GHz band as Bluetooth, longer distance between devices, the existence of obstacles between devices, and more…

Hope you found this post useful. As always, feel free to comment or ask any question in the comments section below.

References/Credits

By | 2017-10-13T15:41:38+00:00 September 6th, 2017|Categories: BLE technology|15 Comments

About the Author:

Mohammad Afaneh
Mohammad has a strong passion for developing Bluetooth Low Energy and IoT applications. He helps developers develop for BLE faster through detailed technical tutorials, articles, and videos. He enjoys playing sports, spending time with his wife and kids, and reading non-fiction books. Connect with him on LinkedIn at https://www.linkedin.com/in/mafaneh.

15 Comments

  1. yunushkin88 September 8, 2017 at 3:20 pm - Reply

    Good evening!!! Great explanation. Will there be a post where is described how to achieve maximum range with Bluetooth and 5 is it possible to organize the mesh network over the 5 Blutooth not making life too difficult?)) Thank you!!!

    • Mohammad Afaneh
      Mohammad Afaneh September 10, 2017 at 10:08 pm - Reply

      Thanks, yunushkin88!

      Yes, there will be a follow-up post on how to achieve longer range using Bluetooth 5. Another one covering Bluetooth Mesh will also follow!

  2. Tim September 22, 2017 at 5:42 am - Reply

    Hi, it so great work and awesom description of understanding BLE throughput.

    But you have a mistake in cases:
    Case 3 (PHY: 1 Mbps, ATT MTU = 158 bytes, DLE: enabled, Connection interval: 7.5 millisecs)
    Case 4 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 7.5 millisecs)
    Case 5 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 50 millisecs)
    Case 6 (PHY: 2 Mbps, ATT MTU = 247 bytes, DLE: enabled, Connection interval: 400 millisecs)

    You use 1 byte preambule for 2Mbps during in real it 2 bytes.

    Thank you!

    • Mohammad Afaneh
      Mohammad Afaneh September 22, 2017 at 3:16 pm - Reply

      Tim, thanks!

      Yes, you’re absolutely correct (except Case 3 is 1 Mbps so it’s already correct) – thanks for the correction. I’ve gone ahead and fixed the miscalculations.

  3. Stayhungry October 4, 2017 at 10:13 am - Reply

    Thank you for sharing!!!But I want to know why to choose 50ms and 400ms these two values ​​for connInterval, is there a special significance

    • Mohammad Afaneh
      Mohammad Afaneh October 4, 2017 at 9:53 pm - Reply

      Thanks.

      The only reason was that I used the existing example from Nordic and they had those values built in and easy to choose from a menu via the Serial port. They can easily be changed, however.

  4. Youssef November 13, 2017 at 11:01 am - Reply

    Dear Mohammad, thanks a lot. Great und understandable overview.
    I have a question regarding Audio Streaming.

    Is it possible to stream audio signal for example 345 kbit/s using Bluetooth5/BLE?

    Thanks, Youssef

    • Mohammad Afaneh
      Mohammad Afaneh November 13, 2017 at 1:02 pm - Reply

      Thanks, Youssef. Glad you’ve found it useful!

      Yes, in theory, it’s possible. However, there are two things to keep in mind:
      – Power consumption will be very high when streaming data at this speed for prolonged periods of time.
      – Latency may become an issue, depending on the application. For example, if you have the central device communicating with other peripherals, then the data rate may get affected, as well as the latency. You’ll also need to make sure that the different connection parameters are chosen appropriately to allow for this kind of behavior/application (streaming data at the specified frequency).

      There’s a new spec in the works to allow audio over BLE. I don’t know the timeline for the release of this spec, but it’s definitely coming in the future.

      Hope this helps!

  5. Björn December 13, 2017 at 6:39 am - Reply

    Hello Mohammad,

    I am currently working on this throughput example on two Nordic nRF52840 DKs and trying to calculate the theoretical throughput values and compare them to the real ones.
    Already for case 1 (att_mtu: 23, conn_interval: 7.5, dle: on, phy: 1M) I am a little bit confused. I am getting a throughput of roughly 86 kbps. Your calculation is based on packet transmission times and the asumption, that 11 packets are transmitted in one connection interval, but isn’t Nordic giving 6 as the maximum number of packet transfer per interval (S132, SoftDevice Specification v5.1, Page 56, Table 27: Maximum peripheral packet transfer per Bluetooth low energy Radio Event for given combinations of Radio Notification distances and connection intervals)? If I calculate the throughput by [connections per second] * [data per packet] = (1000 ms/7.5 ms) * 20 bytes * 8 = 21,3 kbps and multiply it by 4 (just one of Nordics given numbers for packet transfer), I will get ~85 kbps.

    I completely understand you way for the theoretical calculation, which absolutely makes sense to me, but the result from your throughput test isn’t clear to me. From which SDK do you have taken this example?

    Thanks and regards,
    Björn

    • Mohammad Afaneh
      Mohammad Afaneh December 16, 2017 at 8:01 am - Reply

      Hi Björn,

      I used the example source code provided by Nordic for the Bluetooth 5 throughput test, available here. I can see what you’re referring to in terms of maximum packets/connection interval – I hadn’t seen that before. Interestingly, in the example, I was using s140 (not s132), and I can’t find the spec for the s140 (though I imagine it probably has the same restriction).

      If the max 6 packets/connection interval is true, then I’m not sure how I’m seeing a throughput of 232.29 Kbits/s reported by the firmware (which is very close to the calculated value).

      Have you asked on the Nordic DevZone forum about this?

      • homeslashbjrn December 18, 2017 at 2:16 pm - Reply

        Thanks for your answer.

        I am using the s140 SoftDevice too, as I am developing on nRF52840 DKs. Maybe I will try this example on s132, but I doubt that there will be any differences. I haven’t found any specs for the s140.

        Are you sure, that you enabled the Data Length Extension? A test run with the same parameters, but with DLE “enabled” instead of “disabled” will lead to ~250 kbps, which is on the other side not as close to your calculation.

        I also thought about influences by the Connection Length Extension. In the Nordic examples, it is enabled by default and if I understood it correctly, it will increase the number of packets per Connection Intervall. Maybe that’s the reason why it is possible to transmit more packets than 6.

        I posted a question in the comment section regarding this throughput example. Hoping for an answer in another question in the Developer Zone.

        Case 2 for example also differs from my runs. Here are some measurements I have made:

        att_mtu, conn_interval, dle, dle, phy, time, throughput
        23, 6, on, on, 1 Mbps, 97.582, 85.96
        23, 6, off, on, 1 Mbps, 33.544, 250.07
        23, 6, on, on, 2 Mbps, 43.373, 193.40
        23, 6, off, on, 2 Mbps, 30.44, 279.21
        247, 6, on, on, 1 Mbps, 10.673, 786.06
        247, 6, off, on, 1 Mbps, 26.662, 314.66
        247, 6, on, on, 2 Mbps, 8.05, 1048.05
        247, 6, off, on, 2 Mbps, 24.611, 340.89

  6. neo December 25, 2017 at 9:12 pm - Reply

    Hi, Mohammad

    Do you have experience about how fast could the latest BLE-5 capable smart phone achieve (iPhone8/X, Galaxy8/Note, etc).
    Even devices can support up to 1.4Mbps, many smart phone and OS has limitation, I want to know what is the realistic speed from phone to device. Thanks.

    • Mohammad Afaneh
      Mohammad Afaneh February 6, 2018 at 5:50 am - Reply

      Hi Neo,

      So sorry for the latte response – missed your message somehow.

      I don’t have much experience with the mobile side, and I haven’t done much testing between a mobile phone and an embedded device. However, I’ve seen videos on YouTube that demonstrate comparable speeds to 1.4 Mbps between a phone and a development kit, both running Bluetooth 5.

  7. Antoine February 6, 2018 at 5:18 am - Reply

    Hi Mohammad,
    Thanks for your greats articles on BLE 5, it really helps !
    When do you expect to release your new post about range with BLE 5

    • Mohammad Afaneh
      Mohammad Afaneh February 6, 2018 at 5:53 am - Reply

      Hi Antoine,

      Thanks for the positive feedback!

      I know my content has been lacking recently, and my post on Bluetooth 5 range is way overdue! However, my focus in the past few months has been on my upcoming e-book which will be released next month. The topic is covered in my e-book so I promise to cover it here on my blog (shortly after the release of the e-book).

      Thanks,
      Mohammad

Leave A Comment