Project Proposal. GPS Collection Unit

Transcription

1 Project Proposal 24 April 2007 Jerald Sussman, Aaron Isaki, Project Abstract This project is a prototype unit of a small Global Positioning System (GPS) collection and storage device. The device will collect GPS data, display critical information from the GPS receiver on an LCD screen, and store selected GPS data onto a non-volatile SD flash card. Because receiving valid GPS coordinates indoors is a challenge, our project incorporates a set of 900MHz transceivers to wirelessly transmit the streaming data from the GPS receiver outdoors to our Z8 board located indoors. The non-volatile SD flash card is then read by a laptop and the coordinates are displayed on a custom stand-alone mapping application that was written in C# using Microsoft's MapPoint mapping software. The Visual Studio 2005 development environment was used for this application. The proposed requirements that the project must meet are: Interact with Garmin GPS over serial interface Communicate streaming data successfully over the MaxStream wireless modules Parse streaming GPS data and display it on an LCD screen Use a SD-card to log the GPS data Be able to read the stored data on a PC, and load it into Microsoft MapPoint for displaying. Status The project worked as planned. We were able to successfully create a GPS data stream from a GPS receiver that was then transmitted through the pair of wireless transceivers and then into a UART on the Z8 hardware development kit. The Z8 parsed the data, then both displayed the parsed data on the LCD display and wrote it to a file on the SD card. Due to a time crunch, we weren t able to implement the optional speaker as we d initially planned. Something that was a bit unexpected is that the two NMEA GPS records that are sent are separated by about one second. Quite unexpectedly we noticed that we are not Page 1 of 19

2 getting all records processed because by the time the first record has gone by and the second GPS record has started transmitting, the Z8 microprocessor is still processing the first NMEA record. This is not a significant issue, however it was unexpected and therefore noteworthy. Unfortunately during the live demonstrations in Washington DC one of our transceivers malfunctioned causing the GPS receiver to constantly transmit it's last known coordinates which were in Centreville, Virginia. LCD and flash memory card writer worked flawlessly and the Mapping software did correctly display the Centreville coordinates. Specification GARMIN OEM GPS receiver (model GPS-35PC) The purpose of this project was to build a prototype GPS collection and storage device. We used a GARMIN OEM GPS receiver (model GPS-35PC) for accurate GPS position information. Prior to using the GARMIN GPS-35PC receiver we configured the device using the "GARMIN Sensor Configuration Software" shown below in figure 1 and figure 2. Figure 1 shows the initial configuration of the software where the user selects the serial port that the GPS receiver is connected. Figure 2 shows the sample configuration screen. Notice that the GPS receiver could be configured to transmit the NMEA GPGGA, GPGSA, GPGSV, GPRMC, PGRMB, PGRME, and PGRMT. We felt that we really only needed two NMEA sentences to obtain the information that we wanted to display and that the transmission of all the other NMEA sentences might slow down the overall embedded system program. Figure 1: GARMIN GPS-35PC Configuration Utility Page 2 of 19

3 Figure 2: GARMIN Sensor Configuration Software The GARMIN GPS-35PC receiver has two cables attached in a single wire harness that leads to the GPS receiver enclosure. The first is a power harness that has a car-lighter socket attached to it. During development of the unit we used an AC adapter to convert standard household outlet to 12-volt DC power for the GPS receiver. We used this same AC Adapter inside the demonstration room for stationary demonstrations. Maxstream model X We also used a pair of serial data transceivers in order to place the GPS receiver outside the building in field of view of the GPS satellite constellation. The two serial data transceivers were Maxstream model X transceivers which transmitted serial data at 9600 baud at 900MHz. A null modem adapter had to be used between the connection of the GPS serial cable and it's transceiver. Page 3 of 19

4 Figure 3: Transceivers with one Null-Modem Converter The output of the second transceiver was then connected to UART0 on the Z8 hardware development kit. The Z8 hardware development kit also had a 16 byte LCD unit that was connected as shown below in figure 4. HD44780-equivalent LCD screen We obtained an HD44780-equivalent LCD screen with an 8x2 character screen output. The physical hook-up was as illustrated below, the variable potentiometer being used to control the contrast on the LCD screen. 10k Pot Resistor +-/\/\-+--/\/\-+ LCD Display Z8 Dev. Kit GND ) ) GND VDD ) Vcc VL RS PE3 RW PE1 E PE2 D PE4 D PE5 D PE6 D PE Page 4 of 19

5 Figure 4: Connections of LCD Array Much of the code for controlling the LCD screen was reused from Zilog application note 0143 entitled Character LCD Interface for the Z8 Encore! MCU. We had to modify it to run on an 8x2 rather than 16x2 LCD screen, but otherwise the majority of the code was unchanged. Sparkfun Breakout Board for SD-MMC Cards Page 5 of 19

6 We obtained from the professor an SD-card breakout board to use. It actually only had nine pins, and was fairly straightforward. The picture below is a close approximation of the board, though the actual board did not include a COM or CD switch. The other pins have the following function: WP : Write Protect Detect Switch P9 : Not used in SPI Mode (Pin 9 on SD Card) IRQ : Not used in SPI mode (Pin 8 on SD Card) DO : Serial Data Out GND : Ground - Connect this to COM to ground the housing CLK : Serial Clock VCC : 3.3V Power DI : Serial Data In CS : Chip Select SD-card reader from Sparkfun WP+-- not connected P9+-- not used in SPI IRQ+-- not used in SPI DO+-- PC5 (MISO) GND+-- GND CLK+-- PC3 (SCK) VCC V (VDD) DI+-- PC4 (MOSI) CS+-- PC Hooking up the board was as illustrated above, and communication was done over the SPI interface. Issuing commands to the SD-card took the following format: The SD card commands were issued in the first byte (bit 7 is always 0 and bit 6 is always 0), then four bytes for arguments, and a CRC byte. By sending the correct sequence of commands (10 clock cycles, GO_IDLE_STATE, SEND_OP_COND, and SET_BLOCKLENGTH) and then driving the SPI bus with clock cycles, we were able to interact with the SD card. Important things to note are that the CS pin is driven low whenever we want to talk to the card, and that clocks must be fed into the card to drive it. The SD card we used was formatted for FAT16. Table 1. Selected SD Memory Card Commands Page 6 of 19

7 Command Mnemonic Argument Reply Description 0 (0x00) GO_IDLE_STATE none R1 Resets the SD card. 9 (0x09) SEND_CSD none R1 Sends card-specific data. 10 (0x0a) SEND_CID none R1 Sends card identification. 17 (0x11) READ_SINGLE_BLOCK address R1 Reads a block at byte address. 24 (0x18) WRITE_BLOCK address R1 Writes a block at byte address. 55 (0x37) APP_CMD none R1 Prefix for application command. 59 (0x3b) CRC_ON_OFF Only Bit 0 R1 Argument sets CRC on (1) or off (0). 41 (0x29) SEND_OP_COND none R1 Starts card initialization. After a successful command transmission, the card does the appropriate task and returns a response. The response bits must be checked to ensure the command was successful, or for the error conditions it found. Data transfer between the host and the SD card involved transmitting commands and checking the responses. This is an example of data transfer from the host to the SD card. Page 7 of 19

8 This is an example of data transfer from the card back to the host. Software Used The software design of the project is divided into three parts: the serial interface from the GPS/transceiver, the LCD interface, and the SD-card interface. The majority of the files were needed for the SD-card interface because it required SPI and FAT libraries. File Listing: Application Files main.c main entry point of the program. Initializes UART, LCD, SPI interface, and LED array. Launches main application thread LCD_API.c/.h Minor modification to Zilog application note source code, used to control the LCD screen SPI.c/.h Serial Peripherial Interface code for SD card PIC_MMC.c/.h Code to interface with an MMC card and converted to work with our SD card (borrowed from web) fatlib.c/.h - FAT library code to work with the SD card (borrowed from web) HALayer.c/.h - Hardware Abstraction Layer code from web to help abstract away some of the SD card interactions typedefs.h common type definitions used by the other files Page 8 of 19

9 Implementation & Constructions The above is an illustration of the data flow in our project. The raw GPS data comes in from the Garmin GPS unit and is transferred via serial connection to our wireless transceiver. The raw GPS data then travels to the other transceiver over 900MHz connection and is read on the serial port of the Z8 board. The Z8 processes the raw data and formats it for display on the LCD screen and to be written to the SD-card. Page 9 of 19

10 The above is a flow chart illustrating in greater detail the sequence of data processing. Retrospective During the development of this project we made several import design decisions that helped improve the development and testing cycle of the project. First, we came up with a design that would allow us to transmit in live GPS data into the classroom. As described above we did this using a pair of serial data transceivers. This was a simple, low-cost design decision which proved successful in testing. The serial transceivers also proved successful during Aaron's in-class serial data transceiver presentation; however during the actual demonstration the serial data transceivers failed to operate. The cause of the failure is still unknown however during the demonstration the GPS receiver was directly connected to the Z8 hardware development kit and the LCD unit did display the last know GPS receiver information and the data was written to the SD card. The SD card was then read and the GPS data was plotted onto a Microsoft MapPoint Window on an isolated laptop. Another important design decision was the selection of the 16 character LCD display that we used in lab #4 to display parsed GPS data. This decision proved useful Page 10 of 19

11 from a cost, schedule, and performance perspective. First, since we used the same LCD display from lab #4 we did not have to purchase an additional part. Second, from a schedule perspective, after completing lab #4 we had the Z8 board all wired up and tested prior to starting the group project. Finally, after completing lab #4, we had a ZILOG project all setup with a fully functional suite of software functions to drive the LCD display. The design decision to leave off the optional sensor was due to several factors: namely time-constraints and space-constraints. We were running short on time near the end of the project, and it would ve taken some time to integrate the speaker without stepping on the other portions of the code. Space was already constrained because it took quite a bit of RAM space to hold all the SD-card code, and our existing speaker libraries from Lab 2 were fairly large to handle playing ringtone notes. Rather than wrangle the code for the optional speaker into place, we decided to leave it off. Also, from a retrospective point of view we should have tested the transceivers prior to the live demonstration so that we could have identified the equipment failure and purchased replacement parts. Since the transceivers simply acted as a bit-for-bit transmission device all our unit testing was done directly with the GPS receiver instead of transmitting through the transceivers that were a simple but critical part of the classroom demonstration. It s ironic that the parts we thought were guaranteed to work were the only parts that failed. During the development of the project we traded off the various hardware devices that we both needed to write our portions of the software. Because we each needed different parts for our respective presentations, we could not keep all the hardware together until late in the semester. We traded zip files across the Internet and drove from one house to another delivering the GPS receiver and transceivers. We also ed a sample SD Card between or homes. We probably should have kept all the equipment at one location and just worked there to minimize hardware transportation risk and ensure more end-to-end testing. A full end-to-end system test at the one location would have been ideal. The development of the unit at one location would have also identified a formatting issue between the GARMIN GPS output and the Microsoft MapPoint application. The two formats, Decimal, Minutes, Seconds (DMS) and Decimal Degrees are not compatible and we didn't realize that we had to convert between the two formats until close to the start of the demonstration. Again, having the system built at one location would have resulted in the earlier identification of these issues. If we knew the entirety of the work involved when we started, we would ve finished the labs much quicker to allow us to have maximum time to focus on the final project. While we had much of the components already finished, getting the hardware together in one place and making all the components work together was a critical piece we should ve started earlier. Page 11 of 19

12 Attachments C# and Windows MapPoint Software using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Text; using System.Windows.Forms; using System.IO; using System.Collections; using System.Threading; namespace GPSTracker public partial class Form1 : Form private MapPoint.Map omap; private MapPoint.FindResults oresults; private MapPoint.Location oloc; private String[] files; public struct structgps public Double Lat; public String LatDir; public Double Long; public String LonDir; public Int32 Hour; public Int32 Min; public Int32 Sec; ; public Form1() InitializeComponent(); private void Form1_Load(object sender, EventArgs e) Page 12 of 19

13 Attachments C# and Windows MapPoint Software private void axmappointcontrol1_enter(object sender, EventArgs e) private void opentoolstripmenuitem_click(object sender, EventArgs e) String line; Double Latitude; Double Longitude; Double Altitude=1; Decimal RecordCounter = 0; Decimal SkipRecorderChecker; String snmeatype; Double ftemp; int ilatitudedegrees; int ilatitudeminutes; int ilatitudeseconds; int itemp; // setup for dialog to choose files for loading // Files from SD RAM are comma delimited files OpenFileDialog openfiledialog1 = new OpenFileDialog(); openfiledialog1.multiselect = true; openfiledialog1.initialdirectory = "c:"; openfiledialog1.title = "Load CSV files for display"; openfiledialog1.filename = "data.csv"; openfiledialog1.filter = "CSV Documents (*.csv) *.csv"; // done w/ setup, get all chosen filenames openfiledialog1.showdialog(); files = openfiledialog1.filenames; Page 13 of 19

14 Attachments C# and Windows MapPoint Software //Create a new map of north america axmappointcontrol1.newmap(mappoint.geomapregion.geomapnorthamerica); // setup an alias control to make code more readable omap = axmappointcontrol1.activemap; // turn off the VERY annoying points of interest symbols for (Int32 i = 1; i < omap.placecategories.count + 1; i++) object index = i; MapPoint.PlaceCategory placecategory = omap.placecategories.get_item(ref index) as MapPoint.PlaceCategory; placecategory.visible = false; //TODO: This can be removed ******************************* //Hack to zoom MapPoint into general location where Aaron and I //usually do our tests. Once we have a DC set of gps points the map //should move quickly to dc (i.e. map doesn't come up pointed in middle of country at startup oresults = omap.findaddressresults("1234 Main Street", "Anytown", string.empty, "CA", "90210", null); if (oresults!= null & oresults.count > 0) object index = 1; oloc = oresults.get_item(ref index) as MapPoint.Location; // put it on the screen oloc.goto(); //omap.zoomout(); Page 14 of 19

15 Attachments C# and Windows MapPoint Software using (StreamReader sr = new StreamReader(files[0])) //Read a line of flatfile. //If no records then skip processing code while ((line = sr.readline())!= null) //Let's only plot every 5 records, //otherwise map get's too crowded RecordCounter = RecordCounter + 1; SkipRecorderChecker = Decimal.Remainder(RecordCounter, 5); if (SkipRecorderChecker == 0) //Parse the string String[] parsedarray = new String[32]; parsedarray = line.split(new Char[] ',' ); snmeatype = parsedarray[0]; if (snmeatype == "$GPRMC") Latitude = Double.Parse(parsedArray[3]); Longitude = Double.Parse(parsedArray[5]); Longitude = Longitude * -1; MapPoint.Location location = axmappointcontrol1.activemap.getlocation(latitude, Longitude, Altitude); //MapPoint.Location location MapPoint.Pushpin pushpin = axmappointcontrol1.activemap.addpushpin(location, "Center"); pushpin.symbol = 82;// 208; pushpin.select(); pushpin.highlight = true; Page 15 of 19

16 Attachments The below schedule was followed. Project was completed and presented on time. Page 16 of 19

17 Attachments Figure 2 Class Demonstration Setup Figure 3 Sample GPS Raw Data Page 17 of 19

18 Attachments Figure 4: GPS Receiver and Tranceivers In Proper Configuration Page 18 of 19

19 GPS 35 Specifications GPS Receiver PhaseTrac 12 tracks and uses up to 12 satellites simultaneously DGPS Software N/A Cable Connections Terminated DB-9 serial connector and cigarette lighter plug, 12 ft. cable. Mounting Optional suction cup and magnetic mount options available. See accessories. Position Accuracy* 15 meters RMS DGPS Position Accuracy N/A Velocity Accuracy* 0.2 m/s RMS steady state Max Speed 999 kts Max Altitude 99,999 meters Time to First Fix 15 sec (warm) 45 sec (cold) 1.5 min (AutoLocate ) Update Rate 1/sec 5 min (sky search) Receiver Sensitivity -160dBW minimum Input Voltage vdc Power Cons. 1 watt Backup Power internal 3v lithium battery Serial Comm. Software baud rates: 1200 to 9600 baud Output Messages NMEA 0183 v2.0 messages plus GARMIN proprietary Dimensions 2.23 x 3.80 x 1.04 " Weight 4.4 oz, not incl. cable Operating Temp -30 C to +85 C References Page 19 of 19