The goal of the project was to create a proof of concept of a BLE connected device which should be able to monitor gas concentration and additionaly check the health of a gas boiler based on sounds emitted by it.
Arduino 101 seemed to be a perfect choice as a basis of such device, mainly thanks the built-in BLE module. Additional advantage of this module is that development of a software for the whole arduino family is fairly easy - so it should be possible to focus not on resolving programmatical problems but on the solution itself. It appeared however, that arduino language has some strange features and i had to spend some time on fighting them - but it might have been my fault - becuase i'm in general poisoned by Java and i had to recall several C/C++ rules.
Another argument for this choice was a presence of starter kits which contain basic compnents used in every design - so you don't have to focus on connecting LCD or buttons on your own - you can use those delivered in a starter kit. However (another however ;-) the Grove Starter Kit for arduino/genuino 101 has one flaw which makes it not suitable in all cases for cooperation with Arduino 101.
IdeaBut back to the project. Below you can find a picture with an initial idea:
First stage of the project was creation of a list of desired features. Based on my expectations i've made the following list:
- the device should be able to detect high concentration of gas in a room with a gas boiler. If too high concentration is detected, the device will inform about this fact with light and a loud sound.
- handling of the device should be as easy as possible
- it should have a possibility to send information about detected problems via BT/BLE. This feature might be used to connect the device with an BT/BLE-ready alarm/smart home system.
- it should be able to utilize also other techniques to assess a state of a boiler
- It shouldn't consume too much power - which is important taking into account principles of work of available gas sensors
After creation of this list i started searching for proper components - and initial idea started its evolution. Below you can see results of these thoughts:
Here are descriptions of choices i've made:
- Gas sensor - i chose a popular and cheap MQ4 gas sensor. It is not too accurate, so you cannot fully rely on concentration of gas presented in ppm by the device - but it should rather detect gas leakages. As you can see in the picture above - the circuit responsible for handling MQ4 is quite complicated. I've used there a bistable, one coil relay to control a heater of the sensor. In my opinion it is a good choice - better than MOSFET. Relays are enough durable and have neglible resistance of contacts. Another advantage is that they can be controlled with a voltage different than a voltage over a contact. In my case it was crucial - Arduino 101 has 3,3 v I/O and the MQ4 heater needs 5v. As i've mentioned - i've used for my project a bistable relay. Thanks this i could save some power - the relay doesn't have to be powered for the whole period of heating of the sensor. The only mistake was choosing a one coil relay - because of that i've had to create a H-bridge to control the relay. Two coils relays would be better - but i had one with one coil in my workshop, so i used it. The MQ4 sensor should be also powered itself with 5v - it raises a problem because ADC of Arduino 101 can work only up to 3.3 v. Because of that i had to create a network of resistors (R5-R9) to match signal from a sensor to range of the ADC.
- DS18B20 - in the MQ4 datasheet there is an information, that values returned by the sensor depend on external temperature - so i decided to add this sensor to the device. It allows to include this factor in calculation of concentration of gas.
- Grove temperature sensor - i use it to check, whether the heater works correctly. Another problem appeared here - LCD RGB Backlight must be powered with 5V voltage. It forces us to use 5V to power all other components connected via Base shield - also those connected to analog inputs (of course if we are using LCD in our projects). Because of that we cannot measure temperature in the whole range which is provided by the sensor. Fortunately, it doesn't matter in my case, because expected temperatures are in a range which can be measured by ADC, even with maximal voltage equal to 3.3v. I had to add some changes to the algorithm of calculation of a temperature to include this limits.
- Grove sound sensor - here is the same problem like with the temperature sensor. The sensor returns signal from 0 to 5 V and ADC is able to read it only up to 3.3 v. Because of that the device is not able to hear louder sounds - so right now my device raises alarm hearing even not too loud sounds. In the final solution this problem might be resolved in two ways - lowering the supply power of the sensor to 3.3 v or dividing output of the sensor to match the signal to maximal values accepted by ADC.
- Grove touch button sensor - i use it as a proximity sensor. Thanks this a user doesn't have to push any buttons - they can only close a hand to a device to turn off the alarm or turn on LCD display. Theoretically "touch button" sensor should react only when a finger almost touches it - but we can extend its range by enlarging the sensor are. For test purposes i used a small piece of aluminimum foil which was connected to the sensor. Thanks this i can switch off the alarm with my hand located no closer than 5 cm from the touch button.
Below you can find a result of thoughts given above. It is a picture of a working model of intelligent gas sensor.
The device works in the following way:
1) after being turned on, the device starts process of initialization. During this stage the status led blinks, the device is initialized (ds sensor, lcd display etc.) The heater of the MQ4 sensor is also turned on during this stage. This stage takes 3 minutes - it should be enough to achieve reliable readings from the MQ4 sensor - i've found information, that readings from this sensor stabilizes after 3 minutes. Before the end of this stage, the system checks temperature of the sensor - if it is not enough hot - device moves to DAMAGE state: information about a source of a problem is displayed on LCD, the led status continues blinking. The same behaviour is in case of problems with initialization of DS sensor.
2) after successfull initialization the device starts working. In this state the following tasks are performed:
- Every 1 minute external temperature is read, its value is presented on LCD and published via BLE.
- Every 3 minutes the device measures a concentration of gas. First it turns the heater on for one minute, after 1 minute it checks temperature of the sensor - if it is too low - the device moves to DAMAGE state. If temperature is ok - the device reads concentration and displays it on LCD. This value is also published via BLE. If concentration is too high (LEL - lower explosive limit of methane is 5% - of course the device raises alarm earlier, at much lower concentration) the device moves to ALARM state. Measuring gas concentration not continuosly but every 3 minutes saves energy (heater can consume up to 150 mA) and this frequency is enough to detect any danger connected with gas leakage early enough. Natural gas pressure is very low (at least in Poland) - and even if a hole in a gas pipe is big and room where the sensor is located is small - the device should detect the problem before concentration of gas achieves dangerous level.
- Level of sound is measured continuosly - if 3 of 5 consecutive samples exceed limit - the ALARM is raised.
- LCD display is turned off one minute after end of initialization. If you want then to see gas concentration or external temperature - you have to close your hand to proximit sensor - after that the device turns on LCD and displays there mentioned values. LCD display plays also a role of an ALARM lamp - if alarm is detected, LCD backlight starts blinking red. Thanks its size such red alert is well visible. In case of any problems, like malfunction of heater, LCD displays message with an information about it.
- Buzzer starts emitting alarm sound after detection of ALARM. For the first minute it is noisy (200ms of sound and 200ms of silence), then it becomes more convenient - it produces 200ms of sound every 1 second.
- Proximity sensor is the only (except of BLE) way to control the device. It has two functions - if the alarm is raised, you can switched it off by closing a hand to this sensor and if LCD is turned off, it can be turned on als by this sensor
- Status LED - presents (together with LCD) a current state of a device. If it blinks - the device is in initialization state or is damaged. If it lights continuously - the device works properly.
Below you can find the LCD display presenting values of temperature and gas concentration.
3) Device uses a BLE interface of a Curie processor to communicate with other devices. It publishes values of gas concentration and external temperature (i've used for these purposes BLEFloatCharacteristic classes from CurieBLE library, object of these classes were defined as BLERead or BLENotify) and allows an external device to control a button (BLECharCharacteristic defined as BLEWrite). Thanks this inteface the device can be controlled by a smartphone/tablet equipped with BLE interface or by a smart home/security controller. These external devices can get results of measurements made by the device and can turn off alarm - just like it can be done with a built-in proximity sensor. I haven't written an application for smartphone to verify how BLE interface works - i didn't have enough time to do this. Instead of this i decided to use nRF Connect tool created by Nordic Semiconductor ASA. Below you can see results of my tests - as you can see there are three characteristics. First two presents external temperature and gas concentration (look at their Value fields). Third can be used to control the device.
Software controlling the device has been written using Arduino language & IDE. It took me a while to get familiar with this environement - language is a funny mixture of C/C++ and some genuine ideas and IDE is not too convenient ;-).
To handle multitasking I decided to use approach proposed by Adafruit (https://learn.adafruit.com/multi-tasking-the-arduino-part-1/overview). In this approach each external component has its own class which describes behaviour of this component. Each class has Update method - this method is called from main loop() method of the program. The state of the device is stored in an object of DeviceState class - this class is passed to Update methods as their parameter. This approach plays its role in situations, when there is no need to make precise time measurements. In our case, where it doesn't matter, whether the heater is turned on for exactly 1 minute or for 1 minut and 5 seconds, it can be freely used. Details can be found in attached code - but please don't treat it as a pattern, it is rather developer's nigthmare. I checked there different solutions and i haven't managed to clear it. It has in general one advantage - it works (usually ;-)
Algorithms used to handle components made by SeedStudio were taken from their web page. Algorithm used to measure gas concentration was taken from the http://www.jayconsystems.com/tutorials/gas-sensor-tutorial/ and it was extended by me with a part used to compensate external temperature - i tried to add in code a few comments to describe the idea of it.
HousingThe sensor in its current form - a set of Grove modules connected to Arduino - is not too handy in use. It will be good to put it into some housing - and in this form hang it up on a wall in a room with a gas boiler (remember - if you want to detect methane leakages - you need to locate the device under a ceiling; methane is lighter than air and thus it concentrates under ceiling).
Below you can find a proposal of such enclosure. Except of the described device it should also contain a power supply - powering the device from a battery is inefficient due to quite big consumption of energy by the MQ4 sensor.
At the begining i have to warn you - methane is very dangerous. Even small concentration of it may lead to explosion. So if you want to use a device built on your own to detect gas leakages - you need to test it very extensively and, what is even more important, such device must be carefully and precisely calibrated. The device described here was not calibrated at all - so it cannot be used as a reliable detector of leakages. The software described here hasn't been tested in details - so it also shouldn't be used directly in real devices.
But let's back to the project. It has proved, that Arduino 101 can be used as a "brain" of an intelligent gas sensor. It provides enough computational power to handle all tasks needed in such device. Its main advantage is built-in BLE interface and very convenient libraries which can be used o control it. In general i've noticed only one problem, connected rather with Grove Started Kit. If you want to use simultanously LCD and analog Grove components - you need to think how to translate signals to match voltage range handled by Arduino's ADC. But except this flaw - the combination of Arduino and Grove starter kit allows you to create prototypes quickly and in quite convenient way (however IDE isn't to comfortable ;-)
What next (aka Lessons Learned)Based on experiences from the project i can outline here potential next steps, which should be taken to improve the device:
- one-coil bistable relay should be replaced with a two-coil bistable relay. Maybe the latter is a little more expensive - but it is easier to control it.
- sound sensor should be powered from 3.3 v source - otherwise it produces signal with too high voltage - so the device is too sensitive
- code should be split into smaller parts - ideally each class should be saved in one file. Due to time shortage i didn't manage to do this
- and the most important thing - the algorithm used currently to detect alarming sounds should be replaced with something more complicated and reliable. I thought about a use of FFT to detect patterns that may indicate a failure of a boiler. Arduino 101 has enough power to make such calculations and enough memory to store several hundreds of patterns. We can imagine even a creation of a library with such patterns in a cloud. This library could be created based on user's experience - the device could gather all sounds and if something happens to a boiler, it could find a pattern connected with this failure and upload it to a cloud. In this cloud all such patterns could be analysed - even with a use of big data. Based on results of such analyses a set of reliable patterns could be created and shared with other users. The device could download them in this case from a cloud through BT<->ETH converter/hub.
- task not connected directly with a device - creation of dedicated software for smartphones/tablets. Such software could warn a person within BLE range about possible threats connected with a boiler failure - based on notifications sent by the device. Of course this software could be also used to turn off the alarm raised by the device.
- it might be good to consider replacement of the analog temperature sensor used to check the state of MQ4 heater with another DS18B20. Thanks this we could forget about incompatible voltages and make code more concise by removing part devoted to handling this analog sensor.
Comments