Comparing ESP32 Variants: Original, S2, S3, C3, and H2

Espressif's ESP32 lineup has expanded well beyond the original chip. The S2, S3, C3, and H2 variants each made deliberate tradeoffs - dropping Bluetooth here, adding USB-OTG there, switching to a RISC-V core. If you're choosing a chip for a project or trying to understand why the BLEShark Nano uses the C3 specifically, this comparison will help. Each chip has a specific use case it's optimized for. None of them is strictly "better" than the others.

Table of Contents

• Original ESP32: The Foundation
• ESP32-S2: Low-Power, No Bluetooth
• ESP32-S3: Dual-Core, AI, USB-OTG
• ESP32-C3: RISC-V, BLE 5, Smallest Package
• ESP32-H2: Thread, Zigbee, No WiFi
• Side-by-Side Comparison
• Why BLEShark Nano Uses the C3
• Choosing the Right Variant

Original ESP32: The Foundation

The original ESP32 (xtensa LX6, dual-core at 240MHz) launched in 2016 and remains widely used. Its distinguishing features relative to the newer variants are its dual-core architecture, its support for both Classic Bluetooth (BR/EDR) and BLE simultaneously, and its rich peripheral set.

Key specs of the original ESP32:

• CPU: Dual Xtensa LX6, 240MHz
• RAM: 520KB SRAM
• WiFi: 802.11b/g/n, 2.4GHz
• Bluetooth: Classic (BR/EDR) + BLE 4.2
• USB: None (requires external USB-to-UART chip)
• GPIO: 34 pins
• ADC: 18 channels

The dual-core design means one core can handle WiFi/BLE stack processing while the other runs application code, reducing latency and improving throughput compared to single-core competitors. The Classic Bluetooth support (for A2DP audio, SPP serial profiles) is unique to the original ESP32 - no other variant in the family supports Classic BT.

The original ESP32 is the go-to for projects that need Classic Bluetooth (speakers, legacy serial equipment) or benefit from dual-core processing. Its limitation relative to newer variants is power consumption - dual-core at 240MHz draws more current than a RISC-V single-core, and the BLE implementation predates BLE 5.0. It's also in a larger package (38 pins in QFN) than the C3.

graph TD
    subgraph "ESP32 Family Tree"
        subgraph "Xtensa Architecture"
            OG["ESP32 (2016)
Dual Xtensa LX6
240MHz
WiFi + BT Classic + BLE 4.2
520KB SRAM
34 GPIO"]
            S2["ESP32-S2 (2020)
Single Xtensa LX7
240MHz
WiFi only (no Bluetooth)
320KB SRAM
43 GPIO
USB-OTG native"]
            S3["ESP32-S3 (2021)
Dual Xtensa LX7
240MHz
WiFi + BLE 5.0
512KB SRAM
45 GPIO
AI/vector instructions
USB-OTG native"]
        end

        subgraph "RISC-V Architecture"
            C3["ESP32-C3 (2021)
Single RISC-V
160MHz
WiFi + BLE 5.0
400KB SRAM
22 GPIO
Smallest package"]
            H2["ESP32-H2 (2023)
Single RISC-V
96MHz
BLE 5.2 + 802.15.4
Thread + Zigbee
256KB SRAM
No WiFi"]
        end
    end

    OG -->|"Cost reduction"| S2
    OG -->|"Performance upgrade"| S3
    OG -->|"Size + efficiency"| C3
    C3 -->|"IoT mesh focus"| H2

    subgraph "BLEShark Nano Choice"
        WHY["ESP32-C3 selected for:
- BLE 5.0 (security scanning)
- WiFi (monitor mode capable)
- RISC-V (open architecture)
- Small QFN-32 package
- Low power (battery device)
- Cost effective"]
    end

    C3 -->|"Selected"| WHY

ESP32 family evolution - from the original dual-core Xtensa to RISC-V variants, showing why the C3 hits the sweet spot for BLEShark Nano's size, power, and wireless requirements.

ESP32-S2: Low-Power, No Bluetooth

The ESP32-S2 launched in 2019 and made a controversial tradeoff: it dropped Bluetooth entirely in exchange for lower power consumption, native USB-OTG, and a smaller die. If you don't need Bluetooth and want to build a USB device (HID keyboard, CDC serial adapter, mass storage) natively without an external chip, the S2 is the right choice.

Key specs of the ESP32-S2:

• CPU: Single Xtensa LX7, 240MHz
• RAM: 320KB SRAM + 128KB RTC SRAM
• WiFi: 802.11b/g/n, 2.4GHz
• Bluetooth: None
• USB: Full-speed USB-OTG 1.1 (native)
• GPIO: 43 pins

The native USB-OTG is the S2's signature feature. Your firmware can present the ESP32-S2 directly as a USB HID device, a USB CDC serial device, or a USB mass storage device without any external chip. This makes the S2 ideal for USB peripherals, USB security keys, and USB-based HID injection devices (a USB equivalent of what Bad-BT does over BLE).

Without Bluetooth, the S2 is inappropriate for anything in the BLEShark's feature set that involves BLE. It's also single-core, which limits parallel processing compared to the original dual-core ESP32. Lower power consumption than the original is a real advantage, but the C3 pushes that further at lower cost.

ESP32-S3: Dual-Core, AI, USB-OTG

The ESP32-S3 is the most capable variant, launching in 2021. It combines dual-core processing with native USB-OTG, BLE 5.0, WiFi 802.11n, and dedicated vector instruction extensions for AI/ML inference workloads. If you're building something that needs everything, the S3 delivers.

Key specs of the ESP32-S3:

• CPU: Dual Xtensa LX7, 240MHz
• RAM: 512KB SRAM + 384KB RTC memory
• WiFi: 802.11b/g/n, 2.4GHz
• Bluetooth: BLE 5.0 (no Classic BT)
• USB: Full-speed USB-OTG 1.1 (native)
• GPIO: 45 usable pins
• AI extensions: PIE (vector instructions for machine learning)

The S3's AI vector extensions make it suitable for on-device inference - running small neural networks for wake word detection, image classification, or anomaly detection directly on the chip without cloud connectivity. This opens up use cases in voice-controlled devices, smart cameras, and edge AI applications that would be impractical on other ESP32 variants.

The S3 is the largest and most power-hungry variant. Dual-core at 240MHz with all peripherals active draws significantly more current than the C3. For battery-powered applications with modest processing requirements (like the BLEShark), the S3's capabilities are overkill and its power draw is a liability. The S3 excels in mains-powered or USB-powered applications where you need raw processing power or USB-OTG.

ESP32-C3: RISC-V, BLE 5, Smallest Package

The ESP32-C3 is the variant in the BLEShark Nano. Launched in 2020, it switched from Xtensa to RISC-V architecture - a significant change from prior ESP32 chips. RISC-V is an open instruction set architecture (ISA) with no licensing fees, a growing toolchain ecosystem, and increasingly competitive performance per watt compared to Xtensa.

Key specs of the ESP32-C3:

• CPU: Single RISC-V, 160MHz
• RAM: 400KB SRAM
• WiFi: 802.11b/g/n, 2.4GHz
• Bluetooth: BLE 5.0 (no Classic BT)
• USB: Full-speed USB Serial/JTAG (limited - not full OTG)
• GPIO: 22 pins
• Package: QFN32 (5x5mm) - smallest in the family

The C3's RISC-V core at 160MHz is single-core, but the architecture is more power-efficient per clock than Xtensa. Active WiFi current is lower than the original ESP32 or S3. The combination of 2.4GHz WiFi and BLE 5.0 covers the BLEShark's entire feature set. BLE 5.0 (vs the original's BLE 4.2) adds Long Range mode (coded PHY at 125 kbps or 500 kbps) and higher throughput LE 2M PHY mode.

The C3's smaller GPIO count (22 vs 34+ on other variants) is sufficient for the BLEShark's needs: I2C for the OLED, GPIO for buttons, UART for debugging, and the IR LED. More pins would just go unused.

The C3 also tends to be cheaper than the S2 and S3. At high volumes, the smaller die and simpler peripheral set translate to lower BOM cost. For a product at $36.99, every component cost matters.

ESP32-H2: Thread, Zigbee, No WiFi

The ESP32-H2 is the most specialized variant, designed for IEEE 802.15.4 mesh protocols - Thread and Zigbee. These are low-power mesh protocols used in smart home devices (Matter, Thread-enabled bulbs, Zigbee sensors). The H2 has no WiFi radio, which is a significant limitation for most development use cases but a deliberate tradeoff for IoT end nodes.

Key specs of the ESP32-H2:

• CPU: Single RISC-V, 96MHz
• RAM: 320KB SRAM
• WiFi: None
• Bluetooth: BLE 5.3
• IEEE 802.15.4: Thread and Zigbee support
• USB: Full-speed USB Serial/JTAG
• GPIO: 19 usable pins

The H2 is for smart home product development where you need Thread/Zigbee compliance, not for general-purpose WiFi devices or security tools. For the BLEShark's feature set (WiFi scanning, deauth, captive portal, BLE spam, IR), the H2 is wrong on multiple dimensions - no WiFi, lower clock speed, fewer GPIOs, and an 802.15.4 radio that none of the BLEShark's features use.

The H2's BLE 5.3 is the newest BLE version in the family and supports features like subrating (for power-efficient connections) and improved channel classification. These features are relevant for BLE device development but don't add security research capabilities beyond what BLE 5.0 already provides.

Side-by-Side Comparison

Why BLEShark Nano Uses the C3

The BLEShark Nano needs: WiFi 2.4GHz (for scanning, deauth, AP hosting, frame injection), BLE 5.0 (for BLESpam, BLE scanning, Bad-BT HID, Shiver mesh coexistence), sufficient RAM for firmware + file buffers + display buffer, and a price point that keeps the product at $36.99.

The original ESP32 would technically work - it has WiFi and BLE, dual-core for parallel processing. But it's older, draws more power, and costs more. The BLE 4.2 implementation is also less capable than BLE 5.0 (no Long Range mode, lower throughput).

The S2 fails immediately - no Bluetooth. The S3 is technically superior in processing power but costs significantly more and draws more current. For a pocket device on a 500mAh battery, the S3's power profile is a liability. The H2 has no WiFi.

The C3 hits the exact requirements: 2.4GHz WiFi, BLE 5.0, 400KB SRAM (enough for the firmware stack + display buffer + file buffers), low power consumption, small package, and competitive cost. The single-core RISC-V at 160MHz handles the BLEShark's workload without issue - most of the work is radio operations (handled by the RF hardware), not CPU-intensive computation.

The BLE 5.0 Long Range mode (coded PHY at 125 kbps or 500 kbps) is specifically useful for the Shiver mesh's Long Range ESP-NOW mode, which extends node-to-node range to 20-50m in open space. BLE 4.2 doesn't support Long Range PHY, which would limit mesh coverage.

Choosing the Right Variant

Quick decision guide for your own projects:

graph LR
    subgraph "Use Case Selection Guide"
        subgraph "Need BT Classic + WiFi?"
            UC1["Audio streaming
SPP serial bridge
Legacy Bluetooth"] --> PICK_OG["Choose: ESP32 Original"]
        end

        subgraph "Need USB HID + WiFi?"
            UC2["USB keyboard/mouse
Low power WiFi
No Bluetooth needed"] --> PICK_S2["Choose: ESP32-S2"]
        end

        subgraph "Need AI + Camera?"
            UC3["Image recognition
Voice processing
USB + BLE + WiFi"] --> PICK_S3["Choose: ESP32-S3"]
        end

        subgraph "Need small + BLE + WiFi?"
            UC4["Wearables
Security tools
Battery devices
Cost-sensitive"] --> PICK_C3["Choose: ESP32-C3
(BLEShark Nano)"]
        end

        subgraph "Need Thread/Zigbee?"
            UC5["Smart home mesh
Matter protocol
Low-power sensors"] --> PICK_H2["Choose: ESP32-H2"]
        end
    end

ESP32 variant selection guide - each chip targets different use cases, from the original's Bluetooth Classic support to the H2's Thread/Zigbee mesh networking.

Need Classic Bluetooth (audio, SPP): Original ESP32. No other variant supports it.

Building a USB HID/CDC/mass storage device: ESP32-S2 or S3. Native USB-OTG.

Need AI/ML inference or dual-core with USB: ESP32-S3.

Building a battery-powered BLE + WiFi device (sensors, wearables, security tools): ESP32-C3. Best power-to-capability ratio.

Building a Thread or Zigbee smart home node: ESP32-H2.

For the security research and wireless tooling use case that the BLEShark Nano represents, the C3 is the correct answer. RISC-V architecture, BLE 5.0, full 2.4GHz WiFi, and a power profile that makes a 500mAh battery last a useful working session. The Shiver mesh's 16-node capability (available with Shiver packs) further leverages the C3's Long Range BLE mode for extended coverage.

Get BLEShark Nano