BLE throughput optimization isn’t about achieving a single number, and it isn’t a single decision. It’s the product of configuration choices made across multiple layers of the stack, from PHY selection at the physical layer all the way up to how your application queues outgoing data. This page collects the most common questions developers run into along the way, with direct answers and links to the full articles where the topic warrants a deeper look.
If you want the full picture before jumping into specific questions, here are the other articles in the series:
- The Fundamentals of BLE Throughput: What’s Possible and Why
- 1M vs. 2M vs. Coded PHY: Choosing the Right BLE PHY for Throughput
- BLE ATT MTU, DLE, and Message Sizing: The Biggest Levers for BLE Throughput
- BLE Connection Interval and Peripheral Latency: How to Configure for Throughput
- BLE Transfer Methods and Application Design for Throughput
Understanding BLE Throughput
What throughput can BLE actually achieve?
With the right configuration, BLE can achieve up to 178 kB/s between two embedded devices, or around 90-100 kB/s when a mobile device is on one end of the connection. Those are real numbers, but they require deliberate configuration decisions across every layer of the stack. They aren’t defaults you’ll hit right out of the gate. For a full breakdown of where those numbers come from, see our article on BLE Throughput Fundamentals.
Why is my BLE throughput slow?
Slow BLE throughput almost always traces back to one of a handful of misconfigured settings: DLE not enabled, ATT MTU left at its default, the wrong ATT operation, or connection parameters that aren’t optimized for your platform. The tricky part is that these settings interact, so getting one right without the others may produce little or no improvement. Dig into our articles on PHY selection, DLE, ATT MTU, and Message Sizing, and connection parameters to work through the most common culprits layer by layer.
Does BLE encryption affect throughput?
Yes, but only marginally. Enabling Bluetooth’s built-in security adds a 4 byte Message Integrity Check to each packet, which drops the theoretical maximum from 178kB/s to 176 kB/s (under the correct conditions), a difference small enough that it shouldn’t factor into most decisions. This is covered in greater depth in our article on DLE, ATT MTU, and Message Sizing.
PHY Selection
What is the difference between 1M PHY, 2M PHY, and Coded PHY?
PHY mode determines how bits are physically transmitted over the air. 1M PHY is the default and transmits at 1 megabit per second. 2M PHY doubles the bit rate to 2 megabits per second, making it the better choice for throughput in most cases. Coded PHY trades speed for range and interference resilience; it’s designed for reliability, not throughput. For a full breakdown, see our article on PHY Selection for BLE Throughput.
Does 2M PHY actually double my throughput?
Not quite. 2M PHY is roughly 77% faster than 1M PHY, rather than 100%, because the radio idle periods (the interframe spacing and the gaps between connection events) are constant regardless of PHY mode. Those idle periods dilute the gain. That said, 2M PHY is still the right choice for most throughput-focused applications.
When should I use Coded PHY?
Coded PHY is the right choice when range or interference resilience matters more than speed. Think dense RF environments, edge-of-range deployments, or applications where dropped packets are more costly than lower throughput. If maximizing data transfer speed is the goal, Coded PHY is generally off the table.
Stack Configuration
What is Data Length Extension (DLE) and do I need it?
DLE increases the maximum Link Layer payload from 27 bytes to 251 bytes, translating to a 3.5x increase in throughput. Without it, throughput is capped at around 54 kB/s regardless of other configurations. So yes, you need it. Most stacks either enable it by default or expose it as a setting called maxTxOctets or maxRxOctets. See our article on DLE, ATT MTU, and Message Sizing for more configuration details.
What should I set my ATT MTU to?
As high as your stack supports, ideally 498 bytes or higher, with 247 bytes as a minimum. The ATT MTU determines the maximum size of a single ATT message, and leaving it at the default of 23 bytes means DLE has nothing meaningful to work with even if it’s enabled. The two settings have to be configured together to produce any real gain.
Why is my BLE throughput still slow after enabling DLE?
DLE sets the ceiling at the Link Layer but the layers above it have to be sized to take advantage of it. If ATT MTU is still at its default, DLE is effectively doing nothing. The same applies to message sizing. Sending the wrong payload size introduces fragmentation or other overhead that quietly limits throughput even when everything else looks right. All three settings have to move together. We dive into this in greater detail in our article on DLE, ATT MTU, and Message Sizing.
What is the optimal BLE payload size?
244 or 495 bytes. These are the ATT payload sizes that result in fully packed Link Layer packets when DLE is enabled. Adding just one byte beyond either target forces an additional Link Layer packet carrying a single byte of payload, which drops throughput significantly. With 495 byte payloads theoretical maximum application throughput is 177.8 kB/s and with 496 bytes it drops to 156.2 kB/s.
Connection Parameters
What connection interval should I use for high throughput?
15ms is the sweet spot for most applications. It’s the lowest connection interval accepted by iOS, and while Android accepts intervals down to 7.5ms there’s generally no throughput benefit below 15ms. Lower intervals mean faster recovery from packet errors, but going too low can actually hurt performance depending on your stack. See our article BLE Connection Interval and Peripheral Latency for the full picture.
What should I set Peripheral Latency to?
Zero, if you need high throughput in the Central to Peripheral direction. Peripheral latency allows the Peripheral to skip connection events, which directly limits how often it can receive data. There’s no impact in the Peripheral to Central direction because the Peripheral can send data in any connection event regardless of the latency setting.
Why does BLE throughput behave differently on iOS and Android than on my embedded device?
On proprietary devices, you control both ends of the connection and the radio can transmit nearly continuously. On mobile platforms the OS decides how much of the connection interval is actually allocated to BLE, and it shares that time with WiFi and other radio activity. We’ve observed iOS allocating roughly 50% of a 15ms connection interval to BLE with a single connection, effectively cutting theoretical throughput in half. Android shows more variability. Our article on BLE Connection Interval and Peripheral Latency dives into greater details.
Can I run multiple BLE connections without affecting throughput?
Not without a cost. Multiple connections force the radio to divide air time between them, leading to shortened or missed connection events on each. There’s no reliable way to quantify the impact since it depends on the number of connections, their intervals, and how your stack manages them. If high throughput is the goal, avoid multiple simultaneous connections where possible and disable advertising while connected.
Application Layer
Write Command vs. Write Request — which is faster?
Write Command is significantly faster. Write Requests are synchronous, so the GATT Server has to send a Write Response before the next message can go out, which typically limits you to one ATT operation every one or two connection events. Write Commands are asynchronous and can be sent back-to-back, allowing multiple messages per connection event. The same applies in the other direction: Notifications outperform Indications for the same reason.
My BLE stack is configured correctly, but throughput is still slow. What am I missing?
Three places to check. First, make sure you’re using Write Commands and Notifications rather than Write Requests and Indications. The wrong ATT operation limits you to one message per connection event regardless of how well the stack is configured. Second, check that your transmit pipeline is staying fed. If the stack runs out of queued data before a connection event ends that air time is wasted and there’s nothing the stack can do about it. Third, the RF environment may be harsh, leading to packet errors and internal stack retries. In such scenarios, smaller packets or a different PHY mode may counterintuitively improve throughput. For a deeper dive on these possibilities, check out our articles on 1M vs 2M vs Coded PHY and BLE Transfer Methods and Application Design.
How do I send large amounts of data over BLE?
ATT operations are capped at 512 bytes, so large payloads need to be segmented at the application layer. The right approach is to break your data into 244 or 495 byte chunks and reassemble them on the receiving side. A common pattern is to prepend a small custom header to each segment with a segment ID and count so the receiver knows how to put it back together. For more detail, see our article on BLE Transfer Methods and Application Design.
Does sending data in both directions reduce throughput?
Yes. BLE is half-duplex, so it can only transmit in one direction at a time. When sending data in both directions simultaneously, throughput in each direction drops to around 103 kB/s. If maximizing throughput in a single direction is the goal, minimize traffic in the opposite direction.
Where to Go Next
If you didn’t find what you were looking for, or you want to dig into a topic in more depth, our BLE throughput series page has the full set of articles.
