November 21, 2014 at 08:37White Cube on guard of clean air, part 1
A device for monitoring the parameters of a home environment with data transfer over Wi-Fi.
The article describes a device for measuring, indicating on the built-in display and transmitting to the network via Wi-Fi the following environmental parameters:
• CO2 level (carbon dioxide)
• CO level (carbon monoxide)
• ethanol vapor content (C2H5ON)
• combustible gas level ( LPG)
• ammonia level (NH3)
• hydrogen content (H2)
• atmospheric pressure values
• humidity and air temperature
• illumination
level • magnetic field level along three axes
• gravity level along three axes
• acceleration level along three axes
• temperature of any number of digital temperature sensors type DS18B20.
The highlight of the BC is the way to change screens by double tapping the case. Video how it happens:
A detailed description of this control method is given below.
The White Cube externally is a white case with a 10 cm rib, bought in Chip and Deep.
When considering the implementation of the device, I decided that the device should transmit all the collected data to the network. The data is not interesting at the same time, but in its long-term trends. It is very interesting to have large data archives for further processing. Thus, it is reasonable to transmit data from sensors to a “big machine”, process it there, store, retrieve, read statistics, draw graphs, build various correlations, etc. All this makes sense only on a large machine with a powerful processor, large memory, large display and low complexity of data processing, using all the wealth of proven software for display and diverse data processing.
I used Arduino Nano as the central processor of the BC. For me, the convenience of developing and programming outweighed the flaws. Considering also the noticeable power consumption of gas sensors, a CO2 sensor and a Wi-Fi module, it makes no sense to fight for low CPU consumption. Plus, one must take into account the fact that the BK is a single device, not intended for mass production.
For data transfer via Wi-Fi I used the wonderful device “HI-LINK HLK-RM04 Serial Port-Ethernet-Wi-Fi Adapter Module” (http://dx.com/p/hi-link-hlk-rm04-serial- port-ethernet-wi-fi-adapter-module-blue-black-214540), which is essentially a mini-router with great features.
And on the flip side:
I used the transparent data transfer mode Serial - Wi-Fi. I will not dwell on this device in detail - the network has enough descriptions, application experience and forums on this mini-router.
Of the curious, mention should be made of the github.com/chunlinhan/WiFiRM04 library
During debugging, we found out some features of data transmission over Wi-Fi compared to cable. So, if by cable a data line from 130 bytes from Arduino, for example, arrives at 130 bytes, then when transmitting the same line via Wi-Fi, the data turns out to be divided into 4-5 parts and these parts must be collected at the receiving end and only then pass the string for processing. I did not understand this in depth, I took into account when writing a program for receiving data from the White Cube. Perhaps these features of radio transmission are associated with the already heavy workload of the 2.4 GHz band and the competitive access of devices operating on the same frequency channel.
It should be noted that with DX modules come without an internal antenna:
I bought external antennas at DESSY.RU and demanded reimbursement from the seller.
The following sensors were used to assess the presence of harmful substances in the air:
CO2 sensor type K-30 :
Purchased separately from the manufacturer on the site. This is the most expensive of the sensors used, but it costs its money, because it is very durable and stable. The principle of operation is to measure the absorption of infrared radiation in a calibrated path. Data from this sensor can be taken both in analog form and with two digital interfaces - serial and I2C. Also, this sensor contains an auto-calibration mechanism that takes into account data for the past two weeks (the time interval is programmed) and considers the minimum level during this time as 400 ppm. In this way, the long-term offset of the sensor calibration is taken into account. The manufacturer’s website has both detailed documentation and examples of a data reading program, which I used. I bought two sensors, one through the serial-to-USB converter on the FT232 is connected to the home control machine, the second is used in the BC. The sensor is powered by 5 volts, but the levels on the serial port should be 3.3 volts. This is for the case of connecting via the serial port. If I2C port is used, then a level converter is not required.
The rest of the sensors are analog:
Ethyl alcohol vapors (C2H5OH) - MQ5
Carbon monoxide СО – MQ7
Hydrogen H2 - MQ8
Liquefied gas (LPG) - MQ6
Ammonia (NH3) - MQ135
Smoke - MQ2 The
sensors look like this:
Despite some external difference, they are arranged the sensors are the same, they contain a sensitive element that changes the conductivity under the influence of a particular gas and a comparator on the LM393 half. The sensors have 4 external outputs - two for powering the module (+5 and ground) and two outputs - one analog and one digital from the output of the comparator.
Sensitive elements need heating and therefore the current consumption is quite large - about 200 mA.
The switching circuit recommended by the manual - a resistor is connected in series with the sensor and a useful signal is removed from it. According to the manual, a load resistor can be set from 5 to 47 KΩ, a typical value is 10 KΩ.
It is interesting to note that the sensors themselves have low selectivity and respond equally well to the entire spectrum of substances and gases. This, however, was found out already in the process of testing and debugging BC.
The sensor itself, a dual comparator of the LM393 type, a pair of LEDs and auxiliary wiring are located on the printed circuit board. One LED is a power indicator, the second is a comparator response indicator. Fortunately, the output connector also has an analog signal output directly from the sensor, so that I could use these nodes without changes, except for the CO sensor.
The CO sensor (MQ7) had to be upgraded. This sensor requires a special power mode in accordance with the manual. For 90 seconds, a full voltage of 5 volts should be applied to the heating element, and then 60 seconds - 1.4 volts. On the board, the heater's power is organized differently - +5 volts are applied to one heater terminal, and the second terminal is connected to the ground through a 5 ohm resistor.
The red arrows show the elements in the photo:
1 - 5 ohm resistor in the heater circuit
2 - heater output
3 - comparator LM393
I dismantled the resistor (1) and connected the heater output (2) to the leg of the connector, onto which the output of the comparator was connected, using a MGTF wire. I also removed the comparator (3) from the board. The second wire restores the erroneously destroyed circuit of the indicator LED. The indicator LED is connected parallel to the heating element. This allowed during debugging the program to visually observe the current mode - heating or measurement by changing the brightness of the LED.
photo of the converted CO MQ7 sensor
Since the sensor heater requires significant current (about 200 mA), it is impossible to power it directly from the Arduino output (maximum 40 mA). I used an intermediate field effect transistor in key mode. The transistor is like this: IRLU120NPBF, Ncan 100V 10A logic TO251, purchased in Chip and Deep. This is the transistor T1 on the circuit diagram of the BC.
Electrical schematic diagram of the White Cube:
Having studied the materials on the Internet, I decided that the pulse power supply of the sensor in the PWM mode of the required duty cycle would be optimal. Other methods - for example, the series connection of diodes or resistors - require manual selection of elements. The disadvantage of this method is that the pulsed power of the heater can lead to interference when measuring the analog signal from the sensor.
Having carefully read the datasheet, I realized that it is necessary to measure the level of CO at the very end of the measurement cycle immediately before the start of the heating cycle. Therefore, I decided that I would not take any special measures to suppress pulse interference from PWM, but simply turn off the PWM signal before measuring, let the system calm down for a few milliseconds, measure the CO level and then turn on the power again. The thermal inertia of the sensor is tens of seconds, so that during the switching the temperature of the sensor does not change and the output signal is also stable.
The type of the output signal from the CO measurement channel is shown in the graph:
In this graph, the green meander is the voltage switching on the heating element, the red line is the signal from the CO sensor, and the yellow is the signal recorded immediately before changing the heating mode.
The signal from the CO sensor is measured continuously, both the current signal measured with a period of about 3 seconds (the period of the main sketch cycle) and the measurement "by manual" with a period of 2.5 minutes (90 + 60 seconds) are fed into the processing system. The graphs show that the signal inside the measurement period also carries information about the current level of CO and its rate of change. It is possible to isolate and use it by comparing (subtracting) the stored array of values on the previous measurement step with the current values. The difference with the previous cycle with possibly some additional processing (averaging over 10-20 seconds) will give more or less adequate information about the rate of increase of the harmful agent in the air. This will increase the reaction rate to a change in CO from two and a half minutes to several seconds. I found the idea of such processinghere .
Other analog sensors do not require special power. All analog gas sensors require warming up for 48 hours after power up.
Air pressure measurement.
To measure this parameter, I used the module "L3G4200D ADXL345 HMC5883L BMP085 MWC Sensor Module for Arduino".
The module contains 4 sensors, originally designed for aircraft such as a multicopter. The module was purchased on DX.com for reasons of "wholesale cheaper." It turned out, however, that the ADXL345 sensor also found its application. This is somewhat lower.
BMP085 is a digital absolute pressure sensor with a temperature sensor.
ADXL345 - Three-axis acceleration sensor
HMC5883L - Three-axis magnetic field sensor
L3G4200D is a three-axis digital gyroscope.
All sensors are connected to the I2C bus, for reading readings I used ready-made libraries.
The ADXL345 sensor is designed to measure acceleration along three axes with the output on the I2C bus. This sensor can measure in particular the acceleration of gravity.
And also this sensor can respond to the effects of “tap” and “double tap” - i.e. single and double tapping. And this makes it possible to exert control influences on the BC program (sketch). I used this mechanism to switch the screens on the display. There is a lot of data and they do not fit on one screen. Therefore, I grouped them into three screens and switch them to double tap on the BC body. I really did not want to make any buttons, I wanted to leave the surface of the BC clean as possible.
ADXL345 can set a hardware interrupt upon detection of double tap, I connected it to the D3 pin of Arduino.
Unfortunately, due to MK limitations, I could not organize a full-fledged processing of hardware interrupts. Inside the interrupt, I can’t poll the ADXL345 registers, because if the interrupt happened inside the program of communication with another device on the same I2C bus, I will ruin this exchange. Therefore, I made a compromise - when processing an interrupt from ADXL345, I only set the flag that double tap is registered, and actually I poll ADXL345 to reset the interrupt flag in the display routine. The solution is not perfect and sometimes gives artifacts on the screen, but it is as fast as possible. If you simply interrogate the presence of an event in the ADXL345 main cycle, then the reaction time can be about 3 seconds if the situation is unsuccessful. This is annoyingly long ... My option gives a maximum delay of less than a second and I found it acceptable.
Double-tap screen switching video:
Data from the magnetic field and acceleration sensors are read, displayed on the display (screen 2) and transmitted over the communication channel without changes. Their processing is a matter of the future.
If you turn the Cube in your hands, the readings of the acceleration, gravity and magnetic field sensors will change. There is an active reaction when presenting a magnet.
What practical benefit to derive from these testimonies - I have not yet decided. Perhaps the analysis of changes in the magnetic field will provide some useful information for weather-sensitive people? However, as an electronic compass device can be used now.
Light sensor.
I still have a couple of free conclusions on Arduin, one of them with a hardware interrupt. I decided to use this output to measure illumination. On the net, I found mentions of a methodmeasuring illumination by measuring the discharge time of the reverse-connected pn junction of the LED. The essence of the method is as follows - a back-on LED is connected to the processor output. The output is switched to OUTPUT mode and a high level (+5 V) is applied to it. The stray capacitance of the LED plus the mounting capacitance is charged to a high level. Next, the output switches to INPUT mode and an interrupt is attached to it on a level change or on a negative edge. The input impedance of the ATMEL328P processor in this mode is very large - tens of megaohms, therefore, the discharge of stray capacitance by the photocurrent takes a fairly long time - from units of milliseconds to units of seconds. By triggering an interrupt, it is enough to fix the current time. The difference between the start time of the cycle and the end time of the cycle will give time in milliseconds, inversely proportional to illumination. In my case, for darkness at night, the time is approximately 3500 milliseconds, and during the day on the Sun - units of milliseconds. I put an additional capacitor parallel to the LED with a capacity of a dozen picofarads, otherwise during the day the discharge was very fast (less than 1 ms). I got 3-10 ms on a bright sunny day. The internal capacitance of the LED is about 8 picofarads. Additional capacity led to a noticeable increase in discharge time in the dark - more than 4 seconds. Then I came across a certain difficulty. The main program cycle lasts approximately 3.6 seconds. At the beginning of the cycle, I start the measurement of illumination, perform all other operations, and by the end of the cycle, I expect that in the global variable lies the value of the illumination put there in the interrupt. At first, I had the idea of organizing an autonomous cycle for measuring illumination, so that in the interrupt itself the cycle would start again. But then, at high levels of illumination (i.e., a short cycle time of a few milliseconds), the processor will only be busy measuring illumination. If you start once at the beginning of the main cycle, then at low illumination levels there will be no response and the value will be 0 ... I got out of this way - I start the measurement at the beginning of the cycle, but I check whether it was triggered or not. If it was, I start it in a regular way. If not, I do nothing. The disadvantage of this solution is that at low light levels, the measurement speed halves. However - I’m still interested in data with a characteristic change time of tens of seconds, so this minus is unimportant.
LED selection. Since the White Cube already had holes with a diameter of 8 mm by the time the light sensor was connected, I decided that it would be nice to use a diode of the same diameter. In Chip and Deep, I bought a pair of LEDs of each color there (red, green, yellow, white and blue) with a diameter of 8 mm and experimented with the goal of determining the optimal LED. To study the LEDs, I built a simple stand. The stand consists of Arduino Nano, a Wi-Fi - serial module, and the LED under test using screw terminals. The system was powered by a lithium battery (power pack).
A bit of theory - the illumination in a room changes about 1000 times or more. At night, the illumination is units and fractions of lumens, on a sunny day near the inside of the room the illumination will be about 1000 lumens, and at the window - about 10,000 lumens.
For each LED, I searched for maximum illumination - I pointed the system in small steps at the brightest spot on the street and at the darkest in the room and then carried the system into a dark room.
The measurement processing results are shown in the table.
(digits in the table - discharge time in milliseconds)
It turned out that the green LED has a maximum range width of more than 1000 times (from units of ms to 4 seconds), followed by white (635 times), then red (442) and yellow (72) and closes the list with blue range 11. White The LED is also distinguished by a lower sensitivity to light.
A detailed interpretation of the results is beyond the scope of this article, but it is clear that it is optimal to use a green LED in the BC.
Convert light sensor readings to suites.
Standards for illumination are easily found on the Internet (Sanitary rules and norms of SanPiN 2.2.1 / 2.1.1.1278-03). From the study of this document it follows that the illumination is normalized in the range of 20 - 750 lux (from the pantry to the workplace for precise work). In other words, calibrating the BK light sensor has practical meaning in the range from lux to thousands of lux.
To solve this problem, I applied a ready-made calibrated sensor BH1750. The sensor was connected to a separate Arduino connected to a Wi-Fi module. Sketch read the sensor readings and broadcast them to the network, from where they were taken by the program, averaged over an interval of 1 minute and recorded in a log file. After several days, I processed these primary data by comparing the data from the BC and the calibrated sensor. As a result of processing the data, I got a conversion table, according to which you can recalculate the discharge time of the diode into suites. The formula can be derived from the table, but I left it on When I'm sixty four.
The described method for measuring illumination turned out to be very sensitive to changes in supply voltage and other destabilizing factors. The reason for this is that the output signal relies on the analog operation of comparing a very slowly varying input voltage and a reference voltage approximately equal to half the supply voltage. It turns out that the switching time of the logic element depends very much on random fluctuations in the supply voltage, etc. Here, in this illustration, the dependence of the measured time on the supply voltage is clearly visible:
The supply voltage changes due to heating and measuring cycles of the CO MQ7 sensor. In the measurement cycle, 1.4V is supplied to it, and in the heating cycle - 5V, the current consumption changes, the supply voltage changes and the threshold for the input D3 floats away. According to the measurements, it turned out that due to the power instability factor, the time change is from 10% at high light levels to more than 30% at low.
This change can be adjusted programmatically.
Given that the measurement accuracy turned out to be very low (errors of the order of 30%), I decided to limit myself to the simplest way of converting the measured discharge time into suites in the form of a table. The microprocessor Arduino Nano has very modest resources for serious processing of such data, and I decided to transfer more serious processing to a program in Visual Basic. In such a program, it is possible to filter data, averaging over a large time interval. At the moment, the daily light schedule looks like this:
Black arrow - the moment the TV turns off. Red is the sunrise (today November 20, 2014 is 8:13 according to Gismeteo).
The sensor in the form of a diode also maintains responsiveness to low levels of illumination in the region of units and tenths of a lux. The BH1750 has a minimum sensitivity of 1 lux. For example, the BH1750 does not respond to a TV or a table lamp with a power of units of watts (LED), and the sensor in the BC - responds confidently. However, there are other light sensors with a significantly wide range, for example, MAX44009 with the declared range of 0.045 - 188000 lux, I2C interface, but also at the price of about 200 r (in Chip and Dip - 250 r). However, maybe in the next version of the BC I will replace the light sensor. The use of ready-made modules is certainly more correct in terms of the quality of the final product, but doing it yourself is an order of magnitude more interesting.
Using the LED and the method of measuring the duration of the discharge in such a simple form does not provide sufficient accuracy, but can be used, for example, to adjust the brightness of the display or some other tasks that need to know the illumination roughly, with an accuracy of 30-40%. Let’s say perhaps a confident distinction between day and night.
Display
In BC, I used a display from Nokia 3510i. Its only advantage is the very low price in mobile parts stores. I bought this display for 46 p. Minus - there are no backlight LEDs, you have to do your own, small size, small color - 4096 colors and confused exchange programming in 4096 color mode. At the moment, it seems optimal to use ready-made modules like this. This module is slightly more expensive (about 300 r), but the full color, built-in backlight, simple programming outweigh the slight increase in price. I used this module in a radiometer and am quite pleased with its quality. About the radiometer with Wi-Fi and Glonass \ GPS, see the article here .
I made the backlight in the Nokia 3510i's display in the form of a strip of double-sided foil fiberglass with three evenly spaced LEDs. The height of the bar is about 3 mm, the width corresponds to the width of the end of the display. Slots in the foil are made on the bar and LEDs are soldered in place. A 20 ohm resistor is connected in series with each diode, all sections are connected in parallel and another resistor is connected in series to control the brightness of the backlight. The bar is soldered by two copper wires at the end of the display. Pendant illumination on flexible copper wires allows you to choose the position of the strip to achieve optimal display brightness.
Used LEDs "BL-LS3014A0S1UW2C, SMD 3014 LED, Warm White, 120˚ 2300mKd", bought in Chip and Dip for 26 p. Given the LEDs (3 used + 1 burned), the price of the display is already about 150 rubles, which is only half the finished price.
The display module is mounted in the cube cover and is connected to the main module by a flat cable. An additional wire is for connecting the speaker, which is on the display. I used it at the last moment, when there was both a free leg on Arduin and a place in memory for the code that generated sound signals.
The strange shape of the display module is due to design errors. I decided that the holes on the sides of the Cube were enough to remove heat, but it turned out that it was not enough and it was necessary to make holes on top too. Since the display module covered the entire top cover, everything had to be removed to give maximum passage for warm air. Metal scissors and dremel perfectly coped with the task of removing unnecessary :) An additional MGTF wire wrapped around a flat cable was added at the last moment to signal the tweeter.
Built-in BC display, screen 1:
From left to right, in rows:
Humidity, air temperature
CO2 level, ppm, air pressure in millimeters of mercury, temperature inside the BC
CO level current, measured, status (N - heating, I - measurement)
Smoke level, combustible gas
level Ammonia level, ethyl alcohol vapor
Screen 2:
From left to right, in rows:
Magnetic field sensor readings in three axes - X, Y, Z
The readings of the gravity sensor in three axes - X, Y, Z The
readings of the acceleration sensor of the field in three axes - X, Y, Z
Hydrogen level, illumination.
The last value in the first line is actually a deviation from the direction to the north magnetic pole
Here is a curious photo:
As you can see, the compass needle and the face of the cube are almost parallel to each other and the direction to magnetic north.
Z axis is zero - because the sensor is mounted vertically and the Z axis is horizontal, the Y axis is vertical.
Screen 3, temperature sensors:
A cable of five Dallas 18B20 sensors is connected to Cuba, the sketch at startup determines the number of connected sensors and only interrogates them during further work.
Here's a video of the launch of the sketch, which smoothly changes the brightness of each of the primary colors of the display at startup:
To be continued .
The article describes a device for measuring, indicating on the built-in display and transmitting to the network via Wi-Fi the following environmental parameters:
• CO2 level (carbon dioxide)
• CO level (carbon monoxide)
• ethanol vapor content (C2H5ON)
• combustible gas level ( LPG)
• ammonia level (NH3)
• hydrogen content (H2)
• atmospheric pressure values
• humidity and air temperature
• illumination
level • magnetic field level along three axes
• gravity level along three axes
• acceleration level along three axes
• temperature of any number of digital temperature sensors type DS18B20.
The highlight of the BC is the way to change screens by double tapping the case. Video how it happens:
A detailed description of this control method is given below.
The White Cube externally is a white case with a 10 cm rib, bought in Chip and Deep.
When considering the implementation of the device, I decided that the device should transmit all the collected data to the network. The data is not interesting at the same time, but in its long-term trends. It is very interesting to have large data archives for further processing. Thus, it is reasonable to transmit data from sensors to a “big machine”, process it there, store, retrieve, read statistics, draw graphs, build various correlations, etc. All this makes sense only on a large machine with a powerful processor, large memory, large display and low complexity of data processing, using all the wealth of proven software for display and diverse data processing.
I used Arduino Nano as the central processor of the BC. For me, the convenience of developing and programming outweighed the flaws. Considering also the noticeable power consumption of gas sensors, a CO2 sensor and a Wi-Fi module, it makes no sense to fight for low CPU consumption. Plus, one must take into account the fact that the BK is a single device, not intended for mass production.
For data transfer via Wi-Fi I used the wonderful device “HI-LINK HLK-RM04 Serial Port-Ethernet-Wi-Fi Adapter Module” (http://dx.com/p/hi-link-hlk-rm04-serial- port-ethernet-wi-fi-adapter-module-blue-black-214540), which is essentially a mini-router with great features.
And on the flip side:
I used the transparent data transfer mode Serial - Wi-Fi. I will not dwell on this device in detail - the network has enough descriptions, application experience and forums on this mini-router.
Of the curious, mention should be made of the github.com/chunlinhan/WiFiRM04 library
During debugging, we found out some features of data transmission over Wi-Fi compared to cable. So, if by cable a data line from 130 bytes from Arduino, for example, arrives at 130 bytes, then when transmitting the same line via Wi-Fi, the data turns out to be divided into 4-5 parts and these parts must be collected at the receiving end and only then pass the string for processing. I did not understand this in depth, I took into account when writing a program for receiving data from the White Cube. Perhaps these features of radio transmission are associated with the already heavy workload of the 2.4 GHz band and the competitive access of devices operating on the same frequency channel.
It should be noted that with DX modules come without an internal antenna:
I bought external antennas at DESSY.RU and demanded reimbursement from the seller.
The following sensors were used to assess the presence of harmful substances in the air:
CO2 sensor type K-30 :
Purchased separately from the manufacturer on the site. This is the most expensive of the sensors used, but it costs its money, because it is very durable and stable. The principle of operation is to measure the absorption of infrared radiation in a calibrated path. Data from this sensor can be taken both in analog form and with two digital interfaces - serial and I2C. Also, this sensor contains an auto-calibration mechanism that takes into account data for the past two weeks (the time interval is programmed) and considers the minimum level during this time as 400 ppm. In this way, the long-term offset of the sensor calibration is taken into account. The manufacturer’s website has both detailed documentation and examples of a data reading program, which I used. I bought two sensors, one through the serial-to-USB converter on the FT232 is connected to the home control machine, the second is used in the BC. The sensor is powered by 5 volts, but the levels on the serial port should be 3.3 volts. This is for the case of connecting via the serial port. If I2C port is used, then a level converter is not required.
The rest of the sensors are analog:
Ethyl alcohol vapors (C2H5OH) - MQ5
Carbon monoxide СО – MQ7
Hydrogen H2 - MQ8
Liquefied gas (LPG) - MQ6
Ammonia (NH3) - MQ135
Smoke - MQ2 The
sensors look like this:
Despite some external difference, they are arranged the sensors are the same, they contain a sensitive element that changes the conductivity under the influence of a particular gas and a comparator on the LM393 half. The sensors have 4 external outputs - two for powering the module (+5 and ground) and two outputs - one analog and one digital from the output of the comparator.
Sensitive elements need heating and therefore the current consumption is quite large - about 200 mA.
The switching circuit recommended by the manual - a resistor is connected in series with the sensor and a useful signal is removed from it. According to the manual, a load resistor can be set from 5 to 47 KΩ, a typical value is 10 KΩ.
It is interesting to note that the sensors themselves have low selectivity and respond equally well to the entire spectrum of substances and gases. This, however, was found out already in the process of testing and debugging BC.
The sensor itself, a dual comparator of the LM393 type, a pair of LEDs and auxiliary wiring are located on the printed circuit board. One LED is a power indicator, the second is a comparator response indicator. Fortunately, the output connector also has an analog signal output directly from the sensor, so that I could use these nodes without changes, except for the CO sensor.
The CO sensor (MQ7) had to be upgraded. This sensor requires a special power mode in accordance with the manual. For 90 seconds, a full voltage of 5 volts should be applied to the heating element, and then 60 seconds - 1.4 volts. On the board, the heater's power is organized differently - +5 volts are applied to one heater terminal, and the second terminal is connected to the ground through a 5 ohm resistor.
The red arrows show the elements in the photo:
1 - 5 ohm resistor in the heater circuit
2 - heater output
3 - comparator LM393
I dismantled the resistor (1) and connected the heater output (2) to the leg of the connector, onto which the output of the comparator was connected, using a MGTF wire. I also removed the comparator (3) from the board. The second wire restores the erroneously destroyed circuit of the indicator LED. The indicator LED is connected parallel to the heating element. This allowed during debugging the program to visually observe the current mode - heating or measurement by changing the brightness of the LED.
photo of the converted CO MQ7 sensor
Since the sensor heater requires significant current (about 200 mA), it is impossible to power it directly from the Arduino output (maximum 40 mA). I used an intermediate field effect transistor in key mode. The transistor is like this: IRLU120NPBF, Ncan 100V 10A logic TO251, purchased in Chip and Deep. This is the transistor T1 on the circuit diagram of the BC.
Electrical schematic diagram of the White Cube:
Having studied the materials on the Internet, I decided that the pulse power supply of the sensor in the PWM mode of the required duty cycle would be optimal. Other methods - for example, the series connection of diodes or resistors - require manual selection of elements. The disadvantage of this method is that the pulsed power of the heater can lead to interference when measuring the analog signal from the sensor.
Having carefully read the datasheet, I realized that it is necessary to measure the level of CO at the very end of the measurement cycle immediately before the start of the heating cycle. Therefore, I decided that I would not take any special measures to suppress pulse interference from PWM, but simply turn off the PWM signal before measuring, let the system calm down for a few milliseconds, measure the CO level and then turn on the power again. The thermal inertia of the sensor is tens of seconds, so that during the switching the temperature of the sensor does not change and the output signal is also stable.
The type of the output signal from the CO measurement channel is shown in the graph:
In this graph, the green meander is the voltage switching on the heating element, the red line is the signal from the CO sensor, and the yellow is the signal recorded immediately before changing the heating mode.
The signal from the CO sensor is measured continuously, both the current signal measured with a period of about 3 seconds (the period of the main sketch cycle) and the measurement "by manual" with a period of 2.5 minutes (90 + 60 seconds) are fed into the processing system. The graphs show that the signal inside the measurement period also carries information about the current level of CO and its rate of change. It is possible to isolate and use it by comparing (subtracting) the stored array of values on the previous measurement step with the current values. The difference with the previous cycle with possibly some additional processing (averaging over 10-20 seconds) will give more or less adequate information about the rate of increase of the harmful agent in the air. This will increase the reaction rate to a change in CO from two and a half minutes to several seconds. I found the idea of such processinghere .
Other analog sensors do not require special power. All analog gas sensors require warming up for 48 hours after power up.
Air pressure measurement.
To measure this parameter, I used the module "L3G4200D ADXL345 HMC5883L BMP085 MWC Sensor Module for Arduino".
The module contains 4 sensors, originally designed for aircraft such as a multicopter. The module was purchased on DX.com for reasons of "wholesale cheaper." It turned out, however, that the ADXL345 sensor also found its application. This is somewhat lower.
BMP085 is a digital absolute pressure sensor with a temperature sensor.
ADXL345 - Three-axis acceleration sensor
HMC5883L - Three-axis magnetic field sensor
L3G4200D is a three-axis digital gyroscope.
All sensors are connected to the I2C bus, for reading readings I used ready-made libraries.
The ADXL345 sensor is designed to measure acceleration along three axes with the output on the I2C bus. This sensor can measure in particular the acceleration of gravity.
And also this sensor can respond to the effects of “tap” and “double tap” - i.e. single and double tapping. And this makes it possible to exert control influences on the BC program (sketch). I used this mechanism to switch the screens on the display. There is a lot of data and they do not fit on one screen. Therefore, I grouped them into three screens and switch them to double tap on the BC body. I really did not want to make any buttons, I wanted to leave the surface of the BC clean as possible.
ADXL345 can set a hardware interrupt upon detection of double tap, I connected it to the D3 pin of Arduino.
Unfortunately, due to MK limitations, I could not organize a full-fledged processing of hardware interrupts. Inside the interrupt, I can’t poll the ADXL345 registers, because if the interrupt happened inside the program of communication with another device on the same I2C bus, I will ruin this exchange. Therefore, I made a compromise - when processing an interrupt from ADXL345, I only set the flag that double tap is registered, and actually I poll ADXL345 to reset the interrupt flag in the display routine. The solution is not perfect and sometimes gives artifacts on the screen, but it is as fast as possible. If you simply interrogate the presence of an event in the ADXL345 main cycle, then the reaction time can be about 3 seconds if the situation is unsuccessful. This is annoyingly long ... My option gives a maximum delay of less than a second and I found it acceptable.
Double-tap screen switching video:
Data from the magnetic field and acceleration sensors are read, displayed on the display (screen 2) and transmitted over the communication channel without changes. Their processing is a matter of the future.
If you turn the Cube in your hands, the readings of the acceleration, gravity and magnetic field sensors will change. There is an active reaction when presenting a magnet.
What practical benefit to derive from these testimonies - I have not yet decided. Perhaps the analysis of changes in the magnetic field will provide some useful information for weather-sensitive people? However, as an electronic compass device can be used now.
Light sensor.
I still have a couple of free conclusions on Arduin, one of them with a hardware interrupt. I decided to use this output to measure illumination. On the net, I found mentions of a methodmeasuring illumination by measuring the discharge time of the reverse-connected pn junction of the LED. The essence of the method is as follows - a back-on LED is connected to the processor output. The output is switched to OUTPUT mode and a high level (+5 V) is applied to it. The stray capacitance of the LED plus the mounting capacitance is charged to a high level. Next, the output switches to INPUT mode and an interrupt is attached to it on a level change or on a negative edge. The input impedance of the ATMEL328P processor in this mode is very large - tens of megaohms, therefore, the discharge of stray capacitance by the photocurrent takes a fairly long time - from units of milliseconds to units of seconds. By triggering an interrupt, it is enough to fix the current time. The difference between the start time of the cycle and the end time of the cycle will give time in milliseconds, inversely proportional to illumination. In my case, for darkness at night, the time is approximately 3500 milliseconds, and during the day on the Sun - units of milliseconds. I put an additional capacitor parallel to the LED with a capacity of a dozen picofarads, otherwise during the day the discharge was very fast (less than 1 ms). I got 3-10 ms on a bright sunny day. The internal capacitance of the LED is about 8 picofarads. Additional capacity led to a noticeable increase in discharge time in the dark - more than 4 seconds. Then I came across a certain difficulty. The main program cycle lasts approximately 3.6 seconds. At the beginning of the cycle, I start the measurement of illumination, perform all other operations, and by the end of the cycle, I expect that in the global variable lies the value of the illumination put there in the interrupt. At first, I had the idea of organizing an autonomous cycle for measuring illumination, so that in the interrupt itself the cycle would start again. But then, at high levels of illumination (i.e., a short cycle time of a few milliseconds), the processor will only be busy measuring illumination. If you start once at the beginning of the main cycle, then at low illumination levels there will be no response and the value will be 0 ... I got out of this way - I start the measurement at the beginning of the cycle, but I check whether it was triggered or not. If it was, I start it in a regular way. If not, I do nothing. The disadvantage of this solution is that at low light levels, the measurement speed halves. However - I’m still interested in data with a characteristic change time of tens of seconds, so this minus is unimportant.
LED selection. Since the White Cube already had holes with a diameter of 8 mm by the time the light sensor was connected, I decided that it would be nice to use a diode of the same diameter. In Chip and Deep, I bought a pair of LEDs of each color there (red, green, yellow, white and blue) with a diameter of 8 mm and experimented with the goal of determining the optimal LED. To study the LEDs, I built a simple stand. The stand consists of Arduino Nano, a Wi-Fi - serial module, and the LED under test using screw terminals. The system was powered by a lithium battery (power pack).
A bit of theory - the illumination in a room changes about 1000 times or more. At night, the illumination is units and fractions of lumens, on a sunny day near the inside of the room the illumination will be about 1000 lumens, and at the window - about 10,000 lumens.
For each LED, I searched for maximum illumination - I pointed the system in small steps at the brightest spot on the street and at the darkest in the room and then carried the system into a dark room.
The measurement processing results are shown in the table.
(digits in the table - discharge time in milliseconds)
| LED | window | room | In the dark | range, times |
|---|---|---|---|---|
| green | 4 | 440 | 4524 | 1131 |
| white | 16 | 1028 | 10161 | 635 |
| red | 2 | 49 | 883 | 442 |
| yellow | 4 | 25 | 287 | 72 |
| blue | 5 | 53 | 53 | eleven |
It turned out that the green LED has a maximum range width of more than 1000 times (from units of ms to 4 seconds), followed by white (635 times), then red (442) and yellow (72) and closes the list with blue range 11. White The LED is also distinguished by a lower sensitivity to light.
A detailed interpretation of the results is beyond the scope of this article, but it is clear that it is optimal to use a green LED in the BC.
Convert light sensor readings to suites.
Standards for illumination are easily found on the Internet (Sanitary rules and norms of SanPiN 2.2.1 / 2.1.1.1278-03). From the study of this document it follows that the illumination is normalized in the range of 20 - 750 lux (from the pantry to the workplace for precise work). In other words, calibrating the BK light sensor has practical meaning in the range from lux to thousands of lux.
To solve this problem, I applied a ready-made calibrated sensor BH1750. The sensor was connected to a separate Arduino connected to a Wi-Fi module. Sketch read the sensor readings and broadcast them to the network, from where they were taken by the program, averaged over an interval of 1 minute and recorded in a log file. After several days, I processed these primary data by comparing the data from the BC and the calibrated sensor. As a result of processing the data, I got a conversion table, according to which you can recalculate the discharge time of the diode into suites. The formula can be derived from the table, but I left it on When I'm sixty four.
The described method for measuring illumination turned out to be very sensitive to changes in supply voltage and other destabilizing factors. The reason for this is that the output signal relies on the analog operation of comparing a very slowly varying input voltage and a reference voltage approximately equal to half the supply voltage. It turns out that the switching time of the logic element depends very much on random fluctuations in the supply voltage, etc. Here, in this illustration, the dependence of the measured time on the supply voltage is clearly visible:
The supply voltage changes due to heating and measuring cycles of the CO MQ7 sensor. In the measurement cycle, 1.4V is supplied to it, and in the heating cycle - 5V, the current consumption changes, the supply voltage changes and the threshold for the input D3 floats away. According to the measurements, it turned out that due to the power instability factor, the time change is from 10% at high light levels to more than 30% at low.
This change can be adjusted programmatically.
Given that the measurement accuracy turned out to be very low (errors of the order of 30%), I decided to limit myself to the simplest way of converting the measured discharge time into suites in the form of a table. The microprocessor Arduino Nano has very modest resources for serious processing of such data, and I decided to transfer more serious processing to a program in Visual Basic. In such a program, it is possible to filter data, averaging over a large time interval. At the moment, the daily light schedule looks like this:
Black arrow - the moment the TV turns off. Red is the sunrise (today November 20, 2014 is 8:13 according to Gismeteo).
The sensor in the form of a diode also maintains responsiveness to low levels of illumination in the region of units and tenths of a lux. The BH1750 has a minimum sensitivity of 1 lux. For example, the BH1750 does not respond to a TV or a table lamp with a power of units of watts (LED), and the sensor in the BC - responds confidently. However, there are other light sensors with a significantly wide range, for example, MAX44009 with the declared range of 0.045 - 188000 lux, I2C interface, but also at the price of about 200 r (in Chip and Dip - 250 r). However, maybe in the next version of the BC I will replace the light sensor. The use of ready-made modules is certainly more correct in terms of the quality of the final product, but doing it yourself is an order of magnitude more interesting.
Using the LED and the method of measuring the duration of the discharge in such a simple form does not provide sufficient accuracy, but can be used, for example, to adjust the brightness of the display or some other tasks that need to know the illumination roughly, with an accuracy of 30-40%. Let’s say perhaps a confident distinction between day and night.
Display
In BC, I used a display from Nokia 3510i. Its only advantage is the very low price in mobile parts stores. I bought this display for 46 p. Minus - there are no backlight LEDs, you have to do your own, small size, small color - 4096 colors and confused exchange programming in 4096 color mode. At the moment, it seems optimal to use ready-made modules like this. This module is slightly more expensive (about 300 r), but the full color, built-in backlight, simple programming outweigh the slight increase in price. I used this module in a radiometer and am quite pleased with its quality. About the radiometer with Wi-Fi and Glonass \ GPS, see the article here .
I made the backlight in the Nokia 3510i's display in the form of a strip of double-sided foil fiberglass with three evenly spaced LEDs. The height of the bar is about 3 mm, the width corresponds to the width of the end of the display. Slots in the foil are made on the bar and LEDs are soldered in place. A 20 ohm resistor is connected in series with each diode, all sections are connected in parallel and another resistor is connected in series to control the brightness of the backlight. The bar is soldered by two copper wires at the end of the display. Pendant illumination on flexible copper wires allows you to choose the position of the strip to achieve optimal display brightness.
Used LEDs "BL-LS3014A0S1UW2C, SMD 3014 LED, Warm White, 120˚ 2300mKd", bought in Chip and Dip for 26 p. Given the LEDs (3 used + 1 burned), the price of the display is already about 150 rubles, which is only half the finished price.
The display module is mounted in the cube cover and is connected to the main module by a flat cable. An additional wire is for connecting the speaker, which is on the display. I used it at the last moment, when there was both a free leg on Arduin and a place in memory for the code that generated sound signals.
The strange shape of the display module is due to design errors. I decided that the holes on the sides of the Cube were enough to remove heat, but it turned out that it was not enough and it was necessary to make holes on top too. Since the display module covered the entire top cover, everything had to be removed to give maximum passage for warm air. Metal scissors and dremel perfectly coped with the task of removing unnecessary :) An additional MGTF wire wrapped around a flat cable was added at the last moment to signal the tweeter.
Built-in BC display, screen 1:
From left to right, in rows:
Humidity, air temperature
CO2 level, ppm, air pressure in millimeters of mercury, temperature inside the BC
CO level current, measured, status (N - heating, I - measurement)
Smoke level, combustible gas
level Ammonia level, ethyl alcohol vapor
Screen 2:
From left to right, in rows:
Magnetic field sensor readings in three axes - X, Y, Z
The readings of the gravity sensor in three axes - X, Y, Z The
readings of the acceleration sensor of the field in three axes - X, Y, Z
Hydrogen level, illumination.
The last value in the first line is actually a deviation from the direction to the north magnetic pole
Here is a curious photo:
As you can see, the compass needle and the face of the cube are almost parallel to each other and the direction to magnetic north.
Z axis is zero - because the sensor is mounted vertically and the Z axis is horizontal, the Y axis is vertical.
Screen 3, temperature sensors:
A cable of five Dallas 18B20 sensors is connected to Cuba, the sketch at startup determines the number of connected sensors and only interrogates them during further work.
Here's a video of the launch of the sketch, which smoothly changes the brightness of each of the primary colors of the display at startup:
To be continued .