The choice of how a host system communicates with a Bluetooth module is one of the first architectural decisions in a BLE product design, and it shapes every subsequent firmware and hardware tradeoff. Three dominant approaches exist: HCI (Host Controller Interface), AT command over UART, and fully integrated SoC (System on Chip) designs. Each targets a different development profile, and selecting the wrong one adds cost and complexity that cannot be easily undone post-design.
HCI: Maximum Control, Maximum Complexity
The HCI interface exposes the Bluetooth controller to a host processor at the lowest useful abstraction level. The host runs the full BLE stack — L2CAP, ATT/GATT, GAP, SMP — and communicates with the controller via standardized HCI commands and events over USB, UART, or SPI.
HCI is the right choice when:
- The host is a Linux system (Raspberry Pi, industrial gateway, Android device) — BlueZ runs the full host stack natively
- Custom GATT profiles are required with precise control over attribute permissions, connection parameters, and security modes
- The application requires simultaneous BLE central and peripheral roles with multiple concurrent connections
- Maximum throughput is required — HCI gives direct access to connection event timing and data length extension (DLE) parameters
HCI modules typically cost 15–25% more than AT-command modules at equivalent RF performance because they include more complete silicon (controller only, no embedded application stack). Modules like the u-blox ODIN-W262 and the Laird DVK-BL5340 target this segment.
The development cost is significant: implementing a full BLE host stack from specification takes 3–6 months for an experienced team. Open-source stacks (Zephyr BLE host, NimBLE) reduce this to weeks, but require understanding of connection parameter negotiation, pairing/bonding state machines, and GATT service structure — concepts that AT-command abstraction hides entirely.
AT Commands: Fast Integration, Limited Flexibility
AT-command modules expose a simplified control interface over UART, SPI, or I2C. The module runs the full BLE stack internally; the host sends text commands (AT+SCAN, AT+CONNECT, AT+SEND) and receives event notifications. Development time to a working prototype is typically 1–2 weeks.
AT command architecture characteristics:
| Parameter | Typical Value | Notes |
|---|---|---|
| UART baud rate | 9600–921600 baud | Higher rates require flow control |
| Command response latency | 5–50 ms | Depends on BLE stack processing load |
| Maximum throughput (transparent mode) | 20–80 kbps | Limited by UART framing and BLE connection interval |
| GATT profile customization | Vendor-specific commands | Varies significantly across vendors |
| Simultaneous connections | 1–8 (vendor dependent) | Most consumer modules: 1 central or 1 peripheral |
AT command modules are appropriate for designs where the BLE function is secondary to the main application: a temperature sensor that periodically sends readings to a smartphone, a relay controller that receives BLE commands, or an equipment panel that provides wireless configuration access.
The limitations become visible at scale. AT commands add 5–50 ms latency to every BLE operation — unacceptable in real-time control applications. Throughput is capped by the UART bridge: a 20 kbps effective data rate through an AT-command module versus 200–800 kbps achievable with direct HCI stack access. Custom GATT service definitions are usually impossible — the module exposes a fixed service profile that may not match application requirements.
SoC Integration: Lowest BOM, Highest Development Investment
Fully integrated SoC designs eliminate the module entirely. The Nordic nRF52840, Silicon Labs EFR32BG22, or Texas Instruments CC2652R provides BLE radio, 32-bit ARM Cortex-M4 MCU, and peripherals in a single package. The application firmware runs directly on the same silicon as the BLE stack.
SoC integration economics:
| Aspect | Module Approach | SoC Approach |
|---|---|---|
| BOM cost (RF component) | $3–12 per unit | $1.50–4 per unit |
| PCB area | 15–40 mm² | 5–10 mm² (with matching network) |
| RF certification cost | Included in module cert | $15,000–60,000 (FCC + CE + others) |
| Development timeline | 2–8 weeks firmware | 3–12 months firmware + RF design |
| Break-even volume | N/A | ~50,000–200,000 units |
The certification cost differential is the dominant factor for volume decisions. A module carries pre-certified FCC/CE status. An SoC design requires a full RF certification run — $15,000–60,000 depending on target markets — before the product can ship. At production volumes above 100,000–200,000 units per year, the BOM cost savings justify the certification investment. Below that threshold, modules almost always win on total project cost.
Protocol Stack Comparison: Zephyr vs NimBLE vs Vendor SDKs
For HCI and SoC approaches, the choice of host stack matters significantly:
| Stack | Platform | BLE 5.x Features | Certification | Best For |
|---|---|---|---|---|
| Zephyr BLE Host | Multi-SoC (nRF, EFR32, STM32) | Full (Coded PHY, Extended Adv, CTE) | QDID available | Multi-platform products, open-source requirement |
| NimBLE (Apache) | ESP32, custom ports | BLE 5.0 core features | No formal QDID | ESP32 products, cost-sensitive designs |
| Nordic SoftDevice | nRF52/53 only | Full (per SoftDevice version) | QDID certified | Nordic SoC designs requiring certification |
| Silicon Labs BGAPI | EFR32 only | Full | QDID certified | EFR32 designs with Silicon Labs tools |
For products requiring Bluetooth qualification (required to use the Bluetooth trademark), the stack must carry a valid QDID (Qualified Design ID). Zephyr and vendor SDKs (SoftDevice, BGAPI) maintain QDIDs through the Bluetooth SIG. NimBLE does not maintain a formal QDID — products using NimBLE that require qualification must file their own QDID or use an exemption path.
UART Interface Design for AT Command Modules
AT command Bluetooth modules typically use UART as the host interface. Common integration mistakes:
- Missing flow control: RTS/CTS hardware flow control is mandatory for reliable operation above 115200 baud. Without it, a BLE event burst (multiple connection notifications arriving simultaneously) overflows the UART receive buffer. Symptoms: intermittent dropped events that are impossible to reproduce deterministically.
- Incorrect voltage translation: Most BLE modules use 3.3 V logic. Connecting a 5 V MCU UART directly — without level shifting — stresses the module’s input protection diodes and causes intermittent logic failures within weeks. Use an active level shifter, not a resistor divider, for reliable 5 V/3.3 V translation.
- Wake-up latency not accounted for: Modules in low-power sleep mode require 3–15 ms to wake before accepting UART commands. Send a wake-up pulse or wait for a wake indication signal before issuing commands after a sleep period.
SPI vs UART Interface Selection
Some BLE modules support both UART and SPI host interfaces. Key tradeoffs:
| Parameter | UART | SPI |
|---|---|---|
| Maximum clock speed | 3 Mbps practical | 8–32 Mbps |
| Wire count | 2–4 (TX, RX, RTS, CTS) | 4–6 (MOSI, MISO, CLK, CS, IRQ) |
| Full-duplex operation | Yes (hardware) | Yes (hardware) |
| Multi-master support | Not applicable | Not applicable (single master) |
| Buffer management | Flow control (RTS/CTS) | IRQ-based notification |
| CPU interrupt overhead | Character-by-character | Block transfer with DMA |
SPI is preferred when the host MCU has limited UART peripherals, when transfer latency matters (SPI delivers the first byte 10–50× faster than UART at equivalent data rates), or when DMA integration is important for CPU overhead reduction. UART remains the more common choice for cost and simplicity.
Making the Decision: A Selection Framework
Use this framework to narrow the interface selection before evaluating specific modules:
- Linux/Android host + complex GATT profiles + high throughput requirement: HCI module or SoC (Zephyr BLE host)
- MCU host + standard GATT profiles + time-to-market priority: AT command module
- MCU host + application runs on BLE SoC + volume >100K/year: SoC integration with Nordic/SiLabs/TI SDK
- MCU host + custom GATT required + volume <50K/year: HCI module with NimBLE or Zephyr host stack on MCU
The worst outcome is starting with an AT-command Bluetooth module for its simplicity and discovering mid-development that the application requires custom GATT profiles or throughput above 50 kbps. At that point, switching to HCI or SoC requires redesigning both firmware and hardware. Front-loading the interface selection decision with a clear requirements analysis saves this rework, which typically costs 4–8 weeks of engineering time and delays product launch.