Students
Jonathan Garcia
Jose Garcia
Faculty
Jeremy Hajek
Course Name/Number
ITM 492 - Embedded Systems and Reconfigurable Logic Design
Date
Fall 2016
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 have 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 different systems that can better our lives by being more efficient, more reliable, and less time-consuming. As for this project, we will focus on an Arduino and multiple Bluetooth transmitters called XBee 802.15.4 which 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 of the industrial buildings. To resolve this issue, a course of action was needed to 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 airflow 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 airflow in the ventilation system shifts entirely to one side rather than utilizing the whole space. This caused the system to overwork itself 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 saved $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 contributed greatly to saving a large sum of money for the university. This concept can be used to detect irregularities in utility usage and can be applied to many other areas. A setup like this can be brought to a wider scale to save not only money but also the lives of many people. The possibilities for this type of system are endless.
The essential concept of our project is to create 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 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 collecting and transmitting the data on the temperature? How could we prevent the radio endpoints from collecting mixed results in an average house temperature? Not only that, but where would we precisely place each endpoint to make full use of it?
To overcome this dilemma, we decided to research how to address each issue. When transmitting the data, we had already used the Xbee radios used in a previous lab from class. After fully observing them, they have many advantages. Unlike Wi-Fi, which goes off on 802.11, the XBee consumes an exponentially lesser amount of power, allowing it to run for days on end. Regarding connecting many devices, Wi-Fi is limited to 32 devices and Bluetooth is limited to 7, while the XBee is relatively unlimited. While Wi-Fi and Bluetooth can 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 collecting the exact temperature pattern in each room, we isolated each room to maintain its 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 solder 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 capacitors of very specific sizes and complete knowledge of where each pin of the XBee connects. We then decided to use a simpler layout and solder the pieces together to ensure that they stayed in place. The breakout board worked better with the setup as it was smaller and more slender in comparison to 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, which caused 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 places 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 the XBee to record a more accurate representation of the room temperature and charge at the same time.
Once we started incorporating the solar panels, we soldered 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 sleep mode while collecting the data, 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 so as not to cause more code issues. Instead, we decided to lengthen the data collection intervals as it was not necessary to record every second of data collection at 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 data types. 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, which 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 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 respective areas, it was time to fully configure them for the system of endpoints, router, and base. The most difficult part was configuring 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 was expected, or even worse, when the shield or radio was bad. This caused much troubleshooting and time-consuming adjustments.
When writing the code, we struggled a lot as neither of us was 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. It 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. Afterward, 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 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 room temperature 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 is transferred not from just point A to point b but also through an intermediate. We tested the range of this setup 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 completing 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. This improvement will allow for more data collection and 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 to 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 where 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. Since 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 data collection similar to 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. Implementing a radio network for our system allows unlimited endpoint connections and data collection for a cost of less than half of the other units. The basic set, such as ours with the Arduino, radios, solar panels, and other parts, costs 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 must function independently and collectively in a meshed network. It was a great learning experience.
Works Cited
adafruit. (2016). Retrieved from www.adafruit.com: https://www.adafruit.com/
arduino. (2016). Retrieved from www.arduino.cc: https://www.arduino.cc/
Chicago Tribune. (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