Sponsored by Nordic Semiconductor
If you’ve ever used a Bluetooth LE gaming mouse or VR controller, you’ve probably noticed something: there’s a slight delay between your input and the response on screen. For casual use, it’s barely noticeable. But for competitive gaming or immersive VR experiences, that delay can be the difference between a headshot and a miss—or the difference between presence and motion sickness.
The culprit? Latency, and more specifically for Bluetooth LE: connection intervals. Until now, Bluetooth LE connections have been limited to a minimum interval of 7.5 milliseconds. That might not sound like much, but for applications where every millisecond counts, it’s a real bottleneck.
Bluetooth Core v6.2 changes everything with Shorter Connection Intervals (SCI)—a feature that reduces the minimum interval all the way down to 375 microseconds. That’s a 20x improvement over the previous limit, enabling sub-millisecond communication cycles for the first time in Bluetooth LE’s history.
In this post, we’ll explore what Shorter Connection Intervals bring to the table and why they matter for your next product. We’ll also walk through a hands-on demo using Nordic’s nRF54L15 Development Kit to see SCI in action. Here’s what we’ll cover:
- What Shorter Connection Intervals are and why they matter
- The technical changes in Bluetooth Core v6.2 that enable SCI
- The dependencies you need to know about (Connection Subrating and Frame Space Update)
- Practical limits and what’s achievable today
- A hands-on demo with the nRF54L15 Development Kit
- Key considerations for your design
Let’s dive in.
The Latency Problem
Before we get into the specifics of Shorter Connection Intervals, let’s step back and understand why connection intervals matter in the first place.
In a Bluetooth LE connection, the Central and Peripheral don’t communicate continuously. Instead, they wake up at regular intervals to exchange data, then go back to sleep to conserve power. This interval—the connection interval—determines how often these exchanges happen.
Prior to Bluetooth Core v6.2, the minimum connection interval was 7.5 ms with a resolution of 1.25 ms. For many applications (fitness trackers, smart home sensors, medical devices), this is perfectly adequate. But for latency-sensitive use cases, 7.5 ms can feel like an eternity:
- Gaming peripherals: A gaming mouse with a 7.5 ms connection interval translates to roughly 133 Hz polling rate. Competitive gamers expect 1000 Hz or higher.
- AR/VR controllers: Immersive experiences require tight synchronization between your hand movements and what you see. Even small delays break the illusion.
- Real-time industrial sensors: Factory automation and robotics demand predictable, low-latency data delivery.
- Pen tablets and styluses: Artists and designers need responsive input that feels like pen on paper, not pen on molasses.
The gaming peripheral market, in particular, has been stuck in a frustrating situation. Proprietary 2.4 GHz protocols can achieve sub-millisecond latency, but they require dedicated dongles and sacrifice the interoperability benefits of Bluetooth. Until now, developers had to choose between low latency and universal compatibility.
Shorter Connection Intervals finally closes that gap.
What’s New in Bluetooth Core v6.2
Let’s take a closer look at what the Bluetooth Core v6.2 specification actually changes to enable Shorter Connection Intervals.
The New Limits
The headline numbers are impressive:
| Parameter | Before Bluetooth Core v6.2 | With Bluetooth Core v6.2 |
|---|---|---|
| Minimum interval | 7.5 ms | 375 µs |
| Resolution | 1.25 ms | 125 µs |
| Improvement | — | 20x shorter, 10x finer |
This means connection intervals can now be configured in 125 µs increments, all the way down to 375 µs (0.375 ms). For a gaming mouse, that translates to a theoretical polling rate of over 2,600 Hz—well beyond what even the most demanding competitive gamers need.
Three Connection Interval Value Types
To maintain backward compatibility while enabling these new capabilities, Bluetooth Core v6.2 introduces three categories of connection interval values:
| Type | Name | Range | Resolution | When Used |
|---|---|---|---|---|
| BCV | Baseline Connection Interval Values | ≥7.5 ms | 1.25 ms | Mandatory when SCI is supported |
| RCV | Rounded Connection Interval Values | ≥1.25 ms | 1.25 ms | Mandatory when SCI supported |
| ECV | Extended Connection Interval Values | ≥375 µs | 125 µs | Optional extension for ultra-low latency |
Here’s how to think about these:
- BCV (Baseline) ensures backward compatibility. Devices that don’t support SCI continue to work exactly as before.
- RCV (Rounded) is the new mandatory baseline for SCI-capable devices. If your Controller supports SCI, it must support all RCV values (1.25 ms and above).
- ECV (Extended) unlocks the full potential of SCI. These values go below 1.25 ms and provide the finest granularity (125 µs steps). Support for ECV is optional, so you’ll want to verify your specific platform’s capabilities.
When a new connection is formed, it always starts with an interval in the BCV range (7.5 ms or higher). The devices can then negotiate shorter intervals using the new procedures we’ll discuss next.
New Link Layer PDUs
The legacy LL_CONNECTION_UPDATE_IND PDU wasn’t flexible enough for the new requirements, so Bluetooth Core v6.2 introduces two new Link Layer control PDUs for connection rate negotiation:
LL_CONNECTION_RATE_REQ— Sent by the Peripheral to propose new timing parameters. This PDU includes the acceptable interval range, subrate factors, latency, continuation number, timeout, preferred periodicity, and up to four candidate anchor offsets.LL_CONNECTION_RATE_IND— Sent by the Central to confirm and enforce the final parameters. This PDU specifies the exact interval, window offset, and the instant (event count) at which the new parameters take effect.
The key difference from the legacy approach is flexibility. The Peripheral can now propose a range of acceptable intervals, and the Central chooses the final value within that range. This negotiation happens at the Link Layer, keeping the process efficient and deterministic.
ACL Flush Mechanism
Here’s a subtle but important addition: at shorter connection intervals, stale data becomes a real problem.
Imagine a gaming mouse sending position updates every 750 µs. If one packet gets delayed due to interference and requires retransmission, the packets behind it start to pile up. By the time the retransmission succeeds, you might have several “old” position updates waiting in the queue. Transmitting all of them would add latency and waste airtime—but in a traditional Bluetooth LE connection, you have no choice.
Bluetooth Core v6.2 introduces LE Flushable ACL Data to solve this. The Host can now mark certain packets as “flushable” and specify a flush timeout. If a packet sits in the queue longer than the timeout before its first transmission attempt, the Controller discards it. This keeps the data stream fresh and responsive.
I recommend using flushable data for any application where freshness matters more than guaranteed delivery—gaming inputs, real-time sensor readings, and similar use cases.
SCI Dependencies
Shorter Connection Intervals (SCI) doesn’t exist in isolation. To fully support SCI, your Controller needs to support features introduced in Bluetooth Core v5.3 and v6.0. Let’s walk through what you need to know.
Connection Subrating (Bluetooth Core v5.3) — Mandatory
If your Controller supports SCI, it must also support Connection Subrating. This isn’t optional—it’s a hard requirement in the specification.
According to the Bluetooth Core Specification:
“Connection subrating is a means of quickly modifying the effective connection interval of an existing LE ACL connection. It is accomplished by the Central and Peripheral skipping most of the underlying connection events; for example, if the subrating factor is set to 7 then only every 7th connection event is used.”
— Bluetooth Core v6.2, p. 313
Connection Subrating, introduced in Bluetooth Core v5.3, allows devices to skip connection events to save power while maintaining the connection. When connection subrating is applied to an existing connection, the active duty cycle may be quickly reduced—saving power—but the original connection interval can be quickly restored for improved throughput when needed.
Why does SCI depend on it? The new LL_CONNECTION_RATE_REQ PDU includes subrate factor parameters as part of the negotiation. The subrate factor and latency are negotiated alongside the connection interval itself, with a specific constraint:
SubrateFactorMax × (Max_Latency + 1) ≤ 500This integration makes sense when you think about it: shorter connection intervals mean more frequent wake-ups, which could dramatically increase power consumption. Connection Subrating provides a mechanism to balance latency and power by allowing devices to skip events when they don’t have data to send.
Frame Space Update (Bluetooth Core v6.0) — Recommended
While not strictly mandatory, Frame Space Update (FSU) is highly recommended if you want to fully utilize Shorter Connection Intervals.
In traditional Bluetooth LE, there’s a fixed 150 µs gap (called T_IFS, or Inter Frame Space) between adjacent packet transmissions within a connection event. This timing was baked into the specification and couldn’t be changed.
According to the Bluetooth Core Specification:
“A Controller that supports the Frame Space Update feature shall support a minimum frame space value that is less than or equal to 145 µs or support a maximum frame space value that is greater than or equal to 155 µs (or both)”
— Bluetooth Core v6.2, p. 3188
Frame Space Update, introduced in Bluetooth Core v6.0, makes T_IFS negotiable. Devices can agree on values shorter or longer than 150 µs, depending on their capabilities and requirements. The negotiation uses two new Link Layer PDUs:
LL_FRAME_SPACE_REQ(Section 2.4.2.54) — Initiates the negotiationLL_FRAME_SPACE_RSP(Section 2.4.2.55) — Responds with agreed parameters
Why does this matter for SCI? When your connection interval is only 750 µs, every microsecond counts. If you’re stuck with a fixed 150 µs gap between packets, that’s a significant portion of your available time. FSU allows tighter packet spacing, making shorter intervals more practical and efficient.
Dependency Summary
| Feature | Spec Version | Required for SCI? | Purpose |
|---|---|---|---|
| Connection Subrating | Bluetooth Core v5.3 | Mandatory | Power optimization through event skipping |
| Frame Space Update | Bluetooth Core v6.0 | Recommended | T_IFS negotiation below 150 µs |
| LE Flushable ACL Data | Bluetooth Core v6.2 | Optional | Prevents stale data buildup |
- When evaluating platforms for SCI support, make sure to verify support for Connection Subrating at a minimum.
- FSU support will give you the best performance, especially at the shortest intervals.
Practical Limits — Theory vs. Reality
The specification allows connection intervals as short as 375 µs, but what can you actually achieve in practice?
Here’s the reality: reaching the theoretical minimum is extremely difficult due to Bluetooth stack overhead. Processing packets, running the protocol state machine, and handling application logic all take time. Most implementations today can’t get all the way down to 375 µs.
Nordic’s current support looks like this:
| Platform | Minimum Supported Interval |
|---|---|
| nRF54L Series | 750 µs |
| nRF52 Series, nRF53 Series, nRF54H Series | 875 µs |
These numbers may improve with future SDK optimizations, but they represent what’s achievable today with the nRF Connect SDK.
Now, before you get disappointed, let’s put this in perspective:
- 750 µs is still a 10x improvement over the previous 7.5 ms minimum
- Both values are sub-1ms, which is the “magical limit” for high-performance HID devices
- A 750 µs interval translates to roughly 1,333 Hz polling rate—well above the 1,000 Hz that competitive gamers consider the gold standard
In other words, even without hitting the theoretical minimum, SCI delivers the performance that gaming peripherals and other latency-sensitive applications have been waiting for.
Exploring Nordic’s Stock SCI Sample
If you want to dive deeper into how SCI works at the protocol level, Nordic provides a comprehensive shorter_conn_intervals sample in the nRF Connect SDK. This sample is perfect for understanding the underlying mechanics and for analyzing the connection with a Bluetooth protocol sniffer.
Let’s walk through how this sample works and what you’ll see when you capture the traffic.
What the Sample Does
The stock sample demonstrates the complete SCI negotiation flow:
- Establishes a connection between two nRF54L15 development kits
- Enables encryption using Just Works pairing
- Updates PHY to LE 2M (required for shortest intervals)
- Negotiates Frame Space Update to reduce inter-frame spacing
- Cycles through connection intervals every 3 seconds: 750 µs → 1 ms → 1.25 ms → 2 ms → 4 ms
- Measures transmission latency using a custom GATT Latency service
The sample continuously performs GATT write operations and measures round-trip time, providing real-time latency data at each interval.
Key Code Components
Here are the critical functions that make SCI work:
1. Setting Connection Rate Defaults
Before any connection rate updates can happen, the sample configures the default parameters:
static int set_conn_rate_defaults(uint32_t interval_min_us, uint32_t interval_max_us)
{
const struct bt_conn_le_conn_rate_param params = {
.interval_min_125us = interval_min_us / 125,
.interval_max_125us = interval_max_us / 125,
.subrate_min = 1,
.subrate_max = 1,
.max_latency = 5,
.continuation_number = 0,
.supervision_timeout_10ms = 400,
.min_ce_len_125us = BT_HCI_LE_SCI_CE_LEN_MIN_125US,
.max_ce_len_125us = BT_HCI_LE_SCI_CE_LEN_MAX_125US,
};
int err = bt_conn_le_conn_rate_set_defaults(¶ms);
if (err) {
LOG_WRN("Set default rate parameters failed (err %d)", err);
return err;
}
LOG_INF("SCI default connection rate parameters set (min=%u μs, max=%u μs)",
interval_min_us, interval_max_us);
return 0;
}The BT_CONN_INTERVAL_TO_ECV() macro converts microseconds to the Extended Connection Interval Value format used by the Bluetooth stack.
2. Frame Space Update
To achieve the shortest intervals, the sample negotiates reduced inter-frame spacing:
static int select_lowest_frame_space(void)
{
const struct bt_conn_le_frame_space_update_param params = {
.phys = BT_HCI_LE_FRAME_SPACE_UPDATE_PHY_2M_MASK,
.spacing_types = BT_CONN_LE_FRAME_SPACE_TYPES_MASK_ACL_IFS,
.frame_space_min = 0,
.frame_space_max = 150,
};
int err = bt_conn_le_frame_space_update(default_conn, ¶ms);
if (err) {
LOG_WRN("Frame space update request failed (err %d)", err);
return err;
}
/* Wait for frame space update to complete */
k_sem_take(&frame_space_updated_sem, K_FOREVER);
return 0;
}On the nRF54L15, this typically results in a frame space of approximately 63 µs—less than half the traditional 150 µs T_IFS.
3. Connection Rate Request
When cycling through intervals, the sample uses the Connection Rate Request procedure:
static int conn_rate_request(uint32_t interval_min_us, uint32_t interval_max_us)
{
const struct bt_conn_le_conn_rate_param params = {
.interval_min_125us = interval_min_us / 125,
.interval_max_125us = interval_max_us / 125,
.subrate_min = 1,
.subrate_max = 1,
.max_latency = 0,
.continuation_number = 0,
.supervision_timeout_10ms = 400,
.min_ce_len_125us = BT_HCI_LE_SCI_CE_LEN_MIN_125US,
.max_ce_len_125us = BT_HCI_LE_SCI_CE_LEN_MAX_125US,
};
int err = bt_conn_le_conn_rate_request(default_conn, ¶ms);
if (err) {
LOG_WRN("Connection rate request failed (err %d)", err);
return err;
}
return 0;
}Running the Sample
To build and run the stock sample:
- Locate the sample in your nRF Connect SDK installation
- Build for nRF54L15 using VS Code
- Flash both development kits
- Open serial terminals for both devices (115200 baud)
- Configure the devices:
- Device 1: Type
y(initiator), thenc(Central) - Device 2: Type
n(follower), thenp(Peripheral)
- Device 1: Type
You’ll see the connection form and watch as the interval cycles every 3 seconds, with latency measurements at each step (watch the video demo below).
Hands-On Demo with the nRF54L15
Key Considerations for Your Design
Before you rush to implement Shorter Connection Intervals in your product, there are a few important considerations to keep in mind.
Power Consumption Trade-offs
Shorter intervals mean more frequent radio activity, which means higher power consumption. There’s no way around this fundamental trade-off.
SCI is best suited for:
- Devices with larger batteries (gaming mice, VR controllers), where battery life is measured in days or weeks, not months or years
- Use cases where latency is more critical than long battery life (competitive gaming, real-time control)
- Burst activity patterns where you need low latency during active use but can relax intervals during idle periods (this is where Connection Subrating helps)
For always-on sensors or devices powered by coin cells, SCI probably isn’t the right choice. Stick with longer intervals and optimize for battery life instead.
Device Support and Compatibility
SCI requires support on both ends of the connection. Your Peripheral might support 750 µs intervals, but if the Central (phone, PC, gaming dongle) doesn’t support SCI, you’ll be limited to the legacy 7.5 ms minimum.
As of this writing, smartphone support for SCI is still emerging. For now, SCI is best suited for applications with dedicated central hardware:
- Gaming dongles (USB receivers)
- VR/AR headsets
- Custom Central devices you control
As Android and iOS (hopefully!) add SCI support in future releases, the ecosystem will open up. But for production designs shipping today, plan for dedicated host hardware if you need guaranteed SCI support.
What About Throughput?
You might be wondering whether shorter connection intervals translate to higher throughput. The answer is nuanced: SCI is optimized for latency, not throughput.
Here’s why: at very short intervals like 750 µs, connection events are so brief that you can only fit one small packet per event. The packet transmission time itself (a 251-byte packet at 2M PHY takes ~1 ms) exceeds the connection interval! So you’re limited to smaller payloads.
With longer intervals, such as 7.5 ms, you can pack multiple full-size packets into each connection event, which is more efficient for bulk data transfer. The math works out to roughly similar peak throughput (~1.5 Mbps) for both approaches, but with very different characteristics:
- SCI (750 µs): Small packets arriving very frequently—ideal for real-time control data
- Legacy (7.5 ms): Larger bursts less frequently—better for file transfers or streaming
If your application needs to move large amounts of data quickly, longer connection intervals with multiple packets per event will serve you better. SCI shines when you need each individual piece of data to arrive as fast as possible, even if that data is small.
Ultra-Low Latency HID Profile
You might have heard about the Bluetooth SIG’s work on an Ultra-Low Latency (ULL) HID profile. This profile is designed to standardize low-latency HID applications, building on SCI as a foundation.
As of the time of this writing (NovemberDecember 2025), the ULL HID profile isn’t available yet. You can absolutely use SCI today—it’s fully specified and implemented—but you’ll be doing so outside the context of a standardized profile. This means more flexibility in your implementation, but also more work to ensure interoperability.
When ULL HID does arrive, expect it to provide standardized service definitions, report formats, and best practices for latency-sensitive HID applications.
Summary
In this post, we covered a lot of ground:
- The latency problem: Why 7.5 ms connection intervals were limiting for gaming, VR, and real-time applications
- What’s new in Bluetooth Core v6.2: The SCI feature, including BCV/RCV/ECV value types, new Link Layer PDUs, and the ACL flush mechanism
- Dependencies: Connection Subrating (mandatory) and Frame Space Update (recommended)
- Practical limits: 750 µs on nRF54L, 875 µs on nRF52—both sub-1ms and a huge improvement over the legacy minimum
- Hands-on demo: How to test SCI using Nordic’s sample application
- Design considerations: Power trade-offs, host support, and the upcoming ULL profile
You should now be able to test Shorter Connection Intervals on your own Nordic development kit and evaluate whether sub-millisecond latency is the right fit for your next product.
For gaming peripherals, AR/VR controllers, and real-time sensing applications, SCI is a genuine game-changer. After years of proprietary 2.4 GHz protocols holding the performance crown, Bluetooth LE finally has the latency characteristics to compete—without sacrificing interoperability.
References
- nRF54L15 Product Page
- Getting Started with the nRF54L15
- Shorter Connection Intervals (SCI) nRF Connect SDK Sample
- Bluetooth Core Specification v6.2
- Bluetooth Core v6.2 Feature Overview
- Bluetooth Core v5.3 Feature Enhancements (Connection Subrating)
- Nordic DevZone: What’s New in Bluetooth Core 6.2
- nRF Connect SDK Documentation
