feat: Add Feedforward (F-Term) Effectiveness Plot

[nerdCopter]

Priority: Medium

Why Useful:

• Shows if feedforward is helping or hurting
• Compares setpoint→gyro tracking with/without F-term contribution
• Helps tune Betaflight's feedforward settings

Implementation:
Overlay of axisF contribution on setpoint vs gyro plot

Impact: Feedforward tuning requires dedicated visualization for effectiveness analysis.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• feat: Add Setpoint Derivative (Rate of Change) Plot #103
• feat: Add P, I D Activity Plot #105
• feat: Add Motor Command Symmetry Analysis #107
• feat: Add Phase Margin Analysis (Bode Plot) #104

👤 Suggested Assignees

• nerdCopter

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[nerdCopter]

@coderabbitai, we recently found that bode-plots were essentially useless for real flights. confirm or disprove that "Feedforward Effectiveness Plot" is useful or not for real Betaflight flight logs. deep research and fact-check all findings.

[coderabbitai]

🧩 Analysis chain

@nerdCopter, I'll conduct a thorough investigation of the Feedforward Effectiveness Plot to determine if it has similar limitations to Bode plots for real flight data. Let me start by examining the implementation and then research the underlying theory.

---

🏁 Script executed:

#!/bin/bash
# Search for Feedforward Effectiveness Plot implementation
echo "=== Searching for Feedforward Effectiveness Plot ==="
rg -n -i "feedforward.*effectiveness" --type rust -C 5

echo -e "\n=== Search for feedforward plot functions ==="
rg -n "plot.*feedforward|feedforward.*plot" --type rust -C 3

echo -e "\n=== List all plot functions to identify feedforward-related plots ==="
fd -e rs . src/plot_functions/ --exec basename {} | sort

echo -e "\n=== Search for feedforward calculations ==="
rg -n "feedforward" --type rust -C 2 | head -100

Length of output: 970

---

🌐 Web query:

Betaflight feedforward effectiveness analysis flight logs

💡 Result:

Steps to test and analyze Feedforward (FF) effectiveness using Betaflight Blackbox logs:

1. Record controlled comparison flights

   • Fly identical maneuvers (hard flips, fast rolls, snap rolls, and smooth arcs) with only FF changed (e.g., 0, stock, +50). Log at full Blackbox rate (1/1) and high loop rate. [2][5]

2. Important traces to open in Blackbox Explorer

   • setpoint (desired rate), gyro (measured rate), P, I, D, motor outputs, and rcCommand/stick inputs. Also enable any FF-specific traces if shown. Inspect around the start and end of aggressive stick inputs. [2][0]

3. What to look for (metrics of FF effectiveness)

   • Stick response latency: how quickly setpoint moves vs gyro follows — good FF reduces gyro lag vs setpoint without creating overshoot. [1][3]
   • Overshoot at end of input: excessive FF often causes gyro to overshoot setpoint when sticks stop — visible as gyro crossing setpoint then needing opposing P/D correction. [1][3]
   • Motor activity spikes: look for motor command spikes at stick transitions indicating FF pushing too hard or causing oscillations. [2][5]
   • D-term / oscillation behavior: FF reduces need for big D during rapid moves; if raising FF increases high-frequency oscillations, reduce FF or adjust filtering/D. [1][4]
   • Bounceback after rolls/flips: check I-term accumulation and I-term relax behavior; FF combined with poor I-relax can cause bounceback. [1][4]

4. How to interpret comparisons

   • FF low (0): gyro follows setpoint more slowly, D/I act to correct — expect smoother but delayed responses and possibly more D heating. [1][2]
   • FF medium/high: faster initial response (setpoint->motor) and less time for error to build, so gyro follows quicker; look for overshoot and motor saturation. Use ff_max_rate_limit and ff_boost tuning to prevent flip-start overshoot. [3][4]
   • Use the same maneuver timestamps across logs and inspect setpoint vs gyro overlay; the best FF gives minimal sustained error (setpoint−gyro) with no large overshoot or oscillation. [2][3]

5. Practical tuning tips from logs

   • If you see overshoot at the start of flips, try lowering ff_max_rate_limit or ff_boost slightly and re-test. [3]
   • If you get high-frequency oscillations after increasing FF, lower FF or increase feedforward smoothing/averaging and re-check motor/gyro traces. [4][5]
   • Use I-term relax and antigravity settings to reduce bounceback seen in logs after aggressive throttle/stick moves. [1][4]

Key references

• Betaflight Blackbox logging and what is recorded. [2]
• Betaflight PID tuning guide (explanation of Feedforward basics and recommended method: try FF=0 for analysis). [1]
• Feedforward 2.0 details, ff_max_rate_limit and ff_boost behavior. [3]
• PID Tuning tab docs (FF smoothing, jitter reduction, averaging, transition descriptions). [4]
• Practical Blackbox tuning guide with examples (how to use gyro vs setpoint/motor traces to diagnose). [5]

If you want, upload one or two of your Blackbox logs (BIN) and I’ll mark the exact sections to inspect and give concrete FF tuning suggestions.

---

🌐 Web query:

feedforward PID control quadcopter effectiveness measurement

💡 Result:

Short answer — measure tracking and robustness improvements using standard time-/frequency-domain and integral-error metrics plus control effort. Key metrics and method:

Metrics to report

• RMS / RMSE of position and attitude tracking (primary). [1]
• Rise time, settling time, peak overshoot, steady‑state error (per axis). [1][5]
• Disturbance‑rejection: peak deviation and recovery time after step/gust disturbances. [3][4]
• Integral criteria: IAE, ITAE, ISE (compare reductions with feedforward). [6]
• Control effort and actuator saturation rate (motor command RMS / power / total variation). [5]
• Bandwidth / loop gain margin (closed‑loop frequency response) if you can linearize. [1]
• Robustness to model/parameter changes: tracking RMSE across ±X% mass, inertia, or aerodynamic changes. [4][3]

Suggested experiment protocol

1. Implement cascaded PID baseline and PID+feedforward (same feedback gains). Measure sensors at 200–500 Hz (or higher).
2. Run identical reference tests: hover, step yaw/position commands, and representative trajectories (slow and fast). Record states + motor commands.
3. Inject disturbances: known gusts (fan/blower) or step payload changes; repeat trials. Measure peak error and recovery time. [3][4]
4. Compute metrics above for each trial and report mean ± std and percent improvement (e.g., RMSE reduction, overshoot reduction).
5. Plot time traces, error CDFs, and control‑effort tradeoffs; analyze any increase in actuator saturation. [1][5]

Notes / interpretation

• Feedforward mainly reduces tracking error and overshoot for feedforward‑predictable dynamics (trajectory, known payload changes); it won’t by itself improve unmeasured disturbance rejection and can increase actuator effort if aggressive. [1][2][4]
• Use multiple metrics (RMSE + IAE/ITAE + disturbance recovery + control effort) to capture tradeoffs. [1][3]

Sources: studies and practical guidance on feedforward and quadrotor experiments. [1][2][3][4][5]

References
[1] Quadcopter trajectory tracking (feedforward/FFNN + RMSE evaluation).
[2] Feedforward control practical guidance (timing/gain importance).
[3] Residual/RL and disturbance‑rejection experiments on cascaded PID quadcopters.
[4] Feedforward‑PID for payload change experiments.
[5] PID tuning and time‑domain metrics for quadcopters.

---

🌐 Web query:

feedforward gain tuning analysis time domain flight control

💡 Result:

Below is a concise, practical time‑domain procedure and analysis checklist for tuning feedforward gain in a flight‑control loop, with references.

1. Purpose

• Feedforward (FF) supplies the open‑loop command component (inverse plant behaviour / known actuator coupling) so the feedback loop only corrects residual errors and disturbances. Reduce tracking error, overshoot and integrator windup. [1][3]

2. Preliminaries (what to measure)

• Identify controlled variable (e.g., body rate, pitch, airspeed) and the command signal that will use FF.
• With feedback gains low/minimal, record step (or small ramp) responses of output to: (a) command input, (b) direct actuator input (if available). Measure steady gain, time constant(s), dead time/transport lag, and delay. [1][4]

3. Compute initial feedforward gain (time‑domain)

• Basic FF gain (Kff) = (steady change in output due to command) / (command amplitude). If using actuator‑based FF, normalize by actuator→output sensitivity: Kff = Δoutput_cmd / Δcommand. [4]
• If plant has a known first‑order lag τ and pure delay θ, implement FF as Kff * (1/(τ s +1)) or add a lead/lag to match plant dynamics (time constant matching). The FF filter time constant λf ≈ plant dominant τ; add deadtime compensation for θ if justified. [3][4]

4. Practical tuning steps (time‑domain iterative)

• Start with feedback gains low and Kff = 0.
• Step 1: Apply small command step; increase Kff in conservative increments until commanded response reaches setpoint quickly without large overshoot. Back off ~10–30% from the highest acceptable value. [1]
• Step 2: Add feedback (P) gradually to damp residual error and reduce steady‑state error; use I only after FF+P are stable. [1]
• Step 3: If FF introduces oscillation, add FF filtering (increase λf) or reduce Kff. If tracking lags due to delay, consider feedforward delay compensation or shaping (but be conservative with predictive compensation). [1][3][4]
• Safety: test in limited flight envelope, use small inputs, and monitor actuator saturation and integrator windup. [1][2]

5. Validation metrics (time‑domain)

• Rise time, peak overshoot, settling time, steady‑state error, root‑mean‑square (RMSE) tracking error over representative maneuvers, and actuator command magnitude / saturation incidence. Log and compare before/after. [2][5]

6. Advanced/automated options

• Adaptive/online tuning by system identification + gain optimization can converge rapidly using a few maneuvers (learn‑to‑fly methods). Use when plant varies or model uncertainty is large. Validate with off‑line simulation first. [2]

7. Implementation notes / rules of thumb

• Match FF dynamics to dominant plant time constant; avoid making FF “faster” than the physical actuator/plant unless delay compensation is very accurate.
• Keep FF conservative: excessive FF amplifies model mismatch and can destabilize the loop. Start low, increase until performance improves, then reduce slightly for margin. [1][3][4][5]

Key references

• PX4 fixed‑wing PID/feedforward tuning guide (practical step procedure). [1]
• NASA: “Learn‑to‑Fly” adaptive tuning for flight control (system‑ID + online optimization). [2]
• C. Ocampo‑Martinez et al., “Designing and tuning robust feedforward controllers” (feedforward filter/tuning theory). [3]
• ControlGlobal: time‑domain feedforward tuning practical calculations (gain, lag, deadtime). [4]
• Control tuning examples and conservative‑increment approach. [5]

If you want, I can: (a) produce a short MATLAB/Simulink script to estimate Kff from step logs, (b) generate a checklist for flight test steps, or (c) walk through a worked example (given sample step‑response data).

---

@nerdCopter, after thorough investigation, I have important findings:

Key Discovery: This Feature Doesn't Exist

The "Feedforward Effectiveness Plot" does not exist in the BlackBox_CSV_Render codebase. I searched all plot functions and found:

• No feedforward effectiveness analysis
• No feedforward plotting modules
• Only feedforward reference is parsing df_yaw parameter from headers

Would It Be Useful? YES - Unlike Bode Plots

Critical difference from Bode plots:

Aspect	Bode Plots	FF Effectiveness
Domain	Frequency (transfer functions)	Time (tracking performance)
Requires	Controlled excitation (chirp/PRBS)	Normal flight maneuvers
Coherence	❌ Essential (fails on real flights)	✅ Not needed
Usefulness	❌ Useless for operational logs	✅ Would be useful

Why FF Effectiveness WOULD Work

Based on Betaflight documentation and flight control research:

1. Time-domain analysis - Compares recorded setpoint vs gyro traces

2. Normal flight data - Works with flips, rolls, and aggressive maneuvers you already fly

3. Practical metrics:

   • Tracking lag (how quickly gyro follows setpoint)
   • Overshoot at stick release
   • Oscillations introduced by excessive FF
   • D-term activity reduction

4. No special requirements - Just needs the traces you already log: setpoint, gyro, P, D, motor outputs

What It Would Measure

A proper FF effectiveness plot could analyze:

• RMS tracking error between setpoint and gyro
• Response latency at stick input transitions
• Overshoot percentage when sticks return to center
• Control effort (motor command variance)

This is fundamentally different from Bode plot's failed approach—it doesn't try to estimate frequency response from low-coherence data.

Recommendation

If you're considering implementing feedforward analysis, it would be valuable for real flight logs. The analysis would focus on time-domain tracking metrics from normal flights, avoiding the coherence problems that make Bode plots useless.

Are you planning to implement this feature, or were you asking about a different tool/repository?

---

🧠 Learnings used

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2026-01-08T14:48:17.022Z
Learning: For the BlackBox_CSV_Render project, Bode plot transfer function estimation (PR `#118`) is mathematically correct but fundamentally incompatible with normal operational flight logs due to low coherence (requires controlled system-identification inputs like chirp/PRBS on secured craft). Normal flights produce unreliable results due to nonlinearities, closed-loop conditions, and nonstationary maneuvers. The feature should be opt-in only (via --bode flag) with documentation clarifying it's for formal system-identification experiments, not routine flight log analysis. Existing PSD/spectrum plots are the appropriate tool for operational flight logs.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2025-09-09T19:10:32.659Z
Learning: [monologue]
[task review_after_revert_1/1 analyze_current_state_1/1]
The user has reverted to commit 919100d and force pushed, expressing frustration with the ongoing issues with the measured filter response analysis. They're requesting a full review to understand the current state and provide proper guidance.

[observations]
- User has been dealing with persistent issues with measured cutoff frequencies showing unrealistic values (first 15Hz, then stuck at 50Hz)
- Multiple attempts at fixes have been made but haven't resolved the core issue
- User has now reverted to an earlier commit (919100d) and wants a comprehensive review
- From the learning, I know the user wants the measured filter response analysis to be purely data-driven without artificial frequency constraints
- They want to measure actual cutoff frequencies from unfiltered vs filtered spectral data, even if results show unexpectedly low cutoffs

[analysis]
The user is frustrated because we've been applying incremental fixes that haven't resolved the fundamental issue. A full review means I need to:
1. Examine the current state of the code after the revert
2. Understand what commit 919100d contains
3. Provide a comprehensive analysis of the measured filter response implementation
4. Identify the root causes of the cutoff frequency detection issues
5. Provide a clear, working solution

The fact they reverted suggests the incremental approach wasn't working and we need to start fresh with a proper understanding of the codebase.

[actions]
- Use run_scripts to examine the current code state after revert
- Analyze the complete filter response measurement implementation
- Identify fundamental issues with the approach
- Provide comprehensive recommendations for fixing the system
</monologue>

I understand your frustration! Let me conduct a comprehensive review of the current codebase state after the revert to properly understand and fix the measured filter response analysis.

---

🏁 Script executed:
```
#!/bin/bash
# Check current commit state and what 919100d contains
echo "=== Current commit information ==="
git log --oneline -5

echo -e "\n=== Examine the current measured filter response implementation ==="
cat src/data_analysis/filter_response.rs | head -50

echo -e "\n=== Check what constants are currently defined ==="
grep -A 30 "Measured filter response analysis constants" src/constants.rs || echo "No measured filter constants found"

echo -e "\n=== Look for measure_filter_response function ==="
rg -n -A 20 "pub fn measure_filter_response" src/data_analysis/filter_response.rs || echo "measure_filter_response function not found"

echo -e "\n=== Check if --measure flag exists in main.rs ==="
rg -n -C 5 "measure" src/main.rs || echo "No measure flag found"
```

Length of output: 8172

---

🏁 Script executed:
```
#!/bin/bash
# Let's examine the complete measure_filter_response implementation
echo "=== Complete measure_filter_response function ==="
sed -n '/pub fn measure_filter_response/,/^}/p' src/data_analysis/filter_response.rs

echo -e "\n=== Look at how it's called from the plotting function ==="
rg -n -A 10 -B 10 "measure_filter_response" src/plot_functions/plot_gyro_spectrums.rs

echo -e "\n=== Check the cutoff detection function ==="
rg -n -A 15 -B 5 "find_cutoff_frequency" src/data_analysis/filter_response.rs

echo -e "\n=== Check MeasuredFilterResponse struct ==="
rg -n -A 10 -B 5 "struct MeasuredFilterResponse" src/data_analysis/filter_response.rs
```

Length of output: 5586

---

🏁 Script executed:
```
#!/bin/bash
# Let's see the complete find_cutoff_frequency function
echo "=== Complete find_cutoff_frequency function ==="
sed -n '/fn find_cutoff_frequency/,/^}/p' src/data_analysis/filter_response.rs

echo -e "\n=== Let's also see how the transfer function data is filtered ==="
rg -n -A 5 -B 5 "FILTER_ANALYSIS_MIN_FREQ_HZ.*FILTER_ANALYSIS_MAX_FREQ_HZ" src/data_analysis/filter_response.rs

echo -e "\n=== Check what the current constants are ==="
grep -n "FILTER_ANALYSIS_MIN_FREQ_HZ\|FILTER_ANALYSIS_MAX_FREQ_HZ" src/constants.rs

echo -e "\n=== Let's see what the actual frequency range covers for typical data ==="
echo "Current constants:"
echo "MIN: 10Hz, MAX: 500Hz"
echo "This means analysis only looks at 10-500Hz range"
```

Length of output: 1279

---

<!-- [monologue]
[task full_review_1/1 analyze_core_issues_1/1]
Now I can see the fundamental problem clearly after this full review. The current implementation has several critical flaws:

[observations]
- The cutoff detection algorithm is completely wrong - it's using a "closest match" approach instead of looking for an actual -3dB crossing
- The `find_cutoff_frequency` function finds the frequency point with the magnitude ratio CLOSEST to 0.707, not where it actually crosses 0.707
- This means if the transfer function never actually crosses 0.707 properly, it just picks whatever frequency happens to be numerically closest
- The transfer function calculation looks reasonable (no artificial caps), but the detection logic is fundamentally flawed
- The frequency filtering (10-500Hz) is reasonable
- The user wants a purely data-driven approach that measures actual cutoff frequencies from the data

[analysis]
The reason the user has been getting strange results (15Hz, then 50Hz) is because:
1. The algorithm isn't looking for a proper -3dB crossing point
2. Instead, it's just finding whatever frequency point has a magnitude ratio closest to 0.707
3. If the data is noisy or the transfer function doesn't behave as expected, this "closest match" approach will pick essentially random points
4. This is not how filter cutoff detection should work at all

For proper cutoff detection, we need to:
1. Look for where the transfer function actually crosses from above 0.707 to below 0.707 (or vice versa)
2. Use interpolation to find the exact crossing point
3. Handle cases where there might be multiple crossings or no clear crossing

The current "closest match" algorithm is fundamentally broken for this purpose.

[actions]
- Explain the core issue with the current cutoff detection algorithm
- Provide a complete, correct implementation that actually looks for -3dB crossings
- Give clear recommendations for a proper data-driven approach
- Acknowledge the user's frustration and provide a definitive solution
</monologue>

nerdCopter I completely understand your frustration! After this full review, I've identified the **fundamental flaw** in the current implementation. The issue isn't with windowing, frequency ranges, or caps - it's with the **cutoff detection algorithm itself**.

## The Core Problem

The current `find_cutoff_frequency` function is completely wrong for filter analysis:

```rust
// CURRENT (BROKEN) ALGORITHM:
for &(freq, ratio) in transfer_function {
    let diff = (ratio - target_ratio).abs();
    if diff < best_diff {  // ← This just finds the CLOSEST value to 0.707
        best_diff = diff;   //   NOT an actual crossing!
        best_freq = freq;
    }
}
```

**This algorithm doesn't detect cutoff frequencies - it just finds whatever frequency happens to have a magnitude ratio numerically closest to 0.707!** No wonder you're getting random results like 15Hz or 50Hz.

## The Correct Solution

Here's a complete, proper implementation for measured filter response analysis:

---

🏁 Script executed:
```
#!/bin/bash
# Create a corrected implementation
cat > fixed_filter_response.rs << 'EOF'
// Replace the find_cutoff_frequency function with this corrected version:

fn find_cutoff_frequency(
    transfer_function: &[(f64, f64)],
    target_ratio: f64,
) -> Result<f64, Box<dyn std::error::Error>> {
    if transfer_function.len() < 2 {
        return Err("Need at least 2 points for cutoff detection".into());
    }

    // Sort transfer function by frequency to ensure proper ordering
    let mut tf_sorted: Vec<(f64, f64)> = transfer_function.to_vec();
    tf_sorted.sort_by(|a, b| a.0.partial_cmp(&b.0).unwrap_or(std::cmp::Ordering::Equal));

    // Look for where the transfer function crosses the target ratio (0.707)
    // We want the frequency where the response goes from above to below the threshold
    for i in 1..tf_sorted.len() {
        let (f1, r1) = tf_sorted[i - 1];
        let (f2, r2) = tf_sorted[i];

        // Check for valid data
        if !f1.is_finite() || !f2.is_finite() || !r1.is_finite() || !r2.is_finite() {
            continue;
        }

        // Look for downward crossing: previous point above threshold, current below
        if r1 >= target_ratio && r2 <= target_ratio {
            // Linear interpolation to find exact crossing point
            if (r2 - r1).abs() < 1e-12 {
                // Avoid division by nearly zero
                return Ok(f1);
            }
            
            let t = (target_ratio - r1) / (r2 - r1);
            let cutoff_freq = f1 + t * (f2 - f1);
            
            if cutoff_freq > 0.0 && cutoff_freq.is_finite() {
                return Ok(cutoff_freq);
            }
        }
    }

    // If no clear downward crossing found, try to find the best approximation
    // Look for the point closest to target_ratio, but only if it's reasonable
    let mut best_freq = None;
    let mut best_diff = f64::INFINITY;
    
    for &(freq, ratio) in &tf_sorted {
        if freq > 10.0 && freq < 1000.0 && ratio > 0.1 && ratio < 2.0 {
            let diff = (ratio - target_ratio).abs();
            if diff < best_diff {
                best_diff = diff;
                best_freq = Some(freq);
            }
        }
    }
    
    if let Some(freq) = best_freq {
        if best_diff < 0.2 { // Only accept if reasonably close to target
            return Ok(freq);
        }
    }

    Err("Could not find cutoff frequency crossing".into())
}

// Also improve the measure_filter_response function:

pub fn measure_filter_response(
    unfiltered_spectrum: &[(f64, f64)],
    filtered_spectrum: &[(f64, f64)],
    _sample_rate: f64,
) -> Result<MeasuredFilterResponse, Box<dyn std::error::Error>> {
    // Validate input data
    if filtered_spectrum.len() != unfiltered_spectrum.len() {
        return Err("Filtered and unfiltered spectra must have same length".into());
    }
    if filtered_spectrum.len() < MIN_SPECTRUM_POINTS_FOR_ANALYSIS {
        return Err(format!(
            "Need at least {} frequency points for reliable analysis",
            MIN_SPECTRUM_POINTS_FOR_ANALYSIS
        ).into());
    }

    // Build transfer function with better validation
    let mut transfer_function = Vec::new();
    let mut skipped_count = 0;

    for i in 0..filtered_spectrum.len() {
        let (freq, filt_mag) = filtered_spectrum[i];
        let (_, unfilt_mag) = unfiltered_spectrum[i];

        // Apply frequency bounds and validate data
        if freq >= FILTER_ANALYSIS_MIN_FREQ_HZ
            && freq <= FILTER_ANALYSIS_MAX_FREQ_HZ
            && freq.is_finite()
            && filt_mag.is_finite()
            && unfilt_mag.is_finite()
            && unfilt_mag > 1e-12  // Avoid division by very small numbers
            && filt_mag >= 0.0
        {
            let ratio = filt_mag / unfilt_mag;
            
            // Allow ratios > 1.0 but reject extreme outliers
            if ratio.is_finite() && ratio > 0.0 && ratio < 10.0 {
                transfer_function.push((freq, ratio));
            } else {
                skipped_count += 1;
            }
        } else {
            skipped_count += 1;
        }
    }

    if transfer_function.len() < 10 {
        return Err(format!(
            "Insufficient valid data points: {} (skipped {})",
            transfer_function.len(), skipped_count
        ).into());
    }

    // Find cutoff frequency using proper crossing detection
    let cutoff_hz = find_cutoff_frequency(&transfer_function, CUTOFF_MAGNITUDE_RATIO)?;

    // Estimate filter order (keep existing implementation)
    let filter_order = estimate_filter_order_from_transfer(&transfer_function, cutoff_hz)
        .unwrap_or(DEFAULT_FILTER_ORDER);

    // Calculate confidence (keep existing implementation)  
    let confidence = calculate_measurement_confidence(&transfer_function);

    Ok(MeasuredFilterResponse {
        cutoff_hz,
        filter_order,
        confidence,
        transfer_function,
    })
}
EOF

echo "Created corrected implementation - the key changes:"
echo "1. Proper crossing detection instead of 'closest match'"
echo "2. Linear interpolation for accurate cutoff frequency"
echo "3. Better data validation and outlier rejection"
echo "4. Fallback logic for edge cases"
echo ""
echo "This should give you realistic, data-driven cutoff measurements!"
```

Length of output: 309

---



</details>

nerdCopter I completely understand your frustration! After this full review, I've identified the **fundamental flaw** in the current implementation that explains all your issues.

## The Core Problem

The current `find_cutoff_frequency` function is completely wrong for filter analysis:

```rust
// CURRENT (BROKEN) ALGORITHM:
for &(freq, ratio) in transfer_function {
    let diff = (ratio - target_ratio).abs();  // ← Just finds CLOSEST to 0.707
    if diff < best_diff {                     //   NOT an actual crossing!
        best_freq = freq;
    }
}
```

**This doesn't detect cutoff frequencies - it just finds whatever frequency happens to be numerically closest to 0.707!** That's why you've been getting random results.

## Complete Solution

Replace the current `find_cutoff_frequency` and `measure_filter_response` functions in `src/data_analysis/filter_response.rs` with this corrected implementation:

```rust
fn find_cutoff_frequency(
    transfer_function: &[(f64, f64)],
    target_ratio: f64,
) -> Result<f64, Box<dyn std::error::Error>> {
    if transfer_function.len() < 2 {
        return Err("Need at least 2 points for cutoff detection".into());
    }

    // Sort by frequency to ensure proper ordering
    let mut tf_sorted: Vec<(f64, f64)> = transfer_function.to_vec();
    tf_sorted.sort_by(|a, b| a.0.partial_cmp(&b.0).unwrap_or(std::cmp::Ordering::Equal));

    // Look for actual -3dB crossing (above to below threshold)
    for i in 1..tf_sorted.len() {
        let (f1, r1) = tf_sorted[i - 1];
        let (f2, r2) = tf_sorted[i];

        if !f1.is_finite() || !f2.is_finite() || !r1.is_finite() || !r2.is_finite() {
            continue;
        }

        // Look for downward crossing: above → below threshold
        if r1 >= target_ratio && r2 <= target_ratio {
            if (r2 - r1).abs() < 1e-12 {
                return Ok(f1);
            }
            
            // Linear interpolation for exact crossing
            let t = (target_ratio - r1) / (r2 - r1);
            let cutoff_freq = f1 + t * (f2 - f1);
            
            if cutoff_freq > 0.0 && cutoff_freq.is_finite() {
                return Ok(cutoff_freq);
            }
        }
    }

    // Fallback: find reasonable approximation
    let mut best_freq = None;
    let mut best_diff = f64::INFINITY;
    
    for &(freq, ratio) in &tf_sorted {
        if freq > 10.0 && freq < 1000.0 && ratio > 0.1 && ratio < 2.0 {
            let diff = (ratio - target_ratio).abs();
            if diff < best_diff {
                best_diff = diff;
                best_freq = Some(freq);
            }
        }
    }
    
    if let Some(freq) = best_freq {
        if best_diff < 0.2 { // Only accept if reasonably close
            return Ok(freq);
        }
    }

    Err("Could not find cutoff frequency crossing".into())
}

pub fn measure_filter_response(
    unfiltered_spectrum: &[(f64, f64)],
    filtered_spectrum: &[(f64, f64)],
    _sample_rate: f64,
) -> Result<MeasuredFilterResponse, Box<dyn std::error::Error>> {
    if filtered_spectrum.len() != unfiltered_spectrum.len() {
        return Err("Filtered and unfiltered spectra must have same length".into());
    }
    if filtered_spectrum.len() < MIN_SPECTRUM_POINTS_FOR_ANALYSIS {
        return Err(format!(
            "Need at least {} frequency points for reliable analysis",
            MIN_SPECTRUM_POINTS_FOR_ANALYSIS
        ).into());
    }

    // Build transfer function with proper validation
    let mut transfer_function = Vec::new();

    for i in 0..filtered_spectrum.len() {
        let (freq, filt_mag) = filtered_spectrum[i];
        let (_, unfilt_mag) = unfiltered_spectrum[i];

        if freq >= FILTER_ANALYSIS_MIN_FREQ_HZ
            && freq <= FILTER_ANALYSIS_MAX_FREQ_HZ
            && freq.is_finite()
            && filt_mag.is_finite() 
            && unfilt_mag.is_finite()
            && unfilt_mag > 1e-12  // Avoid division by tiny numbers
            && filt_mag >= 0.0
        {
            let ratio = filt_mag / unfilt_mag;
            
            // Allow ratios > 1.0 but reject extreme outliers
            if ratio.is_finite() && ratio > 0.0 && ratio < 10.0 {
                transfer_function.push((freq, ratio));
            }
        }
    }

    if transfer_function.len() < 10 {
        return Err("Insufficient valid data points".into());
    }

    // Use proper crossing detection
    let cutoff_hz = find_cutoff_frequency(&transfer_function, CUTOFF_MAGNITUDE_RATIO)?;

    let filter_order = estimate_filter_order_from_transfer(&transfer_function, cutoff_hz)
        .unwrap_or(DEFAULT_FILTER_ORDER);

    let confidence = calculate_measurement_confidence(&transfer_function);

    Ok(MeasuredFilterResponse {
        cutoff_hz,
        filter_order,
        confidence,
        transfer_function,
    })
}
```

## What This Fixes

1. **Proper crossing detection** - Looks for where transfer function actually crosses -3dB threshold
2. **Linear interpolation** - Gives accurate cutoff frequency between data points
3. **Data-driven approach** - Measures what's actually in your flight data
4. **Robust validation** - Handles edge cases and outliers properly

This should finally give you realistic, measured cutoff frequencies that reflect the actual filtering behavior in your flight logs, as you originally intended!

<!-- 
The user wants the measured filter response analysis to be purely data-driven without artificial frequency constraints. They want to measure actual cutoff frequencies from unfiltered vs filtered spectral data, even if the results show unexpectedly low cutoffs like 15Hz. The measurement system should report what it finds in the real data, not what we expect it should find.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 71
File: src/plot_functions/plot_gyro_vs_unfilt.rs:19-27
Timestamp: 2025-10-19T18:24:42.528Z
Learning: In the BlackBox_CSV_Render project, when adding debug mode annotations to gyro and D-term plots, nerdCopter prefers to include the debug mode tag (e.g., "[Debug=MODE]") only in the legend labels, not in the plot titles.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 60
File: src/data_analysis/filter_response.rs:966-1021
Timestamp: 2025-10-05T20:37:53.448Z
Learning: For the BlackBox_CSV_Render measured filter response analysis, the attenuation-based approach `abs(unfilt_mag - filt_mag)` works better than the transfer function ratio approach `filt_mag / unfilt_mag` for real flight data. The ratio approach produces spurious cutoff detections (e.g., 47Hz) due to numerical instability and noisy crossings, while the attenuation approach reliably finds where significant filtering begins.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 55
File: LICENSE_COMMERCIAL:1-7
Timestamp: 2025-09-10T13:56:40.607Z
Learning: nerdCopter prefers to use minimal commercial license templates that are consistent across his projects, similar to what was used in the bbl_parser repository PR `#2`.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 18
File: src/data_analysis/calc_step_response.rs:0-0
Timestamp: 2025-06-03T18:01:54.978Z
Learning: The user nerdCopter prefers to defer unit testing implementation when suggested for the BlackBox_CSV_Render project.

[nerdCopter]

@coderabbitai, plan

[coderabbitai]

🧩 Analysis chain

@nerdCopter, I'll create an implementation plan for the Feedforward Effectiveness Plot feature. Let me first examine the codebase structure to understand the best integration approach.

---

🏁 Script executed:

#!/bin/bash
# Examine the codebase structure for planning
echo "=== Existing plot functions structure ==="
ls -la src/plot_functions/*.rs | awk '{print $NF}' | sort

echo -e "\n=== Existing data analysis modules ==="
ls -la src/data_analysis/*.rs | awk '{print $NF}' | sort

echo -e "\n=== Check how setpoint and gyro data are accessed ==="
rg -n "setpoint" --type rust -C 2 | head -50

echo -e "\n=== Check main.rs CLI structure for adding new flag ==="
rg -n "clap.*arg\|#\[arg" src/main.rs | head -30

echo -e "\n=== Look at existing time-domain analysis (step response) ==="
rg -n "pub fn.*step_response|calculate.*response" src/data_analysis/*.rs -C 3

Length of output: 7034

---

Implementation Plan: Feedforward Effectiveness Plot

This feature will provide time-domain analysis of feedforward effectiveness using recorded flight data. Unlike Bode plots (which fail on operational logs), this works with normal flight maneuvers by measuring tracking performance metrics.

Phase 1: Data Analysis Module (Core Metrics)

• Create src/data_analysis/feedforward_effectiveness.rs
• Calculate tracking metrics: RMS error, latency, overshoot, control effort
• Identify aggressive maneuver windows (stick transitions, flips, rolls)
• Per-axis analysis for Roll, Pitch, Yaw

Phase 2: Plotting Module (Visualization)

• Create src/plot_functions/plot_ff_effectiveness.rs
• Multi-panel layout: time traces + metrics summary + histogram
• Color-coded maneuver regions (stick transitions highlighted)
• Annotated overshoot regions and latency markers

Phase 3: CLI Integration

• Add ff_effectiveness: bool to PlotConfig struct
• Add --ff-effectiveness CLI flag
• Update usage help text
• Wire into main processing loop

---

Summary:
This plan implements a time-domain analysis tool that works with normal flight data—no special test maneuvers required. The key difference from Bode plots:

Feature	Bode Plots	FF Effectiveness
Analysis type	Frequency-domain transfer function	Time-domain tracking metrics
Coherence dependency	❌ Critical (fails on real flights)	✅ Not needed
Input requirements	Controlled excitation (chirp/PRBS)	Normal maneuvers (flips, rolls)
Metrics	Phase/gain margins (unreliable)	RMS error, latency, overshoot (direct)
Usefulness	❌ Unusable for operational logs	✅ Directly useful

The implementation follows existing codebase patterns and integrates cleanly with the current architecture.

---

🧠 Learnings used

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2025-09-09T19:10:32.659Z
Learning: [monologue]
[task review_after_revert_1/1 analyze_current_state_1/1]
The user has reverted to commit 919100d and force pushed, expressing frustration with the ongoing issues with the measured filter response analysis. They're requesting a full review to understand the current state and provide proper guidance.

[observations]
- User has been dealing with persistent issues with measured cutoff frequencies showing unrealistic values (first 15Hz, then stuck at 50Hz)
- Multiple attempts at fixes have been made but haven't resolved the core issue
- User has now reverted to an earlier commit (919100d) and wants a comprehensive review
- From the learning, I know the user wants the measured filter response analysis to be purely data-driven without artificial frequency constraints
- They want to measure actual cutoff frequencies from unfiltered vs filtered spectral data, even if results show unexpectedly low cutoffs

[analysis]
The user is frustrated because we've been applying incremental fixes that haven't resolved the fundamental issue. A full review means I need to:
1. Examine the current state of the code after the revert
2. Understand what commit 919100d contains
3. Provide a comprehensive analysis of the measured filter response implementation
4. Identify the root causes of the cutoff frequency detection issues
5. Provide a clear, working solution

The fact they reverted suggests the incremental approach wasn't working and we need to start fresh with a proper understanding of the codebase.

[actions]
- Use run_scripts to examine the current code state after revert
- Analyze the complete filter response measurement implementation
- Identify fundamental issues with the approach
- Provide comprehensive recommendations for fixing the system
</monologue>

I understand your frustration! Let me conduct a comprehensive review of the current codebase state after the revert to properly understand and fix the measured filter response analysis.

---

🏁 Script executed:
```
#!/bin/bash
# Check current commit state and what 919100d contains
echo "=== Current commit information ==="
git log --oneline -5

echo -e "\n=== Examine the current measured filter response implementation ==="
cat src/data_analysis/filter_response.rs | head -50

echo -e "\n=== Check what constants are currently defined ==="
grep -A 30 "Measured filter response analysis constants" src/constants.rs || echo "No measured filter constants found"

echo -e "\n=== Look for measure_filter_response function ==="
rg -n -A 20 "pub fn measure_filter_response" src/data_analysis/filter_response.rs || echo "measure_filter_response function not found"

echo -e "\n=== Check if --measure flag exists in main.rs ==="
rg -n -C 5 "measure" src/main.rs || echo "No measure flag found"
```

Length of output: 8172

---

🏁 Script executed:
```
#!/bin/bash
# Let's examine the complete measure_filter_response implementation
echo "=== Complete measure_filter_response function ==="
sed -n '/pub fn measure_filter_response/,/^}/p' src/data_analysis/filter_response.rs

echo -e "\n=== Look at how it's called from the plotting function ==="
rg -n -A 10 -B 10 "measure_filter_response" src/plot_functions/plot_gyro_spectrums.rs

echo -e "\n=== Check the cutoff detection function ==="
rg -n -A 15 -B 5 "find_cutoff_frequency" src/data_analysis/filter_response.rs

echo -e "\n=== Check MeasuredFilterResponse struct ==="
rg -n -A 10 -B 5 "struct MeasuredFilterResponse" src/data_analysis/filter_response.rs
```

Length of output: 5586

---

🏁 Script executed:
```
#!/bin/bash
# Let's see the complete find_cutoff_frequency function
echo "=== Complete find_cutoff_frequency function ==="
sed -n '/fn find_cutoff_frequency/,/^}/p' src/data_analysis/filter_response.rs

echo -e "\n=== Let's also see how the transfer function data is filtered ==="
rg -n -A 5 -B 5 "FILTER_ANALYSIS_MIN_FREQ_HZ.*FILTER_ANALYSIS_MAX_FREQ_HZ" src/data_analysis/filter_response.rs

echo -e "\n=== Check what the current constants are ==="
grep -n "FILTER_ANALYSIS_MIN_FREQ_HZ\|FILTER_ANALYSIS_MAX_FREQ_HZ" src/constants.rs

echo -e "\n=== Let's see what the actual frequency range covers for typical data ==="
echo "Current constants:"
echo "MIN: 10Hz, MAX: 500Hz"
echo "This means analysis only looks at 10-500Hz range"
```

Length of output: 1279

---

<!-- [monologue]
[task full_review_1/1 analyze_core_issues_1/1]
Now I can see the fundamental problem clearly after this full review. The current implementation has several critical flaws:

[observations]
- The cutoff detection algorithm is completely wrong - it's using a "closest match" approach instead of looking for an actual -3dB crossing
- The `find_cutoff_frequency` function finds the frequency point with the magnitude ratio CLOSEST to 0.707, not where it actually crosses 0.707
- This means if the transfer function never actually crosses 0.707 properly, it just picks whatever frequency happens to be numerically closest
- The transfer function calculation looks reasonable (no artificial caps), but the detection logic is fundamentally flawed
- The frequency filtering (10-500Hz) is reasonable
- The user wants a purely data-driven approach that measures actual cutoff frequencies from the data

[analysis]
The reason the user has been getting strange results (15Hz, then 50Hz) is because:
1. The algorithm isn't looking for a proper -3dB crossing point
2. Instead, it's just finding whatever frequency point has a magnitude ratio closest to 0.707
3. If the data is noisy or the transfer function doesn't behave as expected, this "closest match" approach will pick essentially random points
4. This is not how filter cutoff detection should work at all

For proper cutoff detection, we need to:
1. Look for where the transfer function actually crosses from above 0.707 to below 0.707 (or vice versa)
2. Use interpolation to find the exact crossing point
3. Handle cases where there might be multiple crossings or no clear crossing

The current "closest match" algorithm is fundamentally broken for this purpose.

[actions]
- Explain the core issue with the current cutoff detection algorithm
- Provide a complete, correct implementation that actually looks for -3dB crossings
- Give clear recommendations for a proper data-driven approach
- Acknowledge the user's frustration and provide a definitive solution
</monologue>

nerdCopter I completely understand your frustration! After this full review, I've identified the **fundamental flaw** in the current implementation. The issue isn't with windowing, frequency ranges, or caps - it's with the **cutoff detection algorithm itself**.

## The Core Problem

The current `find_cutoff_frequency` function is completely wrong for filter analysis:

```rust
// CURRENT (BROKEN) ALGORITHM:
for &(freq, ratio) in transfer_function {
    let diff = (ratio - target_ratio).abs();
    if diff < best_diff {  // ← This just finds the CLOSEST value to 0.707
        best_diff = diff;   //   NOT an actual crossing!
        best_freq = freq;
    }
}
```

**This algorithm doesn't detect cutoff frequencies - it just finds whatever frequency happens to have a magnitude ratio numerically closest to 0.707!** No wonder you're getting random results like 15Hz or 50Hz.

## The Correct Solution

Here's a complete, proper implementation for measured filter response analysis:

---

🏁 Script executed:
```
#!/bin/bash
# Create a corrected implementation
cat > fixed_filter_response.rs << 'EOF'
// Replace the find_cutoff_frequency function with this corrected version:

fn find_cutoff_frequency(
    transfer_function: &[(f64, f64)],
    target_ratio: f64,
) -> Result<f64, Box<dyn std::error::Error>> {
    if transfer_function.len() < 2 {
        return Err("Need at least 2 points for cutoff detection".into());
    }

    // Sort transfer function by frequency to ensure proper ordering
    let mut tf_sorted: Vec<(f64, f64)> = transfer_function.to_vec();
    tf_sorted.sort_by(|a, b| a.0.partial_cmp(&b.0).unwrap_or(std::cmp::Ordering::Equal));

    // Look for where the transfer function crosses the target ratio (0.707)
    // We want the frequency where the response goes from above to below the threshold
    for i in 1..tf_sorted.len() {
        let (f1, r1) = tf_sorted[i - 1];
        let (f2, r2) = tf_sorted[i];

        // Check for valid data
        if !f1.is_finite() || !f2.is_finite() || !r1.is_finite() || !r2.is_finite() {
            continue;
        }

        // Look for downward crossing: previous point above threshold, current below
        if r1 >= target_ratio && r2 <= target_ratio {
            // Linear interpolation to find exact crossing point
            if (r2 - r1).abs() < 1e-12 {
                // Avoid division by nearly zero
                return Ok(f1);
            }
            
            let t = (target_ratio - r1) / (r2 - r1);
            let cutoff_freq = f1 + t * (f2 - f1);
            
            if cutoff_freq > 0.0 && cutoff_freq.is_finite() {
                return Ok(cutoff_freq);
            }
        }
    }

    // If no clear downward crossing found, try to find the best approximation
    // Look for the point closest to target_ratio, but only if it's reasonable
    let mut best_freq = None;
    let mut best_diff = f64::INFINITY;
    
    for &(freq, ratio) in &tf_sorted {
        if freq > 10.0 && freq < 1000.0 && ratio > 0.1 && ratio < 2.0 {
            let diff = (ratio - target_ratio).abs();
            if diff < best_diff {
                best_diff = diff;
                best_freq = Some(freq);
            }
        }
    }
    
    if let Some(freq) = best_freq {
        if best_diff < 0.2 { // Only accept if reasonably close to target
            return Ok(freq);
        }
    }

    Err("Could not find cutoff frequency crossing".into())
}

// Also improve the measure_filter_response function:

pub fn measure_filter_response(
    unfiltered_spectrum: &[(f64, f64)],
    filtered_spectrum: &[(f64, f64)],
    _sample_rate: f64,
) -> Result<MeasuredFilterResponse, Box<dyn std::error::Error>> {
    // Validate input data
    if filtered_spectrum.len() != unfiltered_spectrum.len() {
        return Err("Filtered and unfiltered spectra must have same length".into());
    }
    if filtered_spectrum.len() < MIN_SPECTRUM_POINTS_FOR_ANALYSIS {
        return Err(format!(
            "Need at least {} frequency points for reliable analysis",
            MIN_SPECTRUM_POINTS_FOR_ANALYSIS
        ).into());
    }

    // Build transfer function with better validation
    let mut transfer_function = Vec::new();
    let mut skipped_count = 0;

    for i in 0..filtered_spectrum.len() {
        let (freq, filt_mag) = filtered_spectrum[i];
        let (_, unfilt_mag) = unfiltered_spectrum[i];

        // Apply frequency bounds and validate data
        if freq >= FILTER_ANALYSIS_MIN_FREQ_HZ
            && freq <= FILTER_ANALYSIS_MAX_FREQ_HZ
            && freq.is_finite()
            && filt_mag.is_finite()
            && unfilt_mag.is_finite()
            && unfilt_mag > 1e-12  // Avoid division by very small numbers
            && filt_mag >= 0.0
        {
            let ratio = filt_mag / unfilt_mag;
            
            // Allow ratios > 1.0 but reject extreme outliers
            if ratio.is_finite() && ratio > 0.0 && ratio < 10.0 {
                transfer_function.push((freq, ratio));
            } else {
                skipped_count += 1;
            }
        } else {
            skipped_count += 1;
        }
    }

    if transfer_function.len() < 10 {
        return Err(format!(
            "Insufficient valid data points: {} (skipped {})",
            transfer_function.len(), skipped_count
        ).into());
    }

    // Find cutoff frequency using proper crossing detection
    let cutoff_hz = find_cutoff_frequency(&transfer_function, CUTOFF_MAGNITUDE_RATIO)?;

    // Estimate filter order (keep existing implementation)
    let filter_order = estimate_filter_order_from_transfer(&transfer_function, cutoff_hz)
        .unwrap_or(DEFAULT_FILTER_ORDER);

    // Calculate confidence (keep existing implementation)  
    let confidence = calculate_measurement_confidence(&transfer_function);

    Ok(MeasuredFilterResponse {
        cutoff_hz,
        filter_order,
        confidence,
        transfer_function,
    })
}
EOF

echo "Created corrected implementation - the key changes:"
echo "1. Proper crossing detection instead of 'closest match'"
echo "2. Linear interpolation for accurate cutoff frequency"
echo "3. Better data validation and outlier rejection"
echo "4. Fallback logic for edge cases"
echo ""
echo "This should give you realistic, data-driven cutoff measurements!"
```

Length of output: 309

---



</details>

nerdCopter I completely understand your frustration! After this full review, I've identified the **fundamental flaw** in the current implementation that explains all your issues.

## The Core Problem

The current `find_cutoff_frequency` function is completely wrong for filter analysis:

```rust
// CURRENT (BROKEN) ALGORITHM:
for &(freq, ratio) in transfer_function {
    let diff = (ratio - target_ratio).abs();  // ← Just finds CLOSEST to 0.707
    if diff < best_diff {                     //   NOT an actual crossing!
        best_freq = freq;
    }
}
```

**This doesn't detect cutoff frequencies - it just finds whatever frequency happens to be numerically closest to 0.707!** That's why you've been getting random results.

## Complete Solution

Replace the current `find_cutoff_frequency` and `measure_filter_response` functions in `src/data_analysis/filter_response.rs` with this corrected implementation:

```rust
fn find_cutoff_frequency(
    transfer_function: &[(f64, f64)],
    target_ratio: f64,
) -> Result<f64, Box<dyn std::error::Error>> {
    if transfer_function.len() < 2 {
        return Err("Need at least 2 points for cutoff detection".into());
    }

    // Sort by frequency to ensure proper ordering
    let mut tf_sorted: Vec<(f64, f64)> = transfer_function.to_vec();
    tf_sorted.sort_by(|a, b| a.0.partial_cmp(&b.0).unwrap_or(std::cmp::Ordering::Equal));

    // Look for actual -3dB crossing (above to below threshold)
    for i in 1..tf_sorted.len() {
        let (f1, r1) = tf_sorted[i - 1];
        let (f2, r2) = tf_sorted[i];

        if !f1.is_finite() || !f2.is_finite() || !r1.is_finite() || !r2.is_finite() {
            continue;
        }

        // Look for downward crossing: above → below threshold
        if r1 >= target_ratio && r2 <= target_ratio {
            if (r2 - r1).abs() < 1e-12 {
                return Ok(f1);
            }
            
            // Linear interpolation for exact crossing
            let t = (target_ratio - r1) / (r2 - r1);
            let cutoff_freq = f1 + t * (f2 - f1);
            
            if cutoff_freq > 0.0 && cutoff_freq.is_finite() {
                return Ok(cutoff_freq);
            }
        }
    }

    // Fallback: find reasonable approximation
    let mut best_freq = None;
    let mut best_diff = f64::INFINITY;
    
    for &(freq, ratio) in &tf_sorted {
        if freq > 10.0 && freq < 1000.0 && ratio > 0.1 && ratio < 2.0 {
            let diff = (ratio - target_ratio).abs();
            if diff < best_diff {
                best_diff = diff;
                best_freq = Some(freq);
            }
        }
    }
    
    if let Some(freq) = best_freq {
        if best_diff < 0.2 { // Only accept if reasonably close
            return Ok(freq);
        }
    }

    Err("Could not find cutoff frequency crossing".into())
}

pub fn measure_filter_response(
    unfiltered_spectrum: &[(f64, f64)],
    filtered_spectrum: &[(f64, f64)],
    _sample_rate: f64,
) -> Result<MeasuredFilterResponse, Box<dyn std::error::Error>> {
    if filtered_spectrum.len() != unfiltered_spectrum.len() {
        return Err("Filtered and unfiltered spectra must have same length".into());
    }
    if filtered_spectrum.len() < MIN_SPECTRUM_POINTS_FOR_ANALYSIS {
        return Err(format!(
            "Need at least {} frequency points for reliable analysis",
            MIN_SPECTRUM_POINTS_FOR_ANALYSIS
        ).into());
    }

    // Build transfer function with proper validation
    let mut transfer_function = Vec::new();

    for i in 0..filtered_spectrum.len() {
        let (freq, filt_mag) = filtered_spectrum[i];
        let (_, unfilt_mag) = unfiltered_spectrum[i];

        if freq >= FILTER_ANALYSIS_MIN_FREQ_HZ
            && freq <= FILTER_ANALYSIS_MAX_FREQ_HZ
            && freq.is_finite()
            && filt_mag.is_finite() 
            && unfilt_mag.is_finite()
            && unfilt_mag > 1e-12  // Avoid division by tiny numbers
            && filt_mag >= 0.0
        {
            let ratio = filt_mag / unfilt_mag;
            
            // Allow ratios > 1.0 but reject extreme outliers
            if ratio.is_finite() && ratio > 0.0 && ratio < 10.0 {
                transfer_function.push((freq, ratio));
            }
        }
    }

    if transfer_function.len() < 10 {
        return Err("Insufficient valid data points".into());
    }

    // Use proper crossing detection
    let cutoff_hz = find_cutoff_frequency(&transfer_function, CUTOFF_MAGNITUDE_RATIO)?;

    let filter_order = estimate_filter_order_from_transfer(&transfer_function, cutoff_hz)
        .unwrap_or(DEFAULT_FILTER_ORDER);

    let confidence = calculate_measurement_confidence(&transfer_function);

    Ok(MeasuredFilterResponse {
        cutoff_hz,
        filter_order,
        confidence,
        transfer_function,
    })
}
```

## What This Fixes

1. **Proper crossing detection** - Looks for where transfer function actually crosses -3dB threshold
2. **Linear interpolation** - Gives accurate cutoff frequency between data points
3. **Data-driven approach** - Measures what's actually in your flight data
4. **Robust validation** - Handles edge cases and outliers properly

This should finally give you realistic, measured cutoff frequencies that reflect the actual filtering behavior in your flight logs, as you originally intended!

<!-- 
The user wants the measured filter response analysis to be purely data-driven without artificial frequency constraints. They want to measure actual cutoff frequencies from unfiltered vs filtered spectral data, even if the results show unexpectedly low cutoffs like 15Hz. The measurement system should report what it finds in the real data, not what we expect it should find.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 60
File: src/data_analysis/filter_response.rs:966-1021
Timestamp: 2025-10-05T20:37:53.448Z
Learning: For the BlackBox_CSV_Render measured filter response analysis, the attenuation-based approach `abs(unfilt_mag - filt_mag)` works better than the transfer function ratio approach `filt_mag / unfilt_mag` for real flight data. The ratio approach produces spurious cutoff detections (e.g., 47Hz) due to numerical instability and noisy crossings, while the attenuation approach reliably finds where significant filtering begins.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 53
File: src/data_analysis/filter_response.rs:840-854
Timestamp: 2025-09-09T19:03:16.302Z
Learning: The user wants the measured filter response analysis to be purely data-driven without artificial frequency constraints. They want to measure actual cutoff frequencies from unfiltered vs filtered spectral data, even if the results show unexpectedly low cutoffs like 15Hz. The measurement system should report what it finds in the real data, not what we expect it should find.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2026-01-08T14:48:17.022Z
Learning: For the BlackBox_CSV_Render project, Bode plot transfer function estimation (PR `#118`) is mathematically correct but fundamentally incompatible with normal operational flight logs due to low coherence (requires controlled system-identification inputs like chirp/PRBS on secured craft). Normal flights produce unreliable results due to nonlinearities, closed-loop conditions, and nonstationary maneuvers. The feature should be opt-in only (via --bode flag) with documentation clarifying it's for formal system-identification experiments, not routine flight log analysis. Existing PSD/spectrum plots are the appropriate tool for operational flight logs.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2026-01-14T21:56:11.727Z
Learning: RC command and setpoint smoothness analysis (time-domain metrics like derivative, jerk, total variation, and spectral energy) is fundamentally different from Bode plot transfer function estimation and IS VALID for operational Betaflight flight logs. Unlike Bode plots which require controlled system-identification inputs, setpoint smoothness analysis works with normal flight data by measuring command quality through time-domain and spectral metrics without estimating transfer functions. The existing plot_setpoint_derivative.rs only visualizes raw derivatives and does not calculate quantitative smoothness metrics.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2026-01-14T21:54:32.732Z
Learning: Dynamic notch filter tracking plots (showing FFT_FREQ debug data over time) are useful for operational Betaflight flight logs because they visualize real-time filter behavior during normal flights. Unlike Bode plots which require controlled system-identification inputs, dynamic notch tracking works with standard flight data to show how notch filters follow resonances. The debug[0-2] fields contain notch center frequencies when debug_mode=FFT_FREQ.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 71
File: src/main.rs:888-909
Timestamp: 2025-10-19T18:25:15.413Z
Learning: In the BlackBox_CSV_Render project, gyroUnfilt headers are always present for all three axes or completely absent (with all three axes falling back to debug data). Per-axis fallback detection is not needed—the all-or-nothing approach in main.rs correctly reflects real-world log file behavior.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2025-08-31T20:17:05.654Z
Learning: The user nerdCopter successfully implemented a minimal, targeted fix for replacing "Axis 0/1/2" labels with "Roll/Pitch/Yaw" by using a simple axis_names array lookup in main.rs and plot_framework.rs, avoiding over-engineering and scope creep.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2025-11-21T19:49:21.004Z
Learning: For the BlackBox_CSV_Render project, the user nerdCopter worked extensively to perfect right-aligned peak label positioning in src/plot_framework.rs. The working formula at line 575 uses `peak_x_pixel - tri_label_width + triangle_width` with system font measurement. This positioning logic should not be modified without explicit user request.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 18
File: src/data_analysis/calc_step_response.rs:0-0
Timestamp: 2025-06-03T18:01:54.978Z
Learning: The user nerdCopter prefers to defer unit testing implementation when suggested for the BlackBox_CSV_Render project.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 0
File: :0-0
Timestamp: 2025-11-25T17:54:40.907Z
Learning: For the nerdCopter/BlackBox_CSV_Render project, the codebase has strict linting rules that enforce `.unwrap_or(default)` patterns over `if let Some` for certain Option handling cases. These linting rules are enforced by pre-commit hooks and should be respected - they take precedence over general style consistency suggestions.

---

Learnt from: nerdCopter
Repo: nerdCopter/BlackBox_CSV_Render PR: 55
File: LICENSE_COMMERCIAL:1-7
Timestamp: 2025-09-10T13:56:40.607Z
Learning: nerdCopter prefers to use minimal commercial license templates that are consistent across his projects, similar to what was used in the bbl_parser repository PR `#2`.

---

💡 Use @coderabbitai plan to create a plan for code changes