Portable Web-based Tracking System

Midterm Proposal


CPSC 483.501: Dr. Rabi Mahapatra

November 3, 1999

Jennifer Arnold

Barbara Davis

Luther Durkop

Greg Feiner

Portable Web-based Tracking System

Abstract

In the rapidly changing communications industry, if a product is not portable, then it will eventually become obsolete. As a result of the recent explosion in electronic technologies, practically everything is becoming mobile. Telephones have become portable cellular devices and personal assistants have become highly transportable. Personal assistants made by 3Com and Compaq, to name a few, are calculator size computers that can perform basic computer functions in a small, portable package. At present, the only moveable tracking devices available are hand-held or mounted in vehicles. The main difficulty with these devices is that they are not truly portable and that the person who knows their position is the one with the device. The Portable Web-based Tracking System (PWTS) is able to actually create a transportable tracking system. This system uses a global positioning system (GPS), such as what the hand-held devices use, a hand-held Windows CE PC, and a Personal Web Server connected to the Internet to make it completely portable. By placing the data of the tracked object dynamically on the Internet, users are enabled to see where an object is from any location in the world. No longer does the user have to be at a specific base location to be able to track an object. The user can be at home, at the office, or on vacation and be able to check a predefined web site for an update on the object’s position.

Introduction and Background Research

The idea for PWTS came from several ideas from all of the group members and from ideas from Dr. Rabi Mahapatra. We wanted to create a portable tracking device that could be used to constantly trace an object and send that location and time data to a central location. We wanted to design a truly portable device because when dealing with tracking an object, having connections to power or other communication lines make it difficult to maneuver.

In many different areas of commerce, tracking has become a rapidly growing interest. Several car rental companies are designing tracking devices in vehicles to help with navigation in unfamiliar cities. Numerous hikers and campers are using hand-held devices to keep track of their location via GPS. However, all of these systems are missing one important functionality. None of the location and time information available to the users of these products is available to others that are dislocated from the actual device. This is where the real benefit of PWTS lies. With PWTS, the user will be able to access data from the device from any location in the world using a computer that has access to the World Wide Web. With this added new ability, tracking can be taken to a whole new level. Now, a person in Europe can track a ship sailing across the ocean, or track a car on a trip in North America; all this by accessing a single web site. PWTS has many different qualities that formulate it into an exciting and challenging project. This project also has features that feed off of each of the team members abilities. Thus, making the product the best it can be by combining the best of all of the team members’ abilities.

Data Acquisition Methodology

The procedures used to dynamically link the GPS Data File acquired from the modem connection, to our Web site involves four transactions of connectivity.







Individual Achievements

Jennifer Arnold- Database and Web Site administrator/programmer:

  • Setup the personal web server
  • Setup the database ODBC system files, database, and GPS data source file linked to the database
  • Established database connection with the web site
  • Implemented several web page functions for tracking and displaying information about the GPS device movements and locations
  • Created functions, routines, and queries for data conversion, data extraction, and table relationships within the database
  • Provided solution for mapping the GPS device on the web
  • Created a map database of College Station to be used to track the GPS device on the web.

Barbara “Jeana” Davis - Web Graphical User Interface Designer:

Jeana has been working to create the web graphical user interface for the web site that will display the current location information. The web user interface incorporates all the functionalities Jennifer has designed into the database to connect to the web site. She has designed the web site to be easy to navigate and locate information on the GPS data.

The web site allows access to several different mapping and GPS web sites that are maintained by other companies on the Internet. Currently, information on latitude, longitude, and height have been incorporated in the site and are refreshed continuously so as to reflect any new information that may be in the database.

Jeana has been researching solutions to solve the challenge of displaying a street level map on the site that illustrates the current GPS position. She found several mapping applications that could be potentially used to display this information including GPSS, ARPS, AGIS, GPS Navigation Wonder, ESRI and Intergraph. The GPSS software seems to contain some good street level maps and she has contacted the creator of this software to obtain more information on how to interface this software with the web. By using JavaScript within the HTML coding, an application of any kind can be spawned and then information from that application can be generally manipulated.

Jeana spent two weeks working on JavaScript code to pull GPS mapping data out of the GPSS software without help from the creator of the software and was only able to start the application and pull some data from the application. It seems that the GPSS software package that is available on the Internet is not complete and cannot be easily implemented for use on the Internet as we had planned.

Jeana also spent a considerable amount of time working to figure out how to implement APRS GPS software on the web interface. After studying this option, she found that the only maps that were viable to use in our application are vector maps. Since we would like street level map functionality, this software will not be useful in our project and another solution will have to be found.

The difficulty is in finding an application that will push only the map (excluding any extraneous information) to the web site and then refresh this part of the application using JavaScript. So far, a mapping application that can provide this type of functionality without completely consuming all of our development time has not been found.

While Jennifer has been working on a solution to put maps into the database containing specific latitudes and longitudes for street level maps in College Station, Jeana has been working to create a mapping application using HTML layers with JavaScript to dynamically change a pointer on the static maps Jennifer has stored in the database. If this is possible, the solution will allow us to conserve space on the server by reducing the number of maps that are stored in the database. Jeana is researching, writing, testing code to see if this is a viable option for us to pursue. The main difficulty comes in finding a quick way to convert the map pixels into latitude and longitude coordinates, which may take more time than is available to complete the project.

Luther John Durkop-GPS system designer/ Overall system engineer:

John was able to finish re-designing the Power System to work with the Motorola VP Oncore receiver. The Power System had to be modified to support 12 V output to the receiver. So we use two 9V batteries in series to make 18V. That 18Vline is connected to a 12V-voltage regulator that outputs 12V to the receiver. We also have another connector that sends 12V from a car adapter to the receiver. Then there is a switch to allow either one to be used at a time. The following is a figure of the new Power System.

John also worked with testing and developing of connection with the GPS unit to the Power System and the MobilPro 800. The Motorola VP Oncore receiver came completely with a serial port conversion system. That is the reason that the Power System was redesigned. The serial conversion that came with the receiver requires 12V to run. Due to this option on the receiver we no longer need to use our own serial conversion. Now the GPS data can go straight into the MobilPro 800. Due to the fact that the GPS receiver outputs data in the form NMEA output. We had to add code to the server to discard the data that contains satellite information and signal strength. This data might be useful for another application, so it can be added back in if necessary, but for our project, it is unnecessary and will only take up more space in the data file.

John has also been researching mapping options and trying to trouble shoot problems with refreshing the web page when data is being written to the data file by the server. Currently we are having a problem when the web page is accessed at the same time when the data is being written to the file. This produces an ODBC error that cannot be controlled using HTML. This produces an error that is not pleasant when wanting to view real time data. Currently we are looking into several options to try to handle this problem. One idea is to write in the server code some signaling to tell the database when it is writing to the file, then when the page is accessed and it checks this signal it will know to wait to access the file. Another idea is to create a clone page with the last data in it, so if the file is being used it can simply post the last web page. While both these ideas are good, John is still looking for a more professional solution and looking into the feasibility of these two existing ideas.

The mapping solutions John is looking into is the ability to have a simple mapping application on our server to where we can run is using a Java applet to continuously display where the receiver is when the data file is updated. Many of the team members have been working on this and we have found many different approaches using web-based maps on other pages, but have not been able to find much on developing a Java applet to control a mapping application. It might turn out to be too much work to do for this project, but may be feasible for part of another semester project.

John has also been working with Greg in testing/debugging the server client code on the MobilPro 800 and the server. John and Greg have been working to get the MobilPro 800 to be able to dial up and receive data on the serial port and send it out over the phone line to the server where it receivers the data and saves it to the data file. So far we have been successful in sending data from a file over the phone to the server where it is saved. However we are still trying to get the data into the MobilPro 800 over the serial port.

John has also spent time researching the serial communication for the GPS to the MobilPro 800. However, this research will not be useful due to the fact that the GPS unit came with its own serial conversion. If the receiver had come in sooner when expected this time could have been managed better.

Greg Feiner- Cellular communication designer/ Overall system engineer:

Modifications to Original Proposal

  • Modem to Modem Software

Due to difficulties in getting direct modem-to-modem handshaking to work in

Windows CE, we changed the method of connectivity. Instead of using a single program to dial directly into the server and communicate with its modem, we are know using a socket-oriented approach. Using this approach provides a level of redundancy that we didn't have before.

We are now using two programs, a TCP client program that resides on the hand-held computer, and a TCP server program that resides on the Windows NT workstation. Using the dial-up networking capabilities of Windows, we establish a network connection with any Internet Service Provider. Once this is done, the client program simply attaches to a TCP socket on the workstation that has been created by our server program.

The redundancy comes into play if the network connection of the workstation goes down or if the Internet Service Provider goes down. Should this happen, we can use the dial-up server capabilities of Windows NAT to dial directly into the workstation. This provides the client with a regular network connection just as if it had dialed into a ISP. So we now have a backup method of connecting to the server, should the other connection terminate unexpectedly.

  • Modem to Modem Software Details

The client program starts off by initializing the serial port to receive data from the GPS receiver. The serial port is set to 4800bps, 8bits, no parity, and 1 stop bit. Once this done, two threads are created. One thread reads data from the serial port and stores it in the buffer. As it does this, it filters the data to make sure complete data packets are stored. This is needed to ensure that data is saved starting at the beginning of the packet and not somewhere in the middle. All data packets that we are interested in start with $GPGGA and end with a carriage return followed by a line feed. The data packets can vary in length, but are at most 79 characters. The second thread takes the data that was buffered by the firs thread and sends it to the server via the socket command send. This process continues over and over with each thread taking turns doing its task. This process doesn't stop until the user specifically ends it. Due to the buffer being a shared resource between the two threads, synchronization techniques are employed to ensure that the two thread don't attempt to access the buffer at the same time. This could cause the corruption of data or cause incomplete data to be sent to the server. To do this, mutex objects called "events" are used to signal a thread when it is safe for it to proceed. When one thread has done its job, it signals the other that it is safe "to go." Threads are used instead of regular functions because the reading and sending of data is something that occurs continuously. Regular function calls block until they return. If we did this, the GUI would be totally unresponsive, since the functions would have to be called over and over again. The use of threads solves this problem. The Windows operating system rapidly switches control among the threads, making it appear as if they run simultaneously.

The server program just basically performs operations opposite that of the client. The server program creates three threads upon execution. The fist thread creates the TCP socket and listens for incoming connections. Once the client makes a connection to server, control is passed to the thread that reads the data from the socket. The data is placed in a buffer just as it was in the client program. The read thread takes in the data character by character using the recv socket function. Each incoming character is checked to see if it is the '\n'. The '\n' marks the end of a complete data packet. When this is received, the packet is stored in the buffer and a null terminator is added to it. Seven data points are cached in the buffer. Once the buffer is full, control is passed to the thread that writes the data to the database file. This is done using a simple fprintf command. Once the data is written to the database, control passes back to the read thread and the whole process starts all over again. This continues until the client disconnects from the server or stops sending data. Mutex objects are used, just as they were in the client, to synchronize the read and write threads.

  • Mapping Software Changes

When we originally proposed this project, our thought process on how to attack displaying the information we collected from the GPS device was a little different than it is now. At first, we were planning to show raw data from the GPS on the web site along with manipulated data that was a result of calculations on the raw data. We also planned on displaying a map that was generated using the raw data from the Tiger Mapping Service. As we researched and studied how to go about accomplishing this functionality, we discovered that it would be better to use maps generated by MapBlast. MapBlast’s maps are highly featured and allow users to see the world at street level.


Instead of depending on the MapBlast site to constantly be accessible when map information is needed, we have developed a strategy that will allow us to access the mapping information from the Personal Web Server. By storing map images in the database linked with the latitude and longitude information for that image, the maps will be available when our server is on. This will also allow us to display just the image of the map on our site rather than the entire site page from MapBlast that contains the image.