Choose a Bluetooth module by the behavior your product needs, not by its version number or smallest advertised sleep current. The useful comparison includes radio capabilities, application services, host interfaces, antenna placement, power over a complete operating cycle, and a workable firmware maintenance plan.
Define the peer and the feature first
Write down what the module communicates with and what must pass between them. A phone sensor app, an existing Classic serial client, and an audio accessory impose different requirements. Include the required operating systems, message sizes, update frequency, number of connections, and expected recovery after loss of power or radio contact.
Check the exact chip and module variant. Espressif’s Bluetooth capability table, for example, distinguishes the original ESP32’s Classic and LE support from the ESP32-S3’s LE support. A newer product in a familiar family does not necessarily support the same radio modes. Also verify the chosen SDK and firmware configuration.
A Bluetooth LE radio does not automatically implement every LE service or LE Audio feature. The application and supported stack must provide the required behavior. If a peer expects a particular service, document its identifiers, data format, units, and access rules rather than substituting a vaguely similar example application.
Decide where the Bluetooth software runs
On a small screen, scroll the table sideways to read all columns.
| Approach | What your host or application handles | Questions to resolve |
|---|---|---|
| Controller with an HCI interface | Much of the host stack and application runs elsewhere. | Host stack support, transport, memory, integration, and update ownership. |
| Module with command firmware | A separate controller sends the module documented commands or data. | Firmware API, supported services, buffering, error reporting, and lifecycle. |
| Programmable wireless module | Your application runs on the module’s processor and SDK. | Toolchain, memory budget, peripheral support, debugging, and update recovery. |
UART, SPI, and USB describe possible local transport interfaces; they do not tell you where the stack or application lives. Espressif’s architecture overview separates the Bluetooth host and controller layers. Read the selected module’s API and integration guide to understand which responsibilities remain in your design.
A “UART service” is also not necessarily a cable-compatible serial port. Nordic’s Nordic UART Service example uses custom GATT characteristics. Both application ends must understand the service and message framing. For equipment exposing an RS-232 connector, also account for electrical level translation; see Bluetooth Serial Adapters.
Reserve antenna space before finishing the enclosure
The module’s outline is not its complete space requirement. PCB antennas need their specified clearance from board copper, components, batteries, cables, and the enclosure. An external-antenna variant instead needs the specified antenna and feed arrangement. Compare the module’s integration drawing against the actual mechanical design early.
Espressif’s ESP32 module placement guidance favors placing the antenna beyond the base-board edge where practical and calls for clearance in the finished housing. Its dimensions are guidance for the documented design, not a universal keepout for every Bluetooth module.
Test with the final enclosure, intended battery, cables, and mounting position. A development board operating on an open desk is useful for software bring-up but does not establish the finished product’s range. Keep representative orientations and obstructions in the test record, including the peer device and its location.
Worked example: average current needs a time budget
Invented example: a simplified device repeats a one-second cycle. Assume its total current at the battery is 8 mA for 20 milliseconds and 0.008 mA for the remaining 980 milliseconds. These values are fictional; they are not measurements or specifications of any module.
On a small screen, scroll the table sideways to read all columns.
| State | Current | Time in cycle | Contribution to average |
|---|---|---|---|
| Active | 8 mA | 20 ms (2%) | 0.16000 mA |
| Sleeping | 0.008 mA | 980 ms (98%) | 0.00784 mA |
| Total | Varies by state | 1,000 ms (100%) | 0.16784 mA |
The time-weighted average is (8 × 20 + 0.008 × 980) ÷ 1000 = 0.16784 mA. A hypothetical 500 mAh usable capacity at that same measurement boundary gives 500 ÷ 0.16784 ≈ 2,979 hours, or about 124 days. This is an ideal arithmetic estimate for the stated cycle.
It assumes all relevant consumption is included and ignores changes in usable battery capacity, self-discharge, temperature, and operating behavior. If the currents are measured at a regulated module supply rather than the battery, account for voltage conversion and regulator losses before using battery capacity. Sensors, LEDs, a host processor, and a development board’s debugger can also change the total substantially.
A supply must support the active current peaks even when the average is small. Profile advertising, connecting, data transfer, waiting, and firmware updates rather than measuring sleep alone. Nordic’s Online Power Profiler documentation offers a way to explore supported devices’ protocol settings; validate estimates with measurements of the complete design.
Download the verified fictional power-budget table (CSV). Replace the example states and values with measured data for your system, keeping a consistent measurement point and a complete cycle.
Plan maintenance and qualification before committing
Check SDK support, firmware licensing, update signing and recovery options, debugging access, and the supplier’s lifecycle information. Establish what happens if power fails during an update and how supported software can be restored. Keep the application protocol versioned so later firmware does not silently reinterpret older data.
Do not treat a supplier’s qualified design as the end of your product’s Bluetooth process. The Bluetooth SIG’s qualification overview states that your own product must complete the process under your company’s membership account before sale or distribution. Review the current procedure and the supplier’s design information for the exact product.
Bluetooth qualification is a different question from market-specific radio approvals and the conditions of a module’s integration documentation. In the United States, the FCC’s transmitter-module guidance includes a separate integration guide for host-product manufacturers. Identify requirements for the intended markets with the supplier and an appropriate compliance specialist. A module can reduce integration work without removing responsibility for the finished product.
Before selection, demonstrate the required peer connection, exercise a realistic data cycle, measure power in the intended configuration, and test update and reconnection recovery. These checks turn a promising module into evidence for a design decision.
Related resources
- RS-232, UART, and wireless serial interfaces
- Pairing, permissions, and security maintenance
- Why radio version alone does not establish audio support
- Explore all Bluetooth resources
Researched and updated September 5, 2026. Feature availability depends on the exact devices, software, and connection method.