HC-05 vs HM-10 vs BLE 5.0: Which Bluetooth Module Should You Choose?

If you search for a “Bluetooth module for Arduino,” HC-05, HM-10, and BLE 5.0 are almost guaranteed to appear. They look similar: a small board with VCC, GND, TX, and RX. Choosing the wrong family can cost an afternoon of debugging because the phone cannot discover the device, the app speaks the wrong profile, or the battery drains faster than expected.

The important distinction is this: HC-05 belongs to Bluetooth Classic and commonly uses SPP like a wireless serial port; HM-10 uses Bluetooth Low Energy and GATT; and “BLE 5.0” is a family of modules, not one exact model.

The short version

They look similar on the bench, but HC-05, HM-10, and BLE 5.x use very different profiles and workflows.

Criteria	HC-05	HM-10	BLE 5.x
Technology	Bluetooth Classic, usually SPP	Bluetooth Low Energy, GATT	Bluetooth Low Energy with newer PHY/features
Programming model	UART as a transparent serial link	UART plus services/characteristics	UART bridge or programmable SoC
Phone support	Android is usually easier; no universal iOS SPP	Android/iOS can use BLE	Android/iOS can use BLE
Power	Often higher than BLE	Low, suitable for sensors	Depends on stack, PHY, and firmware
Best fit	Serial cable replacement, robots, computers	Simple BLE controls and sensors	New products, battery devices, long-term control
Trade-off	Older ecosystem and SPP dependency	Clone firmware is inconsistent	More firmware work and no single breakout standard

How Bluetooth Classic and BLE differ

Bluetooth Classic works well for stream-like connections. With HC-05, the MCU sends bytes over UART; the module handles Bluetooth, and the other side sees an SPP serial-style link.

BLE does not create a serial port by default. It organizes data through GATT: services contain characteristics, and characteristics support Read, Write, Notify, or Indicate. A phone must discover the expected UUIDs before exchanging data. The BLE communication design guide for IoT devices covers GATT, packets, MTU, and reconnection in more depth.

Choose the profile before the board: SPP behaves like serial, while BLE requires services and characteristics.

HC-05: easiest for wireless serial

HC-05 is often the fastest choice for a project that already has UART. The HC05 Arduino Library includes examples for controlling the module and entering AT command mode through its KEY/command pin.

It fits Android-controlled robots, logs between an Arduino and a computer, and replacing a serial cable in a prototype. Some modules also support master/slave roles, depending on firmware.

HC-05 is not BLE, so do not expect an iPhone to use it like a normal BLE peripheral. Many breakouts accept 5 V on VCC through a regulator while their UART logic remains 3.3 V. I check the exact breakout, especially its RX input, before connecting it to an MCU.

AT command mode also varies across clones. Data mode may use 9600 baud, while command mode often uses another speed and entry sequence. Send AT, confirm the response, and record the baud rate before writing firmware.

HC-05 is useful for replacing a serial cable, but verify UART logic levels and SPP support on the other device.

HM-10: a practical step into BLE

HM-10 is commonly sold as a BLE 4.0 module based on the CC2540/CC2541 family, but the market contains many clones carrying the HM-10 name. The actual firmware/version matters more than the name on a listing.

The MCU still talks over UART, but the phone no longer receives an automatic serial port. You need the service and characteristic UUIDs, then decide which characteristics support Write, Notify, or Read.

HM-10 fits small sensors, Android/iOS control apps, and prototypes that need BLE without owning the RF design. The cost is a GATT client: an SPP terminal app cannot replace it. I always read AT+VERSION, verify UUIDs, and test notifications on the exact module before committing to a PCB.

BLE 5.0: the label does not automatically mean faster

BLE 5.x adds options such as 2M PHY and LE Coded PHY. The Bluetooth SIG regulatory document describes 2M PHY as a higher-symbol-rate option than LE 1M, while LE Coded PHY targets longer range with trade-offs in speed and airtime.

A low-cost BLE 5.0 module may expose only part of that feature set, or its UART-bridge firmware may not let you select a PHY. Range still depends on transmit power, receiver sensitivity, antenna, enclosure, interference, and orientation. I would not put “BLE 5.0 = 2 Mbps and 100 m” in a specification without measuring the final hardware.

Illustration of an nRF52-style BLE 5.x board; BLE 5.0 is a feature family, while the actual module still depends on its chip, firmware, antenna, and enclosure.

For an nRF52 module, the Adafruit nRF52 Arduino core is a useful starting point. For ESP32, Espressif's ESP-IDF NimBLE examples help verify peripheral and central behavior before making a custom board.

Compare them against the job

I only need to control a robot from Android

Choose HC-05 if the app already uses SPP and you want the quickest prototype. Choose HM-10 if the app must work on iPhone and Android, accepting that you need a GATT client.

I am building a battery sensor

I would skip HC-05 first. HM-10 is enough for small telemetry; BLE 5.x becomes interesting when you need more control or have a longer roadmap. Measure advertising, connected idle, notifications, and reconnection instead of trusting one “low power” number.

I am building a product, not a prototype

I lean toward a BLE 5.x module with a real datasheet, maintained SDK, and known firmware. A breakout is only the RF layer; product quality also depends on the antenna, power, EMC, bootloader, OTA, and GATT design.

I want to replace one UART cable

HC-05 remains the easiest mental model, but check whether the other device supports Bluetooth Classic SPP. If the other end must include iOS, BLE is usually the safer compatibility path.

AT commands are not your product protocol

AT commands only configure the module. I separate three layers:

1. UART between MCU and module: baud, flow control, and logic levels.
2. Bluetooth link: SPP or GATT, pairing, and connection parameters.
3. Application protocol: version, length, and sequence/transaction ID.

With HC-05, the Bluetooth layer resembles a byte stream, so teams often skip layer three. With HM-10 and BLE 5.x, UUIDs, MTU, notifications, and subscription state must be documented. Start with a small versioned binary packet; it will age better than unstructured JSON.

Module selection checklist

• Is the target Android, iOS, a computer, or another Bluetooth module?
• Do you need SPP/serial streaming or GATT?
• Must the module be a peripheral, central, or both?
• Are the datasheet and firmware version known?
• Are the UART logic levels 3.3 V or 5 V tolerant?
• How do data-mode and AT-mode baud rates differ?
• Are KEY/EN, STATE/LED, and reset pins available?
• Is the onboard antenna clear of metal and near the enclosure edge?
• What is the current in advertising, idle, connected, and burst states?
• Will you need OTA, bonding, encryption, or future GATT changes?

Conclusion

If you are replacing a serial cable in an Android prototype, HC-05 is still practical. If you need basic BLE across iOS and Android, HM-10 is easier to start with. If this is a new battery-powered product or you need long-term control, I would choose a BLE 5.x module with a known chip, SDK, and documentation.

No module wins absolutely. Choose the profile first, then choose the board. Reversing that order is the fastest way to get a circuit that is technically connected but incompatible with the real app.

References

• GitHub - HC05 Arduino Library
• GitHub - HM-10 BLE Shield Sketch
• Bluetooth SIG - Bluetooth LE regulatory aspects
• GitHub - Adafruit nRF52 Arduino core
• GitHub - ESP-IDF NimBLE examples