EE 477 Final Report · Web viewSurface mount parts are utilized for major components to further reduce on size and a battery connector allows for the battery compartment to be placed

ECE 477 Final ReportSpring 2006

Team Code Name: We Ate Nine_______________________________ Team ID: __7____

Team Members (#1 is Team Leader):

#1: ____________________________ Signature: ____________________ Date: _________

#2: ____________________________ Signature: ____________________ Date: _________

#3: ____________________________ Signature: ____________________ Date: _________

#4: ____________________________ Signature: ____________________ Date: _________

Brian Eng

Matteo Mannino

Andy Homar

Saad Sami

ECE 477 Final Report Spring 2006

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

-ii-

Comments:


TABLE OF CONTENTS

Abstract A-1 1.0 Project Overview and Block Diagram A-2 2.0 Team Success Criteria and Fulfillment A-3 3.0 Constraint Analysis and Component Selection A-4 4.0 Patent Liability Analysis A-11 5.0 Reliability and Safety Analysis A-16 6.0 Ethical and Environmental Impact Analysis A-23 7.0 Packaging Design Considerations A-27 8.0 Schematic Design Considerations A-33 9.0 PCB Layout Design Considerations A-3710.0 Software Design Considerations A-4011.0 Version 2 Changes A-4712.0 Summary and Conclusions A-4913.0 References A-50Appendix A: Individual Contributions A-56Appendix B: Packaging B-1Appendix C: Schematic C-1Appendix D: PCB Layout Top and Bottom Copper D-1Appendix E: Parts List Spreadsheet E-1Appendix F: Software Listing F-1Appendix G: FMECA Worksheet G-1

-iii-


Abstract

The proposed project is to design a glove that allows a user to control the mouse pointer

on a Windows XP personal computer with simple hand, arm, and wrist movements. The glove

controls the movement of the mouse pointer with simple movements of the hand and wrist.

Mouse buttons, scroll functions, and sensitivity are implemented with pressure and bend sensors

on the fingers. The entire system includes two stations; a base station connected through a USB

interface to a computer running Windows OS, and a battery powered mobile station connected to

the control glove. The stations communicate with each other between RF transceivers.

A-1


1.0 Project Overview and Block Diagram

The glove will be powered by two AA batteries that will supply a usable voltage range

between 1V and 3V. A DC-DC boost converter will then boost this output to a constant 3.3V

that will be used to power the microcontroller and (Radio Frequency) RF transceiver. Wrist and

finger movements will be measured with pressure sensors and bend sensors, and hand

movements will be measured with an accelerometer. The microcontroller will measure the data

from the accelerometer and sensors with an on-board Analog to Digital (ATD) converter,

interpret the data into movements, and send the data to the RF transceiver.

The base will interface with and draw power from a Windows XP personal computer

through a Universal Serial Bus (USB) connection. The RF transceiver will intercept the data

from the glove and activate a hardware interrupt to the microcontroller when data is received.

The microcontroller will service the interrupt, encode the data into standard windows mouse

signals, and transmit the data to the PC through the USB line.

Figure 1-1. Mouse Glove Block Diagram

A-2


2.0 Team Success Criteria and Fulfillment

All of the five success criteria proposed for our project have been met, and have been

demonstrated to a teaching assistant and documented in a video.

1. An ability to detect “finger taps” based on pressure sensor data.

2. An ability to detect wrist movement base on bend sensor data.

3. An ability to detect hand movements base on accelerometer data.

4. An ability to wirelessly transmit encoded finger/wrist/hand movements to base

station

5. An ability to translate encoded finger/wrist/hand movements into “Windows

mouse” format. (using USB protocol)

A-3


3.0 Constraint Analysis and Component Selection

In the process of designing the Wireless Control Glove, several constraint issues must

be considered. The goal is to make an interface that is most natural to the user and to also give

them the comfort and range of existing wireless devices. With this in mind, range of operation,

power consumption, and packaging design are of greatest importance.

3.1 Computation Requirements

Main sources of computation will arise from the following:

Accelerometer Computations

Wireless Communication

USB Communication

Handling interrupts from the RF module

Excessive computations will lead to an increase in power consumption. As a resolve,

simple algorithms will determine the user’s hand movement. In all three Cartesian planes, the

tilt in one’s hand will be measured and parsed to determine the direction the mouse will move.

The amount of the pressure placed on the mouse enable button will serve as a scalar to the

aforementioned direction. The harder the button is pressed, the more velocity the cursor will

obtain.

All velocity values must be determined before the next refresh. In addition, the

microcontroller must poll all of the mouse buttons and shift the data into the RF module’s shift

register. These factors will determine the clock of the microcontroller on the glove. The base

station will need to communicate with the PC through a USB protocol and shift data out of the

shift register of the RF module. Most of the computation will be taken up by the base station

MCU when converting the incoming data into standard mouse protocol and then feeding this

data to the PC.

The average refresh time of a mouse is 50 Hz [1]. The accelerometer will refresh

between 150 – 350 Hz depending on which axis is selected. All buttons must also be polled in a

timely fashion. Button refresh rates of 200 Hz to detect fast double-click times are expected.

Following the Nyquist sampling rate, data must be sent to the base station 400 Hz to recognize

both movement and button clicks. The MCU candidates in question, however, are capable of

A-4


operating at much higher frequencies. They can therefore be clocked at a lower frequency which

would save in terms of power consumption.

3.2 Interface Requirements

The control glove will require a microcontroller with enough I/O pins to emulate a

standard computer mouse as well as interface with the accelerometer and the RF module. There

will be two buttons on the glove: one for the mouse click and another for the mouse enable. In

addition, there will be three bend sensors: one for the left mouse button, one for the right mouse

button, and one for the mouse scrolling. The MCU will need to poll these inputs at a certain rate

to ensure that all user controls are registered.

3.3 On-Chip Peripheral Requirements

Interfacing with two pressure sensors, three bend sensors, and the three dimensional

accelerometer will require an eight channel ATD converter. 8-Bits of resolution will be

adequate. To elaborate on the pressure sensors, they are not simply buttons that complete a

circuit but rather devices which detect the amount of pressure applied to their surface. The base

station will require integrated USB to communicate with the PC.

3.4 Off-Chip Peripheral Requirements

The design at hand will require a LDO voltage regulator that will take the voltage

from the two AA batteries and regulate them to 3.3 Volts. On the base station, a level translator

will be required for communication between the MCU and the RF module. A voltage regulator

will also be necessary to regulate the 5.0V USB line to 3.3 Volts for the RF module. The

accelerometer and RF modules will also be necessary.

3.5 Power Constraints

Due to our product being a wireless device, power consumption will be of great

importance. However, before speaking about the power constraint issues on the control glove,

the power constraints on the base station will be briefly discussed.

Following the USB 2.0 Low Speed Protocol, the output voltage on the VBus line is

approximately 5.0V. The candidate microcontrollers all have built in voltage regulators that will

A-5


take this input voltage and regulate it down to 3.3V. This voltage is adequate for the RF

transceiver, however it cannot source enough current to the device. Therefore, a separate voltage

regulator will take the 5.0V from the USB bus line and provide the 3.3V needed by the RF

module.

When it comes to the control glove, power consumption is much more critical. Two

alkaline AA batteries will be used in our design. The primary motivation behind choosing AA

batteries over AAA batteries was a ratio of performance to packaging constraints. Three AAA

batteries approximately have a volume of 11559 square millimeters, a width of 31.5 millimeters,

a weight 35 grams, and output 4.5 volts from 2700-3500 mA*h [2]. Two AA batteries on the

other hand approximately have a volume of 15836 millimeters cubed, a combined width of 28

millimeters, a weight of 46 grams, and a output voltage of 3.0 volts at 3600-5200 mA*h [1].

Using a LDO voltage regulator, MAX884 [4], a constant 3.3 V will be acquired from

the 3.0 V coming from the batteries. The regulator will also output a maximum current of 200

mA. The low power MCU candidates each operate between 1.8 V to 3.8 V which fit within this

spec. Accelerometer choices will also operate at this voltage and the most demanding of them

will require a maximum of 1.5 mA of current. Finally, the contenders for the RF modules can

operate at 3.0 volts and in their most taxing stages they can use up to 69 mA of current.

3.6 Packaging Constraints

Packaging constraints on the base station are quite minimal. The only requirement is

that it will be small enough to sit unobstructed on a desktop and have a single USB Type-B

connector.

On the control glove, however, space and weight are crucial to the design.

Components with the lowest surface area are being selected to save on space. This measure will

also result in lower weights of the components. The glove itself will need to be of flexible and

comfortable material. Care must be taken into locating a glove with proper ventilation. Wearing

a glove indoors for a long period of time will create a damp environment for the electronic parts.

Specifically, this could prove dangerous to our accelerometer which is prone to moisture

absorption. Aesthetics and comfort also motivated the design to use pressure sensors from

TekScan [5]. These sensors are sleek and flexible unlike digital buttons. They can line the

inside of the glove and can be easily “clicked” by the user.

A-6


3.7 Cost Constraints

The majority of the expenditures will be for the pressure sensors, bend sensors, and

the RF Units. Similar products range from $30 to $1000. The product of discussion will most

likely fall near the $100 mark in terms of cost.

3.8 Component Selection Rationale

The rationale used to select the RF unit, accelerometer, and microcontroller is the next

topic of discussion. The motivation behind selecting the microcontroller will be discussed last

solely because the microcontroller selection requires knowledge of the components it will

interface with.

RF Unit:

Items of Interest:

Freescale Solution

Cypress Solution

Spark Fun Solution

As mentioned earlier, one of the major design constraints is the range of the control

glove. A simple use case to test the range of the product would be a user that will be moving

around a lecture hall while giving a presentation. Most wireless mice, however, work on the 27

MHz frequency and have a range of only up to two meters. Freescale, in their wireless USB

mouse system [6], suggested using an xx3316 compatible RF chip along with a loop antenna to

communicate to the base station. This path will obviously require the implementation of a trace

antenna on the PCB for both the control glove and the base station. The benefits of this route are

sufficient documentation.

Cypress Semiconductors in its WirelessUSB family of Radio Systems-On-Chip (SoC)

offers a 2.4 GHz transceiver IC with up to 50 meter range [7], however a 10 meter chip [8]

would be more practical for the product design. Cypress also offers this IC bundled within a

transceiver module [9] on a PCB with the PCB trace antenna. The module has a mount for a 12-

pin header and communicates to the MCU through an SPI interface. Data speeds of up to 62.5

kbps can be achieved. Cypress has shown [1], through several use cases, that during the course

A-7


of a typical day the device will be used actively for forty-five minutes each day and consume an

average of 12.66 mA. However, at peak times, current consumption can reach 69 mA [18].

Overall, the wireless module is an excellent product; however, after contacting the distributors,

availability is an issue. Modules that are available are only sold in quantities of 10 at $8.50 a

module.

The final choice for an RF Unit is provided by Spark Fun. The RF-MiRF [10] is also

a full 2.4 GHz transceiver module. In terms of range, this product claims to have 50 feet indoor

and 125 feet line-of-sight [10]. This is definitely a significant increase over the aforementioned

Cypress module. Data rates are also faster at either 1 Mbps or 250Kbps [10]. However, for the

desired application, it will not be sending enough data to utilize such high transfer rates. It

interfaces to the circuit through a 7-pin header mount. Data is shifted into a register and then

clocked out as fast as possible. A benefit of choosing this module is freedom of operation. The

Cypress module follows a certain protocol, WirelessUSB, which in the desired application may

not be necessary. The most appealing feature of this product is its low current consumption.

Peak current in TX mode is 10.5 mA and 18 mA in RX mode. The module has a per unit cost of

$19.95 which is nearly 100% more than its Cypress counterpart. Nevertheless, as mentioned

earlier, the price and availability of the Cypress product forces the selection of this module from

Spark Fun.

Accelerometer:

Items of interest:

STMicroelectronics E-LIS3L02AS4 3-axis Accelerometer

Freescale MMA7260Q 3-axis Accelerometer

The STMicroelectronics E-LIS3L02AS4 is a low-power three-axis linear

accelerometer [11]. It operates between 2.4 V and 3.6 V and comes in a SOIC package.

Maximum current consumption is rated at 1.5 mA [11]. The user is given two sensitivities to

operate the device: +/- 2g and +/- 6g. For the application at hand, 2g sensitivity will be ideal.

The device has a 0.5 mg resolution at 100 Hz which will give the sensitivity needed to detect

hand movements. Readings will be read on three pins, one for each axis. A/D Converters on the

microcontroller will capture these values. Benefits of this board are its sensitivity and

packaging. It is priced at a reasonable $9.95 but must be ordered in quantities of 5.

A-8


The main contender to the STMicroelectronics chip is the Freescale MMA7260Q [12].

Also a 3-axis low-power linear accelerometer, the MMA7260Q has a much smaller profile,

lower power consumption, and more selectable sensitivities. The device is packaged into a 16-

pin leadless quad flat pack, which is much smaller than the STM part. Maximum current

consumption is 800 micro amps and it is capable of detecting acceleration at four sensitivities:

1.5g, 2g, 4g, and 6g [12]. The accelerometer outputs in the same fashion as the STM part, a pin

for each axis. The MMA7260Q can be purchased for $10.86 which is only 10 % more than its

competitor. In the end this Freescale part was chosen due to its lower profile and lower current

consumption.

Microcontroller:Items of interest for the control glove:

PicMicro PIC18F44J10 – MCU for control glove

Cypress CY7C60223 – MCU for control glove

Freescale MC9S08GT16 – MCU for control glove

Cypress CYC63823-PXC – MCU for base station

Freescale MC68HC908JB16 – MCU for base station

In terms of the control glove, three possible choices were considered. The first

microcontroller in question is the PIC18F44J10 [13]. This is a low power 8-bit MCU that

operates at 2.0 V to 3.6 V and has an on-chip 2.5 V regulator. It has 13 A/D channels what will

be useful for all of the mouse inputs. It has 16K of system flash and has SPI and I2C. It is

readily available in DIP packaging which will greatly aid in prototyping. This part was in high

regards until we looked for a similar PIC microcontroller for the base station. All products with

low-speed USB functions that would fit the base station were one time programmable.

Therefore, the decision to drop the PIC18F44J10 was made simply because devices from the

same manufacturer were desired.

Next on the list is the Cypress CY7C60223 [14]. This is another 8-bit low power

microcontroller that was built for human interface devices. Items of interest are its low power

consumption which is typically 1.97 mA at 3 Mhz and a built-in 125 mA 3.3 V voltage regulator.

Since the device will be operating at a lower frequency it may be able to save even more power.

This microcontroller has plenty of I/O pins for the external devices but lacks any A/D converters.

This is a major problem since interfacing with the 8 components through an ADC is required.

A-9


Another problem with this microcontroller is its availability. None of Cypress’s distributors

have this product in stock and samples may not arrive in time.

The Freescale MC9S08GT16 [15] is the final choice for the control glove. It has

many of the features of the previous microcontrollers mentioned. The most appealing feature is

the lowest power consumption amongst the three contenders. This chip is capable of running at

1.8 volts and has a built in voltage regulator. Other points of interest are the onboard 8-channel

A/D converter. Plenty of I/O pins are available, and 16K of flash will provide the ability to

buffer input from the user. The product is readily available at many of Freescales' distributors

and can be purchased for $3.82.

For the base station, the selection process began with the Cypress CYC63823-PXC

[16]. It comes in a DIP package for easy prototyping. It is designed for HID applications and

has built-in low speed USB functions. The SPI module is an added benefit. A 125 mA 3.3 V

voltage regulator can also be found on the chip. This will be crucial for regulating the voltage

coming from the USB connector. However, as with the other Cypress parts, this chip is difficult

to locate. Samples have been ordered but no confirmation on when they will arrive has been

given.

The final contender for the basestation is the Freescale MC68HC908JB16 [17]. It is

another low-speed USB 8-bit microcontroller. It was suggested by Freescale in their Wireless

USB Mouse system configuration [6]. It has dual 27-MHz phase-locked loops if there is any

need to build a custom RF unit. It also has the benefit of being able to handle a keyboard and

mouse composite device. With this feature, the ability to send shortcut keys to operate specific

windows instructions becomes a possibility. The cost of this microcontroller is $4.60.

A-10


4 Patent Liability Analysis

4.1 Introduction

The underlying function of the design project herein is to control a mouse cursor on a

computer screen by means of capturing and processing hand gestures and arm movements. The

user will wear a glove with flex (bend) and pressure sensors and an accompanying wrist module

with accelerometers to capture data. A mouse click is represented by the user bending his finger

towards his palm, thus activating the flex sensor, and depressing the pressure sensor on the user's

thumb at the same time. Mouse movement is represented by arm movements which are captured

by 2 accelerometers. This data is then sent over RF to a base station which communicates to a

computer via USB in order to ultimately tell the computer to move the cursor and/or activate a

click event. There may be patent liability issues concerning the capturing, processing, and

translating of the user bending his finger and depressing a sensor into a computer input device

signal as well as utilizing accelerometer data to appropriate a computer input device signal. This

paper will cover these patent issues by analyzing 3 different patents and discussing how they

apply to our project. Finally, this paper will discuss the actions required to avoid any patent

infringement.

4.2 Results of Patent and Product Search

After an extensive search through the U.S. Patent and Trademark Office's (USPTO)

online resources [1], 3 patents were deemed to share substantial design implementations as well

as substantially performing the same function as the project that was previously described. The

first step that was taken was to search the USPTO for “human computer interface” in order to get

a feel as to what types of computer interfaces have been patented. This search yielded 328

results and most of the results dealt with force feedback and haptics. Despite this, a narrower

search field was determined as many hand based devices that were found from the initial search

included the words “data glove” in their claims to describe a glove which captured and processed

sensory data. As a result, a search for “data glove” AND “interface” was made to try and narrow

down the results. Three-hundred and fifty-four results came up from this search and there were a

few patents that had similar implementations of the technologies that our project also utilizes;

however, the ultimate functionality was not the same. Finally, a very specific search was made

for “glove” AND “accelerometer” which brought back 109 results, most of which did not pertain

A-11


to any type of interface device but ultimately led to the 3 patents that will be discussed. The

reason for searching for “accelerometer” was that the previous 2 searches did not yield any

patents that discussed utilizing accelerometer data for computer input. The majority of the finds

from the first 2 searches discussed utilizing pressure sensors for computer input.

The first patent which will be discussed is patent 6,242,334, “Computer data entry and

manipulation apparatus and method.” This patent was filed on June 7, 1995 and awarded on July

23, 2002 to Sun Microsystems. The device that this patent covers is an apparatus that generates

“control signals for the manipulation of virtual objects in a computer system according to the

gestures and positions of an operator's hand...The apparatus includes a glove worn on the hand

which includes sensors for detecting the gestures of the hand, as well as hand position sensing

means coupled to the glove and to the computer system for detecting the position of the hand

with respect to the system.” The main claims are that it is a device to control a computer that has

a display and is integrated onto a glove that includes flex sensors to detect finger movements and

a position sensor to detect the position of the glove with respect to the display. Furthermore, the

claims state that a possible configuration of the system is to have 3 sensors. [2]

The second patent which will be discussed is patent 5,819,206, “Method and apparatus

for determining position and orientation of a moveable object using accelerometers.” This patent

was filed on March 20, 1997 and awarded on October, 1998 to Crossbow Technology, Inc. The

method that this patent covers is the method of utilizing multiple accelerometers mounted on a

movable object to track its position and orientation in order to generate “computer simulation

signals.” In the patent's claims, these “computer simulations signals” include video, audio,

tactile, and sensory information. The claims also state that the method is specifically to generate

these “computer simulation signals in response to [the] orientation of a movable object from a

plurality of electronic linear accelerometers mounted on the movable object.” Additionally, the

claims layout the steps to this method which are to process the accelerometer signals, generate

orientation and movement signals, and generate computer simulation signals. [3]

The third and final patent which will be discussed is patent 6,304,840 under the title of

“Fingerless glove for interacting with data processing system.” This patent was filed on June 30,

1998 and awarded on October 16, 2001 to U.S. Philips Corporation. The device that is covered

under this patent is a “data glove...used for enabling ten-finger-typing with a virtual keyboard.”

This system, according to the claims, is comprised of a computer and a fingerless glove that

A-12


utilizes bending sensors for user-interaction with the computer. In addition, each finger

represents a set of keyboard characters. The specific element in this set is determined by the

“angle at which the finger is bent at a proximal interphalangeal joint.” [4]

4.3 Analysis of Patent Liability

First, there is a vital distinction that can be made from patent 6,424,334, “Computer

data entry and manipulation apparatus and method,” [2] and our device despite the fact that they

may sound identical. An important fact is that the device covered under this patent clearly states

that the position of the glove is always calculated with respect to the display. However, our

project does not calculate the glove's position with respect to the display. For our device, the

user does not use the display as a reference. The user can be positioned anywhere within range

of the base station receiver, and an arm movement to the left by 6 inches at some fixed rate will

always yield the same results. This is due to the fact that our project does not utilize position

sensors but accelerometers to capture arm movements. Instead of processing position data, we

process acceleration data in order to calculate velocity and position. Though this is a major

difference between the two devices, the similarities are overwhelming. Both devices use a glove

which is outfitted with flex sensors and sensors to monitor arm movement and translate the

sensory data into the manipulation of an object on a computer screen. In regards to literally

infringing on any functions, it is clear that our project's functionality is identical, but we do not

literally infringe upon this patent because of the claim that the patented device detects the

position of the glove with respect to the display. Our project does not depend on any display-

related positioning. Another issue at hand is the doctrine of equivalents. The doctrine of

equivalents states that something is equivalent if “it performs substantially the same function in

substantially the same way to yield substantially the same result.” [5] In terms of infringement

under the doctrine of equivalents, our project does not infringe upon the patent. This can again

be attributed to the fact that determining arm movements based on accelerometer data rather than

position sensors is a substantially different way of interpreting arm movements. Also,

interpreting arm movements in this manner would also yield substantially different results as

discussed before.

With regards to patent 5,819,206, “Method and apparatus for determining position

and orientation of a moveable object using accelerometers,” [3] there is potential for literal

A-13


infringement. The method of capturing and processing orientation and movement data from

multiple accelerometers and utilizing that data in order to generate computer simulation signals

as described above for this patent is exactly the same as the method utilized by our project. Both

the patented device and our project process “linear acceleration signals from ... [several] ...

accelerometers mounted on ... [the] ... object” [3]. Consequently, our project would also infringe

upon the patent based on the doctrine of equivalents [5] due to the fact that a major sub module

of our project does substantially the same function in substantially the same way to yield

substantially the same results.

Although the previous patent was infringed upon literally, our project does not literally

infringe upon patent 6,304,840, “Fingerless glove for interacting with data processing system”

[4]. This can be attributed to the fact that the fingers and flex sensor module of our project do

not function as keyboard characters; they function as mouse click events. Moreover, our project

does not take into consideration multiple angles of bending in order to map several events, in this

case computer inputs, on one finger. Another reason why our project does not infringe upon this

patent literally is because in our design we do not consider a finger bend as an event that can

generate a computer input signal. Our design calls for a finger bend coupled with the touch of a

pressure sensor at the same time to generate a computer input signal. Finally, our project does

not infringe upon this patent based on the doctrine of equivalents because even though both

devices perform substantially the same function, taking data from bend sensors placed on the

user's fingers and translating that data into computer inputs, in substantially the same way, the

results yielded are substantially different as one yields keyboard character inputs while the other

yields mouse click events. Although a mouse and a keyboard are both used as input interfaces

for a computer, they are substantially different in their functions as a keyboard is primarily used

for entering numbers and letters into a computer whereas a mouse is primarily used for

manipulating the position of and on screen cursor in order to select or highlight certain objects.

4.4 Action Recommended

In order to alleviate the potential literal infringement incurred from patent 5,819,206,

“Method and apparatus for determining position and orientation of a moveable object using

accelerometers,” the use of multiple accelerometers must be eliminated. This means our project

would have to utilize one accelerometer and one gyroscope, or similar device, in order to achieve

A-14


our design goals. This would eliminate the literal infringement and infringement based on the

doctrine of equivalents as the patent only specifically covers the use of multiple accelerometers

in capturing and processing hand/arm movement and orientation.

4.5 Summary

In summary, 3 patents were found that our project had the potential to infringe upon:

both literally and based on the doctrine of equivalents. Our device provides the same

functionality as the device found in the first patent, “Computer data entry and manipulation

apparatus and method.” Despite this fact, our device did not infringe upon the patented device as

a module of our device preformed a task laid out in the patent's claims substantially different

than the patented device and yielded substantially different results. The second patent, “Method

and apparatus for determining position and orientation of a moveable object using

accelerometers,” would have been infringed both literally and based on the doctrine of

equivalents. As a result, a solution to utilize a single accelerometer in our design coupled with a

gyroscope was offered in order to alleviate the infringement. The third and last patent,

“Fingerless glove for interacting with data processing system,” was not infringed upon at all

because the is ultimately used for inputting keyboard characters into a computer as opposed to

mouse click events.

A-15


5 Reliability and Safety Analysis

5.1 Reliability Analysis

Component Selection

For the reliability analysis, five components in the design were chosen under the criteria of

being the most likely to fail. To match these criteria, considerations were taken into the

likelihood of overheating and the criticality of the component to the entire design. Below (Table

1) is a list of the components determined to be the most likely to fail and to be the most critical to

the overall design.

1. MAX1705 (DC-DC Step-Up Converter - Glove) [2]2. LD1117 (Voltage Regulator - Base) [3]3. MC9S08GT16 (Microcontroller - Glove) [4]4. MC68HC908JB16 (Microcontroller - Base) [5]5. nRF2401A (RF Transceiver – Glove/Base) [6]

Table 5-1. List of Components for Reliability Analysis.

Part Failure Rate and MTTF Calculation

In order to calculate the part failure rate and MTTF for each device, several parameters and

equations were used from the Military Handbook for Reliability Prediction of Electronic

Equipment. The parameters used and their definitions are listed on Table 2. In calculating the

MTTF of each device, if a reasonable assumption could not be made in selecting a numerical

value for each parameter, then the value selected would reflect the ‘worst case scenario’ for that

device.

λp = Part failure rateC1 = Die complexityC2 = Constant based on the number of pinsλBD = Die base failure rateπMFG = Manufacturing process correction factorπT = temperature coefficientπL = Learning factor based on amount of time in productionπCD = Die complexity correction factorλBP = Package base failure rateπE = Environmental constantπQ = Quality factor

A-16


πPT = Package type correctionλEOS = Electrical overstress failure rateNp = number of pins

Table 5-2. Parameters used from MIL-HDBK-217F.

1. MAX1705 (DC-DC Step-Up Converter - Glove) – Linear CMOS Device [2]

λp = (C1 πT + C2 πE) πQ πL Failures/106 hours(MIL-HDBK-217F, Section 5.1)

Parameter Value Justification

C1 0.04Assumed linear CMOS with 301-1000 transistors for both the linear step-converter and low battery comparator (MIL-HDBK-217F, Section 5.1)

C2 0.005616 pin SMT device2.8 x 10-4 x (Np)1.08, Np = 16 pins(MIL-HDBK-217F, Section 5.9)

πT 7Normal operation from -40 to 85 degrees C, Linear MOS deviceT (worst case scenario) = 85 degrees C(MIL-HDBK-217F, Section 5.8)

πE 2.0 Assumed ground fixed environment(MIL-HDBK-217F, Section 5.10)

πQ 10 Commercial part with unknown screening levels(MIL-HDBK-217F, Section 5.10)

πL 1.0 At least two years in production(MIL-HDBK-217F, Section 5.10)

λp 2.912 Failures/106 hoursMTTF 3.4341 x 105 hours ~ 39.2 years

Table 5-3. MAX1705 Parameters and Calculations.

The MAX1705 DC-DC Step-Up Converter’s function is to check for a low battery and to

supply power to the entire glove circuit. It was chosen due to its critical role in the power supply

design, and thus its possible tendency to overheat. Since the device sits on the user’s hand,

failure in this device may result in overheating and thus may injure of the user. Therefore, the

criticality of this device is high. This analysis clearly shows that modifications need to be made

to the power supply to ensure greater safety.

A-17


2. LD1117 (Voltage Regulator - Base) – Linear CMOS Device [3]



C1 0.02 Assumed linear CMOS with 101-300 transistors (MIL-HDBK-217F, Section 5.1)

C2 9.2 x 10-43 pin SMT device2.8 x 10-4 x (Np)1.08, Np = 3 pins(MIL-HDBK-217F, Section 5.9)

πT 180Normal operation from -40 to 150 degrees C, Linear MOS deviceT (worst case scenario) = 150 degrees C(MIL-HDBK-217F, Section 5.8)





Table 5-4. LD1117 Parameters and Calculations.

The LD1117 Low Drop-Out Voltage Regulator was chosen for its role in the base station

power supply. The purpose of the LD1117 is to drop 5.0V down to 3.3V for the RF

communication module. While this device is not attached to the user, possible overheating may

cause a fire. For this reason the criticality of the device is high. This analysis shows that

modifications need to be made to the design to ensure greater safety.

3. MC9S08GT16 (Microcontroller - Glove) – 8-bit Microprocessor [4]



C1 0.14 8-bit microprocessor(MIL-HDBK-217F, Section 5.1)

C2 0.017 44 pin SMT device

A-18


2.8 x 10-4 x (Np)1.08, Np = 44 pins (MIL-HDBK-217F, Section 5.9)

πT

0.98 Normal operation from -40 to 85 degrees C, Digital MOS deviceT (worst case scenario) = 85 degrees C(MIL-HDBK-217F, Section 5.8)





Table 5-5. MC9S08GT16 Parameters and Calculations.

This microcontroller is the basis of the entire design for the glove. If it failed, the entire

design would fail. Failure of this part will not lead to overheating or injury, and therefore this

device remains a low criticality. The MTTF shows that it is not necessary to improve the safety

of this device any further.

4. MC68HC908JB16 (Microcontroller - Base) – 8-bit Microprocessor [5]



C1 0.14 8-bit microprocessor(MIL-HDBK-217F, Section 5.1)

C2 0.01232 pin SMT device2.8 x 10-4 x (Np)1.08, Np = 32 pins(MIL-HDBK-217F, Section 5.9)

πT 0.60Normal operation from 0 to 70 degrees C, Digital MOS deviceT (worst case scenario) = 70 degrees C (MIL-HDBK-217F, Section 5.8)



A-19




Table 5-6. MC68HC908JB16 Parameters and Calculations.

This microcontroller is the basis of the entire design for the base station. If it failed, the

entire design would fail. Like the glove microcontroller, failure of this part will not lead to

overheating or injury, and therefore this device remains a low criticality. The MTTF shows that

it is not necessary to improve the safety of this device any further.

5. nRF2401A (2.4 GHz RF Transceiver – Glove/Base) – VHSIC/VHSIC-like

λp = λBD πMFG πT πCD + λBP πE πQ πPT + λEOS Failures/106 hours(MIL-HDBK-217F, Section 5.3)


λBD 0.16 Assumed logic and custom part type(MIL-HDBK-217F, Section 5.3)

λBP 0.0026 24 pins(MIL-HDBK-217F, Section 5.3)

λEOS 0.065 Assumed to be susceptible from 0 to 1000 volts of ESD (worst case)(MIL-HDBK-217F, Section 5.3)



πCD 5.2 Measured ~0.25cm2 Die Area, ~1.00um feature size(MIL-HDBK-217F, Section 5.3)

πPT 6.1 Assumed non-hermetic SMT device (worst case)(MIL-HDBK-217F, Section 5.3)

πMFG 2.0 Assume neither QPL or QML (worst case)(MIL-HDBK-217F, Section 5.3)

πT 7.0Normal operation from -40 to 85 degrees C, Linear MOS deviceT (worst case scenario) = 85 degrees C (MIL-HDBK-217F, Section 5.8)

A-20



Table 5-7. nRF2401A Parameters and Calculations.

Communication between the base station and the glove relies on this device. The

nRF2401 RF Transceiver was chosen because it operates at a high frequency and dissipates a

relatively large amount of power. If it were not to function properly, the entire design would fail,

but there would be no risk of injury to the user. Even though it is of low criticality, the MTTF

calculation shows that more improvements should be made to the reliability of this device.

Conclusion

Part λp MTTFMAX1705 2.912 Failures/106 hours 3.4341 x 105 hours ~ 39.2 yearsLD1117 36.01 Failures/106 hours 2.7764 x 104 hours ~ 3.17 yearsMC9S08GT16 1.712 Failures/106 hours 5.8411 x 105 hours ~ 66.68 yearsMC68HC908JB16 1.08 Failures/106 hours 9.2593 x 105 hours ~ 105.7 yearsnRF2401A 12.03 Failures/106 hours 8.3124 x 104 hours ~ 9.5 years

Table 5-8. Overall Failure Rate Calculations

With the overall failure rate calculations organized together on Table 7, it is easy draw

comparisons to analyze the data. It is clear that the most likely failure to occur is the LD1117

voltage regulator. This failure may could result in a short, and overheat the circuit, or it may just

disconnect the power to the nRF2401A device. Since there is a risk of fire, this current rate of

failure is not acceptable and an improvement on the design is necessary.

The second most likely device to fail is the nRF2401 transceiver. This will cut off all

communication between the base station and glove, thus rendering the device useless. While this

device is of low criticality, improvements should be made to help user satisfaction. The rest of

the devices appear to fail relatively close to each other in comparison to the nRF2401A and the

LD1117.

In conclusion, in order for the device to be marketed improvements on the design must be

made. The current design yields a lifetime of about three years with a possibility of overheating

and causing injury to the user.

A-21


2.0 Failure Mode, Effects, and Criticality Analysis (FMECA)

See Appendix G for the FMECA worksheet.

Functional Block Main Component LabelPower Supply (Glove) MAX1705 ARF Module Voltage Regulator (Base) LD1117 BMCU (Base) MC68HC908JB16 CRF Module Communication (Base) MAX3378 DSensors (Glove) Flex/Bend Sensors EMCU (Glove) MC9S08GT16 F

Table 5-9. FMECA Functional Chart Sections

Criticality Description of Effect Max ProbabilityHigh Possibility of overheating or fire,

explosion, or injury to userλ < 10-9

Low Possibility of user dissatisfaction λ < 10-5

Table 5-10. Criticality Classification

A-22


6 Ethical and Environmental Impact Analysis

6.1 Ethical Impact Analysis

During the design of any product, ethical and environmental considerations need to be

paid close attention to for obvious reasons. The design team should put forth its best effort to

protect the safety of the user as well as the environment. The glove mouse potentially poses risk

of radiation exposure directly to its user due to the RF communication abilities in conjunction

with its close proximity to the user. Environmental effects need to also be considered during the

manufacturing and disposal of the device to reduce harmful chemical wastes. The following text

considers the aforementioned subjects, other related ethical issues, as well as offers some

solutions to reduce the problems.

An important ethical issue regarding the glove mouse is its utilization of the 2.4GHz

RF band for communication between the glove and the base station. Many other devices operate

on the same frequency such as Bluetooth devices and 802.11b wireless LANSs. RF interference

can result in degradation of performance not only for our device but also can affect the

performance of the device it interferes with. Testing our device to ensure minimization of RF

interference with these other devices is important. Testing near wireless LANs, Bluetooth

devices, and other devices that are constantly transmitting through the 2.4GHz band to analyze

performance degradation and reporting these results to potential buyers is one effective option.

One way our device reduces these potential interferences is the use of our RF modules'

Shockburst mode. This mode allows the microcontroller to clock in data at its clock speed, while

the RF module transmits data in high speed bursts at 1Mbps. This feature significantly reduces

transmission time. This shorter transmission time not only reduces power consumption but also

reduces the probability of “on air” collisions which in turn reduces the probability of RF

interference.[2] A warning can be placed in the user documentation that will suggest that the

device may interfere with other devices the user has that may be operating within the same

frequency band (2.4GHz). It will also be noted that this interference may result in small

performance degradation. The RF modules that we use are FCC part 15 compliant and this will

also be noted in the user documentation.

One factor that may contribute to health risks is the fact that the electrical device is

worn by the user. This aspect of the device may have two specific harmful effects: potentially

harmful long-term radiation effects and possible overheating effects. A byproduct of any device

A-23


that uses radio frequency signals to communicate is radiation. Whether prolonged exposure to

certain radiation levels is linked to tumors in humans has been an ongoing debate. A recent

Swedish study suggested that cellular phones impose a greater risk of cancer to users who use

them at high levels.[1] Because the RF modules operate on similar levels to some cellphones

and are worn very near the human body. This will be of concern to potential users of the glove

mouse. An appropriate place to warn the user will be in the user manual. Simply stating that

using the device heavily over long periods of time may pose a risk of cancer will be sufficient.

Another concern with a device that is worn by a human and comes into contact with that

human's body is the potential of the device to heat up to harmful levels. This may occur due to a

device malfunction or because of prolonged use. An effective way to test and prevent this would

be to test the device for prolonged periods of time and analyze the effect this has on the devices

operating temperature. If the device is shown to heat up considerably, more effective heat

dissipating packaging and ventilation will be implemented on the device before it is ready for

production. A warning of possible heating effects due to malfunction and prolonged usage shall

be placed directly on the glove and in the user manual.

Another important concern with HID (human interface devices) is prolonged/repeated

use injuries. These are of particular concern to our device in that the glove is most suitable as a

gaming device where more significant hand, finger and wrist movements are used. When

making these repeated hand gestures over long periods of time, injuries will become more

prevalent. A prolonged use injury that has been noted to be caused by HID's is carpal tunnel

syndrome. Flexing of the wrist repeatedly is one cause of carpel tunnel syndrome. [6] The

nature of our device leads the user to use the wrist repeatedly. Testing the device for prolonged

periods, and subsequently adjusting aspects of the device such as packaging size, glove material,

and weight of the glove to ensure the device will be most comfortable is essential to reduce the

harmful effects of repeated use.

Warnings which concern the aforementioned injuries are usually placed directly on the

device so that the user will know when to stop using it. A warning that "prolonged use of this

device may cause serious injury" should be placed on a tag on the glove or possibly on the arm

strap. This may be elaborated upon in the user documentation as well. The user manual can

explain the user how to calibrate the device for comfort and possibly loosen the glove to make it

more comfortable. The warning may also suggest that the user discontinue use if it becomes

A-24


discomforting. A possible way to assist in preventing injuries caused by malfunction would be

to make the device as easy as possible to remove.

6.2 Environmental Impact Analysis

Not only is it necessary for engineers to conduct thorough functionality tests on their

product, but environmental effects also need to be researched before marketing can begin. A

thorough environmental impact analysis for the glove mouse follows. It includes a description of

potential environmental effects during three stages of the products life cycle. The three stages

are the manufacturing process, the period of normal usage, and concluding with methods for

disposal and/or recycling.

Like most electronic devices that contain a PCB, the glove mouse contains lead. Lead

can be harmful to humans when exposed to high levels. Using lead free products during the

manufacturing process can reduce the amount of lead contained in a PCB. By using lead free,

ROHS compliant parts and solder, the lead content can be dramatically decreased. This will

produce a lesser amount of harmful lead waste exposed to the environment during its disposal

stage.

In addition to the use of lead in printed circuit boards, the manufacturing process

creates a significant amount of hazardous waste and chemicals, as well as uses an excess of

water and energy. The wastewater and sludge generated contains a significant amount of lead

and chemicals that are a direct threat to the environment. The manufacturing process can

produce cleaning waste waters, waste water treatment sludge, spent solvents and spent potassium

cyanide solution, waste thiourea and waste xylene. If these wastes aren’t managed properly they

can contaminate soil and groundwater. The EPA states that when the groundwater evaporates, it

contaminates the air and can be harmful to humans. [2] The only way to lower the risk of danger

as a result of this is to promote safer, waste management manufacturing processes. Ways to

reduce wastes include using non-cyanide baths, recycling etchants, and by reusing cleaners and

rinses. [4]

The wireless glove mouse has little environmental effect during its normal use phase.

As previously mentioned, the RF module may interfere with other devices in the home or

business such ass wireless LANs, cordless phones, Bluetooth devices and possibly medical

equipment. The RF module that our design utilizes operates in its Shockburst mode. As

A-25


previously stated, this mode reduces the amount of RF pollution that can contaminate the

environment by speeding up the transmission period. Since the device can only interfere with

other devices when it is transmitting concurrently with another device, the shortened

transmission time greatly reduces RF pollution. [3]

Disposal of the glove mouse at the end of its life is a cause for environmental concern.

Lead is known to cause harm to humans and animals. Some components on the board as well as

the solder used contain harmful chemicals and substances including as lead. Electronics are

known to contribute forty percent of lead content found in landfills.[5] Limiting the size of the

PCB as well as choosing lead free components is a good solution to reduce the amount of lead

that is disposed of at the end of a products life. Although new lead free manufacturing processes

and lead free components are becoming more available, these components cannot be supported

by some designs. Most of the components in the mouse project are lead free and are ROHS

compliant. Although it may cost a small fee, proper disposal of the product can be carried out by

designated electronics recycling companies. In addition to suggesting using recycling companies

for disposal, we can offer disposal services to the customer. This will increase the likelihood that

the PCB will be disposed of properly, thus avoiding harmful effects unto the environment.

6.3 Conclusion

In conclusion, an essential aspect of engineering is to evaluate and assess potential

ethical issues as well as environmental impacts to avoid liabilities and/or bad image. The glove

mouse produces potentially harmful radiation as well as communication interference due to its

RF capabilities, but reduces probability of impact by utilizing its Shockburst Mode. The glove

mouse’s manufacturing process produces harmful substances that can be controlled by effective

waste management techniques. The glove may also cause discomforting injuries if used for

prolonged periods of time. Warning the user of these possible side effects in user documentation

or directly on the device is essential.

A-26


7 Packaging Design Considerations

7.1 Introduction

In order to make our device user-friendly, we decided to make the device simple

possible. One of the most important goals of our packaging design was to make the glove feel

as natural as possible. Therefore, we needed to minimize the amount of electronics that would

reside on the actual glove. This led to the decision to package only the sensors on the actual

glove itself. A small PCB module with batteries dedicated solely to processing the glove's

sensors resides just above the user's wrist and enclosed in a small plastic enclosure rather than

on top of the user's palm. This solution reduces the weight of the device on the user's hand, thus

making it easier for the use to move his hand as naturally as possible. Consequentially, the use

of a base station to be tethered to the computer is necessary.

The glove will communicate, through RF, to the base station which will be connected

to a desktop computer through USB. This base station will be enclosed in a simple plastic

enclosure with LEDs for status display. For all of the device's enclosures, we chose ones made

of plastic to avoid any possible interference in the RF communications that an aluminum casing

may cause.

7.2.0 Commercial Product Packaging

There were 2 commercial products that we found that stood out from the rest of the

glove-inspired human interface devices (HIDs). The first product embodies what we wanted our

packaging design to stray away from as there were several negative aspects and little redeeming

aspects. The second product, however, has many positive aspects to it and is the closest

resemblance to how we designed our packaging that we found in any commercial product on the

market.

7.2.1 Product #1

The first commercial product that is similar to our project is the Essential Reality P5

Glove which is a device that fits on the user's hand and translates hand and finger movements

into mouse cursor movements and functions. The packaging design of the P5 Glove consists of a

A-27


plastic enclosure that houses the electronics which rests on the top of the user's hand. Two straps

are provided to secure the unit to the user's hand: one is located near the user's wrist while the

other is located in between where the thumb and index finger meet. Furthermore, 5 flexible

extensions, one for each finger, are mounted to the plastic enclosure. These extensions, which

travel the entire length of the user's fingers and sit atop each finger, have loops at the ends of

them in order to secure the user's fingertips to the extensions. There are also 4 buttons on the

enclosure for added functionality. Finally, the unit has a P/S2 (in some models USB) cord

tethered to it for communication with the computer. [1]

[2]

This packaging design has several glaring negative aspects about it. First, the glove's

electronics are placed directly on top of the user's hand. This design choice can make hand

gestures which require wrist movements awkward and strenuous after extended use due to the

A-28


fact that extra force must be used to move one's hand when the device is worn [2]. Second, if

the glove is not securely fastened, it could potentially hinder wrist bends or cause friction

between the device and the user's hand. Third, the restraints used to attach the user's fingers to

the finger extensions may or may not secure the fingers securely or at all if a user's fingers are

particularly large or small. Additionally, the restraints on the finger extensions make it

impossible for the user to use a keyboard with both hands or grab an object with his glove hand

while wearing the device. Fourth, the device is wired which means the user must be in a certain

range of the computer while in operation. Fifth and lastly, the overall packaging design is

cumbersome and simply not natural.

Despite several negative aspects of the P5 Glove, the one redeeming aspect of the

packaging are the 4 buttons located on the top of the glove which can be used as keyboard

inputs; however these buttons are only accessible to the user's other hand. Due to the fact that

we are designing our glove for single hand usage, meaning that the user's second hand will never

be necessary for any glove operation, we will not implement the P5 Glove's keyboard buttons.

Moreover, we have designed our project with the idea that the user will be able to use a keyboard

while wearing the glove, which would make placing keyboard buttons on the glove pointless.

Overall, the P5 Glove is not designed to feel as natural as possible which is the reason why we

will not be adapting any part of the P5 Glove into our project. As a result, our project's

packaging is completely unique when comparing it to the P5 Glove.

7.2.2 Product #2

The second commercial product that is similar to our project is the Immersion

CyberGlove II. The CyberGlove II is a “wireless electronic glove that transforms hand and

finger movement into real-time data for applications including: animation, motion capture,

virtual reality, digital prototyping, biomechanics studies, [and] medical and military training.”

[3] The packaging design of the CyberGlove II consists of a stretch fabric glove with open

fingertips and a plastic casing to house the electronics which straps to the users forearm. A

single wire runs from the glove to the forearm module.

A-29


[3]

Due to the simplicity of the CyberGlove II's packaging design, we could not find any

negative aspects of the packaging design. However, there are several positive aspects of the

design, many of which we had planned on implementing before discovering this device. The

first positive aspect of the CyberGlove II's packing is the choice to use a standard fabric glove

with open fingertips [3]. This makes the device feel as natural as possible while also allowing

the user to type on a keyboard or grab an object without much, if any, hindrance. Another aspect

of the device is the choice to separate the glove and the electronics. By placing the electronics

on the forearm, most of the problems discussed about the P5 Glove are alleviated. The user has

complete freedom of wrist and finger movement and will not become fatigued easily as there is

no extra weight bearing down on the user's hand like there is with the P5 Glove.

The initial packaging design of our project was extremely similar to the design of the

CyberGlove II without prior knowledge that it existed. In fact, our final design pays homage to

the CyberGlove II in several ways. First, like the CyberGlove II, we minimized the amount of

components on the glove and cut the glove's fingertips to allow for typing. Also, our design

shares the idea of utilizing a module that rests on the user's forearm, in our case closer to the

wrist than forearm, in order to process sensor data. We also utilize a strap to secure the wrist

module to the user. One difference, however, is that our design situates the battery next to the

wrist module on the strap but not on the actual module itself. We chose to place the batteries

apart from the module in order to balance the weight on the user’s wrist. If the batteries were

placed inside the module, the module could potentially have too much momentum while the

A-30


user moved his hand thus causing the module to shift. This would make the glove think the

user's hand is tilted when it is really not.

7.3 Project Packaging Specifications

The glove module consists of a baseball batting glove and the necessary sensors: 2

bend sensors, 2 pressure sensors, and an accelerometer. The bend and pressure sensors will be

embedded onto the glove; however, the accelerometer will be part of the wrist module that will

be strapped to the user's wrist. In order to neatly route all the necessary sensory signals, the

wires from the bend sensors will run across the dorsal side of the glove and into the

accelerometer PCB. Then, each sensory signal will be routed through a single insulated wire

with each individual sensory wire bundled inside of it. Next, the bundled wire will lead to a

custom male connector to be connected into the wrist module which will feature a custom female

connector. This single wire will connect to the forearm module which houses the glove

microcontroller and RF module. A battery pack will also reside on the forearm module.

7.4 PCB Footprint Layout

The microcontroller for the glove module comes in 2 footprint choices: SDIP and

QFP. We did not hesitate to choose the QFP footprint as it is considerably smaller than the SDIP

footprint. The QFP has a footprint area of 180.9025 mm^2 while the SDIP has a footprint of

498.9400 mm^2. For the base station microcontroller, we also used the criteria of saving space

when choosing the footprint. The microcontroller for the base station module comes in 2

footprint choices: SOIC and LQFP. The LQFP has a footprint area of 81.0000 mm^2 while the

SOIC had a footprint of 190.4275 mm^2. As a result, we chose the LQFP footprint for the base

station microcontroller. In regards to the RF and accelerometer modules, those packages come

on their own PCB. This is the reason they do not show up in the PCB footprint layout.

7.5 Summary

When designing our project's packaging, we always came back to the same rule: keep

it simple. We want to have the user's experience with the glove operate as smoothly and

naturally as possible. This was one of the determining factors when we decided to place the

glove microcontroller module on the user's forearm instead of on his hand. We did not want the

A-31


have the actual glove be overburdened by an abundance of devices. All electronics module will

be encased its own plastic encasing except for the bend and pressure sensors which will be

embedded onto the glove.

After designing our glove, we found 2 very different glove-inspired devices. One of

the products was almost an exact replica of the design we came up with while the other one was

bulky and cumbersome. In regards to the PCB footprint, we choose QFPs for our

microcontroller footprint in order to minimize the size of the PCB.

A-32


8 Schematic Design Considerations

8.1 Theory of Operation

Mobile Station Microcontroller (MC9S08GT16)

The main controller for the mobile station runs at 40 MHz and is specifically designed

for low power applications. This controller runs the algorithm for extracting hand and finger

movements from the accelerometer data, while sending data to the RF module for transmitting to

the base station.

Several considerations were taken in order to allow in circuit programming,

debugging, and testing. A 3x2 header is connected to power, ground, the background debug

mode pin, and the reset pin. Two holes in the header are left as “No Connection” as given in the

datasheet for the MC9S08GT16. [1] Furthermore, the IRQ pin is connected to a header for the

sake of running a test mode using the hardware interrupt, and an external switch was added to the

reset pin.

Seven A/D ports are taken up for the bend sensors, pressure sensor, and

accelerometers. Since the output sample rate of the accelerometers is at max 350Hz, the A/D

converter must sample by at least twice that frequency – 700Hz. The A/D converter operates at

the scaled absolute minimum conversion frequency of 500kHz with 10 bit resolution. 500kHz is

the best choice since there is no need for a higher frequency that would do nothing more than

consume power.

The controller communicates with the RF module through a standard I/O port

programmed as a shift register. The “Axis Switch” button, which allows a user to choose which

axes plane they wish to operate the mouse on, and is also connected to a standard I/O port.

Interface/Sensors (FlexiForce, Slider Buttons)

Both bend sensors and pressure sensors are variable resistors, where either bending or

applied pressure cause the resistance to increase linearly. For this application, each variable

resistor sensor is connected in series with a constant resistor, where the voltage read by the A/D

converter on the microcontroller is the voltage between the sensor and constant resistor. These

constant resistors determine the sensitivity of the variable resistors, and the constant resistors

must be chosen in such a way that the sensitivity is maximized.

A-33


The bend sensor has a minimum resistance of 10kOhm and a maximum of 30kOhm. [4]

To find the optimal resistance, it is necessary to solve for the maximum voltage difference when

the bend sensor varies from its maximum to its minimum resistance.

3.3V * Max( ) =~ 1.8 V Rconst = 12-13kOhm

Since 12kOhm is readily available, that is the chosen value of. However, for the

pressure sensor has infinite resistance it its rest state (zero pressure). Thus, using the same

method, it is easy to see that the maximum voltage difference is achieved with the highest

possible series resistance. 3MOhm is chosen for the pressure sensor, since anything greater

doesn’t seem to make much of a difference. [5] In addition to the sensor interface, there is one

slider button on the device that turns the glove on and off.

Power Supply (MAX1705)

Power is provided by two AA NiCd/NiMH batteries which supply a maximum voltage

of 3.0V collectively. The power supply voltage is then boosted by a DC-DC converter, the

MAX1705, to a constant voltage of 3.3V. This voltage is required for our RF module, the

ShockBurst MiRF. To configure the MAX1705 to output 3.3V, the FB is a 1.233V feedback

input that is connected to POUT, the boost output, with a resistor divider network. With the FB

pin input needing to be a constant 1.233V, the configuration of the output voltage depends on the

values of the resistors chosen between POUT and FB, and FB and ground. For a 3.3V output,

A-34


the resistance between POUT and FB was calculated to be about 160KOhm, while the resistance

between FB and ground was found to be 100kOhm.

To detect a low battery output, the pin LBP pin the input to a comparator that causes the

output LBO, which normally is pulled to the supply voltage, to output zero volts when LBP is

below 1.250V. Since the MAX1705 requires a start-up voltage of at least 1.1V, it is safe to

choose something a little higher as the “dead” battery voltage. Since a 2.0V LED is connected in

a forward bias configuration from the battery supply voltage to the LBO pin, the voltage

considered low for the battery was chosen to be 2.0V. A resistor divider network, from the

battery output, to the LBP pin, and then to ground was chosen such that when the battery voltage

was 1.5V, the LBP voltage would be just below 1.250V, thus causing the output LBO to output

zero volts, and turning on the LED between the battery power supply and LBO. The resister

between the battery supply and LBP is 300kOhm, while the resistor between LBP to ground is

500kOhm. The reason for the large scale values is due to the fact that the resistor network

provides a direct path from the batteries positive terminal to its negative terminal. [2]

Furthermore, the bypass capacitors used in the design are all highly recommended by the

manufacturer to have low-ESR. [8] A slider switch is part of the interface and is used to

disconnect the battery from the circuit.

Base Station Microcontroller (MC68HC908JB16)

The MC68HC908JB16 translates the signal from the RF module to USB mouse

commands recognizable by Windows XP PCs. The microcontroller is driven by a 5.0V power

supply and ground from the USB, as well as has two special pins designated for USB

communications with the PC. The controller can run at a maximum bus speed of 6MHz, which

will be needed to communicate with the RF module, run operations, and communicate with the

USB module in time before the next transmission next by the mobile station. [10] If the base

station is slower than the mobile station, then there is either going to be an accumulating lag or a

data lost.

A low drop out regulator (LD1117) is used to power the RF module for the base

station, which requires 3.3V. The RF module communicates with the base station through a

5.0V to 3.3V level translator, except for one difference – the “data ready” pin is connected to the

A-35


IRQ pin, since for our purposes the base station microcontroller is focused only on receiving,

encoding, and sending data along the USB connection.

The level translator chosen is the MAX3378, since it can be configured for the necessary

voltage requirements and has four bidirectional inputs/outputs. [9] The “data ready” pin is then

connected to the gate of an NMOS transistor with the IRQ connected to the drain and the source

connected to ground. This effectively translates the logic from 3.3V to 5.0V and inverts the

signal.

8.2 OrCad Schematic

See Appendix C

A-36


9 PCB Layout Design Considerations

Electronic circuits are always subject to noise. Noise can alter digital and analog signals

within a circuit and thereby give invalid or distorted results. It is an unavoidable consequence,

and through proper PCB design, it can be greatly reduced. Layout considerations for the No

Glove No Love Project are structured around reducing EMI (Electro Magnetic Interference) and

other forms of noise. The considerations are broken down amongst the two main components:

the base station and the glove. The following paragraphs discuss packaging constraints, EMI

reduction, trace size, and sectioning of the PCB as they relate to the base station and the glove.

Design of the No Glove No Love project is dictated by its comfort to the user, therefore its

size is very important. The PCB for the glove is around 4 by 2.5 inches and must fit on the wrist

of the user. This size constraint limits the flexibility of the design. Routing of traces and

placement of parts are crucial and are arranged to save on size. Surface mount parts are utilized

for major components to further reduce on size and a battery connector allows for the battery

compartment to be placed off of the PCB.

General PCB design rule states that nothing is more important to circuit design than a solid

and complete power system [1]. Many layout considerations revolve around the power system

of the glove and the base station. As mentioned in the application note [1], there are three types

of signal grounding: single point, multipoint, and hybrid. The article recommends single-point

grounding for frequencies below 1 MHz, however, the glove and the base station will utilize

multipoint grounding due to their higher frequencies of operation. Grounding on the base station

is located near the USB Ground connector. On the glove the grounding connects to the negative

terminal of the batteries. This serves as the primary ground for the entire circuit. As suggested

by the application note, the power and ground lines have wide traces and run parallel to each

other. A copper pour is also introduced on both PCBs for shielding from the 2.4 GHz wireless

transceiver modules. The copper pour also offers protection from ESD from the user’s

interaction with the USB cable.

Stability of signals is an obvious concern. Through the use of power decoupling this issue is

addressed. Capacitors are placed at the power and ground terminals of the ICs and they increase

stability on the power and ground rails by filtering out noise. They are placed as close to the IC

as possible as suggested by the Freescale application note [1]. Bypass capacitors are also placed

A-37


near the IC’s to provide instantaneous current on signal transitions. These capacitor placement

schemes were utilized in both the glove and the base station.

Sectioning of the PCB is also crucial in reducing EMI. The glove has eight A/D channels

that are being utilized. To prevent interference and for proper placement, the digital and the

analog components of the design are separated. The multipoint grounding scheme as described

earlier allows for separation in these components’ ground returns [2]. On the glove, the inputs

from the pressure sensors, the bend sensors, and the accelerometers are placed as close as

possible to the microcontroller to reduce interference. A ground pour is also placed within the

vicinity for further noise reduction. In addition, the RF modules on both PCBs are placed away

from the other components on the board, and, as suggested by the manufacturer, they are placed

as far as possible from the ground plane on the PCB [3]. On the base station, the header for the

module rests near the opposite end of the USB connector. On the glove, the RF module header is

placed on the opposite end of the PCB from the copper pour. Ground and power traces are

routed away from these modules so as not to affect their signals. On the base station, proper

placement of the microcontroller’s clock circuitry is also of concern. Clock circuitry is usually

the biggest generator of wide-band noise [1]. The circuit is placed as close to the MCU as

possible so as not to generate interference. For similar reasons it is also located away from the

wireless transceiver module.

Due to the many modules used in the base station and the glove, header pins are added

around the PCBs. Two eight pin headers are placed on the sides of the board to accommodate

the accelerometer breakout boards. At the front of the board, four two-pin headers interface with

the pressure sensors and the bend sensors. As mentioned earlier, the RF module is interfaced at

the bottom of the board on the glove and opposing the USB connector on the base station. It

uses a seven pin header. The accelerometer breakout boards have onboard filters for their analog

acceleration outputs. The bend sensors and the pressure sensors are basically potentiometers and

as a design decision additional filtering was not added.

As all signals are routed on traces, proper trace size and orientation can lead to further EMI

reduction. The traces on the glove and base station are kept under 12-mils in size. Power and

ground traces are increased in width to handle the demands of the circuit. For ease of routing,

power and ground traces from the regulator output and the USB interface are decreased in width

A-38


to sizes between 25 and 40 mils. To decrease transmission reflections [2], traces which change

direction turn at 135 degrees instead of 90 degrees.

A-39


10 Software Design Considerations

1.0 Software Design Considerations

Most of the design considerations important to the apparent success of this project rely on

software and algorithm tweaking. This leads to a simple software structure. The following

section will describe certain external interface requirements, register and variable mappings,

integrated peripherals used, as well as physical aspects of the project that help guide the software

development

ORGANIZATION OF APPLICATION CODE

The glove MCU (Freescale MC9S08GT16) is responsible for reading external sensor data

and using this data to drive the overall operation of the system. This sensor data needs to be

polled rather frequently. This leads the software for the glove microcontroller to be a polling

loop.

The main software routine for the base station MCU (MC68HC908JB16) is solely event

driven. The main routine eventually enters an infinite loop that waits for external events to

occur. These interrupts are generated by the RF module signaling that data is ready to be

retrieved or by the USB module signaling that a successful transmission has completed. The RF

module generates a keyboard interrupt while the USB module triggers various types of USB

interrupts. The main routines for the software can be seen in Appendix A.

MEMORY MAPPINGS

The memory mapping for the two microcontrollers used in the project are laid out in the

Figure 2.1. Both microcontrollers come with 16K FLASH which is more than enough for our

code. The GT16 has significantly more RAM than the JB16 has so all data processing will be

done on that chip instead of sending raw data to the JB16. Below in Figure 2.1 is a complete

memory mapping for each microcontroller.

Three main sections of memory that is utilized by the glove on the GT16 microcontroller are

RAM, ROM, and FLASH. The RAM stores temporary dynamic variables, the FLASH stores the

program code, while the ROM is used to store constant variables. The gloves program code

consumes about 1K of memory space. It consumes FLASH memory locations from C092 –

A-40


C4A8 which is 1046 bytes. The constant RF configuration word is stored in ROM and takes up

15 bytes. Other variables that are used to store the RF data are located in RAM and consume 9

bytes.

The JB16 has slightly less RAM than the GT16 does but this is not of concern to us because

the base station does not utilize many temporary variables. The program code on the base station

also uses about 1K of FLASH memory. The location the program code resides in is BAA3-

BBD3 for the main routine and BC41-BF0A for the USB module. Another 17 bytes or RAM is

used for temporary USB and RF data variables as well as 114 bytes of ROM for storage of the

USB device descriptors.

Figure 2.1 – Memory map for glove microcontroller (left) and base station microcontroller

(right). These images are generated by Processor Expert.

EXTERNAL INTERFACES

PTA0 – PTA2, PTE3-PTE5 : Control signals sent to accelerometers to select

sensitivity and mode of operation.

AD1P0-AD1P2, AD1P6: Acceleration data is sent to ATD channels through

these port pins.

AD1P3-AD1P5:. Sensor data is sent to the ATD channels through

A-41


these port pins.

PTC4-PTC6 Port C is for configuring and controlling RF

transmission.

PTD0, PTE0: For clocking and sending RF data.

PTE3, PTE4: D+ and D- lines for communication with host.

INTEGRATED PERIPHERALS

ATD channels are utilized on the glove MCU. The ATD control register must be

initialized by selecting a resolution, signed result select, prescaler rate select, and data

justification mode select. Data can be read from the result registers ATD1RH and ATD1RL[1].

The USB module on the base station must be initialized to allow interrupts on

endpoint 0 and the pull up resistor enable on the D- line must be set so the host can detect the

device once plugged in. These initializations are done with the USB control registers (UCR0-4)

[2].

PROGRAMMING/DEBUGGING PROVISIONS

The GT16 microcontroller has a background debug mode that may be used for

debugging and programming with Codewarrior [1]. We have added the necessary programming

headers for this feature. The base station does not have BDM but does include monitor mode

operation. The monitor mode of the JB16 allows for programming and debugging with

Codewarrior. It is also possible to program the JB16 through USB but debugging would not be

available. A programming header has been added to the base station board and a basic monitor

mode programmer circuit has been constructed for debugging [3].

Software Design Narrative

The following section details the modules and routines that drive the operation of the

glove mouse. First the software for the glove will be documented followed by the modules that

compose the base station.

Glove Software

A-42


Main Routine

The main routine is responsible for monitoring sensor data and translating data into

mouse events. Because the glove must continuously monitor signals from bend sensors, pressure

sensors, and accelerometers, the software is implemented with a polling loop. Prior to entering

the main loop, 8 ATD channels are initialized for incoming sensor data. The main loop first

checks signals coming from the accelerometers through the ATD channels. The data from the

accelerometers determines the angle that the hand is oriented. This orientation then determines

which direction the mouse will move. One of the pressure sensors is utilized as a cursor move

enable. This pressure sensor also determines the speed at which the cursor will move. Data

received from the bend sensors are used to determine if a click was made.

Processing the Data

Accelerometer

The accelerometer is used to detect the direction in which the user wishes to displace

the on screen cursor. After the accelerometers ATD ports are initialized and the accelerometer is

configured, the steady state of the device is determined by the initial orientation of the device.

Once these steady state values are determined and stored, changes in X and Y axis data are

translated into mouse motion. Following is pseudo code that illustrates how this is translated.

if acc[x or y] > ss[x or y] + xythres

then dir[x or y] = 2 // clockwise rotation

else if ss[x or y] > acc[x or y] + xythres

then dir[x or y] = 0 // counter-clockwise rotation

else

dir[x or y] = 1 // no rotation - stable

The x threshold values and y threshold values are pre-selected values based on tests

conducted to determine how sensitive movement should be. The x and y threshold is 15 while

the z threshold is 80. If either x or y is 2, this indicates that there is movement in the positive

direction. If x or y is equal to 0 this indicates the direction is in the negative direction while a 1

indicates no movement.

A-43


Bend Sensors and Pressure Sensors

Detection of a mouse click is fairly straight forward. A threshold will be set in a register

and subsequent comparison to that value will occur each loop iteration. If the bend sensor

voltage output drops below a threshold of 1.44V, then a click is detected. If a click is detected

and the click enable pressure sensor detects a voltage in excess of 0.39V, a right or left click will

be registered. There is also a bend sensor located on the underside of the wrist. Detection of a

click from this bend sensor enables scrolling on the desktop.

Once all the data has been processed, it will be ready to be sent to the RF module for

transmission to the base station. No further encoding will be necessary for the data as it will

already be in eight bit X and Y displacement values and binary button states, which all that is

needed for the USB mouse report [4].

RF Routine

After the data has been processed in the previous routine, it will be ready to be sent to

the RF module. All that is necessary for this routine is setting a control bit (CE) for the RF

module (after making sure the previous transmission has been completed), and clocking in the

receiving node address to the module followed by mouse data. The payload data that will be

clocked into the RF module will be 3 bytes wide. It will contain the two current states of the

buttons (2 bits) followed by two 8 bit values containing X and Y displacement. Once the data

has been clocked into the RF module, it can be transmitted by setting the control bit low (CE)

[4].

Base Station Software

Main

Each function that the base station performs is initiated by interrupts. The RF station

generates a keyboard interrupt when it has data available and the on-board USB module

generates interrupts to signal certain successful USB events. Thus the main routine is just an

infinite loop driven by these interrupt requests. Before we enter this infinite loop we must

enable interrupts on the default (control endpoint) endpoint zero and wait for the USB device to

A-44


be configured with the host. Following successful configuration, the main routine can enable

RF and the rest of the USB interrupts.

RF Routine

When the RF transceiver successfully receives a data transmission from the other

transceiver located on the glove, it will set its DR1 pin high which is connected to a keyboard

interrupt pin to generate the RF interrupt. The MCU then clocks out the data and stores the first

two received bits into a byte of their own, receive and store the next two bytes into their

dedicated X and Y displacement registers on the MCU so that they may be added to a mouse

report to be sent to the USB host [3] .

USB Routine

An essential part of our project will be communicating mouse data to a PC. The USB

routine is responsible for this difficult task. Most of the following information can be viewed in

more detail in the USB 2.0 specification and HID Class description [4].

The base station MCU supports three USB endpoints. For control and status

operations, the host communicates via endpoint 0. The mouse reports will be sent through

endpoint one. Upon initializing the USB module, these endpoints will be enabled while the

optional endpoint two will be disabled. The initialization step must also enable the

programmable pull-up on the D- port.

The first step to communicating with the host is plugging in the device to the universal

serial bus. The host detects this by a pull-up resistor on the D- line (for low speed devices).

Once the host detects this condition it will then start sending setup tokens to the device. There

are three conditions that may cause a USB interrupt. One of these conditions is a successful data

transmission or reception. Upon this kind of interrupt, the software must first determine which

endpoint caused this interrupt and whether it was a SETUP token, an IN token or an OUT token.

An IN token indicates a device to host transmission while an OUT token is from the host to the

device. Detection of these tokens is done by reading the USB status registers and control

registers.

The first thing the host will try to send to our base station is a SETUP token for device

configuration. This token describes the type of data or descriptor that the host requests. The

A-45


software must decode this token and prepare the requested data and place it in the endpoint zero

transmit buffers as the next token sent to the device will be an IN token. IN tokens will be

generated until the host has received all bytes of the requested descriptor. Then a new setup

token will be received. This process will repeat until the device is fully configured or

“enumerated”. During this enumeration process, the host will request a specific class descriptor.

In this class descriptor, there is a byte that tells the host that the device is of the HID class. Once

this happens, the host will send a request for a report descriptor. This report descriptor tells the

host the format of the reports the device will be sending and what the report contains (i.e. X and

Y displacements). The report sent by our device consists of one byte with the two lower bits

used to indicate right or left click. The two bytes following contain X and Y displacement

values. Once the device is enumerated, the main routine can enable interrupts on endpoint one.

All data transmission is initiated by the host. The main loop will wait for these

initiations in the form of interrupts. When the software has received data from the RF module, it

will place this data in the USB transmit buffers on endpoint one and set a bit in the control

register signifying the data is new and is ready to be sent to the host on the next IN token. After

this mouse report has been transmitted an interrupt will be generated, the data in the transmit

buffers will be invalidated, and new data must be placed in the buffers as needed. OUT tokens

will be scarce as most of the data will be from the device to host. The only situation where an

OUT token will likely occur is when a descriptor has been sent to the host, and a host will

subsequently respond with zero length packet signifying a successful transmission and

verification of the descriptor. [6]

A-46


11 Version 2 Changes

In the implementation of a second version, one thing that would be taken into heavier

consideration is the velocity estimation from the accelerometer data,. Measuring velocity would

allow the user to move his or her hand freely in order to move around the mouse. The problem

with the accelerometer data is that it contains noise that causes the velocity calculation, which

consists of adding up all the previous values of the acceleration to the current one, to accumulate

error very fast. During the first design iteration, it was assumed that any problems with noise

from the accelerometer could be solved with simple digital filtering. However, because the

glove needed to run at a low frequency in order to maintain a reasonable lifetime and the filter

applied to the accelerometer output was only a first order filter, there were a lot of aliasing

problems that rendered the signal too corrupted for any reasonable calculations. The best that

could be done was to create a tilting sensor for mouse movement. There are at least two

solutions that could be used to solve this problem in the circuit design phase:

1. Implement an analog circuit that calculates the velocity.

This circuit would consist of a high pass filter that would only cutoff the DC gain, and thus

needs to be designed with a fairly high order to ensure a steep roll-off. The DC cutoff is

necessary because the accelerometer does not settle at a consistent voltage when in its rest state,

and the DC gain must be zero in order to properly integrate the signal to obtain the velocity.

Following the high pass filter, a leaky integrator filter would be implemented. The leakiness of

the integrator is necessary since the noise from the accelerometer signal would cause a normal

integrator to saturate quickly. The passive component values for the integrator would be

experimentally chosen, while the high pass filter passive component values would be calculated.

The disadvantages to this solution is that it requires additional 1.65V and -1.65V (3.3V

divided by 2) power rails, and that it takes up more space on our PCB. The advantage is that it is

cheap to implement, and the velocity value would be fed straight into the microcontroller unit.

2. Use a digital signal processing chip.

The advantages here are that a DSP would take up less space on the glove, can implement

any transfer function needed, and allows a constant, selectable sampling frequency. The transfer

A-47


function implemented would be the same as the circuit implementation – a high pass filter

followed by a leaky integrator. The main disadvantage is that DSP chips are generally very

expensive.

From a packaging stand point, it would be better to use smaller, lightweight lithium ion

batteries for power rather than AA batteries in order to decrease weight on the hand. The

accelerometer would also be moved onto the PCB, rather than standing up and off the PCB, in

order to decrease the space taken up inside the packaging.

A-48


12 Summary and Conclusions

Our team accomplished a lot this semester. We were able to create a wireless USB glove

mouse. The idea was novel and could be actually useful to some people. The success of our

project hinged on two things: the hard work and dedication of our team members and the large

amount of time we spent dedicated to our conceptual design phase. Due to the fact that we spent

more time than most teams developing exactly what we wanted our project to do and exactly

how we were going to implement it, this helped in the long run as our design was simple from

the start. Our design was simple from the start because we had thought through the design

several times over and went through many iterative processes before we came to the best design

for our team. This proved to be invaluable as we rarely saw a hiccup in the stages of our design

from start to finish.

The simplicity of our design is a testament to the hard work and thought we put into the

project initially. This project could have been a lot more complicated had we not spent as much

time in the conceptual design phase. Nonetheless, we were dedicated in the beginning and did

not waver at the fact that other teams had started technical work while we were still

brainstorming ideas

This was a very powerful learning experience as we all learned how important the early

phases of a design are critical to a project's ultimate success. The cost of having to redesign a

project in the middle of the design cycle is too costly.

A-49


13 References

Schematic

[1] Freescale MC9S08GT16 Controller Data Sheethttp://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S08GB60.pdf

[2] SparkFun MMA7260Q Accelerometer Breakout Boardhttp://www.sparkfun.com/commerce/product_info.php?products_id=628

[3] Freescale MMA7260Q Accelerometer Data Sheethttp://www.freescale.com/files/sensors/doc/data_sheet/MMA7260Q.pdf

[4] Flexiforce Bend Sensorshttp://www.imagesco.com/catalog/flex/FlexSensors.html

[5] Flexiforce Pressure Sensorshttp://www.tekscan.com/flexiforce/specs_flexiforce.html

[6] SparkFun MiRF Breakout Boardhttp://www.sparkfun.com/commerce/product_info.php?products_id=153

[7] Nordic nRF2401A RF Transceiver Data Sheethttp://www.sparkfun.com/commerce/product_info.php?products_id=153

[8] Maxim MAX1705 DC-DC Boost Converter/Regulator Data Sheethttp://pdfserv.maxim-ic.com/en/ds/MAX1705-MAX1706.pdf

[9] Maxim MAX3378 Level Translator Data Sheethttp://pdfserv.maxim-ic.com/en/ds/MAX3372E-MAX3393E.pdf

[10] Freescale MC68HC908JB16 Microcontroller Data Sheethttp://www.freescale.com/files/microcontrollers/doc/data_sheet/

MC68HC908JB16.pdf

Reliability and Safety Analysis

[1] Reliability Prediction of Electronic Equipment, MIL-HDBK-217Fhttp://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2006/Mil-Hdbk-

217F.pdf

[2] Maxim MAX1705 DC-DC Boost Converter/Regulator Data Sheethttp://pdfserv.maxim-ic.com/en/ds/MAX1705-MAX1706.pdf

[3] LD1117 Series Low Drop Fixed and Adjustable Positive Voltage Regulator Datasheet

A-50

http://pdfserv.maxim-ic.com/en/ds/MAX1705-MAX1706.pdf

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

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

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


http://pdfserv.maxim-ic.com/en/ds/MAX3372E-MAX3393E.pdf

http://pdfserv.maxim-ic.com/en/ds/MAX1705-MAX1706.pdf

http://www.sparkfun.com/commerce/product_info.php?products_id=153


http://www.tekscan.com/flexiforce/specs_flexiforce.html

http://www.imagesco.com/catalog/flex/FlexSensors.html

http://www.freescale.com/files/sensors/doc/data_sheet/MMA7260Q.pdf


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


http://www.stmicroelectronics.com/stonline/products/literature/ds/2572/ld1117xx30.pdf

[4] Freescale MC9S08GT16 Controller Data Sheethttp://www.freescale.com/files/microcontrollers/doc/data_sheet/

MC9S08GB60.pdf

[5] Freescale MC68HC908JB16 Microcontroller Data Sheethttp://www.freescale.com/files/microcontrollers/doc/data_sheet/

MC68HC908JB16.pdf

[6] Nordic nRF2401A RF Transceiver Data Sheethttp://www.sparkfun.com/commerce/product_info.php?products_id=153

Design constraints

[1] Cypress. (2006) “Calculating battery life in wirelessUSB systems”.http://www.cypress.com/portal/server.pt?

space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Calculating%20Battery%20Life%20in%20WirelessUSB(TM)%20Systems%20-%20AN4002

[2] Wikipedia. (2006) “AA Battery”http://en.wikipedia.org/wiki/AA_battery

[3] Wikipedia (2006) “AAA Battery”http://en.wikipedia.org/wiki/AAA_battery

[4] Maxim-IC (2006) “MAX884 Product Summary”http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1214/ln/en

[5] TekScan (2006) “FlexiForce Force Sensor Summary”http://www.tekscan.com/flexiforce/flexiforce.html

[6] Freescale (2006) “High Data Rate Wireless USB Optical Mouse Solution”http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM055.pdf?

srch=1

[7] Cypress (2006) “CYWUSB6935 Product Info”http://www.cypress.com/portal/server.pt?

space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=65&rpn=CYWUSB6935

[8] Cypress (2006) “CYRF6936 Product Info”

A-51

http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=65&rpn=CYWUSB6935



http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM055.pdf?srch=1

http://www.freescale.com/files/microcontrollers/doc/ref_manual/DRM055.pdf?srch=1

http://www.tekscan.com/flexiforce/flexiforce.html

http://www.maxim-ic.com/quick_view2.cfm/qv_pk/1214/ln/en

http://en.wikipedia.org/wiki/AAA_battery

http://en.wikipedia.org/wiki/AA_battery

http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Calculating%20Battery%20Life%20in%20WirelessUSB(TM)%20Systems%20-%20AN4002












[9] Cypress (2006) “CYWM6934 Product Info”http://www.cypress.com/portal/server.pt?

space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=65&rpn=CYWM6934

[10] Spark Fun (2006) “RF-MiRF Product Info”http://www.sparkfun.com/commerce/product_info.php?products_id=153

[11] STMicroelectronics (2006) “LIS3L02AS4 Accelerometer”http://www.st.com/stonline/products/literature/ds/10221/lis3l02as4.htm

[12] Freescale (2006) “MMA7260Q Accelerometer Info”http://www.freescale.com/webapp/sps/site/prod_summary.jsp?

code=MMA7260Q&srch=1

[13] Microchip (2006) “PIC18F44J0 Pic Microcontroller”http://www.microchip.com/stellent/idcplg?

IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en024620

[14] Cypress (2006) “CY7C60223 Microcontroller”http://www.cypress.com/portal/server.pt?

space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=125&rpn=CY7C602xx

[15] Freescale (2006) “MC9S08GT16 Microcontroller”http://www.freescale.com/webapp/sps/site/prod_summary.jsp?

code=MC9S08GT16&nodeId=016246844914370008

[16] Cypress (2006) “CYC63823 Microcontroller”http://www.cypress.com/portal/server.pt?

space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=16&rpn=CY7C638xx

[17] Freescale (2006) “MC68HC908JB16 Microcontroller”http://www.freescale.com/webapp/sps/site/prod_summary.jsp?

code=68HC908JB16&srch=1

[18] Cypress. (2006) “Managing Power in WirelessUSB Systems”. http://www.cypress.com/portal/server.pt?

space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Managing%20Power%20in%20WirelessUSB(TM)%20Systems%20-%20AN4007

A-52

http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=418&r_folder=Application%20Notes&r_title=Managing%20Power%20in%20WirelessUSB(TM)%20Systems%20-%20AN4007



http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=68HC908JB16&srch=1

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=68HC908JB16&srch=1

http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=16&rpn=CY7C638xx



http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC9S08GT16&nodeId=016246844914370008

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MC9S08GT16&nodeId=016246844914370008




http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en024620

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en024620

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MMA7260Q&srch=1

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MMA7260Q&srch=1

http://www.st.com/stonline/products/literature/ds/10221/lis3l02as4.htm


http://www.cypress.com/portal/server.pt?space=CommunityPage&control=SetCommunity&CommunityID=209&PageID=259&fid=65&rpn=CYWM6934







PCB Considerations

14 Freescale. (2006) “Noise Reduction Techniques for Microcontroller-based Systems”http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-2759.xml

15 Freescale. (2006) “System Design and Layout Techniques for Noise Reduction in MCU-Based Systems”http://www.freescale.com/files/microcontrollers/doc/app_note/AN1259.pdf?srch=1

16 Personal E-Mail. E-Mail from SparkFun employee on RF-MiRF suggestions. http://shay.ecn.purdue.edu/~477grp7/documents/RF-MiRF_Assistance.html

Packaging

[1] Virtual Realities, “P5 Glove,” 2006, http://www.vrealities.com/P5.html

[2] RatePcMods.com, “P5 Glove Review,” 2006, http://www.ratepcmods.com/RevPages/p5/p5.htm

[3] Immersion Corporation – 3D Interaction Products, “CyberGlove II Wireless Data Glove,” 2006, http://immersion.com/3d/products/cyber_glove.php

[4] USB.org, “USB 2.0 Specification Engineering Change Notice (ECN) #1: Mini-B connector,” October 2000, http://www.usb.org/developers/docs/ecn1.pdf

[5] Unibox Standard Plastic Enclosures, “Series 100 Standard Enclosures (119),” 2006, http://www.uniboxinfo.com/images/s100/Pn119sh.pdf

[6] Unibox Standard Plastic Enclosures, “Series 100 Standard Enclosures (120),” 2006, http://www.uniboxinfo.com/images/s100/Pn120sh.pdf

Patent

[1] “United States Patent and Trademark Office”, 2006http://www.uspto.gov/.

[ 2] United States Patent and Trademark Office, “Computer data entry and manipulation apparatus and method,” July 2002, http://patft1.uspto.gov/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,424,334.PN.&OS=PN/6,424,334&RS=PN/6,424,334

A-53

http://patft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/PTO/srchnum.htm&r=1&f=G&l=50&s1=6,424,334.PN.&OS=PN/6,424,334&RS=PN/6,424,334



http://www.uspto.gov/

http://www.uniboxinfo.com/images/s100/Pn120sh.pdf

http://www.uniboxinfo.com/images/s100/Pn119sh.pdf

http://www.usb.org/developers/docs/ecn1.pdf

http://immersion.com/3d/products/cyber_glove.php

http://www.ratepcmods.com/RevPages/p5/p5.htm

http://www.vrealities.com/P5.html

http://shay.ecn.purdue.edu/~477grp7/documents/RF-MiRF_Assistance.html

http://www.freescale.com/files/microcontrollers/doc/app_note/AN1259.pdf?srch=1

http://www.freescale.com/webapp/sps/utils/SingleFaq.jsp?FAQ-2759.xml


[3] United States Patent and Trademark Office, “Method and apparatus for determining position and orientation of a moveable object using accelerometers,” October 1998, http://patft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5,819,206.PN.&OS=PN/5,819,206&RS=PN/5,819,206

[4] United States Patent and Trademark Office, “Fingerless glove for interacting with data processing system,” October 2001, http://patft1.uspto.gov/netacgi/nph-Parser? Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6,304,840.PN.&OS=PN/6,304,840&RS=PN/6,304,840

[5] Wikipedia, “Doctrine of Equivalents,” 2006, http://en.wikipedia.org/wiki/Doctrine_of_equivalents

Ethical and Environmental

[11] “Swedish Study Finds Cell Phone Cancer Risk”

http://www.betanews.com/article/Study_Tumor_Risk_from_Cell_Phones/1143823783

[2] “EPA orders Connecticut manufacturer to clean up site”http://www.epa.gov/region1/pr/2003/dec/031211.html

[3] “RFMiRF Datasheet”

http://www.sparkfun.com/datasheets/IC/nRF2401A.pdf

[4] “Pollution Prevention for Printed Circuit Board Manufacturing”

http://www.calgold.ca.gov/P2/3672.htm

[5] “Keeping Old Computers and Electronics Out of the Landfill”

http://www.tceq.state.tx.us/assistance/P2Recycle/electronics/landfill.html

[6] “Carpal Tunnel Syndrome”

http://www.webmd.com/content/article/78/95624.htm

Software

A-54

http://www.webmd.com/content/article/78/95624.htm

http://www.tceq.state.tx.us/assistance/P2Recycle/electronics/landfill.html

http://www.calgold.ca.gov/P2/3672.htm


http://www.epa.gov/region1/pr/2003/dec/031211.html

http://www.betanews.com/article/Study_Tumor_Risk_from_Cell_Phones/1143823783

http://en.wikipedia.org/wiki/Doctrine_of_equivalents




http://patft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5,819,206.PN.&OS=PN/5,819,206&RS=PN/5,819,206




[1] “MC9S08GB60 Datasheet”


[2] “MC68HC908JB16 Datasheet”


[3] “MON08”

http://eckhard-gosch.de/eng/controller/mon08.htm

[4] “nRF2401A RF Module Datasheet”


[5] “Device Class Definition For Human Interface Devices”

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

[6] “USB In A Nutshell”

http://www.beyondlogic.org/usbnutshell/usb1.htm

A-55

http://www.beyondlogic.org/usbnutshell/usb1.htm

http://www.usb.org/developers/devclass_docs/HID1_11.pdf


http://eckhard-gosch.de/eng/controller/mon08.htm




A-56


Appendix A: Individual Contributions

A.1 Contributions of Matteo Mannino:

As being the only EE on the project, my focus was mainly in hardware. Due to my

focus in hardware, I worked with Saad on selecting appropriate components when he was

working on the design constraints. I did the necessary power calculations for the design

constraints, and with those calculations I selected the MAX1705 DC-DC converter for the power

supply on the glove, and the LD1117 for the RF power supply on the base station. For

communication between the glove and the microcontroller on the base station, I selected the

MAX3378 level translator. I prototyped the MAX1705 power supply, and also calculated the

series resistance for the sensors and tested the sensors with them (when they came in) to make

sure they were working correctly with the resistance – then I made necessary changes to the

resistor values.

I drew up the functional block diagram, and documented and updated it with each

functional change in the project. I designed and created the schematic for the project, with my

attention directed mainly on the battery driven glove power supply, and documented and updated

the schematic with each change made to the design. After we got the PCB back, I fully

populated and fully tested all of the components on the glove PCB and partially populated the

base station PCB.

In the software, I created the preliminary flow chart as a guide to how the software

was going to be designed. I wrote the code for continuously reading the accelerometer values

through the base station. I designed various digital filters in an effort to estimate velocity from

the accelerometers which got thrown out due to my lack of success. After we changed the way

the hand would move the mouse, I wrote the code for detecting which direction the

accelerometer tilted, which would become the direction that the mouse pointer would move.

In the packaging, I filed out the USB port hole out of the plastic box, stitched and

sewed pockets onto the glove for the sensors to slip into, and bought and attached the elastic

Velcro to the glove station for wrist attachment.

In general, I hung around as often as I could to help out team members if they needed

me or if they thought there was a problem with the circuit. The two problems in the circuit were

that the NMOS transistor did not have the right pin-outs and had to be fly-wired, and the level

A-57


translator did not pull to a high enough voltage for the RF module to read a logical high – in

which case I soldered a SIP resistor as a pull-up to level translator pins in order to pull up the

voltage. Another modification I did was when the team decided to make tilt determine the

movement of the mouse, in which case I simply cut out the additional accelerometer and fly-

wired a resistor onto the ATD in order to use the now open ATD input as another sensor input.

From the homework perspective, I did schematic and theory of operation as my design

component homework and the safety and reliability analysis as my professional component

homework.

A-58


A.2 Contributions of Saad Sami:There are three main areas in which I believe I contributed the most. The first was the

design elements of the project. The second was software development and the third was my role

as a general helper of my teammates. I will elaborate on this position and the other areas of my

contribution in the paragraphs to come.

Having the Design Constraints homework as one of my assignments I believe I played

a crucial role in the design of the project. By taking on this homework I was given the

responsibility of selecting the components to our design. I spent many hours scouring the web in

search of these parts. Oftentimes I would have to contact various vendors on availability of the

product. In the process of selecting certain components such as the microcontroller, I had to

layout how the project would work. My team was of great help during this phase. The layout

included the operation of the device and the peripherals needed on the MCUs to perform these

operations. When selecting components, I verified availability of the product and also took

prototyping the product into consideration. I tried to choose parts that could be breadboarded or

an evaluation board could be found for them.

Another design element of the project was the PCB design. I took upon the task of

designing the PCB layout because it was interesting to me and I believed it to be a valuable asset

to have when working in an industry setting. The process of converting the schematic of our

project into an actual circuit board was a time-consuming task. I began by verifying that all parts

selected had footprints that were well documented in their datasheets. Once this was completed I

began making footprints for the parts not listed in OrCad Layout. I then read various application

notes from Freescale which described proper layout guidelines. I learned about EMI reduction

and the importance of proper grounding, component placement, and trace placement. Using this

knowledge as a guide, I began designing the PCB for the glove and the basestation. After getting

feedback from the design review, I made significant revisions to the designs and ultimately

shrunk both PCBs by considerable amounts. The final PCB designs had no major errors and

performed as expected.

In terms of software development, I wrote the RF code for the basestation and the

glove. Development began on demo boards we had received from Freescale. I first got all of the

RF code to work on the demo boards and I was able to communicate between them. I then

ported the code onto the glove MCU and I was able to verify functionality of it with a GB60

A-59


demo board. We initially were having trouble porting the code to the basestation. I tried writing

a version in assembly to work with the working assembly USB code that Andy had been working

on. Integration between the two was proving difficult. After Andy got the USB code working in

C, we worked together to get the RF code on the base station. After a few hurdles due to

hardware problems, I eventually got the RF code running on the basestation.

My final area of contribution was the role I played in the team. Occasionally, I would

take upon administrator tasks of the team such as setting up the team account, delegating tasks,

ordering parts, and meeting with TA’s and course staff. I tried my best to help the team when in

need by spending a lot of time in lab or in contact with my teammates. I helped others with their

software when possible and eased in their development by performing the soldering work they

required for them. I also soldered most of the basestation PCB and verified its components.

A-60


A.3 Contributions of Andrew Homar:

My contributions mainly focused on software considerations. I was the main developer

of the base station software. I developed the main flowchart for the base station as well as made

significant modifications to the main flowchart for the glove MCU. I initially learned the ropes

of developing C code using Codewarrior. I believe I was used as a software consultant by my

teammates.

One important aspect of our base station MCU was that it did not contain a background

debug mode such that our glove MCU had. We initially thought that it would be fairly simple to

program the base station through the USB port. However this was not the case, I did more

research into this area prior to sending the PCB into fabrication and determined that we would

not be able to debug the software without some serial monitor support. Saad subsequently added

programming headers to support monitor mode onto the PCB.

I then researched methods of actually programming the device. Most methods I came

across were too expensive such as purchasing a Cyclone from P&E. I researched application

notes and found sample monitor mode circuits that we could build. I subsequently built the

programming circuitry necessary for our base station and made it our “demonstration board”. I

spent a significant amount of time battling with our mon08 circuit.

I spent a significant amount of time researching the USB specifications and developed

my own USB code for the microcontroller. I had to research the various USB specifications

such as descriptors necessary to create an HID, as well as a mouse. Most of my time was spent

debugging and trying to get the USB module to communicate to a PC. I eventually succeeded in

communicating with the PC through USB. I eventually had to adapt some demo USB code to

our device and it eventually became a mouse. My knowledge of the various USB descriptors

and the enumeration process as a result of weeks of research resulted in this feat. When the RF

code was complete, I integrated the USB and the RF modules on the base station.

I also assisted in many small areas of the product design. I helped my teammates test

devices and assisted them when in need. I assisted Saad when he needed help with developing

the RF code. I assisted Brian when we needed to tweak the sensor code as well. I also

contributed to the final packaging of the device in the glove. I believe I played a major role in

satisfying two of the five PSSCs, the encoding of the data into windows mouse report format,

A-61


and by demonstration that our device detects wrist movements based on bend sensor data. I was

always available when one of my teammates needed assistance.

A-62


A.4 Contributions of Brian Eng:

My areas of contribution were to general conceptual design, software design,

packaging design, and assisting teammates. During the beginning of the semester, I felt that I

made significant contributions to the conceptual design of our project when we were in the initial

design phases. I laid out the concept of the project, what the functions of the project were, and

how the functions could be implemented.

In terms of software, I made contributions to every piece of code in the project, but

mostly to the glove software. I was responsible for the high level program flow and control of

the glove software as well as programming the glove. The one part that I did not program on the

glove was the accelerometer code. After programming the glove which entailed configuring

peripherals and tweaking and testing the sensor code, I successfully integrated the accelerometer

code into my glove code. This code is the final version of software that resides on the glove.

Moreover, I was active in assisting Andy and Saad with aspects of their software. I spent many

days helping Andy debug his USB code. Several of the problems related to USB was simply not

being able to program the micro. I solved this problem by figuring out that the inability to

program the JB16 was due to certain settings in Codewarrior. I was able to then provide the

solution to this and programming of the JB16 went underway after much delay. Furthermore, I

assisted Saad in his debugging of his RF code. We worked well together in finding bugs in his

code and certain problems may have been overlooked had only one person been working on the

code.

With regards to packaging, I was responsible for choosing the components that would be

part of our final design. I had to weigh several different packaging options and choose the best

mix and match for our specific project.

Overall, I feel my contributions stem from conceptual design, software design, packaging

design, and in general doing lots of little things to help all my teammates out whenever they

needed it.

A-63


Appendix B: Packaging

Figure B-1. Top of Glove Packaging

Figure B-2. Bottom of Glove Packaging

B-1


Appendix C: Schematic

Figure C-1. Glove Controller

Figure C-2. Glove Power Supply

C-1


Figure C-3. Glove Sensors

Figure C-4. Base Controller

C-2


Appendix D: PCB Layout Top and Bottom Copper

Figure D-1. PCB Top Layer (Glove)

Figure D-2. PCB Bottom Layer (Glove)

D-1


Figure D-3. PCB Top Layer (Basestation)

Figure D-4. PCB Bottom Layer (Basestation)

D-2


Appendix E: Parts List Spreadsheet

E-1

Vendor Manufacturer Part No. Description Unit Cost Qty Total CostArrow Electronics Freescale MC9S08GT16 8-Bit MCU – 16K flash, 8 channel ADC 3.82 1 $3.82Digi-Key Freescale MC908JB16FAE 8-Bit MCU – USB 4.60 1 $4.60

Digi-Key Freescale MMA7260Q 3-Axis Accelerometer 10.86 1 $10.86Spark Fun Spark Fun RF-MiRF 2.4 GHz Transceiver Module 19.95 2 $39.90Maxim Maxim MAX884CPA 3.3 V LDO 1.45 1 $1.45Spark Fun Spark Fun Sense-MMA7260Q-PCB Accelerometer Breakout Board 3.95 1 $3.95TekScan TekScan FlexiForce A201 4 Pack of Pressure Sensors 55.00 1 $55.00Maxim Maxim MAX3378EEUD Level Translator 1.86 1 1.86

TOTAL $121.44


Appendix F: Software Listing

BASE STATION SOFTWARE

#include <hidef.h>#include "derivative.h"

#define RF_CLK PTA_PTA5#define RF_DATA PTA_PTA4#define RF_CS PTA_PTA6#define RF_EN PTA_PTA7

//#include <MC68HC908JB16.h>#define cli() asm("cli")#define nop() asm("nop")#define swi() asm("swi")#define TRUE 1#define FALSE 0

//void MCU_init(void);void main(void);void rx_config(void);void rx_rcv(void);

extern void initUSB(void);//extern void rx_config(void); //extern void rx_rcv(void);

const unsigned char cword[] = { 0x20, // Channel 2 Payload Width

0x20, // Channel 1 Payload Width 0x00, // Channel 2 RX Address 0x00, 0x00, 0x00, 0xE7, 0x00, // Channel 1 RX Address 0x00, 0x00, 0x00, 0xE7, 0x23, // Address Width

F-1


0x4E, 0x05};

const unsigned char rx_addr = 0xE7;

unsigned char data[4] = { 0x00, 0x00, 0x00, 0x00};

byte dataready;

/****************************************************** * * rx_config() : Configures the RF Module * ******************************************************/

void rx_config(){ unsigned char i, j; RF_EN = 0; asm("nop"); RF_CS = 1; RF_CLK = 0; RF_DATA = 0; asm("nop"); for (i = 0; i < 15; i++){ for(j = 8; j != 0; j--){ RF_DATA = (cword[i] >> (j - 1)) & 0x01; asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); RF_CLK = 1; asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); asm("nop"); RF_CLK = 0; } } RF_EN = 0; RF_CS = 0; }

/******************************************************

F-2


* * rx_rcv() : Receives data from the module * ******************************************************/

void rx_rcv() { unsigned char i, j, rxdata; RF_EN = 0; RF_CLK = 0; for (i = 4; i != 0; i--) { rxdata = 0x00; for (j = 8; j != 0; j--) { rxdata |= RF_DATA << (j - 1); asm("nop") asm("nop") asm("nop") asm("nop") asm("nop") asm("nop") RF_CLK = 1; asm("nop") asm("nop") asm("nop") asm("nop") asm("nop") asm("nop") RF_CLK = 0; } data[i - 1] = rxdata; } UE1D0 = data[0];//PTA_PTA4; UE1D1 = data[1];//0x00; //PTA_PTA4 << 1; UE1D2 = data[2];//0x00;//PTA_PTA5 << 1; //PTA_PTA4 << 1; UE1D3 = data[3]; UCR1_TP1SIZ=4;

UCR1_T1SEQ^=1; UCR1_TX1E=1; //dataready = TRUE; RF_CS = 0; RF_EN = 1;}//extern unsigned char data[];

interrupt INT_RESET void intReset() { main();}

interrupt 15 void intKBI(){

F-3


PTC_PTC1 = 1; rx_rcv(); KBSCR_ACKK = 1;}

void main() { unsigned int k; // counter for delay loop // RF Setup PTA = 0x00; DDRA = 0xF7; PTA = 0x00; KBSCR_IMASKK = 1; KBIER = 0x08; KBSCR_ACKK = 1; KBSCR_IMASKK = 0; PTC_PTC1 = 0; DDRC_DDRC1 = 1;

CONFIG = 0x21; // USB Reset Disable, COP Disable initUSB(); // init USB

PTC_PTC1 = 1;

// 3 ms Delay loop for (k=0; k < 300; k++) { asm("nop");

}

rx_config(); PTC_PTC1 = 0;

RF_CS = 0; RF_EN = 0;

DDRA_DDRA4 = 0; // Keep original direction, change RF_DATA to input

RF_CS = 0; RF_EN = 1; // Active RX Mode

//

EnableInterrupts;

for(;;) { //__RESET_WATCHDOG(); //PTE_PTE2 = 1; //k++; //data[0] = k; PTA_PTA0 = data[2] & 0x01; PTA_PTA1 = (data[2] & 0x02) >> 1; PTA_PTA2 = (data[2] & 0x04) >> 2; PTC_PTC1 = 0; //PTA_PTA3 = (data[0] & 0x08) >> 3; //if (RF_DR == 1) { // rx_rcv();

F-4


//} }

}

/*************************************************** USB.C***************************************************/

#include <MC68HC908JB16.h> //#include "usb_lowlevel.h"//#include "usb_descriptors.h" #define PULLEN 4

#define ConfigDesc configdescriptors.ConfigDesc1#define InterfaceDesc configdescriptors.InterfaceDesc1#define Endpoint1Desc configdescriptors.Endpoint1Desc1#define HIDDesc configdescriptors.HIDDesc1

#define byte unsigned char

//-- Data Type Definitions ---------------------------------------------------

typedef struct { // Data Type "Intel Word"byte lo; // (High/Low Byte swapped)byte hi;} iword;

//----------------------------------------------------------------------------

// Standard Device Descriptor// according to USB1.1 spec page 197//typedef struct {

byte bLength; // Size of this Descriptor in Bytes

byte bDescriptorType; // Descriptor Type (=1)iword bcdUSB; // USB Spec Release Number

in BCDbyte bDeviceClass; // Device Class Codebyte bDeviceSubClass; // Device Subclass Codebyte bDeviceProtocol; // Device Protocol Codebyte bMaxPacketSize0; // Maximum Packet Size for EP0 iword idVendor; // Vendor ID iword idProduct; // Product IDiword bcdDevice; // Device Release Number in BCDbyte iManufacturer; // Index of String Desc for

Manufacturer

F-5


byte iProduct; // Index of String Desc for Product

byte iSerialNumber; // Index of String Desc for SerNobyte bNumConfigurations; // Number of possible Configurations} device_descriptor;

//----------------------------------------------------------------------------

// Standard Configuration Descriptor// according to USB1.1 spec page 199//typedef struct {


byte bDescriptorType; // Descriptor Type (=2)iword wTotalLength; // Total Length of Data for

this Confbyte bNumInterfaces; // No of Interfaces supported by

this Confbyte bConfigurationValue;// Designator Value for *this* Configurationbyte iConfiguration; // Index of String Desc for this

Confbyte bmAttributes; // Configuration

Characteristics (see below)byte bMaxPower; // Max. Power Consumption in this

Conf (*2mA)} configuration_descriptor;

//----------------------------------------------------------------------------

// Standard Interface Descriptor// according to USB1.1 spec page 202//typedef struct {


byte bDescriptorType; // Descriptor Type (=4)byte bInterfaceNumber; // Number of *this* Interface (0..)byte bAlternateSetting; // Alternative for this Interface (if any)byte bNumEndpoints; // No of EPs used by this IF (excl.

EP0)byte bInterfaceClass; // Interface Class Codebyte bInterfaceSubClass; // Interface Subclass Codebyte bInterfaceProtocol; // Interface Protocol Codebyte iInterface; // Index of String Desc for this

Interface} interface_descriptor;

//----------------------------------------------------------------------------

// Standard Endpoint Descriptor// according to USB1.1 spec page 203//typedef struct {


byte bDescriptorType; // Descriptor Type (=5)

F-6


byte bEndpointAddress; // Endpoint Address (Number + Direction)

byte bmAttributes; // Endpoint Attributes (Transfer Type)

iword wMaxPacketSize; // Max. Endpoint Packet Sizebyte bInterval; // Polling Interval (Interrupt) in

ms} endpoint_descriptor;

//----------------------------------------------------------------------------

// Standard HID Descriptor//typedef struct {


byte bDescriptorType; // Descriptor Type (=5) iword bcdHID; // HID Class specification release number byte bCountryCode; // Hardware target country byte bNumDesriptors; // Number of HID class descriptors to follow byte bRepDescriptorType; // Report descriptor type iword wDescriptorLength; // Total length of Report descriptor

} HID_descriptor;

//----------------------------------------------------------------------------

// Structure of Setup Packet sent during// SETUP Stage of Standard Device Requests// according to USB1.1 spec page 183//typedef struct {

byte bmRequestType; // Characteristics (Direction,Type,Recipient)

byte bRequest; // Standard Request Codeiword wValue; // Value Fieldiword wIndex; // Index or Offset Fieldiword wLength; // Number of Bytes to

transfer (Data Stage)} setup_buffer;

//----------------------------------------------------------------------------

// USB Status Codes//#define US_ATTACHED 0x00 // (not used here)#define US_POWERED 0x01#define US_DEFAULT 0x02#define US_ADDRESSED 0x03#define US_CONFIGURED 0x04#define US_SUSPENDED 0x80

//----------------------------------------------------------------------------

// USB Standard Device Request Codes// according to USB1.1 spec page 187//#define GET_STATUS 0x00

F-7


#define CLEAR_FEATURE 0x01#define SET_FEATURE 0x03#define SET_ADDRESS 0x05#define GET_DESCRIPTOR 0x06#define SET_DESCRIPTOR 0x07 // optional#define GET_CONFIGURATION0x08#define SET_CONFIGURATION0x09#define GET_INTERFACE 0x0a#define SET_INTERFACE 0x0b#define SYNCH_FRAME 0x0c // optional

// USB ClassRequest Codes (HID page 51)#define GET_REPORT 0x01#define SET_REPORT 0x09

#define REQUEST_COMPLETE 0xff // not part of the Standard - just//

a Flag to indicate that the recent//

Request has been finished//----------------------------------------------------------------------------

// Descriptor Types// according to USB1.1 spec page 187//#define DT_DEVICE 1#define DT_CONFIGURATION 2#define DT_STRING 3#define DT_INTERFACE 4#define DT_ENDPOINT 5#define DT_HID 0x21 #define DT_REPORT 0x22

void initUSB(void);void isrUSB(void); extern const device_descriptor DeviceDesc;extern const configuration_descriptor ConfigDesc1;extern const interface_descriptor InterfaceDesc1;extern const byte ReportDesc[62];//extern const byte ReportDesc[50];extern const HID_descriptor HIDDesc1;extern const endpoint_descriptor Endpoint1Desc1;

extern const struct {const configuration_descriptor ConfigDesc1;const interface_descriptor InterfaceDesc1;const HID_descriptor HIDDesc1;const endpoint_descriptor Endpoint1Desc1;

} configdescriptors;

volatile byte USB_State;

volatile byte SuspendCounter;

F-8


setup_buffer SetupBuffer;byte SetupSize;const byte * SetupDataPtr;

extern unsigned char data[4];extern byte dataready;

const device_descriptor DeviceDesc ={sizeof(device_descriptor),DT_DEVICE,{0x10, 0x01},0,0,0,8,{0xFA, 0xFF},{0xFF, 0xFF},{0x01, 0x00},1,2,0,1};

//const byte ReportDesc[50];const byte ReportDesc[62];

const struct {const configuration_descriptor ConfigDesc1;const interface_descriptor InterfaceDesc1;

const HID_descriptor HIDDesc1;const endpoint_descriptor Endpoint1Desc1;

} configdescriptors = {

{sizeof(configuration_descriptor),DT_CONFIGURATION,{sizeof(configuration_descriptor) +sizeof(interface_descriptor) +

sizeof(endpoint_descriptor) + sizeof(HID_descriptor), 0x00},1,1,0,0xA0,0x32},

{sizeof(interface_descriptor),DT_INTERFACE,1,0,1,

F-9


0x3,0x01,0x2,0},

{sizeof(HID_descriptor),DT_HID, {0x01,0x01},0x00,0x01,

DT_REPORT, {sizeof(ReportDesc),0}

}, {sizeof(endpoint_descriptor),DT_ENDPOINT,0x81,0x03,{0x04, 0x00},0x0A}

};

/*

const byte ReportDesc[]= { 0x05,0x01, //Usage Page (Generic Desktop) 0x09,0x02, //Usage (Mouse) 0xA1,0x01, //Collection (Application) 0x09,0x01, //Usage(Pointer) 0xA1,0x00, //Collection (Physical) 0x05,0x09, //Usage Page (Buttons) 0x19,0x01, //Usage Minimum (01) 0x29,0x03, //Usage Maximum (03) 0x15,0x00, //Logical Minimum (00) 0x25,0x01, //Logical Maximum (01) 0x95,0x03, //Report Count (3) 0x75,0x01, //Report Size (1) 0x81,0x02, //Input (Data, Variable, Absolute) 0x95,0x01, //Report Count (1) 0x75,0x05, //Report Size (5) 0x81,0x01, //Input (Constant) 0x05,0x01, //Usage Page (Generic Desktop) 0x09,0x30, //Usage (X) 0x09,0x31, //Usage (Y)// 0x09,0x38, //Usage (Wheel) 0x15,0x81, //Logical Minimum (-127) 0x25,0x7F, //Logical Maximum (127) 0x75,0x08, //Report Size(8) 0x95,0x02, //Report Count(2) 0x81,0x06, //Input (Data, Variable, Relative) 0xC0,0xC0 //End Collection, End Collection };*/

F-10


const byte ReportDesc[]={ 0x05,0x01, //Usage Page (Generic Desktop) 0x09,0x02, //Usage (Mouse) 0xA1,0x01, //Collection (Application) 0x09,0x01, //Usage(Pointer) 0xA1,0x00, //Collection (Physical) 0x05,0x09, //Usage Page (Buttons) 0x19,0x01, //Usage Minimum (01) 0x29,0x03, //Usage Maximum (03) 0x15,0x00, //Logical Minimum (00) 0x25,0x01, //Logical Maximum (01) 0x95,0x03, //Report Count (3) 0x75,0x01, //Report Size (1) 0x81,0x02, //Input (Data, Variable, Absolute) 0x95,0x01, //Report Count (1) 0x75,0x05, //Report Size (5) 0x81,0x01, //Input (Constant) 0x05,0x01, //Usage Page (Generic Desktop) 0x09,0x30, //Usage (X) 0x09,0x31, //Usage (Y) 0x15,0x81, //Logical Minimum (-127) 0x25,0x7F, //Logical Maximum (127) 0x75,0x08, //Report Size(8) 0x95,0x02, //Report Count(2) 0x81,0x06, //Input (Data, Variable, Relative) 0x09,0x38, //Usage (Wheel) 0x15,0x81, //Logical Minimum 0x25,0x7F, //Logical Maximum 0x75,0x08, //Report Size (8) 0x95,0x01, //Report Count(1) 0x81,0x06, //Input (Data, Variable, Relative) 0xC0,0xC0 //End Collection};

void forceSTALL() {UCR3_OSTALL0=1;UCR3_ISTALL0=1;}

#define ENDPOINT_HALT 0x00#define RT_ENDPOINT 0x02

void setAddress() {

if( SetupBuffer.wIndex.hi ||SetupBuffer.wIndex.lo ||SetupBuffer.wLength.hi ||SetupBuffer.wLength.lo ||SetupBuffer.wValue.hi ||(SetupBuffer.wValue.lo & 0x80))forceSTALL();

else {

F-11


// prepare to send empty DATA1 at next IN TransactionUCR0=0;UCR0_T0SEQ=1;UCR0_TX0E=1;}

}

// SET_CONFIGURATION Standard Device Request Handler// called by handleSETUP();//void setConfiguration() {

if( SetupBuffer.wIndex.hi ||SetupBuffer.wIndex.lo ||SetupBuffer.wLength.hi ||SetupBuffer.wLength.lo ||SetupBuffer.wValue.hi ||(SetupBuffer.wValue.lo > 1) ||(USB_State == US_DEFAULT)) {forceSTALL();}

else {if(SetupBuffer.wValue.lo > 0) {

// no need to remember the Configuration Value// since we support only one Configuration anywayUSB_State = US_CONFIGURED;// Activate Interrupt Endpoints, reset STALL and

DATA-ToggleUCR1=0; // EP1 Tx Enable, Data Size is 0UCR1_TX1E=1;}

else {// Zero means: go back to Adressed StateUSB_State = US_ADDRESSED;UCR1=0; // deactivate EP1}

// prepare to send empty DATA1 at next IN TransactionUCR0=0;UCR0_T0SEQ=1;UCR0_TX0E=1;}

}

//----------------------------------------------------------------------------

// GET_DESCRIPTOR Standard Device Request Handler// called by handleSETUP();//void getDescriptor() {

byte n;byte *dest;//onLED(1);switch(SetupBuffer.wValue.hi) {

F-12


case DT_DEVICE: // Get Device DescriptorSetupDataPtr = (byte *)&DeviceDesc;SetupSize = DeviceDesc.bLength;break;

case DT_CONFIGURATION: // Get Configuration DescriptorSetupDataPtr = (byte *)&ConfigDesc;SetupSize = ConfigDesc.wTotalLength.lo;break;

case DT_STRING: // Get String Descriptor forceSTALL();

break;

case DT_HID: SetupDataPtr = (byte *)&HIDDesc; SetupSize= HIDDesc.bLength; break;

case DT_REPORT: // Get Report Descriptor

SetupDataPtr = ReportDesc;SetupSize = sizeof(ReportDesc);break;

default:

forceSTALL();break;

}

if( SetupBuffer.wValue.hi == DT_DEVICE ||SetupBuffer.wValue.hi == DT_CONFIGURATION ||SetupBuffer.wValue.hi == DT_STRING ||

SetupBuffer.wValue.hi == DT_REPORT) {

// check if requested Length is less than Descriptor Lengthif((SetupBuffer.wLength.lo < SetupSize) &&

(SetupBuffer.wLength.hi == 0))SetupSize = SetupBuffer.wLength.lo;

// copy (up to) 8 Bytes to EP0 Data Registersn = 0;dest = (byte *)&UE0D0;while(SetupSize!=0 && n<8) {

*dest = *SetupDataPtr;dest++;SetupDataPtr++;SetupSize--;n++;}

// prepare to send n Bytes as DATA1 at next IN Transaction// Rem: RX0E (currently disabled) will be re-enabled at end

of handleSETUP()UCR0=n;UCR0_T0SEQ=1;UCR0_TX0E=1;// check if this is the last DATA packet to sendif(n < 8) SetupBuffer.bRequest = REQUEST_COMPLETE;}

F-13


}

void do_setup() {

UIR2_RXD0FR=1; // AcknowledgeUCR0_RX0E=0; // Turn off EP0 receiverSetupBuffer = *(setup_buffer *)(&UE0D0);

if(USR0 != 0x48) { // SETUP Transaction must

be DATA0 with Size=8 forceSTALL(); // otherwise we have an Error Condition

} else { if((SetupBuffer.bmRequestType & 0x60) == 0) { // Standard Request Decoder:

switch(SetupBuffer.bRequest) { case CLEAR_FEATURE: // 1

forceSTALL();break;

case SET_ADDRESS: // 5setAddress();break;

case GET_DESCRIPTOR: // 6getDescriptor();break;

case SET_CONFIGURATION: // 9setConfiguration();break;

default:forceSTALL();break;

} } else { forceSTALL(); // Unknown request } }

UCR0_RX0E=1; // Activate EP0 Receiver again}

/********************************************************** Endpoint 0 (cfg) receive data service (new data arrived) **********************************************************/void ep0_rxd() {

byte volatile *src; byte n;

UIR2_RXD0FR=1; // Acknowledge

src = &UE0D0;n = USR0_RP0SIZ; // Check Transfer Size

if(SetupBuffer.bRequest == SET_REPORT) { // Set report

F-14


SetupBuffer.bRequest = REQUEST_COMPLETE;UCR0=0;UCR0_T0SEQ=1;UCR0_TX0E=1;

} // Any other EP0-OUT transactions are ignored

UCR0_RX0E=1; // Activate EP0 receiver again

}

/**************************************************************** Endpoint 0 (cfg) transmit data service (transmit buffer empty) ****************************************************************/void ep0_txd() {

byte n;byte *dest;

UCR0_TX0E=0; // Turn off EP0 transmitter, if any data left, will be turned on later on

UIR2_TXD0FR=1; // Acknowledge

switch(SetupBuffer.bRequest) {case SET_ADDRESS:

UADDR_UADD=SetupBuffer.wValue.lo;UADDR_USBEN=1;if(SetupBuffer.wValue.lo != 0) USB_State =

US_ADDRESSED;else USB_State = US_DEFAULT;SetupBuffer.bRequest = REQUEST_COMPLETE;break;

case GET_DESCRIPTOR:// copy (up to) 8 Bytes to EP0 Data Registersn = 0;

dest = (byte *)&UE0D0;while(SetupSize!=0 && n<8) {

*dest = *SetupDataPtr;dest++;SetupDataPtr++;SetupSize--;n++;}

// prepare to send n Bytes at next IN Transaction// toggle DATA0/1UCR0_TP0SIZ=n;UCR0_T0SEQ^=1;

F-15


UCR0_RX0E=1;UCR0_TX0E=1;// check if this is the last DATA packet to sendif(n < 8) SetupBuffer.bRequest = REQUEST_COMPLETE;break;

case CLEAR_FEATURE:case SET_CONFIGURATION:

// nothing to do - handshake finishedSetupBuffer.bRequest = REQUEST_COMPLETE;

UE1D0 = 0x00; UE1D1 = 0x00; UE1D2 = 0x00; UE1D3 = 0x00; UCR1 = 0x24;break;

case REQUEST_COMPLETE:// Request is finished - just clear the TXD0F Flag

(see above)// and do not re-enable EP0 Transmitter, since there

is no more// data to sendbreak;

default:forceSTALL();break;

}}

/*********************************************************** Endpoint 1 transmit data service (transmit buffer empty) ***********************************************************/void ep1_txd(){

UCR1_TX1E=0; // Deactivate EP1 Transmitter

UIR2_TXD1FR=1;

// UE1D0 = 0x00;//PTA_PTA4;// UE1D1 = 0x01;//data[2];//0x00; //PTA_PTA4 << 1;// UE1D2 = 0x01;//data[1];//0x00;//PTA_PTA5 << 1; //PTA_PTA4 << 1; // UE1D3 = 0x01; //// UCR1_TP1SIZ=4; // UCR1_T1SEQ^=1;

// UCR1_TX1E=1;

}

//----------------------------------------------------------------------------

void initUSB() {

UADDR = 0; // set default address

F-16


UIR0 = 0; // disable InterruptsUIR0 = 0x8B;UIR2 = 0xFF; // clear all Flags in UIR1

UCR0 = 0; // reset EP0UCR1 = 0; // reset EP1UCR2 = 0; // reset EP2

UCR3 = 0x44; // clear TX1ST Flag, enable internal Pull-upUCR4 = 0; // USB normal operation

USB_State = US_POWERED; // powered, but not yet reset

UADDR_USBEN = 1; // enable USB I/F}

// USB Interrupt Handler// All Interrupt Sources of the JB8's integrated USB peripheral// will be treated by this ISR

void interrupt 2 isrUSB() {if(UIR1_EOPF) { // End of Packet detected?

SuspendCounter = 0; // reset 3ms-Suspend CounterUIR2_EOPFR=1; // reset EOP Intr Flag

}if(UIR1_RXD0F) { // any data received via EP0?

if(USR0_SETUP) { // SETUP packet?do_setup(); // go to setup

} else { // or a normal packetep0_rxd(); // receive it

}}

if(UIR1_TXD0F) { // has EP0 sent Data?

ep0_txd();}

if(UIR1_TXD1F) { // has EP1 sent Data? //PTA_PTA5 = 1;

ep1_txd();}

if(UIR1_RSTF) { // USB Reset Signal

State detected?initUSB(); // Soft

Reset of USB SystemsUCR3_ENABLE1=1; // Enable EP1UIR0 = 0x8B; // INT enabled for:

end of packet//

EP0 Rx/Tx Intr Enable and//

EP1 TxUCR0_RX0E=1; // EP0 Receive

Enable

F-17


USB_State = US_DEFAULT; // Device is powered and reset

}}

GLOVE SOFTWARE

#include <hidef.h> /* for EnableInterrupts macro */#include "derivative.h" /* include peripheral declarations */

#define SCROLL_UP 1#define SCROLL_DOWN 2

/*define output in states*/#define ON 1#define OFF 0

/*define RF Control Pins*/#define RF_CLK PTED_PTED0 // TXD1 - J22(5)#define RF_DATA PTED_PTED1 // RXD1 - J22(6)

#define RF_EN PTCD_PTCD4 // PTC4 - J22(2)#define RF_CS PTCD_PTCD5 // PTC5 - J22(3)#define RF_DR PTCD_PTCD6 // PTC6 - J22(4)

/*define Accelerometer 1 Pins (Left) */

F-18


#define GS1 PTAD_PTAD0 // KBIP0 - J20(6)#define GS2 PTAD_PTAD1 // KBIP1 - J20(7)#define ACC_EN PTAD_PTAD2 // KBIP2 - J20(8)#define X2 PTBD_PTBD7 // AD1P7 - J20(3)

/*define Accelerometer 2 Pins (Right) */#define GS1_R PTED_PTED5 // SPSCK1 - J21(6)#define GS2_R PTED_PTED4 // MOSI1 - J21(7) #define ACC_EN2 PTED_PTED3 // MISO1 - J21(8)#define X1 PTBD_PTBD2 // AD1P2 - J21(3)#define Y1 PTBD_PTBD1 // AD1P1 - J21(4)#define Z1 PTBD_PTBD0 // AD1P0 - J21(5)

/* Pressure Sensors */#define SENS_EN PTBD_PTBD6 // AD1P6 - J11#define SENS_EN_2 PTBD_PTBD3 // AD1P3 - J24

/* Bend Sensors */#define LIN PTBD_PTBD5 // AD1P5 - J17 #define RIN PTBD_PTBD4 // AD1P4 - J12

/* Axis Switch */#define AXS PTCD_PTCD0 // TXD2 - J13

/* Extra I/O Pins */#define PA3 PTAD_PTAD3 // KBIP3 - J27#define PA4 PTAD_PTAD4 // KBIP4 - J28#define PA5 PTAD_PTAD5 // KBIP5 - J25#define PA6 PTAD_PTAD6 // KBIP6 - J26#define PA7 PTAD_PTAD7 // KBIP7 - J29

#define PD0 PTDD_PTDD0 // TPM1CH0 - J30#define PD1 PTDD_PTDD1 // TPM1CH1 - J31#define PD3 PTDD_PTDD3 // TPM2CH0 - J32#define PD4 PTDD_PTDD4 // TPM2CH1 - J33

// NOTE: 0 = x axis, 1 = y axis, 2 = z axis

#define AXIS_UP 2 // axis pointing upward during calibration#define UP 0 // orientation of glove - right side up#define DOWN 1 // orientation of glove - upside down

void main(void);

unsigned char counter;unsigned char data[4];

unsigned char click; // SENDunsigned char scroll; // SEND LATER

signed char x_displacement; // SENDsigned char y_displacement; // SEND

const unsigned char cword[] = { 0x20, // Channel 2 Payload Width

0x20, //0x20, // Channel 1 Payload Width

F-19


0x00, // Channel 2 RX Address 0x00, 0x00, 0x00, 0xE7, 0x00, // Channel 1 RX Address 0x00, 0x00, 0x00, 0xE7, 0x23, // Address Width 0x4E, 0x04};

const unsigned char rx_addr = 0xE7;

interrupt Vreset void intReset(){ main();}

void MCU_init(void); /* Device initialization function declaration */

void tx_data() { unsigned char i, j; // data[0] = counter; //0x12; // ~(PTFD) & 0x0F;// data[1] = counter; //0xB3; // ~(PTFD) & 0x0F;// data[2] = counter; //0xE7; // ~(PTFD) & 0x0F;// data[3] = counter; //0x81; // ~(PTFD) & 0x0F; data[0] = click; data[1] = x_displacement; data[2] = y_displacement; data[3] = scroll; RF_EN = 1; RF_CS = 0; for (i = 8; i != 0; i--){ RF_DATA = (rx_addr >> (i - 1)) & 0x01; RF_CLK = 1; RF_CLK = 0; } for (i = 4; i != 0; i--){ for(j = 8; j !=0; j--){ RF_DATA = (data[i - 1] >> (j - 1)) & 0x01; RF_CLK = 1;

F-20


RF_CLK = 0; } } RF_EN = 0; RF_CS = 0;}

void tx_config(){ unsigned char i, j; RF_EN = 0; RF_CS = 1; for (i = 0; i < 15; i++){ for(j = 8; j != 0; j--){ RF_DATA = (cword[i] >> (j - 1)) & 0x01; RF_CLK = 1; RF_CLK = 0; } } RF_EN = 0; RF_CS = 0;}

void main(void) {// Array index reference// 1 = x axis 1// 2 = x axis 2// 3 = y axis// 4 = z axis unsigned char acc[3]; unsigned char ss[3]; // steady state value unsigned char dir[3]; unsigned char upthres = 80; unsigned char zythres = 20; unsigned int k = 0; // loop variable unsigned char click_pressure; unsigned char click_bend_L; unsigned char click_bend_R; unsigned char scroll_bend; signed char cursor_speed; //unsigned char click; // SEND //unsigned char scroll; // SEND LATER unsigned char count_HIGH; unsigned char count_LOW; //signed char x_displacement; // SEND //signed char y_displacement; // SEND counter = 0; // set up freq for 34.714285714285714285714285714286 kHz ICGC1 = 0x28;

F-21


ICGC2 = 0x35;

for (k = 0; k < 3; k++) { ss[k] = 0; dir[k] = 2; acc[k] = 0; } dir[AXIS_UP] = 0; // 0 for right-side up, 1 for upside down

/* Uncomment this function call after using Device Initialization to use the generated code */ /* MCU_init(); */ EnableInterrupts; /* enable interrupts */

/* include your code here */

// first, enable Ports on B as ATD inputs by setting the ATD Ctrl byte (ATD1C) and ATD1C_ATDPU = 1; // ATD Power Up ATD1C_DJM = 1; // Result register data is right justified ATD1C_RES8 = 1; // 8-bit resolution ATD1C_PRS = 0x0; // Prescaler Rate Select...dunno what to choose for this yet // ATD Status and Control byte (ATD1SC) and ATD1SC_ATDIE = 0; // do not enable ATD interrupt. we want to poll the CCF bit instead ATD1SC_ATDCO = 0; // continuous conversion mode off...dunno what to choose for this yet // ATD Pin Enable (ATD1PE) ATD1PE = 0xFF; // enable all port B pins for ATD usage for now

PTADD = 0xFF; PTEDD = 0xFF; PTCDD = 0x70; // RF RF_EN = 0; RF_CS = 0; RF_CLK = 0; RF_DATA = 0; GS1 = OFF; GS2 = OFF; GS1_R = OFF; GS2_R = OFF; ACC_EN = ON; ACC_EN2 = ON;

F-22


// make axis header output for debugging PTCDD_PTCDD0 = 1;

// begin calibration, glove must be LEVEL

for (k = 0; k <= 10000; k++) { asm("nop"); }

ATD1SC_ATDCH = 0x00; // select ATD channel 0 while (ATD1SC_CCF == 0) { } ss[2] = ATD1RH; // z1 ATD1SC_ATDCH = 0x01; // select ATD channel 1 while (ATD1SC_CCF == 0) { } ss[1] = ATD1RH; // y1

ATD1SC_ATDCH = 0x02; // select ATD channel 2 while (ATD1SC_CCF == 0) { } ss[0] = ATD1RH; // x1 // end calibration tx_config(); RF_CS = 0; RF_EN = 0; /*** TPM1SC - TPM 1 Status and Control Register; 0x00000030 ***/ TPM1MODH = 0xFF; // sets the timer modulo value TPM1MODL = 0xFF; TPM1SC_CLKSA = 1; //use bus clk for now TPM1SC_CLKSB = 0; TPM1SC_CPWMS = 1; TPM1SC_TOIE = 0; TPM1SC_PS0 = 0; TPM1SC_PS1 = 0; TPM1SC_PS2 = 0; for(;;) { __RESET_WATCHDOG(); /* feeds the dog */ counter++; count_HIGH = TPM1CNTH; count_LOW = TPM1CNTL;

ATD1SC_ATDCH = 0x00; // select ATD channel 0 while (ATD1SC_CCF == 0) { }

F-23


acc[2] = ATD1RH; // z1 ATD1SC_ATDCH = 0x01; // select ATD channel 1 while (ATD1SC_CCF == 0) { } acc[1] = ATD1RH; // y1

ATD1SC_ATDCH = 0x02; // select ATD channel 2 while (ATD1SC_CCF == 0) { } acc[0] = ATD1RH; // x1

for (k = 0; k < 3; k++) { if(k == AXIS_UP) { if ((ss[k] > acc[k] + upthres) && (dir[k] == 0)) { dir[k] = DOWN; // upside down } else if ((acc[k] + 10 > ss[k]) && (dir[k] == 1)) { dir[k] = UP; // rightside up; } } else { if (ss[k] > acc[k] + zythres) { dir[k] = 0; } else if (acc[k] > ss[k] + zythres) { dir[k] = 2; } else { dir[k] = 1; // stable } } }

/************************************************************************** * * CAPTURE PRESSURE/BEND SENSORS (CLICK DETECTION) * **************************************************************************/ ATD1SC_ATDCH = 0x03; // select ATD channel 3 - pressure sens (click en) J24 while (ATD1SC_CCF == 0) { } if(ATD1RH > 30) { // was 80 click_pressure = 1; } else click_pressure = 0;

ATD1SC_ATDCH = 0x05; // select ATD channel 5 - right click bend sens J17 while (ATD1SC_CCF == 0) { }

F-24


if(ATD1RH < 111) { click_bend_R = 1; } else click_bend_R = 0; cursor_speed = 0; ATD1SC_ATDCH = 0x06; // select ATD channel 6 - left click bend sens J11 while (ATD1SC_CCF == 0) { } if(ATD1RH < 111) { click_bend_L = 1; if(ATD1RH > 45 && ATD1RH < 49) { cursor_speed = 1; } else if(ATD1RH > 49 && ATD1RH < 55) { cursor_speed = ATD1RH - 47; } else if(ATD1RH > 55) { cursor_speed = 10; } } else click_bend_L = 0; /************************************************************************** * * CAPTURE BEND SENSOR (SCROLLING) * * NOTE: we need to flywire a 20K ohm resistor from pin 29 to GND * **************************************************************************/ ATD1SC_ATDCH = 0x07; // select ATD channel 7 - scroll bend sens while (ATD1SC_CCF == 0) { } if(ATD1RH < 111) { scroll_bend = 1; } else scroll_bend = 0; /************************************************************************** * * CAPTURE PRESSURE SENSOR (CURSOR SENSIVITIVTY) * **************************************************************************/ ATD1SC_ATDCH = 0x04; // select ATD channel 4 - cursor pressure sens J12 while (ATD1SC_CCF == 0) { } if(ATD1RH > 45 && ATD1RH < 49) { cursor_speed = 1; } else if(ATD1RH > 49 && ATD1RH < 55) { cursor_speed = ATD1RH - 47; } else if(ATD1RH > 55) { cursor_speed = 10; }

F-25


//if(cursor_speed > ) cursor_speed = 123; // MAKE SURE U DONT HAVE NEG NUM < -127 OR A POS # > 127 /************************************************************************** * * PROCESS THE FLAGS - are we allowing a L + R click on the same clock? * i think we should screw sleep mode cuz of the acc * noise and what if the person wants to click in the * same spot over and over after sleep is enabled? * **************************************************************************/ click = 0x00; // if click_pressure && click_bend_L then set left click if(click_pressure && click_bend_L) click |= 0x01; // if click_pressure && click_bend_R then set right click if(click_pressure && click_bend_R) click |= 0x02; // if scroll_bend && palm_down then set scroll down // if scroll_bend && palm_up then set scroll up if(scroll_bend && (dir[0] || dir[0] == 2)) scroll = -2; // scroll down else if(scroll_bend && dir[0] == 0) scroll = 2; // up else scroll = 0; // displacement processing now if(dir[0] == 0) x_displacement = cursor_speed; // move to the right else if(dir[0] == 2) x_displacement = -1 * cursor_speed; // move to the left else x_displacement = 0; if(dir[1] == 0) y_displacement = cursor_speed * -1; // move up else if(dir[1] == 2) y_displacement = cursor_speed; // move down else y_displacement = 0; /* if(dir[0] == 0) x_displacement = 3; // move to the right else if(dir[0] == 2) x_displacement = -3; // move to the left else x_displacement = 0; if(dir[1] == 0) y_displacement = 3; // move up else if(dir[1] == 2) y_displacement = -3; // move down else y_displacement = 0; */ tx_data(); } /* loop forever */

F-26


/* please make sure that you never leave this function */}

F-27


Appendix G: FMECA Worksheet

Failure No.

Failure Mode Possible Causes Failure Effects Method of Detection

Criticality Remarks

A1 Output = 0 Failure of C1,C2,C4,C5,R1,R4,U1, D2

Battery terminalswill be shorted

Observation High Will cause battery to overheat and may burn the user

A2 0V < Output < 3.3V

Failure of L1, D1 Causes step up converter to output the battery supply voltage

Observation Low Circuit still works, but will not run as long due to inefficient use of batteries

A3 Output > 3.3V Failure of R3 Causes step-up converter to output its highest capable voltage (5.5V)

Observation High Will overheat and damage MCU, RF module, and accelerometers

B1 Output = 0 Failure of U7, C23, C24

USB power rails shorted

Observation High Will overheat the regulator (max 500mA through board)

B2 Output out of tolerance

Failure of C23, C24 RF may not work properly

Observation Low Circuit still works, but problems may occur with receiving signals from glove

G-1


Failure No.


Criticality Remarks

B3 Output = 5.0V Failure of U7 RF module will overheat.

Observation High None

C1 Noisy signal from USB

Failure of R15, C18, C19

MCU will overheat

Observation High None

C2 MCU not functioning properly or not at all

Failure of X1, C16, C17, U5, Software

Designed circuit does not function

Observation Low None

C3 MCU not receiving hardware interrupt request from RF unit

Failure of Q2, RF Module, U5, Software

MCU cannot communicate with the glove.

Observation Low It’s possible that the IRQ hasn’t been set to active pull-up mode. (Software issue)

E1 Output = 3.3V Failure of VR1, VR2, VR3

Can’t read clicking movements


G-2


Failure No.


Criticality Remarks

E2 Output = 0V Failure of R11, R12, R13, R14, R17

Can’t read clicking movements


E3 Noisy signal from sensors

Bad header connection

Unpredictable clicking

Observation Low Noisy signal may cause unintended mouse clicking

D1 Unable to read RF output

Failure of U7 (voltage regulator), C23, C24, Q2 (NMOS), U6 (level translator)

No communication between glove and base.

Observation Low No functionality

D2 Noisy signal from RF output

Bad header connection

Unpredictable mouse movement and clicking

Observation Low Incoming bit in a packet may be read as a 1 instead of 0, or vice versa.

F1 MCU not functioning properly or not at all

Failure of C12, C13, C14, U4

Designed circuit does not function


G-3

Documents

EE 477 Final Report · Web viewSurface mount parts are utilized for major components to further reduce on size and a battery connector allows for the battery compartment to be placed