PiBalloon II – Design Ideas

In August, I built and flew a Raspberry Pi powered high altitude weather balloon. The Pi was ideal, as it provided a low power Linux platform in a credit-card sized package. Using Python, BASH, and caffeine, I was able to produce 1200 baud APRS packets to be sent through the audio jack to a Baofeng UV-3R. The Pi also took pictures using a webcam, and sent them out using Slow Scan Television (SSTV). This was sent through a Wouxun KG-UVD1 using VOX. This system worked very well, but there are plenty of design improvements to be made, so I need to start from scratch.

PiBalloon II it shall be called.

I came across a new balloon box as I was walking through a biology centric building on the UTD campus. 2014-09-24[1]I didn’t have a banana for reference, but I did have a Pi B+. The box (externally) is 7x7x5.5 inches, giving me the perfect amount of room for a GPS module, Raspberry Pi, 2 D cell lithium batteries, a webcam, and these Baofeng-on-a-chip modules [DRA818V is the search term, if the link dies].

The Baofeng-on-a-chip modules are programmable via UART and can transmit at 27 or 30dBm (500mW/1W). I haven’t received mine yet, but I expect China Air Mail to provide in a week or two. Because they’re programmable via UART, it is theoretically possible to send SSTV on 144.5 and APRS packets on 144.39 using the same module. Admittedly, you can’t get APRS while SSTV is running, but it still has a lot of potential. My favorite idea is to program in the top 15 repeater pairs and the top 5 PL tones, and go down the list kerchunking repeaters from the edge of space. One could also program the Pi to announce its status on their favorite repeater using a speech synthesizer. “This is your Pi speaking. Our current altitude is 82,348 feet, and ascending. It’s a little chilly outside at -37 degrees celcius. Batteries are looking good. Go ahead and put your seatbacks and tray tables in the upright and locked positions, as we expect burst at any minute now.” The possibilities are endless with a radio that can be programmed in real time by a Raspberry Pi.

Similar to the last launch, I’d like to monitor several different parameters and send them out using APRS. I plan on building another 1-wire thermal sensor network using the Maxim DS18B20’s or similar. This time I’ll be using the real sensors, not the unreliable parasitic power units. The TI ADC didn’t perform well either on the previous launch, so I’ll most likely load up an ATmega chip to handle battery voltage monitoring. Ideally I can just feed data back to the Pi using a UART or other GPIO interface.

TI offers this chip called the TMP513. Check it out. It interfaces using I2C, and can measure battery voltage, three temperature sensors (and a fourth internal sensor), and even has a GPIO pin. Mouser has them in stock for <$5. If I can figure out how to use this chip, I’ll swap out the 1-wire network and the ATmega in favor of this. It has potential.

There is a possibility of a December launch. This group requests that the payloads be <2lbs and <12″ on any face. Size isn’t a problem, but weight might be. Hopefully the PiBalloon II will come out under that constraint.

Stay tuned for more updates on this project.

Flight of the Leftovers – A Success!

On Sunday, August 17th, 2014 we launched a 600g Totex balloon with a homebrew APRS tracker, and recovered the payload just 5 miles from the launch site.

Around 8:30AM on Sunday August 17th, it was pouring outside of my apartment in Richardson. Weather radar showed a decent amount of storm cells moving in a west-to-east fashion across the entire metroplex. By 11:30 the majority of the cells were to be out of the area, but we expected heavy cloud cover and a light sprinkle. As you can see in the photos above, heavy cloud cover and a light sprinkle were provided.

At the launch site, we plugged in the batteries, tested the various systems, and deemed the payload OK to launch. SSTV images were streaming in, and APRS packets were being relayed by the TinyTrak4 in the chase Jeep. The balloon-filling team used an entire size-K tank of helium (200cu ft.) to gain ~11.87 lbs of lift (~13.2lbs – 600 grams of balloon). Our box only weighs 6lbs, so we had roughly 5.9lbs of free lift with the payload attached. Using the APRS data, I was able to determine that our average rate of ascent was ~1417feet/min (7.2m/s).

[Note on calculations: Using the Slope function in Excel, it told me the average rate of change between packets was 1063 feet. Because we were beaconing at a 45 sec interval (.75min), 1063/.75 = 1417 feet/min. This is hella fast.]

Once we had liftoff, we decided it was time to grab a quick lunch, and prepare for the chase. A local Sonic was able to grab our business. When the balloon reached around 40,000 feet, we noticed that the position packets stopped updating, but the telemetry indicated that things kept getting cooler. After some quick research, we determined that our GPS was soft-limited to 40,000 feet, despite the spec sheet stating 50km. [More research and discussion with the South Texas Balloon Launch Team indicated that a certain serial string must be sent to the GPS to enable high altitude mode; furthering the educational factor of this launch].

After about twenty minutes of munching, the telemetry data indicated a quick drop in temperature. This can only mean one thing – burst. Admittedly, we didn’t know which way to head, as the APRS data was not yet providing accurate position packets. As we were driving towards the predicted landing site, the balloon dropped below the 40k foot GPS ceiling, and started providing us with accurate position data. The packets kept streaming in, altitude getting lower each time. Finally, we stopped getting packets. The last packet indicated the balloon was a quarter mile from 121, not far from where we performed several “legal” U-turns. Lo and behold, one of the chase Jeep passengers spotted an orange box in a muddy field. It was exactly a quarter mile from highway 121. The landing site was approximately 5 miles from the launch site.

There were several learning experiences with this launch.

  1. Don’t fly DB9 connectors. They will come disconnected, and you will have a bad day.
  2. Unlock the GPS. Just do it.
  3. Buy the right batteries. Lithium Thionyl Chloride cells are BAD. They have a high internal impedance, yielding a much lower current draw. Lithium Sulfur Dioxide (LiSO2) are the correct choice. I compensated for the 200ma max draw on the batteries we had by doubling up, giving me the 400ma required by the Pi.
  4. Wide angle lenses take cooler photos of landscapes. The Canon SX110IS does not have a wide angle lens. There was potential for cooler photos.
  5. Use switching voltage regulators. Linear regulators will dump a ton of energy in the form of heat. Tons of weight can be saved by flying less batteries when the right regulators are flown.

That sums it up pretty well. Enjoy some photos of our activities:

Design Updates – Flight of Leftovers

Various elements of “The Flight of The Leftovers” have been coming together. Here’s a a brief overview of what’s going on:


Okay, I screwed up on this one, but not bad enough that it will compromise the launch. It just means we’re going to fly a little heavy and a little hot. Here’s the backstory:

Several weeks ago, I requested the Xeno XL-200F D-cell batteries for the Intro to Space Camp flight. 10 of these batteries were ordered, but the company didn’t ship them in time for the flight; they arrived two days after launch. We ended up purchasing the same cells at BatteriesPlus (at twice the Amazon price) for that flight. This led to 10 extra batteries.

The batteries are Lithium Thionyl Chloride; they are very high capacity (16.5Ah), but have a very high internal impedance, yielding a low current draw. After the batteries were in my possession, I re-read the spec sheet, and it turns out that the max current draw is 200ma, 500ma peak. It was a simple oversight, but required a decent amount of redesigning to compensate for.

Here’s where the second problem comes in: I’m using linear voltage regulators. With my prior knowledge, I didn’t know switching regulators were an easy option, so I went straight for the LM350. With launch less than a week away, there isn’t time to swap to switchers. I’ve never built a circuit that involves switching regulators, and the Chinese eBay options are many weeks away.

So, all things considered, we’re flying batteries with a low current output and inefficient voltage regulators. The Pi draws exactly 400ma (measured from the input side of the voltage regulators). Because we have so many batteries, we’ll just fly two pairs (7.2V@200ma x2). The LM350 gives us a perfect 5v. The chemistry slips my mind at the moment, but there’s another form of Lithium battery commonly found in military surplus that can handle a very high current draw. We’ll be flying those and switching regulators for the next flight.


Since I found out that it was possible to modulate NBFM from GPIO pin 4 on the Pi, I had planned on running SSTV and APRS from that one “transmitter.” After further discussion and testing, it’s been determined that we shouldn’t use this for our transmissions. There are two main problems: signal quality and transmitted power. The power output is <20mW. Signal quality can be addressed by the fact that we’d be modulating FM from a 500MHz square wave. In the radio room, we were able to receive SSTV on frequency, at +/- 10KHz, 20KHz, and 30KHz. It would have been dirty to fly such a transmitter. We’re not ruling it out for future flights, but filtering and amplification is a must-have if we go that route.

For this flight, we’ll be flying two Baofeng UV-3R’s. One for SSTV, the other for APRS. The SSTV Baofeng will transmit some APRS for redundancy, but that’s only once every 3 minutes or so. Due to the nature of this project, I want to power the Baofengs from an external source, so I built some battery eliminators that seemingly resemble the original batteries with a cable coming out. I learned a lesson the hard way: don’t feed the Baofengs more than 4.2v! Anything more WILL fry the CPU. This particular lesson happened to be taught twice. The Baofengs will accept 3.4v to 4.2v. Anything less, it becomes a receiver. Anything more, it becomes a brick.


The telemetry side of things is slowly but surely coming together. It’s boiled down to these parameters: voltage regulator temp, internal temp, external temp, radio battery voltage, Pi battery voltage, Pi CPU temp, and altitude. Although pressure would be interesting, the sensors aren’t as cheap as the 1-wire thermal sensors, and I honestly don’t have the time to program it in with the launch being several days away.

For battery voltages we’re measuring values from an 8-channel, 8-bit TI ADC. I’ve built some resistor dividers to scale the voltages of 0-8.5v to 0-5v. This gives us a dynamic range that encompasses the typical battery voltages (7.2v). Programming the SPI interface wasn’t much fun. I learned a lot in the process, but I ended up bit-banging it with Python. Although not ideal, SPI is the perfect interface to bit bang with, since you define the clock in software.

Thermal sensors are basic 1-Wire devices from Maxim Integrated. I made the mistake of buying the parasitic power versions. Parasitic power allows you to charge a capacitor inside the thermal sensor by sending the high value from your GPIO pin. The thermal sensors then use this charge to make their measurement, and send it back to the controller. This sounds nice, but it’s a huge compromise on reliability. I’ve spent more time writing data quality check code than it’s worth because I keep getting 85 or 127 degrees as the values (both are invalid and suggest errors). Mouser didn’t have the regular type in stock. Next time I’ll just get it from Digikey. I will admit, it’s awesome that you can toss multiple sensors in parallel with eachother, and each one will be read individually. I literally have twisted pairs running through the box connecting these three sensors to eachother and the Pi.

Sending the telemetry is probably the easiest part. The format is simple: T#sss,aaa,bbb,ccc,ddd,eee,0000000. The a-e fields are the data values, these can be 0-999 (though the original spec says 8-bit, 0-255). sss is just a counter. It ensures that out-of-order packets are properly accounted for. 00000000 are 8 binary bits (say 0 for no GPS lock, 1 for lock). I’m not planning on using the binary portion. A typical packet should look like this: K5UTD-4>WIDE1-1,WIDE2-1:T#020,455,234,967,236,442,00000000. This is the 20th telemetry packet, and you can read the subsequent values yourself. It’s simple to form such a packet in Python.


Tracking was the first thing I did, and honestly the most stable code I’ve written for this project. At boot, the Pi launches gpsd for communications with the GPS. gpsd is a very versatile program, and even supports USB GPS systems. I did most of this testing with a Garmin eTrex Legend before I had the uBlox wired into the UART.

The Python code polls gpsd once per second, and writes an APRS position packet with that data to /tmp/position (yes, yes, poor practices, I know). This packet includes position, APRS symbol, altitude, and a comment (“RasPi Tracker Alpha”). Another script, bash this time, picks up the packet every 45 seconds. It runs the aprs command (part of python’s afsk library), which spits out a wav file. The command looks something like this: aprs -c K5UTD-4 -o aprs.wav ‘$(cat /tmp/packet)’. The next few lines of code toggle a GPIO pin, play the audio file on the left channel, and then turn off said GPIO pin.


High resolution imaging is coming from a Canon SX110IS. It’s an 8 year old point-and-shoot, but is perfect for this task. Luckily, it takes two AA batteries, so interfacing it to 4 AA Li-Ion cells was not difficult. Because I lacked wooden dowels, I soldered a lead onto the positive side of one (dead) AA battery, and another onto the negative side of another battery. I taped the opposing ends, and ran the two wires out of the battery bay to be connected to two pairs of AA lithium cells.

Low resolution imaging was handled by a $15 Fry’s webcam. Not all webcams are created equal, but fortunately this one was equal enough to have built-in Linux support. Some webcams are more equal than others, right? Anyway, fswebcam was the easiest choice for image collection. My single command tells it to wait for 30 frames to compensate for AGC, add a header with a title and subtitle, and a timestamp. All of this is sent to image.png, which the sstv binary takes and modulates into a Martin 1 wav file. From there, it’s sent to the SSTV Baofeng.


I think that covers all of the updates for now. I’ll post soon with more info as the launch approaches. We’ll most likely be launching on Sunday, August 16th somewhere in the DFW area.

Flight of the Leftovers?

As part of the Intro to Space Camp that I assisted with at UT Dallas, four balloons were purchased: two 1200g and two 600g Totex balloons. With the space camp, we launched one of the 1200g balloons, and “used” the other in a “learning experience.” So, presently, we have two 600g balloons and a size-K tank of helium.

Due to the complexity of the last launch, we’ve agreed to slim this one down. A lot. Here are our new goals:

  • Imaging. We want photos from the edge of space.
  • Telemetry. Temperature, altitude, and battery voltages are parameters we want to see.
  • Tracking. Recovery is imperative.

How do we go about doing this? With a Raspberry Pi of course! Back in June, I demonstrated SSTV transmissions using a webcam and GPIO pin 4 on the Pi. It was quite simple: take the picture, feed the png file to a program that pumps out a wav file, and then transmit the wave file using a modified version of the PiFM binary. The transmission is >10mW, possibly up to 20mW. I was able to key our on-campus repeater using a piece of RG-58 soldered onto the pin and a rubber duck antenna.


Although we’re still in the design phase, I’d like to fly two cameras: SSTV and Hi-Res. As mentioned above, it’s not difficult to run SSTV from the Pi. The higher resolution images would be taken from a “Point-and-Shoot” camera, probably a Canon with CHDK. I personally own a Canon SX110, and with our current budget, we’ll likely be flying a certain SX110.

At the highest resolution (9MP), the SX110 will hold ~1000 photos on a 4GB card. Why fly only 4GB? CHDK is limited to 4GB cards due to the nature of the bootflag that tells the camera to boot into the modified firmware. Cards larger than that require multiple partitions, and then partition swapping to take advantage of the higher capacities. 4GB is simplest. Although we’d like the flight to be rather short, planning on a 4 hour flight would be wise. When you do the math, it yields 15 seconds as being the ideal interval for getting 4 hours of photos.


Education has been a goal of this launch, and being able to get something out of this launch will justify the expense of helium, balloons, and payload. Pictures are typically the most interesting and flashy byproduct of these events, but telemetry provides useful data that can influence future designs. What are things we can measure using Commercial-off-the-Shelf parts (COTS) and send through the APRS network? Several things came to mind: pressure, temperature, battery voltages and altitude. I’m sure SparkFun sells sensors that can measure many more things, but for the purpose of this launch we should probably stick to just those.

What parameters exactly should we measure? Internal temperature, external temperature, and altitude are most important, in my opinion. Behind those come battery voltages, and finally pressure. In all honesty, I don’t really care about pressure. Sure, it’s interesting, but I’m not going to bend over backwards (or pay more than a couple of dollars) to fly a pressure sensor.


Oh, tracking. Tracking is easily the most complex part of any launch. There are many different ways to approach tracking, but for ease of reception, we’re going to narrow it down to “things that use the APRS network.” Although it would be fun to DF our way to the landing site, I’m going to opt to use the systems that will easily plot the balloons position on a GPS or aprs.fi.

On the last balloon launch, we flew a TinyTrak4 and a MicroTrak400. The TinyTrak performed flawlessly, and ultimately offered everything we needed to transmit position and telemetry. The only drawback to the TT4 is the price (yes, I am a broke Engineering student). $65 isn’t too much, but we’ve already determined that a Pi will fly. Maybe we can connect the GPS to the UART? What if we modulated the AFSK with the Pi, and pumped it out through the GPIO pin, like the SSTV?


Anyway, there are many things to consider. Budget is the main constraint. We’re not being funded by any group (aside from launch mechanics), and most of these things aren’t particularly cheap. Stay tuned for more info!

CASES GPS Receiver at Arecibo

One of my recent projects in the Upper Atmosphere and Remote Sensing Lab has involved the CASES GPS receivers. These receivers monitor the L1 and L2 GPS carriers, and can determine atmospheric anomalies from differences in the two carriers. The receiver itself is a Emdebian-based box with an SDR GPS receiver. When it detects oddities, it records an IQ file.

I was given the opportunity to place one of these receivers at the Arecibo Observatory. There were several constraints with regards to data transfer. Most importantly, the computers retrieving the data at the UT Dallas campus did not have public IP addresses, and Information Resources would not openly grant us a public IP. At Arecibo, the internet connection can be spotty, and a public IP is not guaranteed. With both constraints in mind, I opted to use BTSync to move the files from one box to the other. I used a Raspberry Pi to collect data (binary and IQ data) from the CASES box, and then relay the data to UT Dallas.

GPS Antenna

GPS Receiver & Pi

70cm Line Feed Antenna

Satellite Station at K5UTD

The K5UTD Amateur Radio Club satellite station is the first major project I’ve led since joining the club. I thoroughly enjoy satellite QSOs and the technical challenge behind the contacts, so it was only right for our shack to be one step closer to “complete” with a satellite station.

Several of the pieces were already at the shack, including an FT-847, Yaesu G-5400, and tons of Heliax. Some pieces were missing though: rotor control box, satellite antennas, and preamps. From a previous project, we had a GlenMartin RT-936 (8 foot tower) and the associated non-penetrating roof mount. After a few emails and phone calls, I was able to locate our antennas and the control box. Oddly enough, we went to pickup the control box and came back with nearly 4 van-loads of old test equipment and other radio-related gear. The stuff had just never been delivered to the shack, and if we wanted the box, the rest had to come. A generous professor donated a pair of ARR switched preamps for our station, taking care of the last piece in the puzzle.

Our antennas are believed to be KLM cross-polarized Yagis, but we’re not too sure. The markings have long since faded. From the antennas, we have about 25ft of Davis Bury-Flex into our custom preamp box. The preamps are ARR switching boxes, which feed about 200ft of 1/2″ heliax. The heliax terminates in our closet outside the radio room, and we finish the rest of the coax run with 30 more feet of Bury-Flex. Both runs terminate into a Yaesu FT-847, which is controlled by a Linux PC running GPredict. The G-5400 control box is interfaced to the PC with an Arduino running the K3NG rotor control software. All things considered, this is a fine satellite station, and we’re very fortunate to have the gear that we do.

With all of the pieces, we began assembling. Assembly BeginsLandon and Matthew mounting the Elevation rotor on the mast.

IMG_20140208_163513Our lovely preamp box.

IMG_20140209_143041And there I am doing some cable management.


Our satellite station in the shack.


And finally, the completed station.