Tag Archives: Humidity

Matters relating to the measurement of air humidity

Building the hardware for a room sensor

The final sensor housing design

Here at Cranfield University we are putting in place plans related to the new ‘Living Laboratory’ project, part of our ‘Urban Observatory’. This project sits within the wider UKCRIC initiative, across a number of universities. Of the many experiments in development, we are gathering environmental data from IoT devices and building data dashboards to show the data and related analyses. One of our projects will be to investigate air quality on the campus, in our lecture rooms and public spaces. Cranfield is a unique University in the UK for having its own airfield as part of the campus – we want to monitor any particular impacts that can arise from this. In this blog we discuss building the hardware for a room sensor to detect levels for temperature, humidity, barometric pressure and VOC (volatile organic compounds).

In previous blogs, we have explored the use of the fantastic Bosch BME680 sensor from PiMoroni with the equally fantastic Particle Photon board to detect environmental characteristics. This blog post is more about building the hardware for the sensor, describing a prototype design.

An initial issue is how to site the sensor in a room. We were considering at first fixing sensors to walls, and running power to the case with trunking going up the wall from power sockets. This is all pretty unsightly and obtrusive. However, an idea then emerged that offers a perfect solution. Each room has a WiFi router positioned centrally on the ceiling, and each router has a spare USB socket. The design goal was therefore to design a plug-in unit that can be positioned in this USB socket. There certainly shouldn’t be an issue with WiFi connectivity!

WiFi ceiling mounted routers
Routers have a spare USB socket

We therefore looked to find a suitable case to fit a Particle photon, and the sensor, with the ability to plug into the USB socket. We found the perfect case from Farnell, the Hammond 1551USB3TSK USB Plastic Enclosure. We also bought a right angled USB PCB plug. Together with the Photon and BME680, all the parts looked like this.

Components being assembled for build

The next stage involved soldering the PCB USB connector onto a piece of veroboard and cutting it to fit with the trusty Dremmel saw, drill and deburring tool.

After much fiddling with the components, the piece was starting to take shape. The first task was to fit the USB connector. We cut out a piece of veroboard and then cut it to fit. As can be seen this was a pretty fiddly task. The USB plug needed fixing in place so the case could plugged in and removed without the USB plugboard moving. Next time we realised we should use the case pillars better and cut a slot out to fit around them!

Finally, after the USB board was fitted, the rest of the components could be fitted and wired up. The other end of the case then had a small slot routed in to allow the sensor to be stuck through to poke outside. We found that in use the Photon can heat up, so we wanted the temperature sensor located as far away as possible from it and to have the sensor exposed to the air. We then needed to wire the components up permanently which meant soldering wires in rather than using the header pillars that our earlier prototype had used. We had our wiring diagram to work to from our prototype.

We realised there was not enough space in the case for adding header blocks on the Photon or the sensor, so soldering directly to their PCBs was the only way to proceed. Soldering makes a permanent join, but the electronics of both the photon and BME680 sensor are very delicate, so we were careful to use the absolute minimum heating time from the soldering iron to make the joins, and use a solder with plenty of flux. This resulted in satisfactory joins. Also, we needed to get the 5v power to the Photon from the USB plug unit. To to this we took the power lines off and soldered directly to the VIn and Gnd pins on the photon (bypassing the micro USB socket).

The final wiring in place, the unit is ready for assembly

Once the wiring was all in place and all the solder joints checked carefully under a powerful magnifying lens (to check there were no ‘dry’ joints), the components could be packed out with sticky pads to ensure there was no rattling around. Finally we could fit the lid on the case and screw it all into place.

The final assembly was very satisfactory. We could turn it on to test it by plugging it into a USB charger battery. The photon was brand new and so commenced the setup routine with the flashing blue light. We were able to then connect to it with our mobile, claim and name the deice, and then upload the source code previously written. able to save off a JSON structure with all the data included to the Particle cloud on a regular basis. The Photon’s excellent design means that even once one or more units are deployed, their code can be flashed remotely to update their functionality. Multiple devices can be grouped into ‘products’ to allow concurrent code maintenance. We realise we will have to work out how to have photons automatically identify themselves individually when multiple data sources are collated to one database – something to think about next!

The new sensor in use and generating data

A test of the electrical current for the completed unit shows a draw of about 530mAh, which is pretty small for such a sensor and acceptable in that it isn’t drawing off too much current.

Epilogue

The exercise here is more one of hardware than of software – all the code and software methodologies were sorted as described with the earlier prototype. Here we have a physical design which will do what we want, plugging unobtrusively into a spare USB socket located on a WiFi router on the ceiling. The device will be now fixed into place in a lecture room and tested. To extend the project to a campus-wide solution, ideally a custom PCB would be created, designed to fit the case perfectly (or a dedicated case could be designed and 3D printed). Also, to gather the data together, potentially from multiple sources we will need a ‘dashboard’ and a linked database in a system able to receive the data streams. This solution would be bigger than the ThingSpeak tooling we have used for recent prototypes. We have been experimenting with ThingsBoard for this system scale solution, with a provisional version already running on a test Raspberry Pi – perhaps this will become the subject for a future blog.

Arduino – making a simple BlueTooth data logger

Introduction – Arduino
Arduino_01Another area of informatics interest, here at Cranfield University is the use of the amazing Arduino microprocessor board for various projects. With the increasing emergence of the ‘Internet of Things’, ‘big data’ and machine to machine communication, the Arduino represents a great starting point for learning about this field.

What we wanted was to develop the basis for a simple data logger using an Arduino ‘Uno’, using a simple temperature and humidity sensor module, used to take readings that can be read off remotely with data retrieved via BlueTooth.

This post assumes you have already installed the Arduino IDE and are able to build and run programmes, or ‘sketches’. The Arduino site has an excellent Getting Started page if not.

Arduino_JY_MCU_BlueToothThe first thing is to get the BlueTooth working. For this we bought an inexpensive JY-MCU module from the website dx.com. This unit has 4 pins, VCC voltage (3.3-6v); TX; RX; Gnd. Typically the other two connectors, State and Key, do not have pins soldered in.

The BlueTooth JY-MCU unit is advertised as being able to take power at either 3.3 or 5v. Many designs on the web for using this unit use resistors to split the voltage, but for this application we connected directly VCC to the Arduino 3.3v, and the Gnd to Gnd. The receive and transmit pins were connected respectively to digital pins 10 and 11. When hooked up with the software sketch below, the Bluetooth RX goes to the SoftwareSerial TX, and the BlueTooth TX to the SoftwareSerial RX respectively.

Configuring the BlueTooth module
Once connected, you can create a new sketch to allow communications. The first thing needed is configuration of the BlueTooth module settings – achieved by sending simple ‘AT’ commands to the unit. Byron’s Blog documents these codes really clearly, for example sending the module the command ‘AT+BAUD4’ sets its internal serial baud rate to 9,600bps. Note the device must be in an ‘unpaired’ state before these settings can be received.

A sketch can be set up to configure the module the way required, thus:

/* Include the software serial port library */
#include <SoftwareSerial.h>
/* to communicate with the Bluetooth module's TXD pin */
#define BT_SERIAL_TX 10
/* to communicate with the Bluetooth module's RXD pin */
#define BT_SERIAL_RX 11
/* Initialise the software serial port */
SoftwareSerial BluetoothSerial(BT_SERIAL_TX, BT_SERIAL_RX);

void setup() {
/* Set the baud rate for the hardware serial port */
Serial.begin(9600);
/* Set the baud rate for the software serial port */
BluetoothSerial.begin(9600);
delay(1000);

// Should respond with OK
BluetoothSerial.print("AT");
waitForResponse();

// Should respond with its version
BluetoothSerial.print("AT+VERSION");
waitForResponse();

// Set pin to 1234
BluetoothSerial.print("AT+PIN1234");
waitForResponse();

// Set the name to BLU
BluetoothSerial.print("AT+NAMEBLU");
waitForResponse();

// Set baudrate from 9600 (default) to 57600
// * Note of warning * - many people report issues after increasing JY-MCU
// baud rate upwards from the default 9,600bps rate (e.g. 'AT+BAUD4')
// so you may want to leave this and not alter the speed!!
BluetoothSerial.print("AT+BAUD7");
waitForResponse();

Serial.println("Finished!");
}

// Function to pass BlueTooth output through to serial port output
void waitForResponse() {
delay(1000);
while (BluetoothSerial.available()) {
Serial.write(BluetoothSerial.read());
}
Serial.write("\n");
}

void loop() { }

Alternatively, by contrast to pre-programmed statements as above, Clinertech’s great sketch here allows AT values to be typed in and set interactively.

The warning in the code above highlights the potential pitfalls of changing the speed of the internal BlueTooth serial communication to be higher than the default 9,600bps. We found that 57,600bps worked OK (‘AT+BAUD7’) on our unit. However, note that once this change is made, the code connecting to the Software Serial port also needs its speed adjusting to the new rate selected.

Temperature and Humidity
Once the BlueTooth module is configured correctly, the next step is to introduce the temperature/humidity module to the Arduino Uno. For this, we used a ‘DHT-11‘ module. This has three pins, + (vcc), – (gnd) and signal (we connected this to Digital pin 12).

Note that a software library ‘TinyDHT’ was used to manage the communications with this sensor. The library is included in the code below in the same way the SoftwareSerial library is included.

// BT Data Logger
// BlueTooth Configuration
/* Include the software serial port library */
#include <SoftwareSerial.h>
/* to communicate with the Bluetooth module's TXD pin */
#define BT_SERIAL_TX 10
/* to communicate with the Bluetooth module's RXD pin */
#define BT_SERIAL_RX 11
/* Initialise the software serial port */
SoftwareSerial BluetoothSerial(BT_SERIAL_TX, BT_SERIAL_RX);

// DHT-11 Configuration
#include <TinyDHT.h> // lightweight DHT sensor library
// Uncomment whatever type sensor you are using!
#define DHTTYPE DHT11 // DHT 11
//#define DHTTYPE DHT22 // DHT 22 (AM2302)
//#define DHTTYPE DHT21 // DHT 21 (AM2301)
#define TEMPTYPE 0 // Use 0 for Celsius, 1 for Fahrenheit
#define DHTPIN 12
DHT dht(DHTPIN, DHTTYPE); // Define Temp Sensor

void setup() {
/* Set the baud rate for the software serial port */
BluetoothSerial.begin(57600); // Initialise BlueTooth
delay(1000);
dht.begin(); // Initialize DHT Teperature Sensor
BluetoothSerial.print("Starting ...");
}

void loop() {
// Take readings
int8_t h = dht.readHumidity(); // Read humidity
int16_t t = dht.readTemperature(TEMPTYPE); // read temperature

if ( t == BAD_TEMP || h == BAD_HUM ) { // if error conditions (see TinyDHT.h)
} else {
BluetoothSerial.print("Temperature: ");
BluetoothSerial.print(t);
BluetoothSerial.print(", Humidity: ");
BluetoothSerial.print(h);
BluetoothSerial.print("\n");
}
}

This code sets up the ‘software serial’ port to receive the output from the BlueTooth module. Readings of temperature and humidity are then taken and output constantly.

SoftwareSerialAccessing the data
To access the data being sent by the Arduino Uno, a few steps are required. First you need a computer with a BlueTooth capability. If your computer doesn’t have BlueTooth, inexpensive ‘USB BlueTooth dongles’ can be bought. By example, the instructions to do this using a MacBook are as follows: the laptop BlueTooth is turned ‘on’, and the ‘System preferences’ -> ‘Network’ dialogue opened. The ‘BlueTooth option is selected, and the Arduino module should then hopefully appear in the available devices list and can be selected and ‘paired’ (using the pairing number set earlier – e.g. the default being ‘1234’). Finally, with BlueTooth still connected and paired, the last step is to open a serial monitor window, connected to the BlueTooth port, which is then used for monitoring the BlueTooth Software Serial port and the data being generated. To achieve this last step, open the Arduino IDE. First select the menu ‘Tools’ -> ‘Port’, then select the BlueTooth device (with the name set earlier); finally select ‘Tools’ -> ‘Serial Monitor’. As long as the baud rate matches that of the BlueTooth module the data readings should be shown as here.

What next?
Having this all working is just the start of a bigger project. One option would next be to attach to the Arduino an SD card writer, to allow data to be saved locally, with BlueTooth then used to access the data periodically. Data could be time-stamped using a separate clock module, or geo-positioned with a GPS module.

Processing Temperature Humidity Data LoggerTo do something more useful with the data being received, there are also a number of options. The ‘Processing’ language is gaining interest (see https://processing.org), and can be used to extract data (perhaps re-formatted as a data stream), suitable for graphing or further analysis. Of interest, the Arduino IDE itself is a subset of Processing. One excellent example using Processing that we followed and adapted here is Bhatt’s P2_DHT11_Logger project.

A further development beyond this could be to write a mobile device ‘app’ to make the connection via the mobile device’s BlueTooth. Future posts here may develop on these themes.