Results

Our design turned out to be very robust, yet very simple to understand. The scheme we used to control the menu selections was very structured, making it easy to add features and transition between different menu screens. By storing and manipulating a few global state variables, we were easily able to implement the different features of the device. Timing was not an issue with this project since none of the features were very time sensitive. The only feature that needed to be time accurate was the clock, which was controlled by timer1. Thus, the clock was accurate for our purposes.

Although our database consisted of a small set of cities and interstates, there is a large potential for usability of our project in a commercial setting. The database is easily expandable, subject to memory limitations, and the functionality is easily extendable.

We first tested our device in Manual mode and all of the features worked as expected. We did not notice any bugs or glitches in our implementation. In order to test our device in NMEA mode, we needed a GPS receiver capable of outputting NMEA sentences through an RS232 connection. In place of a GPS receiver, we obtained a GPS simulator software that outputted configurable NMEA sentences through the COM port of a PC. As a result, we were able to connect the PC to our device and test our features under a variety of circumstances, such as constantly changing position. Again, our device worked as expected and we are convinced that our device is compatible with any commercially available GPS receiver capable of producing output to the above specification.

One issue we encountered while developing our device was memory limitations. The memory available for implementing our device was limited, due to the large amount of information stored in the database. We made an initial guess as to how many cities we could afford to represent in our map and it turned out to be very close to the maximum number of cities we could store, given the set of features we wanted to implement. There was a point at which we ran out of RAM due to the information we needed to store. To rectify this, we reorganized our memory usage so that we could utilize available flash memory. Flash memory turned out to be an issue also as we implemented more and more features. Since the instructions are stored in flash and we had a lot of conditions to handle, we had to eliminate some of the features we originally intended so our program could fit on the chip.

Click here to see pictures demonstrating our project