University of Portland
School of Engineering
5000 N. Willamette Blvd.
Portland, OR 97203-5798
Phone 503 943 7314
Fax 503 943 7316
Theory of Operations
Project Long Tom: Optically Triggered
Traffic Recorder
Contributors:
Annette Collins
Tom Kinnear
Jeff Scott
Approvals
Name
Dr. Inan
Date
Name
Date
Dr. Lillevik
Insert checkmark (√) next to name when approved.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: A. NAME
.
.
.
.
.
Revision History
.
.
Rev.
Date.
0.9
02/19/06 .
THEORY OF OPERATIONS
PROJECT LONG TOM
.95
02/24/06
1.0
02/24/06
UNIVERSITY OF PORTLAND
REV. 1.0
PAGE II
Author
Collins, Kinnear,
Scott
Collins, Kinnear,
Scott
Collins, Kinnear,
Scott
Reason for Changes
Initial draft
Minor edit of content, added
sensor figure
Minor content revision
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
.
.
.
.
.
Table of Contents
.
.
Summary.......................................................................................................................
1
.
.
Introduction ..................................................................................................................
2
THEORY OF OPERATIONS
PROJECT LONG TOM
REV. 1.0
PAGE III
Background .................................................................................................................. 2
Architecture .................................................................................................................. 3
General Description ................................................................................................................................3
Hardware Architecture ............................................................................................................................3
Optical Sensors ................................................................................................................................3
Electronics ........................................................................................................................................4
Computer/Software ..........................................................................................................................4
Design Overview.......................................................................................................... 5
System Block Diagram............................................................................................................................5
Hardware Design ....................................................................................................................................6
CMOS Chips ....................................................................................................................................6
Long Tom 1 ...............................................................................................................................6
Long Tom 2 ...............................................................................................................................6
Analog Input Conditioning................................................................................................................7
UART ................................................................................................................................................7
7 Segment Decoder .........................................................................................................................7
Door Sensors ...................................................................................................................................7
Relay .................................................................................................................................................7
Software Design ......................................................................................................................................7
Conclusions ................................................................................................................. 8
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
.
.
.
.
List of Figures.
.
Figure 1 - High Level Block. Diagram.............................................................................................................3
.
Figure 2 - System Level Block
. Diagram........................................................................................................5
THEORY OF OPERATIONS
PROJECT LONG TOM
REV. 1.0
PAGE IV
Figure 3 - Door Sensor Diagram ...................................................................................................................6
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
THEORY OF OPERATIONS
PROJECT LONG TOM
Chapter
1
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 1
Summary
The goal of project Long Tom is to create a device that accurately keeps track of the
number of people in a room at a given time. An interested party can analyze the data to
find peak traffic times, as well as to evaluate the usage of a particular room such as a
computer lab. The primary component of the device will use a custom CMOS chip
combined with various pre-made parts.
We have not determined the dimensions of Long Tom yet. We will house all of the
device’s electronics inside of a box with the display mounted to the top. The box will likely
follow a blue color scheme.
Project Long Tom is also known as an Optically Triggered Traffic Recorder (OTTR). This
device will interface with a computer over a serial link. A custom software program will be
running on the computer to log the times when a person enters or exits the room, as well
as the total number of people in the room at that time and the total for the day. The
primary display will also provide this information to the user. The OTTR can switch
between two display modes, one corresponding to the current number of people in the
room and another to display the daily total of room entrances.
OTTR will control the lights in a room via a relay wired into the lighting system for the
room. Entrances and exits are determined from output of two electronic eyes situated in
the door frame of the room. Our software will create a weekly report of the traffic in the
room containing the maximum occupancy of the room, the time it occurred and the total
traffic for the week. The software will archive old data in tarballs to conserve space and
provide better file organization.
OTTR will be a fully portable system. A computer will not be required for operation, but will
enhance the capabilities by providing data logging. The OTTR system’s electronics will be
fully contained within the box, a power supply and the electronic eyes will be external to
the device.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
THEORY OF OPERATIONS
PROJECT LONG TOM
Chapter
2
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 2
Introduction
The purpose of the Theory of Operation document is to inform the University of Portland
faculty, industry representatives, and all other interested parties, of the technical details of
project OTTR. OTTR stands for Optically Triggered Traffic Recorder. OTTR is designed
to provide data on the total number of personnel in a room at any given moment and the
total number of personnel that have entered the room over a twenty-four hour period.
Custom software will then archive this data in a database for future reference. This
document will provide an in-depth description of OTTR by discussing background and
design specifications, as well as hardware and software design and architecture details.
Chapter
Background
3
Administrators could benefit from knowing the number of people entering or exiting a room
over a given period of time. This information could be especially useful in a university
setting where vast numbers of students must share a limited number of resources. For
example, data could be gathered to determine how many people use certain resources
like the library, computer labs, study areas, the engineering study room/library, and to
identify peak usage times. If certain facilities are overloaded while others are hardly in
use, attempts could be made to direct traffic from highly frequented areas to those rarely in
use, or other studies conducted to provide insight into why students use some areas more
than others. Also, in the case of the computer labs, this data could support arguments
either for or against the need for more computers. OTTR can serve this valuable function
by collecting and recording human traffic data.
OTTR uses a variety of technologies to accomplish this task and is, therefore, a
challenging yet ideal learning opportunity for a senior design project. OTTR incorporates
the following in its design.
 The use of optics in the triggering of the device
 Analog or digital circuit design to prepare the signal as an input to the main
controller
 Digital VLSI (very-large-scale integration) design and layout for the MOSIS
controller chip
 The use of serial communications via external UART to a PC
 Knowledge of the Linux operating system and good C programming skills
 Power electronics to turn the lights in the room on or off
The specific use of these technologies is described in more detail in the following sections.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
THEORY OF OPERATIONS
PROJECT LONG TOM
Chapter
4
.
.
.
.
.
.
.
.
.
REV. 1.0
PAGE 3
Architecture
General Description
Figure 1 shows a high level block diagram. The hardware architecture section below
describes each major block of the diagram and its components.
Optical Sensor
Electronics Box With LCD Display
Computer/Software
Figure 1 - High Level Block Diagram
Hardware Architecture
Optical Sensors
The optical sensors use an infrared beam to detect when someone walks through a door.
We will use two optical sensors to allow us to determine direction of travel – in or out of the
room.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
.
.
.
.
Electronics
.
. box houses the two CMOS chips, analog input conditioning, 7 segment
The electronics
. displays and a UART for communication. Each of these items are
decoders and
.
explained in detail in section 5.
.
THEORY OF OPERATIONS
PROJECT LONG TOM
REV. 1.0
PAGE 4
Computer/Software
OTTR talks to a PC over an RS-232 serial link. The PC will be running the Linux
operating system and the software will be written in C and C++. The software will keep
track of how many people are in a room at a given time and what time someone entered
or exited the room.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
.
.
.
.
Chapter
.
.
. Design Overview
5
.
.
System Block Diagram
THEORY OF OPERATIONS
PROJECT LONG TOM
REV. 1.0
PAGE 5
UART & Controller
Day Total
Counter
Door Sensor 1
Analog Input
Conditioning
Direction
Sensor
Door Sensor 2
text
Room
Total
Counter
Display
text
Selector
7
Segment
Decoder
Light
Controller
LongTom 1
LongTom 2
Relay
Figure 2 - System Level Block Diagram
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
THEORY OF OPERATIONS
PROJECT LONG TOM
.
.
.
.
.
.
.
.
.
Door
Facing
Hall
REV. 1.0
Door
Frame
PAGE 6
Door (Top)
text
Optical
Sensors
text
Optical
Sensors
Figure 3 - Door Sensor Diagram
Hardware Design
CMOS Chips
Each CMOS chip contains roughly ½ of our custom circuitry. Long Tom 1 contains the
direction sensor and the light controller. Long Tom 2 contains two counters, room total
(total number of people currently in the room) and day total (total number of people who
have entered the room that day), as well as a display selector. Each of these elements
will be discussed in more detail below.
Long Tom 1
Long Tom 1 houses the direction sensor and the light controller. The direction sensor
takes input from the door sensors and determines if someone entered or exited the room.
It then outputs an enable signal to Long Tom 2 as well as an Up/Down signal. The light
controller outputs a logic HIGH if there are people in the room and logic LOW when the
room is empty.
Long Tom 2
Long Tom 2 houses the Day and Room counters as well as the Display Selector. Each
counter is composed of 3 cascaded 0-9 counters. The day counter counts up only and the
room counter can count up and down. The counters provide their output in BCD form to
the display selector. The selector is a 12-bit multiplexer that chooses between the output
of each counter based on the position of a switch which is controlled by the user.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
.
.
.
.
Analog Input Conditioning
.
. conditioning circuitry limits the output voltage of the optical door sensors
The analog input
. input to the CMOS chips is within spec and will not go over the +5V
to +4.7V, ensuring
.
max. This is then inverted to provide the proper input to Long Tom 1 (see door sensor
.
below).
THEORY OF OPERATIONS
PROJECT LONG TOM
REV. 1.0
PAGE 7
UART
The UART and the accompanying TTL/RS-232 level converter format all data to be sent
to and received from a PC over an RS-232 serial link. It converts parallel bits from our
CMOS chips into serial format and sends it to a PC. Serial data from a PC is converted
into parallel data that is used to provide a reset signal to our CMOS chips.
7 Segment Decoder
Each 7-segment decoder (3 total, one for each display) receives a 4-bit Binary Coded
Decimal (BCD) input from Long Tom 2 and converts it into the proper 7-bits to drive a
common cathode LED 7-segment display.
Door Sensors
Each door sensor was purchased as a kit item. The sensor provides an output of 0V
when an infrared beam is solid (not tripped) and a +6.8V output when the beam is tripped.
Power, ground and communication will be provided by a 6-pin Mini-DIN connector and
cable. See Figure 3 above for layout.
Relay
The relay takes a digital output from Long Tom 1 and uses it as an input to control
switching on or off the lights in a room. Output from Long Tom 1 will be buffered
appropriately to provide enough current drive to switch the relay.
Software Design
Software design of this system is composed of two main pieces: serial communications,
and data storage/archiving. Both pieces are written in Linux C. The serial communication
involves reading information from the PC’s serial port (sent to the computer via UART from
the hardware) and calling one of two functions that either count up if someone has just
entered the room, or count down if someone has left. In addition, a reset signal must also
be sent via serial communications to inform the hardware to set the “day total” equal to the
“room total” at the beginning of each new day.
The data storage/archiving software provides the two functions, count_up(void) and
count_down(void), that keep the computer database synchronized with the hardware.
These functions get the current system date and time and check to see if a log file exists
for that day. If a log file does exist, the function increments or decrements the room count
and day count accordingly and appends them to the log file. The log file is formatted as a
comma separated values (.csv) file so that the information can be easily viewed with
spreadsheet software (such as gnumeric in Debian Linux). If a log file does not exist for
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT
.
.
.
.
the current date, the old log file is compressed then archived; the room count and day
.
count are incremented or decremented and written to a new log file; and the reset function
.
is called to set the hardware day counter equal to the room counter.
.
.
.
THEORY OF OPERATIONS
PROJECT LONG TOM
Chapter
REV. 1.0
PAGE 8
Conclusions
6
This document discussed the design details, specifications and architecture for OTTR.
The System Block Diagram shows how each block will interconnect with the other blocks,
as well as how OTTR will interface with the PC. Each MOSIS chip was broken down into
its component blocks and each block discussed fully so that each can be understood.
Finally, we explained the software programming methods that maintained synchronization
between PC and the hardware device.
UNIVERSITY OF PORTLAND
SCHOOL OF ENGINEERING
CONTACT: JEFF SCOTT