Run the full deterministic diagnostic suite over an ArduPilot .bin log (or a ground station's .tlog).

A .tlog is the telemetry the ground station received: a few Hz, the primary sensor and EKF core only, and gaps where the radio link dropped. Checks that would read a link dropout as a vehicle fault (log integrity, timing) are skipped on it; prefer the onboard .bin when the user has it.

Returns severity-ranked findings (each with concrete evidence AND official ArduPilot doc links), per-check results, a plain-language summary, and guidance. Read the cited references for the log's firmware version, call vehicle_profile for the airframe's physical configuration, and fold in any real-world details the user gives — then explain and cite sources. Every finding is grounded in the log; do not invent causes beyond them.

What went wrong first, and what followed: the onset (first anomaly while armed), the impact (crash check, crash disarm, or the log ending while armed), and every firmware verdict, error, failsafe mode change and finding in time order, each tagged before_onset / onset / after_onset / impact / after_impact. Use it to answer "what failed first, and is the rest just the crash?". Time order only — never causation.

A Markdown reply to paste into a discuss.ardupilot.org thread: vehicle and firmware, what went wrong first (onset and impact), the findings with their corroborating log records, and a small text plot of the data behind each one. It contains no GPS positions and is returned as text (nothing is written to disk). Review it with the user and add what they saw before they post it.

What changed between two logs of the same vehicle ("it flew fine last week")? Lists configuration parameters that differ (separately from values the autopilot learns/counts itself), parameters present in only one log, the firmware change, and flight metrics side by side (vibration, hover throttle, battery/board voltage minimums). Differences only — it does not judge which side is right. By convention A is the earlier/good flight and B the later/bad one.

Cheap orientation: vehicle, firmware, duration, message counts, flight modes, max altitude, integrity.

Physical / architecture profile of the aircraft inferred from the log.

Frame class & type, motor count, battery cells/capacity, and — the key physical insight — the hover throttle and resulting power margin / thrust-to-weight. Use this to reason about the craft physically and to combine with real-world details the user gives (weight, prop diameter, motor KV, wind).

Decoded ERR/MODE/EV/MSG timeline. kinds filters families (ERR, MODE, EV, MSG); times are seconds.

Numeric time series for a message type and fields, for drilling into a finding.

Multi-instance messages (VIBE/IMU per IMU, GPS per receiver, MAG per compass, BAT per battery, XKF* per EKF core) are returned one instance at a time: pass instance (default: the first one; see available_instances). Values are aligned with times_s by index. Downsamples (decimates) to at most max_points points.

Parameter values recorded in the log's PARM dump. name_glob is a case-insensitive glob, e.g. 'INS_HNTCH_*'.

Includes total (full param count), metadata_url (version-specific definitions to interpret values), and a note if the snapshot looks incomplete (truncated log) — in which case ask the user for their exported .param file and read it with load_param_file. documented gives each returned param's documented range, units, listed values and bitmask bits for the log's firmware (bundled, offline); a value outside the documented range or list is not necessarily wrong (some defaults, e.g. 0 = disabled, lie outside). undocumented names params that release does not document.

Load a user-exported ArduPilot parameter file (.param / .params).

The authoritative complete configuration — use it when the log's PARM snapshot is truncated/incomplete, or to compare the flown config (get_params) against the user's current/intended config. name_glob filters. firmware (e.g. 'ArduCopter V4.6.3', from the log's log_summary) attaches the documented metadata and lists names that release does not document (typos, script or other-firmware params).

Advisory tuning recommendations (harmonic notch from the batch sampler, a fast IMU, the in-flight FFT or ESC RPM; PID; autotune). Recommendation ONLY — never applied.

List the registered diagnostic checks (the extensible catalogue).