The problem with single-flight forensics: one log shows you one flight. The interesting question — "is this airframe degrading?" — only becomes answerable once you've accumulated a few flights from the same drone and compared them. Maestro Flight Review builds that history automatically, on your machine, as you analyse. After a handful of flights per airframe, it starts surfacing maintenance trends and flagging anomalies against that drone's own baseline. Free. No cloud, no subscription, no account.

What the archive captures

Every time you drop a .ulg into Maestro Flight Review and the parse succeeds, the parsed summary gets recorded in a local JSON store under your OS user-data directory (it survives reinstalls and never syncs anywhere). The store is hash-deduplicated, so re-analysing the same flight doesn't double-count toward baselines.

The record includes:

  • The full parsed summary — mode timeline, battery / GPS / position trends, log messages, dropouts, and roll-up stats
  • A stable per-airframe key derived from the flight controller's identity, so flights from the same drone group together automatically across reflashes
  • Auto-tags derived from the data: errors-logged, battery-critical, gps-loss, reactive-rtl, vibration-high, long-flight, acro-mode, and more
  • An optional free-text operator note

Storage is generously bounded (oldest flights pruned beyond the cap), and the on-disk footprint stays small — a fleet's worth of flights sits comfortably inside a single modest JSON file. Your operator profile owns it; back it up however you back up the rest of your home directory.

Per-airframe rolling baselines

For each airframe, Flight Review maintains an incrementally-updated baseline of every interesting metric — a running mean and standard deviation that updates with each new flight, without holding the raw history in memory. The metrics tracked include:

  • Minimum battery percentage — how low the pack got
  • Maximum altitude, maximum speed, and total distance flown
  • Flight duration
  • Mode changes, GPS-loss events, error count, and warning count
  • Accelerometer and gyro vibration (RMS)
  • Minimum satellites and worst-case GPS HDOP

Once a drone has enough flights on record, the per-flight panel starts showing an Anomalies vs Your Baseline section — any metric that's well outside that airframe's own historical range gets flagged with the value, the baseline, and how far it deviates. A flight that lands far below its usual battery margin, for example, is the kind of signal that's invisible to single-flight forensics but obvious in cross-flight context.

Maintenance trends — the regression layer

Once a drone has accumulated enough flights, Flight Review fits a trend line to each metric over time and surfaces the trends that hold up statistically. The output classifies each one as improving, degrading, or stable, depending on whether higher-is-better (battery margin, satellite count) or lower-is-better (vibration, error count, GPS HDOP).

The kind of finding this is designed to produce reads like this:

Landing-battery margin trend: degrading. This airframe's recent flights show a steady decline in landing-state battery margin, where its earliest tracked flights landed with far more headroom than its latest ones. The pattern is consistent with cell wear or thermal drift on the pack. Suggested action: bench-test the battery and rotate the drone to inspection before the next operation.

This is the kind of thing manned-aviation maintenance shops have done for decades with engine-hours data. Applied to drone telemetry, the same statistical machinery is built to catch issues weeks before they'd surface as a single dramatic flight. No proprietary monitoring stack, no fleet-management subscription — just trend analysis on data Flight Review already has.

Auto-tagging and a searchable archive

Every analysed flight gets stamped with rule-based tags so you can find it again. Browse the archive via the Archive tab in Flight Review and filter by tag (show me every flight that triggered a reactive RTL, every flight in ACRO mode, every long flight), or by airframe (just show me this drone's history).

The tagging is deterministic and rule-based, not AI-driven — it runs locally, produces the same tags every time, and needs no API key. If you connect your own model API key, a conversational layer sits on top for ad-hoc questions: "of the flights tagged battery-critical, which airframe is responsible for most of them?"

Why local-only — and what that means for compliance

The whole archive lives on the operator's machine. We made that decision deliberately:

  • Sovereignty. Your flight data is your operational IP. We don't get to see it, we don't get to monetise it, and we never become a data processor that has to comply with your customer's regime.
  • No infrastructure cost to us — which is part of how we keep the product free.
  • Air-gap compatible. The baselines, trends, and anomaly flags all run on a machine that's never touched the internet. The only thing that needs a network connection is the optional AI analysis.
  • Backup discipline is yours. The history file lives in your OS user-data directory. Back it up the same way you back up everything else on the operator's machine — Time Machine, a NAS, or a network share you point Flight Review at via the MAESTRO_USERDATA environment variable.

For teams whose authorisations call for centralised retention, pointing Flight Review at a shared network path is the right answer for most: several operators can review the same archive when they need to. If you have a requirement we haven't accounted for, tell us what you need from a Team plan — we'll build the centralised features once we know what's actually required.

What this looks like in practice

A workflow that fits a small multi-drone programme:

  1. After every shift: pull the .ulg files off the SD cards and drop the whole folder into Flight Review. Per-sortie reports plus shift-level pattern analysis tell you what happened across the day; each per-flight card flags any individual sortie that deviates from its airframe's baseline.
  2. Weekly review: open the Archive tab and filter by airframe. Check the trends panel — is anything degrading? Service that airframe before the next operation.
  3. Incident review: when something goes wrong, search the archive for similar tags. "Last time we got gps-loss here, what did we do?" The archive becomes your fleet's institutional memory.

What no single-flight log viewer can offer

This is the differentiated half of Flight Review. PX4 Flight Review doesn't hold your fleet's history. pyulog is one-flight-at-a-time by design. The hosted paid tools provide cross-flight aggregation, but only after you upload all your logs to them and pay monthly. Maestro Flight Review gives you per-airframe baselines and maintenance trends locally, free, with your own choice of AI model.

That's the wedge. When your single-drone work grows into a multi-drone operation, the Maestro platform is the next step in the same Mac app — letting the drones you already fly coordinate, perceive, and act as one system. But Flight Review is genuinely useful on its own for anyone flying PX4, and it stays free forever.

Get the build

Free download for Mac: Download Maestro Flight Review (Apple-signed app for Apple Silicon, no email gate, no account).

Related reading: Introducing Maestro Flight Review · Multi-file and fleet-aggregate analysis · Getting an AI model API key.