Wireless Controlled Residential Air...
Transcript of Wireless Controlled Residential Air...
UNIVERSITY OF NEVADA LAS VEGAS
DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING
EE & CPE 498 Senior Design
Spring 2015
Wireless Controlled Residential Air Vent: A Smartphone Interface for Air Direction
Final Report
Group Members:
CPE
Name (Print) CPE/EE/ME
EE Name (Print) CPE/EE/ME
Wireless Controlled Residential Air Vent
Introduction………………………………………………………………………...…….3
System Overview…………………………………………………………………………3
Primary System Components……………………………………………………..…….7
Summary and Conclusions…………………………………………………………….17
Appendix…………………………………………………………………………...........19
Introduction
Air conditioning (A/C) vents are stationary with permanently fixed fins. This means that
it can only direct airflow to the predetermined design of the vent. In some applications,
the airflow is scattered to areas that don’t need to be cooled or heated. For example,
couches or other pieces of furniture where people tend to spend most of their time in a
room can sometimes be placed in an area where the vents do not direct airflow to.
Another example can be found in bedrooms where the bed is placed in a position where
the airflow is directed straight to a resting person’s face which in some cases can cause
sinus problems. A need to manually control the A/C vents to direct airflow is the
solution to these issues.
Our project will have a full two dimensional control of the airflow coming out of a vent.
It will be an easy bolt-on replacement for the standard vents already installed in
residential homes and will be controlled via an application on a smart mobile device.
Once the app is installed, the user will have to establish a Wi-Fi connection form their
smartphone to the Wi-Fi module on the air vent. Once that is done, they will open the
application to confirm the connection to be able to use the interface that will control the
direction of the airflow. Depending on what the user wants, the vent can move side-to-
side, up and down or both at the same time. Because we have such control over the vent,
we can also completely close the vent to a room by pressing the down arrow on the app
until the vent closes.
This report will consist of a simplified overview of the design, a description of the
components, a summary with conclusions drawn from the design, and finally the
appendix that will consist of the schematic and final pictures of the product.
System Overview
The proposed air vent will take on the dimensions of the already available vents that can
be found in residential homes and home department stores. Figure 1 shows the vent that
was purchased from Lowes that was modified. The modifications included an extra
chassis to support the movement of the front fins. Servo motors will be added to both the
left-right and up-down chasses to control the direction of the airflow.
Figure 1: Vent purchased at Lowe’s
The two sets of fins with both layers arranged perpendicular to each other to achieve the
two degrees of motion desired to be able to direct air to any location within the living
area of the room. The top layer facing the room will have the fins arranged perpendicular
to the floor. The bottom layer located inside the housing will have the fins parallel to the
top layer and therefore resulting in the fins being parallel to the floor of the room. Figure
2 illustrates the two degrees of motion desired for this controllable vent.
Figure 2: The two degrees of motion for the vent
This architecture for the vent will allow it to be able to cover all the areas within the
volume of the living space. Figure 3 illustrates the potential coverage given that both sets
of pins can pivot 180 degrees with respect to the wall.
Figure 3: Coverage of one vent in a cube shaped room
The circuit will consist of a microcontroller from Atmel and Wi-Fi module from Digi.
Extra components such as LEDs will be used to indicate power on of the Wi-Fi module
and to indicate when the module is receiving commands from the smartphone. The
wireless communication would involve the smartphone sending ASCII characters to the
Wi-Fi module; the Wi-Fi module will send the characters to the microcontroller. The
microcontroller will contain case statements where the ASCII characters will trigger the
appropriate blocks of code that will result in the necessary movements to the servo
motors. The system architecture of the wireless air vent can be seen in figure 4 below.
Figure 4: System Architecture
This design is intended to be wired into the home’s energy supply. The supply and other
components on the circuit board would have to step down the voltage to an appropriate
level for the components on the circuit board to operate correctly and safely without
damaging the components.
Primary System Components
Chapter 1: Air Vent………………………………………………………………...…….8
Chapter 2: Servo Motors…………………………………………………………………9
Chapter 3: Wireless Communication……………………………………………………10
Chapter 4: Microcontroller………………………………………………………………11
Chapter 5: Smartphone Application…………………………………………………….15
Chapter 1: Air vent
The air vent needed to have fins that supported pivoting for both sets of fins. On many
applications of the traditional air vents, the fins on the face of the vents are stationary. They give
you control of the vertical axis but leave the horizontal axis alone. We saw this as a problem that
needed to be solved. In our own personal homes, the fixed fins directed air to an area we did not
necessarily want it to go and even if we got a vent that had horizontal control of the direction, we
would have to get on a ladder to change the direction of it; another problem to be solved. We
then had to find a vent to work with. We felt it would be better to modify an existing vent rather
than build a new one. The air vent we chose to modify had one lever to control the vertical
direction of the air flow and individually controlled fins to direct it horizontally. Having to
control all the fins individually seemed like a hassle so we had to come up with a solution to
control all the horizontal fins at once.
We then attached all the horizontal control fins together so they would move as one. These
horizontal fins and the vertical fins were then connected to individual control servos attached to a
frame we built on the back side of the vent.
The circuit board with the microcontroller and Wi-Fi module attaches to the back of the vent as
well to create an easy, drop-in solution for replacing existing vents. A centrally located power
supply would be at the main air handler with power wires running down the air ducts to power
each individual vent circuit.
Chapter 2: Servo Motors
Limit angle 180˚plus or minus 10˚
Weight 63 plus or minus 1g
Operating Voltage 4.8V - 6.0V
Operating Temperature -10˚C – 50˚C (14˚F - 122˚F)
Dimensions 40.7x20.5x39.5mm
Stall Torque 17kg/cm
We needed something to reliably and precisely control the air vent while at the same time, it had
to move quickly and not take up a lot of space. At first we wanted to use stepper motors because
of their precision but they have very low torque relative to their size. To get a stepper motor that
would have the torque to move the vent fins, it would have to be what we considered to be too
large. It would block too much and give us uneven air flow. Our next thought was a linear
actuator but it too was bulky, plus it was relatively slow. I nthe end we decided on using cervo
motors. They have precise control, good speed, and a great torque to size ratio. The model we
chose to use was the PowerHD 1501MG. This was partially due to our familiarity with the
PowerHD brand of servos and how to control them, as well as its high rated torque. For such a
compact form factor, it has a stall torque of 17kg/cm. This torque does come at a price however.
It uses metal gearing instead of the usual plastic ones and that metal on metal makes them louder
than some other servos.
Chapter 3: Wireless Communication
Since the decision to control the air vent via a smartphone was established, the wireless
modules that had to be selected had to be supported by smartphones. The protocols considered
were Bluetooth, Zigbee, and Wi-Fi. Bluetooth was a promising option because so many people
are familiar with it. The problem with Bluetooth is that it can only connect to two devices at any
one time. While this was fine for our prototype, this would not scale up if this design was ever
expanded to more than two vents. ZigBee is a nice robust protocol because it is self-healing and
creates a strong mesh network. However, smartphones cannot communicate directly without a
gateway and that seemed like an unnecessary addition. This left us with the Wi-Fi module as
being the best choice. It consumes more power than all the others but we decided that ease of use
for the end user was more important. The Wi-Fi module would allow an end user to connect the
vent to the same wireless network their smartphone was already connected to and easily
communicate with it. The consideration of future expansions helped with the decision of this
protocol. Digi’s XBee Wi-Fi module was the best choice due to its simplicity in use and its cost.
This device cost about $35 and it was a simple and small design. Also, Digi provided free
support for this product and the programming software was free. Below are the specifications
and an image of the module.
Serial Data Interface UART up to 1Mbps, SPI up to 6 Mbps
Frequency Band ISM 2.4 GHz
ADC Inputs 4(12-bit)
Digital I/O 10
Operating Temperature -30˚C to +85˚C (-22˚F to 185˚F)
Network Security WPA-PSK,WPA2-PSK and WEP
Channels 13
WLAN Standard 802.11b/g/n
WLAN Data Rates 1Mbps to 72 Mbps
Transmit Power Up to +16dBm
Receiving Sensitivity -93 to -71 dBm
Supply Voltage 3.14 to 3.46 VDC
Transmit Current Up to 309mA
Receiver Current 100mA
Dimensions(L X W) 27.61mm X 24.38mm
Figure shows image of Digi’s Xbee Wi-Fi module along with a table of its specifications
This component must be setup in a certain manner so that it will behave as an access
point. This information was discovered by calling Digi’s technical support number. The
operator advised that the specific infrastructure in which an android and now many other smart
mobile devices interface with their products is through a Wi-Fi protocol called SoftAP mode.
Software enabled Access Point allows this module to be able to be viewed by a smartphone as a
wireless access point or also referred to as a Hot-Spot. The next step is to give it an SSID, which
is simply a name for the network being setup by the module. Lastly, it is set to follow the TCP IP
protocol to ensure a reliable, ordered, and error-checked delivery of a stream of bytes between
the phone and the module. As soon as a button is pressed into on the smartphone application, the
signals are sent to the Wi-Fi module that is programmed to always be listening to data coming
from the phone. The module obviously only receives data when the smartphone transmits it.
OCR=2100
OCR=1200
OCR=400
OCR=1700
A
C
D
B
Chapter 4: Microcontroller
There a numerous amount of microcontrollers in the industry and there were more than
enough that were capable of meeting our demands. Some of the microcontrollers looked into
were the SAM3X8E, Atmega8, and Atmega328. The SAM3X8E has a powerful 32-bit ARM
processor that would allow us to add any additional features in the future we could think of. It
would also give us extremely quick processing speed to minimize delay from button press to
system action. It turned out to be more processing power than we really needed so we moved to a
lower tier ATMEL product. The Atmega 8 has an 8-bit processor which we determined would
be fine for the design but it only had 8KB flash which might not be enough if the design was
ever expanded. Leaving room for expansion was one of the main goals in this project. Lastly, the
Atmega328P was considered, this microcontroller has the same 8-bit processor as the Atmega8
but comes with 32KB flash which opens the possibility of future expansion. Ultimately, the
processor used for the design was the Atmel’s Atmega328P. The main features needed for the
controlling of the servos was its capability to perform pulse width modulation. This is achieved
by timers integrated into the architecture of the microcontroller. So the timer could be configured
to be support assignment of integer values to count to. The values then reflected positions of the
servo motors and were then translated to positions in degrees. The diagram below shows the
positions according to the timer value assigned.
Figure shows the regions where air flow was detected from their corresponding clock values.
Figure shows an image of the Atmega328P and its specifications
The microcontroller of choice did not need to have many ports for input and output pins.
However, future expansions of integrating different types of external sensors made this
microcontroller more optimal due to its many input and output pins. Also, speed was not an
issue either, so a fast microcontroller would have just increased the cost. This controller was
programmed using Atmel Studio, an AVR flash programmer, and an Evil Scientist programming
board. The following program was uploaded to the microcontroller:
/* * Aeolus_Final_controller.c * * Created: 3/16/2015 9:39:46 PM * Author: Omar Salazar */ #define F_CPU 8000000UL //XTAL = 8MHZ #include <avr/io.h> #include <util/delay.h> #include <stdlib.h> #define BAUDRATE 9600 #define BAUD_PRESCALER (((F_CPU/(BAUDRATE*16UL))) - 1 ) void USART_INIT(void); //This function initializes the USART void USART_SEND(unsigned char data); //This function allows what was pressed on the keyboard to be displayed unsigned char USART_RECEIVE(void); //This function allows the Atmega328P to receive from the keyboard int main() { ICR1 = 20000; //ICR1 = 20000 defines 50Hz pwm TCCR1A = 0xA2; //Clear OC1A/OC1B on Compare Match, set OC1A/OC1B at Bottom TCCR1B = 0x1A; //Top is ICR1, and it is fast PWM mode. Start timer with prescaler 8 DDRB |= 0x06; //Sets the appropriate B ports to output USART_INIT(); unsigned int up_max = 1450; unsigned int down_max = 800;
unsigned int left_max = 800; unsigned int right_max = 2600; unsigned int up_down_val; unsigned int left_right_val; unsigned char serv_mode; //*********************CENTER OUT******************************** OCR1A = up_max; //center up OCR1B = 1800; //center left right up_down_val = up_max; left_right_val = 1800; _delay_ms(2000); //*************************************************************** unsigned char konami[4] = {'0','0','0','0'}; while(1) { serv_mode = USART_RECEIVE(); if((serv_mode == 'F') || (serv_mode == 'B') || (serv_mode == 'L') || (serv_mode == 'R')) { konami[3] = konami[2]; konami[2] = konami[1]; konami[1] = konami[0]; konami[0] = serv_mode; if((konami[0] == 'R') && (konami[1] == 'L') && (konami[2] == 'B') && (konami[3] == 'F')) { OCR1A = up_max; int i; for(i = 0; i < 10; i++) { for(int i = left_right_val; i <= right_max; i = i + 100) { OCR1B = i; _delay_ms(400); left_right_val = i; } for(int i = left_right_val; i >= left_max; i = i - 100) { OCR1B = i; _delay_ms(400); left_right_val = i; } } konami[0] = 'X'; serv_mode = 'X'; up_down_val = up_max; OCR1B = 1800; //center left right left_right_val = 1800; } else if((serv_mode == 'F') && (up_down_val < up_max)) {//Move fins up up_down_val = up_down_val + 100;
OCR1A = up_down_val; } else if((serv_mode == 'B') && (up_down_val > down_max)) {//Move fins down up_down_val = up_down_val - 100; OCR1A = up_down_val; } else if((serv_mode == 'L') && (left_right_val > left_max)) {//Move fins left. left_right_val = left_right_val - 100; OCR1B = left_right_val; } else if((serv_mode == 'R') && (left_right_val < right_max)) {//Move fins right left_right_val = left_right_val + 100; OCR1B = left_right_val; } } } } void USART_INIT(void) { // This function will set the micro controller for serial communication with the PC // It sets the necessary baud rate registers, and prescaler value. UBRR0H = (uint8_t)(BAUD_PRESCALER >> 8); UBRR0L = (uint8_t)(BAUD_PRESCALER); UCSR0B = (1 << RXEN0) | (1 << TXEN0); UCSR0C = (3 << UCSZ00); } unsigned char USART_RECEIVE(void) { // This function receives data from the PC Terminal through // the DB-9 cable. while(!(UCSR0A & (1<<RXC0))); return UDR0; } void USART_SEND(unsigned char data) { // Function to send data from the ATmega328P to the terminal on the PC while(!(UCSR0A & (1 << UDRE0))); UDR0 = data; }
The array named konami had to be integrated to activate the oscillation mode that is
described in Chapter 5. The microcontroller receives the data serially with support of the UART
protocol. The Wi-Fi module runs at a different clock than the smartphone and the
microcontroller. The smartphone to Wi-Fi module communication is discussed in Chapter 3, but
quick summary of it is that the module is programmed to always listen for input and once it
receives it, it outputs the data to Pin 3 of the module. So this Pin 3 is treated as a transmit pin.
The microcontroller supports serial communication via its transmission and receiving pins. The
transmission pin of the module is connected to the receiving pin of the microcontroller. The
code involves checking for proper input and then handles it accordingly through the if-else
statements.
Chapter 5: Smartphone Application
The application had to provide a way to direct the data to the Wi-Fi module. The Wi-Fi
module, like stated in Chapter 4, had to be configured in a way so that the smartphone could
establish a Wi-Fi communication. So once the Wi-Fi communication was established, the
application had to do to the rest of the work. The two operating systems taken into consideration
were the Android OS and the iOS. Due to both Taylor and Omar having an Android phone, the
cost of purchasing a different phone containing the iOS was avoided so the app development for
the Android environment was chosen.
The full development of the application was attempted. It was very difficult to find
tutorials that involved programming of an application that would identify a Wi-Fi module and be
able to send commands to it. MIT created an easy interface called MIT APP Inventor. This
option was immediately discarded after encountering its lack of Wi-Fi support. The program
allowed for Bluetooth connections only. Since the application was the last component to the
system, a change in wireless protocol could not be performed. In researching the Soft-AP mode
for the Wi-Fi module configuration, the android application used to test this connection was
Innovative Experiment’s WiFly Remote. The figure below shows the screen for the connection.
Figure shows WiFly Remote connection screen
The WiFly Remote application just requires that the Android smartphone establishes the
Wi-Fi connection between the phone and the Xbee Wi-Fi module. Then the application will
funnel the data transmitted to the Xbee Wi-Fi module. These parameters are pulled from the
programming software of the Xbee Wi-Fi module called XCTU. Once these parameters have
been entered, the next step is to push the connect button located at the bottom of the screen.
When the decision was made to use this application, the next obstacle was to determine
what gets transmitted when the arrow keys were pushed. Using the XCTU’s integrated terminal,
were able to see the data being transmitted. The diagram below shows the result of what was
discovered on the terminal.
This facilitated the program for the microcontroller. However, the feature of oscillation
needed an additional button. Since this required software that would disassemble the application
to make modifications to the interface, a sequence of buttons pressed would be needed to enable
the oscillation mode. The sequence chosen to activate the oscillation mode was pressing up,
down, left, and right. Once that sequence was pressed, the oscillation mode would be enabled
for three minutes. After it timed out, the application would be ready to transmit new commands
to the air vent.
Summary
A need to manually control the A/C vents to direct airflow is the solution to these issues.
A more perfect design involves wireless control of the air vent to give the user the power to
direct the airflow to wherever the user desires. What better device to control the air vent than
with device that has grown to be a part of everyone’s daily life, the smartphone. With the touch
of a button on a smartphone device, you can avoid dealing with the above mentioned problems.
The wireless air vent solves the problem of having unreachable air vents. Homes with
high ceilings have air vents mounted very high. This makes accessing them more difficult and in
many homes, an eight foot ladder would still be insufficient to be able to move the lever on the
air vent. In some applications, the airflow is scattered to areas that don’t need to be cooled or
heated and therefore resulting in airflow not being directed to areas that should be cooled or
heated, the wireless air vent’s feature of full motion control solves this problem. The full motion
control can help alleviate sinus problems. In some cases, the fixed fins direct airflow to a resting
person’s face. This makes your nasal passages dry out making mucus thicker, which in some
cases can cause sinus problems. Once the A/C unit kicks in, it has to cool down or heat up the air
in the room first before the person experiences the temperature relief. Again, the motion control
allows the user to direct the airflow to the himself/herself to have instant relief.
The components selected for this functional prototype were selected with the future of the
project in mind. We selected the parts with the hope for expansions and growth. The table
below illustrates the costs of the components.
Manufacturer Part Number Description Prototype
Quantity
Prototype Cost (per
unit)
Final Quantity
(per vent)
Final Cost Estimate(per
vent)
Digi International
XB2B-WFWT-001
XBee Wi-Fi module 1 $39.35 1 $29.59
Atmel ATMEGA328-
PU Atmel
Processor 1 $4.45 1 $1.86
PowerHD 1501MG Servo
Motor 2 $19.95 2 $16.95
OshPark PCB 1 $20.00 1 $10.00
Misc.
components 1 $60.00 1 $30.00
Air Vent 1 $17.95 1 $10.00
Prototype cost total
Final Cost Total
$181.65
$115.35
A future expansion of this project would be to have a customized application that will
allow for the smartphone to show all the vents established on the network. For this to be
possible, the Wi-Fi module would have to be connected to the home Wi-Fi network instead of
each establishing its own Hot-Spot. This would be an easier interface for the customer and the
accessing of each vent could be sped up because you would eliminate the time it takes to open
the Wi-Fi on the smartphone and changing the connection to a different vent. A higher quality
mechanical build for the vent would help with replacing the servo motors with weaker ones. As
stated in Chapter 2, the servo motors are overkill. They were selected without having the
knowledge of how much force was going to be required to move the louvers on the vent. The
change of the servo motor could also make it a quieter design since the more powerful the servo
motors are, the louder the noise they generate when they move. Lastly, the interface has much
room for improvement. The possibilities can range from pinpointing locations in a room, to be
able to pinpoint multiple locations in the room at the same time so that the air vent can oscillate
in its fan mode between the locations desired.
Appendix
Schematic
The schematic below shows our first PCB design that will be submitted for fabrication.
Both schematics will be put on one PCB.
The schematic above shows the microcontroller and the XBee Wi-Fi module
The above schematic contains the step down amplifiers so that the XBee can receive the
corresponding signals. This must be performed because it operates at 3.3V unlike the
microcontroller that operates at 5V.
Below are images of the final PCB used in the project.
Front
Back
Pictures of the final product
Top view of the vent encased in Plexiglas box to show left/right movement
Angle view of vent encased in Plexiglas box to show circuit board and up/down movement
Circuit board inside display box