#t2e

The Hardware

I’m afraid I didn’t take any pictures of the disassembly of the Chatpad, but it’s really a few screws here and there keeping it together. Once you get into the meat of the thing, you’ve got a very compact, no BS device that looks like this:

Physical dimensions are about 101mm x 43mm. If you desolder the audio port and connector, the madimum height is about 8mm adnd, with the connector, can get down to about 14mm

On board is a PIC chip and a port to the controller connector which, for my own sake, I just chopped off and soldered some headers but there’s a neat hack where, if you have a PIC programmer laying around, you can reflash the firmware as described here: http://forum.arduino.cc/index.php?topic=58463.0 and using these pads.

I haven’t had the pleasure of PIC-ing (but someday!) so I just tried to interpret the protocol preloaded on the board.

The cable looks like so.

We’re interested in the top four wires - power, UART RX, UART TX, GND (RX and TX are from the perspective of the chatpad). The bottom three wires are just for audio. The UART operates at 19.2 kbps and the whole packages operates at 3.3v.

We will go off of only the following first rule: in order to turn the thing on, we need to send two messages: wakeup and initialize. We're going to do things the hard way because that’s how we learn. Instead of using a single 3.3v Arduino both with UART and serial monitoring, we’re going to use the MSP430G2211 (no UART, no monitoring at 19.2 kbps) and a Saleae logic analyzer. It will help us grow as programmers and fast.

Making a UART Library (in progress)

Before we take a look at how to use this thing, let's think about what we can do with it.

An accelerometer, as its name so obviously implies, is all about acceleration along each of the axes. The accelerometer we're using is a 3-axis which means it can measure acceleration in X,Y, and Z directions.

A quick recall of some mechanics and we realize we can get, not only the acceleration, but the velocity and position from this data by just finding the integral over time! Furthermore, since we have the direction of acceleration, we can find every aspect of motion of possible interest about the device!

We can even find the tilt of the thing, but we'll get into that later.

GETTIN' OUR ELECTRONICS ON

The device we're using today is the MMA7455 3-axis accelerometer module from Parallax. Here's where the axes are and the pinouts:

It works in a really interesting way with swinging capacitances and MEMS technology (that's MicroElectroMechanical Systems for those who don't know which mean the smallest feature size is on the order of microns!) but we'll chalk that up to black magic since, for now, we're only interested in interfacing and knowledge of how it works isn't really necessary in the same way that satellite positions were for GPS.

We'll go ahead and leave n/c and INT2 disconnected, but the rest we'll use. The INT1 pin is important to this specific chip while the rest of the pins are all for either power or communication standards which we'll cover in a bit.

Getting a Handle on the Chip

INT1 & INT2 are configurable interrupt pins which means they can serve a few different purposes if we like. The device has a few different modes:

standby -power is low and measurements aren't taken

measurement -the device takes measurements on all three axes and stores them until an axis' acceleration is read and then it re-reads

level detection -if the acceleration goes over a certain level, an interrupt pin is fired high

pulse detection -it senses a "tap" or even a double tap

The INT pins can be configured to go high whenever a tap is sensed, a double tap is sensed, a level is crossed or a measurement is finished!

We want to configure it so that it'll tell us when it's done reading the axes so we'll just configure INT1 to be fired whenever the DRDY (Data ReaDY) bit is switched. Also we have to tell it we want it in measurement mode. These are all accessed through the hex register $16 which has these bits:

BE EXCITED! We're talking on a bit level--exactly what the system understands. Whereas most of our projects are in some extracted language, we'll be directly accessing bits and registers using a microcontroller!

Okay, that note of glee aside, we have a lot of options with this chip. Data comes in 3 flavors: +/-8g, +/-4g, or +/-2g which means we can measure anywhere from 2 times the force of gravity in the + or - directions to 8 times the force of gravity in the + or - direction. Also, we can get all of our data in 8-bit precision (divide up the g range by 256 discrete parts of the full range) or 10-bits of precision in the case of 8g (1024 discrete parts).

As an example, let's say we chose 2g's at 8-bit precision. This means we have +/-2g's (4g's total) divide by 256 or 0.0156g's in each possible measurement. That means if we put it through an actual acceleration of 0.043g's, we would actually round to the nearest multiple of 0.0156 which is 0.469g's.

What will our Mode Control Register look like if want to do +/-2g's in measurement mode using 3-wire SPI with the INT1 pin for when our data's ready?

I hope you got 01100101!

I think we all get it so let's move on to SPI mode.

I SPY a SPI

Sorry, I dig hokey titles.

SPI (Serial Peripheral Interface) is a form of serial communication that you can use to talk to a bunch of devices. Usually, in this scenario, we call the device that's controlling the "master" (the microcontroller) and the devices it is controlling the "slaves" (other devices). Here's the way it works:

Our master is a guy that's shouting commands. He's a rambler so he's always talking, maybe not specifically to any given device. Then when he says "SLAVE #1! FIND ME MY X-AXIS ACCELERATION, Y-AXIS ACCELERATION, AND Z-AXIS ACCELERATION!" Slave #1 is obligated to respond "0.6g's sir!" The other Slaves didn't hear their name so they know they don't really have to listen unless the master says .

That's how SPI works! It's sending commands that all of the devices can hear but they don't listen unless they are addressed. The layout is like what you see below.

Whenever the microcontroller drives the CS pin low for the device it wants to talk to, that device listens. Otherwise, it will keep the devices it doesn't want to talk to high. Each bit is cycled in using the CLK pin. So the basic scheme is set a bit to the output, clock high, the device stores the bit, and then the clock goes low and the device interprets the bit. Similarly, when the uC wants to read information from a device, it'll clock high, read the bit, then clock low so the device knows to send the next bit. The very cool part of this is that you only need n+4 pins to control n devices since the 4 pins for control are shared by each device!

An even more cool thing is that a lot of devices can work in 3-wire mode. Here, the pins are CS, CLK, and I/O where I/O is one pin! The way this works is that the master yells a command to the device that it's either gonna read to or write from one of the registers in the device and sends an address for the register it wants to read or write. If it sent the read command, the uC then listens on the I/O pin for a response. If it sent the write command, the uC then writes the information that it wants to set to the register.

Here's a picture from the datasheet to show ya what I mean:

Each of the "A[n]" bits is an address bit and the "D[n]" bits are the data bits that are either read or written.

Remember that CS has to be low this entire time!

Also, so that you don't bang your head against the wall, notice the first bit in the address byte says "R/W." For this bit, sending 0 first tells the accelerometer we're gonna read information from the addressed register and sending a 1 first tells it we're gonna send information we want set to the register. Also youll notice that, with the R/W bit included, the address byte is only 7 bits long! Actually, that little gray square between A[0] and D[7] is a parity bit and it can be anything you want! It just makes sure that the byte is 8 bits long so go hogwild: 0, 1, set the gray bit to anything your heart desires.

PUTTIN THE CODE TO WORK

Okay, so there is a SPI library in Arduino but how much ownership can you put on a product that you didn't build yourself?! I like the idea of a ground up approach so let's go ahead and code right quick.

Before anything, let's figure out how we're gonna set this up. We'll want to use the serial monitor so pins 0 and 1 are a no-go. Let's use pins 2-5 instead!

#define CLK 2 #define DATA 3 #define CS 4 #define RDY 5

Now there are a few important registers. The ones we're interested in are XOUT8(0x06), YOUT8(0X07), ZOUT8(0X08), the status register (0x09), and the mode register (0x16).

#define  XOUT8  0x06 #define  YOUT8  0x07 #define  ZOUT8  0x08 #define  SREG  0x09 #define  MODE  0x16

We'll want to store the values of X,Y, and Z:

signed char Xval=0x00; signed char Yval=0x00; signed char Zval=0x00;

And we'll want to set up our inputs and outputs.

void setup() {   pinMode(CLK,OUTPUT);   pinMode(DATA,OUTPUT);   pinMode(CS,OUTPUT);   pinMode(RDY,INPUT);      digitalWrite(CLK,LOW);   digitalWrite(DATA,LOW);   digitalWrite(CS,LOW);   Serial.begin(9600);   writeInstruction(MODE,0b00100101);  }

That last line initializes the accelerometer the way we said earlier.

Now, we know we're gonna have to read and write a whole bunch so we oughtta make some functions that do just that!

Writing

For a write, we know we need two pieces of information: which register we want to write to and what we want to write to it. It doesn't have to return anything since it's just a write command so let's do this!

void writeInstruction(char address, char msg){}

We know address and msg will be bytes so we can use char here.

Now we're gonna send the address first. As the picture showed, the address is only 6 bits long and we need to format it the way the accelerometer likes to see, i.e. with a 1 at the beginning showing we're writing and some extra bit at the end.

address=address<<1; address|=0b10000000;

The << operator is called the shift operator because it shifts a byte over by whatever number is to the right of the operator. The |= operation is kind of like +=. It will OR each bit in address with the binary number 10000000 and then store it into address. Since anything ORed with 1 = 1 and anything ORed with 0 is whatever was originally at that bit position, this operation means we're only making the MSB 1 if it wasn't already.

Now, we have to shift out each of the bits from left to right and send them to the microcontroller. We know there'll be 8 bits for every full address byte so let's use a for loop.

for(int i=0;i<8;i++)   {       if(address&0b10000000)       digitalWrite(DATA,HIGH);     else         digitalWrite(DATA,LOW);     address=address<<1;        digitalWrite(CLK,HIGH);     digitalWrite(CLK,LOW);       }

The if statement checks if the first bit is a 1. If it is, it'll send a HIGH to the DATA pin (and otherwise LOW). Then it shifts the address byte that we made, clocks once and then returns to the top. Easy as pie.

For the msg that we sent, it's even easier! We don't need any conditioning so we'll just do the same for that byte:

  for(int i=0;i<8;i++)   {     if(msg&0b10000000)       digitalWrite(DATA,HIGH);     else        digitalWrite(DATA,LOW);       msg=msg<<1;          digitalWrite(CLK,HIGH);     digitalWrite(CLK,LOW);   }

Now stick it all in the writeInstruction function and give yourself a pat on the back because that's DONEZO.

READ

For the read function, we'll send it an address, but we'll want a value back. Specifically, we want the X,Y, and Z acceleration values back. Since this is a signed 8bit value, we'll use a signed char as the return type.

signed char readRegister(char address){}

Again, we condition the address byte, but this time, instead of setting the first bit, we clear it to 0 since that implies we mean to read a byte.

  address=address<<1;   address&=~0b10000000;

Just as before, we send out the address bit by bit:

  for(int i=0;i<8;i++)   {     if(address&0b10000000)       digitalWrite(DATA,HIGH);     else       digitalWrite(DATA,LOW);       address=address<<1;          digitalWrite(CLK,HIGH);     digitalWrite(CLK,LOW);   }

which shouldn't be new to you since that's what we did in the last function!

Next we have to set the DATA pin to read, set up a variable to hold the data we read, and then get the data bit by bit and put it into the variable we created. I called mine temp since I'm creative, but not THAT creative. Then, we set the pin back to output and return temp!

  pinMode(DATA,INPUT);      signed char temp=0x00;   boolean currentBit;   for(int i=7;i>=0;i--){          digitalWrite(CLK,HIGH);     currentBit=digitalRead(DATA);     temp|=currentBit<<i;     digitalWrite(CLK,LOW);   }   pinMode(DATA,OUTPUT);   return temp;

So the loop goes backward (since we're getting the most significant bit first from the MMA) and temp is |='ed with a byte that is essentially the read bit shifted over to its correct position. This way, none of the bits that aren't in the currentBit's position aren't affected.

Stick that code into readRegister() and you're almost home.

The loop is then just getting the values, and then printing them in the serial monitor.

void loop() {   Xval=readRegister(XOUT8);  //get X val   Yval=readRegister(YOUT8);  //get Y val   Zval=readRegister(ZOUT8);  //get Z val   Serial.print (Xval,DEC); Serial.print(",");   Serial.print (Yval,DEC); Serial.print(",");   Serial.println (Zval,DEC); }

Since the Xval is some randomazz byte in binary (2's complement for negative), we use Serial.print(VALUE,DEC); so that the number is converted into some decimal value. I used CSV formatting and I got this neato graph!

Here, I just waved the thing up and down twice in the Z-direction (yellow), X-direction (blue), and then the Y-direction (red).

The Z-axis acceleration is offset because the damn thing can measure gravity! In fact, it's sitting at around 64. Since we chose signed integers to represent the data, and you'll recall this thing is measuring +/-2g's at 8 bit resolution (i.e. ~+/-127), sitting at 64 means that we're measuring 1g: GRAVITY!

This is another great advantage to the chip. If we can measure gravity, we can measure how much the device is tilted; if the X-axis was perpendicular to the ground, then we would get an offset of 64 on the X-acceleration measurement. Here's another graph from tilting it from the Z-direction to the Y-direction, back to the Z and then to the X-direction.

You can see it will go negative depending on which direction you tilt it.

If you're interested in the theory, read on, dear traveler! Otherwise, go ahead and skip to "Talking to GPS," but I warn you, you're missing out on some pretty dope google draw pictures.

THE BASICS

GPS or Global Positioning System is a system set up by the U.S. Department of Defense that uses 24 satellites shooting radio waves in all directions. What we all know as GPS (as in "check the damn GPS!") is actually just a device that has a little radio receiver in it and some circuitry to draw a map on the LCD screen. The business end of things is the little radio receiver that looks something like this:

How does the little GPS do that? Well, like most of our projects, it has to do with some very cool math.

First off, we know the receiver gets its info from satellites sending signals at the speed of light. The receiver knows a few things about the satellites thanks to the information that they send. Each satellite sends an identification message along with its position. By the time the receiver gets a signal from a satellite, some time has passed. Given the amount of delay between the source and receiver and the fact that the signal travels at the speed of light, you can determine the distance between the two.

Kay, so we've got the distance between a satellite and the receiver. Now, let's say we're living in 2D land on a nice X-Y coordinate system. How many satellites do we need? If we have one, we've got

This is obviously no good! We can be anywhere along the circle! Let's add a bunch more precision with another satellite:

MUCH better, but now we've got two possible points. Add another satellite and:

Bingo!

This method is called "trilateration."

But life ain't so flat. Will 3D be much more difficult?

In 3d, here's how our one satellite looks. Keep in mind we're DEFINITELY on earth's surface so we need one less satellite (we're always a distance Ro from the center of the earth).

Okay, so if we get a distance from one satellite, we are somewhere along a circle on the earth. To see this, imagine a sphere intersecting another sphere; you get a circle formed by the intersection. Let's add one more satellite's worth of data.

Now, technically, there were an infinite number of ways for these circles to form and we could have ended up with the same situation as in 2D where we have two intersection points. However, we can shave off an extra satellite if we drop a point straight down from the each satellite to the earth, and form new circles from this point to the receiving point. We can do this since the satellites are at precise locations above the earth so their drop-down distance is exactly known.

If we just do a little Pythagorean theorem, we get A1 and A2!

Very cool!

For more very interesting information, check out this link at pocketgpsworld

TALKING TO GPS

I chose GPS kinda by accident and it turned out to be about the simplest thing to interface with!

Let's start with the Arduino way since we have nearly all the software setup for us and we've got a serial monitor to play with!

The RX and TX for the Arduino's USART module is broken out to Pin 0 and 1 so these guys are reserved for talking to the computer through the USB since we want to use the serial monitor. If, instead, we just piped the information to the processor, did some operations on it and output it somewhere without using the USB communication, we could totally use 0 and 1 on the Arduino. Instead, we'll have to use pins 2 and 3.

Now, with a lot of chips, you need to have a startup sequence, but the GPS is different. On power-up, it immediately starts looking for satellites and, once it has locked onto 3 or 4+, it'll start sending data immediately over its Tx port, so really, for now, let's just ignore the Rx port. This means we only need Tx, Vin, and Gnd! 3 pins! The datasheet shows that too!

Ok ok, this is a doing blog. Let's get into that!

Electronics

You don't by any means have to use the specific hardware I've got since nearly all the pinous and coding will be exactly the same!

I used:

1 cup PMB-688 SiRF GPS module

a pinch of Arduino Diecimila with an Atmega328 onboard

a little love.

As we said, the electronics is dead simple. Positive, ground, and pin2 (let's say for Rx on the Arduino side). 

Bam. No extra components!

The real lifting comes on the programming end.

Programming

Okay, so we already established we needed two extra serial ports to connect through to get this thang goin so we'll use a library called "SoftwareSerial.h" It allows us to use USART on any of the pins. It goes like this:

#include <SoftwareSerial.h>  //the library we want SoftwareSerial GPSmodule = SoftwareSerial(2,3);  //makes a SoftwareSerial object called GPSmodule with Rx at pin2 and Tx at pin3

That's all we need to get started!

Next, in the setup, we need a baudrate or a speed at which to communicate. Serial communication can take place either synchronously or asynchronously. This just means "with a clock" or "without a clock" respectively. In synchronous communication, one pin is designated a clock pin and it tells each device when a bit is being sent/received. We'll cover this in later projects.

For asynchronous, each device operates at a set speed. So let's say we turn on our GPS module and then start reading. We run into a problem! If they're just at some set speed, what's to keep the uC from reading the middle of a byte message instead of the beginning? Well, all the data bits are sandwiched between a start bit and a stop bit like this:

Now, if we see that a '0' followed by a '1' appears periodically after 8 bits, we'll know that they're the start and stop bits! These are called 'parity bits' and they'll be handy later.

Okay, so both the USART module and SoftwareSerial library take care of the parity bits so that we can take out the good stuff. Now we just need to setup the baudrate. The default for our GPS is 4800  so we'll assign the GPSmodule object that number.

void setup(){   GPSmodule.begin(4800);   Serial.begin(9600); } 

And then just readout the raw data:

void loop(){   Serial.write(GPSmodule.read()); }

SIMPLE non? In older Arduino we woulda said Serial.print(GPSmodule.read(),BYTE);. It's been a while since I used Arduino so this is kinda a mystery to me. My output ended up being:

ÿ$ÿGÿPÿGÿSÿVÿ,ÿ3ÿ,ÿ1ÿ,ÿ1ÿ2ÿ,ÿ2ÿ0ÿ,ÿ6ÿ6ÿ,ÿ2ÿ0ÿ0ÿ,ÿ4ÿ1ÿ,ÿ2ÿ3ÿ,ÿ6ÿ0ÿ,

ÿ3ÿ3ÿ9ÿ,ÿ3ÿ5ÿ,ÿ1ÿ6ÿ,ÿ5ÿ4ÿ,ÿ0ÿ9ÿ6ÿ,ÿ2ÿ8ÿ,ÿ3ÿ2ÿ,ÿ4ÿ8ÿ,ÿ1ÿ5ÿ7ÿ,ÿ3ÿ3ÿ*ÿ7ÿ8ÿ

ÿ

ÿ$ÿGÿPÿGÿSÿVÿ,ÿ3ÿ,ÿ2ÿ,ÿ1ÿ2ÿ,ÿ3ÿ0ÿ,ÿ4ÿ1ÿ,ÿ0ÿ5ÿ8ÿ,ÿ3ÿ1ÿ,ÿ1ÿ3ÿ,ÿ3ÿ4ÿ,

ÿ3ÿ0ÿ7ÿ,ÿ2ÿ2ÿ,ÿ0ÿ7ÿ,ÿ2ÿ5ÿ,ÿ2ÿ4ÿ6ÿ,ÿ3ÿ4ÿ,ÿ0ÿ4ÿ,ÿ0ÿ9ÿ,ÿ3ÿ0ÿ1ÿ,ÿ2ÿ8ÿ*ÿ7ÿ1ÿ

ÿ

ÿ$ÿGÿPÿGÿSÿVÿ,ÿ3ÿ,ÿ3ÿ,ÿ1ÿ2ÿ,ÿ2ÿ4ÿ,ÿ0ÿ9ÿ,ÿ3ÿ0ÿ8ÿ,ÿ,ÿ1ÿ0ÿ,ÿ0ÿ7ÿ,

ÿ3ÿ1ÿ9ÿ,ÿ2ÿ7ÿ,ÿ0ÿ3ÿ,ÿ0ÿ7ÿ,ÿ1ÿ3ÿ2ÿ,ÿ2ÿ5ÿ,ÿ3ÿ1ÿ,ÿ0ÿ6ÿ,ÿ0ÿ5ÿ2ÿ,ÿ*ÿ7ÿ6ÿ

ÿ

ÿ$ÿGÿPÿRÿMÿCÿ,ÿ2ÿ1ÿ1ÿ5ÿ0ÿ3ÿ.ÿ0ÿ0ÿ0ÿ,ÿAÿ,ÿ3ÿ4ÿ0ÿ0ÿ.ÿ6ÿ3ÿ6ÿ1ÿ,

ÿNÿ,ÿ1ÿ1ÿ8ÿ2ÿ4ÿ.ÿ8ÿ4ÿ7ÿ4ÿ,ÿWÿ,ÿ0ÿ.ÿ0ÿ0ÿ,ÿ1ÿ1ÿ1ÿ.ÿ1ÿ5ÿ,ÿ1ÿ7ÿ0ÿ4ÿ1ÿ2ÿ,ÿ,ÿ,ÿDÿ*ÿ7ÿDÿ

ÿ

ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Which looks a little gibberish-y right? Let's take away all those "ÿ"

$GPGSV,3,1,12,20,66,200,41,23,60,339,35,16,54,096,28,32,48,157,33*78

$GPGSV,3,2,12,30,41,058,31,13,34,307,22,07,25,246,34,04,09,301,28*71

$GPGSV,3,3,12,24,09,308,,10,07,319,27,03,07,132,25,31,06,052,*76

$GPRMC,211503.000,A,3400.6361,N,11824.8474,W,0.00,111.15,170412,,,D*7D

Aaah, now we've got something a little more interesting!

The GPS just sends straight up text data in ASCII! Obviously we don't want all those ÿ's and we want our PROGRAM to work for US not for US to work for the program! So I converted the stream into integer (you can change between data types by using

(datatype) variable name : example (int) characterVariable

to get the integer value of the character. It turned out to be a bunch of -1's so I just took those out by adding

  char received;

and using the loop:

  received=GPSmodule.read();

  if((int)received==-1){}

  else  Serial.print(received);

and everything was programagically switched to something like this!

$GPRMC,234345.000,A,3400.6283,N,11824.8435,W,0.00,95.49,170412,,,A*47

$GPGGA,234346.000,3400.6283,N,11824.8435,W,1,07,1.3,22.0,M,-33.9,M,,0000*57

$GPGSA,A,3,23,06,07,08,19,10,16,,,,,,2.8,1.3,2.5*3B

$GPGSV,3,1,12,13,76,094,33,07,60,338,31,23,45,129,36,10,39,262,31*7D

$GPGSV,3,2,12,08,35,289,29,19,31,107,27,03,28,064,32,28,18,220,18*74

$GPGSV,3,3,12,06,18,053,36,05,11,316,23,16,10,041,23,20,02,173,*71

$GPRMC,234346.000,A,3400.6283,N,11824.8435,W,0.00,95.49,170412,,,A*44

$GPGGA,234347.000,3400.6283,N,11824.8435,W,1,07,1.3,22.0,M,-33.9,M,,0000*56

$GPGSA,A,3,23,06,07,08,19,10,16,,,,,,2.8,1.3,2.5*3B

$GPRMC,234347.000,A,3400.6283,N,11824.8435,W,0.00,95.49,170412,,,A*45

Nice. I readout about 51 lines and found a recurring pattern:

$GPRMC,$GPGGA,$GPGSA, $GPRMC,$GPGGA,$GPGSA, $GPRMC,$GPGGA,$GPGSA, $GPRMC,$GPGGA,$GPGSA, $GPRMC,$GPGGA,$GPGSA, $GPGSV,$GPGSV,$GPGSV

a buncha times. Now what does each one mean? Whelp, they all happen to be a part of the NMEA standard. Here's are some of the more useful values we've got, but there are more details in the NMEA reference manual here.

Here, the only thing that's not so familiar is speed in knots. Since this was developed by the National Marine Electronics Association, it would make sense that speed is in knots or nautical miles/hr.

1 knot = 1.5078 mph = 0.51444 m/s

Also the angle with respect to true north means we get a nifty compass! Score!

In the GPGGA sentence, we get a whole bunch of altitude data. The mean sea level is a model of the Earth using area specific data and represents the 0 altitude point so, in this example, 22 m is the distance from a 0 sea level. The Geoid to Ellipsoid measurement is the difference between the Earth model as a flattened sphere and its height at hills and valleys. For more information on these values check the esri website here!

The $GPGSA line tells us the ID's of the satellites we're getting data from, and there are some accuracy readings following that to show the fidelity of the readings.

Finally, the $GPGSV line will give us some information about the satellites that the GPS got information from including the elevation (in spherical coordinates, the vertical angle), the azimuth angle (the horizontal angle in spherical) and the signal to noise ratio (SNR). There are four satellites per $GPGSV line and three lines giving a total of 12 satellites.

Isn't that a-friggin-mazing? You have the angle of a satellite and (essentially) their distance, so you could point DIRECTLY AT one. I dunno why but that's pretty astounding to me.

Anywho, this is one of those rare instances where we have SO much information that it's up to us what we want to pull! If we wanted, we could make an atomic clock, but it wouldn't be all that interesting. We could make automated cars, robots that move around the world, geocaching games, the possibilities are endless! In fact, we'll DEFINITELY see this again in a later project so keep your mind sharp and start goin places!