Transit Tracking System (TTS)Monica Nguyen, Chris Dorros, Karl Banks,

Tyler Zaino

School of Electrical Engineering and Computer Science, University of Central Florida, Orlando,

Florida, 32816-2450

Abstract — With a skyrocketing student population ranked second highest in the nation among other universities, the University of Central Florida boasts a campus subjected to heavy amounts of traffic on a daily basis. As an effort to help alleviate such traffic, the Transit Tracking System was engineered to promote usage of the university’s complementary transportation system. Designed in harmony between hardware and software, the Transit Tracking System provides a real-time visual display of the school’s buses. With this display, students, faculty, and staff are capable of identifying the exact position of any given bus on- or off-campus.

Index Terms — Accelerometers, Global Positioning System, radio frequency, road transportation.

I. Introduction

In modern society the need for being able to locate where your property is or where you are located has become a growing necessity amongst the general public. People no longer have to get out of the car in an unfamiliar place to ask for directions to know where they are or how to get where they are heading. Stolen or missing vehicles can now be apprehended or found by simply using a Global Positioning System (GPS) to help take control over or locate the desired automobile. Cellular phones can now access the Internet and download applications, therefore providing limitless resources at ones disposal. Many daily-utilized technologies such as cellular phones, vehicles, mp3 players, and the Internet are becoming more and more technologically advanced. A device will be designed for a specific function and as society becomes more technologically advanced they will continuously include supplementary features. For example the cellular phone, several years ago the purpose of a cell phone was to simply make and receive phone calls, then the cell phone gained the feature of text messaging which became a prevalent feature of the device. At present day cell phones can be used as GPS navigational systems,

provide access to the Internet, download applications to assist a person in their daily tasks, and much more. The resources available to society today make it possible to help improve the University of Central Florida’s Shuttling System.

At the University of Central Florida the development of a Transit Tracking System (TTS) has been designed for the University’s shuttling system. The design of the TTS follows the concept of an Automotive Vehicle Locating (AVL) system. An AVL system is accomplished by mounting a small device and antenna on the vehicle that is being tracked. The device communicates with four of the 24 satellites that orbit the earth to triangulate that specific vehicles position. There are three main methods of real-time communication of interval data to a host computer or web server. The GPS data information can be transferred by using radio, cellular, or satellite communication technologies. The University’s TTS utilizes the transfer of data through Radio Frequency (RF), which makes it a very low cost way to monitor a shuttling fleet as there are no monthly fees. The only cost will be the cost of the TTS system itself with no additional cost of labor. [1]

The University has several complimentary shuttling routes available for the students of the institution such as Park and Ride shuttling, the Gold and Black route shuttling, and College Affiliated apartment complex shuttling. The TTS system was designed to increase the use of the shuttling resources available, as only a small fraction of the University’s affiliates use it. The TTS system will also help to allow administrators of the shuttle fleet to monitor and track where shuttling operators are and if they are complying with operation policies. The general design of the TTS will consist of a tracking device on each shuttle unit. Where the data from each shuttle unit will transfer its data to a receiving station, where data will be compiled and organized, so that users can access the web server and know where all shuttle units are and how far they are from the user with an estimated time of arrival (ETA).

II. Overall System

The overall system will feature a steady balance between hardware and software to achieve its goal. The following diagram below shows the overall system architecture, and how each of the components interconnects with each other. Each bus will be equipped with a custom tracking module (labeled “Mobile Tracking Device” in the illustration), which will contain a GPS for location determination and an accelerometer to detect whether the shuttle bus engine is running. This data will be collected and processed by the microcontroller, then

Microcontroller

Custom Firmware

RF Modem

GPS

Accelerometer

RF Modem

Data Collection & Processing Server

Windows

Custom SW

Web Server

Linux

Apache MySQL

Custom DBCustom Web Application

Client Workstation

Any OS

Approved Web Browser

RF

RF Modem

RF Modem

Serial

TCP/IPTCP/IP

Fig. 1 Overall System Block Diagram

packaged and fed through the RF modem. A system of RF modems consisting of multiple repeaters and one receiving modem will be set up on UCF campus building rooftops to receive this data and pass it along to the data processing server. The processing server will unpack the data and store it into the database.

The web application, available through the internet, will gather this data from the database to present its display. The client workstation (or, “Any Device with Web Browser Installed”) will access to the web application, to provide its user with the graphical interface for the Transit Tracking System. The diagram in Figure 2 illustrates this process systems architecture graphically.

Fig. 2 Overall System Illustration

III. Shuttle Monitoring Module

Fig. 3 Hardware Block Diagram

Each shuttle module will utilize one navigational unit and one accelerometer, which will interface to the monitoring module’s microcontroller and send data out through the transmitting unit. The 900MHz ISM band is the frequency that the entire system will use for data transmitting and receiving.

A. Navigational Unit

The navigational unit chosen for the monitoring module is the EM-406A SiRF III by USGlobalSat. The GPS is a 20-channel receiver that includes on-board voltage regulation, LED status indicator, battery backed RAM, a 6-pin interface cable, and a built-in patch antenna. The GPS was chosen due to the built-in patch antenna as to help minimize entities on the board. The interfacing circuit to the microcontroller can be seen in Figure 4 below.

The GPS data is accessed over a UART serial interface connection and is returned from the GPS in standard NMEA format seen in Figure 5 below. [2]

Fig. 4 GPS NMEA Format

After the GPS data received is verified using the received checksum, the latitude, longitude, time, and date are all collected. The latitude and longitude is converted to signed decimal format. The time and date are converted to standard HHmmss and ddMMyyyy formats, respectively.

B. Accelerometer

The ADXL213AE dual axis accelerometer was chosen and is utilized on each monitoring module to determine if a shuttle’s engine is running or not. It has a sensor measurement range of +/- 1.2g. An illustration of the

accelerometer circuit can be seen Figure 6 below. A single 0.1 μF capacitor is connected from VCC to GND, which adequately decouples the accelerometer from noise on the power supply. 0.1uF capacitors are added at X-Filter and Y-Filter pins to implement low-pass filtering for antialiasing and noise reduction. A 1MΩ resistor is added to the circuit to set the period to complete one duty cycle.

Fig. 5 GPS Connector

The ADXL213AE outputs a voltage between 0-5V, varying by slight changes in acceleration. This voltage reading is mapped to integers between 0 and 1023 by the analog-to-digital converter on the microcontroller. When a shuttle bus engine is running, the bus will vibrate

Fig. 6 Accelerometer Schematic

noticeably, and since the tracking device will be placed on the dashboard, this can be realized by the accelerometer. The accelerometer will output a constantly varying voltage when the bus is vibrating, and an almost static reading then the bus is not moving with the engine off. By simply monitoring these readings, the system can determine whether or not the engine is running. An outline of the algorithm is presented in Figure 7.

-Collect 100 accelerometer reading samples

-Calculate the variance of the samples

-Compare the variance with a threshold value, selected after analyzing shuttle bus vibrations

Fig. 7 Engine Detection Algorithm Outline

C. Interfacing to Microcontroller

The ATmega2560 is a low-power CMOS 8-bit microcontroller. The ATmega2560 is powerful enough to execute instructions in a single clock cycle. The microcontroller has non-volatile programmable and data memories. Some special additional features that the controller has are a power-on reset and programmable brown-out detection. It also offers an internal calibrated oscillator; external and internal interrupt sources, and six different sleep modes. The ATmega2560 offers 86 programmable I/O lines, as well as a 100 lead package. An illustration of the microcontroller’s circuit and interfaced connections can be seen in Figure 8.

Fig. 8 Micrcontroller Pin Connections0.1uF capacitors are added from the VCC to GND pins

to implement low-pass filtering for noise reduction. The ATmega2560 has four serial I/O ports available and three of them are utilized for the GPS, RF modem, and RS-232.

The microcontroller embedded on the tracking device board will be the central point of control for each component. The code written for the controller will accomplish three key tasks: 1) collect and process GPS coordinate and time data 2) collect accelerometer data and determine whether the shuttle bus engine is running and 3) send the processed data over an RF transmission stream. An UML sequence diagram is shown in Figure 9 illustrating the high-level microcontroller code functions.

main GPS Accelerometer RF Modem

request location

return location data

read accelerometer data

return packaged data

request packaged data

request to send (RTS)

return result

calculate if engine is running

clear to send (CTS)

transmit packaged data

Fig. 9 Microcontroller Code UML Sequence Diagram

After the GPS and accelerometer data is received and processed it is packaged in a lightweight custom format. The format can be seen in Figure 10 below.

Fig. 10 TTS Data Package Format

D. Transmitting unit

A higher frequency of the RF transceiver provides a shorter the coverage distance. The lower frequency of the RF transceiver provides a longer coverage distance. Therefore a 900MHz XTend transceiver was chosen due to the 40-mile range capability. However the 40-mile range capability is only with a high gain directional antenna with good line of sight. Fortunately the range maximum distance that would need to be monitored for the TTS is a short distance of three miles. The XTend module also utilizes Frequency Hopping Spread Spectrum (FHSS), where the module has the ability to avoid interference by hopping to a new frequency on every packet transmission or re-transmission.

Fig. 11 RF Modem Connector

The onboard RF modem required for transmitting the data must be configured using an integrated command set to allow for customization of the RF network infrastructure. This is typically done manually by attaching the modem to a computer via a serial interface and configuring the device in a terminal. It was decided that for the TTS this should be automated to limit the service time during upgrades or maintenance since this will ensure the RF modem will never be required to be removed from the PCB. To implement this, an RF modem parameter configuration section of the microcontroller code was developed and runs when the device is powered on. In this fashion, changes to the RF modem configuration can be easily modified from the microcontroller code.

E. PCB Layout and Board Firmware

The PCB design will interface and receive its power from a cigarette lighter adapter, which will connect to the shuttle unit.

Fig. 12 TTS PCB Layout

An enhancement that reduces service time is the inclusion of the Arduino open-source bootloader. Typically, microcontroller code is updated via an in-system programmer device, which flashes the firmware onto the chip. Using a bootloader avoids this hassle. An illustration of the bootloader flash pins can be seen in Figure 13.

Fig. 13 Microcontroller Programming Pins

Fig. 14 RS-232 Schematic

The bootloader is flashed onto the microcontroller once and all subsequent loads of TTS firmware are loaded via a standard RS-232 interface, accessible from an external DB-9 connector on the TTS tracking device. An illustration of the RS-232 circuit can be seen in Figure 14. The advantages of this method are apparent. System maintainers can update and modify the tracking device firmware without any special equipment and without disassembling the device.

IV. Data Collection and Processing

A. Receiving Station

To receive the transmitted RF signal from the tracking devices, a system of repeaters and one receiving RF modem will be set up on campus. The transmitting RF modems send their data every 0.5 seconds. Due to the tracking devices being turned on at different times as well as the utilization of randomized frequency hopping spread spectrum, collision are greatly decreased on the system. Initially a polling mode architecture was selected for the TTS system, however repeaters were not supported in the mode and it proved to require a large time overhead. Since the data is packetized by the RF modem before transmission, tracking data from one bus will never overwrite another once it reaches the receiving RF node. Several repeater RF modems will be placed on the roofs of campus buildings. These repeaters receive packets that are within range, make record of the packet id, and retransmit the signal. A randomized delay is instilled in each repeater to avoid synchronized retransmissions from multiple repeaters that are within range of the transmitting device. Additionally, the repeaters keep track of the packet ids to limit the retransmissions to 1 time, avoiding cycles. The receiving and repeater RF modems are configured once using a serial connection to a computer. [3]

B. Data Collection/Processing Server

After the data is received by the RF modem at the campus, it will be transferred via serial connection to the Data Collection program. This program will parse the input data, strip down the information, and convert it to a format useable in Google maps.  This data will then be inputted, by the custom software, to a database holding all recent tracking data.  This will allow for the web application code to access the data and present it to the user.

The main purpose of the data collector and processor is to analyze the data from the transmitters, clean it up, and write it to the database for the use of the web server. This

phase of the software design is what drives the rest of the design. It is constantly receiving updates from all of the receivers on the shuttles. This means that as long as the shuttles are running and the transmitters are sending out the current coordinates, the data collector and processor is running as well. This means the code had to be extremely efficient so it does not create a bottle neck for the system.

The initial phase of the data collector is where the packets are first acquired from the receiver. Here the code receives the data packet in the form of a string from the serial port of the computer. If no packets are available in the serial port buffer, the program sits idle until information begins to be passed through.

The string then moves to the next phase where it gets stripped down so the data will be usable. Within the string, the packet will contain multiple pieces of data; the shuttle id, the current longitude and latitude coordinate of the bus, the accelerometer data, and the current time. In this phase, multiple checks are implemented to ensure that the packet contains valid and correct data. The initial check is to ensure that the packet is complete and correct, meaning it includes all of the expected information, as well as the correct head and tail flags. Another check follows this to ensure that the information received is valid. This checks to ensure the longitude and latitude coordinates are correct for the given system. Once the packet passes all of the previous tests, an object is created to store this information so it can be passed further through the system. If a packet happens to fail any check, then no object is created and the data is dumped.

The final phase of the data collector and processor is where the information is written to the database. The program is already connected to the database, so adding data is very quick. Here, the information from the data object that was created in the previous phase is inserted into an SQL command and is executed. The information will now appear in the database for the web server.

The Data Collector and Processor is written completely in the C# programming language. C# was chosen because it provides many benefits for the program. First, the program is able to be exported a Windows service. This means that the program will be always running the background of the host computer. This eliminates the need for the program to be activated each day and if in the event of a power failure, when the computer reboots, the program will begin. Also, C# provides many existing libraries that help with reading from a serial port and writing to the database using MySQL commands.

The program will be installed and executed as a Windows service to a host computer running Windows XP. The computer will then be connected to the internet; so it can access the database, and it will connect to the RF

Receiver to collect the data. This bundle will sit atop Tower 2 on the north side of campus.

V. Web Application

The user interface for the TTS is strictly web-based. The web application connects directly to the database to access the live GPS data that is sent from the RF modems. The coordinates are used to superimpose a unique icon for each shuttle onto existing map technology. In addition to these icons, the map also displays each bus route in color-coded fashion. While the markers for each shuttle update in real time (as new data is received), velocity information is utilized to predict and simulate movement between each new coordinate transmission. Following this procedure, the movement of the buses appears “fluid” and “steady” to the user. While the majority of the visible screen in the application is dominated by the live action map, a panel on the side offers the user options to “filter” through the routes; filter, meaning one can toggle the visibility of each route on/off individually.

A. Software Configuration

The TTS web application software provides the user with a real-time view of the UCF shuttle transit system. The interface presents a map of the local UCF area, with each route highlighted in a unique color. The user has the option to toggle the visibility of each of these routes on/off, through an options panel on the side of the screen. The options panel lists the routes, by name, along with their corresponding color. The user may simply click on a listed route, to toggle its visibility. On first load of the web application, all active routes display on the tracking map. When a user first clicks a route in the options panel, the selected route displays, and all other routes are hidden. After a route is selected, a “reset” option appears, which resets the display to the initial condition, in which all routes are shown. Only active routes display during any given time of the day. On the map, each active bus appears with its own icon based on the most recent coordinates sent from the RF modem. As the bus moves, the icon updates and moves in real-time. To compensate for the lag between packages received, the velocity and acceleration of the bus is calculated, to predict movement between coordinates. This information is also used to assist with estimating arrival time, which is also displayed on the TTS web application interface.

B. Client Workstation

Developing the client interface as a web-based application allows a user to utilize his/her own workstation for accessing the Transit Tracking System.

Virtually all desktop/laptop computers with a web browser are able to access the TTS web application. The website is hosted on a server at the UCF campus, which is available by accessing its designated web domain (for example: http://tts.ucf.edu/). The user can simply enter the domain URL (Uniform Resource Locator) into their web browser, and they are able to view the real-time status of the UCF shuttle transit system at their convenience. The web application, as previously mentioned, features wide-scale compatibility and caters to the largest possible user population. As long as their workstation meets the minimum required software requirements, any client is able to have access to the TTS.

Upon accessing the web application through a web browser on their workstation, the client is presented with the full Transit Tracking System interface. The figure below shows a rendering of how the application appears on a client’s workstation. The list of active routes is shown in the left panel, displaying the route number, route name, and their unique color. The remainder of the functionality of the map is built-in to the software provided by Google. The user can zoom in/out, scroll in all directions, and toggle the display (map, satellite, or hybrid). The user also has some additional functionality not shown on this rendering, such as clicking on a bus or bus stop to view more information about it.

Fig. 15 Web Application User Interface

VII. CONCLUSION

This project began with a need. Currently the second largest university in the nation, the University of Central Florida boasts an enormous community, full of students, staff, and faculty. Each day, the campus is plagued with heavy traffic, and no available parking. While the school makes efforts to help alleviate this issue by building more parking garages and expanding parking lots, it is simply not enough to cure it completely. Another resource available to help this cause is the university’s complementary shuttle transit system. Not only is this service provided for transit on campus, but it includes several routes off campus to many of the major local housing developments. The unfortunate part about this free service is the fact that its convenience is not realized by a good majority of the student population. Students lack trust in the reliability of the system, and quickly make the choice to use their own personal vehicle for their commute. Thus the problem arises, how to raise awareness and draw popularity to the shuttle system. This problem provided the foundation for which the Transit Tracking System was created.

The TTS project will incorporate a medley of hardware and software to track the university’s shuttles, and to provide the user population with a graphical interface of each bus location in real-time. The overall design selected for this project will provide a fast and efficient way for accomplishing its goal. Each bus will have its own tracking device, where GPS and accelerometer information will be collected, packaged, and transmitted through the RF modem. At the Tower 2 on the north side of campus, the data collection and processing server will gather this data, unpack it, and store it into the database. Each time a new package is received from the bus, a new entry will be inserted into the database. The web application will connect to the database, to retrieve live data and update the map accordingly. The client will be able to access the web application through their web browser on their workstation.

The final product developed in this project should have a very positive impact on the UCF community. This tracking system should substantially increase the reliability of the transit system, drawing more students towards riding the bus and not using their own personal vehicles. This snowballing effect should eventually help to improve the heavy traffic and parking situation that exists at the university.

Acknowledgement

The authors wish to acknowledge David Norvell and Samuel Richie for their extensive assistance and support throughout the entire Senior Design process.

References

[1] United Service Group, “Automatic Vehicle Location (AVL) Services For Minnesota’s Electric Utility Industry,” November 2003.

[2] GlobalSat, “Product User Manual, GPS Receiver Engine Board, EM-406A,” November 2006.

[3] Digi International Inc., “9XTend OEM RF Module: Product Manual,” version 90000959_A, September 2008.

Biographies

Monica Nguyen Monica will be graduating from the University of Central Florida with a B.S.E.E in May 2011.

She is currently employed at Cubic Simulation Systems Division as an Electrical Engineering Intern. She plans to pursue a full time position in Electrical Engineering upon graduation.

Chris DorrosChris will be graduating from the University of Central Florida with a B.S. in Computer Engineering in May 2011. He has worked with Lockheed Martin for the past three years as a Systems Analyst. He will be moving to Pittsburgh in

August to pursue a Master’s in Information Technology & Security from Carnegie Mellon University.

Karl BanksKarl will be graduating from the University of Central Florida with a Bachelor of Science

degree in Computer Engineering in May 2011. He has maintained a position as lead developer on the JSF program at Lockheed Martin for two years. He plans to pursue a Master’s degree in Engineering Management at the University of Central Florida.

Tyler ZainoTyler will be graduating from the University of Central Florida with a B.S. in Computer Engineering in May 2011. He is currently employed at Pioneer Technology Group as a Quality Assurance Intern. He will pursue his Master’s degree in Engineering Management at the University of Central Florida.