01 Overview

This example demonstrates the ESP32 as a BLE GATT client (Central): scanning for BLE peripherals, filtering by name or service UUID, establishing a connection, discovering services, enabling notifications, and continuously receiving data.

Typical use case is an IoT gateway: the ESP32 collects data from multiple low-power sensors (e.g., temperature/humidity, heart rate, fitness bands) and uploads it to the cloud via Wi-Fi or Ethernet.

Unlike the GATT Server example, the ESP32 actively initiates connections rather than waiting to be connected. If your product requires a phone to connect directly to the ESP32, use Server mode instead.

The example is based on the Bluedroid stack, suitable for complex GATT operations. For low-power or simpler connections, consider NimBLE or ESP-BLE-MESH.

This example does not cover specific sensor protocols; it provides a generic GATT client framework. Actual products must customize service discovery and data parsing according to the sensor's datasheet.

02 Hardware

• RF layout: Same antenna matching and PCB layout requirements as the Server example to ensure BLE sensitivity.
• Antenna: Use PCB or external antenna, keep clearance area, avoid metal shielding.
• Coexistence: If Wi-Fi and BLE are used simultaneously, evaluate coexistence performance; use external coexistence pins or software arbitration if needed.
• Power: Multi-peripheral connections cause current spikes; ensure sufficient decoupling capacitors and regulator headroom.
• Connectors: For external sensors, check I2C/UART level matching; see schematic.
• Crystal: Use a 32.768kHz crystal for low-power modes, otherwise Bluetooth clock may drift.
• Debug interface: Keep UART0 for logging to facilitate field debugging.

03 Software flow

1. Initialize NVS, Wi-Fi (if uplink needed), and the Bluedroid stack.

2. Configure scan parameters (window, interval, filters) and scan for target devices by name or UUID.

3. Stop scanning when target found, initiate connection (with timeout).

4. After connection, discover primary services, then characteristics and descriptors.

5. Enable notifications (write to CCCD) and register callbacks to receive data.

6. In the main loop, process received data, parse, and report (e.g., MQTT).

7. Monitor connection state; on disconnect, reconnect with policy (exponential backoff).

8. Handle pairing/bonding requests, save keys for fast reconnection.

04 Core points

• Strict filters: On site, multiple identical devices may exist; filter by MAC or unique UUID to avoid connecting to the wrong one.
• MTU negotiation: Default MTU is small; for large data transfers, negotiate a larger MTU (e.g., 247 bytes).
• Coexistence issues: Wi-Fi and BLE simultaneously may cause packet loss; test and optimize coexistence strategy.
• Power management: Gateways are usually mains-powered, but if battery-powered, optimize scan interval and connection parameters.
• Security: If data is sensitive, enable pairing and encryption to prevent eavesdropping.
• Customization: Can be extended to multi-connection, data caching, OTA, etc.