GPS Data Logger with Wireless Trigger

Navigation
Home High Level Design Hardware Design Software Design Results Conclusion Considerations Appendices References Jeff Melville (jsm66) Matt Kuzdeba (mpk28)

Home
Introduction
The goal of this project was to create a portable GPS logger that could be wireless triggered by an external device, such as a camera.

Our device that we have designed operates in two modes. The first works as a basic GPS logger, which records GPS position informatio records position information when triggered manually over a wireless interface by an external device. The data is stored to an SD card, w a computer. This can then be used with programs like Google Earth to display a map of the route traveled over the logging period, or in t camera, to correlate pictures with location information.

Inspiration

With GPS technologies becoming much more affordable and available these days, there are many new applications to which it can be ap interested us was logging location data, especially with respect to photography. Geotagging is the process of adding location information sites such as Flickr can use this information to display such photographs on an interactive map. Having taken thousands of photographs

Jeffs travels around Australia and New Zealand, this type of technology would be very helpful in organizing all of this information. Some but most do not. In those cases, a log of position information over time could be correlated against the time stamps on the photographs t

High Level Design

The high level structure of our design uses multiple sources to interface with the ATmega644 MCU. We receive our GPS positional data module. The module does all of the positional calculation, and outputs this information to the uart of the MCU using the NMEA 0183 stan positional latitude and longitude coordinates to the LCD. We read from the SD card at start up to see which mode were operating in. If it

from the GPS module to the SD card at timed intervals. If its trigger mode, then we write the data from the GPS module to the SD card e receiver. The wireless receiver gets a spike in its output when we press the trigger button on our wireless RF transmitter. This trigger but

takes a picture when we press it. The data stored on the SD card can then be used to generate routes, or correlate pictures with location The high level block diagram of our design follows:

Standards Relevant to Project

Since the device utilizes the Global Positioning System (GPS), its operation will be governed by IS-GPS-200D, the specification

of this specification will not be directly used in this project because GPS acquisition and tracking will be handled by the modul

The serial interface between the GPS module and the microcontroller is determined by NMEA (National Marina Electronics Ass The SD memory card is accessed over an SPI interface as dictated by the standards of the SD Association.

Hardware Design
The hardware for our design is comprised of the following:

ATmega644 Prototype Board Navman Jupiter 12 GPS Receiver SD Card and Socket LCD Radiotronix RCT-433 Transmitter

 Radiotronix RCR-433 Receiver Camera

ATmega644 Prototype Board

The ATmega644 is responsible for coordinating data flow between all of the other hardware components. We built the prototype board to the MAX233 and RS232 serial port connector to use for debugging purposes. We also used the LED on the prototype board as a helpful the SD card. The one thing that we changed with the board was to replace the LM340LAZ-5 voltage regulator with the LM340-T5 voltage current on the LM340LAZ-5 was only 100mA, and we needed more than that for the GPS receiver. The LM340-T5 fixed this issue becau sufficient to run our GPS receiver with.

We used the transmit and receive jumpers on the prototype board to switch back and forth between receiving data from the GPS simulat from our actual GPS receiver with the output of the receiver connected directly to the receive pin. Doing this allowed us to still use the tra through the serial port to HyperTerminal.

To make our device portable, we obtained a battery to DC supply plug, and a 9V battery clip so that we could power our prototype board powers the GPS receiver, SD card, LCD, and RCR-433 receiver through their interfacing with the prototype board. Through testing, wev with our circuit is about 3 hours of operation.

Picture courtesy of ECE 476 website Navman Jupiter 12 GPS Receiver

The Navman Jupiter 12 is a 12-channel single board GPS receiver. This means that its capable of simultaneously tracking up to 12 visib from 3.3V to 5V, but we chose to power it with a 5V supply to ease interfacing with the ATmega644 and prototype board. Our particular r which includes dead reckoning functionality. None of the dead reckoning functionality of this receiver was used.

The master reset line is tied high through a 57k resistor as specified in the data sheet. The GPIO3 is similarly tied high to enable the m than using the factory defaults. We connected the SDO1 output pin from the receiver to Pin D0, which is the uart receive pin, on the ATm

The receiver has an OSX/MCX connector for an antenna. The receiver supports both passive and active antennas, with an optional prea specified that a current limiting circuit was required if the preamplifier was used to prevent more than 100mA from passing through the pr was accomplished using two parallel 75 resistors on the power input to the preamplifier.

The antenna that we chose to use was an active GPS antenna at the L1 frequency of 1575.42 MHz. It can be powered from 3.0 to 5.0 V chose this antenna due to its high gain, low price, and availability.

SD Card and Socket

We chose to interface our SD card in SPI mode with the MCU. To implement our SD card hardware, we sampled an SD card socket from involved for it was to implement an effective level shifter between the ATmega644s Port B pins that we used and the SD card. The SD c LM1117T-3.3 voltage regulator. We then needed to level shift all of the data from the output pins of the MCU to the inputs of the SD card that needed this were the chip select, data in, and clock. We accomplished this by using a 1k series resistor between the MCU and SD the SD card inputs to the 3.3V Vcc. The data out pin of the SD card was connected to the MISO input to the MCU. We also put a 57k p SD card and the 3.3V Vcc as recommended by the SD specification.

LCD

We used a standard 16 character, 2 line LCD to display the GPS latitude and longitude coordinates at all times while the GPS logger is o and interface the LCD through Port C of the ATmega644. Radiotronix RCT-433 Transmitter

To implement the wireless trigger capability of our GPS logger, we used the Radiotronix RCT-433 Transmitter and RCR-433 Receiver. W simplicity, and availability in the lab. They operate at a center frequency of 433.92 MHz.

We designed a separate hardware circuit for the transmitter to function as the trigger for our device, and interface with the camera. W e w and avoid needing another MCU on the transmitter side. The transmitter can operate between 1.5V and 12V. For portability, we chose to 9V battery clip in the circuit for our transmitter. We connected the 9V battery to an LM340LAZ-5 voltage regulator so that we could run th necessary for the RCT-433 as it could run off of 9V as well, but since the trigger also interfaces with our camera, which shouldnt have m chosen.

We connected a 10 inch wire antenna to the antenna output of the RCT-433, which worked well for our transmission needs. We connect inputs to the transmitter so that we could transmit a short pulse to the receiver when we wanted to trigger our GPS logger. Since the tran pulses would be relatively easy to detect be the receiver. We also connected a 10k resistor between the data input to the transmitter an push button is pressed. Lastly, we connected the data input pin of the transmitter to the USB cable which we used to interface with our c trigger our GPS logger it would also take a picture with the camera.

Radiotronix RCR-433 Receiver

The RCR-433 receiver operates at 5V, so we powered it off of our 5V Vcc used for the prototype board. We also inserted a 0.01F capa some of the noise from the power supply from interfering with our signal received. We connected another 10 inch wire antenna to the ant trigger pulses from the transmitter.

Initially, we looked at using the digital data output from the receiver to interface with the MCU, but the signal was a very noisy square wa detect our trigger pulses, which just widened the period of the square wave. So, instead we chose to use the analog output from the rece 2.5V, which spiked when we pressed the trigger button on the transmitter. To make this more detectable by the MCU, we placed a 0.01 output of the receiver and Pin B2 of the ATmega644. The eliminated the DC bias from the signal, so that the signal going into the MCU h 0V. When the transmitter button was pressed, this signal would spike to about 4V for a brief period of time before returning to 0V. This sp the positive input of the voltage comparator on the MCU (Pin B2). A reference voltage, determined by a 10k trimpot, was connected to th (Pin B3). We were able to adjust the trimpot voltage level to eliminate noise from triggering our device, but still allow our transmitter circu

Camera

The camera used was a Canon PowerShot SD1000, loaded with the CHDK firmware add-on. CHDK adds many features not typically av this project was the ability to create a remote shutter release. When enabled, the camera will take a picture if between 3 and 5V are appl connector. We were able to implement this by connecting it to our push button trigger described previously.

Image courtesy of CHDK wiki

Software Design
The software for our design is comprised of the following:

NMEA Parsing LCD Display SD Interface Configuration Options Trigger and Log Writing Google Earth Interface

NMEA Parsing

The GPS receiver can output data in the standard NMEA 0183 ASCII format or a manufacturer proprietary binary format. The binary form easier to parse the needed information for this application, and is more compatible with desktop applications. For this application, we rec GSA, and RMC. Examples of each of these follow: $GPGGA,204542,4226.3744,N,07629.1623,W,1,03,4.36,229.5,M,-33.9,M,,*45 $GPGSA,A,2,14,30,12,,,,,,,,,,1.95,1.09,1.62*06 $GPRMC,204542,A,4226.3744,N,07629.1623,W,0.000,89.0,240409,13.1,W*70 For more information on the formatting of NMEA sentences, please see the References page

Each message begins with a $ sign, and ends with a \r\n, with a maximum length of 80 characters which eases parsing. Since each of th GPS module, we implemented an interrupt-driven uart receiver that places each received byte into a circular buffer. To maintain concurre

by a task that executes every 500 milliseconds. This task stores the most recent copy of the GGA, GSA, and RMC messages, as well as as the status of the GPS fix. The status of the GPS fix is determined by the fix quality parameter of the GGA sentence.

For our initial testing of the parsing code, we used a GPS simulator called gpsfeed+, which outputs varying GPS location data on the ser through our uart to the ATmega644 in place of the actual GPS receiver until our parsing testing was complete.

LCD Display

The LCD is updated every 500 milliseconds with the current position retrieved from the NMEA parser. This is displayed as LAT: <positio <position> on the second line of the LCD. If the GPS receiver does not currently have a GPS fix, then NO GPS FIX is displayed on the SD Interface

For ease of use, we wanted the logger to support writing and reading SD cards using the FAT file system. This is the standard file system found a library called FatFs designed for this purpose on a variety of microcontrollers. FatFs is free software with no restrictions on usag layer so that it can be easily adapted to different hardware configurations.

For this application, the disk interface is the SD card controlled over an SPI interface. SD cards typically operate using SPI mode 0. This with CPOL = 0, and CPHA = 0. Although the SD card supports a SPI interface, this is not the default interface when the card is powered rate to a slow speed of 125 kHz, and apply 80 dummy clock cycles by transmitting 0xFF 10 times. After this, the microcontroller sends C state. Once in SPI mode, the card is initialized using ACMD41 repeatedly until the idle state bit in the response is cleared. At this point, t which can be done at a higher clock rate. We used a clock rate of 1 MHz. This rate could have been increased, but performance was no data being read or written in a given period of time.

FatFs included a sample implementation of an SD card interface for AVR microcontrollers. This sample implementation did not initially w configuration, power management, initialization, and disk timer were all modified to work with our hardware. The disk timer also required millisecond interrupt-driven scheduler. We also implemented the real time clock from scratch. If a GPS fix is available, the current date a Otherwise, an approximation is made based on the current up time of the logger. This clock is responsible for the time stamps on files wr

File access is provided by FatFs functions that are analogous to standard C file functions (e.g. f_open vs. fopen). Prior to opening any fil reference the drive. Both this and file operations are simplified by the fact that the hardware interface code only supports one disk.

Configuration Options

During power-up, the file gps_set.txt is read from the SD card to determine configuration options. If the word trigger appears at the beg enabled. If the word interval appears at the beginning of a line, interval logging will be enabled. The interval is defined in seconds, and interval in the line. Both modes can be enabled simultaneously. If the file can not be read, both modes are enabled by default, with a 30

Trigger and Log Writing

Upon power-up, the logger will create a file of the form gps_xxx.txt, where xxx is the lowest number from 000 to 999 that does not curren the writeFlag variable. The writeFlag is asserted by the trigger process, and/or at the specified time interval, depending on the configurat GGA, GSA, and RMC sentences are written to the SD card. After writing the data, the file system is synchronized to prevent data loss if LED is illuminated while data is being written both as an indicator and as a warning not to turn off the logger.

The trigger is implemented using the analog compare interrupt on the ATmega644. The interrupt is set to fire on the rising edge of the an received RF signal crossing the voltage threshold. The interrupt service routine will assert writeFlag if trigger mode is enabled, and the in This 1 second delay between allowable interrupts was put into the code for trigger debouncing purposes. It is unlikely to receive more th application because of delay in the camera.

We chose to use a single on pulse as our trigger to greatly simplify our hardware needed to implement our wireless RF trigger. This resu we used this instead of any specific data sequence for triggering. However, this was an acceptable trade off for our design since we wan that it could interface easily with the camera.

Google Earth Interface

Correlating picture and position data was performed using free software known as GPicSync. This software takes an NMEA log file from determines the location of each picture by using the GPS location that is closest in time to the given picture. Our triggering mode allows GPicSync also generates a KMZ file, which includes the path taken with photothumbnails overlaid in the appropriate places. KMZ files ca also supports exporting this information in a Google Maps format that can be embedded in a website.

We also used the website http://www.gpsvisualizer.com/. This website allows the user to upload a GPS file, and then choose an output fo to display the route of the coordinates taken on it. This is a simpler method than GPicSync if the user is solely interested in using the log routes that were travelled.

Results

Our GPS logger worked satisfactorily during our testing. We were able to record the GPS data to an SD card, and use that data to geot Cornells campus.

The following is the map from Google Maps obtained by uploading our GPS file onto the website gpsvisualizer:

The following is the interactive map with photothumbnails of our pictures overlaid, obtained using GPicSync:
View Larger Map

The accuracy seen in our GPS location information was typical of a non-WAAS GPS receiver, which is on the order of tens of meters. The integration of the various components in our design worked very well, without any concurrency or hesitation issues.

Human factors and usability for our design are not a large consideration because most of its operation is autonomous, and then the data and data processing tools could be completed in various applications that could have interfaces tailored to their purpose or users. This in

Conclusion

Overall, we were very happy with the results of our project. It met all of our specifications that we had generated in our original project pr T.A. about how we may need to get rid of the wireless trigger part due to time limitations and the complexity of other parts of the design, able to get this implemented as well.

We were slightly disappointed in the performance of the GPS receiver itself. Signal acquisition was more difficult than it should have bee to something metal in order to get the initial GPS fix. Even in this situation, it often took more than 2 minutes to obtain a fix, although this backup battery to maintain almanac and time information. It is possible that the performance issues were related to the quality of our ant antenna current limiting circuit may also have negative effects on the antenna performance. To improve this design, a higher end GPS re were out of the budget constraints for this project.

Our implementation of the wireless trigger (using the RCR-433 receiver) was very sensitive to false positives from noise, especially in the amplitude of the signal rather than any specific data sequence. In the lab, this wasnt a problem except for when other groups were using took our device outside, we encountered a lot more false triggers from noise. We were able to practically eliminate these false triggers by from the trimpot to be greater than the noise level, so this sensitivity was acceptable. Also, the range of the trigger worked well at least o

which was satisfactory.

We would have preferred to have the camera initiate the wireless trigger on its own, rather that have an external shutter release that also were unable to find an elegant way to determine when the shutter is pressed without hardware modifications to the camera.

Considerations
Applicable Standards

The GPS receiver that we used was a commercially available product for OEM applications, so it is reasonable to assume that it meets a transmitter is also a commercially available product. This implies that the transmitter complies with FCC rules for general usage. Since o usage is governed as a periodic intentional radiator by Section 15.231 of the FCC Part-15 Rules for unlicensed RF devices. The circuitry transmission length is within the rules of this section. Lastly, we believe that our SD card interface conforms to the specification from the

Intellectual Property and Legal Considerations

The prototype board that we used for the ATmega644 was designed and laid out by ECE 476 Professor Bruce Land. The initial test code Bruce Land. The code used for uart and LCD interfaces was provided as part of earlier labs in ECE 476.

The FatFs file system library was used in compliance with its license. The Secure Digital memory cards are covered by multiple patents such as DRM and encryption, require licensing royalty fees. However, the card can be interfaced as an MMC card over an SPI interface interface is adequate for the needs of this device. All other code and circuitry was original. We do not believe that there are patent oppor already exist.

Ethical Considerations

A large potential impact of this device involves ethical considerations. The increased information availability in all GPS systems brings m information is used improperly. These risks often invade on personal privacy. For example, such a device could be hidden in a car unkno However, no aspect of our design makes it particularly targeted for unethical use by end users.

Referring to the IEEE Code of Ethics, our project has no safety or health consequences to its users. The only environmental issue that n empty batteries. There were no conflicts of interest regarding the completion of this project. No individual involved had any financial or pr realistic in stating results based on our available data and observations. We researched the technologies that we used in depth ahead of and potential consequences of them. While some of the technology we worked with was new to us, we did not exceed our experience le design. We have properly credited the contributions of others, particularly intellectual property. We are seeking constructive criticism on t comments during our final demo. We frequently helped colleagues that encountered issues similar to ones that we had seen previously, receiver module.

Appendices
Acknowledgements

We would like to especially thank Bruce Land for all of his help and miscellaneous tips along the way. We would also like to thank our T. semester. Finally, we would like to thank eBay for allowing us to complete this project within budget. We enjoyed the opportunity to comp interest to us for a long time.

Appendix A: Source Code

Full source code for this project is available for download here.

Appendix B: Schematics Main circuit:

Wireless Trigger Circuit:

Note: USB pin 2 is actually pin 4.

Schematics can also be downloaded in PDF and ExpressSCH format. GPS Logger Schematic: PDF SCH Wireless Trigger Schematic: PDF SCH

Appendix C: Budget and Parts List

Our budget for this project was $75, and we were able to meet it with room to spare, with total costs of $65.15. We were able to keep ou two most expensive parts, the GPS module and antenna, for $18.20 combined off of eBay. Normally, these two parts together will run ov lower by sampling a couple of the other parts, such as the SD card socket and MAX233.

References
Datasheets Atmel ATMega 644 Microcontroller Navman Jupiter 12 GPS Receiver (TU35-D420-021) Secure Digital Card Product Manual Radiotronix RCR-433 RF Receiver Radiotronix RCT-433 RF Transmitter Maxim MAX233 RS-232 Driver/Receiver LM340LAZ-5: 5V Voltage Regulator (100mA) LM340-T5: 5V Voltage Regulator (1A) LM1117T-3.3-ND: 3.3V Voltage Regulator (800mA) Other Documents How to use SDC/MMC Zodiac GPS Receiver Family Designers Guide NMEA Data Circuit for a similar GPS receiver

Utilized Libraries/Software FatFs - Microcontroller compatible R/W FAT12/16/32 library CHDK - Firmware add-on for Canon digital cameras gpsfeed+ - NMEA simulator used for indoors testing ECE 476 Website - UART and LCD libraries, previous labs GPSVisualizer - Quickly view GPS logs on a map GPicSync - Correlate photographs to GPS log and export to Google Earth / Maps Google Earth

Vendors Digikey Jameco Maxim Molex

http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2009/jsm66_mpk28/jsm66_mpk28/index.html

http://circuitplanet.blogspot.com/2009/11/design-with-microcontrollersfinal-year.html