What happened NASA

    All through my childhood I was fascinated by the moon landing, the space shuttle, and all the things NASA engineers were able to do. Last night I got curious about how my near space balloon computer would stack up against the Apollo 11 computer. Apollo 11 was the first manned moon landing for those of you who aren't up on space history. Seeing as my iPhone has roughly 10 times more of everything than my first PC, I figure my balloon computer should come pretty close to what Apollo 11 had. The specs for both are below.

Luke's Near Space Balloon Computer:

• 2 ATMega128 microcontrollers
• 8 MHz clock
• 128k flash memory
• 4k SRAM memory
• 2 uM-FPU co-processors
• 29 MHz clock
• ~2k flash memory
• Telit GM862 Cellular Module
• Python script interpreter
• 2MB flash memory
• 1.2MB RAM

Apollo 11 Command Module Computer:

• Custom Made Integrated Circuits
• 1 MHz clock
• 72k ROM
• 4K RAM

    To be fair the Apollo command module also had the worlds best computer built-in...the human brain. My balloon will be unmanned so it must handle all the problems itself. It's still incredible that NASA was able to keep track of so many sensors and control systems with the equivalent of a $1 microcontroller in today's world. Be careful if you're thinking NASA's budget is way overinflated, though. The sensors, actuators, testing, and development are where the expensive stuff is. Take for example my balloon. The microcontrollers cost me about $15 each, but the IPT temperature/pressure sensor will cost $500. My components aren't rated to handle the large amounts of radiation that circle just outside our atmosphere either. Ionizing radiation will erase the contents of flash memory and that's where the computer's programming is stored!

The Tellit GM862 Cellular Module

    There are many challenges in the communications design for a high altitude balloon. With small standard antennas cellular service stops working anywhere between 20k - 40k feet. There are several arguments as to why, but the most accepted reason is that at altitude multiple cell towers begin to receive the cellular signal and the network becomes confused. Many balloon designs avoid the cellular problem by using amateur radio devices or HAM radio. There is certainly no problem receiving a HAM signal from high altitudes, but as the balloon descends to the ground the line-of-sight becomes obstructed and the communications link can be lost. In my opinion it is better to know where the balloon lands than to keep constant communication with it in the air. Of course both HAM and cellular could be used on the same balloon, but weight is also an issue. With all that in mind I decided to go with a cellular only solution and conduct some experiments with cantennas and waveguide antennas to combat the multi-tower problem.
    I chose to use the GM862 cellular module from Tellit because they are readily available, they include the SIM card connector on-module, and they use a built-in antenna connector. It's quite difficult to do impedance matching on a PCB when you don't have all of the professional tools for layout. The module can be bought with built-in GPS, but the SiRF III chipset is limited to operation below 60k feet. Since I'm heading to almost twice that altitude I won't be able to use that chipset. The cellular part of the module connects to a "data terminal" through a TTL level serial connection. That makes it very easy to experiment with the module using a computer and a TTL to RS-232 level sifter. The commands are in the standard Hayes AT modem commands with a few specialty ones. All of this is well documented in the Software User's Guide and the AT Reference Guide.
    When using the GM862 with a microcontroller things can get a bit tricky. A micro doesn't have a built-in serial buffer like a data terminal has, so there is lots of overhead in the code to capture all the data coming from the GM862 and deal with the data terminal style formatting. It can be a pain to parse the buffer for a status and I usually end up counting the number of characters I expect the module to return for a particular command. If I don't see the status I expected I dig deeper into error cases. It helps a lot if you turn off the GM862's echo feature. That way the commands you send aren't echoed back to you as you send them and there are less characters to confuse the returned data. The echo is enabled by default and can be turned off by sending the ATE0 command. Echo can be re-enabled by sending ATE1. Below is a list of commands you need to get a cellular call and SMS message going, quick and dirty!

Quick Start Cellular Call:

• AT#AUTOBND=2    Sets the module to automatically scan all 4 cellular bands for a network
• AT+CREG?    Checks if the module is registered on a network. You'll get "AT+CREG 1,0\r\nOK\r\n" if it's registered
• AT+FCLASS=8    Tells the module that you are only making phone calls, if you don't use this you have to place a semicolon after your phone call command. Don't use this command if you are going to send SMS messages also.
• AT#CAP=2    Tells the module to use the MT microphone input as the source audio
• ATD {phone number} [; if you didn't use AT+FCLASS=8]   This starts the phone call. Sometimes the network requires the full 10 digit phone number with area code, so it's best to just put it all in there.
• ATH   This will end the voice call.

Quick Start SMS:

• AT+CMGF=1    This command sets the SMS editing mode to TEXT mode. If you understand PDU mode you can use that also, but I prefer to read and write in english.
• AT+CPMS="SM"    This sets the module to store SMS messages on the SIM card
• AT+CNMI=0,0,0,0,0    This command sets the notifications that the module sends out about SMS messages. The first zero disables notifications about incoming messages. The second zero disables notifications about messages being sent. The last three zeros deal with low-level network stuff and will probably always be zero for your project.
• AT+CMGS="{phone number}"  This command tells the module to start a new SMS message. After the command is sent the module will return a command prompt (>) and then you enter the text you want to send. To actually send the message you must send CTRL-Z (0x1A in hex) to the module. 

The Micromega uM-FPU

    I found this great floating point co-processor on the SparkFun website. If you haven't been to www.sparkfun.com and you're looking for hobby electronics parts I highly recommend you go! If you're wondering what a floating point co-processor is good for read on.
    Microcontrollers were designed to be simple processors with a lot of peripheral devices built into the same chip. They are great for many tasks, but most of them do not include hardware support for floating point calculations. If you can deal with working only in integer numbers that isn't a problem, but if you need to use decimal precision of any kind you might have to include a very large math library to your code. The other alternative is to use a floating point co-processor.
    The uM-FPU attaches to the microcontroller via a SPI, I2C, or UART bus. Once the connection is made the microcontroller sends commands (in the uM-FPU machine code format) to the co-processor to do any number of floating point, integer, unit conversion, or NMEA sentence parsing. If you're thinking, "Great...now I have to hand code the bus transactions for the uM-FPU machine code" that may not be the case. The Micromega website, www.micromegacorp.com, has API libraries for many of the popular micros like PIC, AVR, Basic ATOM, etc.
    The uM-FPU is also capable of storing user defined functions in its internal memory. This is handy if you have a lengthy set of commands that you run regularly, like retrieving the lat/long co-ordinates from a NMEA string. To program the user defined functions you'll need the uM-FPU IDE from the Micromega website. The documentation on the IDE and the command set is a little lacking so there are a few pointers below. Once you write a few lines of code with this co-processor you'll be surprised how simple and powerful it is!

Making your own functions:

• The first tab on the IDE lets you enter code and compile it for a number of different target micros or the uM-FPU itself. To compile a function to be stored on the uM-FPU choose "uM-FPU Assembler" from the dropdown list.
• User functions must start with #FUNCTION [optional function name]
• Your code must be enclosed in #asm and #endasm tags
• Your function must end with #END after the #endasm tag
• After you click compile you can see a list of your functions on the Functions tab

 The Chip Select Pin:

• The chip select pin is setup to choose between SPI and I2C interfaces by default. It does not work as a normal SPI chip select pin unless you use the IDE to program the settings.
• If you want to use the IDE to program the device you must tie the chip select pin high to force the UART connection on powerup. It is possible to debug without holding the chip select pin high.

The MCLR# Pin:

• You must tie this pin high for the chip to work, it does not have an internal pullup like all the AVR folks will be use to.

The Support Forum:

• Unlike most support forums, Micromega has a staff member that routinely checks this forum. You can expect to have your questions replied to by the staff in a day or so. They are extremely helpful!
• http://tech.groups.yahoo.com/group/uMFPU/messages

The Balloon Plan

    There have been several amateur high altitude weather balloon launches in the past few years. In the U.S. the most famous is probably the $149 MIT balloon. Most of the projects are just interested in getting pictures and the thrill of finding the payload once it comes back down. I've decided to spend a good amount of money, collect some reliable pressure and temperature data, and of course get some of those beautiful high altitude pictures. If everything goes well with this launch I may attempt to break the unmanned balloon altitude record of 51.82 km. This balloon should reach about 34 km (112,000 feet or so).

The Components:

• Communication by a Telit GM862 cellular module and a custom made directional antenna
• GPS tracking by a GS407 receiver with the u-blox chipset (this is good to 50 km with the right dymanic platform setting programmed)
• Temperature and pressure data from a Honeywell IPT module (it's expensive, but it's one of a few modules that can read the low pressures at high altitudes)
• Heading and acceleration data from a VectorNav VN-100 module (this is just a nice to have thing since the GPS will also give a heading and it's quite expensive)
• Data logging in SD memory cards using the FAT32 file system for easy reading on a computer
  
• Processing done by Atmel AVR micros with Micromega uM-FPU v3.1 co-processors (the co-processors handle complex math and also have NMEA sentence parsers to make the GPS and VN-100 easy to handle)
• Undecided on the specific camera right now, but there will probably be multiple cameras to capture every angle
• DC motor and weighted disk to act as a gyro stabilizer that prevents the payload from spinning during flight
• LiPo batteries of course
• Kaymont cold weather balloon (size to be determined based on the weight of my finished payload)