Still using Claude to help as a complete newbie but have been working through the configuration slowly and am up to 28. Learning loads but appreciate that ai often gets it wrong and frequently have to push back as I have today. I also realise that I might be heading off down the wrong route here so asking for help please
Pitch-axis resonance fixed via D-gain, but PID notch filter (ATC_RAT_PIT_NEF) appears to introduce a new uncommanded oscillation
Aircraft
TBS Source One V5 deadcat, QuadX, Matek H743-SLIM V4, ArduCopter 4.7.0 (bdshot firmware), iFlight BLITZ E55 4-in-1 ESC (BLHeli32 32.9), EMAX/iFlight ECO 2807 1300kv motors, HQProp Cine7 7x4x3, Holybro Micro M10 GPS, ~973g AUW.
Original problem
Isolated single-axis stick testing (pitch-only and roll-only, roll/yaw or pitch/yaw centred) revealed a strong, narrow, high-Q resonance specific to pitch only — roll consistently clean across every test. Comparing PIDP.Tar (target) vs PIDP.Act (actual) via Welch PSD:
- Peak frequency: consistently 15.6–16.0Hz
- Actual/Target power ratio: ~700x
- Target signal itself was clean/slow (0.4–0.8Hz, normal stick input) — confirming the resonance was not something we were commanding, it was the aircraft’s own closed-loop response.
What we ruled out
- GPS antenna mast rigidity (reprinted TPU→PETG, fully clamped) — zero change
- Loose battery lead near the pack — secured, zero change
ATC_ANG_PIT_PvsATC_ANG_RLL_P— both 4.5, symmetric, ruled outATC_RAT_PIT_FF— confirmed zero on both axes
What worked: ATC_RAT_PIT_D reduction
Progressive reduction, each step confirmed via the same Target-vs-Actual isolated pitch test:
| ATC_RAT_PIT_D | Peak freq | Act/Tar ratio |
|---|---|---|
| 0.00333 (original) | 15.6–16.0Hz | ~700x |
| 0.0025 | 12.7–13.1Hz | 330–455x |
| 0.002 | 10.7–12.5Hz | 233–263x (consistent across 3 independent flights) |
| 0.0015 | 9.8–10.7Hz | 204–258x (plateau — no further improvement over 0.002) |
Frequency shifting with gain (not fixed, as a passive mechanical resonance would be) strongly suggested marginal control-loop stability rather than a structural resonance. Settled on ATC_RAT_PIT_D = 0.002, ATC_RAT_PIT_SMAX = 8 as the working config — real, ~3x reduction in amplification, aircraft flies normally, no adverse feel reported in general flying.
The new issue: PID notch filter appears to make things worse
To address the residual ~230–260x, added:
FILT1_TYPE = 1(Notch),FILT1_NOTCH_FREQ = 11.5,FILT1_NOTCH_Q = 5,FILT1_NOTCH_ATT = 25ATC_RAT_PIT_NEF = 1(applied to error signal, not target — confirmed via the Target-vs-Actual check that the resonance lives in the response, not the commanded input)
First flight with this enabled: serious wobble on liftoff, repeated on a second attempt, pilot aborted both times (safe, no damage). Attitude data confirmed the wobble was real and airborne (not ground effect or pilot stick input) — ruled out via RC input logs matching a hard deliberate throttle-cut to idle, not a cause.
Follow-up test flying with notch OFF: clean flight, tight attitude, small uncommanded yaw drift (~4°).
Re-enabled notch on a subsequent flight from the same field: clear uncommanded oscillation returned, this time isolated with zero stick input confirmed via RCIN (pilot holding pure static hover) — real pitch spikes of 2–3°, repeating roughly every ~2.2s, confirmed via raw ATT.Pitch inspection (not visible in a simple PSD of the full window — needed to look at the raw time series).
The confound I can’t rule out
Every single flight where the notch was enabled also logged EKF3 ... ground mag anomaly, yaw re-aligned. Every flight where the notch was disabled did not. This pattern has now repeated across two independent flight pairs, regardless of which one was flown first chronologically. On the most recent notch-ON flight, the anomaly never resolved to an "in-flight yaw alignment complete" message at all, and a PreArm: EKF3 Yaw inconsistent 48 deg warning appeared shortly after landing.
I can’t currently tell whether:
- The notch filter (applied via
ATC_RAT_PIT_NEF, filtering the error signal directly) is adding enough phase lag on top of an already-marginal loop to genuinely destabilize it, or - The magnetic anomaly/EKF heading instability is the real cause, and its correlation with “notch enabled” is coincidental — possibly because changing
FILT1_TYPErequires a reboot, and the reboot/repositioning process is somehow disturbing the compass reading each time.
Questions
- Is applying a notch filter via
ATC_RAT_PIT_NEF(error signal) known to be meaningfully riskier for loop stability than the equivalent harmonic notch on the raw gyro (INS_HNTCH_*), particularly on a loop already confirmed to have thin stability margin? - Has anyone seen
FILT1_TYPEchanges (which require a reboot) correlate with spurious ground mag anomaly detections — i.e., is there a plausible mechanism where the reboot/rearm process itself increases the chance of a compass anomaly flag, independent of the notch filter’s technical function? - Is there a recommended way to distinguish “genuine control-loop instability from a notch filter” from “EKF yaw instability corrupting the attitude estimate and destabilizing pitch as a side effect” from log data alone, beyond what I’ve done here (Target vs Actual PSD, raw time-series inspection, RCIN cross-check)?
Logs available on request (multiple .bin files covering the full test series).
