Dr. Shaun Ramsey
If you’ve noticed KB3ROH-11 on http://aprs.fi, you can see that we’ve launched! Finally!
Videos and pictures, and news of the pending retrieval mission, will follow shortly.
We’ve finished our ten weeks for the summer, and the balloon still hasn’t been launched. That doesn’t mean we’re won’t launch, however. We’re extremely close to being ready!
Our payload currently reads the GPS, temperature, pressure, and humidity from the appropriate sensors, converts that data into an APRS sentence, converts that sentence into an AFSK that is fed into our SRB MX-145 which then generates our signal. This signal is radiated by our quadrifilar helix antenna. With a basic dipole for the 2 meter band, we’re able to receive and decode our signal with a 2-meter transceiver and our computer’s sound card. That means it works!
Unfortunately, there are still problems. We tried decoding our signal with a different computer, and it didn’t work. Thanks to some help from Bill N3DOU and the Physics Department, we’ve determined that our audio signal is too strong. We worked on attenuating it, but ran out of time.
Don’t worry, though – the balloon will still go up! We’ll figure it out when we reconvene at the start of the school year. Even if we did get that last bug smoothed out, we would have postponed the launch until the start of the school year anyway, so that everyone who wants to see it can schedule for it.
We’re still working on the electronics required to radio live telemetry back to earth. Fast Scan TV may be our best option for video, but it won’t be optimal. Our HD camera is digital, but Fast Scan Television equipment uses is designed for analog cameras, and transmits a far less than HD analog signal. There hasn’t been much progress in Amateur Radio towards adopting newer digital television standards, particularly ATSC, which is the North American digital television standard. Most experimentation has been with DVB standards, which consumes less bandwidth, but is primarily used in Europe and can’t be natively received by modern televisions intended for the North American market.
We’ve been experimenting with Arduinos and a Raspberry Pi. We can use an Arduino to read data from a couple sensors, and are working on building a prototype that can be used to accurately calibrate the barometer. We’re still working on the Pi; we need to order a cable so we can keep the header pins intact.
We’ve also been experimenting with developing an app for Android. It’ll have pretty graphics and be able to access the telemetry as it’s posted on the Internet. This should be extremely helpful when trying to track the balloon.
Helium has gotten more and more expensive in the past several years because it is becoming increasingly scarce. Beyond the cost, there are some scientific processes for which there is no substitute to Helium. We just need a lift gas, and Hydrogen is cheap and readily available. That said, it’s very flammable.
After several hours of research and careful consideration, we are confident that we would be able to use Hydrogen safely. However, Washington College is an open campus. Hydrogen’s flammability requires us to fill the balloon outside, and there isn’t anything stopping somebody from igniting our inflating balloon for fun. While we are able to control the substance, we simply cannot account for stupidity. So, for liability reasons, our laboratory safety director has decided that we need to use Helium in our project.
Better safe than sorry!
We decided that the growing number of people interested in our project would like to get regular updates on our progress. So we started this blog.
I plan to post at least once a week. We’ve been doing this full time May 20th, so this post may be unusually long and terse.
This project was created in a brainstorming session that happened before the end of the Spring 2013 semester. Out of all the project ideas, this one was the most exciting. We chose it because this was going to be a 10 week project, so enthusiasm is critical, especially when we are learning about and doing things we’ve never done before. So far, sustaining interest has not been a problem.
At the beginning, we researched different microcontrollers, eventually settling on Arduino and Raspberry Pi as potential platforms off which we’ll build our payload. None of us had very much experience with microcontrollers (if any) and we’re interested in seeing how close to the hardware we can get in a Linux OS environment.
Once we ordered those (a list of what we’ve ordered so far), we researched weather balloons in general. This included FAA regulations (which are terribly hard to understand), balloons, lift gases, sensors and linux system administration.
Our understanding of the FAA regulations (linked above) includes that the payload cannot weigh more than 12 pounds, and any individual package in the payload cannot weigh more than 6 pounds. Furthermore, any package cannot have a weight to size ratio of more than three ounces per square inch. This means that, if the smallest side of the package had to support the full weight of that package, there can’t be more than three ounces per square inch spread across that side. This is to reduce the possibility of serious injury, should someone be struck by the payload on it’s descent.
Weather balloons are typically latex. They have a rated burst diameter, which is reached at their maximum altitude. When they’re launched, they’re only filled part of the way. As they rise into the sky, they expand as the atmospheric pressure around them decreases.
For lift gas, we decided to use Hydrogen. This was after extensive research into the safe usage of the element, as it is very flammable. (It can ignite in concentrations ranging between ~4% and ~75%, while gasoline only ignites in concentrations between ~4% and ~8%.) Since we’re using it outside, a lot of the risks are significantly reduced, especially when there’s a flashback arrestor on the tank, as that would prevent the tank from becoming a bomb, even if the gas in the balloon and the feed line ignites.
For sensors, we decided to get a thermometer, barometer, hygrometer, GPS and hd camera. The barometer can be used as an altimeter, following some onboard calculations. The GPS had to be functional beyond 60,000 feet – a limit imposed by the U.S. federal government on all GPS units that can track at speeds faster than 999 knots. This limitation is to prevent consumer GPS modules from being used in missiles.
System administration was something that we decided to learn because we wanted to have a server that we could use to share code and host our real time data publishing platform, once it’s developed. We talked with OIT about getting a virtual private server, and they kindly gave us one.
Currently, we’re trying to figure out the details of the link between the weather balloon and the ground. We’re planning on using Amateur Radio, specifically the Automatic Packet Reporting System and (hopefully) Fast Scan Television. We’ve contacted many operators, including the Kent County Amateur Radio Society and Dwayne Kincaid, WD8OYG, from LDG Electronics. Thank you all for your help!
We’re also working on being able to submit our data to the NOAA‘s NCDC. We want the data that we collect to be available for use by any meteorologists who want to use it. My neighbor, Mike M., used to work at NOAA, and is putting us in contact with the right people there.
If you have any questions or would like some more details, please feel free to leave a comment or send me an email at iegland at washcoll dot edu.