ESP32-C6 vs ESP32-H2 vs ESP32-C3: Which Chip for BLE-Only Projects
The ESP32-C3 has been shipping in BLE products for years. It works. It’s cheap. Then why did Espressif release two more RISC-V chips with BLE support within months of each other, and how do you know if one of them should replace the C3 in your next design?
Here’s the part that trips up most hardware leads: the ESP32-H2 and ESP32-C6 both support BLE 5.3, but they’re aimed at fundamentally different design philosophies. One strips away everything except low-power radio. The other packs in Wi-Fi 6 and 802.15.4 as insurance. Picking between them isn’t about which has better specs. It’s about which costs your project the least over its lifetime, in dollars, milliamp-hours, and redesign risk.
This is a decision guide for production BLE projects. If you’ve already narrowed to Espressif’s ecosystem (and away from Nordic’s nRF52/53 line, or at least you’re comparing both), this will give you a concrete framework. We’re excluding the original ESP32, S2, and S3. They’re Xtensa-based, more power-hungry, and overkill for BLE-only work.
Wi-Fi and Thread capabilities get acknowledged here, but BLE is the lens.
ESP32 BLE Chip Comparison: The Spec Table
Before we interpret anything, here are the numbers side by side:
| Feature | ESP32-C3 | ESP32-H2 | ESP32-C6 |
|----------------------|----------------|----------------|----------------|
| CPU | RISC-V, 160MHz | RISC-V, 96MHz | RISC-V, 160MHz |
| BLE Version | 5.0 | 5.3 (LE) | 5.3 (LE) |
| Wi-Fi | Yes (Wi-Fi 4) | No | Yes (Wi-Fi 6) |
| 802.15.4 | No | Yes | Yes |
| SRAM | 400 KB | 320 KB | 512 KB |
| Deep Sleep Current | ~5 µA | ~2.5 µA | ~7 µA |
| BLE TX (0 dBm) | ~130 mA | ~72 mA | ~102 mA |
| Operating Voltage | 3.0–3.6 V | 2.7–3.6 V | 3.0–3.6 V |
| Approx. Chip Price | ~$0.90 | ~$1.00 | ~$1.20 |
| (1k qty, mid-2025) | | | |
| Module Example | C3-MINI-1 | H2-MINI-1 | C6-MINI-1 |Prices approximate from LCSC/Mouser as of mid-2025. Deep sleep and TX current from Espressif datasheets (latest revisions). Verify against current datasheets before committing.
Three things jump out immediately. The H2 has the lowest deep sleep current (~2.5 µA) and lowest active TX current (~72 mA) by a wide margin. The C3 is the cheapest. The C6 has the most radios and the most RAM, but also draws the most in deep sleep. These trade-offs are the entire story.
What BLE 5.3 Actually Buys You
All three chips support coded PHY (long range) and 2M PHY for higher throughput. They all handle extended advertising. The BLE version difference, 5.0 on the C3 versus 5.3 on the H2 and C6, is primarily about power management features, not raw data rates.
The headline BLE 5.3 feature for production devices is connection subrating. This lets a BLE connection dynamically switch between fast and slow connection intervals without a full parameter update. For a sensor that reports once per minute but needs occasional bursts, connection subrating avoids the latency penalty of a long base interval and the power penalty of a short one. In practice, this can reduce radio-on time by 30–50% for periodic reporting use cases (per Bluetooth SIG core spec 5.3 analysis).
BLE 5.3 also adds channel classification enhancement (better performance in congested RF environments like factory floors) and AdvDataInfo in periodic advertising (reducing redundant processing on the scanner side).
Here’s the honest assessment of stack maturity: the C3’s BLE support via NimBLE and Bluedroid in ESP-IDF is the most battle-tested. It’s been in production since 2020. The H2 and C6 NimBLE stacks are stable as of ESP-IDF v5.3+, but you’ll find fewer community edge-case reports and fewer third-party examples. If you’re doing something straightforward, a GATT server with standard advertising, the newer chips are fine. If you’re pushing BLE to its limits with custom L2CAP channels or complex multi-connection topologies, the C3’s maturity still matters.
Verdict: If your product benefits from connection subrating (most battery-powered periodic reporters do), the H2 or C6 earn their keep. If BLE 5.0 covers your requirements, the C3’s stack maturity is a real advantage.
Power Consumption: Where the H2 Pulls Away
Deep Sleep
The H2’s ~2.5 µA deep sleep is roughly half the C3’s ~5 µA. The C6, carrying Wi-Fi 6 and 802.15.4 radio hardware, draws ~7 µA. For a device that sleeps 99% of the time, this is the dominant factor in battery life.
Active BLE TX/RX
At 0 dBm, the H2 draws ~72 mA during BLE TX, almost half the C3’s ~130 mA. The C6 sits between them at ~102 mA. This gap compounds with advertising frequency and connection interval.
The Number That Matters: Daily Energy Budget
Real-world battery life depends on your duty cycle, not just peak numbers. Here’s a worked example for a BLE sensor advertising a 31-byte payload every 2 seconds, sleeping between advertisements. Assuming 3 advertising channels per event, ~1 ms per channel:
ESP32-C3 ESP32-H2 ESP32-C6
TX per event: 130mA × 3ms 72mA × 3ms 102mA × 3ms
Events per day: 43,200 43,200 43,200
Daily TX energy: ~4.68 mAh ~2.59 mAh ~3.67 mAh
Deep sleep (23.96h): ~119.8 µAh ~59.9 µAh ~167.7 µAh
Daily total: ~4.80 mAh ~2.65 mAh ~3.84 mAhSimplified model, excludes wake-up transition current, sensor reading time, and RX windows. Use as a relative comparison, not an absolute budget.
On a 250 mAh coin cell, that’s roughly 52 days on the C3, 94 days on the H2, and 65 days on the C6, just from the radio differences. The H2 nearly doubles the C3’s battery life in this scenario.
Verdict: The H2 wins on power, unambiguously. The C6 is closer to the C3 than you’d expect given its extra radios, but it still pays a sleep-current tax. If battery life is your primary constraint, the H2 is the clear choice.
Cost Analysis for Production Builds
At 1k quantity (mid-2025 pricing), you’re looking at roughly $0.90 for the C3 chip, $1.00 for the H2, and $1.20 for the C6. At module level, the spread widens slightly: the C3-MINI-1 is the cheapest and most widely stocked.
The $0.30/unit difference between C3 and C6 sounds trivial, but at 50k units that’s $15,000. More importantly, the C3 has the most mature supply chain. It’s available from multiple module vendors, it’s stocked deeper, and you’re less likely to hit allocation issues. The H2’s module ecosystem is thinner: fewer second sources, less distributor inventory depth. The C6 falls in between.
For BLE-only designs, the C6’s extra radios don’t add BOM components (you’re not populating an antenna switch or external Wi-Fi front-end you don’t need). But you are paying for silicon area and the slightly higher module cost.
Verdict: C3 wins on cost and supply chain today. The H2 is competitive on chip price but riskier on module availability. The C6 costs more, though not dramatically. The premium is a product-management decision, not a cost-engineering one.
Why You Might Want Extra Radios (Even If the Spec Says BLE-Only)
Specs change. Product managers add features. Three scenarios where the C6’s extra radios pay off retroactively:
OTA firmware updates over Wi-Fi. BLE DFU works, but it’s slow (minutes for a modest firmware image) and unreliable at scale when you’re updating thousands of devices. Wi-Fi OTA is faster and more dependable. If your device will ever be within range of a gateway with Wi-Fi, the C6 gives you that escape hatch.
Thread/Matter interoperability. If you’re building for the smart home ecosystem, Matter over Thread (802.15.4) is becoming a baseline expectation. The C6 and H2 both support 802.15.4; the C3 doesn’t.
Field diagnostics. Spinning up a Wi-Fi AP on the C6 for local diagnostics during manufacturing or field service is trivially easy. Over BLE, you’re limited in throughput and tooling.
If you’re certain none of these apply, and you have the product authority to make that call, skip the radios. But if there’s ambiguity, the C6’s $0.30 premium is cheap insurance against a board respin.
Espressif Chip Selection Decision Matrix
| Criteria | ESP32-C3 | ESP32-H2 | ESP32-C6 |
|-------------------------|----------|----------|----------|
| BLE Feature Set | 2 | 3 | 3 |
| Deep Sleep Power | 2 | 3 | 1 |
| Active BLE Power | 2 | 3 | 2 |
| Unit Cost (volume) | 3 | 2 | 1 |
| Supply Chain Maturity | 3 | 1 | 2 |
| Future-Proofing | 1 | 2 | 3 |
| BLE Stack Maturity | 3 | 2 | 2 |
|-------------------------|----------|----------|----------|
| TOTAL | 16 | 16 | 14 |
Scoring: 3 = Best in category | 2 = Competitive | 1 = WeakestThe totals are deliberately close. This isn’t a clear-cut winner situation. The right chip depends on which rows you weight highest.
[BLE-Only Project]
|
v
Is BLE 5.3 required?
/ \
No Yes
| |
v v
Is cost Is Wi-Fi/Thread
#1 priority? possibly needed?
/ \ / \
Yes No Yes No
| | | |
v v v v
C3 C3 C6 H2
(still wins
on cost +
maturity)Three clear recommendations:
- “Ship today, minimize BOM” → ESP32-C3. Proven, cheapest, deepest supply chain. BLE 5.0 is enough for most current designs.
- “Maximum battery life, BLE-only forever” → ESP32-H2. Best deep sleep and active current by a wide margin. BLE 5.3’s connection subrating extends that advantage further.
- “BLE now, but requirements may expand” → ESP32-C6. The insurance policy. Wi-Fi 6 and 802.15.4 sit dormant until you need them.
Migration Isn’t Free: Get It Right the First Time
All three chips are RISC-V. All use ESP-IDF. All support NimBLE. Porting application firmware from one to another is realistic, typically days to a couple of weeks of work, not months.
But here’s the expensive part: they are not pin-compatible. Swapping chips means a board respin. At prototype stage, that’s an inconvenience. At production scale with tooled enclosures and certified designs, it’s a significant cost in time, money, and recertification (FCC/CE test reports are chip-specific).
The firmware port is the easy part. The hardware redesign is what you want to avoid. Spend the time now to make the right call.
Prototype Before You Commit
The decision framework is straightforward: C3 for cost, H2 for power, C6 for flexibility. But frameworks don’t catch everything.
Pull up the datasheet for your top pick. Order the corresponding devkit (ESP32-C3-DevKitM-1, ESP32-H2-DevKitM-1, or ESP32-C6-DevKitC-1). Implement your actual BLE profile: your advertising interval, your connection parameters, your payload sizes. Measure current with a real power profiler, not just datasheet estimates.
Validate your power budget on hardware before you commit to a board design. The $15 devkit and two days of profiling will save you from a $50,000 mistake at production scale.
Hubble Network connects BLE devices directly to satellites—no gateways, no terrestrial infrastructure. See how it works →