Real-Time Wireless Bus Schedule System using 802.11b and GPS, Study Guides, Projects, Research of Electrical and Electronics Engineering

Download Real-Time Wireless Bus Schedule System using 802.11b and GPS and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!

Wireless Bus Schedule with

802.11b

Orus Coffield and Jasen Su

ECE 345

TA: Matthew Olsen

December 4, 2001

Project # 20

Abstract

The wireless bus schedule is a first step toward providing users of public transportation with real time information concerning a bus’ current and future positions. This system is also expandable and easily modified to accommodate very large areas of operation. It is also applicable to other arenas were the need for real time information and mobility are at a premium. This system incorporates a GPS receiver in combination with a wireless network operating in accordance with the IEEE standard 802.11b. Location data is coded by the GPS receiver then decoded and displayed in a webpage-based interface employing a Java applet.

1. INTRODUCTION

1.1 Project Functionality

Our system uses the Global Positioning System (GPS) to find a current location of a bus. When this location is known, the position of the bus relative to its surroundings is displayed on a web page. We chose this project because it uses the latest technology and would fill a need in many of our country’s metropolitan areas.

1.2 Project Overview

This project is composed of different systems working independently. The interfaces we use combine these systems into one smoothly functioning machine. First, the GPS receiver finds the bus’ current location. This data is then stored in a text file. An applet written in Java is able to access this text file over the wireless network. Using the GPS position data, the applet produces a graphical representation of the position of the bus. These three systems, the GPS receiver, the wireless network, and the Java applet are described in detail below.

1.3 Project Application

This project was designed with a civilian application in mind. Firsthand experience in Champaign- Urbana has shown buses rarely abide by the bus schedules printed at the beginning of each year. Our system would allow users of public transportation systems to know exactly how long the wait is for the next bus. Users would then have more freedom in their choices of transportation. Ultimately, this system would make a public transportation system more efficient and accountable.

2. DESIGN PROCEDURE

2.1 Fundamental Design

When we decided to pursue this as our final project, there was not a clear way to implement the system. We did however have some requirements that needed to be met in order to accomplish our goals. These goals included:  A way to communicate with GPS to extract location data  Being able to connect 2 computers VIA wireless network  Provide a way to process and display information of data remotely. Putting these three requirements together, there were two ways we could implement this. One way would be to write a stand-alone program using Visual C++ that would be able to display the bus schedule on the screen. The other way would be to write an applet using Java that could be displayed using a Java enabled web browser. The first option would require extensive knowledge in how to make graphical stand-alone programs which counterbalances the positive attribute of quick and powerful parsing of C++. (There are actually functions built into the C++ library that can perform parsing) Therefore the amount of time needed to complete the project would not be feasible or practical. The second option, despite having to write our own parsing methods, not only is able to satisfy our goals but also provide the means necessary to efficiently carry out our project. By using our Java knowledge from CS 125 along with some additional resources, we could write an applet that could process and display information from the GPS. Another advantage for using Java is its ability to be cross-platform compatible. Therefore, the program running is hardware independent. Another factor to consider involved which wireless protocol to use. When we researched the market of wireless networks, IEEE 802.11b was the clear favorite. Unlike the Bluetooth protocol that is meant for wireless applications in short distances, the 802.11b operated on a “line-of-site” basis. Since bus routes are capable of covering long distances, we needed a protocol that matched our needs.

2.3 Software Block Diagram

The software block diagram of our system is shown below in fig. 2.3.1. Fig. 2.3.1 – Software Block Diagram of System This diagram goes into further detail about the flow of the software involved in our project. The software will begin by performing initialization of variables and constants. Information such as bus stop locations, time to travel between stops will be stored inside the program. The next step involves grabbing the GPS coordinates to performing calculations. After the program performs the ETA and location calculations, the values are reflected in the painting of the applet that appears on the web page. After the web page is updated, the applet will wait four seconds before grabbing the newest GPS coordinates. Grab GPS Coordinates Initialize Variables Perform Calculations Wait four seconds Update Web Page

3. DESIGN DETAIL

3.1 Setup of Server

One of the problems that we encountered was that the applet would not display on the remote computer. When started, the applet would give an error and a gray square would be visible instead of the actual applet. In order to bypass this problem, a web server must be installed in order to make the local text files appear not local and allow the applet to read and write to them. This involved us to install Microsoft Personal Web Server on the host computer and configuring it to be available over the network. By copying all of the used files onto the root directory of the server, this allowed us to serve the applet to remote computers without getting the “sandbox” error from Java. Basically, in this “sandbox”, Java places security restrictions such that no local file can be read from or written to. This prevents hackers to write malicious code that could potentially harm a user. After we installed the server, it is loaded up into memory at startup. To access any given file in the web server, the following address can be typed into a web browser to get into a web page: http:// computername/ webpage.html

3.2 Setup of Wireless Equipment

The next item of interest is the wireless equipment. First, in order to implement a wireless network, we need a minimum of two wireless network cards and one wireless access point. After the network cards are installed, in order to communicate with each other, both network cards must have the same SSID (Service Set Identifiers). The SSID allows security from renegade wireless cards that try and communicate onto the network. Both network cards must also be on the same channel in order to communicate. Without both the correct SSID and channel, the ability to connect wirelessly through the access point is nonexistent. The computers will also be configured to be on the Ad Hoc network structure. As mentioned before, the Ad Hoc structure will allow both computers to travel between multiple access points without problems.

Using the format of the loc.txt file mentioned earlier, we could easily use that format to write data into our Stop object. Grouping each GPS coordinate into the stops, we made an array of Stop objects that could easily map out our bus route. The file text2.txt contains the data dump from the GPS unit. Using the JNAV program, the GPS constantly logged its current position in the log file. Using this log file, the applet searched for the newest coordinate and performed the ETA calculation as well as the plot location. Finally, the time.txt file is a list of numbers that represent the average amount of time to travel between stops. These numbers would be pre-measured and known to the system beforehand. This file is essential in calculating the ETA as described further in this paper.

3.4 Applet Calculations

The customizations mentioned above are used to perform various applet calculations. There are two algorithms that are at the heart of the applet. These two methods allow the bus to be plotted correctly on the screen and have an accurate ETA.

3.4.1 Plotting Location of Bus

The Java coordinate system starts at the upper-left hand corner of the screen. As you increase the x value, the point moves to the right and as you increase the y value, the point moves further down. In the applet, we wanted to maximize the area of the bus route occupied to reduce the confusion of the bus location. Arbitrarily experimenting with numbers, these four coordinates became the “bounds” of the bus route. Refer below in table 3.4.1. Java Coordinates Description (10, 460) Stop A – Lower Left Corner (380, 460) Stop B – Lower Right Corner (380, 160) Stop C – Upper Right Corner (10, 160) Stop D – Upper Left Corner Table 3.4.1 – List of Files Used for Customization With these boundaries defined, the next step involved finding the distance associated with each GPS coordinate. Locating the min and max GPS coordinates (as extracted from the loc.txt file), a simple

equation can be solved to obtain the distance moved per GPS coordinate. Since the horizontal and vertical amounts are scaled differently, we needed two different equations. The first equation takes the difference in longitude and solves for the distance traveled on the applet for each .001 longitude traveled. longitude1 - longitude2 = (380-10) x (1) Likewise, the latitude equation takes the difference in Latitude and solves for the distance traveled on the applet for each .001 latitude traveled. latitude1 - latitude2 = (460-160) y (2) Using these constants, we can plot the next location of the bus by multiply the change in latitude and longitude from the previous stop by the corresponding conversion factor. Using the new results and a few logic statements (mainly to make sure we do not have a negative distance) we can update the next location of the bus.

3.4.2 ETA of Bus

The second algorithm involves the ETA of the bus. This method uses the time.txt file to make estimates on the arrival time of the bus. The first step in determining the ETA is to figure out the next stop of the bus. Using the loc.txt file and grabbing the most recent GPS coordinates, the method can instantly test for the next location of the bus (ns). Once the location is determined, it is compared to the current stop to see if they are the same. If they are not the same, the applet adds up the ETA of the stops found in time.txt from the ns+1 stop to the stop before the actual bus stop. Added to this value is the proportion the bus has traveled to its next stop multiplied by its corresponding value. If the next stop (ns) of the bus is equal to the bus stop at which the schedule refers to, just the proportion of the bus to the next stop is calculated and returned by the ETA algorithm.

in order to draw attention to it. The text found below the applet provides a medium to transmit messages or advertisements to those who use the bus. In this screen shot, we are able to inform the community that all bus services have been cancelled. Finally, on the right hand side displays the entire bus route. This is provided as a service so that previous knowledge of the bus schedule is not required.

3.7 Obstacles and Solutions

Over the course of our project we did run into several obstacles but came up with solutions to these problems as well. The first main problem involved our inability to view the applet on the remote computer. As mentioned above, the only way to successfully bypass this problem was to install a web server onto the host machine. Serving the files off the web server, we were able to read and write to the files we needed to run the applet. Our next obstacle involved not having a GPS unit for most of the semester. In the end, we had to purchase our own GPS unit so that real testing could begin. Once we overcame that obstacle, we ran into some problems with our JNAV program. Because JNAV could only record logs once per minute, this was not feasible due to the fact that our demo route was about 4 minutes total. When confronted with this problem, we discovered that the GPS unit itself could dump its own data into a text file supported by JNAV. Therefore we went with the second implementation in order to more accurately display the location of the bus. Once we overcame that obstacle, we ran into more problems. The dump file that the GPS unit was producing gave us coordinates to the one one-thousandths of a minute whereas the sample files used to parse the data were only given to us in one one-hundredths of a minute. Therefore we had to rewrite the entire parsing method in order to satisfy this new format. Our next problem was encountered when we began testing the location plots and ETA outputs. To our surprise, the applet had problems plotting certain points along the graph as well as produce erroneous ETA outputs. A closer look at the problem showed that the GPS simulation of the path always rounded some corners that did not set well with the applet code. In the applet, it was assumed that the bus would always keep a straight route. Even though in theory we would want this to be true, in reality we had to

account for minor errors in following the bus path. Readjusting our code, we allowed the GPS coordinate to be .004 away from the true bus path. This "fudge" factor allowed the applet to run smoothly and accurately.

5. Special Circuit

5.1 Circuit Schematic

The special circuit requirement this semester was to construct an ultrasonic sensor. We chose the center frequency of our sensor to be 40 kHz, as our research showed that value is a common value among those in the sonar community. The schematic of our circuit is shown below in figure 5.1.1. Fig. 5.1.1 – Special Circuit Schematic

5.2 Theory of Operation

The ultrasonic sensor is made up of two parts – a transmitter and a receiver. The transmitter is built around a KA555 timer chip. When pin 4 of the timer chip is high, the chip emits a signal through pin 8. The frequency of the emitted signal is governed by R1. By adjusting R1 to the appropriate resistance, the signal is set to 40 kHz. This is measured through the oscilloscope from pin 3. The receiver is a more complex circuit. The signal is received and sent to an LM741 op-amp where it is magnified 1000 times. The magnified signal is then sent to the signal decoder LM567. By adjusting R2, the decoder chip is set to respond only to signals at the 40 kHz frequency. When the decoder senses the appropriate signal, pin 8 goes low. Pin 8 of the decoder is connected to pin 2 of the LM comparator. This chip compares the voltages at pin 2 and pin 3. By adjusting R3, pin 3 of the comparator is set at 2.5V. When the voltage at pin 2 is less than pin 3, then pin 7 of the comparator is low and the LED lights up. Our circuit was designed with the transmitter and receiver located about an inch apart facing the same direction. As long as no object disturbs the transmitted signal, the receiver will not detect anything. However, when an obstruction appears, the transmitted signal is reflected and picked up by the receiver. The receiver circuit then goes into action and the LED proves the signal is received.

7. CONCLUSION

Our system constructs a creative application for wireless networks. It is a tool that could be very useful for any bus transportation company that seeks a way to increase customer service and keep track of its employees. Using one wireless access point, it can support 32 simultaneous clients as well as cover a radius of 300 meters outside. With the use of multiple access points, buses could seamlessly pass through the Ad Hoc network to stay connected. In terms of goals we wanted to accomplish, we not only succeeded but also exceeded our own expectations. Making a real-time bus schedule, easily configurable through text files, we offer a way for companies to quickly customize their own routes as well as have a system that has been thoroughly tested to work. A major goal we wanted to do was use off the shelf parts to create this system. This allowed us to reduce our development costs by using equipment that has already been tested to work and was on the open market. Using these parts, we can provide a solution to companies that could easily be adapted to their own needs. This project was a feasible semester project that has many other possibilities. We hope that this project inspires others to use 802.11b to help the people of the world to communicate with each other.

8. REFERENCES

Flanagan, David, Java Examples in a Nutshell, 2nd Edition, California: O’Reily & Associates, Inc, 2000 Lemay, Laura and Rogers Cadenhead, Sams' Teach Yourself Java 2 in 21 Days, New York: Sams Publishing, 2000. .