+<h2 id="_example_pyro_channel_configurations">Appendix B: Example Pyro Channel Configurations</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Programming configurable pyro channels on Altus Metrum products that
+include them isn’t difficult, but in an attempt to aid understanding
+of the configuration interface and help "keep simple things simple",
+we offer the following examples of the simplest configurations for
+common situations, along with some hints on avoiding unexpected
+results.</p>
+</div>
+<div class="paragraph">
+<p>The rich set of conditions provided can be used to configure almost
+any pyro event you can imagine, for a wide variety of objectives.
+But don’t be fooled! Typical events need only one or a few simple
+conditions to be configured for success. A key thing to remember is
+that <strong>all</strong> configured conditions must be true to allow a pyro channel
+to fire. Trying to include too many conditions often results in
+conflicting rules that never allow a channel to fire. The most
+important advice we can offer is, therefore, to try and find the
+simplest set of conditions that will do what you need for a given
+project.</p>
+</div>
+<div class="sect2">
+<h3 id="_two_stage_flights">B.1. Two-Stage Flights</h3>
+<div class="paragraph">
+<p>Successful completion of a two-stage flight often involves
+programming of two events. The first is firing a separation
+charge, the second is igniting the sustainer’s (primary)
+motor.</p>
+</div>
+<div class="paragraph">
+<p>Separation charges are best fired as soon as possible after
+the previous stage has completed providing acceleration, to
+minimize drag of the sustainer’s coast phase before ignition.
+Recovery, whether the remainder of the flight is nominal or
+not, usually works best when the states are separated. So,
+the "best" way to configure a pyro channel for a separation
+charge is to just set "after motor number". For a 2-stage
+project, set this to "1". This will cause the pyro channel
+to fire as soon as the firmware’s flight state machine
+determines the first motor has burned out.</p>
+</div>
+<div class="paragraph">
+<p>Safe ignition of a sustainer (primary) motor requires that
+it happen after the previous stage burns out, while the
+airframe remains mostly vertical, and typically after the
+sustainer has coasted away from the booster a bit. A good
+starting point is thus "after motor number" set the same as
+the separation charge, which is "1" for a 2-stage rocket.
+Then "angle from vertical less than" set to some
+reasonably vertical amount, perhaps 20 degrees. Then "delay
+after other conditions" set for the desired duration of coast.
+Use simulations to figure out what a reasonable value here is,
+but for typical high power rocketry sport flights that aren’t
+trying to set records, something like 2 seconds is usually a
+good place to start.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_triggered_clusters_and_air_starts">B.2. Triggered Clusters and Air Starts</h3>
+<div class="paragraph">
+<p>When an airframe has a cluster of motors, one of which is
+"primary" and centered, surrounding by a ring of "secondary"
+motors, you may want to use the launch control system to fire the primary motor and use onboard electronics to light
+the rest of the cluster as soon as launch is detected. This
+is particularly true if the primary motor is significantly
+different in geometry and may take longer to come up to
+pressure than the secondary motors. In this case, a simple
+configuration to light secondary motors is is "time since
+boost greater than" enabled and set to "0". There’s
+really no point in setting an angle limit since no time has
+transpired for the airframe to change orientation.</p>
+</div>
+<div class="paragraph">
+<p>Air starts can use the same simple configuration, but with
+the time set to a non-zero value. However, if air starts
+are going to light after the airframe leaves the launch rail
+or tower, add an "angle from vertical less than"
+condition just you would for a 2-stage sustainer to stay safe.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_redundant_apogee">B.3. Redundant Apogee</h3>
+<div class="paragraph">
+<p>When flying a board like TeleMega or EasyMega, it’s easy to
+configure a programmable channel to fire a redundant apogee
+charge. This is of course not <strong>fully</strong> redundant, since it’s
+always possible that the board itself or its battery could
+the the failure source, but far more often, pyro events fail
+due to broken wires, bad connectors, or bad e-matches…​ so
+firing two charges from one board can add useful redundancy.</p>
+</div>
+<div class="paragraph">
+<p>The simplest configuration for redundant apogee is "flight
+state after" set to "drogue", and then "delay after other
+conditions" set to a second or two.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_redundant_main">B.4. Redundant Main</h3>
+<div class="paragraph">
+<p>Similarly to apogee, configuring a redundant main charge can
+provide useful redundancy. What we want is to configure an
+altitude for deployment lower than the primary main deploy
+altitude, and then ensure we only trigger on that condition
+while descending.</p>
+</div>
+<div class="paragraph">
+<p>The simplest configuration for redundant main is "flight
+state after" set to "drogue", which will ensure we’re in to
+the descent phase, then "height less than" set to a number
+lower than you’ve chosen for the primary main channel
+deployment height.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_apogee_above_baro_sensor_limit">B.5. Apogee Above Baro Sensor Limit</h3>
+<div class="paragraph">
+<p>A question we’ve seen increasingly often is "How does the
+Telemega/Easymega detect apogee for flights above 100,000
+feet?" Flights above that height are a bit outside
+our original design envelope, but can be made to work…​
+This is <strong>not</strong> a simple flight, and the configuration for it
+is also not simple, but we think including this information
+is important for anyone contemplating such a project with our
+electronics!</p>
+</div>
+<div class="paragraph">
+<p>Our flight computers use a Kalman sensor-fusing filter to
+estimate the flight state, which consists of three values:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Height above ground</p>
+</li>
+<li>
+<p>Vertical speed</p>
+</li>
+<li>
+<p>Vertical acceleration</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>Apogee is assumed to be where vertical speed crosses zero.</p>
+</div>
+<div class="paragraph">
+<p>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 well, pegging
+apogee within a few sensor samples essentially every time.</p>
+</div>
+<div class="paragraph">
+<p>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.</p>
+</div>
+<div class="paragraph">
+<p>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.</p>
+</div>
+<div class="paragraph">
+<p>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.</p>
+</div>
+<div class="paragraph">
+<p>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.</p>
+</div>
+<div class="paragraph">
+<p>The effect of this is to under-estimate apogee when you base
+the computation purely on acceleration as the rocket flies a
+parabolic path.</p>
+</div>
+<div class="paragraph">
+<p>For flights <strong>near</strong> 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.</p>
+</div>
+<div class="paragraph">
+<p>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.</p>
+</div>
+<div class="paragraph">
+<p>In the worst cases we have 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.</p>
+</div>
+<div class="paragraph">
+<p>The good news is that correctly determining apogee is not
+really all that important at high altitudes; there’s so little
+density that a drogue will have almost no drag anyways. Data
+from customer flights shows a very parabolic path down to
+about 50-60k feet, even with a recovery system deployed.</p>
+</div>
+<div class="paragraph">
+<p>So, what we recommend is to set up two apogee plans:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>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.</p>
+</li>
+<li>
+<p>Add a back-up apogee which fires after apogee
+<strong>when the height is below about 20-25km</strong>. 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.</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>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).</p>
+</div>
+<div class="paragraph">
+<p>The bottom line is that flights to altitudes modestly above
+the range of the baro sensor with Altus Metrum products can
+be accomplished safely, but flying "way high" (like 300k')
+demands a deployment mechanism which doesn’t solely rely on
+altimeters (like ours) which are designed for modest altitude
+rocketry. Flights to those altitudes also probably need
+active stabilization to make sure they follow the prescribed
+trajectory and stay inside their waiver.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_handling_precautions">Appendix C: Handling Precautions</h2>