Retrieve Documentaux.coe.utsa.edu/~eesenior/fall2009/Team07/documents... · Web viewDavid Sanchez and Raul Ramos where given the task of integrating the ultrasonic sensor and

Final Report

Self Monitoring Parking Meter

December 3rd, 2009

Prepared for

Mr. August Allo University of Texas at San Antonio 6900 N. Loop 1604 West San Antonio, TX 78249 (210) 458-7753 (210) 458-5947 (Fax)

Prepared by

Design Team #7 David SanchezRaul G. RamosJoshua TorreyJesus Luna

Table of Contents1.0 Executive Summary.........................................................................................................................5

2.0 Introduction.....................................................................................................................................6

3.0 Need Being Addressed.....................................................................................................................8

4.0 Literature and Patent Search Results...............................................................................................9

5.0 Marketing Analysis and Market Strategy.........................................................................................9

5.1 Market Need................................................................................................................................9

5.2 Segmented Target Markets.......................................................................................................10

5.2.1 Universities........................................................................................................................10

5.2.2 Cities..................................................................................................................................10

5.2.3 Parking Garages.................................................................................................................11

5.3 Market Growth..........................................................................................................................11

6.0 Engineering Design Constraints.....................................................................................................11

6.1 Global Constraints.....................................................................................................................11

6.2 Local Constraints........................................................................................................................12

7.0 User Requirements........................................................................................................................13

8.0 Engineering Codes and Standards.................................................................................................14

9.0 Design Concepts............................................................................................................................15

10.0 Product Specifications...................................................................................................................18

10.1 User Specifications.....................................................................................................................18

10.2 Hardware Specifications............................................................................................................19

11.0 Operational Scenarios....................................................................................................................20

11.0.1 Proper Operation...................................................................................................................20

11.0.2 Improper Operation...............................................................................................................20

12.0 High Level Block Diagram...............................................................................................................21

Team #7 Electrical Engineering Design 2 Page 2

13.0 Major (Critical) Components..........................................................................................................22

13.1 Microcontroller – Arduino Mega...............................................................................................22

13.2 XBee Module.............................................................................................................................23

13.3 Ultrasonic Sensor.......................................................................................................................23

13.4 Graphical User Interface (GUI)...................................................................................................25

14.0 Detailed Design..........................................................................................................................25

14.1 Hardware...................................................................................................................................25

14.1.1 Microcontroller..................................................................................................................25

14.1.2 Wireless Modules..............................................................................................................26

14.1.3 Ultrasonic Sensor...............................................................................................................27

14.1.4 Push Button........................................................................................................................27

14.2 Software....................................................................................................................................27

14.2.1 Microcontroller Programming..........................................................................................27

14.2.2 GUI Programming..............................................................................................................29

14.3 Engineering Analysis and Calculations...........................................................................................32

14.3.1 Ultrasonic Sensor Calculations...........................................................................................32

14.3.2 GUI Calculations.................................................................................................................33

15.0 Major Problems.............................................................................................................................35

16.0 Integration and Implementation...................................................................................................36

16.1 Integration.................................................................................................................................36

16.1.1 Preparation Phase..............................................................................................................37

16.1.2 Design Phase......................................................................................................................37

16.1.3 Testing Phase.....................................................................................................................38

16.1.4 Completion Phase..............................................................................................................38

16.2 Implementation.............................................................................................................................38

16.2.1 Ultrasonic Sensor...............................................................................................................38

16.2.2 Arduino Mega....................................................................................................................39

16.2.3 Arduino Mega and Ultrasonic Sensor Communication......................................................39


16.2.4 XBee Communication.........................................................................................................39

16.2.5 Arduino Board, Ultrasonic Sensor and XBee Modules Communication.............................40

16.2.6 Push Button........................................................................................................................40

16.2.7 LED Display.........................................................................................................................41

16.2.8 Graphical User Interface (GUI)...........................................................................................42

17.0 Comments and Conclusion............................................................................................................43

18.0 Team Members..............................................................................................................................44

18.0.1 Joshua Torrey.........................................................................................................................44

18.0.2 Raul G. Ramos........................................................................................................................44

18.0.3 David Sanchez........................................................................................................................44

18.0.4 Jesus Luna..............................................................................................................................45

19.0 References.....................................................................................................................................45


1.0 Executive SummaryTeam Seven of the Senior Design II course has developed a system that provides real

time information of parking spaces throughout parking lots. The purpose of this project was to

design a more efficient system of parking meter enforcement to replace the extremely out of date

current system with today’s technology to make this task more efficient. Furthermore, the new

design will feature a system of parking meters that automatically detect illegally parked vehicles,

and alert the violation to a base station in which the officers would be present. Additionally, a

Graphical User Interface (GUI) would provide the results from the base station to handheld

devices to notify patrolling officers of any illegally used parking spaces. The result? Large

metropolitan areas require less manpower and resources to maintain their current parking

locations. For the purpose of this project, the vehicle detection phase incorporated an ultrasonic

sensor. This was decided upon after reviewing budget constraints of all team members. The

small ultrasonic sensors are less expensive and provide a proof-of-concept model that could be

significantly upgraded with better sensor equipment. In an effort to simulate the functionality of

a parking meter, a push button was integrated into the design to simulate a coin deposit. In terms

of hardware, a microcontroller was implemented to acquire both the sensor and push button

input, it also controls which states the parking space is in. In conclusion, the system includes

wireless communication between the data acquired by the parking meter and the base station, so

no long cables were necessary for this system. According to the original proposal submitted by

Team Seven, a team composed of four Electrical Engineering senior students, the description

above was included and targeted to be finished in mid November. Figure 1 illustrates the final

design.


Figure 1 Final Design

2.0 Introduction Parking station monitoring has become a larger priority as the economy pulls people

closer to their jobs and cities. Proper use of these Parking Stations is both helpful to the citizens

who wish to use them and also to the companies that have invested in building them. Similarly,

cities are looking for ways to increase revenue without once again increasing the fee amount per

traffic fine. Reducing the number of unaccounted violations and fine challenges remains the

largest area of financial growth to be obtained. With this in mind, the concept of a new

monitoring parking station should reduce illegal parking while increasing parking violation

profits.

In preparation for this proposal, market analysis and user design needs were considered in

developing a hard-list of design requirements. These requirements helped form the necessary

design constraints for the design process of the Parking Meter. Other tasks such as patent

searches, design alternatives and block diagrams helped formulate a cohesive top-level view of


the design in preparation for a detailed design analysis. These tasks provided much of the

material and information contained in this proposal.

Each team member provided a key asset to the design of the parking meter. With each

member of the team capable of handling unique portions of the design, no single member was

called upon to deliver more than the others. This resulted in an efficient and productive schedule

as well as completion of all deliverables. David Sanchez provided DSP experience to both the

ADC & DAC development of the design. Furthermore, Mr. Sanchez was in charge of all the

documentation required for the team. Raul Ramos utilized his Matlab and Controls experience

to develop the Graphical User Interface (GUI). Mr. Ramos also served as the administrative

portion of the design. Joshua Torrey made use of his professional Computer Design and

Programming experience in coding the microcontroller, he also was in charge of the website

development for the group. Likewise, Jesus Luna had knowledge in computer programming and

made a strong positive impact to the microcontroller interfacing. The detailed view of the

schedule will be shown on Figure 2.


3.0 Need Being AddressedIn recent years, parking has become a serious problem under the increase of motor

vehicles. A new monitoring system for parking meters is needed for today’s transportation

system. The current system of parking meter enforcement consists of several parking officers

manually checking each meter, trying to catch illegally parked vehicles. The new parking meter

system would be marketed to large metropolitan areas for example: Universities, Cities, and

Parking Garages. They all have different mechanisms to which the system was implemented. In

universities and cities the new system will improve the quality of how officers will receive

information of any illegally parked vehicles. Reducing labor time and improving parker

convenience are the main focuses to implement this new system.


Figure 2 Team Schedule for Self Monitoring Parking Meter

4.0 Literature and Patent Search ResultsIn the early stages of the project, Engineering Standards and current patents/technologies

were researched to consider what was already in the field. Most applications of car detection

were in regards to parking facilities with monitoring at the entrance or exits or the generic

vehicle detection at a stoplight. In both of these cases, induction coils are placed in the cement,

which is both costly, and not in a position to produce direct financial benefits. However the

application of this new system is in a field of substantial profit. Taking advantage of this,

different types of implemented sensors are capable of being positioned individually in each

space. It at this point that the entire system of the project exceeds and of the patent information

researched. Another process that was taken into consideration is the system utilized by

automobiles RFID tags, which uses ultrasonic sensors to acquire data of any close objects one

might be approaching. Use of RFID tags is safely within all Engineering Standards and RFID

tags are found in many different patented technologies. However in that model, instead of the

sensor moving, the sensor is placed statically and when the presence of a car is detected it sends

a signal to the system. This model is more effective for garage monitoring and not open location

parking system (downtown, schools, etc).

5.0 Marketing Analysis and Market StrategyThe new parking meter system would be marketed to highly populated areas, including

but not limited to Universities, Cities, and Parking Garages. Each market would utilize the

current design idea in the way most profitable to their existing circumstances. In Universities and

Cities the new system would improve the speed at which officers are alerted of illegally parked

vehicles. This reduces the amount of paid labor hours while improving the correct usage of

parking space, both major factors in the implementation of this new system. In Parking Garages,

the system would be used solely for the purpose of relaying available parking locations to

incoming vehicles.

5.1 Market Need

Parking meters are a key element in both the transportation market and a cities’ citation

revenue. With respect to transportation, there are limited numbers of parking spaces available in

every metropolitan area, and they are frequently in high demand by users. Development of a new


parking meter system increased the precision of detecting any illegally parked vehicles and

provides better access for those willing to pay for the spots. With respect to citation revenue,

cities across the United States have slowly been increasing the citation fees for illegal parking. It

has become a viable source of increase in revenue. With this new design, cities were capable of

again increasing their citation revenue without increasing parking fees. Along with these

increases in fees, the increase in citations challenged has also gone up. These challenges result

in consistently lost revenue through the legal system. This new parking detection system would

provide the cities with a reliable, consistent, and overwhelming case against such challenges,

seeking to neutralize them and further increase the revenue collected.

5.2 Segmented Target MarketsThe market strategy targeted:

5.2.1 UniversitiesThe improved system can be implemented on any withstanding university parking meter

system. This simple detection system along with passing notification to the limited patrolmen

makes the system perfect for campus use.

Servicing the parking needs of large campuses has been one of the biggest challenges

facing universities as the number of students seeking parking spaces continues to rise.

Universities have slowly utilized park and pay stations for several years now. This system would

allow more Universities to confidently include additional park and pay stations.

5.2.2 CitiesFor cities, the improved system will work seamlessly with both older and modern parking

meters. Parking has implications on business viability, economic development, public safety and

quality of life for metropolitan residents. It is also an integral part of the city's land use and

transportation initiatives. Effective parking management is a key issue in determining the vitality

of a city.

The current system has drawbacks of being manually operated, non-uniformly controlled

and inefficient in terms of revenue collection and control. Patrolmen currently cover all parking

locations, serving as the cities form of parking meter enforcement. The new system is based


upon a more competent means of doing the same enforcement. This will lead to more revenue

and better quality public service for all participating cities.

5.2.3 Parking GaragesThe updated system can also be incorporated to parking garages. Since the new system

will give real time feedback to a base computer, it can provide real time information to the

vehicles entering the parking garage, allowing them to see available parking spaces that are

conveniently close and vacant.

With the growing demand for parking garages where small area and high efficiency are

needed, an improved system for the users of these parking garages will need to be developed.

5.3 Market GrowthMetropolitan areas are experiencing exponential growth as the economy once again

brings people closer to where they work. This city growth will increase the demand for more

effectively monitored parking spaces. It was anticipated that a demand for our product will

increase as communities seek to cut-down on expenses. Furthermore, the demand for this

product was not limited by the bounds of the U.S. market. The market range of this product

consists of any city in the world facing the need for more parking location efficiency. Different

laws will be applied in different markets towards the use of our product, but should represent no

loss in demand since this system was cost effective and precise. This product will market itself

once incorporated.

6.0 Engineering Design ConstraintsThere were many factors that were considered in the design process of the Self

Monitoring Parking Meter. The team considered two types of constraints which are global and

local. Listed below are the subsections of these constraints.

6.1 Global Constraints Economic Factors

The economic constraint applied to this system because the total cost was limited due

to a lack of funding. The final product would also benefit the marketed buyer in

increasing their revenue.

Environmental EffectsTeam #7 Electrical Engineering Design 2 Page 11

This constraint did not apply to this system since we are utilizing sensors that do not

interfere with the environment. For communication the system utilized wireless

modules so no need for long cables is required.

Sustainability

The system was affected by this constraint since there are a fixed number of parking

meters. The market will increase as this new parking is implemented in large

metropolitan areas.

Manufacturability

The Self Monitoring Parking Meter was not a constraint by this since the system

requires few electronic components; this should not be a complex manufacturing

process.

Ethical Consideration

The constraint should not apply to this system due to the fact that it provides the

required data to know all the parking violations.

Health & Safety

The constraint should apply in the manufacturing stage of the system. Likewise the

disposal of electronic components required stringent exposure requirements but the

use of the product was not created health or safety issues.

Social Ramification

The product was constrained in a positive way since it encouraged the proper parking

procedure from citizens therefore it will be beneficial effects on society.

Political Factors

The increase of parking fines with this new system was not a good political campaign

throughout the different states.

Legal Issues

Currently the status quo does not infringe on any patents and the idea for the product is

already patented. A careful design procedure was limited by the legal issues this

product incurred but the potential is there.

6.2 Local Constraints Cost


The cost was constrained to this system because the cost cannot exceed the budget

received for production. There was currently no ability to raise capital for this project.

Schedule

This project was constrained by schedule because the team must have a working

prototype to demonstrate at the end of the Senior Design II course.

Manufacturability

This system was constrained by the limited amount of hands-on skills that the team

members have acquired throughout their careers.

Engineering codes and standards

The product has abided by all codes & standards when in use. The team modified any

steps required to meet all standards.

Ethical considerations

Even as students under UTSA’s Senior Design program, this does not bring ethical

issues for the students or the university.

Health and safety issues

The team member’s and user’s safety was an important constraint in the system.

Lead-free solder and adopting other RoHS standards during the manufacturing stage of

the system helped avoid any minimal impact on this constraint.

Legal

There are no legal issues that stems from the production of the system. It was

important that the system was properly tested to reduce any chance of being liable.

7.0 User RequirementsThe Self-monitoring parking meter was designed to meet many user requirements. Listed

in the subsection below are those user requirements incorporated in the design.

1. The user must be able to read accurate data from each parking space.

2. The user must be able to reset the system from the parking location.

3. The user must be able to deactivate the system for servicing.

4. The user must be able to reset the device in case of accidental readings.

5. The device must have an easily replaceable backup power.


6. The device must not stand out in any way out of the ordinary.

7. The device must be easy to install to existing fixtures.

8. The system must communicate wirelessly.

9. The system must not interfere with any other frequencies in the ambient.

10. The device must be able to power to a 100~127V @60 Hz supply source in North

America.

11. The device must be able to power to a 220~240 V @50 Hz supply in rest of the world.

12. The software must provide a user-friendly graphical interface.

13. The device must provide real-time status information.

14. The device must be weather-resistant to endure changing weather conditions.

15. The sensor must be enclosed within the parking meter to prevent vandalism.

16. The wireless module antenna must protrude the parking meter for best performance.

17. The system must conform to FCC regulations for wireless communications.

18. The system must require little maintenance.

19. The system must be expandable and customizable.

20. No custom parts should be used to construct the system.

21. The system must be able to recalibrate on its own.

22. The system must be reliable.

8.0 Engineering Codes and StandardsThe design was developed to conform to all applicable engineering codes and standards.

Below is a list of the engineering standards referenced for the project:

IEEE Standard 802.15.4-2006

Description

This IEEE standard specifies the physical layer and media access control (MAC) for low-rate

wireless personal area network1.

Type

Regulatory Standard


Conforming Components

XBee wireless modules

Restriction of Hazardous Substances Directive (RoHS)

Description

RoHS is often referred to as the lead-free directive, but it restricts the quantity used to

create a device by setting a maximum concentration within the following six substances:

Hexavalent chromium (1,000 ppm max)

Poly-brominated biphenyls (1,000 ppm max)

Poly-brominated diphenyl ethers (1,000 ppm max)

Cadmium (100 ppm max)

Mercury (1,000 ppm max)

Lead (1,000 ppm max)

Type

European Union Regulatory Standard

Conforming Components

XBee wireless modules

7-Segment Serial Display

Ultrasonic Range Finder – Maxbotix LV EZ1

XBee Breakout Board

9.0 Design ConceptsThe design idea involved developing an upgrade to or replacement for the current parking

meter system that can detect when a vehicle was illegally parked. In the current detection phase

an ultrasonic sensor was considered as it was the cheapest technological option. When the

detection circuit senses an illegally parked car, the parking location monitor where the violation

occurred transmits to a computer based network station. The central computer acting as the home

network would contain real time data of any illegal parking and would be available at all times.


This home network would also retain previous violation information to help monitor and track

trouble locations.

The first concept considered was a wireless network consisting of a base computer and

varying quantity of parking location monitors (transmitters). Parking location monitors, using

ultrasonic sensor, were to be an addition to current parking meters. Handheld devices consisted

of original design and software similar to that on the base computer.

The second concept considered was a wired network consisting of a base computer, and a

varying quantity of parking location monitors. Parking location monitors, using ultrasonic

sensor, were to be an addition to current parking meters. All parking notification information was

reported via walkie-talkies, removing the need for wireless handheld devices.

The third concept considered was an entirely digital, and wireless, network designed from

the ground up at the parking meter phase; consisting of a base computer, a varying quantity of

parking location monitors (transmitters), and multiple handheld patrol devices (receivers).

Parking location monitors, using ultrasonic sensor, were to be an addition to current parking

meters.

For this matrix, the highest weight factors are attributed to Cost, Schedule, and Effective

Range. Effective Range was considered the essential constraint given the natural market usage of

our current design idea. Our design idea seeks to cover, efficiently, the most parking locations

(area) possible. Cost and Schedule was also important constraints on us as students with only one

semester to construct our design. After these constraints; Convenience, Resistance to Weather

and Conforming to Engineering Standards are the next highest weighted. Convenience of Usage

helped reduce the number of patrolmen needed to monitor all parking locations. Resistance to

Weather considers the effect weather could have on the efficiency of our violation data transfer

and on the physical structure of our design devices. Communication Interference, Complexity,

Product Implementation, Power Consumption and Sustainability rounded out the lower half of

our constraints, yet measure the marketability of the current design idea. However, they do not

apply as strongly to the current design idea in view of a Senior Design Project’s parameters. In

comparison, the Wired and Wireless Upgrade designs were the most highly rated. The Cost and

Schedule factors highlighted ease and low-cost of the Wired System Design. Convenience of


Usage heavily favored our Wireless Upgrade design while Resistance to Weather supported the

Wired Upgrade design. The Pugh Matrix is illustrated in Figure 3.

Pugh Matrix

Design Constraint

Weight

Factor Design 1 Design 2 Design 3

Cost 11 7 10 4

Effective Range 11 9 5 9

Resistant To Weather 10 8 10 8

Communication Interference 8 8 10 8

Complexity 5 7 8 5

Conform To Eng. Code & Stand. 10 10 10 10

Product Implementation 8 7 8 6

Power Consumption 8 7 8 9

Convenience Of Usage 10 10 6 10

Sustainability 7 8 5 9

Schedule 12 7 9 4

Total 100 807 816 743

Figure 3 Pugh Matrix


Ultimately, the matrix valued both the Wireless and Wired Upgrade Options similarly.

For the purpose of this class the team decided to move forward with the Wireless Upgrade

Option, as it was the option that best displayed our design skills.

10.0 Product SpecificationsThe system design consists of a few market-required components that are critical to

provide excellent functionality and sustain marketability. By evaluating the multiple markets the

system seeks to reach, the team compiled a list of all requirements. The ones deemed most

important are discussed in detail within their proper field.

10.1 User SpecificationsWireless Communication:

Description:

The system should be capable of handling wireless communication from multiple parking

locations to a main hub station.

Criticality:

A reliance on wires or other physical constructs make the design inapplicable to cities

and schools where underground laying of required transfer equipment is unacceptable.

Technical Issues:

Wireless communication modules are required within every location-monitoring package.

This increases the total cost to monitor each location.

PDA/Handheld GUI:

Description:

The system should provide accurate and up to date information on all monitored locations

in an easy to read GUI. This GUI should be capable of being run on a Handheld or PDA device.

Criticality:


To allow for proper violation documentation, as well as reduce the need for patrol

officers in the field, the GUI must satisfy all information needs required for the city or university

to write up a violation without risk/fear of legal liability.

Technical Issues:

GUI based writing for multiple platforms is a complicated and tedious process. For this

design, a Simulink example has been designed to show what the GUI would need to provide for

in-field use.

10.2 Hardware SpecificationsCompatibility with Analog & Digital Parking Meters:

Description:

Given the many forms of parking meters, the system should be capable of being infused

with any current parking meter system. This includes analog and digital individual park meters

as well as large pay station meters that are becoming popular.

Criticality:

Being able to reach every technological market of the parking meter industry is essential

for good marketability and sustainability.

Technical Issues:

Since all modern parking meters are digital in nature, the system is designed to handle

digital inputs. For analog systems, most contain or simplify down to digital signals at some point

in the system and are easily feasible.

Sensor Upgrades:

Description:

Providing multiple sensor options to allow for cost control abilities to users.

Criticality:


The ability to provide users with multiple detection sensor methods is essential in

reaching the many different types of coverage units required. Allowing users to reduce cost or

improve power efficiency provides the user satisfaction needed to sustain sales.

Technical Issues:

The system design is capable of handling all sensor input. It is the microcontroller code

that must be unique to each sensor input. This code can easily be changed and set for each sensor

type made available.

11.0 Operational ScenariosThe Self Monitoring Parking Meter is a device that assists parking meter patrol officers

and makes their checks more efficient. Even though this design was mainly conceived to be used

with motor vehicle parking meters, the same concept can be applied to other uses. A very close

application would be to monitor boat dock spaces or arrivals at the many harbors throughout the

world. Even though this other application would require a different platform, in essence it would

incorporate the same concept used in our design

11.0.1 Proper OperationThe parking meter notification system works by detecting the presence of a vehicle

within a parking space and relaying the status wirelessly to patrol officers. Making such

information readily available increases the efficiency of checking meters and the ease of parking

for patrons. The design uses wireless modules to relay the status information to a central main

station but also has the potential to be sent to mobile computer devices mostly used by patrol

officers.

11.0.2 Improper Operation Given that the design depends entirely on an ultrasonic sensor to detect the presence of a

vehicle, vandalism may affect the design’s performance and operation. Should there be an

intentional obstruction of the sensor the design will no longer provide a reliable stream of

information. In that scenario, the information would not accurately depict the parking status

thereby corrupting the wireless communication data. In addition, a weather-proof ultrasonic

sensor would need to be installed to prevent corrupt data transmission due to weather damage.


12.0 High Level Block DiagramDuring the process of selection, the team proposed different design ideas and different

ways of implementing each of those ideas. Several of these ideas were discarded based on

important weighting factors such as cost and time required. Therefore after careful examination

of the multiple feasible concepts generated by the Pugh Matrix, the team decided that the best

conceptual design approach and most realizable option would be the one presented in Figure 4.

Figure 4 Block Diagram

The team spent the summer doing research on the electronic components, selecting those

components that best meet the needs and budget of the design team. A vital task over the

summer was to develop familiarity with the major components that comprise the project in order

to understand their strengths and weaknesses.


13.0 Major (Critical) Components The components required for the parking meter monitoring system included a

microcontroller, two wireless XBee modules, and ultrasonic sensor for parking location

simulation, LED display and system GUI. Parts were chosen based upon proven capability, cost

efficiency and ease of use.

13.1 Microcontroller – Arduino MegaTeam Seven had initially proposed to purchase the HCS12 Dragon12-Plus but after

further research and advice from a team member experienced with the Arduino Duemilanove, the

team decided to order an Arduino. Arduino provided the sufficient features for the design as well

as the cheap price versus the HCS12 Dragon12-Plus. After deciding to go with the Arduino, two

distinct microcontrollers were considered for the project, the Duemilanove and the Mega as

shown in Figure 5. Given that the team was unsure if additional components were going to be

added as the semester progressed, the Arduino Mega was chosen over the Duemilanove because

of its increased quantity of I/O pins.

Figure 5 Arduino Mega and Duemilanove

The Arduino board provides16 analog input pins, 54 digital I/O pins of which 14 can be

used for PWM outputs. The design relies on the use of PIN 7 of the PWM section of the board

for compatibility with the ultrasonic sensor in order to output a pulse. This application allows

the use of the Pulse Width Modulation (PWM) option. The power levels necessary to power all

electronic components are provided by the Arduino Mega’s 3.3V/5V power pins, which are both

convenient and simplistic. With no need to build a separate voltage regulator circuit to provide

power, both money and time were saved for other portions of the design. In regards to the

Arduino programming, there were many online examples to help accomplish needed sections of


the design. Some examples were exact models of needed code and others were adequate

examples. A good example was the pushbutton program that was found on the Arduino website.

The final great feature was the ability to power the Arduino Mega with a single 9V battery to

avoid using AC power adapter for showcase purposes.

13.2 XBee ModuleThe XBee modules were chosen for their plug and utilize ability. Furthermore, this was

the primary reason for determining its implementation in the design. Few elements of the

module required set up; establishing one Xbee as a Base and another as a Remote, both

advantageous and simplistic. On the technical side, the Vcc supply powering one the XBee was

from the Arduino Mega’s 3.3V power pin. The Dout, Din and GND pins on that XBee are

connected to the RX, TX and GND pins on the Arduino Mega respectively. The standard

breakout board for the XBee pin outs, as shown in Figure 6, was the exact board used on for the

design. The second XBee must remain attached to the USB development board connected to the

GUI computer, which acts as the necessary power supply, and process the A/D conversions from

signals received from the XBee.

Figure 6 XBee pins

13.3 Ultrasonic SensorAn ultrasonic sensor and an induction coil were the two major object detection

components proposed. After carefully considering the advice of Mr. Ramos to use a Maxbotix

ultrasonic sensor over an induction coil, it was decided that the sensor was easier to implement

onto the SMP Meter and also five times cheaper than an induction coil. Two distinct ultrasonic

sensors were considered for the project, the non-weather resistant LV-EZ1 and the weather-

resistant LV-WR1 as shown in Figure 7.


Figure 7 Ultrasonic Sensor

The ultrasonic sensor LV-EZ1 model from Maxbotix contained all the necessary features

for a “proof of concept” design and was four times cheaper than a weather-resistant model. In

functionality it acts as a transceiver both sending and receiving ultrasonic waves. The primary

element of the sensor was the 13 sound waves of a 42 kHz frequency produced by the sensor

when it was turned on (power supply turned high). The Arduino code used for the design set the

supply voltage high to allow a single pulse and then turn the supply low to shut down the sensor.

However in a locked on state, the ultrasonic sensor was capable of producing pulses every 49 ms

for real time detection. The detection area of the sensor was always depicted in cone shaped. An

object at a distance within six inches from the sensor was always displayed as an output value of

six inches regardless of actual distance. Therefore proper usage of the sensor begins past the six

inches mark from sensor. Likewise, upon start up, the sensor performs a calibration step that

requires no object be within 15-20 inches of the sensor.

In order to produce such high frequency waves from electrical energy, an ultrasonic

transducer was built within the sensor, which was responsible for emitting the waves. In order to

evaluate the echoes generated by objects the transducer converts from acoustic energy back to

electrical energy. The sensor then calculates the time interval between the sent sound waves and

received echoes to determine the distance to an object. The sensor has a power window of

2.5V~5.5V and an optimal long-range detection distance of 6.45 meters within a 50° angle.


13.4 Graphical User Interface (GUI)A user-friendly and easy to use interface platform was needed in the Main Station to

monitor the status of parking meters. The Main Station is the place where the wireless numerical

sequences that contain the status information sent by the Arduino Mega through the XBee

modules would be ultimately analyzed and displayed to the parking officers. The

Matlab/Simulink approach was chosen because of its ease of use, wide range of tools and the

familiarity a team member had with it. In addition, Simulink had a wide range of compatible

serial communication options for the XBee wireless modules. Finally, a key component for using

the Matlab/Simulink package was the extent of documentation both within the software and

online websites.

14.0 Detailed DesignMultiple designs were purposed for the implementation of a self-monitoring parking

system. Different methods required the use of different hardware while all found compatibility

within the software GUI system. Many objectives and requirements were used to influence the

final decision as previously shown via the Pugh Selection Matrix explanation. The final design

was properly displayed and explained in the high level block diagram.

14.1 HardwareFrom the block diagram and from Section 13 (Major Components) it seen that the

hardware contained five components. These five components were the microcontroller, two

wireless XBee modules, ultrasonic sensor, pushbutton for parking location simulation and LED

display. The hardware's intensive utilization (described in detail in Section 13) allows the

simplistic functionality to shine through in this design. Mr. Ramos and Mr. Sanchez were in

charge of all the hardware in the project.

14.1.1 MicrocontrollerThe microcontroller acts as the central detection authority in this design for each parking

location. The microcontroller receives constant feedback from the ultra sonic sensor to correlate

with the current time allowed on the parking meter. The parking meter then sends its parking

location report via the XBee modules to be reported to the main station using the GUI.


Jesus Luna led the development and coding for the microcontroller with coding help and

flow advice from Joshua Torrey. As a team, the group analyzed example code from the Arduino

website as well as the unique instruction set supplied in a C like programming language. The

conceptual data reports from the microcontroller to the GUI were derived by Joshua but were

implemented and refined to a usable completion by Raul and Jesus. Jesus modified code to help

the microcontroller control maintain awareness of the current time and likewise the time allotted

for the parking location to provide the backbone of our design.

Table 1provides a brief description of each of the pins used in the design both in relation

to communication and pins essential to the programming of the microcontroller.

Pin # Type Configuration Function(s)

0 Serial UART Input*Receives any information coming from the

Xbee connected to the computer

1 Serial UART Output*Transmits the current state and time left on

the parking meter.

2 Digital Interrupt

*Interrupt is triggered every time the "coin"

button is pressed with a minimum delay of

250 milliseconds between presses

7

Digital Output*Creates square pulse to drive ultrasonic

sensor

Digital Input*Reads if there is bouncing of signal after the

ultrasonic sensor is driven with a square wave

18 Serial UART Output*Sends a binary value to the 7-segment

display that represents the paid time leftTable 1 Pins in the Microcontroller

14.1.2 Wireless ModulesThe XBee modules used for this design were suggested and recommended by Raul

Ramos after gaining experience with them during a summer research program at UTSA. They

were chosen based upon the extremely easy utility and efficiency. The modules essential were

plug and use while providing excellent quality of distance and transmission power given proof of

concept requirements. Mr. Ramos and Mr. Sanchez modified the XBees to ensure that they Team #7 Electrical Engineering Design 2 Page 26

communicate solely with each other.

The XBee modules are the only form of communication within the design. Working in a

pair, one module connected to the microcontroller board while the other connects via a USB

cable to a working computer/base station.

14.1.3 Ultrasonic SensorThe Maxbotix ultrasonic sensors were used for this design as part of the adherence to a

cost efficient project as stated by the Pugh selection matrix. These sensors were capable of

providing sufficiently accurate information for proof of design while also providing excellent

compatibility options with the Arduino board. The sensors are able to supply both digital and

analog reading to the microcontroller with the digital readings being used as the detection

method of this design.

Raul Ramos and David Sanchez tested the sensor and calibrated it. They quantified the

best distance ranges for the sensor as well and noticed trends in the startup calibration of the

sensor.

14.1.4 Push ButtonThe pushbutton used for this design was a part of a pre-packaged bag of extra parts

needed for the design. The button was used as a simplistic time adding mechanism for the timer

simulation part of the design. Jesus Luna wrote the code required to incorporate the pushbutton

into the microcontroller detection system.

14.2 SoftwareSoftware played a critical part both in making the sensor design feasible while also

allowing it to become a system design. Code was used for the Arduino microcontroller while

Matlab/Simulink was used for the GUI to report parking violations. Programming was done and

advised by Joshua Torrey, Jesus Luna and Raul Ramos.

14.2.1 Microcontroller ProgrammingThe microcontroller was programmed through Arduino alpha which acts as a compiler

using Arduino’s own language which was similar to C/C++. The main program follows a set

flow of detection starting with a coin/money check allowing for a time addition or start (in case

of a new car parking), pinging the ultrasonic sensor and processing the result after verify a

vehicle detection (requires seven successful detections) and then determining the time/detection


state of the parking location and sending the encoded information serially through the XBee

module.

To incorporate as a realistic simulation, the pushbutton was introduced as a “coin” button

set as an interrupt. Thus, the program stepped out of any current task to increase the paid time

and then returned to the task being processed before the interrupt occurred. For simulation

purposes the time in the parking meter was increased only by 15 seconds each time the button

was pressed. However, this time can be easily modified to a real-life scenario where time is

increased in at least 15 minute intervals.

In order to successfully track time the function millis( ) was used. millis( ) is a function

part of the default Arduino alpha library that returns a value equal to the milliseconds elapsed

from the start of the program. This function was used in several instances of the code; the two

most notorious parts being saving a variable (TimeStart) with a value equal to the one returned

by millis( ) after the first button push, and saving the variable InterruptCurrent which followed

the same procedure as TimeStart but occurred at the beginning of the pushbutton interrupt.

Following are excerpts from the code that demonstrate how millis( ) was used in both instances.

Figure 8 demonstrates how millis( ) was used for the variable TimeStart after a satisfied

condition that checks for a button push and also checks if such button push is the first one to

occur.

Figure 8 Program used for push button and status


Figure 9 demonstrates how millis ( ) was used to set the variable InterruptCurrent during

the subroutine that handles the interrupt. The variable InterruptCurrent is used to debounce the

pushbutton because it only sets the CoinFlag if at least one second has elapsed since the last

push.

Figure 9 Interrupt handling

Once the variable TimeStart is set and the number of button pushes is recorded, the

program starts a loop that compares the value of the purchased time with the current time using

the function millis( ). During each loop the code checks with the ultrasonic sensor to ensure a car

is still present. The loop keeps on going and transmitting the information trough the XBee

module until the purchased time is consumed or the parked car leaves the parking space. Once a

new car parks or more time is purchased; the code starts the same procedure.

14.2.2 GUI ProgrammingA Matlab/Simulink software package contained all the tools that the project

required. One of the primary tools used within the package were the communication toolboxes to

establish serial communications. A ‘Query Instrument’ block from the Instrument Control

Toolbox was used to establish COM ports and serial communication between the XBee

development board attached to the computer via USB cable and the Simulink software. Once

established, the numerical sequences enter the Simulink model and are displayed on an ActiveX

numerical LED display. The left-most digit corresponds to a specific parking meter at some

location. The 2nd digit from the left corresponds to the parking meter status which can be

represented by Illegally Parked (0), Legally Parked (1) or No Car Present (2). All digits right of

the parking meter status digit corresponded to the time available on the parking meter.


A graphical user interface (GUI) was then designed to communicate with the Simulink

model and provide a user-friendly interface. For this reason, a GUI was needed in the Main

Station to provide a graphical representation of the status of all parking meters to the parking

officers. The GUI was developed using Matlab’s GUIDE wizard to set the window dimension,

the necessary displays, labels, buttons and images on a blank template. After designing the

aesthetic components of the GUI, the next step was to begin programming a pushbutton to

commence the communication process with the Simulink model while another was set to halt the

communication and reset the GUI. The pushbuttons were programmed with functions referred to

as Callbacks. Callbacks are used to acquire set pieces of information by recalling the handles

structure of the block of interest. As an example, the output blocks OUT1 and OUT2 within the

Simulink model are the important since they both contain the information that was read by the

GUI using a handles structure. There are only a few options available when trying to acquire

information from a Simulink block into a GUI. The first option was the use of a function called

RuntimeObject. This allowed the user to acquire a single instance of data by using a Callback

structure but the only problem was that this did not capture data in real-time per our requirement.

After further research, the most viable method was the use of event listeners. In a practical sense,

event listeners can be thought as alarms that only go off when a user-defined event occurs and

then cause a user-defined trigger to perform a specific action. Using the add_exec_event_listener

function, the user is able to add such listeners to specific Simulink blocks as shown in the

example in figure 10 for the output blocks OUT1 and OUT2.


Figure 10 Program use for Event Listeners in Matlab

After further coding and testing, the pushbuttons on the GUI were ready to automatically

connect to the Simulink model and begin displaying the information necessary for patrol officers

to perform their duties. The final GUI is shown in figure 11.

Figure 11 Team's Final GUI


14.3 Engineering Analysis and CalculationsKnowledge from previous courses helped the team achieve a successful design. The

microcontroller was effectively programmed with all the knowledge acquired during

Microcomputer I and Microcomputer II. Furthermore, Mr. Ramos had utilized this component

during a research program at UTSA which was the main influence to use this component.

Similarly, the analog to digital integration was achieved with the knowledge acquired in Digital

Signal Processing, Signals and Systems I and Signals and Systems II. The Wireless

Communication and Communication Systems classes were helpful for the wireless integration of

the design. Lab 1 and Lab 2 served for all the analog components implemented in the design.

14.3.1 Ultrasonic Sensor CalculationsThe sensor provided two detection methods which provide results in different formats.

The first required the use of analog I/O while the second involved the use of digital I/O. The

latter proved to be the most convenient.

The analog method involved the use of the analog output pin which was labeled as AN

and shown in Figure 10. The sensor has the ability to output an analog voltage-scaling factor that

represents a distance and was calculated by the following formula:

AN=V CC

512

Where Vcc represents the voltage applied to the sensor. As an example, providing 5V to the

sensor the analog output pin AN would provide the following voltage per inch:

AN= 5V512

≈ 9.8 mV /inch


Figure 12 Ultrasonic Sensor Pins

The digital method, which was used for the design, takes advantage of the digital TX

(transmit), RX (receive) and PW (pulse width) pins on the sensor as shown in the Figure 12. The

TX pin outputs asynchronous serial data with an RS232 format. The output was an ASCII capital

letter “R” followed by 3 ASCII character digits representing the range calculated by the PW pin

in inches up to a maximum of 255 followed by a carriage return(ASCII 13) or same as hitting the

‘enter key’ on the keyboard. The baud rate, which was the maximum number of symbols per

second transferred was 9600, 8 bits with no parity and a single stop bit. The RX pin was always

pulled HIGH in order to have the sensor continually measure range and pulled LOW if there was

a need to have the EZ-1 stop ranging. The PW pin outputs a pulse width representation of the

range. The PW pin calculates the distance by using the scale factor of 147µs per inch. A pulse

width with duration of 147 µs was equivalent to having an object 1 inch away. As an example, a

pulse with a HIGH duration of 1470 µs represents a distance of 10 inches as shown in Figure 13.

Figure 13 Pulse Width Example

14.3.2 GUI CalculationsThe mathematical algorithm that segments the numerical sequence first needs calculate

the number of digits in the incoming sequence before attempting to separate them accordingly. Team #7 Electrical Engineering Design 2 Page 33

This was accomplished by an Embedded Matlab Function block that contained various formulas

which included the following:

¿of Digits=∫( log (sequence )log (10 )

+1)The int function was used to convert a rational number into an integer. This integer was used to

segment the time available part of the numeric sequence. The use of two additional functions

mod and fix were applied to separate the numeric sequence properly into the ActiveX numeric

LED displays as shown on the right side of Figure 14.

Figure 14 Matlab/Simulink Sequence

A sample of the code within the Embedded Matlab Function block in the Simulink model

and use of the functions described above are shown in Figure 15. The mod function returns the

remainder from the division of two numbers or perhaps described as the modulus after division.

The fix function rounds rational numbers down to zero which yields an array of integers.


Figure 15 Matlab code used for Simulink

15.0 Major ProblemsThe first major parking meter simulation problem was polling. The desired outcome of

the microcontroller code was to take into account each button press regardless of input time. This

was a real concern since in use people are allowed to insert money into a parking meter at any

time they desire. However, simply polling the button input pin allowed for some of the inputs to

be lost. The source of this accident was that when an input pin was polled, the input must occur

at the same time the pin was being polled otherwise inputs are ignored. As a solution, the input

pin which was connected to the “coin” button was configured as an interrupt. In this way if an


input occurred, the program stopped its current task to take care of the input. It was efficient

programming to reduce the number of possible interrupts but this qualified as a mandatory case.

The second major parking meter simulation problem was switch bouncing. To accurately

model a counter/timer, the microcontroller coded need the counter to be incremented by one each

time the button was pressed. Two unexpected and undesired results however occurred. The first

of which was that after pressing the button, the counter was incremented by more than one. The

second was such that, the switch input was set as an interrupt function where delay functions do

not work. The physical designs of buttons are built in such a way that when they are pressed

there was bouncing (repeated transition between high and low voltage states). This bouncing

may look like a single press for a human because it happens so fast. However a microcontroller

can detect bouncing as several inputs without trouble. Figure 14 illustrates the push button

debouncing.

Figure 16 Push Button Debouncing

Hence the solution was to “debounce” the button pressing. This switch debounce was

done with software. It was necessary to set a “coin” flag inside the interrupt function and then

add a 250 milliseconds delay at the beginning of the code’s main loop (after this delay the “coin”

flag was checked). In this way if the microcontroller detected several inputs only the last one was

taken into account and the counter was incremented by one.

16.0 Integration and Implementation

16.1 IntegrationThe plan provides a detailed description of the methods utilized to achieve all design

objectives. This plan includes all the design phases and how they were integrated into system.

Moreover, the selection and the building of the system implemented. Finally, the testing phase

came to play, to verify that all components worked as planned.Team #7 Electrical Engineering Design 2 Page 36

16.1.1 Preparation PhaseDuring the preparation phase the team studied how the components that were utilized on

the system integrated into the design. Afterward, the group selected and ordered the components

that were implemented on the system. The main components that the group focused on from the

beginning of this design were the microcontroller, ultrasonic sensor, Analog to Digital

Converters and RF signal transceiver. After the components arrived, the team started

incorporating them into the design.

16.1.2 Design PhaseIn the design phase the team started looking for all the alternatives for each major section

of the project. Major components of the design were power, vehicle detection, RF transmitter, and main station design.

16.1.2.1 Power DesignA cohesive power supply design was developed to provide power to every component in

the design. Special attention was given to the power supplied to the Microcontrollers and

wireless transmitter.

16.1.2.2 Vehicle Detection DesignOnce the proper power was supplied to the detection system, an Ultrasonic Sensor

System was developed to provide analog vehicle notification signals as output. At the same time,

an ADC was designed to provide a digital Boolean signal to the microcontroller. The

microcontroller maintained constant analysis of the parking meter. The microcontroller was

programmed in C or C++ to receive these digital signals, analyze them and then provide the

digital signal via wireless communication.

16.1.2.3 Parking Meter RF Transmitter DesignThe RF transceivers were already incorporated to the development board. The team

adjusted the configuration to achieve their signal. Moreover, the development board also

included the Digital to Analog converters for the system to work properly.

16.1.2.4 Main Station Design The Main Station consists of a Matlab/Simulink-based graphical user interface to

provide the officers with a graphical representation of the status of every parking meter. The

Matlab-based GUI can be coded to provide additional viewing options. Such options include


allowing the user to instantly view all open, legally filled, illegally filled and soon to be expired

parking stations.

16.1.3 Testing PhaseIn this phase the team began testing each design subsection to verify each worked

accordingly to the design. The team checked that all subsections have the amount of power that

was needed. The ultrasonic sensor design section verified vehicles were properly detected. In the

parking meter design the team verified that the analog to digital converter works properly. The

team verified each component of the system was receiving the proper amount of power to allow

them to operate. The team also tested for any unwanted noise in any of the signals.

Furthermore, the team verified that the wireless transceivers worked properly.

16.1.4 Completion PhaseAfter all testing was completed the team started assembling and completing a working

model of the system. Moreover, the working model was presented to the administration.

Afterwards, the team started making the final revision for the final written report which

described how the process to achieving a fully functional product developed. Finally, the team

prepared a final presentation consisting of the design process. This presentation described all the

functions the system performed.

16.2 ImplementationThe team started implementing each component previously mentioned for the new

system. Each component was run through some testing before it was actually worked

accordingly with the new system. Furthermore, after testing each component for proper

functioning, the team started implementing each component to the specific design.

16.2.1 Ultrasonic SensorBefore the team integrated the ultrasonic sensor the team started testing and calibrating

the sensor. The first thing the team did was to measure its voltage level through an oscilloscope

to observe whether it was working properly. According to the team’s research, the sensor outputs

a scaling factor of Vcc/512. The team used a 3.3 and 5 voltage source to achieve proper reading

in the oscilloscope. The second test for the sensor was to properly calibrate the sensor.

Furthermore, the team tried to achieve this by using a cardboard sheet with a 50 degree angle

drawn onto the cardboard as shown in Figure 17. The only problem was that the team didn’t


take into consideration the fact that the detection area would be a three dimensional cone. After

learning this fact, the team solved some issues with the sensor detecting the floor as an object.

Figure 17 Initial Ultrasonic Sensor Calibration

16.2.2 Arduino MegaSince none of the team members were familiar with the Arduino programming, a series

of test programs included in the Arduino’s website were implemented to familiarize the team

with its functions. Furthermore, a program that only integrated a LED light which turned on and

off after pressing the push button helped the team understand general format programming 2.

Likewise, the team became familiar with the serial ports by also utilizing an example in the

Arduino website 3.

16.2.3 Arduino Mega and Ultrasonic Sensor CommunicationAfter the team had properly tested the Arduino board and Ultrasonic sensor they wanted

to make sure that they communicated according to the plan. The team uploaded a program that

detected the distance from a given object and the sensor. This distance appeared in inches and

centimeters and display it in the computer connected through a USB cable from the Arduino

board to a computer. In addition, one can observe a video that clearly illustrates this approach;

the Arduino_and_sensor_communication.mov was included in the project file.

16.2.4 XBee CommunicationFrom the beginning, none of the team members were fully familiar on how the XBee

modules. The XBees included a small development board which facilitated the process of

converting Analog to Digital signals. An illustration on how the XBee and its development board


are connected is shown in Figure 18. Soon after the initial research, the team found that the

XBees were supplemented by software known as XCT-U. Moreover, this software included a

test program which let the users know the range in open or close spaces of the modules. The

team started testing the modules in open spaces they had a range of about 100 feet which was

more than enough for the team’s design. In addition, the team also started sending written

messages through these wireless modules.

Figure 18 XBee and Development Board

16.2.5 Arduino Board, Ultrasonic Sensor and XBee Modules CommunicationSince the team had successfully achieved communication between the Arduino

microcontroller and ultrasonic sensor; and between the XBees wireless modules, it was now time

to incorporate all of these components together. The team used the program that had already

being implemented between the Ultrasonic Sensor and Arduino board communication.

Furthermore, this program provided the user with the distance detected by the Ultrasonic Sensor

and illustrates it in the computer connected to the Arduino board. After this major improvement

in the design, it was time to send the information wirelessly. The team integrated the XBee

wireless modules to this program. In addition, the team achieved the wireless communication

between the Arduino board, Ultrasonic Sensor and a base station; which was the final goal for

the team.

16.2.6 Push ButtonThe team integrated a push button to simulate any money deposited into the parking

system. A program which integrated the Arduino board and a push button was found in the

Arduino’s website4. The team incorporated this program into the Arduino board which did not Team #7 Electrical Engineering Design 2 Page 40

work along smoothly with the desired design; these problems were discussed on the major

problems section of this paper. Figure 19 illustrates how the push button was integrated into the

system.

Figure 19 Push Button integrated into the system

16.2.7 LED DisplayThe team decided to implement an LED Display to help the meter user visualize the time

added to the system. This LED display was purchased towards the end of the design since none

of the team members had considered this main component in the design. The team first

considered using separate LED displays for each number in the time sequence. Figure 20

illustrates this approach.

Figure 20 Separate LED displays for each number


After careful consideration the team decided to utilize a single LED which was controlled

by one pin instead of thirteen pins. The team started by studying the user manual of the LED

display5. Firstly, a program that would reset LED internal memory was tested. In addition the

team members started controlling the display brightness and set it to its maximum. Finally the

LED display was tested to display several symbol rate values. Figure 21 illustrates the final LED

display applied by the team.

Figure 21 LED Display

16.2.8 Graphical User Interface (GUI)Initially, several test platforms were developed using Matlab’s GUIDE in order to

understand and acquire a basic understanding of how certain GUI components worked.

Pushbuttons, axes and numeric displays were among the first components that were tested. The

tests included pushing a button in order to display set numbers on the numeric LED display,

toggling an LED on and off by pushbuttons and uploading static images onto the axes such as the

UTSA logo. After a basic understanding was obtained, the next step was to program the bottom

left pushbuttons to connect to the GUI with the Simulink model. The initial test platform of the

GUI design for team seven is displayed on Figure 22.


Figure 22 First Tests for the GUI

17.0 Comments and ConclusionThis project experience was helpful to all the team members of team seven; it provided a

huge insight of how group projects function. The team clearly understood how each component

was to be integrated and how each member provided some knowledge of their career

concentration. The group decided to have meetings every Monday throughout the semester,

since it was the only day all team members could meet for sure. The team divided some of the

tasks since the beginning of the project. Furthermore, after a person finished their task they were

given a new task or helped a team mate with another job. Initially, the team divided its

responsibilities as their concentration in their Electrical Engineering major. Jesus Luna and

Joshua Torrey were in charge of the functionality of the microcontroller, since they both had

experience on programming. Mr. Torrey was also in charge of the website design. David

Sanchez and Raul Ramos where given the task of integrating the ultrasonic sensor and wireless

modules to the system, since they had experience on signal processing and controls systems

respectively. Moreover, since the wireless and sensor integration did not take as much time as

the team thought these two members were given new responsibilities to continue with the

Design. Raul Ramos was in charge of the GUI design. Mr. Sanchez was responsible for all the

documentation for the project. After all the components worked as they had planned, the Demo

platform was built to start the testing phase of the project. In addition, no major problems


occurred from within the group during the Design process. From the start, everybody had a clear

idea of what the final goal was; to finish a great design which will help today’s society.

18.0 Team MembersThis design was developed by a group consisting of four Electrical Engineering students

from the University of Texas at San Antonio. Joshua Torrey, Raul Ramos, David Sanchez, and

Jesus Luna each have fundamental knowledge of electrical engineer. Each member provided a

different area for this design to succeed.

18.0.1 Joshua TorreyJoshua helped with all programming for the group as well as managing the completion of

the final report. His concentration is in Computer Engineering and he has two semesters of

Computer Design & Testing experience with Advanced Micro Devices. Joshua is fluent in both

Perl and C++ while proficient in Ruby, Java and C#. He has taken the following

Programming/Computer Classes: Intro to C, Data Structures, Microcomputer Systems I and

Computer Organization & Design. Mr. Torrey's focus was on providing support for

microcontroller while providing conceptual direction on the GUI for the project.

18.0.2 Raul G. RamosRaul has a Systems and Controls concentration and worked as the hardware integration

team leader. Having taken courses in both control systems and digital signal processing, he

gained experience in Matlab and Simulink which was used to create the team’s GUI. Mr. Ramos

has experience with A/D and D/A converters from his Discrete-Time and Computer Controlled

Systems (EE 4443) along with Neural Networks training and Fuzzy Logic from his current

Intelligent Controls (EE 4733) class. He also assisted in the configuration of inputs and outputs

within the major components.

18.0.3 David SanchezDavid helped develop the Communications, Signals and Processing throughout the

system as well as the physically structure of the parking meter/sensor design. Courses on his

communication concentration such as Wireless Communications and Communication Systems,

helped him developed the communication and wireless communication of this project. His

knowledge in Signal Processing and previous work with companies involving Analog to Digital


Converters and Digital to Analog converters was beneficial to the group in the development of

this project.

18.0.4 Jesus Luna Jesus joined the team after the concept stage in the first semester of the design. With a

concentration in Computers and experience with C++, Maya and C#, Jesus took the lead role in

the detailed microcontroller programming. Mr. Luna has taken several courses that exposed him

to the use of A/D and D/A converters while developing a sense for efficient and structured

coding in microcomputers. Jesus has also experience in the implementation of signal amplifiers

to integrate analog components into digital environments which became fundamental to the

project.

19.0 References1. "Restriction of Hazardous Substances Directive." Wikipedia, The Free Encyclopedia. 24 Nov

2009, 18:53 UTC. 25 Nov 2009. <http://en.wikipedia.org/w/index.php?title=Restriction_of

Hazardous_Substances_Directive&oldid=327710057>.

2. Cuartielles, David. "Arduino - Blink." Arduino - HomePage. 1 June 2005. Web. 03 Sept.

2009. <http://arduino.cc/en/Tutorial/Blink>.

3. Gray, Jeff. "Arduino - Begin." Arduino - HomePage. Web. 03 Sept. 2009.

<http://arduino.cc/en/Serial/Begin>.

4. Igoe, Tom. "Arduino - Button." Arduino - HomePage. 17 June 2009. Web. 10 Oct. 2009.

<http://arduino.cc/en/Tutorial/Button>.

5. "SparkFun Electronics - 7-Segment Serial Display." SparkFun Electronics - News. Web. 28

Oct. 2009. <http://www.sparkfun.com/commerce/product_info.php?products_id=9230>.

6. "Arduino Forum - Debounce Interrupt." Arduino - HomePage. Web. 20 Nov. 2009.

<http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1258424057/0#0>.

7. "Arduino - Reference." Arduino - HomePage. Web. 10 Nov. 2009.

<http://arduino.cc/en/Reference/HomePage>.


8. "Arduino - ArduinoBoardMega." Arduino - HomePage. Web. 02 Sept. 2009.

<http://arduino.cc/en/Main/ArduinoBoardMega>.

9. Goddard, Phil. "Simulink Signal Viewing using Event Listeners and a MATLAB UI." Matlab

Central. 02 November 2009. Web. 02 November 2009.

<http://www.mathworks.com/matlabcentral/fileexchange/24294-simulink-signal-viewing-using-

event-listeners-and-a-matlab-ui>

10. "Using the Embedded MATLAB Function Block." The Mathworks. n.d. Web. 26 October.

2009. < http://www.mathworks.com/access/helpdesk/help/toolbox/simulink/ug/f6-6010.html>.


Documents

Retrieve Documentaux.coe.utsa.edu/~eesenior/fall2009/Team07/documents... · Web viewDavid Sanchez and Raul Ramos where given the task of integrating the ultrasonic sensor and