ECE 477 Final Report Spring 2006 - College of Engineering · 2008-08-25 · ECE 477 Final Report Spring 2006 A-1 Abstract Handy is a hand gesture based remote control. A user is able

ECE 477 Final Report

Spring 2006

Team Code Name: Handy Team ID: 11

Team Members (#1 is Team Leader):

#1: Zaizhuang Cheng Signature: ____________________ Date: _________

#2: Derrick Ko Signature: ____________________ Date: _________

#3: Colin Tan Signature: ____________________ Date: _________

#4: Naga Setiawan Signature: ____________________ Date: _________

Zaizhuang Cheng

Derrick Ko

Colin Tan

ECE 477 Final Report Spring 2006

-ii-

REPORT EVALUATION

Component/Criterion Score Multiplier Points

Abstract 0 1 2 3 4 5 6 7 8 9 10 X 1

Project Overview and Block Diagram 0 1 2 3 4 5 6 7 8 9 10 X 2

Team Success Criteria/Fulfillment 0 1 2 3 4 5 6 7 8 9 10 X 2

Constraint Analysis/Component Selection 0 1 2 3 4 5 6 7 8 9 10 X 2

Patent Liability Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Reliability and Safety Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Ethical/Environmental Impact Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Packaging Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Schematic Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

PCB Layout Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Software Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Version 2 Changes 0 1 2 3 4 5 6 7 8 9 10 X 1

Summary and Conclusions 0 1 2 3 4 5 6 7 8 9 10 X 1

References 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix A: Individual Contributions 0 1 2 3 4 5 6 7 8 9 10 X 4

Appendix B: Packaging 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix C: Schematic 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix D: Top & Bottom Copper 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix E: Parts List Spreadsheet 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix F: Software Listing 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix G: FMECA Worksheet 0 1 2 3 4 5 6 7 8 9 10 X 2

Technical Writing Style 0 1 2 3 4 5 6 7 8 9 10 X 8

CD of Project Website 0 1 2 3 4 5 6 7 8 9 10 X 1

TOTAL

Comments:


-iii-

TABLE OF CONTENTS

Abstract 1

1.0 Project Overview and Block Diagram 1

2.0 Team Success Criteria and Fulfillment 3

3.0 Constraint Analysis and Component Selection 4

4.0 Patent Liability Analysis 12

5.0 Reliability and Safety Analysis 17

6.0 Ethical and Environmental Impact Analysis 23

7.0 Packaging Design Considerations 24

8.0 Schematic Design Considerations 28

9.0 PCB Layout Design Considerations 32

10.0 Software Design Considerations 36

11.0 Version 2 Changes 46

12.0 Summary and Conclusions 48

13.0 References 50

Appendix A: Individual Contributions 53

Appendix B: Packaging B1

Appendix C: Schematic C1

Appendix D: PCB Layout Top and Bottom Copper D1

Appendix E: Parts List Spreadsheet E1

Appendix F: Software Listing F1

Appendix G: FMECA Worksheet G1


A-1

Abstract Handy is a hand gesture based remote control. A user is able to customize Handy, by associating

different hand gestures to infrared control commands of a Bose SoundDock. Handy will

subsequently transmit the appropriate control command upon matching a read gesture to a pre-

recorded one.

1.0 Project Overview and Block Diagram The motivation of creating Handy is to provide a button-free environment in which the user can

just use hand gestures to control the sound system. For example, when the user is driving, all he

has to do is perform the appropriate hand gestures to control his sound system, all without taking

his eyes off the road.

Our project will comprise of three main hardware components: the microcontroller, the sensing

plate and the liquid crystal display (LCD) screen.

The infrared sensors will be mounted on a flat plate in a 3x3 grid. When a user moves his hand

over the plate, each sensor will detect the position of the hand and send the information to the

microcontroller. The microcontroller will then process the raw information and transmit the

associated command code to the sound system via infrared (IR). Users will be able to assign

their own hand movements to correspond to different commands, namely play/pause, next, back,

volume up, volume down and off. An LCD screen will then display the command that is

detected by the microcontroller. The LCD, in conjunction with a rotary pulse generator (RPG),

provides a user interface for the user to assign hand gestures to each command. A high level

block diagram is available in Fig 1.1.


A-2

Fig 1.1 High Level Block Diagram

Microcontroller

Plate of infrared sensors

LCD Screen

RPG

LED Indicators

Battery Pack IR

Transmitter


A-3

2.0 Team Success Criteria and Fulfillment

1. Ability to transmit IR commands that conform to a commercial standard. Criteria fulfilled. Handy is able to send IR commands to the Bose SoundDock, and replicate all

commands on its remote control – play/pause, next, back, volume up, volume down, off.

2. Ability to program distinct hand movements.

Criteria fulfilled. Handy is able to record hand movements and store them correctly in software.

When instructed, it stores them into the hand gesture library.

3. Ability to recognize distinct hand movements and look up the IR command code associated

with each programmed movement.

Criteria fulfilled. Handy is able to recognize distinct hand gestures, including those that are

slightly different. Upon successful recognition, Handy looks up the respective IR command and

transmits it.

4. Ability to configure the device and display its status using a keypad/LCD.

Criteria fulfilled. Handy has a user interface that is displayed on the LCD and navigated using

the RPG. The LCD displays instructions and the status of the system during recording and

recognition. It will display the matched IR command that was sent. When a recorded gesture is

not in the library, an “unrecognized” error message will display on the LCD.

5. Ability to conserve energy when device is not in use.

Criteria fulfilled. After ten seconds of idle time, Handy goes into sleep mode. In sleep mode,

the microcontroller shuts down, leaving only the specified external interrupt ports active. In

addition, the LCD display is cleared and its backlight shut off. The external interrupt ports are

tied to the middle two sensors (known as the activation sensors). Handy will wake up when

either of these two sensors detect hand motion.


A-4

3.0 Constraint Analysis and Component Selection

3.1 Constraint Analysis

During the design phase of the project, various constraints had to be taken into account and

analyzed. The analysis would affect the selection of components and influence key design

decisions. This section covers the following constrains and requirements that were taken into

account:

• Computational Requirements

• Interface Requirements

• On-Chip Peripheral Requirements

• Power Constraints

• Packaging Constraints

• Cost Constraints

3.1.1 Computational Requirements

The computational requirements are based on of the hand gesture recognition algorithm. A timer

starts once any of the non-initial-position sensors are activated. The times at which any

subsequent sensors detect movement are stored as long integers in a 3x3 array. Each sensor is

represented by an array element. The actual recognition will then depend on the comparison

between each new input array and the arrays already stored in memory.

There are key two computational requirements that will be needed – storage and processing

speed. However, these requirements are relatively low.

The storage requirements call for ample space for the RAM and EEPROM. The EEPROM will

be used to store the “library” of pre-recorded hand gesture arrays. The RAM will be used for

storing the newly input hand movement for processing, along with any temporary variable

storage needed for searching algorithms.

A 3x3 array of integers would use 4 bytes * 3 * 3 = 36 bytes. There are five hand gestures that

have to be recognized - play/pause, next, back, volume up, volume down. Hence, the absolute


A-5

minimum requirement for flash memory would be 36 * 5 = 180 bytes. The absolute minimum

for the RAM would be 36 bytes.

The infrared sensors have a sampling rate of 156.25 Hz. Hence, the microprocessor would

require a clock speed significantly higher than the sampling rate.

Most microcontrollers more than readily meet the clock speed and storage requirements of

Handy.

3.1.2 Interface Requirements

The main components of the device that directly interface with the microcontroller are the

Compact Distance Measuring Sensors, Infrared transmitter, LCD screen and the various LEDs

required.

GP2Y0D340K Infrared Sensors

The initial design allows for nine GP2Y0D340K infrared sensors [1] that are spread out on a

plate. Each sensor outputs a logic low when an object is sensed above it or a logic high when

there is no object above it. Since the output of the sensor is digital, nine general purpose I/O pins

are required for the nine sensors. This allows each sensor’s output to be sampled in a polling

loop. The sensor’s output voltages can be seen in Table 3.1.2 below.

Infrared LEDs

The infrared LED is driven by the PWM and is used to transmit command codes that are sent to

a commercially available sound system. A PWM channel is required as a 38KHz carrier

frequency has to be generated.

LCD Module

The function of the LCD screen is to provide a user interface that displays the commands (e.g.

play, pause, next) that are detected and provide a interface for programming of the different

commands. The LCD screen has an 8-bit parallel interface and it needs a total of eleven I/O pins

[2].


A-6

Feedback LEDs

The function of the feedback LEDs are to provide a visual aspect to the device that improves the

intuitive feel for the product. One LED will be used to indicate if the power is on or off. Each

sensor will be tied to an LED and the LED will turn on if an object is detected above the sensor.

A total of ten LEDs are to be used and ten I/O pins are required.

Rotary Pulse Generator (RPG) switch

The function of the RPG switch is to allow the user to scroll through the menu displayed on the

LCD screen. It has a pushbutton that will allow the user to select the item he wants on the menu.

Two I/O pins are needed for the RPG switch and two more I/O pins are needed for the inbuilt

pushbutton [3].

Table 3.1.1 I/O Minimum Pin Count Summary

Component No. of I/O pins

LCD Module 11

Distance Sensors 9

LEDs 10

Infrared LEDs 1

RPG switch 4

Total 35

As can be seen from Table 3.1.1, a total of thirty five I/O pins is the minimum that our

microcontroller must have.

Table 3.1.2 DC Characteristics

Component Input High(min) Input low(max) Output high(min) Output low(max)

Microcontroller 0.7*Vcc = 3.5 0.3*Vcc=1.5 4.2 0.7

LCD Module 0.7*Vcc=3.5 0.3*Vcc=1.5 - -

Distance Sensors - - Vcc-0.3=4.7 0.6


A-7

RPG switch - - 3.8 0.8

*Vcc = 5V.

The LCD module is the only device that requires a microcontroller output. The minimum input

high of the LCD module is 3.5V [2], well below the output high of 4.2V for the microcontroller

[6]. The maximum input low of the LCD module is 1.5V, which is below the 0.7 V output low of

the microcontroller.

3.1.3 On-Chip Peripheral Requirements

Pulse Width Modulation and Timer Channel

The PWM will interface directly with the infrared LED to control codes to the sound system.

The codes are generated by using the PWM to generate the carrier frequency. The timer channel

will then be used to toggle the PWM at specific intervals to create bit sequences.

3.1.4 Off-Chip Peripheral Requirements

Rotary Pulse Generator

The user interface system is simple, and using a rotary pulse generator (RPG) for navigation

would be sufficient. An RPG would save space, and provide an equally intuitive input method.

3.1.5 Power Constraints

Since this device has to be mobile, batteries are to be used. As such, power consumption would

have to be kept to a minimum. To this end, the smallest possible microprocessor needs to be

chosen that meets the minimum requirements. Also, the number of sensors used will have to be

minimized to prevent unnecessary dissipation of power. From Table 3.1.3, it can be seen that the

device needs a maximum possible total current of 1334 mA. Using three AA batteries, the device

would last only for a few hours. Therefore, the primary power constraint in designing this device

would be to include power management. This is done by the inclusion of a sleep mode on the

device, with the microcontroller, sensors, LEDs and the LCD screen powering up only when

necessary (eg. when the user interacts with the device). This would greatly enhance the life of the

AA batteries being used by the device. This current estimate will be much greater than the actual


A-8

current required because the component that draws the most current – the IR transmitter – will

only be used when sending commands, and this will be only for a very small percentage of time

the device is operating.

Table 3.1.3 Power Supply Characteristics

Component Supply Voltage

(V)

Input Current

(max, mA)

Total current

(mA)

LCD Module 4.5-5.5 62 62

Distance Sensor -0.3-7 38 342

LED 1.7 2 18

RPG switch 4.75-5.25 30 30

Infrared

Transmitter

1.7 150 150

Total 602

3.1.6 Packaging Constraints

The major factor affecting the packaging is that the device is to be mobile. Therefore, the device

needs to be light (approximately below 1 kg). In addition, the spacing and geometry of the

sensor positions is a major factor that determines the size of the device, as it must still be able to

distinguish between different hand gestures. Finally, since Handy is likely to be moved around,

the packaging has to be sufficiently strong.

3.1.7 Cost Constraints

The primary cost constraint is to keep the cost of the device as low as possible without

sacrificing its functionality. The closest product that has a similar function to our device is the

Media Center Remote by Gyration [4] and it costs $149.95. This device is similar to Handy in

that it is a remote control that uses motion sensing technology. However, it has a major

difference – Gyration’s product uses its motion sensing technology to translate gestures to


A-9

control an on-screen cursor, much like a “floating” mouse. Based on the Media Center Remote’s

price, the initial cost constraint is to keep the prototype below $150.

3.2 Component Selection

Two major components would determine the success of Handy – the microcontroller and the

sensors. These two components are integral to the basic functions of the device, and it is

important to evaluate the various options and choose the best product available that meets, or

exceeds, the requirements and the above constraints. A list of major components needed is

available in Appendix E.

3.2.1 Freescale MC9S12C32 versus ATmega325

Table 3.1.1 Microcontroller Comparison

Feature Freescale MC9S12C32 ATmega3250

I/O pins 60 69

EEPROM Nil 1Kb

SRAM 2Kb 2Kb

Flash 32Kb 32Kb

PWM channels 6 4

Processor 16-bit 8-bit

Clock Speed 16MHz 16MHz

Wake up on interrupt Yes Yes

Voltage Requirement (v) 5-5.5 4.5-5.5

Power Supply Current 35 mA 3 mA

Maximum current

(sinking/sourcing) per I/O

pin

25 mA 100 mA

References: [5], [6]

Based on the comparison in Table 3.1.1, the ATmega3250 was selected. The microcontroller

needs a minimum of thirty five I/O pins, four PWM channels and power management capability


A-10

(e.g. wake up on interrupt). Both the Freescale MC9S12C32 [5] and Atmel ATmega3250 [6]

microcontrollers met the requirements.

Since Handy is battery powered, power consumption is extremely important. The MC9S12C32

requires a power supply current of 35 mA [5], while the ATmega3250 requires much less at 3

mA [6]. This would assist in prolonging battery life. In addition, the ATmega3250 has a

maximum current (sinking/sourcing) per I/O pin of 100 mA [5] as compared to the

MC9S12C32’s 25 mA [6]. A higher maximum sourcing current is crucial for the IR transmitter,

as a decent transmission range must be achieved. Hence, the decision to use the ATmega3250

was largely based on these two factors.

3.2.2 Ultrasonic Distance Sensors versus Infrared Distance Sensors

To sense the motion of hand above the device, a distance sensor was needed. Looking at the

available parts online, the choice was narrowed down to the Sensor, Ultrasonic, 40KHZ [7] set

from jameco.com and the Sharp GP2Y0D340K Compact Distance Sensor [1]. By a rough

estimate, a minimum of 20 samples per second is needed to properly detect a moving hand above

the sensor. Both sensors met this requirement. The infrared sensors have a digital output which

would simplify data acquisition and its range is more than adequate for the purpose of sensing a

hand above the device. As such, since the infrared sensors met all the requirements and had a

more complete data sheet, it was chosen for the project. Price was not a factor as both sensors

cost about $7. Refer to Table 3.2.2 for a comparison

Table 3.2.2 Sensor Comparison

Feature Ultrasonic Sensors Infrared Sensors

Cost ~$7 ~$7

Output Analog Digital

Datasheet Yes Yes

Range None stated 10cm-60cm

Sampling rate N/A 156.25 Hz


A-11

3.3 Summary

Handy has a variety of interface components and peripheral requirements, with the sensors being

the most important. A proper selection of the sensor would greatly influence the ability of the

device to distinguish between different hand gestures. After the evaluation various sensors,

infrared sensors were chosen as it provided more precision and simplified data acquisition. A

maximum power analysis was performed as Handy is a battery-operated device. It was

determined that some form of software power management would be required. Since Handy

does not have high computational requirements, the short listed microcontrollers met all the

requirements, and the choice of the ATmega 3250 was largely dependent its electrical

characteristics. Finally, a cost constraint of $150 was placed on the device, based on a

comparison of other similar devices on the market.


A-12

4.0 Patent Liability Analysis

A search was performed on the USPTO online database of patents [8] in an effort to ensure that

there is no infringement with existing patents. Queries were made using combinations of related

keywords in conjunction with the keywords “remote control”: “motion sensing”, “motion

detection”, “hand gesture”, “pattern recognition” and “gesture recognition”. Though the different

searches listed many patents, the majority of the patents turned out to be dissimilar, though 3

patents were identified as being sufficiently similar to warrant further investigation so as to avoid

patent infringement.

4.1 Patent Search Results

4.1.1 United States Patent 6498628 (December 24, 2002) [9]

The patent was filed for a remote controller that controls an electronic appliance. The patent

claims that it is a remote control that comprises of a display screen that displays a cursor and

icons denoting different commands for the appliance, a motion detector for detecting hand

motions, and a control circuit that is connected to the motion detector, the appliance and the

display screen. The remote control starts up upon detecting a predetermined gesture, and the

movement of the cursor on the display then mirrors the movement of the user’s hand. The user

sends a command to the electronic device by selecting one of the icons on the display. This is

done by controlling the cursor using hand movements.

4.1.2 United States Patent 5594469 (January 14, 1997) [10]

The patent was filed for a system that controls a machine. The patent claims that the system

comprises of a display screen, a method to detect hand motions, a method to control the on-

screen hand icon, a method to select machine commands using the hand icon and a method for

transmission of the command. The display screen displays a moveable hand icon, as well as

control icons that denote the different machine commands. The user controls the on-screen hand

icon by hand motions, and selects a command icon using a predetermined hand gesture.


A-13

Detection of hand gestures is implemented by scanning a region and recording orientation

vectors of the hand gesture. The movement is then compared to predetermined hand gestures. A

command signal is sent if the performed gesture is similar to the predetermined hand gesture.

4.1.3 United States Patent 6603420 (August 5, 2003) [11]

This patent was filed for a remote control device. It is claimed that the remote control comprises

of a motion detection circuit, a processor and a transmitter. The motion detector circuit sends a

signal to the processor, and this signal corresponds to the direction in which the remote control is

moved. The processor receives the signal and then maps it to a device control signal, which is

then transmitted to the device via the transmitter. The control commands must at least include a

command to increase or decrease the volume and the channel of the device, and must have a

means to control at least one of the device characteristics using a button.

4.2 Analysis of Patent Liability

4.2.1 Literal infringement

“Literal infringement of a patent claim requires that every limitation recited in any claim in the

patent appear in the accused product or process.… If the accused product or process is missing

one of the claim limitations, there is no literal infringement.” [12]

In order to ascertain whether there is any literal infringement involved, a comparison should be

made between Handy and the claims of the 3 patents listed above.

4.2.2 Comparison with patents 6498628 and 5594469

Patents 6498628 and 5594469 both claim to have a display that displays a user-controlled cursor

and device command icons. The claims also state that the user manipulates the on-screen cursor

and selects a command icon using hand gestures. Though Handy has an LCD screen, its purpose

is to serve as a user-interface with the remote control itself, and in no way allows the user to

select which command is to be sent to the device. Furthermore, Handy has neither an on-screen

cursor nor command icons. Going by the definition stated above, Handy will not infringe on


A-14

patents 6498628 and 5594469 by way of literal infringement, since it is missing 2 claims from

each of the patents.

4.3.3 Comparison with patent 6603420

At first glance, patent 6603420 has claims that seem to be all-encompassing, but upon further

inspection, there were found to be 2 distinguishing claims that eliminated grounds for literal

infringement.

The motion detector circuit sends a signal to the processor when it detects motion of the remote

control itself, and not a hand gesture. Handy has a motion detector circuit that sends a signal

based on the user’s hand gesture, and is thus missing this claim. Also, the patent claims that there

must be a way to control a device characteristic by using a button, which Handy does not.

Due to the fact that there are 2 patent claims missing, it is safe to say that there is no literal

infringement on patent 6603420.

4.4 Infringement under the Doctrine of Equivalents

Infringement under the Doctrine of Equivalents is said to occur when there is “a component or

step which is ‘insubstantially different’ from the missing one or if there is equivalence between

the elements in the accused product and the claimed limitations.” [13]

To ascertain as to whether infringement under the Doctrine of Equivalents is present, Handy

must be examined for slightly dissimilar or wholly alternate means of achieving the same

functionality as the missing claims.

4.4.1 Comparison with Patents 6498628 and 5594469

As noted previously, both patents 6498628 and 5594469 have claims that state that the user is

able to choose which device command to transmit to the device by manipulating an on-screen

cursor and selecting the appropriate command icon on a display.


A-15

Though Handy also has an LCD display, its purpose is to function as a user-interface with the

remote control, and aids the user in programming the remote control, or to see which command

is currently being sent. The LCD display does not have an on-screen cursor and command icons,

and does not allow the user to choose which command to send to the device. This is substantially

different from the claims in both patents.

Also, there is no alternate method of selecting a particular device command, as Handy compares

the performed hand gesture to pre-recorded hand gestures, and then automatically transmits the

corresponding device command.

Since there is an absence of an element that is substantially the same or equivalent to the missing

claims in both the patents, it can be said that there is no infringement under the Doctrine of

Equivalents.

4.4.2 Comparison with Patent 6603420

One of the patent claims state the there must be a means to control at least one of the device

characteristics by way of a button.

When using Handy, the user chooses which device command to send to the device by performing

a specific hand gesture that corresponds to a device command. This is not substantially the same

as the claims in patent 6603420, since pressing a button is very different from performing a hand

gesture. It is also not equivalent, as Handy is required to decode which device command

corresponds to the performed hand gesture, whereas pressing the button simply transmits a

predetermined device command.

The patent also claims that the motion detector circuit sends a signal to the processor

corresponding to the movement of the remote control itself. Handy also has a motion detector

circuit, but it detects the user’s hand motion, and not the movement of the remote control itself.

This is neither substantially the same nor equivalent to the patent’s claim, since the signal is

triggered by hand motions, and also because the remote control need not move for the motion

detector circuit to output a signal to the processor.


A-16

Once again, due to the absence of elements that are substantially the same or equivalent to the

claims stated in the patent, there is no infringement under the Doctrine of Equivalents.

From the above comparisons, it can be seen that there is neither literal infringement nor

infringement under the Doctrine of Equivalents with the 3 patents identified.

4.5 Action Recommended

Though no potential for infringement has been found, it would be wise to acknowledge that this

analysis was performed by one not well-versed in legal matters pertaining to patents. The best

course of action would be to engage a patent lawyer to confirm the accuracy of this analysis, and

also to give legal advice.


A-17

5.0 Reliability and Safety Analysis

The following three components were analyzed:

1. ATmega3250 microcontroller

2. UC2577-ADJ Step-up voltage regulator

3. CFAH1602B Liquid crystal display (LCD)

The step-up voltage regulator and the ATmega3250 microcontroller were chosen based on the

fact that these two components would be more likely to operate at higher temperatures than the

rest of the components in the design. The LCD was chosen as it is the next most complex

component besides the ATmega3250 microcontroller.

The following assumptions were made for all components [14]:

1. In determining Eπ , ground mobile (GM) conditions were assumed as Handy is a remote

control and could potentially be used to control a sound system in a vehicle. Eπ is

therefore 4.0 for all three components. (MIL_HDBK-217F, Section 5.10)

2. The maximum operating temperatures found on the datasheets of each component were

used in determining Tπ . This is to account for the worst case scenario in which the

component is functioning at the maximum temperature allowed. (MIL_HDBK-217F,

Section 5.8)

3. The quality factor Qπ is assumed to be 10 for all components. This is because all of these

components are commercial components. (MIL_HDBK-217F, Section 5.10)

4. It is likely that the users of Handy would not know how to replace or repair the three

components in case of a failure, so it is assumed that these three components are

irreparable. Therefore, mean time to failure (MTTF) is used in all the calculations.

5. The packaging of Handy is not sealed or air tight and all the components are assumed to

be non-hermetic when determining C2. (MIL_HDBK-217F, Section 5.9)

All other individual assumptions are stated clearly in the tables. A list of definitions for each

parameter in the equations used to calculate Pλ is given in Table 1 below.


A-18

Table 4.1 Parameter Definitions

Parameter Definition

Pλ Part failure rate per 106 hours of operation

NP Number of functional pins

C1 Die complexity

C2 A constant based on the number of pins

Tπ Temperature coefficient

Eπ Environmental coefficient

Qπ Quality factor

Lπ Learning factor

4.1 ATMega3250 Microcontroller

Table 4.1.1 ATmega3250 Microcontroller Parameters

( ) LQETP CC ππππλ ×××+×= 21

Parameter Value Justification

C1 0.14 MOS 8-bit microcontroller

C2 0.052 NP = 100

Non-hermetic SMT1

Tπ 3.1 Digital MOS

TJ = 125 C° (max. operating temperature)

Eπ 4 Assumed GM, ground mobile environment

Qπ 10 Assumed commercial component

Lπ 1 Years in production > 2.0

1. C2 = 3.6 × ( ) 08.1410 PN−


A-19

Pλ 6.42 per 106 hrs

MTTF 155763 hrs ≈ 17.78 years

The ATmega3250 [6] was chosen as it is the main and most complex component of the design

and it may heat up during normal operation. The ATmega3250 is responsible for controlling

every aspect of the device. If the ATmega3250 fails, then the entire device will not function. No

additional assumptions were made for this component as all information was known or

researched from its data sheet [6].

4.2 UC2577-ADJ Step-Up Voltage Regulator

Table 4.2.1 UC2577-ADJ Step-Up Voltage Regulator Parameters



C1 0.01 Assumed to be linear and have 1 to 100

transistors.

C2 0.02 NP = 5

Non-hermetic DIP1

Tπ 58 Linear MOS





1. C2 = 3.6 × ( ) 08.1410 PN−


A-20

Pλ 6.6 per 106 hrs


The UC2577 Step-up voltage regulator [17] was chosen as it is the only source of power for the

whole device and is the most likely to be operating at higher temperatures. If this component

fails the entire device will not function.

The die complexity, C1, was assumed to be 0.01 based on the assumption that there are 1 to 101

transistors in the voltage regulator. This assumption is reasonable as the component is a simple

step up voltage regulator as can be seen from its datasheet. Everything else was known or

researched from its datasheet [6].

4.3 CFAH1602B Liquid crystal display (LCD)

Table 4.3.1 CFAH1602B LCD Parameters



C1 0.14 Assumed MOS 8-bit microcontroller

C2 0.0072 NP = 16

Non-hermetic DIP1

Tπ 0.29 CMOS





1. C2 = 3.6 × ( ) 08.1410 PN−

Pλ 0.694 per 106


A-21


The LCD [2] was chosen as it is one of the most complex components of the design and would

also be one of the most likely to fail during normal operation. A failure of the LCD would result

in the user being unable to program additional hand gestures and prevent the recognized

command from being displayed.

The LCD utilizes a LSI controller which takes in 8-bit instructions and so it is assumed to fall

under the 8-bit MOS microcontroller category. The die complexity C1 was then determined to be

0.14. Everything else was known or researched from its datasheet [ref LCD datasheet].

4.4 Conclusions

Table 4.4.1 Summary of Pλ and MTTF

Component Pλ MTTF (yrs)

ATmega3250

Microcontroller

6.24 17.78

UC2577-ADJ voltage

regulator

6.6 17.3

CFAH1602B LCD 0.694 164.5

Total 13.534 8.43

The total Pλ of the device, 1.353 510−× , is not an acceptable failure rate for a commercial device.

With just 74,000 Handy units sold, a failure rate of 1.353 510−× translates to a unit failing every

hour. Steps must be taken in the design process to ensure that the device has a better failure rate.

This will translate to savings in costs and increased customer satisfaction later on.

As can be seen, the voltage regulator is the component with the highest failure rate, followed by

the ATmega3250 microcontroller. The LCD and infrared sensors have much lower failure rates


A-22

and do not contribute significantly to the overall failure rate. To improve failure rates, the

individual failure rates of the ATmega3250 and the voltage regulator must be decreased.

Since the main cause of the high failure rates is high operating temperature, heat sinks can be

added to the ATmega3250 and the voltage regulator. Also, the system should be designed so that

each component is used efficiently. For example, the ATmega3250 can go into a power saving

mode after it has not detected any hand motion for five minutes. This will reduce the total

operating time and extend the life of the device.


A-23

6.0 Ethical and Environmental Impact Analysis Uncompleted by teammate.


A-24

7.0 Packaging Design Considerations

Handy is packaged in a white aluminum casing (of dimensions 31cm x 21cm x 7.5cm), with all

the components contained within so as to achieve a neat and aesthetically-pleasing look. The

infrared sensors are arranged in a 3 x 3 grid on the top face of the packaging, though the sensors

themselves will be placed inside the box. An infrared transmitter will be placed at the front face

of Handy, and will transmit the chosen command to the device being controlled. An LCD

display, together with an RPG with a built in pushbutton, allow the user to see what commands

are being sent, as well as aid in programming Handy.

There is a battery panel on the bottom face of the casing, and this slides open to reveal the

battery compartment, which is meant to take three AA batteries.

7.1 Comparison with Packaging of Other Commercial Products

7.1.1 Motion Processor by Toshiba

Fig 7.1.1 Photograph of Toshiba Motion Processor

The Motion Processor, as seen in Fig 7.1.1, is made of a lightweight and durable plastic. [17]

The casing is meant to be placed on a flat surface, and near a computer. There are eight LEDs

pointed in a fixed direction. There is a cable sticking out from the back of the device to interface

with the computer.


A-25

Positive Aspects of the Motion Processor

1. Lightweight.

2. Stable base.

Negative Aspects of the Motion Processor

1. The 8 LEDs are pointed in a fixed direction.

2. Interfaces with a computer via a cable. This means the unit must be placed near a computer.

7.1.2 Gyration Media Center Remote Control

The Media Centre Remote Control is manufactured using a lightweight and durable plastic. The

casing is rectangular in shape, as most remote controls are. There are 49 buttons arranged in an

intuitive manner, with a numerical keypad placed at the bottom, and 3 different sets of volume

up/down and play/pause/stop buttons above it. There is a Radio Frequency data transmitter and

an infrared transmitter encased within the remote. There is a battery panel on the bottom of the

remote control for 2 AA batteries [4].

Fig 7.1.2 Photograph of Gyration Media Center Remote Control

Positive Aspects of the Gyration Media Centre Remote Control

1. Extremely portable.


A-26

2. Durable plastic

3. Lightweight

4. Components neatly packaged within casing.

5. Infrared and Radio Frequency transmitters located at the front edge of the remote, pointing

straight ahead.

Negative Aspects of the Gyration Media Centre Remote Control

1. Too many buttons.

2. Buttons too close together.

3. Buttons exposed: may accidentally press buttons.

7.1.3 Aspects of Compared Products Incorporated into Handy

1. The body was made of a durable and lightweight material, namely aluminum.

2. The battery panel is located at Handy’s bottom plate.

3. The infrared transmitter points outwards from Handy.

7.1.4 Unique Aspects of Handy’s Packaging

1. Handy is packaged such that all the components are contained within the casing, leaving

only the minimum inputs (example an RPG and a power on/off button) exposed.

2. The LCD screen displays the command as it is sent to the hi-fi system.

7.2 Project Packaging Specifications

Handy is packaged in an aluminum casing (dimensions 31cm x 21cm x 7.5cm), with the 3 by 3

grid of infrared sensors on the top plate having dimensions of 28cm x 18cm. An LED is placed

next to each sensor, and emits light when the sensor is triggered.

The LCD screen (dimensions of 7cm x 2.7cm) and the RPG (diameter of 19.05mm) are located

at the bottom right of the top face, while the battery panel (dimensions of 4cm x 7cm) is located

at the bottom face.


A-27

Pictures of Handy’s final packaging are included in Appendix B. Due to space constraints, it was

decided that the LCD and RPG would be placed at the bottom right of the 3 x 3 sensor grid. This

was a sound decision, as it made the packaging less bulky without compromising the accuracy of

gesture recognition.

7.2.1 Materials List

Table 7.2.1 Table of Materials

Component Quantity Weight (kgs) Total Weight (kgs) Unit cost Total

cost

Microcontroller

& PCB

1 ~1 ~1 $7.00 $7.00

Infrared sensor 9 0.005 ~0.050 $6.00 $54.00

Infrared

transmitter

1 0.002 0.002 $2.50 $2.50

LCD screen 1 0.400 0.400 $24.04 $24.04

LED 10 0.001 0.010 $0.20 $2.00

RPG 1 0.300 0.300 $24.95 $24.95

Aluminum

casing

2 1.000 1.000 $15.00 $15.00

Glue 1 0.000 0.000 $2.00 $2.00

~2.762 $132.49

7.2.2 Tooling Requirements

Simple tools required to assemble Handy:

- Plastic epoxy/superglue/hot glue to mount components onto the casing

- Soldering equipment

- Wire strippers

- Cutting tools for the holes in the casing.


A-28

8.0 Schematic Design Considerations

This section discusses the considerations taken into account when creating the schematic. These

considerations are centered about the major components of Handy, namely the microcontroller,

sensors, power supply, LCD, rotary pulse generator and the feedback LEDs. The schematic is

available in Appendix C.

8.1 Microcontroller

The Atmel ATmega3250 [6] controls all the main components of Handy. The main components

consist of the sensors, user interface, and the infrared transmitters. The microcontroller also

handles power management of the whole device and all the LEDs that provide a visual interface

for the user. The operation of the microcontroller is discussed below.

Nine infrared sensors are connected to nine general purpose I/O pins of the microcontroller. The

microcontroller reads and processes the digital output of the infrared distance sensors, stores the

pattern of the hand movement above the sensors and then matches the recorded pattern to

prerecorded list of hand movement patterns. Once a match is found, the recognized command is

displayed on the LCD screen and the PWM channel provides a frequency modulated PWM

signal to the infrared transmitters, which results in an infrared signal being sent to the device..

One LED is connected to one I/O pin of the microcontroller for each of the nine infrared distance

sensors. Each LED is controlled directly by the microcontroller and will light up when the sensor

beside it detects hand movement. Also, these LEDs will be able to provide debugging support as

they are connected directly to the microcontroller.

The user interface consists of the LCD module and the optical encoder. A total of twelve general

purpose I/O pins are connected to the LCD module for the 8 bit parallel interface and various

control signals required. The microcontroller continuously polls the output pins of the optical

encoder. When the pushbutton is pressed, the LCD is activated by the chip enable signal and a

menu is displayed which allows the user to program individual hand gestures. The user scrolls

through the menu by turning the optical encoder and selects a menu item by pressing the

pushbutton.


A-29

The microcontroller also handles the power management of the device by having two modes of

operation: normal recognition mode and power-down sleep mode. In normal recognition mode,

hand gestures can be recognized and the user can access the menu through the LCD and optical

encoder. When the device is first switched on, it is by default in normal recognition mode. In

power-down sleep mode the microcontroller turns off the LCD and all LEDs and stops polling

the infrared distance sensors except for the bottom and middle infrared distance sensors in the

center. Once either one of the two sensors sense a hand movement, the microcontroller will wake

up and enter normal recognition mode. When both these infrared distance sensors sense the hand

at the same time, the microcontroller will start the recognition of the hand gesture. A hard master

on and off switch is provided that turns the device completely off and on.

Four decoupling capacitors are connected across all four of the microcontroller’s power supply

pin and ground pin pairs. The microcontroller has an internal calibrated oscillator and so an

external oscillator is not necessary. All unused general I/O pins are tied to headers to provide

expansion capability in case more distance sensors or other components need to be included in

the final design.

The operation of the various peripherals will be discussed in the sections below.

8.2 Sensors

Nine GP2Y0D340K sensors [1] are used to detect hand gestures. Once powered, the sensors

continually run at a sampling rate of 156.25 Hz. The sensor provides a digital output through

one output pin. The sensor provides an output high by default, and provides an output low upon

detection of an obstacle above it. The sensor has an obstacle detection range of 40 cm with a 1 Ω

resistor at pin 2 and a 15 cm detection range with a 3.9 Ω resistor at pin 2. The natural tendency

is to place the hand about 10 cm above the device. Since the detection range of 15 cm is

sufficient for detecting a human hand moving above it, 3.9 Ω resistors are used for all sensors. A

0.1uF decoupling capacitor [1] is connected between the sensor’s power rail and ground.

The infrared distance sensors are mounted on a three by three grid so that they are facing

vertically up and are able to detect hand motion immediately above it. Hand gesture recognition


A-30

is initiated when the hand is directly above the bottom and middle infrared distance sensors in

the center. A timer is started the moment the hand leaves these sensors and the time that the hand

moves over the other sensors is recorded. The microcontroller then compares the array recorded

with the preprogrammed gesture arrays to see if there is a match. If there is a match, the

microcontroller will look up the infrared command associated with it and output the command

with the PWM channel connected to the infrared transmitter. If there is no match, the device will

return to the normal recognition state to wait for the next hand gesture.

8.3 Power Supply

The approximate maximum output current that is needed for parts to work (with all devices in

active mode) is approximately 602 mA, as mentioned in Section 3.0, while the voltage that is

needed is 5 V. Three Alkaline 1.5 V AA batteries are used in series to provide a 4.5V power

supply to Handy. A Unitrode UC2577 Simple Step-Up Voltage Regulator [17] is used to provide

a constant 5 V power supply from the 4.5V supply provided.

The minimum current that the regulator can provide at these input voltage specifications is

calculated to be 1.344 A, which satisfies the maximum load current of 602 mA that was

calculated for the device. A master power switch will be used to turn Handy completely on and

off. Decoupling capacitors are connected between the 4.5 V power rail and ground rail and

between the 5 V output power rail and ground rail.

8.4 LCD

The Crystalfontz LCD CFAH1602B-TMC-JP [2] is used to display the user interface of Handy.

The display is controlled directly by the microcontroller in parallel mode. A 10 Ωk

potentiometer is used to control the contrast of the LCD (input at the V0 pin) and the backlight of

the LCD is connected to an output pin of the microcontroller. This allows the microcontroller to

switch off the back light whenever the device enters power-down sleep mode. The display

changes in accordance to the inputs of the optical encoder and the infrared distance sensors.

8.5 Rotary Pulse Generator


A-31

The Grayhill 61C22 Optical Encoder provides the only input used to control the user interface

displayed on the LCD. The purpose of the user interface is to display the commands that the

device has detected and to allow the user to customize the hand gestures that are associated with

each remote control command.

The optical encoder outputs its four possible positions using two output pins, and its push button

status using two pins, to the microcontroller. Each time a new position is sensed, or the

pushbutton is pressed, the microcontroller displays the appropriate navigation changes of the

user interface on the LCD. For Handy, a turn of the dial indicates a scroll action, and a press of

the pushbutton indicates a select action. Therefore the user can scroll up or down the menu

displayed by rotating the optical encoder anticlockwise and clockwise respectively. The user

selects a menu item by pressing on the pushbutton on the optical encoder. Two 3.3 k Ω pull-up

resistors are required for operation.

8.6 Feedback LEDs

A feedback LED lights up to provide an indication when an infrared distance sensor is triggered.

The feedback LEDs are low current LEDs that are sourced by general purpose I/O pins of the

microcontroller. A current limiting resistor of 1.2 Ωk is used for each LED. The LEDs are

directly connected to I/O pins of the microcontroller so that they can be used as a visual interface

that gives information to the user.


A-32

9.0 PCB Layout Design Considerations

To allow the minimization of packaging size, the components are placed onto a PCB of

dimensions 5.09 in by 4.72 in. Top and bottom copper of the PCB, along with the silkscreen

layer, is available in Appendix D for reference.

9.1 Overview of PCB Components

The layout of the PCB was organized by component functions. Components were grouped

together into different sections by virtue of similarity and function, and placed onto the PCB as

such:

1. UC2577 voltage regulator circuit.

The voltage regulator draws 4.5V from 3 AA batteries, and outputs a DC voltage of 5V.

2. Infrared sensors interface.

The infrared sensors will be interfaced to the microcontroller via headers.

3. Infrared transmitters interface.

The infrared transmitters will be interfaced to the microcontroller’s PWM via headers, and will

transmit commands to the sound system by pulsing infrared signals.

4. LED interface.

The LEDs will be interfaced to the microcontroller via headers.

5. LCD interface.

The LCD will be interfaced to the microcontroller via a header.

6. RPG.

The RPG will be interfaced to the microcontroller via a header.

7. ATmega3250 microcontroller.


A-33

The ATmega3250, and its associated decoupling capacitors.

8. Programming interface.

A 3 pin header for programming the microcontroller.

9. Debug jumper

Jumper for debugging purposes.

The components were placed onto the PCB according to their various characteristics. Handy’s

components are totally digital, and thus it was unnecessary to allocate a separate section of the

board for analog devices. There were, however, devices and circuits that had high current and/or

noisy characteristics. The UC2577 voltage regulator [16] circuit required high current, and was

also noisy in nature. It was thus placed on the top left corner of the PCB in order to isolate it

from the other components. The infrared transmitters required high current, and were placed at

the top of the board so as to have as minimal an impact on the other devices’ operation as

possible.

Headers were placed near the ATmega3250 microcontroller (one on each side), and traces were

run from all the IO pins to the headers. This was done so as to facilitate fly-wiring using the

unused IO pins, should there be a need to add more infrared sensors to achieve greater gesture-

sensing resolution.

The remaining components were placed onto the PCB according to their similarity, for example

the LED headers were placed next to each other on the right of the microcontroller. This gave the

PCB a measure of organization, which is important, especially at the time of board assembly and

soldering.

9.2 Design Process Considerations

There were various layout considerations that had to be taken into account during the design

process of the PCB. The following considerations were based on “rule of thumb” PCB design

guidelines and the Motorola App Note AN1259 document [19], [20].


A-34

1. Electrical clearances.

Although the PCB was designed to be as small as possible, electrical clearances must be taken

into consideration. Tight clearances between tracks and pads would cause etching problems after

PCB production. Hence, a sufficient minimum spacing of 0.11 mm between the tracks and pads

were enforced during the design.

2. Mixing of Digital and Analog Devices

Handy is purely digital and does not use any analog device. Hence, this was not a problem

during PCB design.

3. Minimization of Net Lengths

The net lengths were minimized to reduce unwanted effects caused by the increase resistance,

capacitance and inductance due to longer nets. The constraint of requiring as small a PCB as

possible helped enforce this consideration.

4. Power and Ground Rails

The power and ground rails were consistently routed close to each other, in the same direction

and in parallel. This reduces the loop inductance and allows for effective bypassing. Also, the

Power and Ground traces were made to be wider than other traces, and used a width of 60.

5. Hole and Vias Sizes

Hole sizes of the PCB was kept constant, as varying sizes increase cost of production, which is

an important overall consideration of the project. The vias and pad sizes were also pegged to the

hole size, so that the vias would be mechanically reliable.

9.3 Summary

As Handy is a relatively less complex project in terms of hardware, the PCB design and its

considerations are subsequently less complex. This section has covered the various design

considerations involved in creating a PCB for Handy, which included a run through of the major

components in relation to PCB layout. The considerations, based on PCB design conventions,


A-35

involved during the actual design of the PCB have also been covered. In conclusion, the PCB

design for Handy has been a success, with all considerations and criteria having been met.


A-36

10.0 Software Design Considerations

A large part of Handy’s success lies in its software design. The core functionality of the project

– hand gesture recognition and transmission of infrared signals – relies on the software

processing of very basic data gathered by the hardware.

The software development of Handy was done in the CodeVision AVR IDE. Development work

was done in C, as opposed to assembly, as it was quicker and more convenient alternative.

Precautions were taken to streamline the code to be as efficient as possible due to the use of a

higher-level programming language.

This section will discuss the software design considerations involved in creating hand gesture

recognition functions, a user interface and the transmission of infrared signals to a commercial

device. The software-level interaction between Handy’s Atmel ATMega 3250 microprocessor,

the infrared sensors, rotary pulse generator, LCD panel, and the infrared transmitter, will be

covered as well.

10.2 Design Considerations

10.2.1 Memory Mapping

The Atmel ATMega 3250 contains 32Kb of flash memory, 1Kb of EEPROM and 2Kb of SRAM

[6]. All startup code and assembly-level initializations were handled by CodeWizard AVR [18].

They were preset by the wizard and could not be changed.

Ports, timers, and interrupt initializations were done manually by referring to CodeVision AVR’s

help file [18] and the Atmel ATMega3250 datasheet [6]. These initializations include the

initializations of data-direction registers, pull-up resistors, output compare, clock pre-scalers,

interrupt masks, etc. Details of these initializations can be seen in Appendix F.


A-37

The entire program resides in the flash memory, and only utilizes 5.570 KB (using address space

0x0000 to 0x15C3, out of 0x7FFF of flash memory) [6]. This still leaves more sufficient space

for the boot loader code.

The SRAM of the microcontroller resides between the address 0x0100 and 0x08FF of the data

memory. Memory addresses before 0x0100 are used for registers. [1] Of the 2KB of available

SRAM, 1KB is allocated for the data stack. 1KB is more that sufficient to cover the local

variables, including those of hand gesture arrays (five 3x3 arrays of integers), and global

variables. This leaves a maximum of 1KB for the call stack, which is sufficient as well.

Handy’s code has a maximum function call depth of five. In addition, most of the functions are

relatively small in size and do not push much data onto the call stack. Lastly, the code does not

use any dynamic memory allocation, and hence the heap size of the SRAM is set to 0Kb.

The EEPROM of the microcontroller is used mainly to store user defined hand gestures for each

command. The EEPROM retains data even after power down, making it especially useful in

“saving” user data. Five hand gestures (3x3 array of integers) will be stored in the EEPROM,

totaling to 180 bytes. Hence, the 1Kb of EEPROM will be more than sufficient, with enough

space available for miscellaneous use. Details of all memory usage can be seen in Fig 10.2.1, a

screenshot of CodeVision AVR’s post-compilation report.


A-38

Fig 10.2.1 Screenshot of Post-Compilation Report

10.2.2 External Interfaces Mapping

The input ports used are accessed by an interface provided by CodeVisionAVR [18]. This

interface allows reading and writing to port addresses by just referencing the port name and pin

number (eg. PORTB.0 = 1). The port mappings to external devices are provided in Table 10.2.1.

Table 10.2.1 Device Port Mapping

Device Port/Pin (in order of device number if more than one device)

Infrared Sensors G0, E0, G1, C4, E1, C5, C6, F0, F1

Indicator LEDs J0-J6, H0-H1

Infrared Transmitters B4-B6

LCD A0-A7, C0-C2


A-39

RPG D2, D4, D5

10.2.3 Integrated Peripherals

The 8-bit timer channel 0 is used in the main loop to time ten seconds of inactivity before the

microcontroller goes into sleep mode. It is programmed to “pulse” every 0.01 seconds. The

generated interrupt increases a counter that is continually polled by the program’s normal

operation until twenty seconds have passed.

The sleep mode used is the microcontroller’s “Power-down Mode”. This mode leaves only the

asynchronous interrupt pins enabled. The microcontroller wakes up upon a pin change interrupt

as detected by the enabled interrupt pins.

Based on a 16 MHz clock, the operating modes and registers of timer channel 0 are initialized as

follows:

Clock Source: System Clock

Timer Prescaler: 1024

Mode: Clear Timer on Compare Match (CTC)

Output Compare: Enabled

Interrupt On: Compare Match

Compare Value: 125

These values are derived as follows:

Pre-scaled clock frequency: 16 MHz / 1024 / 2 = 7812.5 Hz

Time elapsed when timer counter has reached compare value (125):

125 * 1 second/15625 Hz = ~ 0.01 seconds

The 8-bit timer channel 0 is used again in PWM mode to generate the carrier frequency for the

infrared transmission of the commands. The infrared commands require a 38 KHz carrier

frequency with a 50% duty cycle. This requires a port pin toggle every:

(1/38 KHz) / 2 = 13.16 microseconds


A-40


follows:


Timer Prescaler: None


Output Compare: Enabled, toggle Output Compare pin on match

Interrupt On: None

Compare Value: 102


Pre-scaled clock frequency: 16 MHz / 2 = 8 MHz


102 * 1 second/8 MHz = 12.75 microseconds

This is the closest possible generated value to the required 13.16 microseconds. The resultant

carrier frequency at this value, when measured with the oscilloscope, is 38.46 KHz.

Transmission codes transmitted at this frequency do prove to work after testing.

The 8-bit timer channel 2 is to create a unique signature for each distinct hand gesture. It is

programmed to “pulse” every 31 microseconds and increment a counter once the activation

sensors are triggered. Each time another sensor is triggered, the value of the counter is stored in

its corresponding element in the hand gesture array. The value of 31 microseconds was

determined experimentally, as it provided the best resolution for recognition, and it worked the

best.


follows:


Timer Prescaler: 8



A-41



Compare Value: 31


Pre-scaled clock frequency: 16 MHz / 8 / 2 = 1 MHz


31 * 1 second/1 MHz = 31 microseconds

The 8-bit timer channel 2 is again used to create a delay function that accurately creates delays

for multiples of 200 microseconds. This delay function is used by the infrared transmission

functions. The timer is programmed to “pulse” every 200 microseconds. The generated

interrupt increases a counter that is continually polled until a delay specified by the input

multiple has passed.


follows:


Timer Prescaler: 32




Compare Value: 50


Pre-scaled clock frequency: 16 MHz / 32 / 2 = 250 KHz


50 * 1 second/250 KHz = 0.0002 seconds

The Watchdog timer of the ATMega3250 is also used for general delay functions (eg. for

debouncing). However, the Watchdog timer is not explicitly invoked by the code, and is instead

used by CodeVisionAVR’s delay functions API – delay_us() and delay_ms().


A-42

10.2.4 Application Code Organization

The entire application is a polling loop. The main polling loop will constantly poll the input of

the RPG and activation sensors, in order to determine whether to go into user interface mode or

begin recognizing hand gestures. Depending on which branch is taken, corresponding functions

will run, and the program will eventually return to the polling loop. Refer to Appendix H for the

flowchart of the main program.

The main subcomponent of hand gesture recognition also uses a polling loop to read the inputs of

the nine infrared sensors. A polling loop structure was selected for the following reasons:

1) The polling loop runs at a frequency close to the microprocessor’s 16 MHz clock speed.

This is significantly faster than the sampling rate of the sensors and there is an extremely low

possibility of missing part of the gesture.

2) A polling loop allows the program to know exactly which sensor has been detected so as

to store that specific time in the sensor’s corresponding element in a gesture array.

A polling loop structure was chosen over an interrupt-driven structure as each of the nine sensors

must be distinctly read. An interrupt-driven structure would not allow an easy implementation of

this, as inputs tied to an external interrupts are only able to be processed one at a time.

10.2.5 Debugging

Handy will not have any explicit debugging mode. However, the individual functions of Handy

will be testable through the user interface. The following provisions for testing will be made:

1) Manual testing of infrared transmission can be tested manually without the need of

recognizing a hand gesture.

2) Use of the feedback LED as diagnostic of the status of each infrared sensor.

10.3 Software Design Narrative

The hierarchical arrangement of code modules is provided in Appendix I.

void main ()


A-43

This module contains the main polling loop of the program. The loop polls the RPG and

activation sensor inputs and subsequently branches into UserInterface() or RecognizeGesture(),

depending on the triggered inputs. In addition, the module checks a counter, maintained by the

timer0 interrupt service routine, to count ten seconds of idle time before powering down to sleep

mode, as described in Section 10.2.3. More detail on the function’s operation can be seen in the

flowchart in Appendix A.

void UserInterface()

This is the umbrella module of the user interface. It reads in the RPG input and displays the

corresponding user interface elements on the LCD, and endlessly loops until Handy enters sleep

mode. The module provides access to the following functionality:

1) Recording of custom hand gestures for each sound system command, followed by the storage

of the gesture into the EEPROM.

2) Manual transmission of infrared commands.

void RecordGesture (unsigned int InMatrix[3][3])

This is the module that records hand gestures. The module is called once main() detects that the

activation sensors have been triggered. It contains the sensor polling loop and records the

gesture into the array specified by the input argument. The module starts the timer channel for

the counter once the hand has left an activation sensor for another sensor. Each time a sensor is

triggered, the value of the counter is stored in the appropriate element in the hand gesture array, a

3x3 array of integers provided as the input argument. This action is looped until all the sensors

detect nothing above them.

unsigned char MatchGestureLib (unsigned int InMatrix[3][3])

This module matches hand gestures to pre-recorded gestures in the library. The module takes a

hand gesture array input and loops over the library of sound system commands stored in the

EEPROM. Upon a match, the associated infrared command will be transmitted, along with an

output to the LCD stating the transmitted command. If the input gesture array does not match

any library gesture, the LCD will display an error message indicating that the gesture is


A-44

unrecognized. For diagnostic purposes, if there is a match, the module will return a 1. A 0 will

be returned if otherwise.

void SleepProcess()

This module performs the necessary procedures to put Handy to sleep. It enables the external

interrupts, resets the sleep counter and disables the sleep timer before actually powering down

the microprocessor. Upon waking up, the microcontroller will resume at the last point in code,

which is still the module. The module then disables external interrupts and restarts the sleep

timer.

Burst Functions – void Burst_Play(), void Burst_Fwd(), etc

Each of these commands will set the PWM and output the bit pattern of the corresponding

infrared code. They consists of the Burst_Logical1() and Burst_Logical0() submodules in

different arrangements to achieve the desired pattern.

interrupt [TIM0_COMP] void timer0_comp_isr()

This interrupt service routine services the timer channel 0 interrupt. It increases the

Sleep_Counter global variable during each output compare match. Sleep_Counter is used as a

countdown timer to sleep mode. More usage details of timer channel 0 and this interrupt is

described in Section 10.2.3.

interrupt [TIM2_COMP] void timer2_compa_isr(void)

This interrupt service routine services the timer channel 2 interrupt. It increases the

Delay_Counter global variable during each output compare match. The routine is used by both

the infrared transmission and gesture recording modules, and is initialized differently by each set

of modules. More usage details of timer channel 2 and this interrupt is described in Section

10.2.3.

interrupt [PCINT0] void pin_change_isr0(void)

This interrupt service routine is called in response to a change in the external interrupt port

during the microcontroller’s sleep mode. It is tied to the activation sensors, which would start up


A-45

the microcontroller when triggered. Details of the interrupt’s initialization can be seen in

Appendix F.

10.4 Summary

Handy is a very software-centric device, and numerous considerations had to be taken during its

software design phase. The Atmel ATMega3250 is a small microcontroller with limited

resources. Hence, the memory usage of the application, in relation to the microcontroller’s

memory map and constraints, has to be carefully evaluated. In addition, the application calls on

various microcontroller peripherals, which have to be initialized appropriately. These

peripherals include timer channels, pulse width modulation, Watchdog timer, and wake-up on

interrupt. Lastly, a polling loop application structure was selected due to its benefits over an

interrupt driven structure. Descriptions of the core modules of the application were discussed in

the software narrative.


A-46

11.0 Version 2 Changes

As this is the first ever version of Handy, there is definitely a list of improvements for the second

version. These improvements have been broken down into three categories – hardware, software

and packaging.

11.1 Hardware Improvements

1. Select a cheaper, more efficient microcontroller.

2. Rework component selection and power consumption to allow use of smaller batteries.

3. Use physically smaller passive components (eg. power regulators, inductors, capacitors)

to reduce the required interior space of the packaging.

4. Reduce (if possible, eliminate) the use of headers and connectors, to reduce the required

interior space of the packaging. This can be achieved through enlarging the PCB to fit

the packaging and mounting the components directly onto the board.

5. Add two more IR transmitters on the left and right sides to allow Handy to transmit

commands from all sides.

6. Add transistor-based switches for all components to allow power down via software.

11.2 Software Improvements

1. Create an improved, more intuitive user interface.

2. Improve recognition algorithm through more formal testing.

3. Allow a user interface option to transmit infrared commands via of one or more of the

infrared transmitters.

4. Add additional functionality to sleep mode by switching off other components with the

assistance of transistor-based switches.

5. Expand IR command code support to include more devices. Aim to be a universal

remote in the future.

11.3 Packaging Improvements

1. Make the packaging as slim as possible.

2. Use a lighter plastic casing.


A-47

3. Place transparent covers over sensors.

4. Use more aesthetically pleasing RPG knob and switch.

5. Improve overall look (“coolness” factor) of the product.


A-48

12.0 Summary and Conclusions

In conclusion, Handy was a success. The project fulfilled all five project-specific success

criteria. It proved to be a challenging project for the team, and many invaluable lessons and

skills were picked up by everyone along the way.

The development of Handy required us to be fluent in two main areas – programming the

microcontroller and the PCB.

We had to know the various methods, techniques and considerations when programming the

ATmega3250. This was particularly important as we had to develop efficient software, in

addition to interfacing with many other devices.

All aspects in the creation PCB were extremely important, as having a proper PCB was vital to

the functionality of the project. We had no prior experience in working with PCBs. Hence,

creating the layout, routing the traces, and populating the board via soldering were new to us. At

the end of the project, we have learnt to be competent in the creation of PCBs.

There was the problem of the lack of availability of infrared command codes online, regardless

of the choice of sound system. This ultimately led us to reverse engineer the Bose SoundDock’s

signals by reading the remote control’s output using a combination of an IR receiver and an

oscilloscope.

Handy is a very software-centric product. A well written hand gesture recognition algorithm,

determines the success of the project. The algorithm was tested with a number of gestures we

felt most users would try to program it to recognize. As long as Handy had no problem

processing those gestures, the algorithm was deemed to work. Hence, the algorithm went

through countless number of tweaks and revisions after its initial iteration was written.

Handy proved to be a successful prototype. However, through the development of the product,

we have no doubt made a list of improvements that would go into a second version should it


A-49

arise. These improvements include, but are not limited to, a much slimmer design, wider

transmission range, and turning it into a universal remote. Most of the improvements aim to

increase the practicality and aesthetic appeal of Handy.


A-50

13.0 References

[1] Sharp Electronics Components Group, GP2Y0D340K Compact Distance Sensor Datasheet,

undated, http://info.hobbyengineering.com/specs/SHARP-gp2y0d340_j.pdf

[2] Crystalfontz, CFAH1602B-TMC-JP LCD Datasheet, undated,

http://www.crystalfontz.com/products/1602b-color/CFAH1602BTMCJP.pdf

[3] Grayhill, 61C22 Optical Encoder Datasheet, undated,

http://embrace.grayhill.com/embrace/IMAGE S/PDF/I-21-22.pdf

[4] Gyration, Gyration Media Center Remote Website, 2006,

http://www.gyration.com/en-

US/ProductDetail.html?modelnum=GP2000001&accshow=3

[5] Freescale Semiconductor, HCS12 Family Datasheet, March 2006,

http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S12C128V1.pdf

[6] Atmel, ATmega3250 Datasheet, April 2006,

http://www.atmel.com/dyn/resources/prod_documents/doc2570.pdf

[7] Jameco, 40 Khz Ultrasonic Sensor Set Datasheet, undated,

http://www.jameco.com/wcsstore/Jameco/Products/ProdDS/139491.PDF

[8] US Patent and Trademark Office, “USPTO Full-Text Database Boolean Search”,

2006, http://patft1.uspto.gov/netahtml/PTO/search-bool.html

[9] R. Iwamura, “Motion Sensing Interface,”

USPTO Ed. USA: Sony Corporation (Tokyo, JP); Sony Electronics Inc. (Park Ridge,

NJ), 1998, [Available online] http://patft.uspto.gov/netacgi/nph-


A-51

Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&

f=G&l=50&s1=6498628.WKU.&OS=PN/6498628&RS=PN/6498628

[10] W. T. Freeman and C. D. Weissman, “Hand Gesture Machine Control System,”

USPTO Ed. USA: Mitsubishi Electric Information Technology Center America Inc,

1995, [Available online] http://patft.uspto.gov/netacgi/nph-



[11] J. Lu, “Remote control device with motion-based control of receiver volume, channel

selection or other parameters,” USPTO Ed. USA: Koninklijke Philips Electronics N.V.,

1999, [Available online] http://patft.uspto.gov/netacgi/nph-



[12] The Biojudiciary Project, “Literal Infringement,” 2006, [Available online]

http://www.biojudiciary.org/subpage1.asp?tid=159

[13] The Biojudiciary Project, “Infringement under the Doctrine of Equivalents,” 2006,

[Available online] http://www.biojudiciary.org/subpage1.asp?tid=160

[14] Reliability Prediction of Electronic Equipment, MIL-HDBK-217F

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2006/Mil-Hdbk-217F.pdf

[15] George Novacek, Designing for Reliability, Maintainability, and Safety

http://shay.ecn.purdue.edu/~dsml/ece477/N otes/PDF/4-Mod13_ref.pdf

[16] Unitrode, UC2577-ADJ Simple Step-Up Voltage Regulators Datasheet, 2006,

http://www-s.ti.com/sc/ds/uc2577-adj.pdf


A-52

[17] Toshiba, “Toshiba's Motion Processor Recognizes Gestures in Real Time- Basis for

Future Generation of Natural Interfaces between People and Computers”, July 15, 1998,

http://www.toshiba.com/news/980715.htm

[18] HP Infotech s.r.l, “CodeWizardAVR v1.24.8 Automatic Program Generator”, 2006

[19] D. L. Jones, “PCB Design Tutorial,” June 2004, [Available Online]

http://alternatezone.com/electronics/files/PCBDesignTutorialRevA.pdf

[20] M. Glenewinkel, “System Design and Layout Techniques for Noise Reduction in MCU-

Based Systems,” Motorola, Inc., 1995, [Available Online]

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2006/AN1259.pdf


A-53

Appendix A: Individual Contributions

A.1 Contributions of Zaizhuang Cheng: o Team leader

o In charge of keeping the team on track to meet all the deadlines.

o Researched and choose the parts required for power supply, infrared distance sensors and

the infrared receivers.

o Heavily involved in the design of the schematic and printed circuit board.

o Designed footprint for UC2577 step-up voltage regulator.

o Redesigned the layout of the power supply on the printed circuit board.

o Finalized the printed circuit board design with Colin before the final submission.

o Reverse engineered infrared codes used to control the Bose SoundDock and a Sony car

sound system.

o Tested printed circuit board to ensure that all connections were correct.

o Tested power supply on printed circuit board after the components were soldered in.

o Assisted Derrick in debugging the PWM function of the development board.

o Debugged the microcontroller and found out that we needed to add an external crystal to

program it.

o Tested all nine infrared distance sensors before soldering their headers onto the printed

circuit board.

o Made the connectors required for the infrared distance sensors, LCD, optical encoder and

the LEDs.

o Penciled in the required holes needed to be cut into the aluminum box so that it could be

sent down to the machine shop.

o Spray painted the aluminum box.

o Tested and debugged the recognition function of the device.

o Hand model for the project specific success criteria video presentation.

A.2 Contributions of Derrick Ko: o In charge of the all software related aspects of Handy


A-54

o Researched and short listed possible microcontrollers. o Researched various integrated development environments for the Atmel ATMega series.

Made the decision to use CodeVision AVR. o Mapped all port connections of the microcontroller for the schematic, taking into account

the microcontroller’s current sinking and sourcing limits. o Ordered components and kept track of team’s purchases. o Assisted Colin in PCB layout. o Designed, prototyped, developed and tested the hand gesture recording algorithm. o Designed, prototyped, developed and tested the hand gesture matching algorithm. o Designed, prototyped, developed and tested the infrared transmission algorithm. o Looked into various methods of interfacing with the LCD. Made the decision to use

CodeVision AVR’s built-in LCD APIs. o Designed, prototyped, developed and tested the user interface. o Tested, via test code, each individual peripheral’s interaction with the microcontroller. o Mounted the sensors and LEDs to the casing. o Connected the peripherals from the casing to the PCB.

o Filmed and edited the project specific success criteria video presentation

o Compiled final report.

A.3 Contributions of Colin Tan: o In charge of packaging and PCB.

o Came up with the project idea, i.e. gesture-driven remote control.

o Did the Orcad schematic layout.

o Chose component footprints.

o Decided on the PCB layout.

o Chose trace width of Power and Ground rails, as well as normal traces.

o Routed all the traces on the PCB.

o Worked thru and eliminated PCB errors one by one.

o Finalized and submitted PCB design together with Zhuang.

o Tested functionality and range of the infrared sensors.

o Assisted Zhuang in reverse engineering the IR codes.


A-55

o Ohmed out traces on the PCB to ensure that the traces were sound.

o Soldered and de-soldered 4 microcontrollers in the span of one week.

o Populated the board. Soldered headers, capacitors, an inductor and resistors.

o Soldered headers onto the various components.

o Crimped connectors onto connecting wires to link components to the PCB.

o Worked with Derrick to fix components to the inner face of the packaging.

o Assisted Zhuang in painting the packaging.

o Drilled hole for the RPG knob to pass through.

o Soldered connecting wires to join the components to the PCB.

o Directed the project specific success criteria video.

o Worked with Zhuang and Derrick on the final report and assorted documentation.

A.4 Contributions of Naga Setiwan: Unavailable


B-1

Appendix B: Packaging Fig B-1 Top View of Packaging

Fig B-2 Bottom View of Packaging

IR Sensors

LED

LCD

RPG

Battery Pack


B-2

Fig B-3 Back Side View of Packaging

Fig B-4 Front Side View of Packaging

On/Off Switch

IR Transmitter LED


C-1

Appendix C: Schematic Fig C-1 Schematic of Power Supply Circuit

COMP1

FB2 GND

3

SW4

V IN5

Z1

UC2577ADJ/TOC3

2200uF

L1

47uH

R53.09 kohm

R7

1.5 kohm

R41 kohm

Vcc12J19SWITCH

C10.1uF

GND

Power/GND

12

J3

BATTERY

C20.47uF

GND

D1

1N5817

Fig C-2 Schematic of Programming Headers and IR Transmitters

PB1PB2PB3

GND

12 IR 1

GNDPB4

PB512 IR 2

GND

12 IR 3PB6

GNDPG5

123

J13

PROGRAMMING HEADER

R20150 ohms

R18150 ohms

R19150 ohms

IR Transmitters

12

J21

RESET HEADER


C-2

Fig C-3 Schematic of User Interface Components

R2485 ohms

12345678910111213141516

J2

LCD Header

PA7PA6

PC1PC0

PC2

GND

GND

PA1PA0

PA3PA2

PA4PA5

123456

J1

RPG

PD2

PD4Vcc

GND

PD5

Vcc

R33.3kohm

R23.3kohm

Vcc

LCD Header

PC3

R2310 kohm POT

Vcc

GND

Fig C-4 Schematic of Feedback LEDs

12 J4

LED 1

12 J12

LED 9

PJ0GND

12 J5

LED 2

12 J 6

LED 3

LEDs

12

J8

LED 5

12 J7

LED 4

12 J9

LED 6

R81.2 kohms

12 J11

LED 8

PJ1GND

R91.2 kohms

PJ2GND

R101.2 kohms

12 J10

LED 7

PJ3GND

R111.2 kohms

PJ4GND

R121.2 kohms

PJ5GND

R131.2 kohms

PJ6GND

R141.2 kohms

PH0GND

R151.2 kohms

PH1GND

R161.2 kohms


C-3

Fig C-5 Schematic of IR Sensors

GND

R3110 ohms

R26

10 ohmsGND

PG1 PC5

12345

Sensor 4

C71 uF

GNDGND

Vcc

PC4

12345

Sensor 5

C81 uF

GNDGND

Vcc

PE1

R27

10 ohms

GNDGND

GND

12345

Sensor 6

C91 uF

Vcc

PF1

12345

Sensor 7

C101 uF

GNDGND

Vcc

PC6

12345

Sensor 8

C111 uF

GNDGND

Vcc

PF0

GNDGND

12345

Sensor 9

C121 uF

Vcc

12345

Sensor 1

C41 uF

GNDGND

Vcc

PG0

12345

Sensor 2

GND

C51 uF

GND

Vcc

PE0

GND

GND

12345

Sensor 3

R3210 ohms

C61 uF

GND

Vcc

R2810 ohms

GND

R25

10 ohmsGND

GND

R3310 ohms

R2910 ohms

GND

GND

R3010 ohms

Fig C-6 Schematic of Microcontroller Port Headers

2468

1012141618

1357911131517

J17

mcright

PB7PG4PJ2PJ4

PD3

PJ6

PD7PD5

PD1

PG0PG1

PG2

PC0

PC4PC3PC1

PC2

PC7 PC6

PJ0PC5PJ1

PE0

PE4 PE3PE1PE2

PE7PE6 PE5

PB3PB2

PB5PB4PB6

PB1PB0

PH3 PH2

PH5PH4

PH7PH6

PH1 PH0PF3

PF2

PF5PF4

PF7PF6

PF1PF0

135791113151719

2468

101214161820

J18

mctop

2468

10121416

13579111315

J16

mclef t

2468

1012141618

1357911131517

J15

mcbottom

PA0

PA4PA3

PA1 PA2

PA7PA6PA5

PJ5PJ3

PD4PD2PD0

PD6

PG5PG3


C-4

Fig C-7 Schematic of Microcontroller Connections

PG0

PG4PG3

PG1PG2

Vcc

PC0

PC4PC3

PC1PC2

PC7PC6PC5

PB3PB2

PB5PB4

PB7PB6

PB1PB0

PH2

PH4PH3

PH6PH5

PH0

PH7

PH1

PD3PD2

PD5PD4

PD7PD6

PD1PD0

PA0

Vcc

Vcc

C130.1 uF

PA3

Vcc

C140.1 uF

PA4

PA2

GND

C150.1 uF

PA1

C160.1 uF

GND

PC558

XTAL2(TOSC2)33

XTAL1(TOSC1)34

PC668

(MOSI/PCINT10)PB221

(MISO/PCINT11)PB322

(OC0A/PCINT12)PB423

(OC1A/PCINT13)PB524

GND32 VCC

10

PC053

PC154

PC255

PA474

PA573

PA672

PA771

(ADC0)PF097

PA375

PC769

PC457 PC356

PG5(RESET)30

(SS/PCINT8)PB019

(SCK/PCINT9)PB120

(OC1B/PCINT14)PB625

(OC2A/PCINT15)PB726

PA078

PA177

PA276

(TCK/ADC4)PF493

(TMS/ADC5)PF592

PE7(CLKO/PCINT7)9 PE6(DO/PCINT6)8 PE5(DI/SDA/PCINT5)7 PE4(USCK/SCL/PCINT4)6 PE3(AIN1/PCINT3)5 PE2(XCK/AIN0/PCINT2)4 PE1(TXD/PCINT1)3 PE0(RXD/PCINT0)2

PG270 PG152 PG051

PD750PD649PD548PD447PD346PD245(INT0)PD144(ICP1)PD043

GND81

AGND99

VCC31

AVCC100AREF98

DNC1

PG4(T0)29 PG3(T1)28

(ADC1)PF196

(ADC2)PF295

(ADC3)PF394

(TDO/ADC6)PF691

(TDI/ADC7)PF790

(PCINT16)PH063

(PCINT17)PH164

(PCINT18)PH265

(PCINT19)PH366

(PCINT20)PH484

(PCINT21)PH585

(PCINT22)PH686

(PCINT23)PH787

PJ0(PCINT24)13

PJ1(PCINT25)14

PJ2(PCINT26)37

PJ3(PCINT27)38

PJ4(PCINT28)39

PJ5(PCINT29)40

PJ6(PCINT30)41

GND11

VCC80

DNC12

DNC15

DNC16

DNC17

DNC18

DNC27

DNC35

DNC36

DNC42

DNC59

DNC60

DNC61

DNC62

DNC67

DNC79

DNC82

DNC83

DNC88 DNC89

IC2

ATmega3250

PG5

GND

Microcontroller

PJ3

PJ0

PJ2

PJ4PJ5

PJ1

PE0

PE4PE3

PE1PE2

PE7PE6PE5

PF2

PF4PF3

PF6PF5

PF0

PF7

PF1

PA7PA6PA5

PJ6

GND


D-1

Appendix D: PCB Layout Top and Bottom Copper

Fig D-1 PCB Layout Top Copper with Silkscreen


D-2

Fig D-1 PCB Layout Bottom Copper with Silkscreen


E-1

Appendix E: Parts List Spreadsheet Table E-1 Parts List Spreadsheet

Vendor Manufacturer Part No. Description Unit Cost Qty Total Cost

Digi-Key Atmel ATmega 3250 16-bit microcontroller $7.25 1 $7.25

Junon.org Sharp GP2Y0D340K Distance measuring sensor $6.00 9 $54.00

Rentron Vishay TSHF5400 High Powered IR Emitting Diode $1.35 1 $1.35

Newark Grayhill 61C Optical Encoder (RPG) $24.95 1 $24.95

Crystalfontz Crystalfontz CFAH1602B-TMC-JP LCD Display $16.14 1 $16.14

Junun.org Fairchild HLMP-1700 Low Current LEDs $2.00 10 $2.00

TOTAL $105.69


F-1

Appendix F: Software Listing /***************************************************** This program was produced by the CodeWizardAVR V1.24.8d Standard Automatic Program Generator © Copyright 1998-2006 Pavel Haiduc, HP InfoTech s.r.l. http://www.hpinfotech.com Project : Handy Version : Date : 4/20/2006 Author : Derrick Ko Company : Purdue University Comments: Chip type : ATmega3250 Program type : Application Clock frequency : 16.000000 MHz Memory model : Small External SRAM size : 0 Data Stack size : 512 *****************************************************/ /* This code provides all functionality of Handy: - user interface - hand gesture recording - hand gesture recognition - hand gesture programmability - transmission of IR commands */ #include <mega3250.h> #include <delay.h> #include <sleep.h> // required for power down mode // LCD API includes #asm .equ __lcd_port=0x02 //porta #endasm #include <lcd.h> // end LCD API includes /* * * DEFINITIONS * */ // USER INTERFACE #define RPG_A PIND.5 #define RPG_B PIND.4 #define RPG_BUTTON PIND.2 #define LCD_BACKLIGHT PORTC.3 #define LCD_BACKLIGHT_DDR DDRC.3 #define DEF_FUNC_ID 255 // SENSORS #define TOLERANCE 0.55


F-2

#define MAX_INT_VAL 65535 #define SENSOR_0 PING.0 #define SENSOR_1 PINE.0 #define SENSOR_2 PING.1 #define SENSOR_3 PINC.4 #define SENSOR_4 PINE.1 #define SENSOR_5 PINC.5 #define SENSOR_6 PINC.6 #define SENSOR_7 PINF.0 #define SENSOR_8 PINF.1 #define SENSOR_0_PORT PORTG.0 #define SENSOR_1_PORT PORTE.0 #define SENSOR_2_PORT PORTG.1 #define SENSOR_3_PORT PORTC.4 #define SENSOR_4_PORT PORTE.1 #define SENSOR_5_PORT PORTC.5 #define SENSOR_6_PORT PORTC.6 #define SENSOR_7_PORT PORTF.0 #define SENSOR_8_PORT PORTF.1 #define DDR_SENSOR_0 DDRG.0 #define DDR_SENSOR_1 DDRE.0 #define DDR_SENSOR_2 DDRG.1 #define DDR_SENSOR_3 DDRC.4 #define DDR_SENSOR_4 DDRE.1 #define DDR_SENSOR_5 DDRC.5 #define DDR_SENSOR_6 DDRC.6 #define DDR_SENSOR_7 DDRF.0 #define DDR_SENSOR_8 DDRF.1 // POWER MANAGEMENT #define SLEEP_TIMEOUT 10 // in seconds #define MAX_SLEEP 600 /* * END * DEFINITIONS * */ /* * * GLOBAL VARS * */ // USER INTERFACE unsigned char Menu_ID = 0; unsigned char Menu_Sel = 2;//maintains which item in menu is selected unsigned char Menu_Max_Sel = 0; //max val that can be selected in a menu unsigned char Old_Menu_Sel =0; unsigned char Menu_New_ID = 0; unsigned char Menu_Func_ID = 0; unsigned char Menu_Func_Mode = 0; /* id:description


F-3

0: default (no action) 1: back to main -- 2-6 program 2: play 3: volup 4: voldown 5: next 6: back 7: off -- 8-12 send command 8: play 9: volup 10: voldown 11: next 12: back 13: off 14: reset */ // IR TRANSMISSION unsigned int Delay_Counter = 0; // SENSORS eeprom unsigned int GestureLibrary[6][3][3]; // POWER MANAGEMENT unsigned int Sleep_Counter = 0; /* * END * GLOBAL VARS * */ /* * * FUNCTION PROTOTYPES * */ // USER INTERFACE void UserInterface(); void MainSwitchBox(); void UpdateMenuSel(unsigned char); void MainMenu(); void CustomizeMenu(); void SendMenu(); void ProcessFuncID(); // IR TRANSMISSION void Burst_Logical1(); void Burst_Logical0(); void Start_Burst(); void Burst_VolUp();


F-4

void Burst_VolDown(); void Burst_Back(); void Burst_Fwd(); void Burst_Play(); void Burst_Off(); interrupt [TIM2_COMP] void timer2_compa_isr(void); void delay_200us(int counts); // SENSORS interrupt [TIM2_COMP] void timer2_compa_isr(void); void RecordGesture (unsigned int InputMatrix[3][3]); void EmptyArray (unsigned int InMatrix[3][3]); void CopyArrayToLib(unsigned int InMatrix[3][3], unsigned char LibIndex); unsigned char NonePassedOver(unsigned char Array[9]); void InitSensorTimer(); void StartSensorTimer(); void StopSensorTimer(); unsigned char MatchGestureLib (unsigned int InMatrix[3][3]); // POWER MANAGEMENT void InitSleepCounter(); void DisableSleepCounter(); interrupt [TIM0_COMP] void timer0_comp_isr(void); unsigned char CompareSleepCounter(unsigned int Seconds); interrupt [PCINT0] void pin_change_isr0(void); void SleepProcess(); /* * END * FUNCTION PROTOTYPES * */ void main(void) // Declare your local variables here unsigned char Entered_Loop = 0; unsigned int Temp_Recorded_Gesture[3][3]; //unsigned char TempStr[33]=""; // Input/Output Ports initialization // Port A initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTA=0x00; DDRA=0xFF; //output for LCD // Port B initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTB=0x00; DDRB=0b00010000; //pwm channel 0 on // Port C initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T


F-5

PORTC=0x00; DDRC=0x00; // Port D initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTD=0x00; DDRD=0x00; // Port E initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTE=0x00; DDRE=0x00; // Port F initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTF=0x00; DDRF=0x00; // Port G initialization // Func4=In Func3=In Func2=In Func1=In Func0=In // State4=T State3=T State2=T State1=T State0=T PORTG=0x00; DDRG=0x00; // Port H initialization // Func7=In Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State7=T State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTH=0x00; DDRH=0b00000011; // Port J initialization // Func6=In Func5=In Func4=In Func3=In Func2=In Func1=In Func0=In // State6=T State5=T State4=T State3=T State2=T State1=T State0=T PORTJ=0b00000000; DDRJ=0b01111111; // Timer/Counter 0 initialization // Clock source: System Clock // Clock value: Timer 0 Stopped // Mode: Normal top=FFh // OC0 output: Disconnected TCCR0A=0x00; TCNT0=0x00; OCR0A=0x00; // Timer/Counter 1 initialization // Clock source: System Clock // Clock value: Timer 1 Stopped // Mode: Normal top=FFFFh // OC1A output: Discon. // OC1B output: Discon. // Noise Canceler: Off // Input Capture on Falling Edge // Timer 1 Overflow Interrupt: Off // Input Capture Interrupt: Off // Compare A Match Interrupt: Off // Compare B Match Interrupt: Off TCCR1A=0x00; TCCR1B=0x00; TCNT1H=0x00;


F-6

TCNT1L=0x00; ICR1H=0x00; ICR1L=0x00; OCR1AH=0x00; OCR1AL=0x00; OCR1BH=0x00; OCR1BL=0x00; // Timer/Counter 2 initialization // Clock source: System Clock // Clock value: Timer 2 Stopped // Mode: Normal top=FFh // OC2 output: Disconnected ASSR=0x00; TCCR2A=0x00; TCNT2=0x00; OCR2A=0x00; // External Interrupt(s) initialization // INT0: Off // Interrupt on any change on pins PCINT0-7: Off // Interrupt on any change on pins PCINT8-15: Off // Interrupt on any change on pins PCINT16-23: Off // Interrupt on any change on pins PCINT24-30: Off EICRA=0x00; EIMSK=0x00; // Timer/Counter 0 Interrupt(s) initialization TIMSK0=0x00; // Timer/Counter 1 Interrupt(s) initialization TIMSK1=0x00; // Timer/Counter 2 Interrupt(s) initialization TIMSK2=0x00; // Universal Serial Interface initialization // Mode: Disabled // Clock source: Register & Counter=no clk. // USI Counter Overflow Interrupt: Off USICR=0x00; // Analog Comparator initialization // Analog Comparator: Off // Analog Comparator Input Capture by Timer/Counter 1: Off ACSR=0x80; ADCSRB=0x00; #asm("sei") EmptyArray(Temp_Recorded_Gesture); sleep_disable(); // init LCD LCD_BACKLIGHT = 1; lcd_init(16); // init lcd backlight ddr LCD_BACKLIGHT_DDR = 1; // init sensor port inits DDR_SENSOR_0 = 0; DDR_SENSOR_1 = 0; DDR_SENSOR_2 = 0;


F-7

DDR_SENSOR_3 = 0; DDR_SENSOR_4 = 0; DDR_SENSOR_5 = 0; DDR_SENSOR_6 = 0; DDR_SENSOR_7 = 0; DDR_SENSOR_8 = 0; SENSOR_0_PORT = 1; SENSOR_1_PORT = 1; SENSOR_2_PORT = 1; SENSOR_3_PORT = 1; SENSOR_4_PORT = 1; SENSOR_5_PORT = 1; SENSOR_6_PORT = 1; SENSOR_7_PORT = 1; SENSOR_8_PORT = 1; // init sleep counter InitSleepCounter(); // polling loop while (1) if (Entered_Loop == 0) lcd_clear(); lcd_putsf("Welcome to Handy"); Entered_Loop = 1; // listen for RPG button press if (RPG_BUTTON == 1) delay_ms(200); Entered_Loop = 0; UserInterface(); else if (SENSOR_1 == 0 && SENSOR_4 == 0) PORTJ = 0b00010010; lcd_clear(); lcd_putsf("Recognizing..."); InitSensorTimer(); RecordGesture(Temp_Recorded_Gesture); MatchGestureLib (Temp_Recorded_Gesture); EmptyArray(Temp_Recorded_Gesture); Sleep_Counter = MAX_SLEEP - 100; // send to sleep InitSleepCounter(); if (CompareSleepCounter(SLEEP_TIMEOUT)) SleepProcess();


F-8

Entered_Loop = 0; ; /* * * USER INTERFACE FUNCTIONS * */ // Main user interface loop void UserInterface() unsigned char Old_RPG_A = 0; unsigned char Old_RPG_B = 0; unsigned char New_RPG_A = 0; unsigned char New_RPG_B = 0; Menu_ID = 0; Menu_Sel = 0; InitSleepCounter(); MainSwitchBox(); while (1) while (1) New_RPG_A = RPG_A; New_RPG_B = RPG_B; if (CompareSleepCounter(SLEEP_TIMEOUT)) SleepProcess(); InitSleepCounter(); return; else if (Menu_Func_Mode) else if (New_RPG_A == Old_RPG_A && New_RPG_B == Old_RPG_B) else if (!RPG_A && !RPG_B) if (!Old_RPG_A && Old_RPG_B) //Up UpdateMenuSel(0); else if (Old_RPG_A && !Old_RPG_B) //Down UpdateMenuSel(1);


F-9

else if (RPG_A && !RPG_B) if (!Old_RPG_A && !Old_RPG_B) UpdateMenuSel(0); else if (Old_RPG_A && Old_RPG_B) UpdateMenuSel(1); else if (RPG_A && RPG_B) if (Old_RPG_A && !Old_RPG_B) UpdateMenuSel(0); else if (!Old_RPG_A && Old_RPG_B) //Down UpdateMenuSel(1); else if (!RPG_A && RPG_B) if (Old_RPG_A && Old_RPG_B) //Up UpdateMenuSel(0); else if (!Old_RPG_A && !Old_RPG_B) //Down UpdateMenuSel(1); Old_RPG_A = New_RPG_A; Old_RPG_B = New_RPG_B; if (RPG_BUTTON == 1) break; ; if (Menu_Func_ID == 0) Menu_Func_Mode = 0; Menu_ID = Menu_New_ID; Menu_Sel = Old_Menu_Sel; Old_Menu_Sel = 0; MainSwitchBox(); else Menu_Func_Mode = 1; Old_Menu_Sel = Menu_Sel; ProcessFuncID();


F-10

Menu_Func_ID = 0; Sleep_Counter = 0; delay_ms(200); ; // Selects menu based on current navigation status void MainSwitchBox() //selects which menu to display based on menu id InitSleepCounter(); Menu_Func_ID = 0; switch (Menu_ID) case 0: MainMenu(); break; case 1: CustomizeMenu(); break; case 2: SendMenu(); break; case 3: //ResetMenu(Menu_Sel); lcd_clear(); lcd_putsf("Reset Menu"); break; default: break; // Performs function specified by function id void ProcessFuncID() /* id:description 0: default (no action) 1: back to main -- 2-6 program 2: play 3: volup 4: voldown 5: next 6: back 7: off -- 8-12 send command 8: play 9: volup 10: voldown 11: next 12: back


F-11

13: off 14: reset */ /* GestureLibrary index reference 0: play 1: volup 2: voldown 3: next 4: back 5: off */ //Menu_Sel = 0; unsigned int Temp_Recorded_Gesture[3][3]; EmptyArray(Temp_Recorded_Gesture); InitSensorTimer(); switch (Menu_Func_ID) case 0: break; case 1: // back to main menu Menu_ID = 0; Menu_Sel = 0; Menu_Func_ID = 0; Menu_Func_Mode = 0; Old_Menu_Sel = 0; MainSwitchBox(); break; case 2: lcd_clear(); lcd_putsf("Recording:"); lcd_gotoxy(0,1); lcd_putsf(" Play"); RecordGesture(Temp_Recorded_Gesture); lcd_clear(); lcd_putsf("Recorded!"); CopyArrayToLib(Temp_Recorded_Gesture, 0); lcd_gotoxy(0,1); lcd_putsf("Press to return."); EmptyArray(Temp_Recorded_Gesture); Menu_Func_ID = 0; Menu_ID = 1; break; case 3: lcd_clear(); lcd_putsf("Recording:"); lcd_gotoxy(0,1); lcd_putsf(" Volume Up");


F-12

RecordGesture(Temp_Recorded_Gesture); lcd_clear(); lcd_putsf("Recorded!"); CopyArrayToLib(Temp_Recorded_Gesture, 1); lcd_gotoxy(0,1); lcd_putsf("Press to return."); EmptyArray(Temp_Recorded_Gesture); Menu_Func_ID = 0; Menu_ID = 1; break; case 4: lcd_clear(); lcd_putsf("Recording:"); lcd_gotoxy(0,1); lcd_putsf(" Volume Down"); RecordGesture(Temp_Recorded_Gesture); lcd_clear(); lcd_putsf("Recorded!"); CopyArrayToLib(Temp_Recorded_Gesture, 2); lcd_gotoxy(0,1); lcd_putsf("Press to return."); EmptyArray(Temp_Recorded_Gesture); Menu_Func_ID = 0; Menu_ID = 1; break; case 5: lcd_clear(); lcd_putsf("Recording:"); lcd_gotoxy(0,1); lcd_putsf(" Next"); RecordGesture(Temp_Recorded_Gesture); lcd_clear(); lcd_putsf("Recorded!"); CopyArrayToLib(Temp_Recorded_Gesture, 3); lcd_gotoxy(0,1); lcd_putsf("Press to return."); EmptyArray(Temp_Recorded_Gesture); Menu_Func_ID = 0; Menu_ID = 1; break; case 6: lcd_clear(); lcd_putsf("Recording:"); lcd_gotoxy(0,1); lcd_putsf(" Back"); RecordGesture(Temp_Recorded_Gesture); lcd_clear();


F-13

lcd_putsf("Recorded!"); CopyArrayToLib(Temp_Recorded_Gesture, 4); lcd_gotoxy(0,1); lcd_putsf("Press to return."); EmptyArray(Temp_Recorded_Gesture); Menu_Func_ID = 0; Menu_ID = 1; break; case 7: lcd_clear(); lcd_putsf("Recording:"); lcd_gotoxy(0,1); lcd_putsf(" Off"); RecordGesture(Temp_Recorded_Gesture); lcd_clear(); lcd_putsf("Recorded!"); CopyArrayToLib(Temp_Recorded_Gesture, 5); lcd_gotoxy(0,1); lcd_putsf("Press to return."); EmptyArray(Temp_Recorded_Gesture); Menu_Func_ID = 0; Menu_ID = 1; break; case 8: lcd_clear(); lcd_putsf("Sent Play!"); lcd_gotoxy(0,1); lcd_putsf("Press to return."); Burst_Play(); Menu_Func_ID = 0; Menu_ID = 2; break; case 9: lcd_clear(); lcd_putsf("Sent Volume Up!"); lcd_gotoxy(0,1); lcd_putsf("Press to return."); Burst_VolUp(); Menu_Func_ID = 0; Menu_ID = 2; break; case 10: lcd_clear(); lcd_putsf("Sent Volume Down!"); lcd_gotoxy(0,1); lcd_putsf("Press to return."); Burst_VolDown(); Menu_Func_ID = 0; Menu_ID = 2; break; case 11:


F-14

lcd_clear(); lcd_putsf("Sent Next!"); lcd_gotoxy(0,1); lcd_putsf("Press to return."); Burst_Fwd(); Menu_Func_ID = 0; Menu_ID = 2; break; case 12: lcd_clear(); lcd_putsf("Sent Back!"); lcd_gotoxy(0,1); lcd_putsf("Press to return."); Burst_Back(); Menu_Func_ID = 0; Menu_ID = 2; break; case 13: lcd_clear(); lcd_putsf("Sent Off!"); lcd_gotoxy(0,1); lcd_putsf("Press to return."); Burst_Off(); Menu_Func_ID = 0; Menu_ID = 2; break; case 14: lcd_clear(); lcd_putsf("Recognizing..."); RecordGesture(Temp_Recorded_Gesture); MatchGestureLib (Temp_Recorded_Gesture); Menu_ID = 0; //Menu_Sel = 0; Menu_Func_ID = 0; //Menu_Func_Mode = 0; //Old_Menu_Sel = 1; break; default: break; // display main menu void MainMenu() Menu_Max_Sel = 2; InitSleepCounter(); switch (Menu_Sel) case 0: lcd_clear(); lcd_putsf("> Customize"); lcd_gotoxy(0,1); lcd_putsf(" Recognize!"); Menu_New_ID = 1; break;


F-15

case 1: lcd_clear(); lcd_putsf(" Customize"); lcd_gotoxy(0,1); lcd_putsf("> Recognize!"); Menu_New_ID = 0; Menu_Func_ID = 14; break; case 2: lcd_clear(); lcd_putsf("> Send Command"); Menu_New_ID = 2; break; default: break; // display customize menu void CustomizeMenu() Menu_Max_Sel = 6; Menu_ID = 1; InitSleepCounter(); switch (Menu_Sel) case 0: lcd_clear(); lcd_putsf("> Play/Pause"); lcd_gotoxy(0,1); lcd_putsf(" Volume Up"); Menu_Func_ID = 2; //Menu_ID = 1; break; case 1: lcd_clear(); lcd_putsf(" Play/Pause"); lcd_gotoxy(0,1); lcd_putsf("> Volume Up"); Menu_Func_ID = 3; //Menu_ID = 2; break; case 2: lcd_clear(); lcd_putsf("> Volume Down"); lcd_gotoxy(0,1); lcd_putsf(" Next"); Menu_Func_ID = 4; break; case 3: lcd_clear(); lcd_putsf(" Volume Down"); lcd_gotoxy(0,1); lcd_putsf("> Next"); Menu_Func_ID = 5;


F-16

break; case 4: lcd_clear(); lcd_putsf("> Back"); lcd_gotoxy(0,1); lcd_putsf(" Off"); Menu_Func_ID = 6; break; case 5: lcd_clear(); lcd_putsf(" Back"); lcd_gotoxy(0,1); lcd_putsf("> Off"); Menu_Func_ID = 7; break; case 6: lcd_clear(); lcd_putsf("> <--"); Menu_Func_ID = 1; break; default: break; // display menu to send IR commands manually void SendMenu() Menu_Max_Sel = 6; Menu_ID = 2; InitSleepCounter(); switch (Menu_Sel) case 0: lcd_clear(); lcd_putsf("> Play/Pause"); lcd_gotoxy(0,1); lcd_putsf(" Volume Up"); Menu_Func_ID = 8; break; case 1: lcd_clear(); lcd_putsf(" Play/Pause"); lcd_gotoxy(0,1); lcd_putsf("> Volume Up"); Menu_Func_ID = 9; break; case 2: lcd_clear(); lcd_putsf("> Volume Down"); lcd_gotoxy(0,1); lcd_putsf(" Next"); Menu_Func_ID = 10; break; case 3:


F-17

lcd_clear(); lcd_putsf(" Volume Down"); lcd_gotoxy(0,1); lcd_putsf("> Next"); Menu_Func_ID = 11; break; case 4: lcd_clear(); lcd_putsf("> Back"); lcd_gotoxy(0,1); lcd_putsf(" Off"); Menu_Func_ID = 12; break; case 5: lcd_clear(); lcd_putsf(" Back"); lcd_gotoxy(0,1); lcd_putsf("> Off"); Menu_Func_ID = 13; break; case 6: lcd_clear(); lcd_putsf("> <--"); Menu_Func_ID = 1; break; default: break; void UpdateMenuSel (unsigned char Dir) // 1 is up, 0 is down if (Dir == 0) if ((Menu_Sel + 1) <= Menu_Max_Sel) Menu_Sel ++; else Menu_Sel = 0; else if (Dir == 1) if ((Menu_Sel - 1) >= 0) Menu_Sel --; //else // Menu_Sel = 0; Sleep_Counter = 0; InitSleepCounter(); MainSwitchBox(); /* * END * USER INTERFACE FUNCTIONS


F-18

* */ /* * * IR TRANSMISSION FUNCTIONS * */ // all the burst functions transmit the IR command code patterns void Burst_VolUp() OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; Start_Burst(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); //-- delay_200us(2); //-- Start_Burst(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); OCR2A=0x00; TIMSK2=0x00; OCR0A=0x00;


F-19

void Burst_VolDown() OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; Start_Burst(); Burst_Logical1(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); //-- delay_200us(2); //-- Start_Burst(); Burst_Logical1(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); OCR2A=0x00; TIMSK2=0x00; OCR0A=0x00; void Burst_Back()


F-20

OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; Start_Burst(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); OCR2A=0x00; TIMSK2=0x00; OCR0A=0x00; void Burst_Fwd() OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; Start_Burst(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); OCR2A=0x00; TIMSK2=0x00; OCR0A=0x00; void Burst_Play() OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; Start_Burst();


F-21

Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical0(); OCR2A=0x00; TIMSK2=0x00; OCR0A=0x00; void Burst_Off() OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; Start_Burst(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical1(); Burst_Logical0(); Burst_Logical0(); Burst_Logical1(); Burst_Logical0(); OCR2A=0x00; TIMSK2=0x00; OCR0A=0x00; void Start_Burst() // 38khz carrier // output port: PORTA.0 // period: 26.316 us // duty cycle time: 8us // high burst period 1: 1000 us // high burst period 2: 600 us // low burst period: 1400 us


F-22

PORTB.4 = 0; TCCR0A=0b00011001; delay_200us(5); TCCR0A=0; delay_200us(7); TCCR0A=0b00011001; delay_200us(3); TCCR0A=0; void Burst_Logical0() // 38khz carrier // output port: PORTA.0 // period: 26.316 us // duty cycle time: 8us // high burst period: 600 us // low burst period: 1400 us PORTB.4=0; delay_200us(7); TCCR0A=0b00011001; delay_200us(3); TCCR0A=0; void Burst_Logical1() // 38khz carrier // output port: PORTA.0 // period: 26.316 us // duty cycle time: 8us // high burst period: 600 us // low burst period: 400 us PORTB.4=0; delay_200us(2); TCCR0A=0b00011001; delay_200us(3); TCCR0A=0; //PORTB.4=0; // interrupt used for gesture recognition and IR transmission interrupt [TIM2_COMP] void timer2_compa_isr(void) #asm("cli") Delay_Counter++; #asm("sei")


F-23

// delay function for multiples of 200 us void delay_200us(int counts) Delay_Counter = 0; TCCR2A=0b00001011; while(1) if (Delay_Counter == counts) break; TCCR2A=0x00; // inits /* OCR2A=0x32; TIMSK2=0x02; OCR0A=0x66; */ /* * END * IR TRANSMISSION FUNCTIONS * */ /* * * SENSOR FUNCTIONS * */ // records gesture into argument array void RecordGesture (unsigned int InputMatrix[3][3]) unsigned char PassedOver[9] = ""; while (1) if (SENSOR_1 == 0 && SENSOR_4 == 0) break; while (1) if (SENSOR_1 != 0 || SENSOR_4 != 0) StartSensorTimer(); break; // sensor polling loop while (1) if (SENSOR_0 == 0 && !PassedOver[0]) InputMatrix[0][0] = Delay_Counter;


F-24

PassedOver[0] = 1; PORTJ = PORTJ | 0b00000001; // bottom default sensor if (SENSOR_1 == 1) InputMatrix[0][1] = Delay_Counter; PORTJ = PORTJ & 0b01111101; if (SENSOR_8 == 0 && !PassedOver[8]) InputMatrix[2][2] = Delay_Counter; PassedOver[8] = 1; PORTH = PORTH | 0b00000010; if (SENSOR_5 == 0 && !PassedOver[5]) InputMatrix[1][2] = Delay_Counter; PassedOver[5] = 1; PORTJ = PORTJ | 0b00100000; if (SENSOR_2 == 0 && !PassedOver[2]) InputMatrix[0][2] = Delay_Counter; PassedOver[2] = 1; PORTJ = PORTJ | 0b00000100; if (SENSOR_3 == 0 && !PassedOver[3]) InputMatrix[1][0] = Delay_Counter; PassedOver[3] = 1; PORTJ = PORTJ | 0b00001000; // middle default sensor if (SENSOR_4 == 1) InputMatrix[1][1] = Delay_Counter; PORTJ = PORTJ & 0b01101111; if (SENSOR_6 == 0 && !PassedOver[6]) InputMatrix[2][0] = Delay_Counter; PassedOver[6] = 1; PORTJ = PORTJ | 0b01000000; if (SENSOR_7 == 0 && !PassedOver[7]) InputMatrix[2][1] = Delay_Counter; PassedOver[7] = 1; PORTH = PORTH | 0b00000001;


F-25

// check when to end recording if ( (!NonePassedOver(PassedOver)) && (Delay_Counter > 2000) && (SENSOR_0 == 1) && (SENSOR_1 == 1) && (SENSOR_2 == 1) && (SENSOR_3 == 1) && (SENSOR_4 == 1) && (SENSOR_5 == 1) && (SENSOR_6 == 1) && (SENSOR_7 == 1)) StopSensorTimer(); PORTJ = 0b00000000; PORTH = 0b00000000; break; // checks pass over flag array unsigned char NonePassedOver(unsigned char Array[9]) unsigned char i; for (i=0;i<9;i++) if (Array[i]) return 0; return 1; // matches input argument array with eeprom gesture library unsigned char MatchGestureLib (unsigned int InMatrix[3][3]) unsigned char i; unsigned char j; unsigned char LibCnt; unsigned char LibIndex = 255; unsigned char NoMatch = 0; for (LibCnt = 0; LibCnt < 6; LibCnt ++) NoMatch = 0; for (i = 0; i < 3; i ++) for (j = 0; j < 3; j ++) if (GestureLibrary[LibCnt][i][j] == 0) if (InMatrix[i][j] == 0) else if (InMatrix[i][j] != 0) break; else if ( (InMatrix[i][j] > (unsigned int) ((1.0 + TOLERANCE) * (float) GestureLibrary[LibCnt][i][j])) || (InMatrix[i][j] < (unsigned int) ((1.0 - TOLERANCE) * (float) GestureLibrary[LibCnt][i][j])))


F-26

break; // if j loop not completed, set nomatch flag and break to next gesture if (j != 3) NoMatch = 1; break; // if nomatch flag is set, reset flag and proceed, else match detected and break if (NoMatch == 0) LibIndex = LibCnt; break; if (NoMatch) lcd_clear(); lcd_putsf("Unrecognized!"); return 0; switch (LibIndex) case 0: lcd_clear(); lcd_putsf("Play!"); Burst_Play(); break; case 1: lcd_clear(); lcd_putsf("Volume Up!"); Burst_VolUp(); break; case 2: lcd_clear(); lcd_putsf("Volume Down!"); Burst_VolDown(); break; case 3: lcd_clear(); lcd_putsf("Next!"); Burst_Fwd(); break; case 4: lcd_clear(); lcd_putsf("Back!"); Burst_Back(); break; case 5: lcd_clear(); lcd_putsf("Off!"); Burst_Off();


F-27

break; default: lcd_clear(); lcd_putsf("Unrecognized! 255"); break; return 1; // copies input argument array to eeprom gesture library at the given index void CopyArrayToLib(unsigned int InMatrix[3][3], unsigned char LibIndex) unsigned char i; unsigned char j; for (i = 0; i < 3; i ++) for (j = 0; j < 3; j ++) GestureLibrary[LibIndex][i][j] = InMatrix[i][j]; // empties a hand gesture array void EmptyArray (unsigned int InMatrix[3][3]) unsigned char i; unsigned char j; for (i = 0; i < 3; i ++) for (j = 0; j < 3; j ++) InMatrix[i][j] = 0; // these functions sets up/stops the sensor timers void InitSensorTimer() OCR2A=0x1F; //31 TIMSK2=0x00; Delay_Counter = 0; void StartSensorTimer() Delay_Counter = 0; TCCR2A=0b00001010; // 8 prescaler TIMSK2=0x02; void StopSensorTimer() TCCR2A=0x00; TIMSK2=0x00;


F-28

Delay_Counter = 0; /* * END * SENSOR FUNCTIONS * */ /* * * POWER MANAGEMENT FUNCTIONS * */ // these functions sets up/stops the sleep timers void InitSleepCounter() TCCR0A=0b00001101; OCR0A=0x7D; TIMSK0=0x02; void DisableSleepCounter() TCCR0A=0; OCR0A=0; TIMSK0=0; // interrupt increases sleep counter interrupt [TIM0_COMP] void timer0_comp_isr(void) #asm("cli") Sleep_Counter ++; #asm("sei") // detects pin change on activation sensors interrupt [PCINT0] void pin_change_isr0(void) #asm("cli") #asm("sei") // compares the current value of the sleep counter to the input argument unsigned char CompareSleepCounter(unsigned int Seconds) if ((Sleep_Counter / 60) >= Seconds) Sleep_Counter = 0; return 1; else return 0;


F-29

// performs necessary sleep/wakeup procedures for sleep mode void SleepProcess() DisableSleepCounter(); sleep_enable(); LCD_BACKLIGHT = 0; lcd_clear(); // enable external interrupt EICRA=0x00; PCMSK0=0x03; EIMSK=0x10; EIFR=0x10; powerdown(); lcd_putsf("Welcome to Handy"); LCD_BACKLIGHT = 1; sleep_disable(); // disable external interrupts EICRA=0x00; PCMSK0=0x00; EIMSK=0x00; EIFR=0x00; Sleep_Counter = 0; delay_ms(400); InitSleepCounter(); /* * END * POWER MANAGEMENT FUNCTIONS * */


G-1

Appendix G: FMECA Worksheet Table G-1 Power Supply Failure No. Failure Mode Possible Causes Failure Effects Method of

Detection

Criticality Remarks

A1 Output = 0V Failure of any

component in

function block A or

an external short

Device will not function

and may overheat. May

cause burns to the user and

melt the plastic casing.

Observation High

A2 Output > 5.5V Z1, R5 and R4 Potential damage to IC2,

LCD and IR Sensors.

Overheating may occur,

causing a fire and melting

the plastic casing. Injury to

the user may result

Observation High

A3 Output out of

tolerance

Z1, L1, C1, C2, R7,

D1, C3, R5 and R4.

High ripple or out-of-spec

operating voltage.

Overheating may occur,

causing a fire and melting

the plastic casing. Injury to

the user may result.

Observation High


G-2

A4 Battery not

working

Battery shorted or

malfunctioning

Unpredictable voltage

output from battery.

Batteries may explode

causing injury to the user

Observation High


G-3

Table G-2 Microcontroller

Failure No. Failure Mode Possible Causes Failure Effects Method of

Detection

Criticality Remarks

B1 Output

continuously 1

IC2, C13, C14, C15,

C16, reset circuitry,

software

Unreadable display

and loss of control of

infrared transmitters.

Unable to control

external sound

system

Observation Low

B2 Output

continuously 0

IC2, C13, C14, C15,

C16, reset circuitry,

software

Loss of control of

display and IR

transmitters. Unable

to control external

sound system

Observation Low

B3 PWM outputs

wrong signal or

frequency

IC2, C13, C14, C15,

C16, internal crystal,

software

Unable to control

external sound

system.

Observation Low


G-4

Table G-3 LCD and Optical Encoder (RPG)


Detection

Criticality Remarks

C1 LCD fails to

output correct

display.

J2, IC2, software Unable to

program

additional hand

gestures or view

current

command

recognized

Observation Low Could also be caused

by failure of LCD

itself

C2 Optical encoder

not working

J1, R2, R3,

software

Loss of input

control; unable

to access user

menu to

program

additional hand

gestures

Observation Low


G-5

Table G-4 Infrared Sensors


Detection

Criticality Remarks

D1 Output of IR

sensor

continuously 1

Damaged sensor,

R24, R25, R26,

R27, R28, R29,

R30, R31, R32,

software

Recognition of

hand gesture

function

impaired

partially or

totally

Observation of

LEDs tied to each

sensor and input

plausibility check

by microcontroller

observation

Low

D2 Output of IR

sensor

continuously 0

Damaged sensor,

bad connection with

header, R24, R25,

R26, R27, R28,

R29, R30, R31,

R32, software

Recognition of

hand gesture

function

impaired

partially or

totally

Observation of

LEDs tied to each

sensor and input

plausibility check

by microcontroller

observation

Low The infrared

sensors output 0

when the hand

above it is

detected. A built

in test in

microcontroller

can be used to

detect this failure.


G-6

Table G-5 Infrared transmitters


Detection

Criticality Remarks

E1 Output not at the

right frequency

IC2, software Device unable to

control external

sound system

Observation Low

E2 No output from

IR transmitters

IC2, R18, R19, R20,

software

Device unable to

control external

sound system

Observation Low Also can be caused by

failure of IR LED

itself

E3 IR LED

continuously on

IC2, software Device unable to

control external

sound system

Observation Low

ECE 477 Final Report

G-1

Appendix H: Top Level Flowchart of Application H-1 Top Level Flowchart of Application

Flow chart Key

Start/End

Process

Sequence

Start

Display UserInterface

Decision

User InterfaceActivated?

Start UpSensors

Activated?

No

Yes

Capture HandGesture

Gesturematches a

library gesture?

No Indicate on LCDthat gesture isunrecognized

Yes

Retrievecorresponding IRcode and transmit

Indicate on LCDthat command thatw as transmitted

Sleep CounterHit Ten

Seconds?

No

Yes

Sleep Mode(w ait forexternalinterrupt)

No

External "WakeUp" Interrupt


G-1

Appendix I: Application Code Hierarchy Block Diagram I-1 Application Code Hierarchy Block Diagram

void main ()

void SleepProcess()void

UserInterface()unsigned char MatchGestureLib(unsigned int InMatrix[3][3])

interrupt [TIM0_COMP] voidtimer0_comp_isr()

interrupt [TIM2_COMP] voidtimer2_compa_isr(void)

interrupt [PCINT0] voidpin_change_isr0(void)

void RecordGesture (unsignedint InMatrix[3][3])

voidMainSwitchBox()

voidUpdateMenuSel(unsigned char)

voidMainMenu()

voidSendMenu()

voidProcessFuncID()

voidCustomizeMenu(

)

void EmptyArray(unsigned int

InMatrix[3][3])

voidStartSensorTim

er()

voidInitSensorTimer(

)

voidStopSensorTime

r()

BurstFunctions

voidSendMenu()

voidCustomizeMenu()

voidBurst_Logical1()

voidStart_Burst()

voidBurst_Logical0()

voiddelay_200us(int

counts)

unsigned charNonePassedOver(u

nsigned charArray[9])

voidInitSleepCounter()

voidDisableSleepCo

unter()

unsigned charCompareSleepCounter(unsigned int Seconds)

Burst Functions: - Burst_Play() - Burst_VolUp() - Burst_VolDown()- Burst_Fwd() - Burst_Back() - Burst_Off()

Documents

ECE 477 Final Report Spring 2006 - College of Engineering · 2008-08-25 · ECE 477 Final Report Spring 2006 A-1 Abstract Handy is a hand gesture based remote control. A user is able