add another answer

diff --git a/FAQs/apogee-above-100k.mdwn b/FAQs/apogee-above-100k.mdwn
new file mode 100644 (file)
index 0000000..b4fba3b
--- /dev/null
+++ b/FAQs/apogee-above-100k.mdwn
@@ -0,0 +1,88 @@
+# Can I fly your products to an apogee over 100k feet?
+
+Our flight computers use a Kalman sensor-fusing filter to estimate the
+flight state, which consists of three values:
+
+ 1. Height above ground
+ 2. Vertical speed
+ 3. Vertical acceleration
+
+Apogee is assumed to be where vertical speed crosses zero.
+
+Below 30km altitude (about 100k'), we use both the barometer and the
+accelerometer to update the flight state, along with a basic Newtonian
+model of motion. That works super well, pegging apogee within a few
+sensor samples essentially every time.
+
+Above 30km, the barometric sensor doesn't provide useful data, so we
+can't use it to update the flight state. Instead, the Kalman filter
+falls back to a single sensor mode, using only the accelerometer.
+
+At all altitudes, we de-sense the barometric data when we estimate the
+speed is near or above mach as the sensor is often subjected to
+significant transients, which would otherwise push the flight state
+estimates too fast and could trigger a false apogee event.
+
+That means the filter is no longer getting the benefit of two sensors,
+and relies on just the accelerometer. The trouble with accelerometers is
+they're measuring the derivative of speed, so you have to integrate
+their values to compute speed. Any offset error in acceleration
+measurement gets constantly added to that speed.
+
+In addition, we assume the axial acceleration is actually vertical
+acceleration; our tilt measurements have enough integration error during
+coast that we can't usefully use that to get vertical
+acceleration. Because we don't live in an inertial frame, that means
+we're mis-computing the total acceleration acting on the airframe as we
+have to add gravity into the mix, and simply adding that to the axial
+acceleration value doesn't generate the right value.
+
+The effect of this is to under-estimate apogee when you base the
+computation purely on acceleration as the rocket flies a parabolic path.
+
+For flights *near* 100k', all of this works pretty well - you've got the
+flight state estimates adjusted using the barometric sensor up to 30km,
+then you're flying on inertial data to apogee.
+
+For flights well above 100k', it's not great; you're usually going fast
+enough through 100k' that the baro sensor is still de-sensed through the
+end of its useful range, so the flight state estimates are not as
+close. After that, as you're flying purely on accelerometer data,
+there's no way to re-correct the state, so the apogee estimates can be
+off by quite a bit.
+
+In the worst cases that I've seen, the baro sensor data was wildly
+incorrect above mach due to poor static port design, leaving the state
+estimate of speed across the 30km boundary way off and causing the
+apogee detection to happen far from the correct time.
+
+The good news is that correctly determining apogee is not really all
+that important at those altitudes; there's so little density that a
+drogue will have almost no drag anyways. The data I've seen shows a very
+parabolic path down to about 50k'-60k', even with a recovery system
+deployed...
+
+So, what I've been recommending is to set up two apogee plans:
+
+ 1. Use the built-in apogee detection, but add a significant delay (as
+    much as 30 seconds). This will probably fire near enough to apogee
+    to not have a significant impact on the maximum height achieved.
+
+ 2. Add a back-up apogee which fires after apogee *when the height is
+    below about 20-25km*. This way, if the flight isn't nominal, and the
+    sustainer ends up reaching apogee in dense air, you aren't hoping
+    the chutes come out before it gets going too fast. And, you get a
+    second pyro channel firing at that altitude even if it reached a
+    higher altitude before.
+
+You can wire these two pyro channels to the same pyro device; you just
+need to make sure they're wired + to + and - to - (the manual shows
+which screw terminals are which).
+
+All of this is why we're encouraging people flying way high (like 300k')
+to find a deployment mechanism which doesn't solely rely on altimeters
+(like ours) which are designed for modest altitude rocketry.  Besides,
+flights like that probably need active stabilization to make sure they
+follow the prescribed trajectory so that they don't end up outside the
+waiver, but that's a whole 'nother adventure...
+