Bluetooth Low Energy with module HM-12

While I am still waiting to receive a few Bluetooth Low Energy (aka Bluetooth 4.x) tags bought on Kickstarter and Indiegogo Crowfunding platforms, I recently ordered a HM-10 and a HM-12 modules. This modules being tiny, I went for the HMSensor version of the HM-12 thinking it would be easier to use straightaway.

HMSensor-12

Having this one to work turned into A Quest with a lot of wasted time... Since it is relatively badly documented, here is some information which, I hope, could be helpful to someone else. As always, it's a lot easier when one has the right documentation!

Supplying power

This part is simple and painless. The HMSensor has:

When the circuit is powered on, the blue LED starts to blink...

Serial connection

Thanks to the 2 TX & RX pins, using the UART/Serial connection should be very easy. The standard 9600,N,8,1 doesn't give anything, nor speeds just above (19200 or 38400 bauds). Usually when the speed is not totally correct, there is at least some garbled characters. In this case... Nothing, nada.

More about this later...

The iBeacon module from the same manufacturer mentions that AT commands can't be sent through the UART but have to be fed through a Bluetooth connection. Who knows, maybe this module was having the same behaviour?

Connection over BLE

It is worth noting here that I own an iPad 4th generation and a relatively old Android 4.1 mobile (hence without BLE).

The mobile being a no go with BLE, I tried a dozen of iOS apps to connect the iPad to the HM-12 module. The only one which seems usable for this purpose was Lightblue.

Yet, if I could see the module and establish a connection (blue light goes from blinking to steady), I was then stuck with one obscure service UUID: FFE0 and basta!

Still nothing interesting and moreover still unable to make anything of it.

Connection with standard bluetooth

The module being dual mode (i.e. Bluetooth 2.x & 4.x), I should have been able to see it under the settings panel but NO. Until I remembered that Apple is very picky about bluetooth connections and that only a few selected components are allowed to connect...

So, it was time to turn to the mobile which doesn't talk "New bluetooth" but is fluent in the "Old one": This time, I was able to see the HM-12 (by the way, it is by default advertised as "HMSoft" in both modes). After guessing the pin was "1234", connection was established promptly.

There are hundred of terminal/serial apps but again, nothing seemed to happen after the connection...

What am I doing wrong?

I scoured the web low and high, always going back to the same datasheets wh ere the HM-12 module was mentioned (in passing), pictured and where the HMSensor was described. But nothing to crack the connection challenge...

Even a documentation from a certain Tinysine HM-12 wasn't helpful as I still wasn't able to access any of the AT commands.

The Chinese company behind the HM modules has released 2 versions:

Both seems strictly identical otherwise and as I was about to give up, I searched for HM-13 instead of HM-12.

Miracle!!!!

A wiki page from Seeed-Studio gave me two clues as their "Grove - BLE (dual model) v1.0" breakout board was almost identical to my uncooperative sample!

There is light at the end of the tunnel

First, one essential indication: Baud: 115200, N, 8, 1

No wonder I could not communicate via the serial port... the set speed (115200 bauds) being way higher than the usual (and described in other datasheets) ones (i.e. 9600 bauds).

Another thing to know is that by default:

Actually the datasheet for these module can be found on the manufacturer's website but is NOT search engine friendly as it is hidden in a zip file called "Bluetooth Dual".

Obviously, everything is easier with the right datasheet...

The second useful thing on the Seeed-Studio wiki page is the way to use the lightblue App as a pseudo terminal emulator. Very handy!

Lightblue

Still one mystery...

The HM-10 firmware seems to come in 2 flavours: HMSoft and HMSensor. No trace of a HMSensor with HM-12 on the manufacturer site so I really wonder what is going on. Moreover, it doesn't really make sense to have a Old fashion bluetooth powered by a tiny lithium battery which would not last longer than a day!

I removed the HM-12 module (and damaged it in the process) and the HMSensor board bear the mention " HM-10". Fake? Assembly mistake? No idea. In the meantime, I soldered the HM-10 and playing with it right now!

    RTC with DS3231 and Raspberry Pi's I2C Bug?

    When a Raspberry Pi -- which doesn't have a hardware clock -- boots, the time can be set thanks to NTP. It usually works well enough to be totally transparent.

    Trouble usually starts if there is a power cut. By the time the Raspberry is up and running, the modem-router is usually still booting/synchronising with the ISP and no clock is set. Programmes start using the Epoch, i.e. 1st of January 1970!

    The best hardware workaround is certainly to use an external clock like "real" computers. Maxim's DS1307 has been a reference for years but is both 5V and not reputed for its accuracy.

    Raspberry Pi's I²C being in 3.3V, I tried to use a cheap RTC Clock using a DS3231 also from Maxim.

    There are loads of webpages explaining how to setup Linux to use this hardware clock and if at first everything worked fine, I then started to notice some problems.

    DS3231 + AT24C02

    Symptoms

    With Raspbian, the main problem was that after a while, I couldn't SSH to the server anymore. The Raspberry being headless, it wasn't easy to guess what was going on but it turned out this behaviour was the result of the disappearance of the root directory.

    And this was itself caused by an I/O error on the SD Card. It seems that the 2 main reasons for this to happen are:

    • Problem with the power supply
    • Faulty (or incompatible) SD Card

    The power supply was bought from RS with the first Raspberry and is rated 1.5A. Swapping with the second one (from Farnell this time) rated 2A didn't change anything. I then decided to use the other SD Card with a brand new Arch Linux on it.

    At first, no failure but then 2 problems also showed up:

    • Loads of log lines related to mmcblk or
    • An extremely slow Raspberry Pi with an non-explicable high load (~ 6)

    Solution?

    I was a bit lost but I found a forum message which gave me a very important clue:

    Second: disconnected the Dallas RTC DS3231, as it was pulling the 3.3v line too low, along with the DHT22 sensor.

    Another test

    Since I use a Level Shifter (3.3V/5V) on the I²C bus, it was very easy to move the DS3231 IC to the 5V side and try this theory. Unfortunately, this didn't make any difference.

    Reason?

    My best guess would be that the DS3231 or the AT24C02 EEPROM on the same module trigger the (in)famous Raspberry Pi I²C Hardware bug.

    Since I removed the module, the Raspberry Pi is no longer slow and load is now ~0.05.

    Software workaround

    With Arch Linux, I now force the application to start only when the network setup has completed (this includes proper NTP initialisation) by adding in the [Unit] section the following lines:

    After=network-online.target
    Wants=network-online.target
    

    Jeelabs weblog is back...

    I was very pleased when I discovered last month that Jean-Claude Wippler was thinking about restarting his blog. I was an avid reader of his adventures in the world of Electronics, Home Automation, Computing, etc...

    And if I still haven't experimented with the Jeenodes, I could one day find myself in need of the RF variant to use with 868Mhz IT+ sensors, etc...

    I was also glad to find PCA9635 already mounted as the chip only exists in SMD form. At the time, I was experimenting with RGB LEDs and debating PCA9635 vs WS2811.

    If I can't compete with Mr Wippler in terms of knowledge, skills, style and lab hardware, his blog was certainly one of the sources of inspiration for mine.

    Long live http://jeelabs.org/!

    Boxing, part 1

    Now the project is taking shape, there is a need to house:

    • a Raspberry Pi B+
    • some additional electronics (5V converter, transistors, ...),
    • the 433Mhz receiver + digispark
    • a LCD Screen (4*20)
    • 4 pushbuttons
    • the AirPi at the back
    • additional SD Card reader (or even USB hard drive)
    • Z-Wave USB-Key
    • ...

    Wooden box

    So far, the best potential solution I found would be a nice wooden box like this:

    Wooden Box

    They exist in different sizes and shapes, including 16.5 cm and 20.5cm. I have these 2 sizes and am currently testing what feels best.

    Adiabatic enclosure

    Having vague memories from my University years and the concept of adiabatic enclosure, notions of heat and the First Law of thermodynamics, I am also trying to work out if vents will be mandatory or not.

    The Raspberry model B+ seems a lot cooler than my old B (CPU is around 10°C cooler). I added a DS18B20 temperature sensor to monitor the temperature inside the wooden box and it is about 6-7°C more than that outside the box.

    According to Raspberry Pi Engineer Gert van Loo heat should not be a problem, but I'm trying to keep the temperature as low as I can.

    « Page 9 / 12 »