L3 4 Inch Black Brandt Scratch Build *Success*

eggtimer rocketry
rocket sok
Onebadhawk
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
flynfrog said:
Both charges were fired on the Apogee circuits.

Per Jims email since the main fired first the accelerometer never turned over to face down. This caused the raven to think it was still accelerating and never made the criteria for the main deploy.

Had I wired the charges correctly the drogue would have turned the altimeters over and should have worked as intended.
Click to expand...

Yeeeehaaaa!!!,

Since this is "expected" behavior, you're good to go then! Just make sure you wire the charges correctly next time!! Jim's thinking makes good sense.

Kurt
 
flynfrog said:
Per Jims email since the main fired first the accelerometer never turned over to face down.
Click to expand...
That explanation confuses me. Accelerometers in free fall can't sense gravity, and the Raven shouldn't be integrating velocity after it thinks it's at inertial apogee.
 
mikec said:
That explanation confuses me. Accelerometers in free fall can't sense gravity, and the Raven shouldn't be integrating velocity after it thinks it's at inertial apogee.
Click to expand...

When the accelerometer is hanging from the main, the actual acceleration on the Raven will be 1G. If the Raven was recording exactly that value, then it would think that the velocity was constant (so the reported velocity shouldn't change). I haven't analyzed the data exactly, but there is some error in the accelerometer value. If the error causes the acceleration to be a bit above 1G, then the Raven will think it is accelerating and the velocity will climb. That clearly happened, because the velocity flag went false on both altimeters (their errors appear to me to be in the same direction). There is more room to look at this data and to figure out exactly what the Ravens did, but the flags going false on the two altimeters is why the mains didn't fire. I think the need to use a V<Vel1 method for Mach lockout is a weakness of the Raven. I prefer to use a Mach lockout time (T>Tval) even though there is the obvious risk of doing it this way. Too many issues using velocity, such as the one Ryan encountered.

Jim
 
JimJarvis50 said:
When the accelerometer is hanging from the main, the actual acceleration on the Raven will be 1G. If the Raven was recording exactly that value, then it would think that the velocity was constant (so the reported velocity shouldn't change). I haven't analyzed the data exactly, but there is some error in the accelerometer value. If the error causes the acceleration to be a bit above 1G, then the Raven will think it is accelerating and the velocity will climb. That clearly happened, because the velocity flag went false on both altimeters (their errors appear to me to be in the same direction). There is more room to look at this data and to figure out exactly what the Ravens did, but the flags going false on the two altimeters is why the mains didn't fire. I think the need to use a V<Vel1 method for Mach lockout is a weakness of the Raven. I prefer to use a Mach lockout time (T>Tval) even though there is the obvious risk of doing it this way. Too many issues using velocity, such as the one Ryan encountered.

Jim
Click to expand...

Hi Jim,

If the charges were correctly wired does V<Vel1 make any difference then? In this situation, the main was out at apogee, rocket was saved ( to drift a Loooooong ways maybe) and whether or not the Main wired to drogue charges fired or not makes no difference. Kurt
 
ksaves2 said:
Hi Jim,

If the charges were correctly wired does V<Vel1 make any difference then? In this situation, the main was out at apogee, rocket was saved ( to drift a Loooooong ways maybe) and whether or not the Main wired to drogue charges fired or not makes no difference. Kurt
Click to expand...

There are other situations where V<Vel1 doesn't work. If the accelerometer reads low, which is a common Raven problem, it is possible to have a calculated velocity that meets the criteria (less than 400 ft/s for example) while the rocket is still above Mach 1. On multi-stage flights, it isn't very effective either, and then # of burnouts plus delay is a way to get around the problem.

Jim
 
Jim,

I looked at the FIP files and you're definitely right, something happened with V<Vel1 that seems due to the Raven continuing to integrate velocity after apogee. I didn't think it was supposed to do this since there are no circumstances where it would be very meaningful. FIP usually cuts off the velocity at apogee on display but it looks like the altimeter itself is still updating it. This seems like a bug, pure and simple, though it may not matter much in practical terms since the main was out already.
 
mikec said:
Jim,

I looked at the FIP files and you're definitely right, something happened with V<Vel1 that seems due to the Raven continuing to integrate velocity after apogee. I didn't think it was supposed to do this since there are no circumstances where it would be very meaningful. FIP usually cuts off the velocity at apogee on display but it looks like the altimeter itself is still updating it. This seems like a bug, pure and simple, though it may not matter much in practical terms since the main was out already.
Click to expand...

Well, you can see in the screen shot that V<Vel1 is part of the default configuration for main deployment. This is to prevent the altimeter from getting spoofed during the initial acceleration if the spoof happens before you reach the main altitude setting. I have this issue at Blackrock where the main deployment altitude is high (i.e., 4,000 feet) due to the mountains. But, when you select that approach, you are asking the altimeter to continue to integrate velocity until the main actually fires, and that integration is going to include all sorts of funny data. I still think using T<Tval is a better approach since it provides that initial protection without the V<Vel1 issue later on. For a typical main at 700 feet, it probably isn't necessary to use either approach.

Jim
 
mikec said:
Jim,

I looked at the FIP files and you're definitely right, something happened with V<Vel1 that seems due to the Raven continuing to integrate velocity after apogee. I didn't think it was supposed to do this since there are no circumstances where it would be very meaningful. FIP usually cuts off the velocity at apogee on display but it looks like the altimeter itself is still updating it. This seems like a bug, pure and simple, though it may not matter much in practical terms since the main was out already.
Click to expand...


Hmmmmm, Someone ought to let Adrian know but it seems he might be busy with his usual vocation. Kurt
 
JimJarvis50 said:
Well, you can see in the screen shot that V<Vel1 is part of the default configuration for main deployment. This is to prevent the altimeter from getting spoofed during the initial acceleration if the spoof happens before you reach the main altitude setting.
Click to expand...
I thought it was to protect against pressure increases during ascent caused by the mach transition (which may be what you're saying). But I agree with you, T<Tval is more robust if the altimeter is going to keep integrating after apogee.

I know Adrian is up against the stops of the memory resources for the Raven microcontroller, but having a bit more intelligence in the Raven would be better.
 
But...................

The bottom line of all this legerdemain (sleight-of-hand) is if the right charge is wired to the "right" circuit the Raven will perform as advertised right? That's the only thing important to know for his L3 attempt. Kurt
 
Last edited:
Drove out to Black Rock to fly my L3 at Balls. Got to meet some awesome people. Thanks to all that helped me get this thing off the ground.




[YOUTUBE]D-jhwy1OitA[/YOUTUBE]
 
Congrats on the cert man, glad you were able to make the trip & that I got to see it. Thanks again for the 5am help with the tower.

-steve
 

Similar threads

frogglicker
Doorknob Scratch Build
Replies
5
Views
1K
86mustang408w
86mustang408w
frogglicker
Scratch Build - Upscaled 3-in "Menace-3D"
Replies
2
Views
303
frogglicker
frogglicker
frogglicker
SpiderMax Scratch Build
Replies
16
Views
7K
Hobie1dog
Hobie1dog
bandman444
Project Sasquatch (24" diameter Madcow Squat)
2
Replies
34
Views
3K
Rschub
Rschub
SolarYellow
"Cert racing" vs. skills development and creativity
2
Replies
43
Views
3K
Hobie1dog
Hobie1dog

Latest posts

Back
Top