Take a look at the plans in this issue of Model Rocket News. I'm probably going to throw one together before this weekend's high power launch so I can try it with plenty of room.

http://www.dars.org/jimz/mrn/mrn3701.pdf

__________________
Roy
nar12605

I knew I had seen some helpful threads here on this topic but couldn't seem to find the right combo of search terms.

Eagle3's posting led me to searching through Buzz's old postings, which led me to this thread:
http://forums.rocketshoppe.com/show...74&page=1&pp=10
Which led me to this link:
Buzz's Research on Booster Recovery

From that paper, it appears that there is enough pressure to rear deploy a streamer. Doug, where do your doubts about the feasibility come from?

The engine pod is interesting as well.

However, the thing that really got my brain churning was Buzz's suggestion of blowing off the whole tail cone. That would fit well in the theme of this model.

I'll have to change my plans a little bit, as the booster fins were going to glue to both the tail cone and the booster body tube, and now I'll need to leave them unattached to the booster tube, which means that the fins will go flying away with the tail cone, leaving a bare tube for the booster. I'll need to keep the tube and tail cone connected with a shock cord.

Now do I do a sort of engine pod with the tail cone as part of the pod. Pressurize an area in front of a solid centering ring, and use pressure against the centering ring to push the assembly out.

Or do a complete engine pod, eject the whole kit and kaboodle along with the tail cone, leaving a bare tube (with tube coupler at one end) dangling at the other end of the shock cord?

Or do I just vent to in front of the tail cone and pack layers as follows: tail cone, parachute/streamer, recovery wadding.

It seems like the third option might be difficult because getting adequate protection from the wadding in the space available could be tough. It will be a BT-60 tube and making sure that wadding is sufficient all the way around the stuffer/engine tube could be tricky, I think. Hmmmmm.

BTW, this model will be using 18 mm engines with a BT-60 body. My most likely engine in the sustainer, at least at first is an A8-5 or A8-3 because of the small field I have conveniently available. I really need to get up to Round Rock to scope out that park and/or sign up for AARG.

I'm glad I could help fill out your project queue. :-)

That was a very interesting read. More hmmmm. From a dearth of ideas, I now have several competing possibilities.

I've never done it before, so I'm naturally skeptical (I was once on a sales call at Cisco, and described design engineers as professional skeptics. The lead designer was amused. He could identify with that.)

Anyway, looking at Tim's open gap stager, I'm not sure how he recovers the booster (and the pic is presently blocked so I'm going off memory). But of the ways I've seen discussed over the years, many of them seem too risky. For example, I've heard of folks tucking the booster chute/streamer into the anular space around the sustainer motor tube. That strikes me as as good way to 1) fry the booster shock cord and 2) tip the sustainer way off course.

The more straight-forward approach of using the booster burn-thru to simultaneously light the sustainer AND deploy the booster laundry amounts to what we call in logic design a critical race. Since deployment is a relatively slower event than staging, I suppose that it might work, that the sustainer will light before the booster chute jerks the booster away. But by nature, I'm leery of having simultaneous events when sequential events are preferred

Nevertheless, before you buy into my hypotheticals, let's see what Tim says: How do you deploy the recovery on your booster, Tim?

Doug

.

__________________
YORF member #11

Just to keep Kody(Intruder) from getting mad at me, that's his Aerobee and my photography.

We were lucky that the booster with depleted motor was unstable and comes down with just enough tumble not to damage it. Things might change with a C6-0 and more room to stabilize itself. We'll just have to try it out and see. If it does come down fast enough to damage it, we will end up having to employ a recovery system.

Open air gap staging would be a pain to work with to deploy because there's no back pressure at all to work with. I have a feeling that we'd end up actually going more scale like with the booster and use a cluster of A10's. One would be ducted to a small recovery system, the others would ignite the upper stage.

Heh, if you can stand an off-topic story... Our software guys recently declared that resetting our chip was bringing the DRAM out of self-refresh. This means that the contents (data) of said RAM will soon decay (randomly fade away). Their solution was to initialize the DRAM controller really-really fast right after reset and before initializing anything else.

I pointed out that what they were doing was akin to racing a train across the tracks and they really needed to figure out *why* it was coming out of self-refresh. Your phrase "critical race" is probably more proper.

Fortunately, management agreed with my colorful terminology, I was instructed to reopen the bug, and the problem was found (in the software).



Tim and Intruder also have an interesting thread on gap staging about the rocket shown in those beautiful photos. However, since they use tumble recovery, I did not link to it in any of my posts.

I seem to deal with this much more frequently with my foreign customers than with my domestic ones. I suppose part of it is the language barrier. But much of it stems from the naive development strategies employed by emerging 3rd world electronics houses. They have a hardware team and a software team, who each develop their respective "stuff", then they go to the lab and pour the software into their black box, and when it doesn't work, they're about helpless.

In my past life, when we got to the lab, we wrote debug code to troubleshoot problems, then worked it back into the deliverable. We could crank out pages and pages of code in an afternoon of troubleshooting.

The guys I deal with now take days, weeks even, to crank out a few lines of test code to isolate a problem. The entire concept of how to get something working seems to be totally out of their grasp, as if it's some culturally derived paradigm of "it's not my job". (Sorry for channelling the late Freddie Prinze Sr.)

My take is that instead of the H/W guy sitting down with the S/W guy and figuring things out, the H/W guy has to write a memo to his boss who meets with the software boss who then writes a memo to the S/W writer who then cranks out three lines of code.

No wonder it takes the Japanese 7 years to get a new model to market, and 15 years to figure out how to build a mini-van

Doug...the more I deal with international customers, the more I love it here in America

.

__________________
YORF member #11

Officially, I'm a product/test engineer. However, because I'm custodian of the hardware diagnostic tests and producer of new ones, I seem to also be the Inbetween-Team.

When this bug first raised its head, my boss told me, "Go find out what they're (software guys) doing and see if you can reproduce it.".

So I go read the bug report, talk to the software guy in Texas (most of them are in California--foreign country) ask a couple of, "You're sure you're not doing this? You're sure you are doing this other thing?" questions. "Did someone change the development system such that the software now initializes the DRAM controller without you realizing it?"

Assured that my suspicions are unwarranted, I go write assembly routines which do what the software guys *say* they're doing in 'C'. No problem arises. The DRAM stays in self-refresh until I take it out. I report this in the Bug-Report and point to my code so the whole software team can see it.

"Are you *sure* someone didn't sneak in a DDR controller initialization somewhere near the reset command?" Heads shake.

Software guys think they've found a solution (the fast initialization trick). They close bug. My boss looks at it. Asks me a couple of questions. Tells me to go reopen bug.

Okay. More tests. Larger samples. I cut power to the whole chip while the DRAM (separate chip) is in self-refresh. Well this is interesting. The DRAM comes out of self-refresh after a power cycle of the chip's core power. Hmmm. Could be something, could be a red hering.

Okay, voltage regulator control line goes to a register in the FPGA. "Is your reset routine playing in the FPGA?" Heads shake. Okay, probably a red hering--must make time to look at I/O pad schematic because I/O pads are still powered when core goes down, and could be pulling CKE high, but that's not today's problem.

Finally, I get a board guy to solder a couple of tiny wires to tiny vias, we watch the signal between the chip and the DRAM on the O'scope. Going high is bad. I run my routines. It only goes high when it should--when the DRAM controller is active. We run the software guys' stuff. It's fine, it's fine, it's....ooops. what's that doing high? Software guy looks at it. Well, I was writing to this other controller, not that one. "Does your initialization routine initialize *all* of the controllers whenever you need access to only one of them?" Heads nod.

Problem solved. Sigh. I'm not quite sure why they needed to see it on the O'scope to finally think of where they had snuck in extra initializations, when I had asked them about it in a general way sixteen times. On the other hand, it's a very complex system, several people work on it and modify it, and it's hard for any one person to really keep track of all the stuff going on.

Still, I asked them, like sixteen times...

I'm not sure where that falls in your spectrum between hardware and software talking and working between bosses, but that's what we did, this time. The software team is really nice. But they've got a different way of looking at the universe and a desire for the tough problems to be in hardware rather than in their code.

They don't seem to understand two things:

1) It's a lot cheaper to fix the problem if it is in software.
2) If it's not on fire, it's a software problem.

Arrggghhhhh! I sat down to start piecing this booster together and checking sizing and such and realized that despite doing four or five parts orders in the last month, I don't have any CR-2060!!!! Arrrrgggghhhh.

Actually, they're in the Totally Tubular order, which is one of the last ones I placed, and I bet delivery is really slow because they're probably coming parcel post and the box is at least 34" long because of the tubes and larger boxes seem to take about two weeks by parcel post. At least I hope that's the reason, beause it's been about ten days since Jim emailed me that he was packing up the order.

Still, I only ordered 12 of them and didn't order any from BRS, BMS, Semroc, nor Uncle Mike. What was I thinking? I must have ordered at least 20 of every other centering ring in existence.

Must. Get. New. Brain.