Recorded, then proven.

Every session — live, simulator or replay — is recorded to a companion pair of CSV files in Documents/PFS/ that share one timestamp: the display log (what the pilot saw) and the sensor log (the raw data and the exact setup behind it). Together they let any flight be re-opened, re-analysed and re-processed long after landing.

Fig.01 — One session, two logsDISPLAY & SENSOR

The sensor log is more than a stream of samples — it captures the complete initial state, so a session can be reconstructed exactly: the calibrations in force, the alignment, the learned biases and every relevant setting. Raw means uncorrected — magnetometer in raw µT, gyro and accel before calibration — precisely as the sensor produced them.

Inertial	accelerometer & gyroscope (raw, body frame, configurable up to 250 Hz)
Magnetometer	raw µT (uncalibrated)
Barometric	pressure (hPa) & Inertial Measurement Unit (IMU) temperature (°C)
GPS	lat, lon, ground speed, track, altitude
Quaternion	sensor on-board fusion via Bluetooth Low Energy (BLE)
Battery	voltage (ESP32)

Written once at the start as initial conditions — what a replay needs to reproduce the live state:

Settings	QNH, units, aircraft, filter, IMU mounting, mag declination, vibration cutoffs, GPS-aid
Align	gravity correction, gyro offset, initial quaternion
Magnetometer cal	ellipsoid (sensor 3D) & installation (2D)
Accelerometer cal	6-face scale & bias
Gyro bias	persisted online estimate
Diagnostics	filter-gate activity, vibration RMS (root-mean-square) & recommended cutoff

Raw data turns every flight into a dataset you can interrogate on the ground. Three things it makes possible:

Fig.02 — Sensor characterisationAllan variance, PSD

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.

Gyro — random walk (measured)	0.32–0.33 °/√h per axis (Allan −½ fit, IEEE Std 952; 204 min raw log at 250 Hz)
Gyro — bias instability (measured)	6.3–6.4 °/h (converged interior Allan minimum / 0.664; stable within ±2% as the record grew from 115 to 204 min)
Accel — output noise (measured)	σ ≈ 0.002 m/s² at rest — below one quantisation step, exposing the IMU firmware's internal low-pass

First bench characterisation of the production unit, from raw logs via the exact recipe above. What is characterised is the sensor as the filter consumes it — the BLE output stream — which is precisely what the measurement covariances need.

Fig.03 — Measured: gyro Allan variance & PSDbench, 204 min @ 250 Hz

Because both logs exist, a flight can be replayed two ways. Feed the raw log back through the processing and it re-runs the full pipeline — so a new algorithm can be measured against the previous solution on real data, on the desktop, before it ever flies. Or replay the display log 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. The raw sensor data is re-injected synthetically into the live pipeline, so one flight can be run again and again while sweeping the filter's parameters — the σ weights, the vibration cutoffs, the gains — until the output converges, 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.

Fig.04 — Replay two waysre-run, reproduce

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

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