Balloon 2.0 Begins

I'm building a new high altitude balloon payload and doing things differently this time. In my previous "hi-ball" adventure I followed the design plans and ideas of L. Paul Verhage, an experienced ballooner. But I failed to recover the payload due to a couple flaws in the design (or implementation of the design). I don't blame Paul. His book is extremely helpful and contains a wealth of information for anyone interested in the hobby. In my next effort I will continue to use his book as a resource.

However, having learned a few things from our first attempt I'm going to make a few changes. Changes to my design approach and changes to the on-board electronics.

First, the on-board electronics. I'm going to use an Arduino for sensors and data logging. For the sake of brevity I won't go into full detail about the Arduino or even the "fuss" many have over it in the hacker/microcontroller community. Instead I'll direct you to a recent post on Make that covers this topic better than I could. "Why the Arduino Won and Why It’s Here to Stay" by Phillip Torrone.

And if you're really interested, HackADay posted a counterargument titled "How the arduino won? This is how we can kill it" by Caleb Kraft. The replies on both articles are also worth reading through. I don't disagree with Caleb. In fact I'd like to eventually move on to try other microcontrollers as well. But for this project I think the Arduino is a good choice.

I like the Arduino for it's ease of use, cheap price, and huge user support base. The sensors and datalogger I'm using integrate nicely and very easily. And with its ease of use I'm hoping to inspire my kids to also give the Arduino a try. That last part isn't going so well though. Each time I show them my progress they just look at it and say "Oh." Either they just don't care about the build process or they look at all the circuitry and think it's way over their heads and they don't want to bother even trying to understand. I think I'd like to try out the graphical programming environment and see if that gets their interest. Also, I plan to use an Arduino for some automation in our up-coming chicken coop project, which also might catch their interest.

I also have some other plans for the electronics that I'll cover in later posts.

As for the design approach, I'm going to try to be more like the engineer I learned to be instead of simply copying others hoping that I'm understanding things, cutting corners, or doing a lot of guess work. Oh, I wasn't completely un-engineer like in my previous attempt. But there were a lot of unknowns that I simply shrugged my shoulders at and hoped it wouldn't be that big of a deal.

First step: get a baseline.



The container I'm going to use is an insulated shipping container from The Cheesecake Factory. I used some of the electronics destined for the payload to build a simple temperature data logger and put the whole thing into the freezer for 2 hours to see how well it performs without any modification.



From left to right we have:
OpenLog, datalogger from SparkFun (p/n DEV-09530)
OneWire digital temperature sensor from SparkFun (p/n SEN-00245)
9V battery
Arduino Duemilanove

After 2 hours I removed the package, downloaded the data, and charted the results. (Temperature readings are in degrees Celsius.)



The temperature inside the insulated box went from (24C) to the ambient freezer temp (-13C) in just under 2 hours. That is not an acceptable result. The payload will be in flight for over 2 hours in temperatures well below the freezing temp of the batteries (-40C) with an added wind chill. I need to keep the internal temp from reaching the external temp during that time. During the build process I'll be trying various modifications to improve this performance. Hopefully a few of the principles I learned in my heat transfer classes will come back to me and help me out.