Using Eggfinder Proton for Staging

[FredT]

I have a couple Proton that I've flown on single stage flights and am now looking to incorporate them into some of my staging flights.

It seems using Deviation Percent as a criterion for safe staging is a good idea. However, the documentation is ambiguous on how it is calculated on-board.

It says Deviation is calculated from the filtered barometric altitude (let's call that "AltB") and the distance traveled computed by double integrating filtered acceleration (let's call that "DistA"). I think the sensible way to calculate Deviation is:

Deviation = (DistA-AltB) / DistA

But there are other ways it could be calculated. I'd just like to hear that it is the way I think.

I'd also like to hear from other about their experiences using the Proton in staging applications.

...Fred

 

[Charles_McG]

Fred,

I've used both Quantums and Protons for staged flights in the F-H range.

The accelerometer based timing is a great improvement on the Quantum's baro only. Timing from motor burnout -really- simplifies setup.

So far I've only run with altitude/velocity safety checks and left the deviation off. Due to a design choice, I see 'weird' baro behavior during ascent - the baro reads erroneously high altitude, with error proportional to velocity. I believe it's because I put the vent ports -in- the 'pins' I use to hold the payload tube to the avbay, and the tops of the pins are rounded. So there's a reduced pressure area as air flows over them. It doesn't affect apogee determination because the airspeed is much reduced by then.

The deviation I see (and its pretty big) is BaroAlt>AccelAlt. That's backwards from tilt induced deviation (AccelAlt>BaroAlt), but from my conversations with Cris, the Proton would still lock it out - the test is double sided. It doesn't care about the sign.

I've made some construction changes, but a combination of a lost rocket (with Proton :-( ) and the end of flying season means I don't have actual data.

From the flight data I do have, using the accelerometer altitude and velocity for safety checks looks more certain than using baro, and timing from burnout is just plain awesome.

 

[cerving]

The problem with the accelerometer-based "altitude" is that it's not an altitude at all... it's a "path distance" because it's one-dimensional. Pick your path, and that's what it will report... straight up, spiraling, or looping. The Deviation compares the path distance with the baro altitude (which should be accurate up to about Mach 0.8 or so assuming your ports are sized reasonably well), and if the path is too far away from the baro altitude it assumes that you didn't go straight up and locks out your airstart. If you do go reasonably straight, the Deviation tends to be fairly accurate well past the point where most airstarts would occur. I'll be 100% honest and tell you that it's not as good as a full IMU (3-axis accelerometer and 3-axis gyro) because it can't calculate your actual orientation, however it's "good enough" for the vast majority of hobby rocketry airstarts. If you want to fly to 100K and light your second stage at Mach 1.5, then the Proton may not be the best choice... there are other (much more expensive) devices that are appropriate for those flights.

 

[Charles_McG]

The problem with the accelerometer-based "altitude" is that it's not an altitude at all... it's a "path distance" because it's one-dimensional. Pick your path, and that's what it will report... straight up, spiraling, or looping.

I understand that. And I'm flying well under transonic. As I said, I think I made a bad design/construction choice and ended up with a consistent but faulty high -baro- reading. The bad baro reading complicates using the deviation limit. I didn't anticipate that pin/vent choice would make such a difference. With flight data in hand, I can compensate, if I so desire. But the first time I flew it, I would have gotten it wrong, erring on the safe side. If the test was (AccelAlt-BaroAlt) / BaroAlt <= Limit % * BaroAlt then my case would still be fine because the difference would be a negative value. But if I understand correctly, it's |(AccelAlt-BaroAlt)| / BaroAlt <= Limit % * BaroAlt . So the rocket can fly straight up and still give a false positive - the baro says it's higher than a straight up flight. Which is silly. I'm not asking that you change the code; I'm just sharing my experience that using the deviation limit isn't as simple as it looks.

It also makes me glad that I tend to fly the sustainer as a boosted dart on the first flight.

 

[mbeels]

From the flight data I do have, using the accelerometer altitude and velocity for safety checks looks more certain than using baro, and timing from burnout is just plain awesome.

I'll echo Charles' comment to use the accelerometer based launch detect and trigger source ("Burnout #1") for the 2nd stage ignition.

I think your deviation calculation seems right, but I can't verify that is what the software uses. Setting it somewhere in the 15% range is probably a good number.

 

[cerving]

Charles, you're close... the test is abs(accel_alt - baro_alt)/baro_alt <= dev%. We use the filtered values of both, there's a slight lag due to that (about .25 sec). It's keyed off the baro altitude because that's "the" vertical altitude. Baro alt tends to lag slightly behind accel alt right at launch because the accelerometer sensors are more responsive, but they tend to converge before burnout, unless you're using a VMax motor (which would be a bad choice for a booster motor anyway). For the typical settings that most people would set for their sustainer's ignition time, between zero and five seconds after burnout, it's a pretty good indicator of vertical orientation. This is not to be confused with "tilt", which can only be attained with an IMU.

 

[JimJarvis50]

Charles, you're close... the test is abs(accel_alt - baro_alt)/baro_alt <= dev%. We use the filtered values of both, there's a slight lag due to that (about .25 sec). It's keyed off the baro altitude because that's "the" vertical altitude. Baro alt tends to lag slightly behind accel alt right at launch because the accelerometer sensors are more responsive, but they tend to converge before burnout, unless you're using a VMax motor (which would be a bad choice for a booster motor anyway). For the typical settings that most people would set for their sustainer's ignition time, between zero and five seconds after burnout, it's a pretty good indicator of vertical orientation. This is not to be confused with "tilt", which can only be attained with an IMU.

Just out of curiousity, can you comment on the accuracy of the accelerometer used on the unit? You may recall that there were issues with the accuracy of the Raven accelerometer, which basically made anything calculated using the accelerometer of limited value.

Also, just FYI, but I would urge folks to be cautious about using burnout+ for flights with long-burn motors. This wouldn't be a common issue for two-stage flights (although it could be), but it is for three stage flights. There can be quite a bit of motor burn time that can occur after the point where burnout is typically detected.

Jim

 

[Nytrunner]

unless you're using a VMax motor (which would be a bad choice for a booster motor anyway

Interesting. What are some of the cons for using a high-thrust motor like Vmax for a booster?

 

[heada]

Interesting. What are some of the cons for using a high-thrust motor like Vmax for a booster?

There are/were some systems that needed 'X' Gs for 'Y' seconds in order to detect lift-off. One of the ones I had was something like equal or greater than 5 Gs for at least 0.5 seconds. If your entire booster motor burn time is 0.33 seconds, then you'll never detect lift-off.

 

[boatgeek]

There are/were some systems that needed 'X' Gs for 'Y' seconds in order to detect lift-off. One of the ones I had was something like equal or greater than 5 Gs for at least 0.5 seconds. If your entire booster motor burn time is 0.33 seconds, then you'll never detect lift-off.

Cris also talks about high G liftoffs causing issues with wires coming loose etc.