Bluetooth Fundamentals

1. Bluetooth Overview

1.1 What is Bluetooth

Bluetooth is a short-range wireless communication technology operating in the 2.4 GHz ISM band (2400~2483.5 MHz), used for近距离 data exchange between devices. The name comes from 10th century Nordic King Harald Bluetooth (Harald Blåtann),寓意 unifying communication between different devices.

Bluetooth name comes from Danish King Harald "Bluetooth" Gormson, who unified Scandinavian tribes—as Bluetooth technology aims to unify short-range communication protocols between different devices.

1.2 Bluetooth Version Evolution

ESP32-S3 supports BLE 5.0 and Classic Bluetooth (BR/EDR), theoretical max speed: ~1400 kbps application layer throughput under BLE 2M PHY.

1.3 Bluetooth Frequency Bands and Channels

2.4GHz ISM band divides different channel grids by Bluetooth type:

2.4000 GHz                                                2.4835 GHz
   │                                                          │
   ├─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┬─────┤
   │  0  │  1  │  2  │ ... │     │     │     │ ... │ 78  │     │  ← BR/EDR: 79 channels, 1MHz spacing
   ├──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┬──┤
   │00│01│02│... │09│10│11│12│13│14│15│16│17│18│19│...│35│36│39│  ← BLE: 40 channels, 2MHz spacing
   └──┴──┴──┴──┴──┴──┴─┬┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┘
                        │
            37 data channels (0~36)  ← Adaptive Frequency Hopping
             3 advertising channels (37@2402, 38@2426, 39@2480 MHz)

BLE intentionally places advertising channels at 2402 / 2426 / 2480 MHz—these three frequencies avoid WiFi's most commonly used channels 1, 6, 11 (2412 / 2437 / 2462 MHz), physically reducing mutual interference with WiFi.

1.4 Bluetooth vs WiFi

2. Bluetooth Protocol Stack Architecture

2.1 Dual-Mode Architecture

ESP32-S3 supports dual-mode Bluetooth—the same chip can run classic Bluetooth (BR/EDR) and BLE simultaneously. Both share RF front-end but have independent protocol stacks:

xxxxxxxxxx
┌────────────────────────────────────────────────────────────┐
│                      Application Layer                       │
├──────────────────────────┬─────────────────────────────────┤
│  ┌──────────────────┐   │   ┌──────────────────┐          │
│  │ Classic Bluetooth │   │   │   BLE Profiles   │          │
│  │  SPP / A2DP / HID│   │   │  HID / HRS / BAS │          │
│  └────────┬─────────┘   │   └────────┬─────────┘          │
│           │             │             │                    │
│  ┌────────┴─────────┐   │   ┌────────┴─────────┐          │
│  │   GAP (BR/EDR)   │   │   │   GAP (BLE)      │          │
│  └────────┬─────────┘   │   └────────┬─────────┘          │
│           │             │             │                    │
│  ┌────────┴─────────┐   │   ┌────────┴─────────┐          │
│  │  SDP / RFCOMM    │   │   │  GATT            │          │
│  └────────┬─────────┘   │   │  ATT             │          │
│           │             │   │  SM (Security)   │          │
│  ┌────────┴─────────┐   │   └────────┬─────────┘          │
│  │       L2CAP      │   │   ┌────────┴─────────┐          │
│  └────────┬─────────┘   │   │     L2CAP        │          │
│           │             │   └────────┬─────────┘          │
│           ├──────────────┼─────────────┤                  │
│           │          HCI (Host Controller Interface)        │
│           └──────────────┼─────────────┘                  │
├──────────────────────────┼─────────────────────────────────┤
│  ┌────────┴─────────┐   │   ┌──────────────────┐          │
│  │   Link Manager   │   │   │   Link Layer     │          │
│  │   (LM)           │   │   │   (LL)           │          │  ← Controller
│  ├──────────────────┤   │   ├──────────────────┤          │
│  │      Baseband    │   │   │   Physical Layer │          │
│  ├──────────────────┤   │   │   (PHY)          │          │
│  │   RF / Antenna   │   │   └──────────────────┘          │
│  └──────────────────┘   │                                 │
└──────────────────────────┴─────────────────────────────────┘

2.2 Host vs Controller Layering

Bluetooth protocol stack is divided into two major parts, communicating through HCI (Host Controller Interface):

On ESP32-S3, Host and Controller run on the same chip, HCI communicates via internal virtual interface (not physical UART). On phones and other devices, Host typically runs on main CPU, Controller is a separate Bluetooth chip.

2.3 Layer Details

3. Classic Bluetooth vs Low Energy Bluetooth

3.1 Core Differences

3.2 Why BLE Power Consumption is Low

BLE's low power consumption comes from three design choices:

xxxxxxxxxx
Classic Bluetooth:  ████████████████████████████████████████████  (RF continuously active)
BLE:                 ██      ██      ██      ██      ██          (Periodic instant active)
                    ↑──────↑ Connection Interval (7.5ms~4s)

BLE's RF is in Sleep state most of the time, only waking for a few milliseconds at predetermined connection events to send/receive data. This is the fundamental reason its power is only 1%~5% of classic Bluetooth.

4. BLE Core Concepts

4.1 GAP — Generic Access Profile

GAP defines how BLE devices are discovered and connected by other devices, and is the entry point for all BLE communication.

Four GAP Device Roles

xxxxxxxxxx
                    Active discovery?
                    │
           ┌────────┴────────┐
           ▼                 ▼
      Yes                 No
           │                 │
     ┌─────┴─────┐     ┌─────┴─────┐
     ▼           ▼     ▼           ▼
  Advertise?  No adv  Advertise?  No adv
     │           │     │           │
     ▼           ▼     ▼           ▼
 Peripheral  Central  Broadcaster  Observer

Advertising Types

Advertising Data Format

Advertising data is organized in Length-Type-Value (LTV) structure:

xxxxxxxxxx
Advertising packet (max 31 bytes / legacy mode)
  ├─ [L=2] [T=Flags]            [V=0x06]                    ← 3 bytes
  ├─ [L=9] [T=Complete Name]    [V="ESP-IDF"]               ← 11 bytes
  ├─ [L=3] [T=16-bit Service]   [V=0xFFF0]                  ← 5 bytes
  └─ [L=...] Other fields...

4.2 ATT — Attribute Protocol

ATT (Attribute Protocol) is the foundation of BLE data transmission. All data on BLE devices is stored as attributes (Attribute), each attribute is a data unit with handle and UUID.

Attribute Structure

xxxxxxxxxx
Attribute Handle   UUID            Permissions    Value
─────────────────────────────────────────────────────────
  0x0010          0x2800          R              0xFFF0       ← Service declaration
  0x0011          0x2803          R              NOTIFY, 0xFFF1  ← Characteristic declaration
  0x0012          0xFFF1          R|N            "Hello"      ← Characteristic value
  0x0013          0x2902          R|W            0x0001       ← CCCD descriptor

Four elements of each attribute:

GATT Operations and Permission Correspondence

4.3 GATT — Generic Attribute Profile

GATT (Generic Attribute Profile) is built on ATT, defining the hierarchical organization model for BLE data:

xxxxxxxxxx
Profile (Specification/Application layer, e.g. Heart Rate Profile)
  │
  └─ Service (UUID 16/32/128-bit)
      │  e.g.: 0x180D = Heart Rate Service (SIG standard)
      │         0xFFF0 = Custom service
      │
      └─ Characteristic (unit that actually exposes data)
          │  UUID + property declaration (Read/Write/Notify/Indicate)
          │  e.g.: 0x2A37 = Heart Rate Measurement (notification-oriented)
          │         0xFFF1 = Custom notification characteristic
          │
          └─ Descriptor (metadata of characteristic, optional)
              e.g.: 0x2902 = CCCD (Client Characteristic Configuration Descriptor)
                  0x2901 = Characteristic User Description (characteristic name readable text)

UUID Structure

16-bit UUIDs are standardized identifiers allocated by Bluetooth SIG alliance and require purchase authorization. Custom projects can freely use 128-bit UUIDs, or use non-reserved 16-bit UUIDs (like 0xFFF0~0xFFFE, for development testing only).

CCCD — Client Characteristic Configuration Descriptor

CCCD (Client Characteristic Configuration Descriptor) UUID = 0x2902, is the most critical descriptor in GATT, controlling slave notification/indication toggle:

xxxxxxxxxx
Master enables notification:  Master → CCCD (0x2902) → Write 0x0001 → Slave starts pushing Notify
Master disables notification: Master → CCCD (0x2902) → Write 0x0000 → Slave stops pushing
┌────────────────────────────────────────────────────────────────┐
│ CCCD Value       Meaning                                      │
├────────────────────────────────────────────────────────────────┤
│ 0x0000       Disable all notifications/indications             │
│ 0x0001       Enable notification (Notify)                      │
│ 0x0002       Enable indication (Indicate)                     │
└────────────────────────────────────────────────────────────────┘

4.4 Notify vs Indicate Comparison

xxxxxxxxxx
Notify flow:              Indicate flow:
  Slave ──data──→ Master       Slave ──data──→ Master
  (no ack, continue sending)        ←──ACK──
                               Slave sends next only after receiving ACK

4.5 BLE Connection Parameters

After BLE connection is established, master can request modifications to these connection parameters:

xxxxxxxxxx
Connection interval 7.5ms:  ██ ██ ██ ██ ██ ██ ██ ██  (high throughput, high power)
Connection interval 100ms:  ██     ██     ██     ██   (medium)
Connection interval 1000ms: ██           ██          (low throughput, extremely low power)

Connection interval = 7.5ms × N (N range 6~3200). Smaller value means higher throughput but higher power consumption; larger value means lower power but increased latency. Common sensor scenarios use 100ms~1s; audio scenarios require ≤30ms.

5. BLE Advertising and Connection Process

5.1 Complete Lifecycle

xxxxxxxxxx
Peripheral (Slave)                             Central (Master)
──────────────                               ────────────
  [Standby]                                   [Standby]
     │                                            │
     ▼                                            │
  Advertising ◄── ADV_IND ────────── Scan ────────┘
  (periodic adv)    Adv data: Flags + Name + UUID    (passive or active scan)
     │
     │           ◄── CONNECT_IND ────── Connect
     │               Connection params: Interval + Latency + Timeout
     ▼
  Connected ════════════════════════ Connected ═══
     │                                            │
     │           ◄── Exchange MTU ───            │
     │           ◄── Discover Services ──         │
     │           ◄── Discover Characteristics ──  │
     │           ◄── Enable CCCD ─────            │
     │                                            │
     │           ◄══ Notify/Write ════►           │
     │                                            │
     ▼                                            ▼
  Disconnected                               Disconnected
  (re-advertise)

5.2 Advertising Interval and Discovery Delay

Smaller advertising interval means faster discovery but higher power:

Android/iOS have scan window limitations—iOS background scans about once every 1~2s, so advertising interval should not be greater than 500ms, otherwise phone may take a long time to discover the device. Some systems also require specific Service UUID in advertising data for App background filtering.

5.3 BLE 5.0 Extended Advertising

BLE 5.0 introduced extended advertising mechanism, greatly increasing advertising data capacity from 31 bytes:

​x
Legacy advertising (BLE 4.x):
  3 advertising channels, each ≤ 31 bytes payload

Extended advertising (BLE 5.0):
  Supports carrying advertising data on 37 data channels (not on advertising channels),
  can chain-send multiple packets (max 1650 bytes payload)

  Applications: Indoor navigation, asset tracking, electronic price tag batch updates

6. SM — Security Manager

6.1 Pairing Methods

BLE Security Manager (SM) handles pairing and bonding between devices:

6.2 Three Phases of Pairing

xxxxxxxxxx
Phase 1: Feature Exchange
  Both sides exchange IO Capabilities (display/keyboard presence), security requirements
    → Negotiate pairing method (Just Works / Passkey / OOB)

Phase 2: Key Generation
  STK (Short Term Key, legacy pairing, BLE 4.0/4.1)
  or LTK (Long Term Key, LE Secure Connections, BLE 4.2+)
    → Establish encrypted link

Phase 3: Key Distribution
  LTK + IRK (Identity Resolving Key) + CSRK (Connection Signature Resolving Key)
    → Bonding complete, subsequent reconnections auto-encrypt (no pairing again)

Pairing ≠ Bonding. Pairing is a one-time encryption process; bonding stores keys in NVS flash, subsequent connections auto-encrypt—this is the "paired devices list" in Flutter/Android App.

7. Classic Bluetooth Profile Introduction

Although BLE is mainstream for IoT, ESP32-S3 also supports classic Bluetooth, usable for these classic profiles:

SPP is the most commonly used profile in ESP32-S3 classic Bluetooth development—establishes virtual serial port between two devices via RFCOMM serial emulation protocol, appears to upper layer code as byte stream send/receive, similar to UART but without physical wiring. Applicable to wireless debugging, passthrough control, data acquisition, etc.

8. ESP32-S3 Bluetooth Hardware Features

8.1 Bluetooth and WiFi Coexistence — 2.4GHz Resource Arbitration

Bluetooth and WiFi share the same antenna and 2.4GHz RF front-end—they cannot transmit simultaneously. ESP32-S3 resolves conflicts through Time Division Multiplexing (TDM):

xxxxxxxxxx
WiFi:   ████████░░░░░░░░░░████████░░░░░░░░░░
BLE:    ░░░░░░░░████░░░░░░░░░░░░░░████████░░
        ├──────────┼──────────┼──────────┼──
        Time Slot (coexistence module arbitrates)

In practice, if BLE connection interval is ≥30ms (medium/low throughput scenarios), WiFi and BLE can "peacefully coexist"—BLE occupies predetermined connection event slots (few milliseconds), remaining time WiFi uses RF freely. High-frequency BLE (approaching limit throughput ~700kbps) or dense WiFi transmission (TCP stream, OTA) will interfere with each other; need to tune coexistence strategy or stagger usage periods.

8.2 Coexistence Configuration

Configure coexistence strategy in menuconfig:

xxxxxxxxxx
Component config → Bluetooth → Bluedroid → Bluetooth Coexistence

Or adjust at runtime in code:

xxxxxxxxxx
// Set coexistence mode to balance
esp_coex_set_preferred_mode(ESP_COEX_PREFER_BALANCE);

9. ESP-IDF Bluetooth Protocol Stack Selection

9.1 Bluedroid vs NimBLE

ESP-IDF provides two Bluetooth Host protocol stacks:

9.2 Protocol Stack Selection

xxxxxxxxxx
Need classic Bluetooth (SPP/A2DP/HID)?  ──Yes──→ Bluedroid (only choice)
       │
       No (BLE only)
       │
       ├── Need full BLE features (Mesh, Extended Advertising, LE Audio)?
       │      ──Yes──→ Bluedroid
       │
       └── Lean BLE peripheral/central role, code/ram sensitive?
              ──Yes──→ NimBLE

Subsequent BLE slave and master experiments in this project all use NimBLE protocol stack. For IoT teaching scenarios requiring only BLE peripheral/central roles, NimBLE's code and memory overhead is much smaller than Bluedroid, making it a more suitable choice.

9.3 Bluedroid menuconfig Key Configuration

When using Bluedroid, must configure:

xxxxxxxxxx
Component config → Bluetooth
  ├─ [*] Bluetooth
  ├─ Bluetooth Host → Bluedroid
  └─ Bluedroid Options
      ├─ [*] Include GATT
      ├─ [ ] Include Classic Bluetooth (as needed)
      └─ [*] Enable BLE 5.0 features (as needed)

When using NimBLE:

xxxxxxxxxx
Component config → Bluetooth
  ├─ [*] Bluetooth
  ├─ Bluetooth Host → NimBLE
  └─ Bluetooth Controller → BLE Only

10. Common Troubleshooting