TrueFuse 2C: teaching an altimeter which sensor is lying

The story of the altitude fusion filter behind AltimeterCloud and the Nano: the problem, the design, and the strange things we found in the data along the way.

Every altimeter we make measures altitude with a barometric pressure sensor, and pressure sensors are excellent. At rest, a modern barometer is accurate to within centimetres. The trouble is that a rocket flight affects the barometer at precisely the moments you care about most, and it does so in ways that are not noise. This article explains how we developed TrueFuse 2C, the filter that runs identically on AltimeterCloud and across our altimeters, and of the journey to it: the physics, the design arguments, and a handful of rather odd discoveries that real flight data forced on us.

The truefuse library code was an interesting journey to achieve, all be it quite stressful at times. 

The many ways a barometer lies

The most obvious one is the launch window. While the rocket is accelerating hard, airflow around the static port changes the pressure the sensor sees, and the altitude it reports is simply wrong: not noisy, wrong, with a sign and a size that persist for the whole burn and scale with speed. Averaging does not help. Averaging a consistent lie just gives you a smoother lie. And it starts before the rocket has even moved: the motor coming up to pressure washes its own pressure disturbance over the pad, so the very first samples of a flight can be corrupted while the altitude is still zero.

Then come the events. An ejection charge firing inside an airframe produces a pressure transient that has nothing whatsoever to do with where the rocket is: we have flights on the Altimeter Cloud where the raw trace dives more than three hundred metres in a fraction of a second and comes back. Main deployments do it, delay grains venting do it, and landing impacts do a smaller version of the same thing. Faster rockets add transonic effects, shock behaviour around the airframe distorting the port pressure exactly where the flight is most dramatic. And my favourite for sheer unfairness: sunlight. MEMS pressure sensors are light sensitive, so a rocket swinging under a parachute on a sunny day can flash sunlight onto the die through the port and write a wobble into the altitude that is nothing but optics. The list goes on beyond these, but the shape is always the same: the error is structured, physical, and specific to an event during flight, not random noise.

One real fleet flight, both problems, exactly as the barometer recorded them. Left: the launch window distorting the climb while the rocket is fast. Right: the ejection charge driving the reading 290 metres in a blink. The rocket did neither.

Between those moments, the barometer is the best altitude sensor on the board and nothing should second-guess it. That asymmetry, trustworthy almost always, badly wrong in specific known regimes, is the entire design problem. TrueFuse is not a smoother. It is a referee.

The mission

Before the first line of the filter existed, we wrote down what it had to be, and every decision in the rest of this article was made against these rules:

• It should work for all flights. Not the tidy ones, all of them: every motor, every airframe, every mishap the Altimeter Cloud has.
• It should not need tuning and tweaking. Every behaviour must be based on real science that is justifiable, without ever naming a flight to excuse it.
• It should work with the altimeter mounted at any angle in the rocket.
• It should work with altimeters that are installed loose and may move under thrust or drag.
• It should not be inventive, and it is not an estimator. As far as physics allows, it should be reconstructing the true result from the evidence, not proposing one.
• It should work live, never knowing the future.

Simple to write down but far more difficult in practice! The rest of this article is how it came about, and how we made it work.

Where TrueFuse came from

TrueFuse was not our first answer to any of this. TruePath came first, and TruePath is still here: the post-processing filter that de-spikes and polishes the recorded trace at save time. TruePath has a superpower no live filter can ever have: it knows the future. When it judges a sample, it can see both sides of the event, which makes it superb at final de-spiking, at cleaning ejection transients out of the record, and at polish. It is genuinely hard to beat at that job, which is why it still runs on every flight today, after TrueFuse, doing the final pass.

But TruePath has two limits that no amount of cleverness removes. The first is the burn. The launch window error is not a spike to be detected and bridged, it is a sustained bias with no clean edges, and a pressure-only filter, however well it sees the future, has no second witness to say what the truth was. Our first attempt at fixing that was honest and crude: a repair bolted onto the save that used the accelerometer to correct roughly the first half second of the launch. It worked, as a patch, and it taught the real lesson: the accelerometer was the missing factor, and adding it on for half a second was never going to be the answer. The second limit is fundamental: TruePath is post-processing, and our devices make decisions during the flight.

It is worth saying how flight computers have traditionally coped with living on a lying sensor, because the conventional answer is not wrong, it is just limited. The classic tools are detection and lockouts: arming delays, mach lockouts, windows in which events are simply forbidden so a pressure transient cannot fire a charge at the wrong moment. They work, and every sensible flight computer carries them, ours included. But a lockout does not fix the altitude, it just agrees not to look at it for a while, and that becomes a real cost the moment you want to do anything ambitious. Air brakes need a trustworthy altitude and velocity precisely during the burn and the transonic rush, the exact regimes the lockouts fence off, and any event you would ideally schedule during or near a pressure disturbance is stuck waiting for the fence. A live repair filter turns that on its head: the estimate stays honest through the disturbance, systems carry on operating as normal, and the lockouts are demoted to what they should always have been, a fallback layer of protection rather than the plan.

So we set out to build the real thing: a fully causal, live filter that fuses the different sensors properly, from the pad to the landing, and does it well enough to deserve the flight record. That filter became TrueFuse, and the two now work as a pair: TrueFuse live and causal, TruePath running after it with the whole flight in view, each doing the job the other cannot.

The division of labour: TrueFuse flies the flight sample by sample, never knowing the future; TruePath judges the finished record with both directions of time in view.

Why we did not build a Kalman filter

The textbook answer to sensor fusion is a Kalman filter, and for sensors whose errors are honest zero-mean noise it is the right answer and would beat anything hand-built. Our errors are not that. The launch window error is a sustained bias correlated over the whole burn; a Kalman filter weights measurements by assumed variance and duly averages the bias in, diluted but present. Ejection artifacts are structured multi-sample events that defeat innovation gating in a well-known way: each rejected sample grows the state uncertainty, the gate widens, and eventually the filter swallows the artifact it was rejecting. And even a gate that holds has a rejoin problem: a Kalman filter readmits a measurement the moment it agrees with the prediction, which during a spike happens when the artifact crosses the prediction, snapping the estimate onto the middle of the transient.

The whole argument in two panels. On honest noise, a running average and a Kalman filter both settle on the truth. Feed them a structured pressure event and both are dragged into it: a smoothed lie is still a lie. Ejection charges and the launch window live in the right-hand world. Both estimators here are running live, sample by sample, never knowing the future: the same rules TrueFuse must play by.

To be fair to the Kalman family, the plain linear filter is not where the story ends, and we should be careful with our claim here: we are not saying a Kalman filter cannot do this. The extended and unscented variants, the EKF and UKF, are the standard answer in drones and aerospace for exactly this kind of baro-inertial fusion, and in that world they are excellent, with a bonus we genuinely envy: a live estimate of their own uncertainty. But read the fine print of that world: a rigidly mounted, well-calibrated sensor on a characterised vehicle, noise parameters identified for that specific airframe, and engineers on hand to retune when anything changes. Our fleet deletes those assumptions one by one. Unknown motors, unknown airframes, static ports drilled wherever the builder fancied, altimeters mounted at any angle, and sometimes not really mounted at all. We tested along the advanced lines, adaptive measurement noise, fault detection and exclusion layers, banks of models for the different flight regimes, and could get them close. The conclusion we actually hold is the practical one: with loose altimeters and random mountings, we do not believe these designs can be made to work as reliably as we require, because the trust decisions end up living in noise matrices with no defensible physical meaning, and the settings that flatter one flight quietly degrade another, which is per-flight tuning arriving by the back door, exactly what the mission forbids. The breaking case was the one this hobby actually produces: a loosely mounted altimeter that slips at ignition or burnout, instantly invalidating the state the filter has spent the whole pad wait converging on, with everything downstream inheriting the poisoned attitude with mathematically justified confidence. Meanwhile every mechanism that did survive our testing, the schedules, the gates, the discrete trust verdicts, was the deterministic machinery. If our devices one day carry more witnesses, a magnetometer, perhaps satellite navigation, the balance shifts and we would happily revisit the question, most likely as an estimator running inside the supervisor and gates you are about to read about. For the fleet we serve today, deterministic wins.

So TrueFuse is deterministic instead: a baro-inertial vertical channel driving a velocity-scheduled complementary filter, with supervisory mode logic and fault gating over the top. No covariance, no computed gain. Every weight and every gate is a rule that can be read and defended, and the same inputs always produce the same output to the last bit. That property turned out to be the most valuable engineering decision in the whole project, because it makes the filter provable: every candidate change is run across a battery of real fleet flights and compared exactly, not statistically. Regressions cannot hide in the noise, because there is no noise to hide in. Several fixes you will read about below were rejected by exactly this mechanism.

The design in one pass

The shape of the filter follows from what each sensor knows. The accelerometer measures thrust directly, and thrust is immune to everything the airflow does to a static port, but it measures along its own axes and rockets do not fly straight up: they tilt, weathercock and corkscrew, and what gains altitude is the vertical component of thrust, not the magnitude. An obvious question early on was whether full orientation tracking was even necessary: we tested using orientation-free acceleration magnitude to see whether it was accurate enough to carry the path across events. For short bridges it was acceptable, and that finding has its uses. But as a general integrand it was measurably not good enough for the filter we wanted to build: magnitude has no sign, so away from clean thrust it rectifies noise and tumble into climb, and the fleet numbers ruled it out decisively. So orientation is carried continuously, which brings in the gyro, and the gyro brings drift, bias, and the possibility of railing its range in a fast spin. And integration has no memory of the truth: pressure is absolute and cannot wander off forever, while an integrated inertial altitude accumulates every error indefinitely. The inertial channel is a sprinter, superb over the seconds where pressure is lying, and must never be asked to run a marathon.

So: on the pad, the filter waits for genuine stillness and learns two things at once, the direction of gravity in the sensor's frame and the gyro's at-rest bias. From launch, the attitude carry rotates that vertical through every rotation the airframe makes, the thrust vector is projected onto it, and the projection is integrated into an inertial velocity and altitude.

The blend then hands the estimate between the two witnesses, and it is worth spelling out exactly why the handover is scheduled on velocity and why it deliberately returns to pressure. The static port's error is aerodynamic: it scales with the dynamic pressure of the air moving over the port, so it is largest at top speed and melts away as the rocket slows. Velocity is therefore not a convenient proxy for trust, it is very nearly the size of the barometer's lie itself. And the two witnesses age in opposite directions. Pressure altitude is the absolute, drift-free reference, good to around nine kilometres, wrong only while the air is moving fast; the inertial altitude is superb early, through the burn and the launch-window disturbances, but it is an integral, and an integral accumulates error with every second that passes. So the schedule simply follows the physics. At high speed the inertial channel carries the estimate, because that is when it is at its best and pressure at its worst. As the rocket decelerates toward apogee the weight returns to the barometer, which by then has become both honest and absolute, at precisely the moment the flight's headline number is about to be written. Fast trusts the sprinter, slow trusts the surveyor. The weight slews deliberately in both directions so the output never snaps between sources, and the speed used for the schedule is its own internal estimate, deliberately isolated from the fused output, because a schedule that reads the thing it controls is a feedback loop wearing a schedule's clothing.

The blend in one picture: the port's reliability collapses exactly when the rocket is fast, and returns to full exactly as the rocket slows toward the apogee it is about to measure.

Over the top sits a supervisor that knows the flight's phases, and a trend sensor that guards the pressure stream from the coast all the way to landing, because delay charges and main deployments do not politely wait for apogee. When an artifact hits, the trend sensor freezes its fitted trend, bridges across the event on the frozen prediction, and readmits the barometer only when it is genuinely travelling with the prediction again, in slope as well as value. It is worth asking why the bridge rides a prediction rather than simply handing over to the accelerometer, and the answer is that many pressure events assault both witnesses at once. An ejection charge that spikes the static port also fires mechanical shock through the accelerometer, and the snatch loads and airframe ringing that follow a parachute deployment are violent, structured noise on exactly the sensor you might hope to lean on. During those moments neither sensor deserves trust, and the only honest witness left is the flight's own recent physics, which is precisely what the frozen fit is. That last readmission clause carries a scar too: artifacts have tails, and an early release rule that fired on value agreement alone kept planting the output onto the tail, metres from settled truth, on over a dozen fleet flights before we understood that recovered and passing through look identical for one sample and completely different for several.

Two rules inside the trend sensor are pure physics and worth quoting. While a frozen arc is climbing, its curvature is not allowed to be gentler than gravity, because an unpowered climbing body cannot decelerate more slowly than g; that single rule deleted tens of metres of invented apogee across the fleet. And during a rejoin the output must stay inside the interval between raw pressure and the held prediction, because a blend of two signals cannot leave its own interval: any output that escapes its ingredients is a bug wearing a result's clothing.

At apogee, the handover is hard: the inertial channel retires and the schedules switch, while the trend guard stays armed. This is a deliberate statement of purpose, because the filter exists to offer the truth, not a smoothed fabrication. On descent a rocket swings under its parachute, and the accelerometer reads the whole pendulum: line snatch, canopy breathing, oscillation, spin, a soup of genuine forces with almost no honest vertical story in it. Fusing that in would not improve the altitude, it would manufacture one, a plausible-looking trace whose shape came from the swinging rather than the descending. So we decided against it: past apogee, pressure is the only witness worth believing, and the descent belongs to the barometer, guarded against artifacts but never embellished. A soft blur across the one sample everyone wants to know about is precisely the wrong place for gentleness, and an invented descent is worse than a noisy honest one.

The case of the slipping altimeter

Now the fun part: the discoveries. The best detective story in the project was a fleet flight that refused every explanation. The fused trace ran about ten percent low through the whole burn, steadily, with no aerodynamic story that fit. The altimeter was side-mounted, so its at-rest attitude read around ninety degrees, which is fine, mounting orientation is arbitrary and the pad calibration handles it. But the numbers would not close.

The whole event in one second of data. Top: the ignition rotation burst as the thrust load shoves the loose altimeter into a seat, and a second burst as drag repositions it after burnout. Bottom: the thrust curve, the impossible 0.02 G free-float where drag deceleration should be, and the several-G impacts as the airframe fetches up against it.

The gyro chart gave it away. At ignition there is a burst of rotation, roughly twenty degrees in about forty milliseconds, far too violent and far too early to be the airframe. The altimeter was not fixed to the rocket at all: it was riding loose inside it, and at ignition the thrust load shoved it into a new position. From that instant, the orientation learned on the pad no longer described the sensor that was flying, and the projection charged the difference to tilt: the filter flew the burn believing the thrust was running twenty-six degrees off vertical. And here the arithmetic closed with a satisfying click: the cosine of twenty-six degrees is 0.90, and the measured ratio of projected to total acceleration on that flight was 0.89. The entire burn deficit was the cosine of a phantom angle planted by a loose altimeter.

The witness that settled it was the thrust vector itself, and this is my favourite piece of forensics in the whole project. On the pad, gravity tells you exactly where down is in the sensor's frame. At ignition, thrust tells you exactly where the airframe's axis is, because early in a burn the thrust utterly dominates everything else the accelerometer sees. Comparing the two on this flight: the thrust direction sat less than five degrees from the pad's gravity line. In other words the rocket itself barely moved off vertical, exactly as a rocket leaving a rail should, while the attitude solution was insisting on twenty-plus degrees. Two witnesses, one of them shock-immune, disagreeing by exactly the slip angle: case closed. The epilogue is in the same log, and it completes the physics: a loose altimeter does not move once, it moves every time the load changes. At burnout the thrust vanished, the accelerometer floated at 0.019 G, genuine free-fall ballistics, and then drag took over and hauled the airframe backwards against the loose unit: three quarters of a second after burnout it records a pair of sharp several-G impacts as it fetched up in yet another position, facing yet another way.

The geometry behind the forensics: gravity at rest gives the pad vector, the force direction in the early burn gives the thrust vector, and the angle between them is the rail angle, measured entirely inside the sensor's own frame. A loose altimeter cannot fake either one, which is what makes their disagreement such a reliable witness.

We have since watched the thrust vector do this settling dance directly. One of our own test flights carried two altimeters, both of them loose in the airframe, and stepping the thrust-axis estimate outward from ignition tells the whole story in six rows per unit:

          unit A                       unit B
 time   angle   scatter        time   angle   scatter
  10ms    8.6      4.7          10ms    9.3      2.2
  96ms   13.4      9.0          97ms   10.8      3.6
 180ms   14.0     10.0         184ms   11.7      6.0
 208ms   11.5     27.3         213ms   12.4      7.6
 236ms   28.4     43.4         242ms   17.6     13.8
 349ms   71.4      4.6         386ms   26.5     11.4

Two loose altimeters, one flight: the thrust-axis angle against pad gravity as the burn proceeds, with the scatter of each estimate alongside.

Read it like a flight. For the first two hundred milliseconds both units agree on eleven to fourteen degrees, which is the real rail angle: thrust has pinned each loose unit into a seat and the vector is measuring the rocket. Then the scatter column detonates, first on one unit and then the other, as each breaks loose and starts moving, and the angle walks away to seventy-one degrees on one and twenty-six on the other. The rocket did not do that. The altimeters did, and the scatter shouted it while it happened. That signature, a settled vector whose estimate then wanders instead of converging, is exactly what the filter's machinery watches for, and it is why a loose altimeter earns a note on your flight page instead of a corrupted altitude.

Out of those flights came two permanent pieces of the system. The slip watch, which monitors for exactly this during the pad wait and reseeds the calibration when the altimeter moves, with a line on your flight page telling you it happened. And a deeper respect for the thrust vector as an independent attitude witness during the early burn: the comparison of the pad gravity line with the measured thrust line is information the airflow cannot corrupt and shock cannot fake, and the filter's machinery makes use of that fact. It fires more often than you would think, and it is why we now say, gently: secure your altimeter.

The spinning rocket problem, and being wrong three times

A second family of flights under-read the climb for a different reason, and this one humbled us properly. An accelerometer that sits even slightly off the roll axis reads centrifugal acceleration when the rocket spins, a steady lateral component that a naive projection interprets as tilt. The diagnosis was right. The first three fixes were wrong, and each was wrong in the same instructive way: they repaired the spinning flights by breaking the genuinely tilting ones, because a rocket that is spinning and a rocket that is tipping over look far more alike from inside than anyone would like. All three were rejected by the fleet battery, which is precisely its job: fixing the flight in front of you at the expense of thirty others is not a fix.

The eventual resolution was the discovery that the under-reads were not one problem but several wearing the same costume. Some flights were genuinely spinning hard. Some were rail whip: a violent rotational burst in the instant the rocket leaves the rail, delivering rotation steps faster than any carried attitude can honestly follow. And the worst offenders were the loose altimeters of the previous chapter, shifting at ignition and planting a phantom tilt. No single formula fixes three different physical causes, which is exactly why every single formula we tried failed the fleet. What worked was separating them on evidence: the thrust-vector comparison identifies and corrects the shifted-altimeter family, the trust gates recognise rotation the attitude carry cannot follow and decline the fusion cleanly rather than guess, and the honest tilting flights are left precisely alone. The lesson we keep relearning: when a principled fix breaks other flights, it is usually because the problem you are fixing is actually several problems, and the real work is telling them apart.

One of those separations deserves its own mention: the choice of attitude witness. The device's own orientation engine watches the flight at full sensor rate, and the filter uses that logged attitude when it proves itself, validated at the only moment truth is absolute, at rest on the pad, where the logged vertical can be compared against measured gravity directly. On the fleet, the two agree to fractions of a degree, including on sideways-mounted units whose tilt figure reads absurd while the vertical underneath it is perfect. The carried gyro remains as the fallback. Sometimes the right algorithm is recognising that something upstream already has the best view, and building the gate that proves when it does.

Data that is not data

Three guards exist because logs contain things that look like flight data and are not. Rows recorded through a power brown-out read as clean zeros, and clean zeros through a fusion filter are a phantom minus one G, integrated into confident descent. Logs whose descent rows carry no IMU samples were once treated as zeros too, injecting phantom deceleration into a phase that had none; they are now held rather than believed. And one class of logs carried a corrupt gyro burst from before liftoff, rotation that never physically happened, quietly spinning the carried vertical before the flight began. Each earned a specific, narrow guard, and together they hardened the general rule that runs through the whole filter: a fusion filter must know when to refuse. If the evidence is untrustworthy, TrueFuse declines, states it in the header, and the barometer is saved untouched.

Time itself

One more discovery deserves its section because it nearly hides forever: the pressure and IMU streams travel through different sensor pipelines with different group delays, and a fusion filter fed misaligned streams produces confident nonsense. We found one export where the pressure stream lagged the accelerometer by nearly two hundred milliseconds, and the filter behaved exactly as a correct filter fed skewed time must: its inertial altitude legitimately led the barometer up the climb, and the blend read its own head start as an error to be corrected. The filter was right; the clock was wrong.

Two sensor pipelines, each with its own group delay, describing the same climb at different times. Fed to a fusion filter unaligned, this is two different flights.

In depth: barometric pressure sensor lag, and how to correct it

Time found a second, sneakier way to lie to us as well. Our devices change sampling rate through a recording, a slower cadence while waiting on the pad, full rate for the flight, and an early alignment implementation applied the correction by displacing samples in storage, counted in samples rather than in milliseconds, across exactly that rate boundary. A count of samples changes meaning the moment the rate does: the shifted values landed against timestamps belonging to a different cadence, and time itself was quietly stretched or compressed around the boundary. Integrating acceleration across stretched time is a beautiful way to be wrong: one flight's log-integrated velocity came out vastly above what the device had honestly measured live, a huge overshoot, and a family of others under-read for the same reason with the opposite sign. Everything looked self-consistent, because every sample was genuine and only its position in time was false.

The fixes are characteristic of the whole project: no estimating, no inferring the lag from the data. The delay of each pipeline is determined by its configuration, the sensor filter chains, the smoothing, the polling, so the device calculates it and aligns the streams before the filter ever sees a sample. The lag is arithmetic, so we do the arithmetic, identically, every flight. And the alignment is carried as what it physically is, a quantity of time in milliseconds, never a count of samples, because a count of samples is only a time when the rate never changes. The filter downstream neither knows nor guesses anything about timing, which is exactly how it should be.

The final layout

Here is the whole machine in one picture.

TrueFuse 2C: the inertial vertical channel feeding the flight phase supervisor, with the guards alongside and the two outputs below.

Reading it top to bottom: the sample sync conditions the IMU stream onto the pressure timeline before anything else happens. The inertial vertical channel then does its work, the pad vector seeding gravity and gyro bias at rest, the attitude carry rotating that vertical through the flight, the thrust projection taking only the component that gains altitude, and the integration turning it into a velocity and altitude prediction, with the slip watch and trust gates able to reseed or veto the lot. Its inertial altitude joins the barometer and the event stamps at the flight phase supervisor, which walks the flight in order: pad hold, launch fuse, the velocity-scheduled blend fed by its own isolated velocity estimate, the hard apogee handover, and the guarded descent, with the trend sensor alongside, armed from the coast to the landing. Out of the bottom come the two things the whole machine exists to produce: the fused altitude, and the fused velocity derived from it.

That shape now runs on every flight uploaded to AltimeterCloud, and the fleet verdict is the one that matters: it produces the right answer on every flight, with a couple of exceptions that were investigated fully and proven to be errors in the recorded data itself, artefacts of older firmware rather than the filter, and logs of that kind the filter now recognises and declines rather than fuses. Every rule in the mission list is being honoured in the field, on other people's rockets, which is the only place honouring them counts.

Getting it onto the devices

Make no mistake about the scale of the computation. Every sample, and there are four hundred and more of them a second, the filter is carrying an orientation through three-dimensional rotation, projecting the thrust vector, integrating, maintaining its fitted trends, and running every gate and schedule described above. That is an enormous amount of arithmetic, and our altimeters run it on small microcontrollers. On chips with floating-point hardware, like the S3, it is no issue at all. On the 160 and 240 MHz parts without an FPU, every floating-point operation is done the long way in software, and the filter still runs live at 400 Hz and above. Expensive, certainly, but it runs, and it earns its electricity.

The deployment matches each device's job. Mercury and Jupiter fly the filter live, because they act during the flight. The Nano has no outputs and no live functions to worry about, so it runs the same law as post-processing when the flight is saved: the same filter and the same results, applied where it costs nothing that matters. In our tests on the Nano, which has no FPU, TrueFuse adds around twenty to thirty-five seconds to the save of a typical flight, which we believe is entirely acceptable for the flight record being right.

Whichever device it is, the porting rule was absolute: a device runs the same law, not a resemblance of it. The port was carried across statement by statement and held to the only standard that settles arguments: the entire fleet battery, run through the device code, byte-identical to the reference. Not close. Identical. Then it was proven in the field: real flights saved on the device, decoded, and rerun through the reference, matching to the millimetre across every sample, up to the full maximum-length log.

Two device-side pieces earned their keep. The filter needs to know when apogee was, and the live detectors cannot always commit a timestamp on unusual flights, so a causal probe derives the stamps from the recorded data and the header says which kind of stamp was used. And when a recorded burnout stamp is impossible, contradicted by the accelerometer's own record, a repair law reconstructs it from the thrust evidence and marks it repaired. Everything reports what it did. You may detect a theme.

Validation with a tape measure

To see how reliable the fusion is, the best test is something precise. I decided to attempt to throw one from the floor to exactly the ceiling in my office. The ceiling is 3.10m going by the tape measure. The launch detect might not see enough acceleration even with it set to just 1 meter and require the fall back 2.5 seconds. So I had to throw it and catch it above 1 meter for it to actually record. After a good 20 goes this one stopped just before the ceiling without hitting it.

The fusion resulted in 3.066m (pretty good!) and the pressure based altitude gave 2.767m. A clear win for TrueFuse 2C! Despite it spinning in the air and being thrown by hand.

When the same law that bridges three-hundred-metre ejection spikes also wins an argument with a tape measure, we call that a good week.

Improving it, and thoughts for the future

The filter is finished in the sense that matters, it honours its mission on the whole fleet, but it is not finished in the sense of being done, and the roadmap follows the same logic as everything above: better evidence first, cleverer maths second.

Devices that carry a magnetometer can do a far better fusion, and our Jupiter does. A magnetometer is the witness the vertical channel currently lives without: an absolute orientation reference that works under thrust, when gravity is buried and the gyro is on its own. With it, the attitude carry stops being pure dead reckoning and gains something to check itself against for the whole flight.

A second gyroscope, set to a lower rate range, would improve resolution where most flights actually live. A gyro ranged to survive a fast roll pays for that headroom in coarseness at gentle rates, and most of a well-behaved flight is gentle rates. Two ranges, one sensor set watching the extremes and one resolving the fine motion, gives the carry a cleaner integrand exactly where the precision buys the most.

And there is a route for fixed-mounted altimeters. Everything in the current design tolerates the worst case, an altimeter loose in the airframe, because the mission demands it. But a rigidly mounted altimeter is a better witness, and we can probably detect that rigidity automatically, from the same settle-and-converge evidence that exposes the loose ones. A proven-rigid mount would let the filter safely extend its fusion into places the loose-mount assumption currently forbids, without ever asking the flyer to declare anything. Detected, not configured, in keeping with the house rules.

Honest by design

Finally, the part I care about most, and the reason several of the scars above turned into architecture rather than anecdotes. The .aclz log always keeps the unfiltered pressure altitude in its own column, exactly as recorded, next to the fused trace. The flight page shows raw and processed apogee side by side. The header states the filter version, whether it ran or declined and why, which stamps it used and whether one was repaired, and the largest correction it made. The fused velocity is derived from the fused altitude by a plain time stencil, so it cannot tell a different story than the altitude it sits on.

You never have to take the filter's word for anything: the evidence to judge it ships inside every flight. That is not a feature we added to the filter. After everything above, it is the reason the filter deserves to exist.