If you are searching for an Arduino Bluetooth BLE solution, the first thing to do is throw away your HC-05. Classic Bluetooth Serial Port Profile (SPP) is effectively dead for modern mobile apps because Apple blocks SPP entirely on iOS, and Android is actively deprecating it in favor of Bluetooth Low Energy (BLE). To get an Arduino talking to a modern smartphone, you must use BLE. The direct answer for new builds is to bypass external UART modules entirely and use a native BLE microcontroller like the ESP32-C3 SuperMini. If you are locked into a legacy 5V Arduino Uno, you must use an HM-10 module with a strict voltage divider on the TX line.

The Physical Layer: UART Wiring and Bus Mechanics

Unlike I2C or SPI, BLE modules do not communicate with the host microcontroller over a shared synchronous bus. They use an asynchronous UART serial link. This means you don't need I2C-style pull-up resistors on SDA/SCL lines; instead, your primary physical layer concern is logic level translation. Most BLE modules (HM-10, JDY-08, ESP32) operate at 3.3V logic, while the classic Arduino Uno outputs 5V on its TX pin. Feeding 5V into a 3.3V BLE module's RX pin will fry the module's UART transceiver within seconds.

Table 1: Bus Mechanics — UART Bridge vs. Native BLE RF
Parameter UART Bridge (Arduino to HM-10) Native BLE RF (Module to Phone)
Physical Wires TX, RX, VCC (3.3V), GND None (2.4 GHz ISM Radio)
Bus Speed 9600 to 115200 Baud 1 Mbps or 2 Mbps PHY
Addressing None (Point-to-Point UART) 48-bit MAC / 128-bit UUIDs
Max Distance < 1 meter (UART trace limit) ~30m (indoor) / 100m (outdoor LoS)
Topology 1 Host to 1 Module 1 Central to Multiple Peripherals
Bench Tip: The 5V to 3.3V Voltage Divider
To safely wire an Arduino Uno TX (Pin 1) to an HM-10 RX, build a voltage divider. Place a 1kΩ resistor in series from the Arduino TX to the Module RX. Then, place a 2kΩ resistor from the Module RX to GND. This drops the 5V HIGH signal down to a safe ~3.33V. The Module TX (3.3V) can wire directly to the Arduino RX (Pin 0), as the ATmega328P reliably reads 3.3V as a logic HIGH.

Protocol Decision Tree: Which BLE Path to Take

Choosing the right hardware for Arduino Bluetooth BLE depends entirely on your mobile app requirements, power budget, and whether you are retrofitting an existing 5V board or spinning up a new prototype. Use this decision matrix to terminate your hardware selection.

Table 2: Hardware Decision Path
Condition / Requirement Hardware Path Pros & Cons
Must interface with legacy 5V Arduino Uno/Mega shields HM-10 (CC2541) UART Module Pro: Simple drop-in serial.
Con: Requires voltage divider; limited to AT commands; BLE 4.0 only.
Need ultra-low power (coin cell) & native BLE stack Adafruit Feather nRF52840 Pro: Native BLE 5.0, massive flash, excellent library.
Con: Higher cost (~$25).
Need WiFi + BLE, high processing power, low cost Standard ESP32-WROOM-32 DevKit Pro: Dual-core, cheap, huge community.
Con: High deep-sleep current compared to nRF52.
DEFAULT PICK: New build, low cost, native BLE 5.0, small footprint ESP32-C3 SuperMini Pro: ~$3, RISC-V, native BLE 5.0, fits breadboard.
Con: 3.3V logic only (requires level shifting for 5V sensors).

The Concrete Pick: For 90% of new Arduino Bluetooth BLE projects in 2026, buy the ESP32-C3 SuperMini (Part number: ESP32-C3-DevKitM-1 or generic clone). It costs under $4, runs the standard Arduino IDE via the Espressif core, and handles the BLE stack natively in hardware without tying up your main application loop with UART parsing.

Minimal Working Exchange: Native BLE UART Server

When using the ESP32-C3 natively, you don't use Serial.println() to send data to the phone. Instead, you create a BLE GATT Server using the standard Nordic UART Service (NUS) UUIDs. This allows apps like nRF Connect to read and write to your microcontroller over the air.

Wiring: No external BLE module is needed. The ESP32-C3 handles the RF internally. Just connect your sensors to the GPIO pins (e.g., I2C on GPIO 8/9).

#include <BLEDevice.h>
#include <BLEServer.h>
#include <BLEUtils.h>
#include <BLE2902.h>

// Standard Nordic UART Service UUIDs
#define SERVICE_UUID           "6E400001-B5A3-F393-E0A9-E50E24DCCA9E"
#define CHARACTERISTIC_UUID_RX "6E400002-B5A3-F393-E0A9-E50E24DCCA9E"
#define CHARACTERISTIC_UUID_TX "6E400003-B5A3-F393-E0A9-E50E24DCCA9E"

BLECharacteristic *pCharacteristic;
bool deviceConnected = false;

class MyServerCallbacks: public BLEServerCallbacks {
  void onConnect(BLEServer* pServer) { deviceConnected = true; }
  void onDisconnect(BLEServer* pServer) { deviceConnected = false; }
};

void setup() {
  Serial.begin(115200);
  BLEDevice::init("Arduino-BLE-C3");
  BLEServer *pServer = BLEDevice::createServer();
  pServer->setCallbacks(new MyServerCallbacks());
  
  BLEService *pService = pServer->createService(SERVICE_UUID);
  
  pCharacteristic = pService->createCharacteristic(
    CHARACTERISTIC_UUID_TX, BLECharacteristic::PROPERTY_NOTIFY);
  pCharacteristic->addDescriptor(new BLE2902());
  
  BLECharacteristic *pRxChar = pService->createCharacteristic(
    CHARACTERISTIC_UUID_RX, BLECharacteristic::PROPERTY_WRITE);
    
  pService->start();
  pServer->getAdvertising()->start();
  Serial.println("Waiting for BLE connection...");
}

void loop() {
  if (deviceConnected) {
    // Transmit sensor data over BLE
    String payload = "Sensor: " + String(analogRead(0));
    pCharacteristic->setValue(payload.c_str());
    pCharacteristic->notify();
    delay(500); // BLE connection interval pacing
  }
}

The Classic Failures: Baud Mismatches and MTU Drops

When debugging Arduino Bluetooth BLE setups, the physical RF link is rarely the problem. The failures almost always happen at the data boundaries. Here are the two classic bench failures and how to fix them.

1. The HM-10 AT Command Syntax Trap

If you are using an HM-10 module and trying to configure it via AT commands over the Arduino Serial Monitor, you will likely fail because of a baud and newline mismatch. Unlike the ESP8266 (which requires \r\n), the HM-10 CC2541 chip requires no line endings. If your Serial Monitor is set to "Both NL & CR", the module will ignore your commands. Set the Serial Monitor to "No line ending", ensure the baud rate is 9600, and type AT+NAME directly.

2. BLE MTU Fragmentation and Data Loss

The Maximum Transmission Unit (MTU) dictates how many bytes you can send in a single BLE packet. In BLE 4.0, the default MTU is 23 bytes (leaving exactly 20 bytes for your payload after a 3-byte GATT header). If your Arduino code attempts to push a 64-byte JSON string in one notify() call, the stack will either fragment it (causing massive latency) or drop it entirely.

The Fix: Request an MTU exchange upon connection. Modern smartphones support Data Length Extension (DLE). In your ESP32 code, call BLEDevice::setMTU(128); before starting the server. On the mobile app side, request the MTU update immediately after connecting. Always chunk your data into 20-byte packets if you must support legacy BLE 4.0 phones.

Sniffing and Debugging the BLE Bus

You cannot debug a BLE connection using just a hardware serial monitor, because the payload is encrypted and packetized over the 2.4 GHz spectrum. To see what is actually happening on the bus, you need to sniff the advertising and GATT layers.

  1. Layer 1 (App Level): Download nRF Connect for Mobile (iOS/Android). This is the definitive tool for viewing raw advertising data, scanning for UUIDs, and manually writing hex values to your RX characteristic to verify your Arduino is receiving data.
  2. Layer 2 (Packet Level): If you are debugging connection interval drops or MTU negotiation failures, you need a hardware sniffer. The Bluetooth SIG specifies the Link Layer, which you can capture using a Nordic nRF52840 Dongle flashed with the sniffer firmware, feeding directly into Wireshark. This allows you to see the exact LL_LENGTH_REQ and LL_LENGTH_RSP packets where MTU negotiation happens.
  3. Layer 3 (UART Bridge Debug): If you are stuck using the HM-10 and need to see the raw UART bytes between the Arduino and the module, insert a cheap $5 USB Logic Analyzer (Saleae clone) on the TX/RX lines and use PulseView to decode the async serial frames at 9600 baud.

By moving away from legacy SPP modules and embracing native BLE 5.0 hardware like the ESP32-C3, you eliminate the UART bottleneck entirely, ensuring your Arduino Bluetooth BLE project survives the realities of modern mobile OS restrictions.