ITM 492 - Embedded Systems and Reconfigurable Logic Design
Technology has brought the benefits of incorporated multi-sensor equipment to the masses. Although, the application of sensors and their associated systems has increased and transformed the world forever, the fundamentals of the main sensor types and their functionality has not. These types of sensors range from: Temperature, IR, Ultrasonic, Touch, Proximity, Pressure, Level and, Air/Smoke/Gas sensors. Today, sensors enable us to set up various different systems that can better our lives by being more efficient, more reliable and with less time consuming. As for this project, we will focus upon an Arduino along with multiple Bluetooth transmitters called XBee 802.15.4 and will be utilized for a median range, low power operation.
Temperature is one of the most common of all physical measurements. We have temperature measurement and control units, called thermostats, in our home heating systems, refrigerators, air conditioners, and ovens. Temperature sensors are used on circuit boards, as part of thermal tests, in industrial controls, and in room controls such as in calibration labs and data centers. Though there are many types of temperature sensors, most are passive devices: Thermocouples, RTDs (resistance temperature detectors), and thermistors.
When deciding upon which course of direction we would take our project, I recalled a similar project that was organized and executed by a group of graduate students at Purdue, Calumet. These students wanted to make their university’s power consumption operate more efficiently. In reviewing the University's’ financial records, it was revealed that an exceptional amount of money was spent operating one the industrial buildings. In order to resolve this issue, a course of action was needed that would determine what caused such efficiency waste, without physically entering the system and disrupting production. In reviewing options, it was determined that a wireless system of sensors would obtain the best representation of data for air flow in the vents.
This system is similar to our setup, except their main concept is utilizing Bluetooth frequency, rather than our inclusion of radio frequency to collect the data. In reviewing their collected data, they realized that the air flow in the ventilation system shift entirely to one side rather than utilizing the whole space. This caused the system to overwork itself in order to compensate for the lack of airflow on the other side of the building. Once this problem was addressed, they constructed a 3D simulation of the best fit for a slit to help distribute the directional flow of the air. Once they had completed their project, the institution was able to save $250,000 per year in utilities and the group of graduate students was rewarded with $1,000 (Chicago Tribune, 2011).
In viewing this outcome, a small and inexpensive system played a large contribution in saving a large sum of money for the university. Not only can this concept be used to just demine irregularities in utilities usage, but it can be applied to many other areas. A setup like this can be brought to even a wider scale to not only save money, but even save the lives of many people. The possibilities for this type of system are endless.
The essential concept of our project creates a system that will gather the temperature and transmit the data to an intermediate router and then to our main base connected to our Arduino to record and display the results. The simulation environment we will create is applies the temperature radio system to a vacant house and determines what area allows an escape of warm air that also lets in cold air. This will help determine what area needs better insulation to help lower cost and energy use to warm up the house. The question is how exactly would we go about in collecting and transmitting the data of the temperature? How could we prevent the radio endpoints from collecting mixed results in an average temperature of the house? Not only that, but where would we precisely place each endpoint to make full use of all?
To overcome this dilemma we decided to do some research on how to address each of these issues. When transmitting the data, we had already set out to use the Xbee radios used in a previous lab from class. After fully observing them, they have many advantages. Unlike Wi-Fi that goes off on 802.11, the XBee consumes an exponentially lesser amount of power, allowing it to run for days on end. When it comes to connecting many devices together, Wi-Fi is limited to 32 devices and Bluetooth is limited to 7, while the XBee is relatively unlimited. While Wi-Fi and Bluetooth are able to transfer data at a larger size and rate, the XBee will be more than enough to transfer the data and temperature. Also, the distance that the XBee covers is generally greater than that of Wi-Fi and Bluetooth without cutting too much into the budget. Finally, we also had to examine how exactly we would create the environment to obtain the most accurate results without interfering with one another (Digi, 2016).
When trying to collect the exact pattern of temperature in each room we decided upon isolating each room to maintain its own climate. With each room we decided to pad the doors with Styrofoam and other padding to keep the temperature isolated to itself. Then, to distinguish the main floor from the basement, we boarded up the entrance to the stairs. This allowed us to better distinguish between both levels.
When looking at how to connect the XBee to the temperature sensor, we have two choices. We either use a typical breadboard or soldering the XBee and sensor to a breakout board. At first we decided to just use an ordinary board and wire everything together, but we soon realized that the mock up required very specific size capacitors and complete knowledge in where each pin of the XBee connects. We then decided to use a simpler layout and solder the pieces together to ensure that they stay in place. The breakout board worked better with the setup as is was a smaller and more slender size in comparison to that of a regular breadboard. This made it easier to place the sensors where we wanted without taking up too much space or looking too out of the ordinary. Originally we had positioned one in a single room, the basement, and the living room. We encountered an issue with the old copper and steel piping in the basement that caused too much interference and irregularities in the results. With the living room, it was too exposed to the rest of the house that it could not be isolated to determine individual results. We later moved one sensor to the bathroom and the garage. The one placed in the bathroom also had some irregularities and fadeouts. This was likely caused by the wall tiles, granite sink, and piping that caused for some distortion in the results. The one placed in the garage had better results, but was delayed in transmitting the data as the aged, bricked wall of the house and garage caused difficulty in the signal reaching the main base.
After investigating each area of the house, these three rooms were the best place to position them. The three rooms proved easier to isolate from the rest of the rooms and this allowed for the XBees to charge more efficiently with a solar panel. Having a great amount of space and access to a window, the XBees were placed in the center of each room with a solar panel facing the room. This enabled for the XBee to record a more accurate representation of the room temperature and charge at the same time.
Once we started to incorporate the solar panels, we solder a set of transformers with a capacitor to prevent the panel from overloading the lithium battery and shorting out or overheating the XBee. Another perk to using the XBee is its functionality to go into a sleep mode during the intervals of collecting the data, in order to conserve even more power from the battery. We tried to utilize that functionality, although it proved to be a difficult portion to try and code. Seeing our deadline approach, we concluded it would be best to leave the program as to not cause more code issues. Instead, we decided to lengthen the intervals of data collection as it was not necessary to record every second of data collection of the room temperature.
Ideally with that function, and the setup of the battery and solar panel, the XBee could essentially run for months with little to no maintenance required. This makes a fully mobile, inexpensive and efficient system for collecting most types of data. If anyone wants to place this in an outside environment, it would fully reach its efficiency in obtaining energy, granted that the device and setup is kept in an enclosed case.
In planning this setup, an Arduino will be connected alongside the XBee that is set as the coordinator and, together, will make up the base station. The base station will wirelessly connect to the other XBee radios to collect data from temperature sensors recording the information from the given area of the data, from which we want to collect. We decided to move the base station around to find the best fit and test the distance of the radio frequency.
Now that the XBees and base were situated in their respected areas, it was time to fully configure them to the system of endpoints, router, and base. The most difficult part was trying to configure the XBees to communicate properly, where the endpoint would collect the data and relay it to the router and the router would forward it to the base to further the distance covered. Many issues arose when the values given were not what expected, or even worse, when the shield or radio was bad. This caused much troubleshooting and time-consuming adjustments.
When time came to write the code, we struggled a lot as neither of us are proficient in writing the logic in coding language to our desired results. The first step was to translate the given values of the XBees’ into a more user friendly output, such as Fahrenheit or even Celsius. This took a few days of research to try to understand the coding behind the logic. We looked at tutorials as how to set up the coding. Afterwards we were able to set up the if statements and the for loop to have the data printout consecutively on the set delay for when the next interval needed to take place. To get the data in Fahrenheit, it was easier to first convert the raw data to Celsius and from there convert the Celsius data to Fahrenheit The coding and the configuring of the data had to be the most difficult and stressful portion of the project.
Once we were able to get the system to work and fully demonstrate it, we were able to concentrate on each point of electricity, data collection, data transmission, and data presentation. In achieving electricity, we demonstrated it within two different portions of the project. The first representation was with the main base, which when plugged into the computer, the Arduino was powered, along with powering the connected XBee. Also, electricity was represented by the endpoints connected to a lithium battery that was being charged by a solar panel maintained by the transformer/capacitor. We demonstrated the data collection portion by implementing the temperature sensor to collect the temperature of the room that we checked for reliability. The endpoint would collect the data and the router transmitted that data to relay it to the main base. The usage of the XBee radios shows a better representation of how data transmission as it transferred not from just point a to point b, but also through an intermediate, as well. We tested the range of this set up from 15 feet to approximately 130 feet. We finally displayed the data presentation by implementing the Arduino to use the code that enabled us to convert the collected data to a readable output of Fahrenheit and display it to the user.
Upon final completion of the project, we had a short-lived feeling of satisfaction as there was still much to improve. We thought about it thoroughly and saw many improvements for a more pleasing product used by many. The main idea that we wanted to develop is to incorporate more radio endpoints to prove that radios have the capacity to far exceed Wi-Fi and Bluetooth devices in the capacity to connect to each other. This improvement will allow for more data collection and more accurate results, which could lead to more discoveries in energy conservation. We could also expand on the solar panels by lengthening cables to move the endpoints further from the windows. Additionally, we could implement a light or sound signal for when the room temperature drops to a certain degree to better identify when and where a loss of temperature/energy occurred. A final suggestion that would make this more marketable to a company is implementing the Ethernet shield to the Arduino used earlier in the course. This will enable the user unlimited mobility to review the temperature of the given area via the Internet and determine whether to adjust the air conditioner or heater.
When looking at this project from a third perspective, there are still many more situations in which this system can be utilized. For this project, we mainly addressed how to record the temperature of separate rooms in a household and save money, but there are still many other uses. That this system is wireless and battery/solar powered, it does not have the restriction of being anchored in a set spot. Though a cheaper solution to solve many issues, a stationary position would be pointless and limited. If the device were stationary, it would require a total reconstruction, costing much more money in the long run. Mobility would allow this system to be expanded to a larger scale and easily transferred to different locations with minimal effort. The only mobile concern is that different portions of the system can be damaged or broken when moved or transferred to a new location.
In the market currently, there are many variations offering similar data collection as this system, but many of those are much more expensive, costing hundreds or even thousands of dollars. Most of those systems also implement only one manually operated sensor, which defeats efficiency and accuracy. Other more expensive units consist of multiple endpoints and are limited by the Wi-Fi 802.11, which limits range, depending on the usage of g, n, ac, ad, etc. Also Wi-Fi limits the amount of endpoints utilized, thus reducing data collection and recording. The implementation of a radio network for our system allows unlimited endpoint connections and data collection for a cost less than half of the other units. The basic set such as ours with the Arduino, radios, solar panels, and other parts cost roughly $250.00 to $300.00. Adding another endpoint to our system only costs approximately $30.00 to $40.00.
This project provided a good challenge. It allowed us to implement what we learned in class and provided a real-world situation for which we could present an applicable solution. The project helped us learn how various components need to function independently and collectively in a meshed network. It was a great learning experience.
adafruit. (2016). Retrieved from www.adafruit.com: https://www.adafruit.com/
arduino. (2016). Retrieved from www.arduino.cc: https://www.arduino.cc/
Chicagotribune. (2011). Retrieved from http://articles.chicagotribune.com: http://articles.chicagotribune.com/keyword/purdue-university-calumet
digi. (2016). Retrieved from www.digi.com: https://www.digi.com/pdf/xbee-802-15-4-protocol-comparison.pdf
Faludi, R. (2010). Wireless Sensor Networks. In R. Faludi, Wireless Sensor Networks (p. 300). Sebastopol, CA: O'Reilly Media, Inc.
Learn more about Illinois Tech's Smart Lab - https://www.iit.edu/smartlab