The reference for the post-processing pass that runs after TrueFuse on every flight: what it is allowed to do that the live filter is not, what it does to the record, and how to read what it did. The TrueFuse page covers the fusion that runs before it.
Version TruePath 6 |
Runs At save, on every device, after TrueFuse |
Input The TrueFuse output, never the raw barometer |
Knows The whole flight, both directions of time |
Never touches The raw column in the log |
What TruePath is for
TrueFuse works through the flight one sample at a time and never sees the future. That is the right rule for a filter whose output has to be acted on in the air, but it has a cost. A filter that cannot look ahead cannot tell a spike is a spike until some of it has already gone through, and it cannot judge a sample against the ones that came after it. TruePath has the view the live filter is not allowed. It runs once, at save, over the finished record, and it does the two jobs a causal filter cannot do well: it removes the artifacts that are left, and it leaves a trace smooth enough to take a velocity from.
It is a post-processor, and that is the limit of its job. It is the only part of the chain allowed to change samples that have already been recorded. Nothing it does feeds back into a decision, nothing it does exists on a device in flight, and nothing it does touches the raw column.
Flight 1485, the example we use when someone asks what TruePath is for. A Rev3 Nano at 49 Hz, pressure only, with an ejection spike where the apogee should be and then sixty seconds of descent with the port alternately shielded and exposed under the parachute. The raw apogee is 349 m. The climb actually stopped at 246.6 m, and that is what TruePath reports.
Two things about that flight before the mechanics. The raw column is not corrected: the 349 m is still in the log, exactly as recorded, next to the processed trace. And every spike on it is pressure the rocket did not fly, so a filter that averaged them would only have produced a smoother version of the same wrong record. TruePath does not average. It decides, sample by sample, whether a sample could have come from the flight around it, and replaces the ones that could not.
Where it sits
The chain at save is raw barometer, then TrueFuse, then TruePath despike, then TruePath smooth. TruePath is fed the TrueFuse output, not the raw barometer. On a flight with an IMU the launch window and the bridged ejection events have already been dealt with by the time it runs, and what reaches it is what the live filter could not know about in time. On a pressure-only board, or a flight where TrueFuse declined, it gets the raw barometer and is the only cleaning the record has. The figures on this page are that case, which is also the harder one.
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.
The despike
The despike is a robust outlier rejection of the kind used throughout instrumentation: each sample is compared with a trend built from the samples around it, and samples that sit too far from that trend are replaced. The details that make it work on a rocket are below. The constants that tune it are not on this page.
A trend the spike cannot drag
The trend is a sliding median, not a mean. A mean is pulled toward the spike it is supposed to be judging, so a big enough artifact moves its own reference and hides behind it. A median is not pulled: as long as the window is wider than the artifact, the artifact is a minority of the samples in it and the median stays on the flight underneath. On flight 1485 the ejection spike at 10.8 s is the highest point in the whole record, and it still sits a long way clear of its trend.
There are three such trends at three widths, short, mid and long. The short one follows the flight most closely and is used wherever it can be trusted. It stops being trustworthy when an artifact is wide enough to fill it, and the filter detects that by the short and long trends disagreeing by more than a real flight could curve across them. Where the short window has been contaminated the mid one is used, and where that has too, the long one. On a clean flight the short window judges every sample and the other two are never used.
How the despike decides, at the apogee of flight 1485. The dashed line is the median trend, the band is its tolerance, and every raw sample outside the band is replaced. The ejection dive at 7.4 s, the spike at 10.8 s and the one at 13.3 s are all judged against a trend that none of them moved.
A tolerance that measures the barometer
The tolerance around the trend is not a fixed number. It is set from the barometer's own noise on that flight, measured in a way the spikes cannot influence, so it is tight on a quiet descent and more forgiving on a rough one. A floor underneath it stops the filter touching anything smaller than a barometer could plausibly be wrong by. The flight page shows what the tolerance came to.
Runs, not samples
A flagged sample is never replaced on its own. Artifacts have edges and tails, and the sample that first crosses the tolerance is usually some way into one, so each flagged run is extended a little either side, further on the trailing side because a pressure event arrives fast and decays slowly. The run is then replaced by a straight line between the clean samples either side of it. A straight line is a deliberately modest choice. It claims nothing about what happened inside the artifact, and TrueFuse, which has the accelerometer, is the part of the chain entitled to claim more.
A second pass then goes over the record with the first pass's runs already removed. The trend it fits to the cleaned trace is no longer contaminated, so the slow tail of a wide spike, which was only a little way off the flight and invisible against the first trend, shows up against the clean one and is added to the run.
The descent of flight 1485 between 28 and 42 s. Each spike is the port shielded from the slipstream for a moment; each is replaced as a run, tail included, by the line between the clean samples either side.
What it leaves alone
The despike does not run over the launch. The launch window is a sustained bias rather than a spike, and seeing the future does not turn a consistent error into the truth; that window belongs to TrueFuse, and on a pressure-only flight it is left as recorded. A flagged run that reaches the start or the end of the record is also left alone. There is no clean sample on the far side to interpolate toward, and an earlier rule that held the last good value flat to the edge put a false altitude on the end of one flight's log. A run that goes on longer than an artifact plausibly can is left too, because by then it is more likely to be the flight.
Gaps are not artifacts
A log can have holes in it, from a device that stalled for a moment or a recovered flight with a block missing. TruePath recognises a gap by its spacing against the sampling rate around it, passes the samples either side through untouched, and restarts its windows on the far side rather than smearing across the hole. The judgement is made against the local rate on purpose, so that hybrid mode's slower logging in the descent is not mistaken for a gap.
The back-fill
TrueFuse cannot open a bridge over a notch before it knows the notch is there, so the first few samples of every notch are on the trace it hands over. Rather than pretend otherwise, TrueFuse records each bridge as an event: when the notch began, when the bridge opened, and the trend it rode. TruePath takes those events and sets the samples between the onset and the opening onto the bridge's own line. Nothing of the artifact survives into the saved file, and the live filter is not asked to have seen something before it could.
The back-fill on flight 2836. The bridge opens the sample the fall becomes impossible; the samples just before it, which the live filter had already let through, are set onto the bridge's line by TruePath.
The smooth
The despike leaves a trace that is right but not yet smooth: the straight-line repairs meet the flight at angles, and the barometer's own quantisation is still in every clean sample. The smooth is a short median followed by a Savitzky-Golay polynomial fit, the standard pairing for this job. The median removes any single-sample residue the despike left; the polynomial fit gives the trace a usable derivative without flattening the peak, which is what a plain moving average does to an apogee. The kernels are spaced out with the logging rate so that they cover the same span of time at every rate, and the flight page reports the spacing used.
Why the smooth matters. The saved velocity comes from the same calculation in both traces; over the raw altitude it is unreadable, over the TruePath altitude it is the flight. The high reading at the start is the launch window on a pressure-only board, which TruePath leaves alone by design.
Velocity
The saved velocity is not a filter of its own. It is a centred difference over a short time baseline on the final altitude, with a few samples averaged at each end to keep the barometer's quantisation out of it. It is a derivative, not a smoother, so it cannot tell a different story from the altitude it sits on, and anyone who differentiates the saved altitude themselves will get the same curve.
What is reported
The flight page carries a TruePath block. Every figure in it describes what TruePath changed about its own input, the TrueFuse output, not about the raw barometer:
| Field | Meaning |
|---|---|
| Filter version | Which TruePath produced the saved column |
| Filter activation | How long after launch the despike was allowed to start |
| Detection floor and threshold | The floor, and the tolerance the flight's own noise set |
| Samples cleaned | How many samples were replaced, out of the total |
| Window selection | How many samples were judged by the short, mid and long trends |
| Caps | How many runs reached a limit and were left rather than replaced |
| Descent change | The RMS difference TruePath made between apogee and landing, a measure of how much cleaning the descent needed |
| Stage 3 tap spacing | The spacing the smooth used at this flight's logging rate |
The processing chain row on the same page gives the order, raw barometer to TrueFuse to TruePath despike to TruePath smooth, and the raw and processed apogees side by side with the difference between them.
What it will not do
TruePath will not fix the launch window; that error is a bias, not a spike, and only the accelerometer can correct it, which is why TrueFuse exists. It will not invent a descent: a long, slow excursion under the parachute that the trends cannot tell from flight is left as it is. It will not hold a value across the edge of a record. And it will not touch the raw column. The pressure altitude exactly as recorded is copied aside before any stage runs and written to the log unchanged, so the evidence to judge TruePath is in every flight, the same as for TrueFuse.
Validation
TruePath is held to the same discipline as the fusion. It is deterministic, so the same input always gives the same output; every candidate change is run across the fleet battery and compared to the previous revision sample by sample; and the device's C++ is a transcription of the website's reference, proven against it on the same logs. A maximum-length log saved on a Nano, decoded from the .aclz and laid against the reference run over the same raw column, differs by a couple of centimetres at its worst sample and by nothing at the median, with the same apogee.
TruePath revision 6 is what the website runs and what current Nano, Mercury and Jupiter firmware carries.