Near Space Balloon

From Dallas Makerspace
Jump to: navigation, search

NOTE: This is the old project. Please see the new HAB project. DMS High Altitude Balloon

High altitude balloons are unmanned balloons, usually filled with helium or hydrogen that are released into the stratosphere, generally reaching between 60,000 to 120,000 feet (18 to 37 km).[1]


This project is currently in the design phase. See the Near Space Balloon thread on our forums to get involved with the design process.

Things We Need

  • People with HAM radio experience.
  • People willing to help build and test various modules.
  • People who will help with launch and recovery (lots of driving involved).
  • Someone to take photos and video to document the project.

- The DPRG has several HAMs, including Jeff Koenig and Kipton Moravec. In addition, the Dallas User Friendly group, has several like minded folks that are quite involved in HAM and telemetry broadcast etc. Once we have the project a little more firm, we can reach out to folks like Melissa Rasmussen and Patrick St. Jean.

Active Members


  • Take pictures, at least once per second from at least one camera
  • Record position, including altitude
  • Some way to recover the electronics package after it has landed
  • Stay within a budget of $300

Secondary Goals

  • Take video
  • Record atmospheric conditions such as temperature, humidity, pressure, acceleration, magnetic field strength, and ionizing radiation (using a Geiger Counter).
  • Broadcast some or all data in real-time


  • Temperature: As low as -50C
  • Pressure: Near 0mbar (almost vacuum!)
  • Legal: We need to meet the FAA regulations
  • Recovery


There are the three main segments, connected by a cord:

  • Balloon
  • Parachute
  • Electronics package


Details on the balloon and cord will go here.


Details on the parachute will go here.

Electronics Package

Telemetry Module

High Altitude Sensing Board

We've modified the source code slightly, so that the sensor board outputs the current UTC time from the GPS receiver. The vanilla firmware only uses the number of miliseconds since activation for timing information. We felt that grabbing the UTC time from the GPS was a better way to match readings to the actual time.

Also of note, it appears that the firmware the sensor board ships with is different that the source code Sparkfun has posted. The shipped firmware would show a menu for a few seconds and then start outputting telemetry in a loop. The source code Sparkfun posted has the menu being displayed with each telemetry burst. Our modified code removes the menu entirely (we didn't need it).

Serial Output

Baud rate is 9600 8N1, TTL voltage. First we'll get 9 lines of accelerometer and magnetometer readings. Then we'll get a 10th line with everything. Each burst starts with a hash ('#') and ends with an asterisk ('*'), all fields are comma delimited. If you see "complete timed out" messages, that means that the external temperature sensor is not communicating with the board.



When the board can not connect to the GPS the following is shown on the last line:


I compiled this info from the source code:

  • # - Start of line
  • accel_x
  • accel_y
  • accel_z
  • mag_x
  • mag_y
  • mag_z
  • millis_passed - Number of miliseconds since activation
  • utc_time - Current UTC time, this field not present with the vanilla firmware
  • long_h.long_l
  • lat_h.lat_l
  • altitude - Meters
  • siv - Satellites In View
  • fix - 0 = Invalid, 1 = GPS fix, 2 = DGPS fix, >2 Unknown
  • temp_internal - Celsius
  • temp_external - Celsius
  • humidity_level - What unit of measure is this?
  • batt_lvl - How do we convert this to volts?
  • temperature (from the pressure sensor) - Why is this so high?
  • pressure - What unit of measure is this?
  • * - End of line
Radio Output

Baud rate is 9600 8N1, I think at TTL voltage.

We have modified the firmware to output telemetry in a different format than the factory firmware. We have also added a number of additional data fields.

Example (this is without a GPS connected):


Example (with GPS):


Data fields:

  • utc_time - Current UTC time, this field not present with the vanilla firmware
  • long_h.long_l
  • lat_h.lat_l
  • altitude - Meters
  • siv - Satellites In View
  • fix - 0 = Invalid, 1 = GPS fix, 2 = DGPS fix, >2 Unknown
  • temp_internal - Celsius
  • temp_external - Celsius
  • batt_lvl - How do we convert this to volts?
  • pressure - What unit of measure is this?

LS20031 GPS

Don't let the datasheet fool you, the GPS defaulted to a baud rate of 57600 8N1 and not the 9600 8N1 that the datasheet claims. To get the GPS module setup to work with our sensor board the following PMTK commands need to be sent.

Turn off everything except GPGGA:


Set the baud rate to 9600:


After much trial and error I realized that the GPS requires both CR and LF line termination. If you are trying to configure the GPS from Linux you will need to use the following commands:

echo -e '$PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29\r' > /dev/ttyUSB0
echo -e '$PMTK251,9600*17\r' > /dev/ttyUSB0

When connecting the LS20031 to our sensor board I discovered that the TX/RX pins need to be swapped on the connector. Since both the sensor board and the GPS use the following pin out:

  1. GND or not connected
  2. GND
  3. TX
  4. RX
  5. Vcc

Just be sure to read the datasheets and make sure that GPS_DOUT on the sensor board is connected to TX on the GPS.

For additional information, see the LS20031 GPS page in this wiki.

TMP102 External Temperature Sensor

Be sure to tie ADD0 to ground, since this is how the sensor determines what I2C address to use. If you don't tie ADD0 to ground the sensor will appear to work, but if you touch it or breathe on it weird things happen. This is probably due to the fact that ADD0 is floating, so touching the board causes ADD0 to jump around randomly.

OpenLog Data Recorder

We took a female 6-pin header, bent the pins about 90 degrees and soldered them to the OpenLog. Be sure to do this with the SD card slot and header on the bottom.



We are looking for a sub-$100 2-meter "handie talkie" that has at least 2 watts transmission power. It should have microphone/headphone connections and ability to operate periodically for 12+ hours on a single charge. Hooking the radio up to our Arduino/RadioShield combination should allow us bi-directional communication with the balloon during its entire flight.

Imaging Module

Information on the cameras used will go here.

Recovery Module

Information on the backup recovery method (cell phone) will go here.


Other Launches