The college I go to decided that they were going to fire our only computer science professor; I think that’s when we started really doing some incredible stuff. Knowing he didn’t have much time with us, we set off right away in the only major class he was teaching for the term, Telemetry.

There were 12 students in the class, all experienced and seasoned computer science kids, either working mainly in programming, or with actually modding up and engineering little project boards. We were put into 3 teams in 4-week cycles for the term; each cycle, we were responsible for creating a new Telemetric device, with no limitations other than where it had to be or go; the first cycle was by land, and we built some animal cameras. The second, by sea, and we built various projects that sensed turbidity, pressure, temperature, and so forth.

The final project turned out to be much harder than we thought, so we ended up breaking up into two 6-person teams, one of which would do individual projects, the other which would work on building one project together: this project was to be by air, and within the first day, we had set out our mission: send up a weather balloon, with an arduino attached, have it measure some data, but most importantly, set up a tracking system that was robust enough for us to go out in the field and find it.

I’ll say it right off the bat now: we didn’t find it, and I think I know why, and I have suggestions for anyone doing something like this. Either way, lets get to the ingredients.

So, you want to send a weather balloon up into the sky, and go out and retrieve it. This is how to do it. I’m breaking it up into 4 sections, so if you’re interested in any particular aspect just jump ahead, but there will be some overlap.

Things you need to know:

  • The FAA doesn’t really give a shit that you’re putting up a weather balloon. All you have to do is throw a shoebox sized payload on the thing that has aluminum foil all over it so radar can pick it up.
  • This is slightly expensive, and it’s not a for sure thing that you’ll get it back, and most of the stuff is kind of one-time use, so go ahead with this stuff only if you have the cashes.
  • Lots of soldering is needed to make a good setup; don’t even think about doing this with my approach if you either a. suck at soldering, or b. hate soldering, or c. don’t know anything about it or lack the materials.

Things you need to buy:

  • Arduino board, with an ATMEGA 168 chip onboard. This Chip has to be replaced with an ATMEGA 328P chip, which sports a lot more ram. More on why in a bit.
  • Three Max395 Chips
  • Disney Camera – I’ll get the specific model for you later.
  • GPS Shield setup – buy it from Lady Ada two sd cards, one under 512 mb, another under 1gb.
    A weather balloon and parachute – these can be purchased at balloonsdirect.com. Anything that can support 5 pounds or more is great.
  • Money for helium when the time comes
  • A cell phone (again, model number will come later; on a plane right now)
  • A sim card for said cell phone
  • Serial wiring (like on old IDEs or floppy drive ribbon wires) tons of regular wire, soldering iron, solder sucker, solder, cutters, the regular stuff.
  • Things you need to build:
The GPS Shield

This part is fairly straightforward – you can grab the directions at Lady Ada’s site, and follow along with all her directions. run through her tests, and it should all be fine. Lots of soldering though; have fun!

The Cell Phone

Take the cover off of the cell phone carefully, and work through the various layers of packaging until you reach the white plastic that seals connections for the buttons. You can take that off carefully, but I just ripped it off, and didn’t look back. Not a big deal.
Then, using your soldering Iron, and 42 carefully cut lead wires, all of about 1 inch in length, solder on the wires to the individual buttons. Basically, you want to add a dimple of solder to each center circle, then reheat it and push the wire in and lock it, then just be careful on the outer circle. Do this for everything. It sucks, but it has to be done. Test each solder before moving onto another button.
Before you do anything else, figure out a solution for testing each of the buttons, which could be as easy as turning on the phone, and touching the wires to complete the signal to the button, or whatever. Doesn’t really matter, just be careful, because these soldering joints generally suck and are hard to do over. its best to get this right the first time.

Once we know that everything is working, seal that thing up. We used a whole shit-ton of silicone to solidify the areas about the joints, and make it harder to move it around. Basically, we want to figure out something to keep it from breaking off. We really need these buttons.

After everything is soldered and sealed, you want to take your serial wires and wire up the phone as is shown in the gallery below. We were working with wries that were connected in groups of 8, which would allow for 4 pairs. We grouped them as the image shows, but if you don’t want to do that its, fine as well, it just keeps it from becoming a rats nest.

Leave this alone for now, and go work on the PCB.

Printed Circuit Board

Another Diagram follows the confusing Max 395 chips. Look over this very carefully; essentially, the Max395 chips piggyback on one another. Hardware side, they are all joined with the same sync wires, and are identical, and can be piggybacked forever. Software wise, you set a constant in the program to say how many Max Chips you are actually using, then you can write to them accordingly.

First, drop in your max chips, in line. Get plug all pins 2 and 23 to power, all pins 4 and 21 to ground. Pins 1, 3, and 24 of the main chip (the first one in the group) into 7, 8, and 9, respectively, on your arduino. Solder the phone’s output wires into place, or stick them in, whatever way you’re going to do this. At this point, you should be able to run the scratch program, keyboardCellphone.c. It maps 0-9 on your keyboard to 0-9 on the phone, and uses the naming schematic A-K for the buttons A-K. From here, you should be able to control the phone via your laptop keyboard.

Doesn’t matter if you have your GPS shield on here for this initial testing program, should just work.

Camera

(Details to be added later)

Rigging the beast together:

GPS

On top of the GPS shield, you will notice that for a while, on the digital side of the ports, there are other jumpers that are pointing out directly parallel to the digital ports; no mistake here. You want to run 5 wires through that area; start with 6, then 5, 4, 3, and 2, and stick wires into the corresponding ports, then you should be all good to go with the GPS.

PHONE
  • All solder joints good and sealed
  • All Max connections are complete, and no solder is touching, not mistakes like that anywhere
  • Power? Enough Minutes? Everything working when you run keyboardCellphone?
CAMERA

Shutter is connected to pin 21, the power and ground are connected to a separate powersource of perhaps 4 AA batteries.

The Program:

Libraries

AF_SDLog
SoftSerial
Hacks on SD Library

By Default, the SD Card library we are using does not recognize Atmega 328 Chips. This is a problem. Basically, a minimum buffer size for SD cards is 512 bytes; meaning automatically, you lose 512 bytes of memory whenever you’re using the sd library. Not a big deal when we’re just using a computer, but this thing only has 800 bytes available; you’re basically a few bytes away from the maximum by the time you get all your libraries in and count the peripheral arduino code.

So, we hack in the ability to use Atmega 328 (which, remember, have more memory) chips by telling the SD library that they can be friendly. The following code is located in sdrawconfig.h in the AF_SDLog library. This all starts at line 55:

    #if defined(__AVR_ATmega8__) || \
        defined(__AVR_ATmega48__) || \
        defined(__AVR_ATmega88__) || \

    //THESE LINES ARE CHANGED/ADDED
        defined(__AVR_ATmega168__) || \
        defined(__AVR_ATmega328P__)
    //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        #define configure_pin_mosi() DDRB |= (1 << DDB3)
        #define configure_pin_sck() DDRB |= (1 << DDB5)
        #define configure_pin_ss() DDRB |= (1 << DDB2)
        #define configure_pin_miso() DDRB &= ~(1 << DDB4)

        #define select_card() PORTB &= ~(1 << PB2)
        #define unselect_card() PORTB |= (1 << PB2)
    #elif defined(__AVR_ATmega16__) || \
          defined(__AVR_ATmega32__)
        #define configure_pin_mosi() DDRB |= (1 << DDB5)
        #define configure_pin_sck() DDRB |= (1 << DDB7)
        #define configure_pin_ss() DDRB |= (1 << DDB4)
        #define configure_pin_miso() DDRB &= ~(1 << DDB6)

        #define select_card() PORTB &= ~(1 << PB4)
        #define unselect_card() PORTB |= (1 << PB4)
    #elif defined(__AVR_ATmega64__) || \
          defined(__AVR_ATmega128__) || \
          defined(__AVR_ATmega169__)
        #define configure_pin_mosi() DDRB |= (1 << DDB2)
        #define configure_pin_sck() DDRB |= (1 << DDB1)
        #define configure_pin_ss() DDRB |= (1 << DDB0)
        #define configure_pin_miso() DDRB &= ~(1 << DDB3)

        #define select_card() PORTB &= ~(1 << PB0)
        #define unselect_card() PORTB |= (1 << PB0)
    #else
        #error "no sd/mmc pin mapping available!"
    #endif

Our Programs, how they work

Basically, we can break our programs into a few major functions:

Gathering data
Taking Pictures
Writing Data
Sending Texts
In order of difficulty.

So, lets begin.

Gathering Data

Gathering data is ridiculously simple. Hardware wise, we just have some LM35’s on our particular project recording temperature; the most fun is trying to find it. LM35’s work just like resistors: one pin goes into power, another ground, and a third into an analog read on the ’duino.

You record the data by using a timer check; if the next check time is less than or equal to the current time, run another check, then set the next time we want to record. in our case, its pretty much every second or so. That’s pretty much it; it all happens in the function save_data.

Taking Pictures

This is only slightly harder, as we want to assign an on and off state using phase switches that write to the max chip. essentially, we wait for a bit, turn the max chip port on (closing the circuit for the shutter button, like hot-wiring it or something), wait some time, simulating that we’re holding it down, then we turn it off again and wait for a long time until its time to snap another pic.

Writing Data

Writing the data is a bit complicated; with the sd library, we have to target the actual memory locations we are interested in saving to; we need to have a log_count in the program, which stores how many records we have. we store this on the sd card as well, and start the big block of sd memory available to the arduino after it. so, say the log is 4 bytes long, then we start the memory block at memory block 8 (accounting for 4 other bytes in the beginning to serve as an ID tag for our sd cards, determining if its the one we want to be using.)

So, then, we read the value at byte 4-7, then use that to iterate through the memory, or point to the next available slot and update the log_count with how many records we now have after a change or how many we want to print out when all is said and done.

Sending Texts

Sending texts is fairly straightforward; notice this line:

//Phone mapping to the max395 chip
//in order, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, G, H, I, POUND, STAR
const char phone[] = {12, 8, 15, 16, 9, 14, 17, 10, 13, 18, 0, 6, 7, 1, 2, 5, 4, 3, 20, 19, 11};

That’s really the nugget; that is a mapping of the cell phone numbers we want to press to the max chip layout. So, if we wanted to press 9, it would be phone9. Cool, right?

The only lame thing is that its not phone[A], but that can always be put in with a #define A 0. I didn’t see it as necessary.

So, that’s how we target the actual buttons on the cell phone. How do we send a text message?

you might notice this:

char sequence[53];

That call right there is the actual sequence we are going to be pushing in. here’s how it works:

First, during setup, we stuff the first 11 spots of the sequence array with the keystrokes to get the cellphone to a good, new text message box.

Then, we allocate the next thirty for latitude and longitude settings; so, for example, we’ll have the handle_gps(); call in the loop, and that resets the latitude and longitude, two different arrays both of length 15. These two arrays are pushed in each time we go through a new initialization of the text message.

Finally, we stuff the end sequence into the char array (this actually happens beforehand in setup, we’re just going through the array step by step here.). This sequence will always ensure that even if we mess up somewhere along the way with the phone, we can get back to a good dialog box for a text message.

Then, it’ll send your text message. you could either make the sequence 53 elements long and have the number send to 40404 (Twitter, you’ll have to setup an account with this phone duhhh), or 58 elements long and just to another phone. Your call.

Potential Gotchas:

The GPS doesn’t work! Answer: It does, its just finicky from time to time. Mess with it, restart arduino, or re-up your code, and all should be well.

Cell phone doesn't work! Answer: In order of steps to take, The SIM card may be out of minutes, the solder joints may be screwed up (probe in this case, don’t cut it all up and do over.), the max chips may have extra solder touching, the max chips may not be wired correctly. SD Card doesn’t work! Answer: This is generally not a problem with the code or anything; its just that these aren’t intended for use with massive SD cards like we have these days; go dig in your attic, basement, drawer, wherever, and grab cards under 1gb. This usually solves the problem.

Flight day (or whatever you do with this thing)
  • Verify that twitter is receiving the texts
  • Verify that the data is valid
  • Verify that the SD card is writing properly after a 15 minute test download the pictures from a test run, verify that those are looking good and right
  • Once you run a 15 minute test making sure all these things are happening, let it go!
Final Notes

MIT did a project just like this one, with two big differences: They used a single box that performed all of these functions, instead of building one, and they were on CNN. This one was done about half a year after the undergrads at a liberal arts college pulled it off…

Oh well. You can look at their project here: 1337Arts

Lady Ada

Zip File of everything

Also, feel free to contact me for any questions on how to do a project like this, and I’m always down for helping build more of these.

GPS Balloon