Final Report Self Monitoring Parking Meter

ukrainianlegalElectronics - Devices

Nov 2, 2013 (3 years and 7 months ago)

256 views



Final Report


S
elf Monitoring Parking

Meter


December

3
rd
, 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 Sanchez

Raul

G.

Ramos

Joshua Torrey

Jesus Luna



Team #7

Electrical Engineering Design 2


Page
2

Table of Contents

1.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

Citi
es

................................
................................
................................
.........................

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

Pro
duct 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

13.0

Major (Critical) Components

................................
................................
................................
..

22

Team #7

Electrical Engineering Design 2


Page
3

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

U
ltrasonic 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

Team #7

Electrical Engineering Design 2


Page
4

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

D
avid Sanchez

................................
................................
................................
................

44

18.0.4

Jesus Luna
................................
................................
................................
......................

45

19.0

References

................................
................................
................................
............................

45




Team #7

Electrical Engineering Design 2


Page
5

1.0

Executive Summary

Team Seven of the Senior Design II course h
as developed a system that
provide
s

real
time information of parking s
paces 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 mo
r
e efficient.
Furthermore, the new
design will feature a sy
stem of parking meters that

automatically detect illegally parked vehicles,
and alert the violation to a base st
ation in which the officers would

be present
.
Additionally, a
Graphical User Interfac
e (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
loca
tions. 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
-
c
oncept 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 S
even, 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.

Team #7

Electrical Engineering Design 2


Page
6


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 violat
ion
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 Me
ter. Other tasks such as patent
searches, design alternatives and block diagrams helped formulate a cohesive top
-
level view of
Team #7

Electrical Engineering Design 2


Page
7

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 provide
d

a key asset to the design of the parking meter. With each
member of the team capable of handling unique portions of th
e design, no single member was

called upon to deliver more than the others.
This

result
ed

in an e
fficient and productive schedule
as well as completion of all deliverables. David Sanchez provide
d

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 utilize
d

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 c
od
ing 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
sche
dule w
ill be shown on Figure 2
.

Team #7

Electrical Engineering Design 2


Page
8

3.0

Need Being Addressed

In recent years, parking has become a serious problem
under the increase of motor

vehicles
. A new
m
onitoring
system

for parking meter
s

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 mec
hanisms to which the system was

implemented. In
u
niversities and cities the new system will improve the quality of how officers will receive
infor
mation 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

Team #7

Electrical Engineering Design 2


Page
9

4.0

Literature and Patent Search Results

In 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 fac
ilities with monitoring at
the entr
ance 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 benefi
ts. However the
application of this new system is in a field of substantial profit. Taking advantage of this,
dif
ferent types of
implemented

sensors are capable of being

positi
oned 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 techn
ologies. However in that

model, instead of the

sensor moving, the sensor is
placed statically and when the prese
nce of a car is detected it
send
s

a
signal to the system. T
his model is more effective for garage monitoring and not open location
parking syst
em (downtown, schools, etc).

5.0

Marketing Analysis and Market Strategy

The 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
curren
t 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 impro
ving 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 rel
a
ying 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
Team #7

Electrical Engineering Design 2

Page
10

parking meter system increase
d

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 s
lowly 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
inc
reases 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 Markets

The market strategy
target
ed
:

5.2.1

Universities

The improved system can be implemented on any withstanding unive
rsity park
ing 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 th
e 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

Cities

For 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 pa
rt 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 r
evenue collection and control. Patrolmen currently cover all parking
locations, serving as the cities form of parking meter enforcement. The new system is based
Team #7

Electrical Engineering Design 2

Page
11

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 Garages

The 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 t
o 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 us
ers of these parking garages will need to be developed.

5.3

Market Growth

Metropolitan 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
effectiv
ely

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
los
s in demand since this system was

cost effective and precise. This product will market itself
once incorporated.

6.0

Engineering Design Constraints

There were many factors that were considered in the design process of the
Self
Mon
itoring 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 sy
stem 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 Effects

Team #7

Electrical Engineering Design 2

Page
12

This
constraint did

not apply to this system since we are utilizing sensors that do not
interfere w
ith the environment. F
or 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 t
his new parking is implemented in large
metropolitan areas.



Manufacturability

Th
e 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

di
sposal of electronic components
require
d

stringent exposure requirements

but the
use of the product was

not create
d

health or safety issues.



Social Ramification

The product was

constrained
in a positive way since it
encourage
d

the proper parking
procedu
re 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 infr
inge on any patents and the idea for the produ
ct is
already patented
. A careful design procedure was

limit
ed by
the

legal issues this
product
incurred

but the potential is there.

6.2

Local Constraints



Cost

Team #7

Electrical Engineering Design 2

Page
13

The cost was

constrained to this system because the cost cannot exceed the budget
received for p
roduction. 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
protot
ype 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

abide
d

by all codes & standa
rds when in use. The team
modi
fied

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
Ro
H
S

standards during the manufa
cturing stage of
the system

help
ed

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 Requirements


The Self
-
monitoring parking meter was designed t
o meet many use
r 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.

Team #7

Electrical Engineering Design 2

Page
14

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 condit
ions.

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 requi
re 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 Standards


The
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 network
1
.

Type

Regulatory Standard

Conforming Components

Team #7

Electrical Engineering Design 2

Page
15



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)



Cadm
ium (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
Concepts


The 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 t
echnological 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.
Team #7

Electrical Engineering Design 2

Page
16

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


The first concept considered
was

a wireless networ
k consisting of a base comp
uter

a
nd

varying quantity of parking location monitors (transmitters). Parking location monitors, using
ultrasonic sensor
, w
ere to be

an addition to current parkin
g meters. Handheld devices
consist
ed

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 in
formation
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. Ou
r design idea seeks to cover, efficiently, the most parking locations
(area) possible. Cost and Sche
dule was also

important constraints on us as students with only one
semester to construct our d
esign. After these constraints;
Convenience, Resistance to We
ather
and Conforming to Engineering Standards are the next highest weighted. Convenience of Usage
help
ed

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 marketa
bility of the
current design idea. H
owever,

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 f
actors highlighted ease and
low
-
cost

of the Wired System Design. Convenience of
Team #7

Electrical Engineering Design 2

Page
17

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


Team #7

Electrical Engineering Design 2

Page
18

Ultimately, the matrix valued both the Wireless and Wired Upgrade
Options similarly.
F
or the purpose of this class the team decided to

move forward with the Wireless Upgrade
Optio
n, as it
was

the option that

best display
ed

our design skills.

10.
0

Product
Specifications


The 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 w
ithin their proper field.

10.1

User Specifications

Wireless 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 in
creases 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 d
evice.

Criticality:

Team #7

Electrical Engineering Design 2

Page
19

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 p
rocess. For this
design, a Simul
ink example has been designed to show what the GUI would need to provide for
in
-
field use.

10.2

Hardware Specifications

Com
patibility 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 l
arge 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 digi
tal 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 a
llow for cost control abilities to users.

Criticality:

Team #7

Electrical Engineering Design 2

Page
20

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 se
t for each sensor
type made available.

11.0

Operational Scenarios


The 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 pl
atform, in essence it would
incorporate the same concept used in our design

11.0.1

Proper Operation


The parking meter notification system works by detecting the presence of a vehicle
within a parking space and relaying the status wirelessly to patrol offi
cers. 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 sen
t 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
v
e
hicle, 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 ad
dition, a weather
-
proof ultrasonic
sensor would need to be installed to prevent corrupt data transmission due to weather damage.


Team #7

Electrical Engineering Design 2

Page
21

12.0

High Level Block Diagram

During 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 decide
d that the best
conceptual design approach and
m
ost 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
summe
r was

to develop familiarity with the major components that comprise the project in orde
r
to understand their strengths and weaknesses.

Team #7

Electrical Engineering Design 2

Page
22

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 Mega

Team Seven had initially proposed to purchase the HCS12 Dragon12
-
Plus but af
ter
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 deci
ding 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 Ar
duino 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. Thi
s 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
Team #7

Electrical Engineering Design 2

Page
23

the design. Some examples wer
e 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 p
ower adapter for showcase purposes.

13.2

XB
ee Module

The XB
ee 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
; es
tablishing one Xbee as a Base and another as a Remote, both
advantageous and simplistic.
On the technical side, the V
cc

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 st
andard
breakout board for the XB
ee

pin outs
, as shown in
Figure 6
,

was

the exact board used
on for the
design. The second XB
ee must remain attached to the USB development board connected to the
GU
I computer, which acts as the necessary power supply,

and process the A/D conversions f
rom
signals received from the XB
ee.


Figure
6

XB
ee pins

13.3

Ultrasonic Sensor

An ultrasonic sensor and an induction coil

were

the

two major object detection

components
proposed.

After careful
ly 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 M
eter and also five

times c
heaper than an induction coil.
T
wo 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
.

Team #7

Electrical Engineering Design 2

Page
24


Figure
7

Ultrasonic Sensor

The ultrasonic
sensor LV
-
EZ
1 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 pri
mary
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 supp
ly 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 t
hat
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.

Team #7

Electrical Engineering Design 2

Page
25


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 me
ters. The Main Station is

the place where the wireless nu
merical
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 Design

Multiple 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

Hardware


From the block diagram and from Sectio
n 13 (
Major
Components) it

seen that the
hardware contained five components
.
These five components were the microcontroller, two
wireless XBee m
odules, 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

Microcontroller

The 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.

Team #7

Electrical Engineering Design 2

Page
26

Jesus Luna led the development and coding for the microcontroller
with coding help and
flow advice f
rom 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 t
o 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 locati
on to provide the backbone of our design.

T
able

1
provides

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 left

Table
1

Pins in the Microcontroller

14
.1.2

Wireless Modules

The XBee modules used for this design were suggested and recommended by Raul
Ramos a
fter 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 proo
f of
concept requirements. Mr. Ramos and Mr. Sanchez modified

the XBees to ensure that they
Team #7

Electrical Engineering Design 2

Page
27

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 Sensor

The 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 op
tions 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 i
t
. 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 Button


The 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 incorpo
rate the pushbutton
into the microcontroller detection system.

14
.2

Software


Software 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
Ma
tlab/Simulink was used for the GUI to report parking violations. Programming was done and
advised by Joshua Torr
ey, Jesus Luna and Raul Ramos.

14
.2.1


Microcontroller Programming

The 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 st
art (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
Team #7

Electrical Engineering Design 2

Page
28

state of the parking location and sending the encode
d 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
step
ped

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 i
s
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 wh
ich 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 var
iable 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

Team #7

Electrical Engineering Design 2

Page
29

Figure 9 demonstrates how
millis (

) was us
ed 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 e
ach 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
ne
w car parks or more time is purchased; the code starts the same procedure.


14
.2.2

GUI
Programming


A 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 Contr
ol
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 2
nd

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 correspond
ed

to the time available on the parking meter.

Team #7

Electrical Engineering Design 2

Page
30

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 acquir
e 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
han
dles

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 th
at 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
fi
gure 10

for the output blocks OUT1 and OUT2.

Team #7

Electrical Engineering Design 2

Page
31


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

Team #7

Electrical Engineering Design 2

Page
32

14
.3

Engineering Analysis and Calculations


Knowledge from previous
courses helped the team achieve

a successful design. The
microcontroller was effectively programmed with all the knowledge acquired during
Mi
crocomputer 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 acqu
ired 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 component
s implemented in the design.

14
.3.1

Ultrasonic Sensor Calculations

The 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 p
roved 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:











Where V
cc

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:

















Team #7

Electrical Engineering Design 2

Page
33


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 measu
re 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 Calculations

The 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
34

This was accomplished by an Embedded Matlab Function block that contained va
rious formulas
which included the following:








(



(

)

(

)



)



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
F
igure 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
F
igure 15
. The
mod

function returns the
remainder from the division of two numbers or perhaps des
cribed as the modulus after division.
The
fix

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

Team #7

Electrical Engineering Design 2

Page
35


Figure
15

Matlab code used for Simulink

15
.0

Major Problems

The first major parking meter simulation
problem was p
olling
. The desired outcome of
the microcontroller code was to t
ake into account each button press rega
rdless 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 p
olling the
button input pin allowed for

some

of the

inputs to
be lost.

The source of this accident
was

that w
hen an input pin
was

polled
,

the input must occur
at the sam
e time the pin
was

being polled
otherwise inputs are ignored.

As a sol
ution, t
he input
pin which
was

connected to the “coin” button was configured as an interrupt. In this way if an
Team #7

Electrical Engineering Design 2

Page
36

input occur
red
,

the program

stop
ped

its

current task to take care of the input.

It
was

efficient
programming to reduce the number of possible in
terrupts but this qualified as a mandatory case.

The second major parking meter simulation problem was switch b
ouncing
. To accurate
ly

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 result
s

howeve
r

occurred. The first
of which was that a
fter pressing the button
,

the counter
was

incremented by more than one.

The
second was such that, t
he switch input
was

set as an i
nterrupt 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

bounci
ng (
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 millisecond
s

delay
at the beginning of the code’s main loop (after this delay the “coin”
flag
was

checked)
.
In this way if the microcontroller detect
ed

several inputs only the last one
was

ta
ken into account and the counter
was

incremented by one.


16
.0

Integration and Implementation

16.1

Integration

The 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 selec
tion and the building of the system

implemented. Fina
lly, the testing phase
ca
me to play, to verify that all components work
ed

as planned.

Team #7

Electrical Engineering Design 2

Page
37

16
.1
.1

Preparation Phase

During the preparation phase the team
studied

how the components that
were

utilize
d on
the system
integrate
d
into the de
sign. Afterward, the
group

select
ed

and order
ed

the components
that
were
implemented on the system. The main c
omponents that the group
focus
ed on

from the
beginning of

this design were the
microcontroller,
ultrasonic sensor,

Analog to Digital
Converters and RF signal transcei
ver. After the components arrive
d, the team
start
ed
incorporating them into the d
esign.

1
6.1.2

Design Phase


In the design phase the team started looking for all the alternatives for each major section
of the project. Major components of the design we
re power, vehicle detection, RF transmitter,
and main station design.

16
.
1.2
.1

Power Design

A 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 Microcontro
llers and
wireless transmitter.

16
.
1
.2
.2

Vehicle Detection Design

Once 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

d
esigned to provide a digital Boolean signal to the micro
controller. 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
di
gital signal via wireless communication.

16
.
1.
2.3

Parking Meter RF Transmitter Design

The RF transceivers
were already
incorporated to the development board. The team
adjusted the configuration to achieve their signal. Moreover, the developmen
t board
also
include
d

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 statu
s of every parking meter. The
Matlab
-
based GUI can be coded to provide additional viewing options. Such options include
Team #7

Electrical Engineering Design 2

Page
38

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

16
.
1.3

Testing P
hase

In this phase the team bega
n testing each design

subsection to verify each
work
ed

accordingly to the design. The team check
ed

that all subsections have the amount of power that
was

needed. The
ultrasonic sensor

design section verified vehicles were

properly detected. In the
par
king meter design the team verified

that the analog to digital converte
r 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 test
ed

fo
r any unwanted noise in any of the sign
als.
Furthermore, the team
verified

that the wireless transceivers
work
ed

properly.

16.1.4

Completion Phase

After 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
pre
pared a final presentation consisting of the design process. This presentation described all the
functions the system performed.

16.2 Implementation


The 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 impleme
nting each component to the specific design.

16.2.1

Ultrasonic Sensor



Before the team integrated the ultrasonic sensor the team started testing and calibrating
the sensor. The first thing the team did wa
s to measure its voltage level
through an
oscilloscope
to observe

whether

it was working properly
. A
ccording to the team’s research
, the sensor

output
s

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 sen
sor was to properly calibrate the sensor.
Furthermore, the team tried to achieve this by using a cardboard

sheet with a 50 degree angle
drawn o
nto the cardboard

as shown in

Figure 17
.

The only problem was that the team didn’t
Team #7

Electrical Engineering Design 2

Page
39

take into con
sideration
the

fact that the detection area would

be

a

three dimensional

cone. After
learning this fact, the team solved

some issue
s

with the sensor detecting the floor

as an object
.


Figure
17

Initial Ultrasonic Sensor Calibration

16.2.2

Arduin
o Mega


Since 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 familiari
ze 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
.
Likew
ise, the team became familiar

with the serial ports by also utilizing an examp
le in the
Arduino website
3
.

16.2.3

Arduino Mega and Ultrasonic Sensor Communication


After 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 p
rogram 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

XB
ee Communication


From the beginning, n
one of the team
members were fully familiar

on ho
w the XBee
modules. The XB
ees included a s
mall development board which facilitated the process of
converting Anal
og to Digital signals. An illustration on how the XB
ee and its development board
Team #7

Electrical Engineering Design 2

Page
40

are connected

is shown in Figure 18
. Soon after

the

initial
r
esearch, the team

found that the
XB
ees wer
e

supplemented by so
ftware 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 w
hich
was

more than enough for the team’s design. In addition, the team also started sending written
messages through these wireless modules.


Figure
18

XB
ee and Development Board

16.2.5

Arduino

Board, Ultrasonic Sensor and XB
ee Modules Communication


Since the team had successfully achieved communication between the Arduino
microcontroller and ultra
sonic sensor; and between the XB
ees wireless modules, it was now time
to incorporate all of these components together. The team u
sed 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 informat
ion wirelessly. The team integrated the XB
ee
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 Button


The team integrated a push button to simulate any money deposited into the parking
system. A program which integrated the Arduino board and a push bu
tton was found in the
Arduino’s website
4
. The team incorporated this program into the Arduino board
which did not
Team #7

Electrical Engineering Design 2

Page
41

work along smoothly with the desired design; these problems were

discussed on the major
problems section of this paper.
Figure 1
9

illustrate
s how the push button was integrated into the
system.


Figure
19

Push Button integrated into the system

1
6
.
2.
7

LED

Display


The
team decided to implement an LED
Display to help

the
meter user

visualize the tim
e
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
i
llustrates this approach.


Figure
20

Separate LED displays for each number

Team #7

Electrical Engineering Design 2

Page
42

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
display
5
.
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 di
splay 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 wi
th the Simulink model. The initial test platform of the
GUI design for team seven
is

displayed on
Figure 22
.

Team #7

Electrical Engineering Design 2

Page
43


Figure
22

First Tests for the GUI

1
7
.0

Comments and Conclusion

This 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 pe
rson 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 s
ystem, 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 t
he
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
Team #7

Electrical Engineering Design 2

Page
44

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 Members

This
de
sign
was

de
veloped

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 membe
r
provide
d

a
dif
ferent area for this design to succeed.

18
.0.1

Joshua Torrey

Joshua
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 Organi
zation & Design.
Mr. Torrey's

focus was

on providing support for

microc
ontroller while providing conceptual direction on the

GUI for the project.

18
.0.2

Raul G. Ramos

Raul

has
a
System
s

an
d Control
s

concentration and worked as
the
hardware integration
team

leader
. Having taken courses in both control systems and di
gital signal processing, he
gained experience in Matlab and Simulink

whic
h 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 Co
ntrols (EE 4733) class. He also
assist
ed

in the configuration of

inputs and outputs
within the major components
.

18
.0.3

David Sanchez


David
help
ed

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 in
volving Analog to Digital
Team #7

Electrical Engineering Design 2

Page
45

Converters and Digital to Anal
og
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 cour
ses 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 envir
onments which became fundamental to the
project.

19
.0

References

1. "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
Hazardou
s_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
O
ct.
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>.

Team #7

Electrical Engineering Design 2

Page
46

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
>.