13  Bluetooth Connection Establishment

In 60 Seconds

Bluetooth connection establishment differs fundamentally between Classic (inquiry + paging) and BLE (advertising on channels 37/38/39 + scanning). BLE connection parameters – connection interval, peripheral latency, and supervision timeout – directly control the trade-off between responsiveness and power consumption for battery-powered IoT devices.

Key Concepts
  • Advertising PDU: BLE packet broadcast by a peripheral on channels 37/38/39 to announce presence; types include ADV_IND (connectable), ADV_NONCONN_IND, ADV_DIRECT_IND
  • Scanner (Passive/Active): Central device listening for advertising packets; active scanner sends SCAN_REQ to obtain additional data (SCAN_RSP)
  • CONNECT_IND: BLE packet sent by the initiator to a specific advertiser to establish a connection; contains connection interval, latency, and supervision timeout
  • Connection Parameters: Three values negotiated at connection: Interval (7.5 ms–4 s), Slave Latency (0–499 skippable intervals), Supervision Timeout (100 ms–32 s)
  • Bonding: Process of exchanging and storing Long Term Keys (LTK) and Identity Resolving Keys (IRK) so two devices can re-connect without full re-pairing
  • Pairing: Temporary key exchange procedure (Just Works, Passkey Entry, Numeric Comparison, OOB) resulting in a Short Term Key for the current session
  • IRK (Identity Resolving Key): 128-bit key used to generate and resolve Resolvable Private Addresses (RPAs), enabling privacy while allowing bonded devices to identify each other
  • Supervision Timeout: Maximum time without a valid packet before a BLE connection is declared lost; must be greater than (1 + Slave Latency) × Interval × 2
Minimum Viable Understanding

Bluetooth connection establishment differs fundamentally between Classic (two-phase inquiry + paging) and BLE (advertising on channels 37/38/39 + scanning). BLE connection parameters – connection interval, peripheral latency, and supervision timeout – directly control the trade-off between responsiveness and power consumption, and mastering their configuration is essential for any battery-powered IoT device.

13.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain the Classic Bluetooth discovery process (inquiry and paging phases)
  • Analyze BLE connection establishment through advertising and scanning state transitions
  • Configure connection parameters for optimal power and latency trade-offs
  • Implement connection event handling in BLE applications
  • Diagnose connection issues using state machine knowledge and supervision timeout calculations

When two Bluetooth devices want to communicate, they go through a connection process – advertising (announcing their presence), scanning (looking for nearby devices), and pairing (agreeing on security). Think of it like meeting someone at a party: you introduce yourself, exchange contact info, and agree on how to communicate.

“Making a Bluetooth connection is like making a new friend at school!” Sammy the Sensor explained. “First, I stand in the hallway and shout, ‘Hey, I am Sammy and I have temperature data!’ That is called advertising. Then a phone walking by hears me and says, ‘Oh, I want that data!’ That is scanning.”

“It is like a dance,” Lila the LED added. “First you wave to get someone’s attention – that is advertising. Then they wave back – that is scanning. Then you walk over and agree on which dance to do together – that is the connection. BLE uses three special advertising channels, like three different hallways where you can shout your message!”

Max the Microcontroller chuckled. “The clever part is the connection parameters. I get to control how often we talk – the connection interval – and how many times the sensor can skip check-ins – the peripheral latency. A heart rate monitor might check in every second, but a weather station only needs to check in every few minutes.”

“And that is where I get excited!” Bella the Battery exclaimed. “The higher the peripheral latency and the longer the connection interval, the more sleep time I get. It is like saying, ‘I will only wake up when I actually have something important to say.’ That is how we make batteries last for months instead of days!”

13.2 Prerequisites

Before diving into this chapter, you should be familiar with:

13.3 Classic Bluetooth Discovery

Classic Bluetooth uses a two-phase discovery and connection process:

13.3.1 Phase 1: Inquiry (Discovery)

The inquiry phase allows devices to find each other:

Process:

  1. Central broadcasts inquiry packets over 32 carriers
  2. Pseudo-random hopping over 79 MHz band
  3. Peripheral listens 11.25ms every 1.28s (when discoverable)
  4. Peripheral responds with address and clock offset

Timing:

  • Typical discovery time: 1-10 seconds
  • Peripheral must be in “discoverable” mode
  • Central learns peripheral’s BD_ADDR and clock for paging

13.3.2 Phase 2: Paging (Connection)

Once discovered, the central pages the peripheral to establish a connection:

Process:

  1. Central uses peripheral’s address to calculate hopping sequence
  2. Central transmits page packets on expected channels
  3. Peripheral responds and synchronizes clocks
  4. Piconet established with shared timing

Timing:

  • Typical paging time: 100ms - 3 seconds
  • Depends on peripheral’s scan interval
  • Faster if peripheral is in “connectable” mode

13.4 BLE Connection Establishment

BLE uses a simpler, more power-efficient discovery mechanism based on advertising channels.

13.4.1 Advertising Phase

The peripheral broadcasts its presence:

Advertising Channels:

  • Channels 37, 38, 39 (dedicated for advertising)
  • Positioned between Wi-Fi channels 1, 6, 11 for coexistence
  • Peripheral cycles through all three each advertising event

Advertising Packet:

  • Device name
  • Service UUIDs
  • Manufacturer data
  • TX power level (for distance estimation)

Advertising Parameters:

Parameter Range Default Impact
Interval 20ms - 10.24s 100ms Power vs discovery time
TX Power -20 to +20 dBm 0 dBm Range vs power
Mode Connectable, Scannable, Non-connectable Connectable Functionality

13.4.2 Scanning Phase

The central listens for advertisements:

Scanner Parameters:

Parameter Description Typical Value
Scan Interval How often to scan 100-200ms
Scan Window Duration of each scan 30-50ms
Scan Type Active (request more data) or Passive Active

Active vs Passive Scanning:

  • Passive: Just listen for advertisements
  • Active: Send scan request, receive scan response with additional data

13.4.3 Connection Request

When the central finds a suitable peripheral:

  1. Central sends CONNECT_IND packet on advertising channel
  2. Packet includes connection parameters:
    • Connection interval (7.5ms - 4s)
    • Peripheral latency (0-499 events)
    • Supervision timeout (100ms - 32s)
  3. Both devices switch to data channels
  4. Frequency hopping begins using agreed sequence

13.4.4 Connection Sequence

Peripheral                    Central
    |                           |
    |---[ADV_IND (Ch 37)]------>|  Advertising
    |---[ADV_IND (Ch 38)]------>|
    |---[ADV_IND (Ch 39)]------>|
    |                           |
    |<--[SCAN_REQ]--------------| Active scan
    |---[SCAN_RSP]------------->|
    |                           |
    |<--[CONNECT_IND]-----------| Connection request
    |                           |
    |---(Switch to data ch)-----|
    |                           |
    |<---[Empty PDU]------------| First connection event
    |----[Empty PDU]----------->|
    |                           |
    |---[Data exchange begins]--|

13.5 Connection Parameters

BLE connection parameters significantly affect power consumption and responsiveness.

13.5.1 Connection Interval

How often central and peripheral exchange data:

Interval Events/sec Use Case Power Impact
7.5ms 133 Gaming controllers Highest
30ms 33 Interactive apps High
100ms 10 Wearables Medium
500ms 2 Sensors Low
4000ms 0.25 Infrequent updates Lowest

Formula: Interval in 1.25ms units (e.g., 80 = 100ms)

13.5.2 Peripheral Latency

Number of connection events the peripheral can skip:

Example:

  • Connection interval: 100ms
  • Peripheral latency: 4
  • Effective wake rate: 100ms x 5 = 500ms (peripheral wakes every 5th event minimum)

Use Case:

A sensor that only sends data every 30 seconds can use high peripheral latency to skip most connection events, dramatically reducing power consumption.

// Connection parameters for a temperature sensor
// Updates every 30 seconds, needs quick response to phone requests
ble_gap_conn_params_t params = {
    .min_conn_interval = 80,    // 100ms minimum
    .max_conn_interval = 800,   // 1000ms maximum
    .slave_latency = 30,        // Can skip 30 events
    .conn_sup_timeout = 600     // 6 second supervision timeout
};
// Effective: wakes at least every 31 seconds (1000ms x 31 = 31s)

13.5.3 Supervision Timeout

Maximum time without successful exchange before disconnecting:

  • Minimum: 100ms
  • Maximum: 32 seconds
  • Must be > (1 + latency) x interval x 2

Example: With 100ms interval and latency 4, minimum timeout = (1+4) x 100ms x 2 = 1 second

The supervision timeout formula ensures the connection survives maximum latency without false disconnections.

\[\text{Min Timeout} = (1 + \text{Latency}) \times \text{Interval} \times 2\]

For a sensor with 500ms interval and latency 19 (wakes every 20th event for 10-second effective rate):

\[\text{Min} = (1 + 19) \times 500\text{ms} \times 2 = 20{,}000\text{ms} = 20\text{s}\]

With recommended 3× safety margin: Timeout = \(20\text{s} \times 3 = 60\text{s}\) prevents spurious disconnects from occasional packet loss.

Try It: BLE Connection Parameter Validator

Adjust connection parameters and verify that your supervision timeout meets the BLE specification requirements.

13.5.4 Knowledge Check: Connection Parameter Relationships

13.6 Connection Event Handling

Proper handling of connection events is crucial for robust BLE applications.

13.6.1 Connection Callbacks

// Server (Peripheral) callbacks
class MyServerCallbacks : public BLEServerCallbacks {
    void onConnect(BLEServer* pServer) {
        deviceConnected = true;
        connectionCount++;

        // Get connection handle for parameter updates
        uint16_t connId = pServer->getConnId();

        // Log connection
        Serial.println("Client connected!");
    }

    void onDisconnect(BLEServer* pServer) {
        deviceConnected = false;

        // Restart advertising for next connection
        pServer->startAdvertising();
        Serial.println("Client disconnected, advertising restarted");
    }
};

13.6.2 MTU Negotiation

After connection, negotiate larger packet sizes:

void onConnect(BLEServer* pServer) {
    // Request MTU exchange for larger payloads
    // Default MTU is 23 bytes (20 usable)
    // Request up to 517 bytes for efficiency

    esp_ble_gattc_send_mtu_req(gattc_if, conn_id);
}

void onMtuChanged(uint16_t mtu) {
    Serial.printf("MTU negotiated: %d bytes\n", mtu);
    // Usable payload = MTU - 3 (ATT header)
    maxPayload = mtu - 3;
}

13.6.3 Connection Parameter Updates

Dynamically adjust parameters based on activity:

// Workout mode: responsive updates
void enableWorkoutMode() {
    ble_gap_conn_params_t workout = {
        .min_conn_interval = 12,   // 15ms
        .max_conn_interval = 24,   // 30ms
        .slave_latency = 0,        // Respond every interval
        .conn_sup_timeout = 200    // 2 seconds
    };
    ble_gap_conn_param_update(conn_handle, &workout);
}

// Daily mode: power saving
void enableDailyMode() {
    ble_gap_conn_params_t daily = {
        .min_conn_interval = 80,   // 100ms
        .max_conn_interval = 400,  // 500ms
        .slave_latency = 10,       // Skip up to 10 events
        .conn_sup_timeout = 600    // 6 seconds
    };
    ble_gap_conn_param_update(conn_handle, &daily);
}

13.7 Bluetooth Addresses

Every Bluetooth device has a unique 48-bit address (BD_ADDR):

Structure:

  • Upper 24 bits: Organization Unique Identifier (OUI) - manufacturer ID
  • Lower 24 bits: Device-specific identifier
  • Format: 12-digit hex with colons (e.g., A4:C1:38:12:34:56)

Address Types (BLE):

Type Description Use Case
Public Fixed, IEEE registered Traditional devices
Random Static Fixed per boot, not registered Privacy-focused
Random Private Resolvable Changes periodically, resolvable by bonded devices Maximum privacy
Random Private Non-Resolvable Changes periodically, not resolvable Beacons

BLE Privacy:

BLE supports address rotation for privacy:

  1. Device generates random address periodically (every 15 minutes)
  2. Bonded devices can resolve address using stored IRK (Identity Resolving Key)
  3. Prevents tracking by unauthorized parties

13.8 Bonding and Pairing

13.8.1 Pairing

Creates temporary security for current session:

  • Authenticates devices
  • Generates session encryption keys
  • Enables encrypted communication

13.8.2 Bonding

Stores pairing information for future reconnection:

  • Auto-connect when in range
  • No user interaction needed for subsequent connections
  • Stores Long Term Key (LTK) for encryption

Pairing Methods:

Method Security Requirements Use Case
Just Works Basic Button only Simple devices
Numeric Comparison High Display on both Smartphones, tablets
Passkey Entry High Display + Keyboard One device has display
Out of Band Highest NFC, QR code Maximum security

Security Levels:

Level Encryption Authentication MITM Protection
1 None None No
2 Encrypted None No
3 Encrypted Authenticated Yes
4 LE Secure Connections Authenticated Yes

13.9 Troubleshooting Connection Issues

13.9.1 Common Issues and Solutions

Device not discovered:

  • Ensure advertising is active
  • Check advertising interval (too long = slow discovery)
  • Verify scan parameters on central
  • Check TX power and range

Connection fails immediately:

  • Verify connection parameters are valid
  • Check supervision timeout > (1 + latency) x interval x 2
  • Ensure both devices support the requested parameters

Connection drops frequently:

  • Increase supervision timeout
  • Reduce peripheral latency
  • Check for RF interference
  • Move devices closer together

Slow data transfer:

  • Negotiate larger MTU
  • Reduce connection interval
  • Set peripheral latency to 0 during transfers
  • Use notifications instead of indications

13.9.2 Debug Logging

void logConnectionParams(BLEServer* pServer) {
    uint16_t connId = pServer->getConnId();
    uint16_t mtu = pServer->getPeerMTU();

    Serial.printf("Connection ID: %d\n", connId);
    Serial.printf("Peer MTU: %d bytes\n", mtu);
    Serial.printf("Max payload: %d bytes\n", mtu - 3);
}

13.9.3 Knowledge Check: Connection Parameters

13.9.4 Knowledge Check: BLE Discovery

13.9.5 Knowledge Check: Bonding vs Pairing

13.10 Real-World Deployment: Connection Optimization at Scale

13.10.1 Tile (now Life360): 40 Million BLE Trackers

Tile’s item-tracking network, with over 40 million active BLE trackers and 500+ million smartphones in its crowd-finding mesh, faced extreme connection parameter challenges because their trackers must balance two contradictory requirements: maximum battery life (1 year on CR1632 coin cell, 137 mAh) and minimum discovery latency when a user actively searches for a lost item.

Advertising parameter evolution:

Tile iterated through three advertising strategies over 2016-2020:

Generation Advertising interval TX power Discovery time (median) Battery life
Tile 2016 (Gen 1) 1000 ms 0 dBm 8.2 seconds 8 months
Tile 2018 (Gen 2) 2000 ms -8 dBm 14.5 seconds 14 months
Tile 2020 (Gen 3) Adaptive: 2000/152 ms -8/+4 dBm 2.1 seconds when searching 12 months

The Gen 3 adaptive strategy was the breakthrough. In “quiet mode” (default), the tracker advertises every 2 seconds at low power, consuming 6 uA average. When any Tile app user within Bluetooth range triggers a “Find” request, the app sends a BLE scan request that includes a Tile-specific manufacturer data field. Nearby Tile trackers detect this (via the scan request callback in the BLE stack) and switch to “loud mode”: 152 ms advertising at +4 dBm for 30 seconds, then revert to quiet mode.

Power budget analysis for the 137 mAh CR1632:

Quiet mode (23.5 hours/day average):
  Advertising: 2000 ms interval, 3 channels, 0.3 ms TX each
  Active time: 0.45 ms per 2000 ms = 0.0225% duty cycle
  Current: 12 mA active x 0.000225 = 2.7 uA + 3.3 uA sleep = 6 uA
  Daily: 6 uA x 24 h = 144 uAh

Loud mode (0.5 hours/day average, 1 search event):
  Advertising: 152 ms interval, 3 channels, 0.3 ms TX at +4 dBm
  Active time: 0.9 ms per 152 ms = 0.59% duty cycle
  Current: 18 mA x 0.0059 = 106 uA
  Daily: 106 uA x 0.5 h = 53 uAh

Total daily: 197 uAh
Battery life: 137,000 uAh / 197 uAh/day = 695 days = 23 months (theoretical)
Real-world (self-discharge, temperature): approximately 12-14 months

Connection establishment for the finding network:

When a user’s phone connects to their own Tile for direct finding (playing the audible ring), Tile uses aggressive connection parameters:

  • Connection interval: 15 ms (minimum allowed for responsive audio playback)
  • Peripheral latency: 0 (respond every interval during active finding)
  • Supervision timeout: 2 seconds (detect lost connection quickly)
  • MTU: 185 bytes (negotiated to transfer location history in single ATT payload)

The connection is terminated immediately after the ring command completes (typically 5-15 seconds), and the tracker returns to advertising mode. This “connect, command, disconnect” pattern avoids the power drain of maintained connections.

The 40-million-device crowd-finding challenge:

The most interesting engineering was not the tracker itself but the smartphone mesh. Each Tile app performs passive BLE scanning in the background, and when it detects any Tile tracker (identified by Tile’s 16-bit company ID 0x0059 in the manufacturer-specific data), it reports the tracker’s encrypted identifier and the phone’s GPS coordinates to Tile’s cloud. A user who lost their keys in a park can see the last location where any Tile app user walked past their tracker. With 500 million phones scanning, the median time-to-location for a lost Tile in an urban area is 8 minutes.

13.11 Summary

This chapter covered Bluetooth connection establishment:

  • Classic Bluetooth uses two-phase discovery (inquiry + paging)
  • BLE uses advertising/scanning with three dedicated channels (37, 38, 39)
  • Connection parameters (interval, latency, timeout) trade off power vs responsiveness
  • MTU negotiation enables efficient large data transfers
  • Dynamic parameter updates allow adapting to activity levels
  • Bonding stores security keys for seamless reconnection
  • Address privacy in BLE prevents tracking through random address rotation

Scenario: A BLE fitness tracker with a CR2032 battery (225 mAh) needs to stream heart rate data to a smartphone during workouts while maximizing battery life during daily wear.

Given parameters:

  • Active workout mode: 2 hours/day, requires <100ms latency for real-time heart rate display
  • Daily wear mode: 22 hours/day, occasional app checks (every 15 minutes for sync)
  • Battery budget: 60 µAh/day to achieve 10-month battery life (225 mAh × 0.8 ÷ 300 days)
  • BLE radio current: 8 mA TX/RX active, 1.5 µA sleep

Workout mode parameters:

Parameter Value Calculation
Connection interval 30 ms 33 connection events/sec
Peripheral latency 0 Respond every interval (no skipping)
Supervision timeout 2 s (1+0) × 30ms × 2 × 3 = 180ms minimum, use 2s
Radio active time 3 ms/event 1.5ms TX + 1.5ms RX window
Duty cycle 3ms / 30ms = 10%

Energy during workout (2 hours):

  • Events per workout: 33/sec × 7,200sec = 237,600 events
  • Current per event: 8 mA × 3ms = 24 µAs
  • Sleep per interval: 1.5 µA × 27ms = 40.5 µAs
  • Energy per event: 24 + 0.04 = 24.04 µAs
  • Workout energy: 237,600 × 24.04 µAs = 5,711,904 µAs = 1.59 mAh

Daily wear mode parameters:

Parameter Value Calculation
Connection interval 1000 ms 1 event/sec
Peripheral latency 29 Skip 29 intervals, wake every 30th
Supervision timeout 90 s (1+29) × 1s × 2 = 60s minimum, use 90s with safety margin
Effective wake rate 1/30 sec Wake every 30 seconds
Radio active time 3 ms/wake

Energy during daily wear (22 hours):

  • Wakes per day: 79,200 sec ÷ 30 = 2,640 wakes
  • Energy per wake: 8 mA × 3ms = 24 µAs
  • Sleep time: 22 hours × 3,600 sec = 79,200 sec
  • Sleep energy: 1.5 µA × 79,200 sec = 118,800 µAs = 0.033 mAh
  • Wake energy: 2,640 × 24 µAs = 63,360 µAs = 0.018 mAh
  • Daily wear energy: 0.033 + 0.018 = 0.051 mAh

Total daily energy:

  • Workout: 1.59 mAh
  • Daily wear: 0.051 mAh
  • Total: 1.64 mAh/day

Battery life: 225 mAh × 0.8 (usable capacity) ÷ 1.64 mAh/day = 110 days ≈ 3.5 months

Problem: This falls short of the 10-month (300-day) target!

Optimization: Reduce workout mode connection interval from 30ms to 100ms (still acceptable for heart rate display, which updates every 1 second anyway).

Revised workout energy:

  • Interval: 100ms → 10 events/sec
  • Events per workout: 10/sec × 7,200sec = 72,000 events
  • Energy: 72,000 × 24.04 µAs = 1,730,880 µAs = 0.48 mAh

Revised total daily energy:

  • Workout: 0.48 mAh
  • Daily wear: 0.051 mAh
  • Total: 0.53 mAh/day

New battery life: 225 × 0.8 ÷ 0.53 = 340 days ≈ 11 months ✓ (exceeds 10-month target)

Key insight: Changing workout mode from 30ms to 100ms interval reduced daily energy by 67% with zero user-perceivable impact (heart rate updates are already throttled to 1 Hz by the app).

Criterion Passive Scanning Active Scanning Winner
Data available Advertising packet only (31 bytes) Adv packet + Scan response (62 bytes total) Active for full data
Power consumption (scanner) Lower (RX only) Higher (RX + TX scan request) Passive for battery
Discovery speed Same (limited by advertising interval) Same Tie
Privacy Scanner is silent Scanner reveals its presence Passive for stealth
Complete device name Only if it fits in 31 bytes Can be split across adv + scan response Active for long names
Use case: background monitoring ✓ Passive
Use case: user-initiated pairing ✓ Active (need full name/info)

Real-world decision:

Scenario: A BLE proximity marketing system in a shopping mall scans for customer smartphones to send targeted offers.

Requirements:

  • Detect 500+ devices/hour
  • Identify device type (iPhone, Android, beacon)
  • Minimize scanner battery drain (runs on battery backup during power outages)
  • Legal compliance: GDPR requires minimizing data collection

Decision: Use passive scanning because: - Advertising packets contain manufacturer-specific data (company ID 0x004C = Apple, 0x00E0 = Google) - Device type detection doesn’t require full name - Passive scanning uses 30% less power than active (scanner sleeps during scan intervals) - GDPR compliance easier (not actively probing devices)

When to switch to active: If the system needed to pair with devices (e.g., for opt-in coupons via connection), use active scanning during the pairing phase to retrieve the full device name for user confirmation (“Connect to iPhone 13 Pro?”).

Measured impact: A retail analytics company tested both modes across 45 stores: - Passive scanning: 18-hour battery life on backup power - Active scanning: 12-hour battery life - Data quality: 95% device identification success with passive (only needed company ID, not full name)

Common Mistake: Setting Supervision Timeout Too Short

The error: A developer sets connection parameters for a BLE temperature sensor with interval = 100ms, latency = 4, and supervision timeout = 1 second, thinking “1 second is plenty of time to detect a lost connection.”

What happens:

The Bluetooth spec requires: supervision_timeout > (1 + latency) × interval × 2

Calculation: - (1 + 4) × 100ms × 2 = 1000ms = 1 second

The timeout is exactly at the minimum threshold. In practice, the supervisor timer starts AFTER the last successful packet exchange, and jitter in the connection event timing can cause the timeout to fire prematurely.

Real-world failure scenario (observed in production):

A warehouse temperature monitoring system with 200 BLE sensors experienced 15-20 “phantom disconnections” per hour – connections dropped despite both devices being in range and functional.

Root cause:

  • Connection interval: 500ms
  • Peripheral latency: 19 (wake every 20th interval = every 10 seconds)
  • Supervision timeout: 20 seconds (exactly (1+19) × 500ms × 2)

During peak warehouse activity, RF interference from forklifts caused occasional packet loss. When the peripheral skipped the maximum allowed intervals (19) and then lost the 20th packet due to interference, the supervisor timer expired before the next connection event.

The fix:

Add a safety margin of 2-3x the minimum:

Minimum: (1 + latency) × interval × 2
Recommended: (1 + latency) × interval × 2 × 3

For the sensor above:
(1 + 19) × 500ms × 2 × 3 = 60 seconds

Impact:

  • Before fix: 15-20 disconnections/hour, 95% uptime
  • After fix (60s timeout): 0-1 disconnection/hour, 99.9% uptime

Measured in industrial BLE deployments:

  • Minimum timeout (2× formula): 5-10% spurious disconnection rate
  • 3× timeout: 0.1% disconnection rate
  • 5× timeout: <0.01% (but slower detection of genuine disconnections)

Rule of thumb: Use 3× minimum for consumer devices, 5× for industrial/medical where RF environments are harsh.

Common Pitfalls

Using the minimum 7.5 ms connection interval when the application only sends data every 10 seconds wastes ~99.9% of radio events. Each empty connection event still requires the radio to wake, sync, and exchange empty PDUs. Set the connection interval to match the application data rate: temperature sensor → 1 s interval; interactive GATT commands → 50–100 ms; real-time control → 7.5–15 ms.

Setting supervision timeout to 1 second with a 500 ms interval and slave latency 0 means any 2-packet gap drops the connection. The minimum safe timeout is (1 + latency) × interval × 6 (allowing 6 missed events). For mobile devices that may enter RF shadows briefly, use a timeout of at least 6 seconds for indoor applications.

A BLE peripheral can request connection parameter updates (LL_CONNECTION_PARAM_REQ), but the central is not required to accept them. Firmware that assumes the update was accepted and adjusts its internal timing without checking the LL_UNKNOWN_RSP or LL_REJECT_IND response will have connection event timing mismatches, causing systematic missed events and eventual timeout.

Devices with static public MAC addresses can be tracked across locations by passive BLE scanners. Use Resolvable Private Addresses (RPAs) that rotate every 15 minutes (configurable). The IRK ensures bonded devices can still identify each other while preventing third-party tracking. Both Android 10+ and iOS automatically use RPAs; ensure your firmware supports RPA resolution.

13.12 What’s Next

Chapter Why Read It Next
Bluetooth Protocol Stack Understand the layered architecture from PHY to GATT that underpins every connection
Bluetooth Security Dive deeper into pairing, bonding, and LE Secure Connections introduced in this chapter
Bluetooth GATT Profiles Learn how services and characteristics are discovered and used over an established connection
Bluetooth Power Optimization Apply connection parameter strategies to real battery-budget calculations
Bluetooth Troubleshooting Extend the diagnostic techniques introduced in the troubleshooting section
Bluetooth Overview Review the foundational concepts if you need to revisit Classic vs BLE differences