[j-w9]

Fixes #259, following your diagnosis there: with LOG_DARM_RATEMAX set, raw GYR samples logged while disarmed are rate limited, and the loader's batch sample rate no longer matches the data.

Reproduced in SITL (LOG_DISARMED 1, LOG_DARM_RATEMAX 10, INS_RAW_LOG_OPT 1, raw IMU logging on, takeoff, hover, land). GYR runs at ~25 Hz disarmed and 1000 Hz armed. The step from 25 Hz to 1000 Hz isn't a gap, so the whole log becomes one batch with a mean rate of 793.5 Hz, and every frequency is scaled by 0.79 (spectrum ends at 397 Hz). If a gap does split off a disarmed first batch, run_batch_fft takes its rate from data_set[0], which gives the very low rate and the oversized spectrogram from the issue.

When LOG_DARM_RATEMAX > 0 and the log has ARM messages, raw samples logged while disarmed are dropped before batching. The gap left behind splits the armed sections as before. Logs without LOG_DARM_RATEMAX, or with no armed data, take the existing path unchanged.

I don't have the log from the issue, so it would be good to check it against that one.

[AP-Review]

Deprecated — see below for the updated review.

Previous review (2026-11-09)

Automated review note — AI-generated (Claude+Codex), validated against the live diff. Please sanity-check before acting.
Verdict: REQUEST CHANGES

Reviewed at head cc4f13a118.
Full report: https://firmware.ardupilot.org/Tools/APReview/DevCallReviews/PRReviews/ardupilot/webtools/367/1.html#prWebTools-367

The rate-limit fix works for logs with disarmed logging on, but in some multi-arm logs it now drops a whole flight.

Blocking

1. FilterReview/FilterReview.js:2234 armed_mask() starts disarmed, but when LOG_DISARMED is 0 the first arming has no ARM message (ARM is written before the logger is marked armed). In a log with a later re-arm, every armed sample before the first logged ARM is thrown away, although none of it was rate limited. Fix: seed the state from the first logged message, let armed = (ARM.ArmState.length > 0) && (ARM.ArmState[0] == 0), or also require LOG_DISARMED != 0 at line 2270. The first option was tested on SITL logs: it recovers both flights and gives the same result for LOG_DISARMED=1.

[AP-Review]

Automated review note — AI-generated (Claude+Codex), validated against the live diff. Please sanity-check before acting.
Verdict: ACCEPT

Reviewed at head 76381adefc.
Full report: https://firmware.ardupilot.org/Tools/APReview/DevCallReviews/PRReviews/ardupilot/webtools/367/2.html#prWebTools-367

No problems found at the new head 76381ad. The blocker from the last review is fixed: armed_mask() now starts from the opposite of the first logged arm state (FilterReview/FilterReview.js:2235), so logs with disarmed logging off keep their first flight again. Replaying the SITL logs keeps both flights, and with LOG_DISARMED=1 the batches are still clean ~1000 Hz.