Post your Raven FIPa files here

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Here is a FIPa file from my Comp 3 flight at XPRS this weekend on a K540M. It seems to show that the main pyro channel did not fire because the Velocity < Vel1 = 400 ft/s criterion was false at AGL = AGL1 = 704 feet. No worries though, the backup altimeter fired fine at 500' just like any good insurance policy should. This is the configuration.
View attachment 184509

I know there is no velocity measurement on descent. Isn't velocity considered effectively zero so that Velocity < Vel1 is true? The Apo channel fired fine. Then Velocity < Vel1 criterion toggled false during the descent at about 6,109', toggled back true at 6,070' and finally toggled back false at 6,020' remaining false for the rest of the descent. The accelerometer data looks normal through out the flight.
View attachment 184510
 
Here is a FIPa file from my Comp 3 flight at XPRS this weekend on a K540M. It seems to show that the main pyro channel did not fire because the Velocity < Vel1 = 400 ft/s criterion was false at AGL = AGL1 = 704 feet. No worries though, the backup altimeter fired fine at 500' just like any good insurance policy should. This is the configuration.
View attachment 184509

I know there is no velocity measurement on descent. Isn't velocity considered effectively zero so that Velocity < Vel1 is true? The Apo channel fired fine. Then Velocity < Vel1 criterion toggled false during the descent at about 6,109', toggled back true at 6,070' and finally toggled back false at 6,020' remaining false for the rest of the descent. The accelerometer data looks normal through out the flight.
View attachment 184510

It looks like this was a side effect of the way the Raven does the Mach speed lockout. The velocity is estimated on-board throughout the flight. Normally, the on-board velocity estimate is around 0 at apogee, and then with a typical configuration with the drogue chute behind the av-bay, the av-bay flips upside down during the drogue descent such that the chute drag causes negative Gs, driving the on-board velocity estimate rapidly downward. But even if the drogue is above the av-bay or the main chute deploys, the average measured Gs during the descent are around 1, and the since the Raven subtracts off the pad readings for acceleration throughout the flight, so the velocity estimate stays around zero and doesn't cause a problem. In your case, something was causing 1-3 Gs of measured acceleration throughout the descent, and so the velocity estimate kept going up and up, triggering the mach lockout, unfortunately before the main altitude was reached.

Did you have a drogue chute mounted above the av-bay? A vent hole can be pretty effective at reducing coning, along with balancing the shroud lengths.
 
It looks like this was a side effect of the way the Raven does the Mach speed lockout. The velocity is estimated on-board throughout the flight. Normally, the on-board velocity estimate is around 0 at apogee, and then with a typical configuration with the drogue chute behind the av-bay, the av-bay flips upside down during the drogue descent such that the chute drag causes negative Gs, driving the on-board velocity estimate rapidly downward. But even if the drogue is above the av-bay or the main chute deploys, the average measured Gs during the descent are around 1, and the since the Raven subtracts off the pad readings for acceleration throughout the flight, so the velocity estimate stays around zero and doesn't cause a problem. In your case, something was causing 1-3 Gs of measured acceleration throughout the descent, and so the velocity estimate kept going up and up, triggering the mach lockout, unfortunately before the main altitude was reached.

Thanks for the follow-up and teaching me something new. Having looked at some other Raven 3 flight data I can now see the descent G's are positive and significant in this one.

Did you have a drogue chute mounted above the av-bay? A vent hole can be pretty effective at reducing coning, along with balancing the shroud lengths.

This Competitor 3" flight was standard DD with a 24" vented drogue (Giant Leap Hemispherical) below the AV bay. The centripetal force from coning seems a likely explanation for the sustained axial Gs. Not something I would think of, but it makes perfect sense. What I don't understand is how that force would be seen as positive Gs by the accelerometer. The descent rate with this configuration is 60 fps, so I would not want to go much smaller on the drogue. The drogue was tied almost 6' from the AV bay. That's a little far, I know, but I was trying to avoid burning the drogue with the backup charge. The shock cord to the AV-bay and booster below the drogue was quite twisted at recovery. Centripetal force would have increased as the cords shortened, making he axial G problem worse. I am picturing the booster and AV-bay in an almost flat spin pulling against each other under the drogue. I have seen this sort of thing looking at in-flight video of other DD flights. Having the drogue closer to the center of mass of this rotating system meant less dissipation of the spin velocity. The mitigations that come to mind are to attach the drogue closer to the AV-bay with a Nomex / Kevlar blast shield over the back up charge and to use an even longer shock cord.
 
Last edited:
Maybe you got really unlucky and had the front end of the rocket get tangled up in the drogue harness at deployment, such that the nosecone was toward the center of the circle when it started coning? If the rocket was coning in a regular stretched-out configuration with the av-bay toward the center of the rotation, the Raven would have seen negative Gs. Very unusual situation.
 
Maybe you got really unlucky and had the front end of the rocket get tangled up in the drogue harness at deployment, such that the nosecone was toward the center of the circle when it started coning? If the rocket was coning in a regular stretched-out configuration with the av-bay toward the center of the rotation, the Raven would have seen negative Gs. Very unusual situation.

Thanks again for the follow-up. This is quite a head scratcher considering that the same positive axial Gs were present during descent on the previous (and 1st) flight (FIPa attached). In that flight, the velocity < Vel1 criterion toggled a couple times, and then remained asserted so it did not inhibit the main. There was no apparent tangling at recovery. Everything came down nice and orderly so any tangling had sorted itself out by the time the rocket landed. The required tangling to cause positive Gs being unlucky as you said, it seems that something else more repeatable is happening to cause the positive axial Gs. Next time I will get some on board video.

A wild conjecture, but if there was a vibration could that somehow get aliased into positive Gs by the accelerometer sampling?

EDIT. After staring at the axial and lateral accelerometer data for these two flights, the only logical explanation I can come up with is that the AV bay / payload / nose cone assembly (45" long and ~4-5 lbs) was itself spinning during descent. That would be seen as positive Gs by the Raven 3. If this were the case, attaching the drogue closer with a nomex blast shield to protect it from the secondary should help dissipate the rotation.

View attachment 185312
 
Last edited:
Anyone want to look at my most recent flight?

During the flight the rocket had a pre-mature breakup. Luckily the parachute came out and everything still works.

I only had to ejection charges hooked up and they were supposed to fire at apogee and back up at apogee. I also used motor eject as back up. From what I can see my charges fired after the break up which leads me to believe it could be from the motor eject or drag separation.

Motor: CTI I180
Rocket: Darkstar Jr.

View attachment CTI-I180.FIPa
 
Have fun with this one. Bay wasn't vented, so I'd advise against using baro channels. The rocket also had a pretty serious attitude problem, so make of the accel channels what you will. Flight was on a CTI J140. Loaded mass 3.22kg. The Raven was pretty much toast after this flight, but enough of it was still in tact to pull the data off. (Then it finally bit the dust when the USB connector broke all the way off removing the USB cable.)

View attachment bank4.FIPa
 
Flew my Madcow Frenzy a for the first time last weekend. I'm using a 2s 180 mAh LiPo to power the Raven, no replacement/recharge from first flight to second. Here's the second flight on CTI J430, no issues in this flight, and lots of battery capacity with only 8.12V at the end:

View attachment FrenzyJ430-SN-150103.FIPa

One thing of note was that I did not go to extremes to seal the hardware and wiring on the plywood a/v bay bulkheads. I used elmer's tack putty on the exterior side of the bulkhead only. No signs of pressure leaks into the bay :D
 
Anyone want to look at my most recent flight?

During the flight the rocket had a pre-mature breakup. Luckily the parachute came out and everything still works.

I only had to ejection charges hooked up and they were supposed to fire at apogee and back up at apogee. I also used motor eject as back up. From what I can see my charges fired after the break up which leads me to believe it could be from the motor eject or drag separation.

Motor: CTI I180
Rocket: Darkstar Jr.

Motor ejection would normally not be at ~3 seconds unless you drilled out the CTI delay excessively (or it had a 'fault'). But the Raven shows that it didn't fire your main until well after the breakup (so it never did anything to cause it). [If you select the Volts Pyro Main and Volts Pyro Apogee in the parameter selector, you will see a drop in voltage on the pyro channels when they fire.] So maybe drag separation...? interesting for sure.
 
Have fun with this one. Bay wasn't vented, so I'd advise against using baro channels. The rocket also had a pretty serious attitude problem, so make of the accel channels what you will. Flight was on a CTI J140. Loaded mass 3.22kg. The Raven was pretty much toast after this flight, but enough of it was still in tact to pull the data off. (Then it finally bit the dust when the USB connector broke all the way off removing the USB cable.)

Yes with an unvented bay, you would want to change the deployments to be Accel based. I've made that mistake myself...
 
Flew my Madcow Frenzy a for the first time last weekend. I'm using a 2s 180 mAh LiPo to power the Raven, no replacement/recharge from first flight to second. Here's the second flight on CTI J430, no issues in this flight, and lots of battery capacity with only 8.12V at the end:

View attachment 250919

One thing of note was that I did not go to extremes to seal the hardware and wiring on the plywood a/v bay bulkheads. I used elmer's tack putty on the exterior side of the bulkhead only. No signs of pressure leaks into the bay :D

Beautiful flight! Good idea with the tack putty - it obviously worked!
 
Yes with an unvented bay, you would want to change the deployments to be Accel based. I've made that mistake myself...

Deployments were accel-based. Channel 3 fired correctly at Accel Apo. IIRC, Apo tried to fire correctly at Accel Apo +0.5. Main did not fire because it was toast by then (timer-based). The issue was not the deployment, rather the bird went unstable and shortly thereafter turned into a cruise missile.
 
Motor ejection would normally not be at ~3 seconds unless you drilled out the CTI delay excessively (or it had a 'fault'). But the Raven shows that it didn't fire your main until well after the breakup (so it never did anything to cause it). [If you select the Volts Pyro Main and Volts Pyro Apogee in the parameter selector, you will see a drop in voltage on the pyro channels when they fire.] So maybe drag separation...? interesting for sure.

Thank you for your response! I came to the same conclusion of drag separation as I saw the same thing you did.
 
I have 29 different Raven flights and decide that these two might be interesting to look at. The first is the flight of the Thrusting the Throne 450 lb porta potty that flew on a N3300 three L2200's and three L1040's. The second is a 1/13 scale Soyuz flown on two K1275's and two K750's in the boosters that were jettisoned and air started an M1450.View attachment Thrusting the Throne.FIPaView attachment Soyuz.FIPa
 
Maybe you got really unlucky and had the front end of the rocket get tangled up in the drogue harness at deployment, such that the nosecone was toward the center of the circle when it started coning? If the rocket was coning in a regular stretched-out configuration with the av-bay toward the center of the rotation, the Raven would have seen negative Gs. Very unusual situation.

Maybe another to add to this very unusual scenario. View attachment MnM_K660_BR-150801.FIPa

Flight at Black Rock Nevada, approximately 4000 ASL. Rocket is a scratch 3" with 54mm mount, flying on a CTI K660 Classic. From about 59 seconds into the flight until about 197 seconds, there was a net positive axial G force recorded by my Raven 3. There's also a small portion before that period where a positive and then net negative axial G force caused Velocity < 0 to toggle. Velocity < Vel1 is false when AGL < AGL1 goes true.

Somehow this configuration also resulted in a lower rate of change in barometric pressure (GPS data mirrors this so I think the configuration caused a slower descent rate as opposed to a venting artifact). We did not have eyes back on the rocket until about 400' agl, so I did not observe anything out of the ordinary in the descent configuration... apart from the missing main parachute.

I'll include a flight of the same rocket with a different motor from the day before (all other aspects identical). After apogee, it never has enough positive axial G forces to register Velocity < 0. View attachment MnM_J430_BR-150731.FIPa

No redundant altimeter. The rocket did a "mini" lakestake with the nose and snapped an upper section of the booster (made from giant leap magnaframe). Repairable, I've got a coupler and spare tubing.

MixNMatch Thunk.jpg

side note: if you zoom in on the early part of the flight, you can see a nice barometric pressure transient at 5.24 seconds into the flight. Definitely needed some sort of mach lockout on this flight to avoid an untimely apogee deployment.
 
Update after more investigation. When I recovered the rocket, I noticed some yellow lines along the nose and at first thought they were from a rock or something on the playa since it was along the part that dug in. However, when I whacked the nose against some of the damaged yellow tubing of the booster, the paint matched. So at some point in the deployment, the nose was sliding along the booster very hard (possibly recoil from apogee deployment but did not happen in other flights with same charge levels). They were separated when I saw the rocket again and at impact.

I've looked over settings and am concerned that this type of situation could repeat since it's not obvious what the root cause is without getting some onboard video. For flights where I anticipate a long descent period (when it's most likely runaway integration of positive axial acceleration could result in V > Vel1), my plan is to switch to using the T > Tval flag to replace the mach inhibit behavior provided by V > Vel1. This has a downside of not providing a main deployment if there is a catastrophic failure very early in the flight, but at that time, I know the rocket is at a safe distance and probably in pieces anyway.
 
On a recent Wildman Jr two stage flight, the rocket fell off a pad support before launch and bumped on the blast deflector. Unbeknownst to me it was enough to trip the LiftOff detect and effectively disable the Raven 3. It collected data for about 5 seconds after the bump and then apparently went dormant. The results after launch were not good (i.e. no channel events), but could have been worse had there not been a backup altimeter on board. Sooo, if you do bump your Raven 3 while the rocket is on the pad, remember to at least check again for the continuity beeps. Better yet, just recycle the power to be sure.

View attachment WM Jr Sustainer Boosted with J510W.FIPa
 
What were your pre-set conditions and which version; 2 or 3?
Did you use an altitude check?
I've been toying with the idea of using a Raven for 2 stage flights.
I know of at least 2 people who have successfully done so..

JD


On a recent Wildman Jr two stage flight, the rocket fell off a pad support before launch and bumped on the blast deflector. Unbeknownst to me it was enough to trip the LiftOff detect and effectively disable the Raven 3. It collected data for about 5 seconds after the bump and then apparently went dormant. The results after launch were not good (i.e. no channel events), but could have been worse had there not been a backup altimeter on board. Sooo, if you do bump your Raven 3 while the rocket is on the pad, remember to at least check again for the continuity beeps. Better yet, just recycle the power to be sure.
 
Yes, the Raven is my altimeter of choice for the sustainer start and DD recovery in 2 stage flights. I have the Raven 3 and this is how it was set it up for the WM Jr 2 stage:
WM Jr 2 Stage J510W to J150MY 18Sep2015.jpg

My point in the post was not so much about 2 stage setup, but rather that the Raven 3 (and maybe Raven 2) apparently uses only the accelerometer for LiftOff detect and does not look at barometric altitude. That is not something you can change in the configuration as far as I can tell. If the Raven gets bumped on the pad after you power it up (like when the rocket slips off a rail support and drops an inch or two onto the blast deflector), it can incorrectly detect LiftOff. Then, when there is no actual lift off within 5 seconds or so, the Raven effectively shuts off. This is what the data on the Raven 3 looks like when this happens:
WM Jr 2 Stage Data J510W to J150MY 18Sep2015.jpg

Notice the LiftOff detect on the top line after the bump artifact on the axial accelerometer trace. If you don't recognize that this has happened, the rocket will get launched with a disarmed Raven and not so good things can happen.
 
Sooo, if you do bump your Raven 3 while the rocket is on the pad, remember to at least check again for the continuity beeps. Better yet, just recycle the power to be sure.

I definitely second that advice. There are some things that the Raven does to account for and ignore some drops and bumps at the pad, but some motions can still get by that filtering. The bottom line is, don't walk away until you've confirmed that the prelauch beeps are what you're expecting.

(In case you guys are wondering, yes I've been absent from TRF for the past year or so, getting established at a new day job. I've only made time for filling orders and doing customer service, but I've decided to get more involved again, at least in TRF. Still no good shop or time for my own rocketry, though. :( )
 
Last edited:
Looks like your main shook out at apogee? Also, your rocket was still recording positive Gs during the coast. I'd recommend doing a user re-calibration of the altimeter with the FIP, especially since this is a 250G single-axis version, so any cal errors get magnified.
 
Posting two separate 2-stage flights.

You tell me what max altitude was on them (AGL).

View attachment 274978
View attachment 274979

s6

Nice flights! The altitude for the July flight was 4048 feet, and the altitude for the October flight was 3435 feet. Did you use an altitude trigger for the 2nd stage ignition? If so, kudos. That's a good safe way to go, minimizing the chance for an unwanted ignition of the 2nd stage in the even of a ground mishap or a CATO.
 
(In case you guys are wondering, yes I've been absent from TRF for the past year or so, getting established at a new day job. I've only made time for filling orders and doing customer service, but I've decided to get more involved again, at least in TRF. Still no good shop or time for my own rocketry, though. :( )

Good to see you on the forum!
 
I'm curious to know what people make of the continuity of my apogee channel on this flight from Thunda Down Under

2015-03-14 Flying Dutchman J530 Raven DD (main) Thunda.jpg
 

Attachments

  • 2015-03-14 Flying Dutchman J530 Raven DD (main) Thunda.FIPa
    293.1 KB · Views: 56
I'm curious to know what people make of the continuity of my apogee channel on this flight from Thunda Down Under

View attachment 291740

Do you mean that it drifts back up as if you have continuity? I'm guessing there is still a bit or resistive something left on you ematch after ejection and it made contact enough to register. You'll note on your main channel also that it drops during ejection and then returns to near battery V as if it is now a good ematch again. One unobvious lesson from this is to measure your ematches before flight - they should be around 1-2 ohms. You can have ematches that show as continuity (as in your picture) that are obviously not going to fire...

Let me know if you had a different question / concern?

/kjs
 
Do you mean that it drifts back up as if you have continuity? I'm guessing there is still a bit or resistive something left on you ematch after ejection and it made contact enough to register. You'll note on your main channel also that it drops during ejection and then returns to near battery V as if it is now a good ematch again. One unobvious lesson from this is to measure your ematches before flight - they should be around 1-2 ohms. You can have ematches that show as continuity (as in your picture) that are obviously not going to fire...

Let me know if you had a different question / concern?

/kjs
The voltage drop under load is expected, in previous flights I've always seen the voltage jump back up which indicates that the ematch is either still intact or has shorted. This is what you can see on the main channel. The other expected alternative is that the match goes open circuit resulting in a constant low voltage after it fires. What I did not expect is this "self healing" scenario. So was wondering if anyone had seen something similar?
 
Back
Top