I was showing my flight computer to one of my roommates, and as typical when I talk about my project and I have my flight computer handy, I like to point out the tiny tiny inductor we had to solder onto the PCB for the GPS. Today, however, I tried to point out the inductor, and noticed it was missing!

I could have easily knocked it off accidentally as I was struggling to connect the short antenna connector through the styrofoam wall to the flight computer. Knocking this out prevents power from getting to the antenna, and hence the GPS would have trouble seeing satellites! The problem seems to be the issue, but I won't know for sure until I fix the connection and test some more.

Full picture of the flight computer with the inductor after the break.

UPDATE: I connected the joint where the inductor used to be with straight solder, and we're now back up and running, successfully receiving a GPS lock. I think losing the inductor may have actually improved reception!

A fuller write up (and hopefully pictures!) will come soon, but here's the result of today's launch. Unfortunate, I know. We'll come back with chainsaws tomorrow. Hopefully tonight's rain doesn't affect the payload too much

Tonight we performed successful drop tests with two different size parachutes, an Orange 50" one that I had ordered a long time ago and a black 24" one that came with my Norad Pro Maxx kit. The above video shows our first test with the 24" parachute, and as you can see it is not very gentle on the payload. However, tabulating data from the tests shows that the descent rate of the 50" parachute should be slow enough to provide a reasonable ground track. Below are the first predictions for the ground track of hte initial balloon launch.

Quite conveniently, the balloon is predicted to land 10-15 minutes away from my house! Of course, it's only a predictor, and I've seen other projects where people land 20 miles away from the predicted landing spot. And with my newfonud knowledge that the data for the model gets updated every 6 hours I'm not holding on to any sort of hope that it will land in such a convenient location :)

Working late into the night, I was trying to prepare the flight computer and relevant systems for a range test. I'd had poor results in earlier tests, and made the call that we would not launch if we could not get at least 1 mile of range on the radio.

But we never got as far as the range test. We had components outside, we were moving to the cars, when suddenly I noticed the flight computer had stopped transmitting. The transmitter was still on, but it wasn't doing anything. I re-uploaded the sketch to no avail.

Finally we went back inside and I did some more debugging. The SD card library that had been supposedly fixed for chipkit processors was having problems. After a file got too big, it would hang when trying to write, and stop the whole show. I looked at the data on the SD card and saw that the last time data had been recorded had been 30 minutes ago, despite the fact the flight computer was on the whole time.

Trying to fix the issues by switching flight computers led to damage to the SD card shield that we surprisingly weren't able to repair, even with the most primitive methods. Another decision I had made is that we had to log flight data to the onboard SD card. In the event the radio communications broke off, but we managed to find the payload either via the cell phone backup or some good samaritan finding it and calling us, I wanted to know the ground track of the balloon and the max altitude it achieved. This would help indicate how accurate the predictions were, and that seemed important enough to me.

So we're not able to launch the balloon, but the preparations to do so certainly got me closer to launching than I've been yet. The flight box is pretty much assembled, and it weighs about 2.5 lbs without batteries, comfortably under the FAA 4lb limit for such payloads. The flight computer has matured from breadboard to protoshield, and the code, while still having issues, is coming along. Most of the materials are in place, now we just need a new opportunity.

The rest of this post has some more details on the other tasks on which we made progress and the errors we faced.

Over the past couple weeks I've been making progress in directions I did not see myself going until, well, the past few weeks.

I ran into an issue in that I was running out of RAM for my Arduino program. Someone told me about this chipkit boards that were arduino compatible and had 8x as much RAM, so I sprung for one. Then I found that two of the libraries I was using for my program were not compatible with the new chipkit. One of the libraries inverted the signal from the Garmin GPS 18x LVC unit I was using. To invert it now, I would need to put a MAX232 chip on a Printed Circuit Board (PCB). I figured, while I'm making a PCB, I might as well use the old Inventek GPS I got back in November. Bill French (from FUBAR labs) and I made the PCB and got the GPS working using the toner transfer method in just 3 hours after I finalized the design. In the picture above you see the board.


Shortly afterwards, I finally managed to get the NTX2 transmitter properly hooked up to both Arduino and the chipkit board. Very ironically, I then discovered that the other incompatible library was SD.h, which is what I was using to write to the SD card (to store data onboard in case radio transmission failed). It's ironic because I wanted a board with more RAM so that I could increase the size of the buffer I was using to write to the SD card :-/

The good news is that the company that makes the chipkit boards supposedly has someone working on making the library compatible, and I was told this morning that changes are going to be uploaded soon. Hopefully those fix the issue.

This is where it starts to get exciting

I've been spending lots of time on the flight computer this week. A kindly gentleman on the Arduino forums also pointed me to the TinyGPS library, which parses GPS data. It checks the data too, to make sure there are no weird sentences!

This is a figure of altitude data from the GPS sensor. I managed to take it with me on a flight out to the midwest where I was meeting some friends, and I was really excited to be able to get such data.

Then I saw the same picture you're looking at now. The readings, while managing to capture the "gist" of what was going on, had errors in a number of places. All throughout the flight, readings were bouncing around between the true altitude and something else. As a matter of fact, that picture even has some data reduction methods applied to it already via throwing out values above 15000m.

The GPS lost signal as the plane took off, but thankfully managed to reacquire signal it reached altitude. All the way through, however, the data was mangled. Sentence were cut short, or smashed together with other sentences. Sometimes the decimal point in the altitude reading simply got lost, nowhere to be found.

After implementing a bunch of data filters in MATLAB, I was able to improve the output significantly:

I know I promised an update last week but I ran into an unexpected opportunity to test out the GPS system and I've been busy working the analysis on that. So in return for no post last week there will be a more interesting post this week!

I'm back! Sorry to my readers (both of you) that I haven't posted in 3 months. Schoolwork got to be pretty intense and my dorm room was not really the best workshop. I'm now at home in NJ for a couple weeks before my summer internship starts and have oodles of free time to work on Project HAL!

I realized, after making that "thing" out of a construction tube and some balsa/plywood (see this post) that I had to rethink my design entirely. I'd also read that even though anybody can fly G class motors without a license, flying four of them at a time wasn't exactly a shortcut to more power with less paperwork.

So I went back to the drawing board and took a look at what a system with only one rocket motor would look like. Details after the break.