gps data logger

http://courses.cit.cornell.edu/ee476/FinalProjects/s2009/jsm66_mpk28/jsm66_mpk28/index.html
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 information at timed intervals. The second mode only records
position information when triggered manually over a wireless interface by an external device.
The data is stored to an SD card, which can be removed for viewing the data on 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 the case of using the external trigger with a camera, to correlate pictures
with location information.

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 from a Navman Jupiter 12 GPS
receiver module. The module does all of the positional calculation, and outputs this
information to the uart of the MCU using the NMEA 0183 standard. We parse this data,
and display the 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 its just logging mode, then
we write the data 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 every time we get a
trigger from the wireless receiver. The wireless receiver gets a spike in its output when we
press the trigger button on our wireless RF transmitter. This trigger button also is
connected to a camera, which 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 locations, using
preexisting software for Google Earth. 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 GPS signals and operation. The
details of this specification will not be directly used in this project because GPS
acquisition and tracking will be handled by the module chip.

The serial interface between the GPS module and the microcontroller is
determined by NMEA (National Marina Electronics Association) standard 0183.

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 use the ATmega644 on, and also
attached the MAX233 and RS232 serial port connector to use for debugging purposes. We
also used the LED on the prototype board as a helpful tool to blink every time we wrote
GPS data to 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 regulator. We did this
because the output current on the LM340LAZ-5 was only 100mA, and we needed more
than that for the GPS receiver. The LM340-T5 fixed this issue because it has an output
current of 1A, which was 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 simulator through the serial port, and receiving data
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 transmit pin to send debugging
information 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 off of a 9V battery. This battery supply
also powers the GPS receiver, SD card, LCD, and RCR-433 receiver through their
interfacing with the prototype board. Through testing, weve found that the battery life on
a 9V battery 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 visible satellites. The receiver can be powered
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 receiver was part of the TU35-D420
series, 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 modules EEPROM for receiver settings
rather 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 ATmega644.

The receiver has an OSX/MCX connector for an antenna. The receiver supports both
passive and active antennas, with an optional preamplifier for active antennas. The
datasheet specified that a current limiting circuit was required if the preamplifier was used
to prevent more than 100mA from passing through the preamplifier in the event of a short
circuit. This 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, and has a gain of approximately 30
dBi. We 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 Molex. The majority of the hardware
design 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 card runs at 3.3V, so we
powered it using a 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 from 5V to 3.3V. The
three SD card inputs 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 card inputs,
along with a clamping diode from 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 pull-up
resistor between the data out pin of the SD card and the 3.3V Vcc as recommended by the
SD specification.

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 capacitor between Vcc and ground to
eliminate some of the noise from the power supply from interfering with our signal
received. We connected another 10 inch wire antenna to the antenna input of the receiver
to receive our 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 wave, and appeared to require a bit of work
to detect our trigger pulses, which just widened the period of the square wave. So, instead
we chose to use the analog output from the receiver. This was a noisy signal centered
around 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.01F capacitor in series between the
analog 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 had small noise variations and was
centered at 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 spike was detected by
connecting the output to the positive input of the voltage comparator on the MCU (Pin
B2). A reference voltage, determined by a 10k trimpot, was connected to the negative
input of the voltage comparator (Pin B3). We were able to adjust the trimpot voltage level
to eliminate noise from triggering our device, but still allow our transmitter circuit to
break the threshold and trigger it.

Camera

The camera used was a Canon PowerShot SD1000, loaded with the CHDK firmware addon. CHDK adds many features not typically available on this camera. The relevant feature
for 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 applied between pins 1 and 4 of the

USB connector. We were able to implement this by connecting it to our push button
trigger described previously.

Image courtesy of CHDK wiki

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 proposal. Originally, we had discussed with
our 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, but we ended up having
enough time to be 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 been. Several times we had to attach the
antenna 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 time could have been
shortened by using a backup battery to maintain almanac and time information. It is
possible that the performance issues were related to the quality of our antenna, which was
of questionable origin. The antenna current limiting circuit may also have negative effects
on the antenna performance. To improve this design, a higher end GPS receiver and
antenna would be needed, which 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 433 MHz band, since we only
look at 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 RF broadcasting as well.
However, when we took our device outside, we encountered a lot more false triggers from
noise. We were able to practically eliminate these false triggers by increasing the
reference voltage threshold 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 out to 10 feet
with this new threshold level, 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 activated the wireless trigger. However, we
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 all relevant standards for its
operation. Our RF transmitter is also a commercially available product. This implies that
the transmitter complies with FCC rules for general usage. Since our application is
atypical for this transmitter, its usage is governed as a periodic intentional radiator by
Section 15.231 of the FCC Part-15 Rules for unlicensed RF devices. The circuitry of the
transmitter ensures that the transmission length is within the rules of this section. Lastly,
we believe that our SD card interface conforms to the specification from the SD
Association.