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) for data exchange between devices over short distances. The name originates from the 10th-century Nordic King Harald Bluetooth (Harald Blåtann), symbolizing the unification of communication between different devices.

The Bluetooth name comes from Danish King Harald "Bluetooth" Gormsson, who unified the tribes of the Scandinavian Peninsula - just 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 with BLE 2M PHY.

1.3 Bluetooth Frequency Bands and Channels

The 2.4GHz ISM band is divided into different channel grids based on 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 places advertising channels deliberately at 2402 / 2426 / 2480 MHz - these three frequencies avoid the most commonly used WiFi channels 1, 6, 11 (2412 / 2437 / 2462 MHz), reducing mutual interference with WiFi at the physical layer.

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 Bluetooth Low Energy (BLE) simultaneously, both sharing the RF front-end but with independent protocol stacks:

xxxxxxxxxx
┌────────────────────────────────────────────────────────────┐
│                      Application Layer                     │
├──────────────────────────┬─────────────────────────────────┤
│  ┌──────────────────┐    │    ┌──────────────────┐         │
│  │  Classic Bluetooth Profiles │    │    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 and Controller Layers

The 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, with HCI communicating through an internal virtual interface (not physical UART). On phones and other devices, Host typically runs on the main CPU with Controller as a separate Bluetooth chip.

2.3 Layer Details

3. Classic Bluetooth vs Bluetooth Low Energy

3.1 Core Differences

3.2 Why BLE Has Low Power Consumption

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 mode most of the time, only waking up for a few milliseconds during scheduled connection events for data transmission. This is the fundamental reason why its power consumption 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 of others?
                    │
           ┌────────┴────────┐
           ▼                 ▼
        Yes              No
           │                 │
     ┌─────┴─────┐     ┌─────┴─────┐
     ▼           ▼     ▼           ▼
  Advertise?  Don't?  Advertise?  Don't?
     │           │     │           │
     ▼           ▼     ▼           ▼
 Peripheral  Central  Broadcaster  Observer
 (Slave, accepts connections) (Master, initiates connections) (Pure advertiser, non-connectable) (Pure scanner, doesn't connect)

Advertising PDU 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 foundational protocol for BLE data transmission. All data on BLE devices is stored in the form of Attributes (Attribute), where each attribute is a data unit with a 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

Each attribute is defined by four elements:

GATT Operations and Permission Mapping

4.3 GATT — Generic Attribute Profile

GATT (Generic Attribute Profile) is built on top of ATT and defines 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 (The unit that actually exposes data)
          │  UUID + property declarations (Read/Write/Notify/Indicate)
          │  e.g.: 0x2A37 = Heart Rate Measurement (notification-oriented)
          │      0xFFF1 = Custom notification characteristic
          │
          └─ Descriptor (Metadata for characteristic, optional)
              e.g.: 0x2902 = CCCD (Client Characteristic Configuration Descriptor)
                  0x2901 = Characteristic User Description (human-readable text for characteristic name)

UUID Structure

16-bit UUIDs are standardized identifiers assigned by the Bluetooth SIG Alliance and require purchase authorization. Custom projects can freely use 128-bit UUIDs, or use 16-bit UUIDs in non-reserved segments (such as 0xFFF0~0xFFFE, for development and testing only).

CCCD — Client Characteristic Configuration Descriptor

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

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       All notifications/indications disabled            │
│ 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 confirmation, continue sending next)        ←──ACK──
                                Slave sends next only after receiving ACK

4.5 BLE Connection Parameters

After a BLE connection is established, the master can request the slave to modify the following 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 ranges from 6 to 3200). Smaller values mean higher throughput but higher power consumption, larger values mean lower power consumption but increased latency. Sensor applications typically use 100ms~1s, while audio applications require ≤30ms.

5. BLE Advertising and Connection Process

5.1 Complete Lifecycle

xxxxxxxxxx
Peripheral (Slave)                              Central (Master)
─────────────                               ────────────
  [Standby]                                   [Standby]
     │                                            │
     ▼                                            │
  Advertising ◄── ADV_IND ────────── Scan ────────┘
  (Periodic advertising)    Advertising data: Flags + Name + UUID    (Passive or active scanning)
     │
     │           ◄── CONNECT_IND ────── Connect
     │               Connection parameters: 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 Latency

Smaller advertising interval means faster discovery, but higher power consumption:

Android / iOS have scan window limitations - iOS background scanning occurs approximately once every 1~2 seconds, so the advertising interval should not exceed 500ms, otherwise the phone may take a long time to discover the device. Some systems also require the advertising data to contain specific Service UUIDs for the App to filter in the background.

5.3 BLE 5.0 Extended Advertising

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

​x
Legacy advertising (BLE 4.x):
  3 advertising channels, max 31 bytes payload per packet

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) is responsible for pairing and bonding between devices:

6.2 Three Phases of Pairing

xxxxxxxxxx
Phase 1: Feature Exchange
  Both sides exchange IO Capabilities (display/keyboard availability), 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 automatically encrypted (no need to pair again)

Pairing ≠ Bonding. Pairing is a one-time encryption process, bonding stores keys in NVS flash, subsequent connections automatically encrypted - this is what "paired devices list" means in Flutter / Android Apps.

7. Classic Bluetooth Profiles Introduction

While BLE is the mainstream for IoT, ESP32-S3 also supports Classic Bluetooth, which can be used for the following classic Profiles:

SPP is the most commonly used Profile in ESP32-S3 Classic Bluetooth development - it establishes a virtual serial port between two devices through RFCOMM serial emulation protocol, presenting as byte stream sending/receiving to upper layer code, similar to UART but without physical wiring. Suitable for wireless debugging, passthrough control, data collection and other scenarios.

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 - both cannot transmit simultaneously. ESP32-S3 resolves conflicts through Time Division Multiplexing (TDM):

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

In practice, if BLE connection interval ≥30ms (medium/low throughput scenarios), WiFi and BLE can "peacefully coexist" - BLE occupies scheduled connection event slots (a few milliseconds), WiFi freely uses RF for the rest of the time. At high-frequency BLE (approaching max throughput ~700kbps) or dense WiFi transmission (TCP streaming, OTA), they will interfere with each other, requiring tuning coexistence strategy or staggering 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 BT/WiFi 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
       │
       └── Lite BLE peripheral/central role, code size/RAM sensitive?
              ──Yes──→ NimBLE

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

9.3 Bluedroid menuconfig Key Configuration

Required configuration when using Bluedroid:

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