# 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 we'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 we've seen shows a very
parabolic path down to about 50k'-60k', even with a recovery system
deployed...

So, what we'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...