Tuesday, February 2, 2016

Thermometer application with nRF51822 and Android

I built quite many prototypes on this blog with RFDuino based on Nordic Semiconductor's nRF51822 and I can still recommend that small development board to people who want to get initiated quickly and painlessly into the world of Bluetooth Low Energy programming. The limitations of RFDuino became apparent quite soon and it was time to get deeper. On the other hand, I wanted to stay with the excellent nRF51822 so I looked for a breakout board - as simple as possible.

This is how I stumbled into Florian Echtler's page about low-cost BLE development environment based on the nRF51822 and the Bus Pirate programming tool. So I quickly ordered a no-name variant of Waveshare's Core51822 breakout board, a Bus Pirate tool and a bunch of DHT-22 sensors (because I wanted to measure something in the environment). Also note that the breakout board has a connector with 2 mm pin spacing which is not the usual 0.1 inch pitch. It helps if you have a prototyping board with both 2 mm and 0.1 inch pitch like this one which cannot be found in every store.

Generally speaking, following the instructions on Florian's page was easy enough. I ran into two issues. First, I had no success with the SWD programming software he refers to but Florian's fork (which is based on an earlier version of the programming software) worked well for me. Second, I experienced instability if the GND pins of the breakout are not connected (there are 2 of them).

First about the hardware. The schematic below show only the parts that are connected to the pins of the breakout board, the schematic of the breakout board itself is not included.


  • DHT-22 is connected to P0.17 which is both input and output depending on the communication phase.
  • P0.21 LED provides a feedback about the BLE activities. This is a convention coming from the PCA10028 dev board that we lied to the Nordic tool chain that we have. You can omit this LED if you want to save some energy.
  • SV1 header is a TTL serial port where the example program emits some debug messages. You can omit this header if you are extremely confident. I use a level converter like this to connect this port to a standard RS232C port. The UART operates on P0.18 (RxD) and P0.20 (TxD).
  • SV2 header goes to the Bus Pirate. Check out Florian's document about the connection. Make sure that this cable is as short as possible.
Here is how the board looks in all its glory, the Bus Pirate and the RS232C level converter boards in the background. These are of course not needed for deployment, the board runs standalone after the testing is successful.

Click here (adv_dht22.zip (nRF51822), bledht22.zip (Android)) to download the example programs related to this blog post.

Let's start with the code that goes into the nRF51822 which can be found in adv_dht22.zip. The assumption is that you completed Florian's instructions, including the upload of the S110 soft device. Then unzip adv_dht22.zip and do the following modifications:

  • Edit Makefile and make sure that the RF51_SDK_PATH variable points to the location where you installed the Nordic SDK.
  • Edit upload.sh and make sure that the paths point to the location where you installed Florian's version of the SWD programmer. Also, make sure that the USB device is correct (/dev/ttyUSB0 by default).
Now you can say "make" and then "upload.sh". If all goes well, the code is installed in the nRF51822 and you get debug messages on the serial port. At this moment, the nRF51822 is already advertising the measurements it obtained from the DHT-22 sensor. You can check the content of the advertisements with this test tool.

The code looks quite frightening compared to the super-simple RFDuino equivalent but most of it is just template. My highlights:
  • Check out in advertising_init(), how the advertisement packet is set up. We transfer the measurements in a service data GAP field and I took the liberty to allocate a 16-bit UUID for it (quite far from the standard service UUIDs).
  • Check out timers_init(), timers_start() and sampler_timer_handler() methods how the periodic reading of the sensor and the update of the advertisement packet is accomplished.
  • DHT-22 sensor handling is done in dht22.c. This sensor has a somewhat peculiar 1-wire interface. Read this document and the code will be easy to understand.

Regarding the Android code: this is just the app/src part of the source tree of an Android Studio project. I adopted this rather primitive export method as this super-advanced IDE still does not have code export option that its obsolete predecessor, the Eclipse IDE used to have. Check out onLeScan method in MainActivity.java to see, how the BLE GAP parser introduced in this blog post is used to take apart the advertisement message and filter BLE nodes that advertise DHT-22 measurements.

The outcome looks like this:

Note that each sensor is identified by a 64-bit unique ID (a service of the nRF51822). Now this data just needs to be uploaded into some sort of service and then the big data analysis can start ;-). More about that later.


Anonymous said...

How about powering the device with batteries? Have you experimented with that? Would be nice to have the device running for months or years without direct connection to a power source. Any recommendations on the required parts?

Gabor Paller said...

Anonymous, there's a continuation post. If you scroll down to the end of that post, there's a picture, how the device looks like now. It runs on 3 AA batteries which is about 3600 mAh. The operating voltage range of this circuit is determined by the DHT-22 (about 3.1V minimum) and the nRF51822 (3.6V max). Hence I inserted a 1 Ohm serial resistor and a 3.6V Zener diode between the battery pack and the circuit as the nominally 3x1.2V batteries tend to have higher voltage initially that exceeds the nRF51822 max. 3.6V voltage.

With regards to power consumption: according to my measurements this circuit draws about 4-5 mA on average. With the 3600 mAh battery pack (which are quite ordinary batteries), that means about 30 days, 1 month. If that is not enough for you, look for specialist batteries like this one. This is a 17Ah battery, with this battery the device would remain operational for about 140 days. If that's still not enough, you can go higher, e.g. a typical car battery is 55 Ah but that's quite heavy.

One thing about batteries: normal, household batteries don't tolerate outside temperatures, look for that too.

hakan aydın said...
This comment has been removed by the author.
hakan aydın said...

Hi. I didn't compile your project. I get an errror from keil. The error is about
static ble_uuid_t m_adv_uuids[] = {}; . Keil said to me an empty initializer is invalid for an array with unspecified bound. how i can solve this problem ? Can you send the working full project to my mail ?

Gabor Paller said...

Hakan, this is the working full project in the ZIP file. It was compiled with gcc, you should look at the Makefile that also comes with the project, how to compile it. I never used the Keil compiler and I don't know, what sort of problem it has.

I did not try but what about removing this line (line 90):
static ble_uuid_t m_adv_uuids[] = {};

Change this line (line 257):
advdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
to this:
advdata.uuids_complete.uuid_cnt = 0;
and removing line 258 entirely?

Essentially we are constructing here an advertisement packet that does not have any advertised services but does have a service data structure (with the measurement data in it).

hakan aydın said...

Tenk you very much Gabor Paller. Your solution is working now. :)