Sensor fusion

TrueFuse

The barometer tells the truth about altitude, except for the few moments each flight when it doesn't. TrueFuse finds those moments as they happen, bridges them with inertial data, and hands control straight back. It can decline to trust the barometer. It can never invent an altitude the barometer did not support.

What goes wrong with a barometer

A barometric altimeter measures static pressure and converts it to height. For most of a flight this is the most trustworthy altitude source on the board: it does not drift, it needs no initial condition, and it is immune to the errors that accumulate in an integrated accelerometer.

For a few seconds of that same flight, it is badly wrong. Three events dominate:

• Ejection. The charge pressurises the airframe and the port sees a pressure step that has nothing to do with altitude. On the chart it appears as a sharp dip or spike, tens of metres deep, lasting a few hundred milliseconds.
• Launch. The motor plume and the sudden airflow over the vent holes disturb the port before the rocket has left the rail, and the recorded altitude can climb, hesitate or hump while the real altitude is still near zero.
• Poorly sized or blocked vents. The internal volume lags or steps behind the external pressure, so the trace acquires a staircase shape under a smooth flight.

An accelerometer is unaffected by all three, but integrating it twice turns a small bias into a large altitude error within seconds. Neither sensor is good enough alone. TrueFuse uses the barometer as the reference and the accelerometer only to carry the altitude across a window where the barometer has been shown to be untrustworthy.

Staying live through a pressure event

This is the practical reason TrueFuse exists, rather than an accuracy improvement measured after the fact.

An altimeter that trusts pressure alone has exactly one safe response to a pressure event: stop believing itself. The charge fires, the trace dives forty metres in a third of a second, and every decision keyed to altitude is suddenly reading a number the airframe never flew. Deployment at a set height, airbrake control, staging, altitude triggered outputs, telemetry state, all of them are looking at the same corrupted value.

The conventional answer is a lockout: suspend altitude driven decisions for a fixed blanking period and wait for the sensor to settle. It works, and it costs something real. The blanking lands at the busiest moment of the flight, its length has to be chosen in advance for the worst charge the design might ever see, and so every flight pays for the worst case. During that window the flight computer is flying blind by policy, not because the information was unavailable.

TrueFuse removes the reason for the blanking. The altitude is carried across the window rather than abandoned, so the vehicle still has a believable height and vertical speed while the port is recovering, and the window ends when the barometer genuinely agrees again rather than when a timer expires. Decisions can keep running through the disturbance instead of being parked for it.

Signal chain

Every stage below runs on the flight computer. Nothing is reconstructed on the ground, and nothing in the live channel uses a sample that had not yet been taken.

Window grammar

TrueFuse holds one of four states. The state names appear in the diagnostics and describe exactly what the filter was doing at that moment in the flight.

Inside a window

While a window is open the altitude is carried forward from the accelerometer, projected onto the tracked world vertical, with a closed form ballistic continuation used when the motor has stopped and the vehicle is coasting. The carry is anchored to the altitude and velocity that were valid at the moment the window opened, so the error inside a window grows only with the duration of that window, typically a few hundred milliseconds.

Windows have a bounded life. If the barometer has not become believable again within the time limit, the filter stops carrying and returns to the barometer regardless, because a carry that runs long has no way to prove itself right.

Sensor synchronisation

Fusing two sensors requires knowing which instant each sample describes. A barometer sample is old by the time the processor sees it: the ADC averages pressure over a conversion, the result waits to be read, and the sensor's own filter delays the ramp further. An accelerometer sample is comparatively fresh. Comparing them without correcting for this makes a perfectly good barometer look like it disagrees with a perfectly good accelerometer.

The delay is not measured from flight data. It is a property of the configuration and is calculated from it:

• t_conv/2 the ADC integrates over the conversion, so the value describes the middle of that interval.
• T_odr/2 mean age of the most recent completed conversion when the processor reads it.
• c_iir × T_odr the sensor's internal IIR filter delays a ramp by exactly its coefficient in sensor samples, not in loop samples.
• t_kalman the altitude smoothing filter's own ramp lag, the only term that varies with speed, and the smallest.
• t_imu the accelerometer's own small conversion and filter delay, subtracted because it applies to the other side.

Calculated barometer delay, milliseconds, at the 50 m/s reference

The correction is applied by delaying the inertial channel until it is as old as the barometric one. Both channels then describe the same instant, which is what fusion requires. A consequence worth knowing when reading a log: every timestamp in it trails the physical event by the barometer's chain delay, uniformly, so intervals and rates are correct even though absolute instants are late.

Scale calibration

An accelerometer at rest measures exactly one gravity. Its reported magnitude at rest is therefore a direct measurement of its own scale error, and TrueFuse uses that rather than assuming the nominal scale is correct.

On the pad, any sample with a plausible rest magnitude and a quiet barometer seeds a running estimate. Later samples join the estimate if they sit within 6 percent of it, or 60 mG, whichever is larger. The calibration factor is then the ratio of true gravity to the measured rest magnitude.

The alternative, a fixed acceptance band around 1000 mG, fails silently on a unit whose scale is off: it admits no samples at all, the factor stays at one, and the filter integrates an accelerometer that is reporting the wrong number. A flight in the reference set rested at 2050 mG for exactly this reason, and its altitude was manufactured, not measured, until the calibration was made a measurement.

World vertical

An accelerometer measures force along its own axes, which are fixed to the airframe. To contribute to an altitude, that force has to be projected onto the direction that is actually up, and the airframe rotates during flight.

TrueFuse establishes the vertical from gravity while the vehicle is at rest, then rotates that vector with the gyroscope for the rest of the flight. Thrust is projected onto the tracked vertical, so a rocket flying at an angle contributes only its vertical component, which is the physically correct behaviour.

Guards

Four conditions can stop TrueFuse trusting the accelerometer. Each resolves to the barometer, which is why none of them can produce an inflated altitude.

Saturation, and why a few samples are tolerated

A clipped accelerometer reports its rail, not the real force, so the reading is a floor. Using a floor briefly understates the acceleration and pulls the fused altitude toward the barometer, which is the harmless direction. Hard motors touch full scale for a few milliseconds at ignition, and treating that as a fault would suspend the carry at the exact moment it is most needed. TrueFuse therefore ignores saturation shorter than five consecutive samples, and treats anything longer as a genuine out of range burn where integration would be dishonest.

The clip threshold is derived from the configured measurement range rather than assumed, because the range is a setting.

Live and post channels

TrueFuse produces two altitude series from the same grammar.

The live channel is what the flight computer can know in flight. It is strictly causal: at every sample it uses only what had already been measured. This is the channel that matters for anything the altimeter has to act on, it is the only honest basis for an in flight decision, and it is what keeps a usable altitude available through a pressure event instead of forcing a blanking period.

The post channel runs once at save, over the same recorded window structure, with one extra piece of information the live channel cannot have: where the barometer ended up after each window closed. Knowing the far side of a window lets the displacement across it be anchored at both ends rather than one, which removes the small residual offset a one sided carry leaves behind. Velocity in the post channel is recomputed with a symmetric stencil, which is why the recorded velocity trace is smoother than the live one.

Reading the log header

Every flight records what the filter did, so a chart can be interpreted without guessing.

A declined flight is not a failed flight. It means the filter judged the fusion unsafe and gave you the barometer, which is exactly what an altimeter without fusion would have recorded.