How the numbers are made, and when they are not good enough to act on

Every value in a report is a measurement with a definition and a confidence. This page writes both down, including the cases where the tool refuses to raise a gain. If a recommendation cannot be traced to a rule and a measured value, it should not be in the report.

What is read from the log

Input	Source	Used for
Gyro and setpoint per axis	Blackbox frames	Step response, tracking error, overshoot, steady state
Motor output	Blackbox frames	Saturation checks and propwash segments
Throttle and time	Blackbox frames	Segmenting the flight into cleaner and noisier windows
Header PIDs, filters, sliders	Log header	Starting point and the before column of every change
Firmware, loop time, logging rate	Log header	Which tuning path applies (CLI integers vs simplified sliders)

Step response, defined

Normalisation. Both the commanded setpoint and the measured gyro are divided by the commanded step size, so a 200 °/s flick and an 800 °/s flick are comparable. The old estimator divided each curve by its own maximum, which made the measured peak exactly 1.0 and guaranteed 0 % overshoot.
Window. 250 ms by default, cut at the point where the pilot releases the stick. A tap that ends after 100 ms cannot be measured against a 250 ms window, so the segment is marked and the chart loses confidence rather than inventing a settle time.
Rise time. 10 % to 90 % of the final value, linearly interpolated between samples, in milliseconds.
Settling time. The last moment the response is outside ±5 % of its final value, in milliseconds.
Overshoot. Peak above 1.0 against the commanded step, and separately peak against the response's own final value. The second one is the damping number; the first also contains a steady-state offset, which is an I/FF problem, not D.
Steady-state ratio. Final value divided by commanded value. Above 1.08 the gyro is carrying more rate than asked for; that is a surplus, not a bandwidth shortfall, and it blocks gain raises.
Tracking error RMS. Root mean square of measured minus commanded over the window.

A worked example, from the published log

The flight behind /demo measured roll at 8.63 % overshoot, 54.85 ms rise and 86.65 ms settle; pitch at 28.85 %, 47.45 ms and 69.79 ms; yaw at 22.42 %, 100.62 ms and 157.02 ms. All three charts were graded good.

The bandwidth estimate is 350 / riseTimeMs, the 10–90 % rise-time approximation (0.35 / riseSeconds). For roll that is 6.4 Hz, which the engine reports as 18 Hz because 18 Hz is the floor: below that, the number says more about the analysis window than about the aircraft. A rise of 55 ms is slow for every profile, so this axis is treated as a bandwidth shortfall rather than a damping problem. The engine responds with a small nudge, not a jump, and only because the chart is chart-grade.

The rules that turn a measurement into a change

A change comes from a comparison between the measured shape and a target shape for the selected profile. The size of the change scales with the measured gap: a response near target moves a little, one far off moves more, up to a cap that differs by profile. The direction is fixed by the measurement — slow and overdamped means more gain, overshooting means less, and a steady-state surplus blocks a gain raise entirely.

The targets, the caps, the weights and the coefficients that turn a gap into a number are not published. They are the product, they are recalibrated whenever real logs disagree with them, and a published coefficient table would turn a measurement into a recipe anyone could apply without ever uploading a log. What is published is the set of rules that decides whether a change is allowed at all:

Overshoot is a ceiling, not a setpoint. A well-damped response is left alone; low overshoot never reduces D.
Weak evidence cannot raise gain. The hard rule below applies before any coefficient is evaluated.
Only measured axes can move. A missing pitch step cannot produce a pitch change from the step response; only spectrum-based changes survive.
Filters come from the spectrum. Filter changes are derived from measured peaks, not from the gain loop, so they still apply when the step chart is weak.
Every line is bounded. No single report can move a parameter without a limit, and the before/after table always shows the value it started from.

An illustration of the decision, with made-up numbers

The numbers in this example are invented to show the shape of the reasoning. They are not the values the product uses, and no value below can be used to predict a real report.

Suppose a profile's overshoot limit were 10 % and the roll chart had been graded good.
Suppose it measured 13.4 % overshoot against its own final value. That is 3.4 points above the ceiling, so the direction is fixed: reduce damping, never increase it. How far it is reduced depends on the size of the gap, the evidence weight and the profile cap — none of which is implied by this example.
Suppose pitch instead measured 4.1 % overshoot — below the ceiling — with a weak chart grade. Nothing is raised, because the chart cannot show tracking, and nothing is reduced, because overshoot below a ceiling is not a fault. The correct output for that axis is no change.

That last case is the one worth understanding: a report that changes nothing on a well-behaved axis is the method working, not the method failing. A tool that always finds something to move is a random number generator with a legend.

Hard rule: if the step chart is weak or missing, master, P and feedforward are capped at 1.0×. A chart that cannot show tracking cannot justify more of it. D-term and filter changes still apply, because they come from the spectrum, which is measured independently.

Confidence grades

Grade	What it means	What it may move
`good`	Step at least 100 °/s, setpoint held through the window, response settled inside it	Gain, D and filters, within the profile's caps
`weak`	Small step, setpoint moved, response still moving at the end, or a tap with no hold	No gain raise; spectrum-based changes still apply
`unusable`	No response, no rise, or fewer than 10 usable samples	Nothing from the chart; spectrum-based changes only

Log quality is scored separately and is shown before the tune. A short, hover-only or noisy log is not a failed analysis; it is a log that cannot answer the question. The guides cover how to fly one that can.

Arithmetic on your samples, not AI

It is worth being explicit about what this is, because "the app analysed my log" now covers two very different things. An AI chat assistant — the kind you type a question into — predicts the next word from text it was trained on. It never integrates your gyro trace, so it cannot know that your roll axis overshot by 8 %; it can only produce a sentence that reads like someone who does. Easyquadtune computes instead:

Question	How it is answered here
Which frequencies are in my gyro noise?	A Welch periodogram: Hann window, 50 % overlap, one-sided PSD, averaged over flight-gated windows. Bin width is `f_s / N`; nothing above `f_s / 2` exists to be found.
How far did the gyro overshoot the command?	Both curves divided by the commanded step, then the peak above 1.0 measured against the response's own final value.
How fast and how settled is the loop?	10 % to 90 % crossings interpolated between samples, and the last moment outside a ±5 % band. Both in milliseconds, both from the sample rate.
Is the response too slow for this profile?	The 10–90 % rise-time approximation `0.35 / t_r`, compared with a target the server holds.
Which setting should move?	A deterministic rule table. Same measurements and same craft bounds produce the same values on every run.

Two consequences follow, and both are testable rather than rhetorical. The result is deterministic: there is no sampling temperature and no model weights, so the same log and the same craft bounds give the same tune values every time — re-running an analysis is a reproduction, not a second opinion. And the measurement layer is reproducible by hand: every number in the report can be recomputed from the definitions above with a calculator and the raw CSV.

What AI is genuinely better at: explaining a concept, summarising an article, or suggesting what to check next. What it cannot do is measure an aircraft it has never seen. If you want the reasoning behind a recommendation spelled out in prose, ask an AI assistant — but check its numbers against /demo, because it will invent them.

What the log cannot tell us

Whether the tune feels right. A chart-grade step response is a measurement of tracking, not of pilot preference. Rates, expo and feel are yours.
The cause of a mechanical fault. A frame resonance at 210 Hz is a frequency. Whether it is a loose arm, a bent motor shaft or a soft mount is a physical inspection.
Motor temperature, voltage sag under load, or a failing ESC. The log shows symptoms, not the hardware.
Anything after the log ends. A change is a hypothesis; the re-log is the test. That is why the report ends with a post-tune checklist rather than a promise.

What is published, and what is not

This page defines what is measured, how each number is computed, when a measurement is too weak to act on, and which rules decide whether a change is allowed at all. The source code is not published, and neither is the tuning recipe: the per-profile targets, the caps and the coefficients that convert a measured gap into a number stay in the product. That is deliberate. A published recipe is not a method, it is a paste target — and it would let someone skip the log the recommendation is supposed to come from.

What you can hold the tool to is this page: a number in a report that cannot be reproduced from the definitions below is a bug, and the changelog records every time a number moved.

“Then could I just build the tune myself?”

The measurement, yes. Given the same log and the definitions above, any engineer can reproduce the FFT, the overshoot, the rise and the settle time, and should. That is the point: the published half is the half you are allowed to check.

The tune, no. The part that turns a measurement into a value is not a formula with a single unknown — it is a feature set, a set of weights, a starting curve per airframe class and an envelope per class, and every one of them is withheld. Knowing the shape of the calculation does not let you evaluate it any more than knowing that a lens is convex lets you grind one to the same prescription.

What the published half does allow is the rule of thumb every pilot already applies — slow means more gain, bouncing means less — which produces a flyable generic tune. That is not a per-log recommendation: it has no bound, no provenance line, no confidence grade, and no rule that says change nothing here. Those four things are the product. And nothing on this site pairs a log with the values we produced from it, so there is no table to fit the withheld constants against.

What changed in this method

The step estimator used to normalise each curve by its own maximum and count rise in samples, which is why earlier reports could show 0 % overshoot on a bouncing quad. That is fixed, and the changelog records it. A report generated before that fix should be regenerated from the original log rather than trusted for overshoot or settling.

See it applied to a real log

The sample report shows every section and the CLI shape for Cine, Freestyle and Race. The demo shows the charts and log score from the same flight.

Analyse my first log — free

Easyquadtune is not affiliated with Betaflight. Published 2026-10-21. Measurements come from the maintainer's own flight logs; an example is illustrative of the method, not a tune for your aircraft.