HM-10 and HM-11: BLE and the Mysteries of Engineering Logic

Recently I added two BLE modules to the Nettigo offer: the HM-10 and HM-11. The former has already been in our offer, but for various reasons I decided that a version sourced directly from the manufacturer would be an interesting addition. First of all – availability without a soldered adapter board. If this module suits your needs, you can use it directly in your own project and on your own PCB. This matters when miniaturization is important.

And if you need even further miniaturization – besides the HM-10 available as an unsoldered module + adapter pair, we now also have the HM-11. The HM-11 uses the same chip and the same firmware, just in a smaller package. The tradeoff is that it loses some IO pins, although a few remain available.

Bluetooth 4.0 supported by the HM-1x modules is a completely different beast compared to the old, good Bluetooth 2.1 used by the HC-05, well known among Arduino enthusiasts. In simplified terms, the HC-05 is just a wireless serial pipe. You connect it to a microcontroller, send data over UART, and the bytes come out at the other end – whether that is another HC-05 connected to a different microcontroller or some application on a phone or computer.

With the HM-1x modules, the situation is a bit more complicated. Why? Because BT 4.0 introduced a different philosophy of operation. Instead of the point-to-point connection known from the HC-05, you get the ability to send data, receive data, and receive notifications from various services. Why make it so complicated? Because this architecture does not require devices to remain constantly connected, which means significantly lower power consumption. So if you plan to build small battery-powered devices with long operating times, BLE – Bluetooth Low Energy, another name for BT 4.0 – is something worth considering.

I won’t pretend to be a BLE expert myself, but recently circumstances forced me to work with it several times. This post is partly a way for me to organize and reinforce my own knowledge – maybe it will also be useful for you.

Preparing for use

OK, back to the HM-1x. As I mentioned, both the new BLE HM-10 and its smaller brother HM-11 come as an SMD module and an adapter board. If you are not mounting the module directly onto your own PCB as an SMD component, you first need to solder the module onto the adapter.

The adapter has tinned pads (only a small subset are actual pads – the rest are just silkscreen markings). Soldering with hot air is probably possible, but from experience I know that using a regular soldering iron is no problem at all. I always used a sharp conical tip; a standard tip would probably work too, although I haven’t tried it. The pad spacing is quite small, so using a fine tip is definitely better.

The whole process comes down to properly aligning the module with the adapter, soldering one point first (the pads are pre-tinned, but it helps to add more solder), then checking whether everything lines up correctly. If it does – continue soldering. If not, reheat that first pad and adjust the alignment.

You can try soldering the HM module loosely placed on the adapter, but if you want extra reassurance that nothing shifts accidentally, you can use a regular clothespin. Thanks to the tiny size, it holds the module perfectly in place.

After soldering the first few points, you can remove the clip and continue soldering. Shortly afterward, you have a finished module ready for connection.

Connecting the module

First tests – from a computer. I’m using the fastest USB/Serial converter around (everyone knows red ones are faster!). It also has the advantage of a jumper for selecting either 3.3V or 5V operation.

Importantly, this affects not only the voltage supplied to the converter’s Vcc pin. The TX/RX logic levels are also adjusted accordingly. The HM-1x modules are designed for 3.3V logic levels.

The previously mentioned HM-10 version with the larger adapter has built-in logic level converters, so for use with 5V systems (older Arduino boards), you either need the older HM-10 version (MOD-1441) or an external level shifter (for example our 4-channel MOD-636).

The module has 6 pins, but only 4 are required for connection: Vcc, GND, TX, and RX. The remaining two are 3.3V and GND. The adapter includes a voltage regulator (the module can be powered with up to 6V), and this is the output from that regulator. The additional 3.3V and GND pins can be used to power a sensor such as a DS18B20 or DHT. Why I mention this will become clear later.

Connect everything required (Vcc, GND, TX, RX) from the converter and start communicating with the module.

Here I have to admit I had quite a few issues, the exact cause of which I never fully identified. On my Ubuntu laptop, the module stubbornly refused to accept commands when using miniterm.py or picocom. Data was received, but I could not send anything. A custom Python script worked correctly, and the Arduino IDE Serial Monitor also had no issues. Even after whipping GPT for answers, we never reached any definitive conclusions. I assume it’s a problem with my heavily modified system.

AT commands

To use the module’s capabilities, you need to configure it using AT commands. The name comes from the fact that the commands begin with “AT”, supposedly short for “attention”. This protocol originated in the 1980s for controlling modems in the pre-internet era.

To check whether communication works, send the AT command to the module (baud rate 9600). The module should respond with OK. If not, check whether you swapped TX and RX – a very common mistake. You might also receive OK+WAKE, which means the module was asleep and has just woken up.

The AT command structure is usually AT+XXXX?, where XXXX is the command itself and the ? represents parameters. The parameter can either literally be a question mark or a value.

A question mark means you are querying a parameter. A value means you are setting it.

For example:

• AT+MODE? asks for the operating mode.
• The module might respond with OK+Get:0.

Here:

• OK means the command was valid,
• + is just a separator,
• Get:0 means the current value is 0.

Sending AT+MODE2 sets the operating mode to 2. The module responds with OK+Set:2.

Again:

• OK means success,
• + is the separator,
• Set:2 confirms the mode has been changed to 2.

The full command list is available in the HM-10 datasheet. There are many commands, and to fully utilize the module you really need to learn them. They are also closely tied to BLE concepts, so that’s another topic worth exploring.

Since we started with AT+MODE, let’s continue there. The modules have three operating modes: 0, 1, and 2.

Mode 0 resembles the classic HC-05 behavior – whatever one side sends appears on the UART of the other side. Let’s test it. Set the module to mode 0 using AT+MODE0 and connect to it from a phone.

Phone applications

If you need an app for tinkering with BLE, I recommend nRF Connect. I personally use Android, but nRF Connect is probably available on iOS as well. The app allows detailed exploration of the BLE protocol.

If you only need communication and control, something simpler is enough – I recommend Serial Bluetooth Terminal (SBT), which I’ll use here.

Thanks to the simplicity and native support for HM-1x modules in SBT, using these modules feels somewhat like the old HC-05 “data pipe” approach. If you are interested, install nRF Connect and start looking “under the hood”. But I’ll skip those details here because I don’t feel qualified enough to explain BLE internals properly.

On the main SBT screen, tap the hamburger menu to access Devices, select the Bluetooth BLE tab, and press SCAN in the upper-right corner. After a moment, you should see HMSoft, which is the default name of the HM-10/11. If it doesn’t appear, make sure the module is not asleep. Tap it and you are connected.

As you can see, there is no pairing process. That’s the module’s default configuration, not a BLE limitation. Pairing can be enabled, but since this is BLE 4.0, don’t expect sophisticated security features. This is mainly a simple module for amateur BLE experimentation.

If you are thinking about serious HM-10 applications, stick to publicly accessible services – for example a temperature sensor that anyone can read.

Sending data

Now simply type something in SBT and it will appear on the module’s UART. Likewise, anything typed into the Serial Monitor appears in SBT.

In MODE 0, the entire data stream is transparently transmitted both ways.

Blue messages are sent from the phone to the module, green messages are responses from the module.

More interesting things happen in MODE 1 or 2.

Send the command AT+MODE2 over UART.

Important: if a BT device is currently connected to the module, it ignores UART commands. You must disconnect the phone first before changing configuration settings.

Do you already have the HM-10 in MODE2? Now connect the phone and make sure SBT is not sending newline characters (hamburger menu -> Settings -> Send -> Newline: None). Then send AT.

Nothing will appear on the module UART (which I continuously monitor using the Serial Monitor), but the module itself responds with OK. Ask for the module name with AT+NAME? or firmware version with AT+VERS? and the module responds accordingly.

In modes 1 and 2, you can remotely control and configure the module over BLE using AT commands. You simply need to send the exact command without any extra newline characters. If the module does not recognize a command, it forwards the data to UART instead.

Here’s the communication sequence in MODE2:

Everything recognized as an AT command was executed, while anything unrecognized (*) was forwarded to UART. A message sent on UART (FG) was delivered to the phone.

The lack of newline characters makes the display slightly messy, but the behavior is easy to understand.

Pairing and security

In MODE 1/2 you can change the modem configuration entirely through AT commands.

Let’s cover the absolute minimum: the PIN code.

The PIN must contain 6 digits, and by default it is 000000.

Set a new PIN with:
AT+PASS112233

Now the new PIN is 112233.

Setting the PIN alone is not enough – you also need to enable pairing/bonding.

You have two options:

• AT+TYPE2
• AT+TYPE3

In both cases, pairing with PIN entry is required.

With TYPE3, devices are bonded, meaning future connections happen automatically.

So:

• TYPE2 → PIN required every connection
• TYPE3 → PIN required only the first time

The temperature sensor twist

Now we arrive at the mystery from the article title. According to the documentation, this feature should only exist in firmware V7xx or earlier HMSensor firmware variants. Meanwhile, the firmware identifies itself as standard HMSoft v610. And yet – it works. What am I talking about?

The CC2451 chip used in the HM-10 and HM-11 has a built-in temperature sensor, and the firmware supports it. However, if you want to use it – it seems pretty useless :)

Mine constantly reports temperatures between 22-25°C. After half an hour in the fridge (with power disconnected), once powered again it immediately reported 22.31°C. In an oven heated to 40°C it showed 24.80°C. The direction of change is technically correct, but the readings are not really useful. But there’s more news and they are much more interesting.

Alongside AT+TEMP?, the firmware supposedly supports AT+SENSOR?. There are three modes:

• 0 → internal sensor
• 1 → DHTxx
• 2 → DS18B20

The HM-10 supports external sensors connected to pin PIO011 (physical pad 34), while the smaller HM-11 uses PIO03 (physical pad 13).

I mentioned earlier that not all adapter pads are actually exposed as metal contacts – some are merely silkscreen markings. The choice of which IO pins received real pads is another example of mysterious Chinese engineering logic ;) On the HM-10, the external sensor pin is a proper pad. On the HM-11, it is not. Still, this is not really a problem. It’s easy enough to solder a wire directly either to the HM-10 pad or directly onto the HM-11 module itself.

Connecting a DS18B20

Now things get a bit messy with wires.

Take one of the waterproof DS18B20 sensors on a cable, solder its wires to a connector, and add a pull-up resistor between Vcc (red wire) and signal (yellow wire). About 4.7kΩ is fine – I happened to use two 2.2kΩ resistors because I had them nearby. Then connect everything to the previously mentioned GND and 3.3V output pins on the adapter.

My DS18 sensor was already prepared for connection to NAM, so the wire order was predetermined. If I were building this specifically for the test, I would arrange the wires differently so the connector could plug directly onto the GND and 3V3 pins, with only the signal connected separately to the HM-1x sensor pin.

I didn’t want to resolder everything, so the wiring became a bit messy.

The DS connector sits on the GND pin, power comes from a female-to-male jumper wire, and the signal uses an extra soldered wire.

Now send:

• AT+SENSOR2
• AT+TEMP?

The first reading always returns 085.00 for me, but subsequent readings are sensible.

As you can see, the temperature changes quite clearly. I placed the sensor outside the window where it was around 15-16°C and the DS18 correctly reported the temperature – unlike the internal sensor.

Summary

This article has already grown quite large, so let’s stop here for now and will continue later.

The HM-10 (MOD-2391) and HM-11 (MOD-2392) are small BLE modules offering basic BLE 4.0 functionality (which is already quite an old standard). If you have no BLE experience and want to start experimenting with this technology, the HM-10 and HM-11 are probably good starting points.

Besides UART communication, they also support direct temperature/humidity sensor reading. You can also control outputs, read digital inputs, and measure voltages – all without a microcontroller.

The HM-10 (MOD-2391) and HM-11 (MOD-2392) versions currently ship with firmware V610 supporting external sensors. The older HM-10 already in our offer (MOD-1441) currently does not support this feature (firmware V605).

In future orders we’ll try to ensure those capabilities are included there as well, since it is based on the same HM-10 hardware.