Post your Raven FIPa files here

Viperfixr said:

Here is the flight from my Wildman Darkstar Extreme on an AT L900DM. I am surprised at the G forces at/around the apogee event and I think my main may have come out at apogee as a result, despite using nylon 2-56 shear pins. Since the flight was beyond visual range, the data is all I have to go on, but I do not see a drop in descent rate when the main charges go off. This rocket had redundant electronics, so an RRC3 was the primary for the apogee event and the Raven primary for the main event, and vice versa for backup duty. Also, the rocket went way off vertical shortly after leaving the rail, but I cannot determine the velocity at the time of the apogee event. Any thoughts on what the data says here?

Click to expand...

FWIW:
These data are not obviously inconsistent, but that doesn't necessarily mean they're accurate. Assuming they are, analyzed them two ways:

1) OVAA, an off-vertical accelerometer analysis method. It assumes a ballistic trajectory. Taking you at your word that the off-vertical trajectory started early, the method backtracked a virtual launch angle and worked from there. The virtual angle was 77.8 degrees.

2) WGX, a method that uses a barometrically-adjusted speed estimate. It can compute a trajectory sine (WRT the horizontal) using that.

There was an extremely small discrepancy between WGX and OVAA sines, but that's to be expected as the OVAA sine is an approximation. Velocity curves virtually coincided. Note the residual velocity at apogee from the off-vertical trajectory.

BTW, used temperature-adjusted barometric data

Regards,

Larry Curcio said:

FWIW:
The virtual angle was 77.8 degrees.

Click to expand...

Awesome analysis! I played with Rocksim and tried different launch angles to get down to the altitude that it actually reached, and almost came to the same launch angle/speeds. A deployment around 140mph must have been enough to shear the forward shear pins and get the sorta tight fitting main out. Thanks for the info.

kjs said:

I get the same behavior so will see if I can figure out what FIP is doing this evening. A quick check confirms that it also happens in the debugger in both debug and release builds with Dev Studio not catching any exception or anything (making it harder to find/fix but should be doable). Thanks for pointing this out!

Click to expand...

Is there a software repository somewhere for FIP or is the source closed? I may be able to help debug.

This is my first file so I had to submit it here.

It is from a dual deployment flight on a H120. The apogee event was drogueless with a main at 550 feet.

Now for fun what happened? Or did not happen?

View attachment typeII.FIPa

BLKKROW said:

This is my first file so I had to submit it here.

It is from a dual deployment flight on a H120. The apogee event was drogueless with a main at 550 feet.

Now for fun what happened? Or did not happen?

Click to expand...

Main came out at apogee...

cvanc said:

Main came out at apogee...

Click to expand...

Nope, the main never came out.

Here is a good one.

3" DarkStar 2 stage

K2045 booster to a K1440 sustainer.

I love the graph that shows how much velocity changes when the sustainer lit. From the ground it looked awesome!! The flight was a perfect 2nd place in the " closest to 15K" race at MWP11

View attachment DarkStar3 2Stage K2045-K1400 MWP11.FIPa

Speaking of 3" Darkstar on K1440
here is mine to over 10k and a bit past mach

View attachment 3in Darkstar CTI K1440WT primary.FIPa

GRIFFIN said:

Here is a good one.

3" DarkStar 2 stage

K2045 booster to a K1440 sustainer.

I love the graph that shows how much velocity changes when the sustainer lit. From the ground it looked awesome!! The flight was a perfect 2nd place in the " closest to 15K" race at MWP11

Click to expand...

Must of been cool to watch with sustainer lighting at 1200'... warp drive engaged... gotta get me one of those! How did you set up the air start? Looks like Pyro 4 fired, but I couldn't figure out how it was programmed.

WoShuGui said:

Must of been cool to watch with sustainer lighting at 1200'... warp drive engaged... gotta get me one of those! How did you set up the air start? Looks like Pyro 4 fired, but I couldn't figure out how it was programmed.

Click to expand...

3rd was separation charge
4th was sustainer ignition

GRIFFIN said:

3rd was separation charge
4th was sustainer ignition

Click to expand...

Thanks, that what it looked like. I was having trouble figuring out the trigger conditions... looked like none of the logic conditions changed at pyro 4.

WoShuGui said:

Thanks, that what it looked like. I was having trouble figuring out the trigger conditions... looked like none of the logic conditions changed at pyro 4.

Click to expand...

There could have been a delay added to any of trigger conditions. Maybe AGL > AGL2 plus 2.5 seconds?

The current and voltage during the 2nd motor burn is interesting. It looks like the igniter wire may have been bouncing in and out of the flame, based on the periodic shorting.

CTI K4000 (1 grain 98mm) flown in a Wildman Extreme Jart. Pretty damn cool motor. To bad it won't be certified.

GRIFFIN said:

CTI K4000 (1 grain 98mm) flown in a Wildman Extreme Jart. Pretty damn cool motor. To bad it won't be certified.

Click to expand...

40G's for about 6 tenths of a second - nice!

So why is it a foregone conclusion it won't see certification? Bummer.

FIPa file from my L3 flight is attached. 20 lb 4 inch rocket on an AT M1500. The accel data seems a bit off. Actual Raven baro. altitude was 11,200 ft. approximately, but accel altitude was only 6600. Also, accel based velocity was only Mach 1.1, while the rocket simmed at Mach 1.5. Strattologger data shows the velocity was Mach 2. Baro data from the Raven also gives about the same velocity as the the SL100. I think the baro velocity is too high, but the gelcoat on the nosecone actually bubbled quite a bit, so I'm wondering how fast this flight actually went.

The rocket was launched on about a 5 degree angle which normally I would expect to cause the accel. based altitude to be higher than baro.

Any clues as to why the accel. data is less than expected?

View attachment L3 62814.FIPa

MarkH said:

FIPa file from my L3 flight is attached. 20 lb 4 inch rocket on an AT M1500. The accel data seems a bit off. Actual Raven baro. altitude was 11,200 ft. approximately, but accel altitude was only 6600. Also, accel based velocity was only Mach 1.1, while the rocket simmed at Mach 1.5. Strattologger data shows the velocity was Mach 2. Baro data from the Raven also gives about the same velocity as the the SL100. I think the baro velocity is too high, but the gelcoat on the nosecone actually bubbled quite a bit, so I'm wondering how fast this flight actually went.

The rocket was launched on about a 5 degree angle which normally I would expect to cause the accel. based altitude to be higher than baro.

Any clues as to why the accel. data is less than expected?

View attachment 176717

View attachment 176715View attachment 176716

Click to expand...

A quick calculation from the thrustcurve.org simulator predicts an apogee of ~12,000' @ ~22.5 seconds and a maximum velocity of ~1600 fps or M~1.5.

I believe there are problems with both sets of data.

1.) The Raven velocity is calculated from the accelerometer which does not appear to be properly calibrated. Did you recalibrate it?

2.) The StratoLogger uses the pressure data to calculate the velocity, however there are mach pressure transients clearly visible in the velocity data so the velocity values as calculated are not valid. The macg transients need to be removed before you can do the calculation. Please supply the raw data from the StratoLogger so this can be done.

Bob

Bob,

The Strattologger file is attached.

I checked the Raven a couple days before launch but did not calibrate it, because it was reading close to 1 on both axes and was in spec per the manual. The Raven data show something like 0.89 axial Gs before launch which is consistent with the angle on the rail of about 5 degrees.

For a vertical flight, my simulations in Open Rocket and RASAero both predicted about 12,000 ft and mach 1.5 as well. We angled the rail to account for the breeze on Saturday, so I believe the actual altitude of ~ 11,200 is consistent with the angle.

Nice meeting you at URRF by the way. I did the RSO shift from 12-2 Friday and Saturday.

View attachment L3 62814.pf2

MarkH said:

I checked the Raven a couple days before launch but did not calibrate it, because it was reading close to 1 on both axes and was in spec per the manual. The Raven data show something like 0.89 axial Gs before launch which is consistent with the angle on the rail of about 5 degrees.

Click to expand...

I took a look at the data and I noticed that the accelerometer based apogee detection (velocity < 0) happens several seconds before barometric apogee. This is an indication of accelerometer offset or non-linearity errors or both. There is a built in offset because you started in a non vertical position but it isn't that big.

The Raven is known to have occasional problems with the accelerometer data because it operates outside of the supply voltages where performance is characterized. (The data sheet for the ADXL78 only guarantees performance specifications for a supply voltage of 5V +/-5%. The Raven runs it at about 3.6V.)

MarkH said:

Bob,

The Strattologger file is attached.

I checked the Raven a couple days before launch but did not calibrate it, because it was reading close to 1 on both axes and was in spec per the manual. The Raven data show something like 0.89 axial Gs before launch which is consistent with the angle on the rail of about 5 degrees.

For a vertical flight, my simulations in Open Rocket and RASAero both predicted about 12,000 ft and mach 1.5 as well. We angled the rail to account for the breeze on Saturday, so I believe the actual altitude of ~ 11,200 is consistent with the angle.

Nice meeting you at URRF by the way. I did the RSO shift from 12-2 Friday and Saturday.

View attachment 176766

Click to expand...

I was great to meet you as well. There were a bunch of TRF members at URRF2 that I met for the first time and a number that I got to see again.

I looked at your data and did a simulation of your flight in RASAero and compared the results to the "data" generated by the PerfectFlite StratoLogger as shown in the jpg below.



The RASAero Simulation is close to your rocket. It has a smooth altitude versus time curve so when you calculate the velocity you obtain a smooth velocity curve. The maximum vertical velocity is ~ 1500 fps as contrasted to ~2200 fps obtained from the StratoLogger. The reason is in part due to the 2 mach transition events that disturb the pressure readings which are carried over to the altitude calculations. Since the pressure readings are not smoothly varying or accurate near the mach transitions, the velocity derived from the altitude values are also not smoothly varying or accurate near the mach transitions. Furthermore, it appears that the pressure sampling holes are not of sufficient area to provide the high conductance necessary to accurately sample the static pressure at high velocity and low altitude. This is indicated by the lower apparent altitude in the beginning of the flight and the higher apparent altitude in the coast to apogee when compared to a normalized simulation.

When I look at the RASAero simulation I get good correspondence with flight events on the Raven, but not with the altitude values from the accelerometer. Dave probably has the proper explanation for that.

These 2 different effects observed on two different altimeters spotlight some of the real world instrumental measurement errors that can be present in high performance flight data. If instrumental velocity/altitude/time values do not agree with well characterized sims based on the laws of motion, suspect the values derived from instrument measurements. A careful analysis of the flight data will usually resolve any discrepancies.

Bob

Bob

UhClem said:

I took a look at the data and I noticed that the accelerometer based apogee detection (velocity < 0) happens several seconds before barometric apogee. This is an indication of accelerometer offset or non-linearity errors or both. There is a built in offset because you started in a non vertical position but it isn't that big.

The Raven is known to have occasional problems with the accelerometer data because it operates outside of the supply voltages where performance is characterized. (The data sheet for the ADXL78 only guarantees performance specifications for a supply voltage of 5V +/-5%. The Raven runs it at about 3.6V.)

Click to expand...

I'm fine with accurate criticism of the Raven, and I try to be open about the weaknesses as well as the strengths. I fully acknowledge that the accelerometer accuracy leaves something to be desired. But inaccurate criticism bugs me. The correct part number for the Raven's accel is ADXL193. The recommended power supply input range is 3.5V to 6V (page 5), and the Raven provides it with 3.6V. The single-voltage characterization at the part level isn't especially relevant, because the sensor is still designed to operate accurately over the wider range, and the output is ratiometric with the supply. More to the point, my own testing has shown that the accelerometer output is not affected until the supply falls below 3.2-3.3V.

Inaccuracy in the Raven's accelerometer readings instead stems from nonlinearity in the analog/digital converter in its microcontroller. This is especially apparent with the +/-250G model of the Raven, which has around 0.5Gs per raw digital count. I have the Raven do lots of averaging during the calibration and a little in flight to help with resolution, but it's still susceptible to nonlinearites. A nonlinearity error of 1 count during the -1G to +1G calibration can throw off the scale factor by 25%. This is consistent with the data above. Ideally, if you want the most accurate data out of a +/- 250G sensor, you need to calibrate it at -250Gs and +250Gs. Then minor non-linearities in the readout electronics won't significantly affect the scale factor. But a sustained 250G calibration apparatus is not a viable option, especially for users, so we're left with the very non-optimal calibration range of +/-1 G. In future versions of Featherweight altimeters, I'll use new high-range digital-output acclerometers that are available now, and I expect that the accuracy will improve. But that's going to be a long time from now, if ever. In the meantime the Raven still uniquely fills an important role in the market, as a small, high-G altimeter that records lots of data and has lots of deployment options for staging, etc.

Adrian A said:

I'm fine with accurate criticism of the Raven, and I try to be open about the weaknesses as well as the strengths. I fully acknowledge that the accelerometer accuracy leaves something to be desired. But inaccurate criticism bugs me. The correct part number for the Raven's accel is ADXL193. The recommended power supply input range is 3.5V to 6V (page 5), and the Raven provides it with 3.6V. The single-voltage characterization at the part level isn't especially relevant, because the sensor is still designed to operate accurately over the wider range, and the output is ratiometric with the supply. More to the point, my own testing has shown that the accelerometer output is not affected until the supply falls below 3.2-3.3V.

Click to expand...

Different part number, very similar data sheet where power is concerned. The table on page 3 is titled, in part: "Specifications at 5V +/-5%". It says that it has a functional range of 3.5 to 6V (this is not a recommended range) but since functional is never defined and more importantly the specifications are not guaranteed over that range, operational accuracy in unknown.

Unless you performed centrifuge testing of multiple parts while varying both temperature and operating voltage so as to characterize operation or have data from someone who did.

The very poor ADC in the eZ8 doesn't help.

Thanks for the feedback Bob, Adrian and David.

Without having calibrated my Raven since the recent flight, placed square on end, my Raven still reads a pretty much constant .98 Gs in the axial direction. With it plugged into my laptop and varying position, the resolution on the live data appears to be about 0.07 Gs so it appears that a cal will have no effect. The manual calls out a 0.8 to 1.2 G range being exceeded for when calibration should be done, which seems like a pretty wide margin.

Hey Adrian, I don't know if you're following this long-winded thread still but here's some interesting files.

These are both from the same flight at LDRS; my Ultimate Darkstar on a M4770 VMax. (For those who were there, this is one of the flights that had "Kate the Talking Tracker" onboard.)

Please take a look at the baro data during motor burn. It appears AV bay pressure went UP during the burn, reached a peak at motor burnout, and then started to fall off until apogee. Odd. I have never seen this behavior on any earlier flight (about ten flights total).

Two things to consider:
1- I had a surprising amount of lean right off the rail, not sure why but it was at an angle during motor burn.
2- New this flight is one of those Mobius cameras mounted with the 3-D printed shroud you can find here on the forum. The camera is on the AV bay switchband and I made sure to not cover any vent holes, but I don't bother to center it between vent holes.

All ideas welcome, thanks.
-Carl Van Camp
TRA #5388 L3


View attachment M4770_2332.FIPa View attachment M4770_1402.FIPa

The key, I think, is to recognize that an accelerometer is not really the correct sensor to use for apogee detection in most instances, which is why the Raven also has barometric sensors. Any mathematical integration of sensor data will inevitably produce drift and become less viable over time unless it is accompanied by some other method of anchoring the integrated solution to reality. But for reasonably accurate speed measurements during the boost phase, the accelerometer is very difficult if not impossible to beat without sticking a pitot tube out of the rocket somewhere, and I am not aware of any available commercial off the shelf (COTS) pitot product that is practical for small-scale sport rocketry (I once asked about this on the forum and was told that there was a COTS solution - all I had to do was buy a bunch of COTS parts, design a circuit, get a PCB made, solder it all together, etc. My definition of COTS is "I can buy it, glue/screw it in, plug it in, and take it out to the pad").

Carl, Well since it was only going about 1/2 mach, we can I think rule out the pressure wave that happens there, so if I were to guess, I would think maybe the camera shroud had a leak around the leading edge to maybe force air into the av bay? It certainly just happens during the acceleration / thrust phase and then returns to normal as it decelerates after motor burnout. Something that contradicts my theory is that it starts returning to normal (decreasing slightly before motor burnout and slightly before max velocity (at least according to the accelerometer).

Adrian may have more / better insight

Zooming in on the relevant part of the graph I get attached:

cvanc said:

Hey Adrian, I don't know if you're following this long-winded thread still but here's some interesting files.

These are both from the same flight at LDRS; my Ultimate Darkstar on a M4770 VMax. (For those who were there, this is one of the flights that had "Kate the Talking Tracker" onboard.)

Please take a look at the baro data during motor burn. It appears AV bay pressure went UP during the burn, reached a peak at motor burnout, and then started to fall off until apogee. Odd. I have never seen this behavior on any earlier flight (about ten flights total).

Two things to consider:
1- I had a surprising amount of lean right off the rail, not sure why but it was at an angle during motor burn.
2- New this flight is one of those Mobius cameras mounted with the 3-D printed shroud you can find here on the forum. The camera is on the AV bay switchband and I made sure to not cover any vent holes, but I don't bother to center it between vent holes.

All ideas welcome, thanks.
-Carl Van Camp
TRA #5388 L3


View attachment 178276 View attachment 178277

Click to expand...

This earlier response from Adrian comes to mind...

Adrian A said:

It's a pretty common phenomenon to get some significant pressure transients during liftoff. One common mechanism is that the parachute slides back in the upper av-bay like a piston, and any leakage paths into the av-bay look like a decrease in altitude. Just the accelerating air column can be also significant on high-G flights. Imagine you have a 5-foot long, sealed air column above the altimeter, and you accelerate at 50 Gs. The increase in air pressure at the altimeter just from accelerating the mass of air above the altimeter will be equivalent to 250 feet.

Click to expand...

Thanks WoShuGui - that makes more sense than my suggestion and matches better with the acceleration curve.

To me it looks like the pressure transient is better correlated to speed than to acceleration, since it's still near its peak after the boost is done. And the speed is actually close enough to Mach 1 to get some transonic effects, so I think it could be some interaction with the camera shroud. Was the camera in the av-bay, looking out through a hole?

Adrian A said:

To me it looks like the pressure transient is better correlated to speed than to acceleration, since it's still near its peak after the boost is done. And the speed is actually close enough to Mach 1 to get some transonic effects, so I think it could be some interaction with the camera shroud. Was the camera in the av-bay, looking out through a hole?

Click to expand...

Hey there Adrian! Was hoping to see you at LDRS - you missed one heck of a launch.

I should make sure it's understood the flight was perfect, the dual Ravens did everything right (other than not steering me away from a wet landing, but I don't think they can help with that). I just have this weird blip in the baro data.

The camera is externally mounted in a 3-D printed shroud, so it's entirely out in the airstream. Generic photos here:
https://www.rocketryforum.com/showt...Camera-Shrouds-3D-Printed&p=660674#post660674

The more I think about the more I think it's gotta be the camera doing this. I've flown this thing without cameras on an N10,000 and didn't see any of this artifact. So I think the basic rocket/bay design is proven 'smooth' (if that's the right word).

And Kevin, there aren't any holes to leak air into the bay. It's all surface mounted on the outside.

So I should probably move the camera away from the ports. Is there a rule of thumb I can apply here? How far away is 'safe'?

Thanks for all the comments, deconstructing the flights afterwards is really interesting to me. Give me a couple hours and I'll post a picture of the assembly.

Best,
-Carl

cvanc said:

So I should probably move the camera away from the ports. Is there a rule of thumb I can apply here? How far away is 'safe'?

Thanks for all the comments, deconstructing the flights afterwards is really interesting to me. Give me a couple hours and I'll post a picture of the assembly.

Best,
-Carl

Click to expand...

Carl,

I think where you have them is safe already. The current location makes an interesting baro artifact when the rocket is going fast, but that's what the Mach lockout is for. When the rocket slows down closer to apogee and the baro data can fire the charges, we wouldn't expect the camera port to have any significant effect on the baro sensing, and from the data from the last flight, it looks like it's fine.