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.
Same as yours.

p and v also show up in JordanT's file, though the v isn't nearly as crazy as my file's.

Also odd is how both Ravens are 250g, but his doesn't seem to have recorded any lateral acceleration but my club's one did.
 
The 250 G units do not record lateral movement.
It can't be a 250 g model.
Send the serial number to Adrian and he can confirm which model it is.


JD


Same as yours.

p and v also show up in JordanT's file, though the v isn't nearly as crazy as my file's.

Also odd is how both Ravens are 250g, but his doesn't seem to have recorded any lateral acceleration but my club's one did.
 
Had a picture perfect flight on Saturday at MDRA's ESL 175. I used my Raven2 to its full potential and it performed flawlessly, as usual. :cool:

This is the first time I used all 4 outputs during a flight, any thoughts on each setting?


View attachment ESL 175.FIPa

I think there's a Raven3 in my future!
 
Had a picture perfect flight on Saturday at MDRA's ESL 175. I used my Raven2 to its full potential and it performed flawlessly, as usual. :cool:

This is the first time I used all 4 outputs during a flight, any thoughts on each setting?


View attachment 108155

I think there's a Raven3 in my future!

Looks like a 2 stager? What did you have channel 3 doing? It fired at burnout of the first motor.

At apogee it looks like there's about 4 seconds between the charge going off and the initial slowdown. Took a while for the drogue to open, maybe?

And at main deploy there's about 5 seconds between the channel firing and the final slowdown. Big chute?
 
Spot on on all accounts. I used channel 3 to ensure seperation after booster burnout. I didn't get eyes back on the sustainer until after the drogue opened but that's what I'm assuming happened as well. There was very little wind so I think it took a few seconds for the drogue to open which was a little larger than needed. The main was a little oversived as well and took a few seconds to open.

I love all the settings that can be used to control the operations on the Raven. Sustainer ignition was dependent on pressure decreasing, elevation above the pad, flight time and min verlocity. I feel it's a little safer that a timer that's going to fire no matter what happens buring initial boost.

Here's a video of the flight:

https://www.youtube.com/watch?v=fiAwYFI4Tgk&feature=youtu.be

Had a close call on the booster as the drogue got tangled in the chute protector but the main came out and all held together!
 
Hey CarVac, just so you don't think I'm crazy, here's a screengrab of my PC. P and V just aren't there.

View attachment 108016

I think you're (or rather my computer is) crazy.

Same as yours.

p and v also show up in JordanT's file, though the v isn't nearly as crazy as my file's.

Also odd is how both Ravens are 250g, but his doesn't seem to have recorded any lateral acceleration but my club's one did.
I think these are a couple of diagnostic data traces that aren't showing up in the latest version of the FIP that I'm using. If I remember correctly, one was an on-board prediction of the apogee altitude and the other one had something to do with timing. These weren't meant to be displayed.
 
I'm not quite following. What exactly did CH3 trigger? Was it a BP charge that separated the stages somehow? If so I'd love to see pics of the setup...

It was a very small BP charge. The interstage coupler volume is very small, only about 7 in^3. I used a quest Q2G2 igniter. The igniter comes with a plastic sleeve over the head of the pyrogen. I crimped one end of the plastic sleeve, put about 0.05 grams of BP into it and inserted the Q2G2 back in and taped it all together. The "charge" was just hanging in the void below the nozzle of the sustainer.

I don't have any pictures showing the prepped sustainer off the booster but I'll try to post some pictures of the setup shortly.


Nike-Tomahawk.jpg
 
Nice data.
-LarryC

Thanks Larry.


cvanc, Here's some pictures:

First is the motor mount for the sustainer. I put a tube in to allow the leads for the igniter and the seperation charge to come down from the sustainer AV bay. You can also see 4 steel dowels that are going through the bottom centering ring. These will be attached to the top of the booster.
Booster MMT.jpg

This is the top of the booster. A PML reducer with a glassed coupler tube sticking out the top. You can see the steel dowels have been epoxied and glassed to the inside of the tube to help stabilize the sustainer.
Interstage Coupler.jpg


The last picture shows how it slides together. The rods extend up through the bottom centering ring and the coupler tube friction fits into the sustainer airframe. It's a tight fit between the ID of the coupler and the OD of the retainer for the wire leads to fit through.
Connection.jpg


I can almost hold the rocket horizontal before the sustainer wants to come off the booster. Hope this shows you what you were looking for.
 
What igniter did you use for the sustainer, and what kind of battery?
 
The igniter was a J-Tek ematch dipped in Magnalite and the battery was a standard 9V Alkaline.

I programmed the Raven with the following before lighting the igniter:
Time < 7 sec - If it didn't get to 1300' in less than 7 sec something was wrong
AGL > 1300' - I wanted the sustainer to coast for a few seconds after booster seperation
Velocity > 130 fps - Thought this may help ensure it was still traveling vertical and hadn't arced over to much if the booster didn't burn correctly(?)
Pressure Decreasing - It's going up :shock:
 
Regarding the data posted by Scott S. (#156) (This is one is for Adrian...)


OK. Now I'm a bit confused.
1) The inertial time interval on the Raven used to be 1/440 second, IIRC

2) The time interval on this data set looks like it's 1/400 second - from the exported data (See below)

3) When I analyze the inertial data assuming 1/400 second, the Baro/Inertial altitude difference is larger than that reported

4) When I analyze the inertial data assuming 1/440 second, I get an altitude close to that reported by FIP

Maybe I'm mixed up.

Thanks,
-Larry (Wouldn't be the first time.) C

Time@Axial Accel (Gs)
0
0.0025
0.005
0.0075
0.01
0.0125
0.015
0.0175
0.02
0.0225
0.025
0.0275
0.03
0.0325
0.035
0.0375
0.04
0.0425
 
I flew Disappearing Act yesterday for the Tripoli I record on an I59WN. Disappointingly, it weathercocked a lot and only went ~10247 feet. Oh well, there was no record before.

View attachment tripoli_i59wn_disappearing_act.FIPa
i59_fipa_screenshot.PNG

Things to note: When the rocket went supersonic (1117 ft/s at 60 F), the pressure decreased instead of increasing, then increased again once it slowed down. You can see this in the comparison between the baro and accel altitude traces. The single vent port was just behind the rather blunt nosecone, but I'm not quite sure why that would have happened.

This time, I sealed the av-bay with putty, so there were no odd voltage happenings.

Also, this I59 was incredibly noisy! The only other one I've seen made a wimpy hiss, but this one made a crackling roar as it ripped off the pad. At the burnout of the boost White Lightning grain, there was an acceleration spike visible in the accel trace, and which you could clearly hear on the ground.


Then, I flew it on an Aerotech I1299, for a predicted 220 G's (with a 250 G Raven). Man is that motor ridiculous.

Unfortunately, it disappeared and the tracker put out no signal, so I haven't found it yet. I would really, really like the FIPa file from that flight...
 
I flew Disappearing Act yesterday for the Tripoli I record on an I59WN. Disappointingly, it weathercocked a lot and only went ~10247 feet. Oh well, there was no record before.

View attachment 117486
View attachment 117485

Things to note: When the rocket went supersonic (1117 ft/s at 60 F), the pressure decreased instead of increasing, then increased again once it slowed down. You can see this in the comparison between the baro and accel altitude traces. The single vent port was just behind the rather blunt nosecone, but I'm not quite sure why that would have happened.

This time, I sealed the av-bay with putty, so there were no odd voltage happenings.

Also, this I59 was incredibly noisy! The only other one I've seen made a wimpy hiss, but this one made a crackling roar as it ripped off the pad. At the burnout of the boost White Lightning grain, there was an acceleration spike visible in the accel trace, and which you could clearly hear on the ground.


Then, I flew it on an Aerotech I1299, for a predicted 220 G's (with a 250 G Raven). Man is that motor ridiculous.

Unfortunately, it disappeared and the tracker put out no signal, so I haven't found it yet. I would really, really like the FIPa file from that flight...


Pressure decrease isn't uncommon, particularly with a vent hold just aft of the nose cone. Pressures just behind the bow shock are typically low; when the shock wave disappears, they go back up. My working theory is that this is a major cause of false apogee detection, since it looks like the rocket descends rapidly after the second transition.

-Larry (Sure hope you find it... and post the file) C.
 
That's interesting that it went supersonic, since I think you were predicting 0.85 Mach or something like that from your other thread.
Perhaps the large G spike is the motor spitting some propellant, partially explaining the weird thrust profile.

The burn was MUCH, much faster and stronger than expected.

i59_fipa_vs_rasaero.PNG

In this comparison I have the accelerometer traces compared. The purple X marks the peak acceleration from the sim.

More detailed analysis is in the build thread...
 
Last week I flew a (recently-repaired) Raven2 with V2.5 high-altitude firmware on my rocket Upward Propensity.

Needless to say, it didn't go to very high altitude by any means; only 750 ft.

However, it ejected waaaaaay late; apogee was at 6.6 seconds and ejection was at 9.7 seconds. I kinda doubt it, but could this perhaps be because of heavy filtering imposed on barometric data in v2.5 Ravens that's not in V2.4 or other low-altitude firmwares?

upwardpropensity_i357_fipa.PNG

Here's the FIPa.
View attachment upwardpropensity_flight1_i357t.FIPa
 
All filtering mechanisms add latency, including the Kalman filter, they are usually a few samples behind the "real-time" data. My experience with Kalman filters has been that it's about 3-5 samples behind, at 20 samples/sec that's only .25 sec. 3 seconds is pretty excessive... unless there's a bug in his filtering (and I would imagine that a few flight tests would have shaken it out pretty early), I doubt that it's due to the filter.

Last week I flew a (recently-repaired) Raven2 with V2.5 high-altitude firmware on my rocket Upward Propensity.

Needless to say, it didn't go to very high altitude by any means; only 750 ft.

However, it ejected waaaaaay late; apogee was at 6.6 seconds and ejection was at 9.7 seconds. I kinda doubt it, but could this perhaps be because of heavy filtering imposed on barometric data in v2.5 Ravens that's not in V2.4 or other low-altitude firmwares?

View attachment 121846

Here's the FIPa.
View attachment 121847
 
Last week I flew a (recently-repaired) Raven2 with V2.5 high-altitude firmware on my rocket Upward Propensity.

Needless to say, it didn't go to very high altitude by any means; only 750 ft.

However, it ejected waaaaaay late; apogee was at 6.6 seconds and ejection was at 9.7 seconds. I kinda doubt it, but could this perhaps be because of heavy filtering imposed on barometric data in v2.5 Ravens that's not in V2.4 or other low-altitude firmwares?

View attachment 121846

Here's the FIPa.
View attachment 121847

There are some significant off-axial G's early in the flight. Did this rocket rise vertically? Did it fishtail at all? Nonzero angles of attack in the boost phase or early coast phase can make an accelerometer think it's going faster than it is, and causing it to fire late and over-estimate altitude. (Looks to be during boost, here.) Off-verical ascent will make it over-estimate altitude, but ejection time tends to be affected less, unless the off-verticality is radical.
 
There are some significant off-axial G's early in the flight. Did this rocket rise vertically? Did it fishtail at all? Nonzero angles of attack in the boost phase or early coast phase can make an accelerometer think it's going faster than it is, and causing it to fire late and over-estimate altitude. (Looks to be during boost, here.) Off-verical ascent will make it over-estimate altitude, but ejection time tends to be affected less, unless the off-verticality is radical.

It fishtailed a tad, but it was set to "pressure increasing" as the main condition. I didn't have it plotted in the screenshot I posted, but the "pressure increasing" condition turned true exactly when the spike from the main charge went off.
 
It fishtailed a tad, but it was set to "pressure increasing" as the main condition. I didn't have it plotted in the screenshot I posted, but the "pressure increasing" condition turned true exactly when the spike from the main charge went off.

Sorry. I was temporarily confused by Adrian's answer to UChem in another thread. Once again, subtracting the prelaunch G's before integrating (instead of 1 g) made the apogee times correspond better. Don't know why the altimeter was late.
 
Was it a baro sensed apogee?
Maybe the vent holes were a little on the small side?
If it takes longer to equalize the pressure wouldn't apogee detection be late as well?



JD
 
Was it a baro sensed apogee?
Maybe the vent holes were a little on the small side?
If it takes longer to equalize the pressure wouldn't apogee detection be late as well?



JD

The pressure clearly indicated apogee way before the event. It was easily adequate venting.
 
All filtering mechanisms add latency, including the Kalman filter, they are usually a few samples behind the "real-time" data.

Not true. While in general causal filters have delay, some do not. Recently I was reading up on a class of filters that have zero group delay at DC. First there was a Filter Wizard which described how to do it with a general FIR filter. Then I found a dead simple ramp filter in this article on a GPSDO.

I even played around with filtering altimeter data using the ramp filter and produced the attached plot.

flt8.png
 
Last week I flew a (recently-repaired) Raven2 with V2.5 high-altitude firmware on my rocket Upward Propensity.

Needless to say, it didn't go to very high altitude by any means; only 750 ft.

However, it ejected waaaaaay late; apogee was at 6.6 seconds and ejection was at 9.7 seconds. I kinda doubt it, but could this perhaps be because of heavy filtering imposed on barometric data in v2.5 Ravens that's not in V2.4 or other low-altitude firmwares?

View attachment 121846

Here's the FIPa.
View attachment 121847

The altimeter you used for this is a special case (1 of 4 in the world, if I recall correctly) because it has version 2.5 firmware that is specifically optimized for multi-stage flights over 80,000 feet. I only install it, by request, it for people who need a 2nd stage ignition higher than the normal maximum setpoint of 32,000 feet and/or a timer setpoint that's over the normal maximum of 32 seconds. That makes the timer and altitude resolution setpoints resolutions correspondingly coarse. The filter gain on the baro sensor for apogee detection is also set higher in this special-case version of the firmware, to reduce the effect of sensor noise for apogee detection at 100,000 feet. In that application, the extra filter lag and the extra smoothing are both beneficial, because the noise floor is relatively high, which will bias the baro-based ejection to be early without counter-measures like this intentionally laggy filter or a Kalman filter. For those flights, the filter lag is a feature rather than a bug, and would make the apogee detection happen right on time. For your 650 foot flight, the apogee detection performance suffers because of that lag.
 
The altimeter you used for this is a special case (1 of 4 in the world, if I recall correctly) because it has version 2.5 firmware that is specifically optimized for multi-stage flights over 80,000 feet. I only install it, by request, it for people who need a 2nd stage ignition higher than the normal maximum setpoint of 32,000 feet and/or a timer setpoint that's over the normal maximum of 32 seconds. That makes the timer and altitude resolution setpoints resolutions correspondingly coarse. The filter gain on the baro sensor for apogee detection is also set higher in this special-case version of the firmware, to reduce the effect of sensor noise for apogee detection at 100,000 feet. In that application, the extra filter lag and the extra smoothing are both beneficial, because the noise floor is relatively high, which will bias the baro-based ejection to be early without counter-measures like this intentionally laggy filter or a Kalman filter. For those flights, the filter lag is a feature rather than a bug, and would make the apogee detection happen right on time. For your 650 foot flight, the apogee detection performance suffers because of that lag.

I take it that accelerometer apogee would have been a better choice? After destroying our 250g one this was the only Raven our club had available for me to use.
 
Back
Top