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