BALLS

[JimJarvis50]

Great movie Tony. You said you couldn't see at the point where you recovered your rocket. Just in case you didn't realize it, we were just down the road from you and we were able to enjoy your moment of discovery. Nice rocket and nice flight!

I have one more update to offer on my flight. This will probably be it unless the rocket is found. There are several of us looking at the gps file and I think we have reached a consensus on at least part of what happened. The data from two separate gps units are shown in the graph below. It includes the on-board gps data from an 18mw BRB unit (the red diamonds) and the separate telemetry from a 100mw BRB unit (the black squares). The 100mw unit is a prototype from Greg with a uBlox chip, and I think the unit will be a hit. The data can be superimposed, which I think provides more assurance that the data around apogee are correct.

By slightly changing the simulation (reducing the Cd a little) we were able to fit the simulation to the gps data collected PRIOR to apogee. By "fit", I mean we were able to match the time, altitude and calculated speed of the gps data. The revised simulation suggests that the final altitude should have been 111,000 feet (a bit higher than my 98K estimate prior to the flight, which was based on exactly zero actual data at these altitudes). This simulation, which I think represents the best representation of the "up" part of the flight, is shown as the blue line in the figure.

At 97K feet, there is a 12-second gap in the data. We now believe that this is where the apogee event occurred. According to Adrian, 97K AGL at Black Rock gives an air pressure (0.01 atm) that exactly corresponds to the lower pressure range of the barometric sensor in the Raven. We suspect that when the altimeter reached this limit, it fired the charge. Please note that this does not represent a problem with the altimeter, and it remains to be verified that the altimeter actually operates this way when the range is exceeded. The problem was that it appears that the flight was going to go higher than I expected. Had we known that, we would not have tried barometric detection at apogee. Lesson learned.

At the suspected deployment point, the rocket was traveling at a speed of 1,100 ft/s. Although it's been pointed out that the air is pretty thin there, that's still a pretty good rate of speed. Unfortunately, we can't piece together why the rocket came apart. Perhaps it will be found at some point and we will find out what happened.

All things considered, I'm pleased with the flight. I managed to get at least one piece of space junk above 100K AGL using a rocket with home-rolled tubes and without sponsors (although I certainly had lots of good help!). Every aspect of the trip and the launch went exactly as planned (except for the coming apart part), and we were even able to accelerate the flight by a day to try and hit the best weather. And I have at least one movie that shows the flight and how the rocket managed to survive a pretty bumpy Mach 2+ ride through the jet stream. Dang, I'd like to find that rocket though.

Jim

[Ethan]

Nice job Jim. What receiver setup did you end up using for the flight?

[jsdemar]

That's some good detective work there, Jim.

At Mach 1 at 100Kft, there's a dynamic pressure of about 0.2 psi. Not much pressure to cause something to break upon deployment. It's also very cold there (about -50 F or C, take your pick). Is one minute long enough to cause a temperature affect in the electronics or materials? Don't think so, except for the baro sensor which will report a lower pressure than actual. It may have triggered separation earlier than you think and it took some time to tumble and lose GPS lock. Do you have logged accelerometer data? That would show the tumbling.

No matter what happened, it was an amazing flight. Team of one, no sponsors, hand-made composite airframe, only a pair of commercial N motors.

One way to get back the whole 2nd stage is to "do it again"!

[Burner]

The problem was that it appears that the flight was going to go higher than I expected. Had we known that, we would not have tried barometric detection at apogee. Lesson learned.

Out of curiosity, why did you change the default setting and use baro for apogee deployment on the raven?

[JimJarvis50]

Nice job Jim. What receiver setup did you end up using for the flight?

I had two setups. One was a Yaesu VX8-GR with an Arrow Yagi and the other was a mobile Kenwood (don't know unit) with an eggbeater antenna. The data from the Kenwood system was interfaced with a PC for real-time display on a map.

Jim

[JimJarvis50]

Out of curiosity, why did you change the default setting and use baro for apogee deployment on the raven?

I did not change the default setting (at least I don't think I did). The Raven has default selections for both barometric deployment and accelerometer deployment. I used both, but added a delay to the accelerometer-based deployment (we were concerned about cumulative errors in the calculated velocity). It's possible I might have tweeked one of the default values (as opposed to the default approach).

I think we were basically trying to decide which of the two non-ideal approaches we should take. With a better simulation, I could probably use a timer-based backup approach. I'm also curious if the tiltmeter approach would work (where instead of inhibiting staging above a certain angle, it would instead permit an apogee event). Any ideas along this line are welcome.

Jim

[JimJarvis50]

That's some good detective work there, Jim.

At Mach 1 at 100Kft, there's a dynamic pressure of about 0.2 psi. Not much pressure to cause something to break upon deployment. It's also very cold there (about -50 F or C, take your pick). Is one minute long enough to cause a temperature affect in the electronics or materials? Don't think so, except for the baro sensor which will report a lower pressure than actual. It may have triggered separation earlier than you think and it took some time to tumble and lose GPS lock. Do you have logged accelerometer data? That would show the tumbling.

No matter what happened, it was an amazing flight. Team of one, no sponsors, hand-made composite airframe, only a pair of commercial N motors.

One way to get back the whole 2nd stage is to "do it again"!

Yes, we're still not sure why things were not all together. I don't think we'll be able to figure that out until the bottom of the sustainer (containing the altimeters) is found.

Try it again!? That would be insani.... OK.

Jim

[mikec]

Out of curiosity, why did you change the default setting and use baro for apogee deployment on the raven?

I think the default setting in FIP was changed to barometric with accel-based mach inhibit after some problems with out-of-spec accelerometers caused early deployments with the old default.

[Adrian A]

Is one minute long enough to cause a temperature affect in the electronics or materials? Don't think so, except for the baro sensor which will report a lower pressure than actual. It may have triggered separation earlier than you think and it took some time to tumble and lose GPS lock. Do you have logged accelerometer data? That would show the tumbling.

The baro sensor in question has an internal temperature sensor (it's actually the same silicon as the pressure sensor, wired up differently) that ensures that the pressure output reading is unaffected by changes in the sensor temperature. Each sensor is individually tested and calibrated at a range of temperatures at the chip factory, with calibration coefficients programmed in that I read when the altimeter boots up.

Ambient atmospheric temperature does affect the pressure-to-temperature conversion, but that's baked into the standard atmosphere model that the Raven uses. If the ambient temperature is warmer or colder than what the standard atmosphere assumes, that does affect the absolute accuracy. It would not cause the altimeter to think it was going down when it was really going up, however, and there weren't any altitude thresholds used in the deployment logic, other than the low altitude check for the main deployment.

[Adrian A]

Yes, we're still not sure why things were not all together. I don't think we'll be able to figure that out until the bottom of the sustainer (containing the altimeters) is found.

Try it again!? That would be insani.... OK.

Jim

Glad to hear it! Replacement Ravens for the next flight are on me, if you want them. I'm making my BALLS 2012 plans, also.

[troj]

Jim, I love the synopsis of your findings -- great info, and stuff that others who want to follow in your footsteps can learn from!

-Kevin

[Adrian A]

I think the default setting in FIP was changed to barometric with accel-based mach inhibit after some problems with out-of-spec accelerometers caused early deployments with the old default.

That's correct, along with the fact that I've found over the years that the barometric apogee detection is just more robust to a wide range of uncertainties in the flight. Coning and weathercocking can add errors to the accel-based apogee detection, too. The first altimeter that I made, the Parrot, had a baro sensor that was susceptible to RF inputs from trackers, which was part of the original motivation for accel-based apogee detection as the default. RF susceptibility isn't an issue for the Raven, so I made the change so that more users would have more accurate apogee detection.

For Jim's flight, since both types were wired up, we may never know for sure which one fired early. However, running some quick calculations it looks unlikely that the accel-based apogee detection could have been that far off, especially since Jim put a 5-second delay on that event at my recommendation. So if I had to guess it would be that the baro apogee detection went off on the way up at about 98,000 feet. I don't currently have vacuum equipment that can simulate those conditions, so I have not tested to find out what the sensor does once the pressure drops below the 10 mbar specified operating range for the part. I do know that others have tested to the equivalent of > 70,000 feet without an issue. I was hoping, and frankly expecting, that the altimeter output would continue to be well-behaved below 10 mbar so that it could reliably be used to detect whether the pressure is increasing or decreasing, even if the absolute accuracy suffers. But I don't know yet whether that is the case for this sensor. I'm working on improving my test equipment so that I can test this out.

[jsdemar]

The baro sensor in question has an internal temperature sensor (it's actually the same silicon as the pressure sensor, wired up differently) that ensures that the pressure output reading is unaffected by changes in the sensor temperature. Each sensor is individually tested and calibrated at a range of temperatures at the chip factory, with calibration coefficients programmed in that I read when the altimeter boots up.

Ambient atmospheric temperature does affect the pressure-to-temperature conversion, but that's baked into the standard atmosphere model that the Raven uses. If the ambient temperature is warmer or colder than what the standard atmosphere assumes, that does affect the absolute accuracy. It would not cause the altimeter to think it was going down when it was really going up, however, and there weren't any altitude thresholds used in the deployment logic, other than the low altitude check for the main deployment.

From my experiences with temperature compensated sensors, they become quite non-linear and not necessarily monotonic at the extremes. The linearization (or error margin fit) is done at mid ranges of temperature and pressure. Depending on the numerical methods implementing the standard atmosphere at the low pressure, and the sensor response to thermal shock, and possibly at Mach transition, I could imagine a series of reading with an inflection to fool the apogee detection. Also, at the low end of the sensor reading, noise from vibration and RF could get integrated in.

[jsdemar]

Yes, we're still not sure why things were not all together. I don't think we'll be able to figure that out until the bottom of the sustainer (containing the altimeters) is found.

Try it again!? That would be insani.... OK.

Jim

Ahah... the acc data are in the missing half. Darn it.

Any possibility the top came off due to pressure differential once the speed decreased enough to reduce the pressure on the cone? Vent holes? Shear pins? Any sign that charges went off?

OK, I'll stop thinking about it.

[JimJarvis50]

Ahah... the acc data are in the missing half. Darn it.

Any possibility the top came off due to pressure differential once the speed decreased enough to reduce the pressure on the cone? Vent holes? Shear pins? Any sign that charges went off?

OK, I'll stop thinking about it.

Well, there were vent holes, but they can always get blocked. With the amount of time to apogee (1.5 minutes), I would think even a blocked vent would let enough air out. With the heavy cone I mentioned before, I went to the heavier #4 nylon screws for shearpins. I use a piston (and a D-bag), so there's no way to tell what the charges did or didn't do.

Jim

[JimJarvis50]

Glad to hear it! Replacement Ravens for the next flight are on me, if you want them. I'm making my BALLS 2012 plans, also.

I'll take you up on that. Thanks! Once I figured out how to use the logic, the way the staging could be done (by setting a velocity) was exactly what I wanted.

Jim

[Burner]

That's correct, along with the fact that I've found over the years that the barometric apogee detection is just more robust to a wide range of uncertainties in the flight. Coning and weathercocking can add errors to the accel-based apogee detection, too. The first altimeter that I made, the Parrot, had a baro sensor that was susceptible to RF inputs from trackers, which was part of the original motivation for accel-based apogee detection as the default. RF susceptibility isn't an issue for the Raven, so I made the change so that more users would have more accurate apogee detection.

For Jim's flight, since both types were wired up, we may never know for sure which one fired early. However, running some quick calculations it looks unlikely that the accel-based apogee detection could have been that far off, especially since Jim put a 5-second delay on that event at my recommendation. So if I had to guess it would be that the baro apogee detection went off on the way up at about 98,000 feet. I don't currently have vacuum equipment that can simulate those conditions, so I have not tested to find out what the sensor does once the pressure drops below the 10 mbar specified operating range for the part. I do know that others have tested to the equivalent of > 70,000 feet without an issue. I was hoping, and frankly expecting, that the altimeter output would continue to be well-behaved below 10 mbar so that it could reliably be used to detect whether the pressure is increasing or decreasing, even if the absolute accuracy suffers. But I don't know yet whether that is the case for this sensor. I'm working on improving my test equipment so that I can test this out.

Ah that makes sense. I asked because I have over 30 flights on my first generation Raven, all used accel data for apogee and all were right on time.

[Adrian A]

Testing I did today with an upgraded vacuum setup revealed a bug in the Raven's conversion of pressure to altitude for altitudes over 65600 feet. See this thread for more details. So it looks like what happened with Jim's flight was at 65,617 feet, the onboard baro altitude went crazy, and then the only thing preventing the baro apogee and both main charges from firing was the 400 feet/second Mach inhibit. That inhibit apparently went away at 98,000 feet, allowing both main chute charges to fire at approximately the same time. That plus the chute deployment at about 1000 feet/second (accumulated accelerometer error) broke the Kevlar shock cord.

[JimJarvis50]

Yep, we confirmed that there was a problem with the altimeter. One other thing we learned is that in addition to the apogee charge, both mains went at the same time. Although the mechanism of the separation is still a bit fuzzy, having an apogee and two main charges go off at the same time while traveling 1,100 ft/s probably isn't going to end well.

I know Adrian feels badly about this, but the fact is that I have the responsibility to make sure my electronics work for my flight profile. I didn't do that and it bit me. If i do this flight or something like it again, I'll most likely be using Ravens to do it.

Jim

edit - actually, it is more likely that one altimeter went off before the other. Therefore, at 98K, there would have been either a main event only, followed by an apogee event later, or there would have been a simultaneous apogee and main event, depending on which of the two altimeters fired first.

[jsdemar]

Depending on the numerical methods implementing the standard atmosphere at the low pressure [...] I could imagine a series of readings with an inflection to fool the apogee detection.

OK, what do I win? ...

[Adrian A]

OK, what do I win? ...

Sorry, no prize for incorrect guesses. This had nothing to do with numerical methods or fixed-point arithmetic or polynomial approximations, or inflection points. The full standard atmosphere equations, calculated with full 32-bit floating point ANSI-C library functions for exp() and pow() are used in the Raven's firmware. That model is well-behaved at the layer transitions. The subtle things you had in mind were already taken care of. The premature deployment was caused by a typographic error in the source code, pure and simple. The bug has escaped detection for this many years simply because until now, nobody has flown a Raven above 65,617 feet. (Also, my vacuum pump didn't suck enough during testing. I have a suckier vacuum pump now.) There isn't anything subtle about it. When Jim's rocket was in ambient pressure equivalent to 65,616 feet the Raven calculated the altitude correctly, and at 65,618 feet it thought it was underground. It only waited to fire Jim's charges until 98,000 feet because that's how long it took for the velocity to be under the Mach inhibit threshold of 400 feet/second.

[jsdemar]

Sorry, no prize for incorrect guesses. This had nothing to do with numerical methods or fixed-point arithmetic or polynomial approximations, or inflection points.

Leaving out a negative sign could be considered a numerical method.

All kidding aside, that's some good detective work. And it's a testimonial to full coverage testing for software verification.

I assume you aren't done with your testing. As I mentioned before, it's very common for noise to get injected and integrated when operating a sensor near it's low limit. A major source of noise is an RF transmitter. This problem could have been masked by the bug you just found.

[bob mappes]

Sooo...Is anyone going to respect Kevin's request?

I will....Here's a vid of the beer keg rocket.


http://www.youtube.com/watch?v=Cc1dsJDOp-U

I really hope the beer was okay. If the beer were trashed that would make this a truly tragic flight.

it appears to me (as a very novice L1 rocketeer) that the beer keg rocket knew exactly what to do after it cato'd......it went in the safest direction to burn off all residual propellant before returning to it's resting place on the ground. And it did it in extraordinary fashion!

Well done Beer Keg Rocket

[FredA]

it appears to me (as a very novice L1 rocketeer) that the beer keg rocket knew exactly what to do after it cato'd......it went in the safest direction to burn off all residual propellant before returning to it's resting place on the ground. And it did it in extraordinary fashion!

Well done Beer Keg Rocket

It wasn't so much of a CATO, but the disintegration of the nozzle.
The case, snap rings and nozzle washer were intact....although the washer was a little fried after acting as the nozzle.
It was surprising how much thrust the motor made with a net 4-inch nozzle.

We are sure are glad it had enough power to clear the flight line....a real "pucker" moment for the team for sure!

[Thermo]

Um...ahh...has anyone got a link to Dave L's "pink rocket" CATO? I saw a video of that at my NAR meeting a couple hours ago, definitely the most interesting thing I saw all evening....

[troj]

Um...ahh...has anyone got a link to Dave L's "pink rocket" CATO? I saw a video of that at my NAR meeting a couple hours ago, definitely the most interesting thing I saw all evening....

The best place I know to get it is to buy the BALLS DVD.

At $16 ($20 for Blu-Ray), it's definitely worth it. Neil and Bob do a great job.

Not to mention, supporting them by buying DVDs helps keep them coming out and documenting what we do!

-Kevin

[Thermo]

Thanks Kevin!

-Thomas