Recorded, then proven.
An attitude instrument is only as good as its evidence. A flight is documented by two records, each started at the pilot's command — the raw sensor stream on the instrument and the computed picture on the display — the foundation for post-mission diagnostics, calibration, sensor characterisation and exact replay. On top of that, the system is checked three ways: by hand, against recorded flights, and in the aircraft.
Two records, each written where the data is born, each under the pilot's control. The instrument, when recording is started, captures its raw sensor stream on its own storage — every sample, with its microsecond timestamp and the complete setup in force — the black box. The display, when logging is enabled, writes a CSV in Documents/PFD/ of exactly what the pilot saw: attitude, tapes, panel settings and the instrument's telemetry, frame for frame. Together they let any flight be re-opened, re-analysed and re-processed long after landing.
The instrument's raw log is more than a stream of samples — its header captures the complete initial state, so a flight can be reconstructed exactly: the calibrations in force, the mounting, the panel and every relevant setting. Raw means uncorrected — precisely as each sensor produced it, each sample stamped on the instrument's microsecond timebase.
| Inertial | accelerometer & gyroscope, raw FIFO stream (960 Hz, body frame) |
|---|---|
| Magnetometer | raw field (100 Hz, uncalibrated) |
| Barometric | pressure (50 Hz) & sensor temperatures |
| Control accelerometer | ±16 g witness stream (100 Hz — saturation control for the main accelerometer) |
| Environment | air temperature & battery telemetry (1 Hz) |
| Time anchors | clock-sync records that tie every sample to the instrument's µs timebase |
Written once at the start, in the file header — what a replay needs to reproduce the live state:
| Panel | QNH, units, alarm thresholds — the cockpit as flown |
|---|---|
| Mounting | level trim (sensor→aircraft rotation) & slip-ball zero |
| Magnetometer cal | ellipsoid (sensor 3D) & installation (2D) |
| Accelerometer cal | 6-face scale & bias |
| Gyro | persisted offset, thermal slope & scale, with provenance |
Every sample, or it doesn't count
“Every sample” is a claim, so it is measured. A recording stalls the main loop as a matter of course — the storage card pauses to program its cells, the radio holds the processor through a transaction, a batch of inertial data takes its turn. Over eighteen hours of continuous recording those pauses were counted: tens of thousands of them, a median of 28 ms. Naming where the longest ones came from took a second instrument — a stopwatch that splits each pass of the main loop into fourteen named stages instead of one bucket called “other” — and the answer was not what had been assumed: 2.4 s to create a session file on a full card, and 248 ms for a single batch of inertial data on its way to becoming attitude. In any one of them, nobody is reading the sensors.
So no sensor is allowed to depend on being read in time. Each one holds its own data until the instrument comes back for it: the control accelerometer keeps 128 samples (1.28 s), and the magnetometer and barometer are carried by transfers that run without the processor at all. The inertial unit, the fastest of the four, holds 256 — and 256 records at 960 Hz is 127 ms, which is shorter than the longest pauses actually measured. A buffer alone was never going to be enough for that one.
It is therefore given a way out rather than a bigger cushion. Whatever holds the processor — a card programming its cells, a file being created, a batch of data being turned into attitude — hands the acquisition a moment back, and in that moment the inertial queue is emptied into memory ahead of anything newer, keeping the recorded order intact. Under continuous recording the queue now runs at half depth where it used to reach the ceiling.
The verdict is not the instrument's own opinion of itself. Every thirty-two samples the inertial unit stamps the data with its own clock, and those stamps go into the file. Between two of them the interval is a fixed number of ticks; if a batch of samples is ever destroyed it takes its stamp with it, and the gap is unmistakable — whatever the instrument believed at the time. Judged that way, four hours of continuous recording — 18.35 million samples across all four sensors — gave 456 495 intervals out of 456 495 exact, and not one sample missing on any of them; the same quarter of an hour, before this work, lost several hundred. And the instrument’s own loss counter is held to the same standard: it has to agree with that file, and it does.
When something goes wrong anyway
The same discipline applies when something does go wrong. A unit in the field once went quiet — attitude frozen, radio still talking — and the answer was not a restart. The board was read in place, through its debug port, while it was still in that state: every interrupt it depended on had been switched off by a stray write from the radio’s own transport layer, a fault that lives in vendor code and would have gone on hiding behind reboots. The transport now checks every pointer it is handed and refuses to run a command inside another; a healthy instrument reports those refusals as zero, and a recurrence names its own cause in the log instead of taking the instrument down.
One sample, six minutes into a twenty-five-hour recording, was enough to stop that recording and start an investigation. The instrument and the file agreed it was gone; what was missing was the reason. A purpose-built test that reads the control accelerometer at chosen instants relative to its own internal clock showed the sensor dropping the very sample it is storing when a read lands on that instant — a fault in the chip, reproducible on the bench in five of sixty attempts inside a fifty-microsecond window and never outside it. Reads are now kept clear of that window; eight hundred attempts later, none is lost, and the counters that would show a recurrence are part of every report.
That finding prompted a wider question: does every sensor get configured and read the way its manufacturer documents, or the way that happened to work? Each device was audited against its datasheet and application note, every claim checked independently twice before it counted. The answer was mostly yes, with a handful of exceptions worth fixing — registers a software reset does not clear on a unit that is never powered off, a reset issued in the wrong order, a read that relied on undocumented courtesy. Each fix was proven the same way: write a wrong value into the sensor on purpose, reboot, and confirm the instrument finds and corrects it — then the usual recordings, judged sample by sample.
The same day a field unit lost its attitude display after being shaken hard. The instrument was healthy in every counter; the filter's state had simply stopped being a number, and the console printed that as zero. Two things followed. A witness now checks the whole filter state after every step and, the first time it is not finite, records where it happened, what went in, what the state was just before — and repairs nothing, so the cause stays visible until an explicit re-alignment. And the cause itself, reproduced on the bench in half a minute with a synthetic near-saturation gyro stimulus: a numerical shortcut deep in the filter's bookkeeping, harmless in ordinary flight, let violent rotation inflate an internal estimate without bound until it overflowed. The shortcut is now the exact computation, proven by ten minutes of the same stimulus and the standard recordings. Saturated samples are counted and shown; a non-number now prints as one.
The same evening, a second finding from the same unit: after a firmware update over a demonstration image, the inertial sensor kept an operating mode the previous image had left behind, and delivered samples at a different rate than the instrument assumed — a software reset does not clear that mode, only a power cycle did. The start-up sequence now sets the mode explicitly, in the state the datasheet prescribes, and reads back the whole control registers rather than the fields it expects; the alarm that caught it now names the registers too. Proven by writing the foreign mode into the sensor on purpose and rebooting.
That finding earned a permanent place on the instrument panel: the app now shows, next to the connection status, the sensor clock rate the instrument measures against its own timebase — and beside it, the rate the sensor's factory calibration predicts. The two agreeing, continuously, is the quiet proof that every sample is arriving at the rate the mathematics assumes; the day they disagree, the fault class above announces itself on the display, no console attached.
Five nights of a four-second stall
A long overnight recording then failed in its seventeenth minute: a single write to the storage card held the instrument for over four seconds, and every buffer in the chain drowned behind it. One real cause was found and fixed — the filesystem had never told the card which blocks a deletion had freed, so the card was doing that housekeeping later, under a full-rate recording; it is now told at deletion time, when latency costs nothing. That was not the whole story. A second run died the same way an hour in, and with the same loss count to the sample — a repeatability that argues against a card misbehaving at random, and for something deterministic in our own path.
This is where an instrument earns its keep. The failed runs were not wasted: the recorder counted every lost sample, and the arithmetic of those counts located the stall to within a tenth of a second from two independent witnesses. Several candidate explanations were then eliminated on evidence rather than argument — each would have left a trace in a counter that exists, and none had.
The next step was to stop waiting for a failure that arrives once every few hours. A bench control now holds the next card write for exactly as long as we ask, on the real waiting path, with the real acquisition running inside it — a six-hour experiment reduced to two minutes. It reproduced the failure precisely: the same slow record, the same lost-sample count to within one of the real event. With the failure available on demand, the witness answered. During a four-second stall the emergency drain that is supposed to empty the sensor queue was taking one small fixed portion and returning, then finding the queue below its own trigger and taking nothing at all — it was rescuing about a fifth of what the sensors produced, and the rest died in a queue that holds a seventh of a second. It now empties the queue instead. Same four-second stall, provoked the same way: zero samples lost, on every sensor, with the queue peaking at half its depth.
A second thread ran alongside. Long recordings had been given one contiguous, pre-allocated region on the card years of experience say to use — appending forces the card to interleave bookkeeping with data, which is what provokes its internal housekeeping to stall a write for seconds. The diagnostic trace written beside each recording had never been given the same treatment, and it is precisely the write that stalled on all four failures: the file that had been fixed never stalled, the one that had not stalled four times out of four.
Reserving the whole session up front has its own costs, though: it means guessing in advance how long the session will be, and a recording interrupted by a power loss strands the entire unused reservation. So the reservation now grows instead. The instrument books five minutes of space at a time and quietly extends the booking while it writes, each extension taking 26 to 36 milliseconds against the tenth of a second its sensor queue can hold. Between extensions the card is asked for nothing but plain sequential data. Starting a recording went from 4.8 seconds to 54 milliseconds, closing one from 4.6 seconds to nothing measurable, and the session length stopped being a number anyone has to know in advance.
Two defects in that mechanism were caught by the instrument's own reporting rather than by review. In the first, the booking was never made at all — a size limit left over from the previous design rejected every request as too small, and both files silently fell back to the behaviour being replaced. In the second, the extension ran only when a recording ended, so the file outgrew its booking by eleven megabytes without a word. Both were visible only because every extension prints a line saying what it did; a mechanism without a witness would have passed for working.
The last thread of the night came from a question about round numbers, and ended somewhere else entirely. A storage card erases memory in large internal units, and a filesystem laid out without regard to where those units begin makes ordinary writes fall across two of them — so the card must rewrite both. The card will say how big its unit is if asked. This one answers four megabytes. The instrument had never asked: it declared four kilobytes, a stand-in value with a comment calling itself a safe default, and formatted every card to that. A thousand-fold out, on precisely the number that decides whether writes land cleanly.
It now reads the card's answer and lays the filesystem out to match, and — because an intention is not a result — it reports where the data area actually starts, so the alignment can be read rather than assumed. It starts exactly on a four-megabyte boundary.
It was never the card
And then the story turned. With every millisecond of the stall window forced to name its place — including an explicit unaccounted figure that is not allowed to stay silent — the next failure pointed away from the card entirely. The write path had done nothing slow and the card reported no error at all; the stall's duration matched, to a hundredth of a percent, one of the instrument's own internal time limits — on the side that reads the sensors, not the side that stores them.
The mechanism, once seen, is a classic of concurrent systems, and it needs no particulars to be told. Two routine activities inside the instrument, each fast and each correct on its own, could land in the same vanishingly narrow moment; when they did, a sensor read lost a little data, and the code waiting for that data waited out its entire generous time limit for bytes that no longer existed — with the whole instrument captive behind it. Five overnight recordings died on a coincidence measured in millionths of a second.
The proof is a capture, not an argument: the failure witness now records the exact state of the machine at the moment of death, and the very next event — provoked within the hour by deliberately running on a full card — showed precisely the state the chain predicted. The first fix was a single deliberate configuration change, prescribed by the manufacturer's own documentation for exactly this case, enabling a safeguard that stops data from being lost in the collision.
The twenty-four-hour proof
Every repair here faces the same rigorous proof: a full twenty-four-hour recording, judged sample by sample, where a single lost sample ends the run and starts an investigation. That proof run then did its job by failing. Forty-seven minutes in, one collision cost ten samples and the run stopped itself. This time the witness photograph told the whole story in one night: the safeguard had worked — nothing was corrupted — but the fine print in the manufacturer's documentation puts the job of resuming a paused transfer on the software, and the vendor's library never does it. The repair follows that fine print to the letter, and it was verified line by line at the source before touching the instrument — a verification that caught the first version of the patch missing its target, something a clean build cannot show. Collisions are now counted as they are absorbed, so a quiet journal proves they happened and cost nothing, rather than that they never came. The twenty-four-hour proof began again on this repair; its criterion was unchanged and written down in advance — zero lost samples and not a single failure line.
It passed. The third long run went the distance — twenty-six and a half hours, ninety million inertial samples, seventy-one collisions absorbed and counted — and the verdict was read off the file afterwards, sample by sample, not off the instrument's own tally: nothing lost, nothing out of order. The same night the judge itself was put on trial. An independent audit of the tools found that the program certifying every recording skipped its first few samples and would have accepted a damaged first or last block without a word. It was repaired and then proven the way the instrument is proven: ten faults injected into a clean recording, every one convicted by the new judge, six of them waved through by the old.
The recording also settled a question three earlier nights could not. On each of those, the die temperature and the clock fell together, so no analysis could tell a thermal effect from plain drift. This run spanned a full day and night, temperature and time finally parted ways, and the gyroscope's thermal coefficient became measurable from differences alone — with a placebo regressor alongside to show what a bare correlation is worth here. The day showed up too: one gyroscope axis read a fifth higher than on the earlier nights, and instead of being filed as a curiosity it was measured hour by hour. The excess lived in a narrow band, on one axis, for ten afternoon and evening hours, and vanished at night — something in the room, not in the sensor. Its source is still open; the sensor's own figures are read from the quiet hours.
The storage card, for the record, was innocent all along. Its slow moments — a few writes per hour stretching to a quarter of a second — were real, measured, and absorbed without losing a byte. What looked for five nights like a card misbehaving was the instrument measuring its own write window and finding someone else's timeout inside it.
One postscript, from the housekeeping between runs: maintenance is not an intermission. The instrument keeps every sample while its storage is being erased, formatted, or checked — and that zero is measured after each such window, not assumed. Deleting a multi-gigabyte file while recording was the case that broke this, in the very test written to catch it: freeing a file that large keeps the filesystem busy for longer than the recorder can hold its breath, and the first answer was to refuse such a delete mid-flight, by name. The refusal lasted one night. The delete is now a background job of the instrument's main loop: the file is cut back one slice at a time, one slice per pass, and a slice starts only when the recorder's buffer is nearly empty, so the recorder always drains between two cuts. Nothing is refused by size any more; every finished file reports how many slices it took, how long, and the slowest cut — and the recording around it is judged sample by sample. Proved the same morning with a 200 MB file deleted inside a ten-minute recording: 12 slices, slowest 215 ms, zero samples lost.
The same night showed the limit of the instrument's own diary. Its in-memory journal kept the first four kilobytes of a session and refused everything after — twenty-two thousand lines in one night, counted but gone, so a fault at hour nineteen left no story at all. The journal now keeps the boot sequence whole and, after it, a ring in which the newest lines win and the evicted ones are counted; alarm lines are kept aside where nothing can evict them. A reader that takes seconds to drain the journal over the radio follows the ring by position, so lines overwritten under it are never handed out, and the dump ends by saying how many went by.
The audit that judged the tools also judged the instrument itself, and the seventy-four findings it raised are now closed in the firmware. They share one rule: nothing may fail quietly. A fault that would once have ended as an anonymous reset now writes down what the processor knew at the instant it tripped, and says so at the next start. A refused erase reports the refusal instead of success. A temperature that has never been measured prints as nan, never as a plausible zero. Where the instrument cannot certify an interval, it counts it as lost rather than as nothing.
Two of the repairs were found by the proofs themselves, which is the point of running them. The line that records a processor fault turned out to be longer than the journal's own limit for a single message, so the very number that says how many faults have happened was being cut off — found by injecting a fault on purpose and reading the result. And the loss counter read zero on the console while the panel in the aircraft read six, in the same second: two true answers to two different questions wearing one name. The instrument acquires continuously, whether or not the samples are being written to a card, so the counter now counts continuously too — and the recording's own verdict keeps its answer under a name of its own.
Raw data turns every flight into a dataset you can interrogate on the ground. Three things it makes possible:
Diagnostics
Replay a flight and read the filter's gate activity, sample by sample — see exactly which check blocked a correction, and when.
Calibration — σ
A static recording yields the per-axis noise std-dev (σ) that sets each sensor's weight — the measurement covariance R — in the estimator.
Characterisation
Allan variance and PSD reveal the noise structure: random walk, bias instability, and the vibration peaks that set the filter cutoff.
The test itself is simple: lay the IMU still on the bench (or spin it at a constant rate on a turntable) and record for a few minutes. A still log isolates noise and drift; a constant-rate log adds scale-factor and linearity. From that one recording the sensor is qualified:
| Noise level (σ) | How jumpy the readings are while the sensor sits perfectly still. A quieter sensor (small σ) is trusted more by the filter. |
|---|---|
| Short-term noise | The random flicker from one sample to the next — the downward slope of the Allan curve (slope −½, white noise). It sets how fast a gyro-only estimate drifts away. |
| Bias instability | The best the sensor can do: past a point, averaging for longer stops helping. It's the bottom of the Allan curve (the minimum) — the single most telling quality number. |
| Long-term drift | How far the zero point wanders over minutes — the upward slope of the Allan curve (slope +½, rate random walk). It says how often the attitude needs re-aligning. |
| Noise floor | The steady background hiss across all frequencies on the PSD — a second, independent check on the noise level. |
| Vibration peaks | The spikes on the PSD, where the engine and airframe shake the sensor — these set the frequency the vibration filter must cut. |
In short: a still recording tells you how good the sensor is and how much to trust it. Those numbers — measured from the unit in hand, not copied from a datasheet — are what set the filter's weights and its vibration cutoff, and let two sensors be compared head to head.
Characterisation runs on the instrument's own raw logs, via the exact recipe above — what is characterised is the sensor as the filter consumes it, which is precisely what the measurement covariances need. The definitive figures follow the full-length bench characterisation of the production instrument and will be published here.
Because both records exist, a flight can be replayed two ways. The raw log replays on the instrument itself: the recorded stream is fed through the identical live pipeline — the same filter, the same numbers, bit-exact against the original flight, proven on the bench run after run. Or replay the display log on the device to reproduce exactly what the pilot saw — frame for frame.
And because a recorded log replays deterministically — the same samples in, the same result out, every time — it doubles as a tuning and diagnostics bench. One flight can be run again and again while a candidate filter or a new parameter set is measured against the previous solution on real data, with no aircraft and no waiting for weather. The same loop isolates a fault: feed in the exact data that misbehaved and step through it until the cause is found.
Re-run
The raw log drives the identical live pipeline on the instrument — live and replay agree bit-for-bit by construction, and a new filter is tested on real flights.
Tune & diagnose
Replay one flight repeatedly while sweeping σ, cutoffs and gains — deterministic, so tuning converges and a fault can be stepped through to its cause.
Compare
A candidate solution is diffed against the previous one over a library of real data — regressions are caught on the ground.
Move the IMU by hand and watch the horizon, heading and tapes respond immediately and in the right sense — pitch up, bank left, turn through a heading. Demo mode supplies synthetic motion, so the full display can be exercised with no hardware connected at all.
| Needs | the device (IMU optional) |
|---|---|
| Checks | sense & response of each instrument |
| Modes | live IMU, internal sensors, demo |
A compass calibrated in Switzerland tells you nothing about a compass in Brazil. Earth's magnetic field spans roughly 22 to 67 µT across the globe — a three-to-one range — so the instrument is field tested at both ends of what it will meet.
The hard case was measured on a beach at Cumbuco, Brazil, inside the South Atlantic Anomaly — the weakest geomagnetic field on Earth. The local field there measured 19.1 µT, against roughly 48 µT at the development bench in Geneva, with the instrument's own magnetic signature four times larger than the field it had to measure. Every collection threshold in the magnetometer calibration is now a fraction of the locally measured field rather than a fixed figure, and the calibration converges to the same centre in both places.
| Weak-field site | Cumbuco, Brazil — 19.1 µT (South Atlantic Anomaly) |
|---|---|
| Reference site | Geneva, Switzerland — ~48 µT |
| Design range | 22–67 µT, thresholds scaled to the measured field |
| Convergence | fit residual 7 mGa; centre agrees with an independent offline sphere fit to 1 mGa |
The display is flown in a real aircraft (a Robin DR400) and compared against references it doesn't itself use — bank derived from GPS ground track and speed, and altitude from the barometric reference — so attitude is checked against independent physics, not against itself.
| Platform | Robin DR400/180 |
|---|---|
| Bank reference | GPS ground-track & speed |
| Altitude reference | barometric |
| Goal | true bank in sustained turns |