Flight Report — How It Works

A Post-Flight Report, Generated at the Pad

The rocket is down. Before you've packed up the ground station, you long-press the tracker, tap Flight Report, and a multi-page analysis opens — peak altitude with Mach number, motor burn data, deceleration through the aero phase, apogee details, recovery descent rates, GPS drift, signal quality, an altitude profile chart, and a list of advisories. You can read it on the spot, share it as a paginated PDF, or email it to us with a note about anything that looks off.

The Flight Report is built entirely from the radio telemetry the ground station already has. No file import, no laptop, no cable.

The Idea

A radio-telemetry capture is a stream of small, type-coded packets — the rocket's flight computer announcing its state, sensor readings, GPS fixes, and Kalman-filtered estimates roughly once or twice a second during descent and several times per second during ascent. Each packet has a checksum, so we know which ones survived the link intact. A complete .telem file is the chronological log of everything the ground station heard during the flight.

The Flight Report is a one-pass analysis of that log. We walk the file from beginning to end, watching for state-transition packets to find the boundaries between flight phases (boost, fast, coast, drogue, main, landed); recording the peak Kalman-filtered altitude, speed, and acceleration as we go; capturing the speed and altitude at each phase change so we can compute durations and rate-of-change; and counting valid-versus-invalid packets so we can report the link's health honestly. Once the pass is finished, we render it all into a self-contained HTML document with an inline SVG altitude chart.

Phase boundaries come straight from the flight computer — we read its reported state changes rather than guessing them from sensor data. That makes the report's timeline match what the rocket itself thought was happening, which is the right reference for any post-flight conversation.

Where the Numbers Come From

Each section of the report is computed differently, and the differences matter when you're comparing values or troubleshooting.

Headline performance. Maximum altitude is the highest Kalman-filtered height seen anywhere in the flight. Maximum speed and maximum acceleration are restricted to the boost phase only — the powered-ascent window between liftoff and motor burnout. This matches the desktop AltosUI convention. Without that restriction, brief deployment transients during recovery can spike the numbers and bury the actual flight performance under noise. If you've been comparing iOS report numbers to a "boost-phase max" elsewhere and they match, this is why. If you've been comparing to an unrestricted "all-time max," the iOS numbers will look slightly lower — that's intentional.

Phase timeline. We capture the height and speed at the exact tick the flight computer announced each transition. Boost-to-fast, fast-to-coast, coast-to-drogue, drogue-to-main, main-to-landed: each one is a recorded moment in flight, not an interpolation between samples.

Motor performance. Burn time is the duration of the boost phase. Peak and average acceleration are the maximum and arithmetic mean of the Kalman-filtered acceleration during boost. Burnout speed and altitude are the speed and height the rocket had at the moment the flight computer left boost.

Aerodynamic deceleration. We report the speed lost during the fast phase as the difference between the speed at burnout (start of fast) and the speed at the start of coast. This is the speed the rocket lost to drag and to gravity over that window — on a near-vertical flight gravity's contribution is small, but on a tilted flight it can be a noticeable share of the total. The label "aerodynamic deceleration" is the rocketry-community shorthand; the underlying number is a simple speed difference, not a drag-isolated calculation.

Peak drag deceleration is the steepest point on the speed-versus-time curve during the fast phase — the largest sample-to-sample rate at which the rocket was shedding speed. Because the radio link samples at a few hertz during ascent, the derivative is windowed over roughly 100–250 ms; the true peak deceleration lives at a finer time scale than the radio carries. The reported value will read consistently lower than what AltosUI desktop computes from the onboard .eeprom log. Both numbers are derived directly from the Kalman speed series — we are not modeling drag from first principles.

Apogee. Reported as the altitude and time of peak height, the duration of the coast phase that preceded it, and the gap between apogee and drogue deployment. At ordinary altitudes a small gap (a few tens of meters) is a sign that apogee detection and deployment were tightly aligned. A large gap at ordinary altitudes can be a flag — late detection, baro saturation, or a deployment-charge timing issue. Above the baro ceiling, the gap value is geometry between two Kalman-extrapolated heights, not a physical altitude difference; the advisory that comments on apogee gap is suppressed up there for the same reason, and the timeline value should be read as a sanity check, not a measurement.

Recovery. Drogue and main deploy altitudes come from the heights captured at the firmware-reported state transitions. Descent rates are time-averaged over each phase — total altitude change divided by total duration. The main descent rate accounts for landing elevation: if the rocket lands at a different altitude than the pad, we use the actual altitude difference rather than assuming the rocket touched down at zero. Landing speed is the speed reported at the landed transition, not the last sample in the file — Kalman filters can ring for several seconds after touchdown, and the speed at the moment of state change is the right reference point.

GPS drift. The pad location is the first GPS fix the rocket reported with at least four satellites locked. Landing is the last good fix at the moment the flight computer announced the landed state. Drift distance and bearing between those two points are computed as the great-circle distance and initial bearing — the same geometry used by the Recovery tools.

Stability (IMU-equipped flight computers only). Off-rod tilt is the angle the rocket made with vertical at the moment it left the launch rail. Maximum boost tilt is the largest tilt angle observed during powered ascent. Both are read from the flight computer's IMU stream during boost.

Signal quality. Total packets received, valid packets (checksum passed), invalid packets (checksum failed), and a per-type breakdown so you can see whether you lost mostly sensor frames, mostly location frames, or a mix. This is the link's health, not the rocket's.

The Altitude Chart

A single inline SVG chart at the top of the report: altitude versus time, with vertical dashed lines marking each phase transition. The series is decimated to a few hundred points — enough resolution to see the shape of the flight without making the chart heavy to render or print.

For high-altitude flights, the chart honors the barometric ceiling. The altitude sensor on Altus Metrum flight computers saturates somewhere around 30 km; above that point, the Kalman filter's altitude is an extrapolation from accelerometer data, and the chart says so by switching to a dashed trace above the ceiling. Below the ceiling the trace is solid. You're looking at the difference between "measured" and "estimated" without us having to label it.

The chart auto-scales to the active flight. If the rocket landed and the ground station kept logging, the post-landing flat line is clipped — the chart shows the flight, not the cooldown.

When the Capture Was Cut Short

If telemetry stopped before the rocket reached the landed state — antenna shadow on descent, range exhausted, ground-station glitch — the report is honest about it. A signal-loss banner appears at the top. The "Landing Location" label changes to "Last Known Position." Drift distance and bearing are suppressed because we can't compute drift to a landing we never saw. Landing-speed and hard-landing advisories are suppressed for the same reason. The altitude chart adds a "Signal Lost" marker at the right edge of the trace, so it's visually obvious that the data ends there rather than at touchdown.

The detection rule is simple and conservative: if there is no landed state transition packet anywhere in the file, the flight is treated as truncated. We do not guess. A capture that ends mid-descent does not get a synthesized landing.

The Advisories

The "Observations & Recommendations" section flags things worth a second look. The thresholds behind it are engineering judgment from rocketry experience, not certifications:

• Drogue descent rate above 30 m/s suggests an undersized drogue or a spill hole; below 10 m/s suggests excessive drift risk.
• Main descent rate above 10 m/s flags a hard-landing risk; below 3 m/s flags excessive drift under main.
• Landing speed above 8 m/s suggests checking for impact damage.
• Main deploy altitude below 100 m is dangerously low for full deployment time; above 600 m is a long drift.
• Peak acceleration above 30 G suggests verifying that flight components are rated for the load.
• Burnout speed in the transonic range (Mach 0.95 to 1.1) suggests verifying fin rigidity; supersonic suggests checking for aerodynamic loads on every joint.
• Off-rod tilt above 10° suggests checking launch rail alignment; maximum boost tilt above 20° suggests adding fin area or nose weight.
• Signal quality below 80% valid packets suggests checking the antenna, the orientation, or the link budget.

Each advisory closes with a cross-check disclaimer. These are flags, not findings. A landing-speed advisory of 8.1 m/s might be a hard landing on hard ground, or it might be a healthy descent into deep grass. Read the report, look at your rocket, and use your judgment.

Three Ways to Get a Report

The same analysis pipeline serves three input paths:

1. Live flight, on the spot. Long-press a tracker on the Map or Recover tab and choose Flight Report. The report opens against the .telem file the ground station has been writing for that flight.
2. A .telem file in the Files app. Tap a .telem file in the Files app to see a Quick Look preview with peak altitude, callsign, and date — useful for browsing a flight library. Tap Share → Open with AltosUI, or long-press and choose Open with… → AltosUI, to generate the full report.
3. Anything you can get into the Files app. iCloud Drive, AirDrop from another device, email attachment — drop a .telem file into Files and either path above gets you the report. No import step, no setup.

The Quick Look preview uses a deliberately lightweight parser that extracts only the headline values for fast browsing. The full report runs the full analyzer.

Sharing the Report

Tap Share to export a paginated PDF — letter-size pages, proper margins, tables that don't split across page breaks. The PDF preserves the chart and all sections.

The experimental banner at the top of every report includes a feedback email link. Tap it and the system mail composer opens with the PDF already attached and pre-addressed to us. You can describe what looks wrong or surprising, attach a photo of the rocket, and send. The PDF gives us exact context for whatever you're pointing at.

Where This Sits Among the Tools

The iOS Flight Report is one of three tiers of post-flight analysis Altus Metrum users have available, and it helps to know which tier you're holding.

At the launch site, on your phone: the iOS Flight Report covers the headline numbers, phase timeline, motor and aero metrics, recovery, GPS drift, signal quality, and advisories — generated from the radio capture, no laptop or cable required.

Anywhere, on a desktop, from the same .telem file: the AltosUI desktop tools take the same radio capture and add zoomable multi-channel plots, thrust curves, GPS-track maps, and CSV/KML export. You can hand a .telem from your phone to the desktop via iCloud Drive, AirDrop, or email — the rocket doesn't need to be in your hand for that path.

After recovery, from the rocket's onboard log: the AltosUI desktop tools opening a .eeprom file are the authoritative record. The onboard log is sampled at full rate (around 100 Hz versus the radio's once-per-second descent rate), at full sensor precision, with channels the radio doesn't carry. This is the data for records submissions, motor characterization work, and any deep flight-dynamics analysis.

The iOS report is built to be useful where it lives — at the pad, before you've packed up — not to replace the deeper tools.

What This Isn't

It is not a full-rate sample of the flight. The radio link can carry roughly one packet per second during descent, faster during ascent. Fine-grained motor dynamics, the exact timing of apogee inside a half-second window, and short-duration deployment transients are all undersampled compared to the onboard log on the rocket. If a number in the report looks slightly different from what AltosUI desktop shows you from the .eeprom, the .eeprom is correct.

It is not a measurement above the barometric ceiling. Altus Metrum altimeters use a baro sensor that saturates around 30 km. Above that, the Kalman filter is integrating accelerometer data and the chart shows a dashed trace to make the distinction visible. The numbers above the ceiling are estimates, not measurements.

It is not a substitute for an .eeprom download for record-attempt flights. The radio record is subject to dropouts. The onboard log is not. Records bodies want the lossless record.

Its advisories are heuristics, not certifications. The thresholds in the recommendations section are tuned to flag things worth checking. They are not pass/fail criteria. A report with no advisories is not a certification of a clean flight, and a report with several advisories is not a finding of a bad one. Read your rocket alongside the report.

It is not anything more than what the link delivered. If the radio capture is missing the boost phase because the antenna was on the wrong side of the truck at liftoff, those numbers are missing. If the capture ends in mid-descent, drift and landing values are absent. The report tells you so explicitly rather than synthesizing values.

What You Need

• A .telem file — either being written live by the ground station, or accessible through the Files app
• For live flights: an active telemetry connection to a TeleBT ground station

No network is required. The report and its altitude chart are self-contained HTML, generated and rendered entirely on the device.

This is an experimental feature, deliberately labeled as such to invite feedback. Tap the email link in the report banner and send us the PDF along with anything that looks off, missing, or worth a second pair of eyes.