When your phone connects to a fitness tracker or a tablet links up with a medical device, there’s an entire conversation happening beneath the surface. Bluetooth Low Energy’s connection process is what makes these interactions both reliable and power-efficient. But if you’re new to BLE, this handshake between devices can feel like a black box.
This article unpacks that black box. We’ll walk through how BLE devices find each other and establish connections, focusing on the decisions you’ll need to make and the tradeoffs you’re navigating at each stage. By the end, you’ll understand not just what happens when you call connect() in your code, but why you’re choosing specific parameters and what happens when you get those choices wrong.
BLE Device Roles: Central and Peripheral
Before we dive into the connection flow, we need to establish the two main characters in any BLE interaction: the central and the peripheral.
The peripheral is typically the smaller, battery-constrained device. Think fitness trackers, sensors, medical devices, or smart home gadgets. Its job is to advertise its presence, broadcasting “I’m here and available” to anyone listening.
The central is usually the device with more processing power and a bigger battery, like your phone, tablet, or laptop. The central scans for advertisements, decides which device it wants to talk to, and initiates the connection.
This division of labor is intentional. By making the peripheral the “broadcaster” and the central the “decision maker,” BLE keeps power consumption low on the devices that need it most. The peripheral doesn’t need to constantly scan for other devices or manage complex connection logic. It just calls out at regular intervals and waits for someone to respond.
Think of it like two people trying to find each other in a crowded room. The peripheral stands in one spot and occasionally shouts their name. The central walks around, listening for that specific name, and when they hear it, they walk over to start a conversation.
Advertising: How Devices Announce Themselves
Advertising is how a peripheral makes itself known. At regular intervals, the peripheral broadcasts small packets of data called advertising packets on three dedicated channels (channels 37, 38, and 39). These channels are spread across the 2.4 GHz spectrum and positioned to avoid interference from Wi-Fi.
If you’ve ever opened LightBlue or nRF Connect and watched devices pop up in the scan list, you’re seeing the result of advertising in action. Each entry represents a peripheral that’s currently calling out, waiting to be discovered.
But here’s where your first major design decision comes in: how often do you advertise?
Choosing Your Advertising Interval
Your advertising interval is fundamentally a trade-off between discovery speed and battery life. And the stakes are higher than you might think.
Let’s say you’re building a medical device that patients interact with via a mobile app. If you advertise every 1000ms (once per second), the user might open your app and stare at a spinner for several seconds before the device appears. In user experience terms, that’s an eternity. Users may assume something’s broken. They’ll close the app, open it again, maybe restart their phone. You’ve just turned a technical parameter into a support ticket.
Now consider the same device advertising every 100ms. Discovery is nearly instant and the device pops up in the app within a fraction of a second. Great user experience. But you’re now transmitting 10 times as often, and each advertisement costs power.
And keep in mind that discovery is rarely as clean as “one advertisement, one detection.” Most phones and tablets share a single radio between BLE and Wi-Fi, which means the radio isn’t always listening on the BLE advertising channels. It typically takes several advertising packets before the scanner actually picks one up, which makes your effective discovery time longer than your advertising interval alone would suggest.
Power Consumption Impact of Advertising Intervals
The power consumption of advertising isn’t trivial. A typical BLE radio might draw 10-15mA during an advertising event. If you’re advertising every 100ms, that’s 10 events per second. Over the course of a day, if your device is continuously advertising (which many peripherals do when not connected), you’re talking about the difference between months and weeks of battery life.
Here’s the math that matters: advertising at 100ms vs 1000ms can mean the difference between a coin cell lasting 6 months versus 2 months. For a consumer device, that might be the difference between “replace the battery twice a year” versus “replace it six times a year.” For a medical device, it might determine whether your device meets the minimum battery life requirements in your design spec.
When Advertising Parameters Cause Discovery Problems
If you optimize too heavily for battery life with a long advertising interval:
- Discovery becomes frustratingly slow
- In noisy RF environments, the central might miss multiple advertising packets in a row, making discovery feel unreliable
- Users perceive your device as “flaky” or “hard to connect to”
If you optimize too heavily for discovery speed with a short advertising interval:
- Battery life takes a significant hit
- In dense BLE environments (think a hospital with dozens of devices), you’re contributing to congestion on those three advertising channels
- Your support costs go up because users are replacing batteries more often
So how do you find the sweet spot? It depends entirely on your use case. A medical device that patients interact with multiple times per day might justify 100-200ms intervals for a good user experience. A sensor that’s only accessed during setup or troubleshooting might use 1000ms or longer, sacrificing discovery speed for battery life since fast discovery isn’t critical to the primary use case.
Connectable vs. Non-Connectable Advertisements
Not all advertisements are invitations to connect. A connectable advertisement tells nearby centrals, “You can connect to me if you want.” A non-connectable advertisement is purely informational, often used for beacon-style devices that just broadcast data without ever establishing a connection.
The power difference between the two isn’t about the advertisement itself, it’s about what happens after. With a connectable advertisement, the peripheral has to briefly listen for incoming connection requests after each advertising event, which keeps the radio awake longer. A non-connectable (and non-scannable) advertisement lets the peripheral transmit and immediately go back to sleep, reducing the awake time per advertising event. If you’re building a beacon that periodically broadcasts sensor data, that savings adds up.
But if you need bidirectional communication (reading characteristics, writing data, receiving notifications) you need connectable advertisements. This brings us to the next stage: scanning.
Scanning: How BLE Devices Discover Others
While peripherals are advertising, centrals are scanning, monitoring those same three advertising channels for advertising packets. But centrals rarely listen continuously, which can make discovering peripherals trickier than it first appears.
Passive vs. Active Scanning: When Each Makes Sense
Passive scanning is straightforward: the central monitors the advertising channels, logs whatever it receives, and moves on. This is power-efficient and works perfectly when the advertising packet already contains everything you need to identify the device.
Active scanning adds a request-response exchange. When the central receives an advertisement, it sends back a scan request, and the peripheral responds with a scan response packet containing additional data like a longer device name, more service UUIDs, or custom manufacturer data. The trade-off is a bit more power consumption and RF overhead in exchange for more complete device information before you commit to a connection attempt.
Historically, active scanning was often necessary because legacy advertising packets are limited to just 31 bytes each. But if your peripheral supports BLE 5, extended advertisements allow up to 254 bytes per packet or up to 1,650 bytes when chaining multiple extended advertisements together. That’s usually more than enough to include all your identifying information in the advertisement itself, eliminating the need for active scanning entirely.
The trade-off is minimal additional power consumption and RF overhead versus more complete device information before you commit to a connection attempt.
The Scan Window and Interval: Timing Collision
Here’s where things get interesting. Your central has two parameters: scan interval (how often it checks for advertisements) and scan window (how long it listens during each interval). If you’re developing on mobile, it’s worth noting that iOS doesn’t expose these parameters at all, and Android only gives you limited control, so the tuning advice that follows applies most directly to embedded or desktop central implementations.
If your scan window equals your scan interval, you’re listening continuously which can be great for discovery, but rough on battery. If your scan window is shorter, you’re periodically taking breaks, which saves power but creates timing windows where you might miss advertisements.
Now add in the peripheral’s advertising interval. If your central is scanning with a 1000ms interval and 100ms window, and the peripheral is advertising every 1000ms, you’ve created a timing lottery. Sometimes you’ll catch the advertisement, sometimes you won’t, depending on whether the peripheral’s advertising event happens to overlap with your scanning window. And if the advertising interval and scanning interval are too close together, the timing can theoretically never align. The peripheral keeps advertising just outside your scan window, every single time.
This is why Apple publishes a set of recommended advertising intervals specifically optimized to collide with the scan window/interval combinations their devices use. If you’re building a peripheral that needs to work well with iPhones and iPads, these recommendations are worth following.
This is the timing collision problem. In the worst case, the two devices can be perfectly out of sync, with the peripheral advertising just after your scan window closes, every single time.
What Good Scan Parameters Look Like
For mobile apps where discovery speed matters and the user is actively looking at the screen:
- Scan continuously (window = interval) for the first few seconds
- Drop to a more conservative ratio after initial discovery
- This gives you fast discovery when it matters while preserving battery for background scanning
For background scanning or low-power central devices:
- Use a scan window that’s 25-50% of your interval
- Avoid a scan interval that’s a clean factor of the peripheral’s advertising interval, this is what creates those perfect collision scenarios where the timing never aligns
- If your peripheral needs to work with iOS and Android devices, follow Apple’s recommended advertising intervals. They’re designed to avoid these timing problems with the scan parameters mobile OSes use, and Android devices benefit from the same choices.
- Accept that discovery will be slower in exchange for better battery life
The failure mode you’re trying to avoid is simple but frustrating: the user opens your app, the device is sitting two feet away and actively advertising, but nothing shows up in the scan list for 10, 15, 20 seconds. From the user’s perspective, your app is broken. From your perspective, you’re just experiencing the timing collision problem.
Connecting: Where Everything Comes Together
Once the central finds the peripheral, it sends a connection request containing a set of connection parameters that define how the two devices will communicate going forward:
- Connection interval: How often they’ll exchange data (7.5ms to 4000ms, in 1.25ms steps). Note that many embedded stacks have you set a multiplier value rather than the millisecond value directly, so a multiplier of 80 gives you a 100ms interval.
- Peripheral latency: How many events the peripheral can skip when idle (0-499)
- Supervision timeout: How long without hearing from the peripheral before considering the connection lost (100ms to 32 seconds)
These aren’t arbitrary numbers you pull from an example. They’re the parameters that determine whether your connection works well for your specific use case.
How to Pick the Right Connection Interval for Your Use Case
Let’s start with the connection interval, because this is where the rubber meets the road, so to speak.
A 7.5ms connection interval means the devices are attempting to communicate 133 times per second. This is what you see in high-throughput applications like wireless audio or firmware updates. The radio is on frequently, power consumption is high, but data flows fast. BLE 6 pushes this even further, introducing support for connection intervals below 1ms for applications that need extremely high throughput or low latency, though hardware support is still limited.
A 100ms connection interval means 10 communication opportunities per second. This is typical for low-power sensors that send occasional readings. The radio spends most of its time off, battery life is great, but if you tried to stream audio over this connection, it would be choppy and awful.
Here’s how to device what’s right for your device:
Short intervals (7.5-20ms) when:
- You need high throughput (firmware updates, audio streaming)
- Latency matters (game controllers, medical devices with real-time feedback)
- The devices are plugged in or battery life isn’t the primary constraint
Medium intervals (20-100ms) when:
- You need moderate throughput (fitness data during a workout)
- Occasional responsiveness is important but not real-time
- You’re balancing battery life with user experience
Long intervals (100ms+) when:
- You’re sending infrequent data (temperature readings every few seconds)
- Battery life is the primary constraint
- Latency of a few hundred milliseconds doesn’t matter
How Connection Parameters Interact With Advertising
Your advertising choices and your connection parameters need to work together.
Remember that peripheral advertising every 100ms to provide fast discovery? Once connected, you might move to a 1000ms connection interval to save power. That’s fine because advertising stops once you’re connected anyway. But if your connection drops and the device goes back to advertising, that fast discovery is what gets the user reconnected quickly.
This is why many devices use shorter advertising intervals immediately following a disconnection(for good discovery) and request longer connection intervals once connected (for good battery life). You’re optimizing for different constraints at different stages of the lifecycle.
It’s worth thinking about how much of its life your peripheral will spend in each state. A device that’s connected 95% of the time can afford aggressive advertising intervals during that brief disconnected window. A device that spends most of its life advertising and only connects occasionally needs to prioritize advertising efficiency, since that’s where most of its power budget goes.
Peripheral Latency: The Hidden Power Saver
Peripheral latency is one of the most underutilized parameters in BLE. It lets the peripheral skip connection events when it has nothing to send, without the central assuming the connection is dead.
With a 100ms connection interval and peripheral latency of 4, the peripheral can sleep through up to 4 consecutive events (400ms) when idle. The central keeps the connection alive, but the peripheral is burning almost no power during these gaps.
This is especially powerful for devices with bursty data patterns. A heart rate monitor might send data every second during exercise, but when the user stops and takes a break, it has nothing to send. Peripheral latency lets it sleep during those idle periods without disconnecting.
The trade-off? The central can’t get instant responses during those latency periods. If the central writes a characteristic while the peripheral is sleeping through events, it has to wait for the peripheral to wake up. Communication in the other direction isn’t affected, though. If something happens on the peripheral, it can wake up and send data to the central at the next connection event immediately. For many use cases, this asymmetry is completely acceptable.
How Supervision Timeout Prevents Zombie Connections
The supervision timeout exists to detect dead connections. If this much time passes without successful communication, both devices give up and clean up the connection.
The math matters here: Supervision timeout > (1 + Peripheral latency) × Connection interval × 2
If you violate this, you’ll see spurious disconnections. The peripheral exercises its latency, sleeps through a few events, and suddenly the supervision timeout expires even though both devices are sitting right next to each other.
Keep in mind that platform constraints narrow this range further. iOS caps the supervision timeout at 6 seconds, while Android supports up to 30 seconds. If you’re targeting both platforms, you’re effectively designing for the iOS limit.
One common mistake is setting an aggressive supervision timeout (say, 1 second) with peripheral latency enabled. In noisy RF environments, you might miss a few connection events due to interference. The peripheral is still there, still functional, but your tight supervision timeout interprets this as a disconnect. Now you’re going through the whole reconnection dance (advertising, scanning, re-establishing connection) because you were too eager to declare the connection dead.
What Happens When You Get Connection Parameters Wrong
If the interval is too short for your use case:
- Battery drains faster than expected
- If you’re on iOS or Android, the OS might override your parameters to protect battery life
- Might cause issues for other devices in dense RF environments with many BLE devices
If the interval is too long for your use case:
- Users perceive lag when interacting with your device
- Throughput is lower than you need (firmware updates take forever)
- Notifications and indications feel sluggish
If the peripheral latency is too aggressive:
- Central can’t get responsive communication when it needs it, making actions initiated by the central seem slow
- If you miscalculate the supervision timeout math, spurious disconnections
If the supervision timeout is too short:
- False disconnections in normal RF conditions
- Users experience unreliable connections
- More reconnection attempts, more power consumption
If the supervision timeout is too long:
- When devices actually do disconnect (user walks away), it takes forever to detect and clean up
- Zombie connections that think they’re alive but aren’t
Why This Design Works
BLE’s connection process is built around a core principle: spend as little time transmitting as possible.
Advertising packets are tiny, containing just enough information to say “I’m here” and allow determination of whether a connection is needed, without burning through the battery. On embedded platforms, scanning can be tuned to balance discovery speed against power consumption. And once connected, devices only talk when they need to, skipping events when there’s nothing to say.
This is precisely what puts the “Low Energy” in Bluetooth Low Energy. This is why BLE can run on coin cell batteries for months or even years. The connection process itself is designed to be event-driven and opportunistic, rather than constantly active. Devices wake up, do their work, and go back to sleep in a carefully choreographed dance.
But that choreography only works when you understand the trade-offs at each stage and make intentional choices about what you’re optimizing for. Fast discovery or long battery life? High throughput or low power? Responsive communication or aggressive latency?
Every choice you make in configuring these parameters ripples through your device’s performance, power consumption, and user experience. Understanding how advertising intervals affect discovery, how scan windows create timing collisions, and how connection parameters interact with each other is what separates a BLE implementation that “kind of works” from one that works reliably in the field.
What to Read Next
Now that you understand how devices find and connect to each other, you’re ready to explore what happens after the connection is established. Start with How GAP and GATT Work: Bluetooth Low Energy Basics to understand the protocols that handle actual data exchange, service discovery, and characteristic interactions once that connection is live.
From there, The Ultimate Guide to Managing Your BLE Connection will help you tune connection parameters for your specific use case to balance responsiveness, throughput, and power consumption based on what your application actually needs.
And if you’re working on applications that need to secure data or maintain persistent device relationships, check out BLE Pairing and Bonding: What’s the Difference and When to Use Each to understand how authentication and encryption fit into the connection lifecycle.
The connection process is just the beginning. But it’s the foundation everything else is built on, and now you’ve got a solid mental model of how it all fits together.
