feat: Add Dynamic Notch Filter Activity Over Time

[nerdCopter]

Priority: Medium

Why Useful:

• Shows where dynamic notches are tracking
• Identifies if dynamic notch filters are stable or hunting
• Helps tune dynamic notch Q and range

Implementation:
Time-frequency plot showing dynamic notch center frequencies (from debug channels if available)

Impact: Critical for tuning dynamic notch filters; currently no dedicated visualization.

[coderabbitai]

📝 CodeRabbit Plan Mode

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

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Related Issues

• feat: Add Feedforward (F-Term) Effectiveness Plot #108
• feat: Add Setpoint Derivative (Rate of Change) Plot #103
• feat: Add Coherence Plot (Input-Output Correlation) #106
• feat: Add P, I D Activity Plot #105

👤 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 "Dynamic Notch Filter Activity Over Time" is useful or not for real Betaflight flight logs. deep research and fact-check all findings.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

echo "=== Searching for Dynamic Notch Filter plotting code ==="
rg -n -C5 "Dynamic Notch" --type rust

echo -e "\n=== Searching for dynamic notch filter implementation ==="
rg -n -C5 "dynamic.*notch|notch.*filter" --type rust -i | head -100

echo -e "\n=== Looking for plot functions related to notch filters ==="
fd -e rs -x grep -l "notch" {} \; | head -20

echo -e "\n=== Checking for any time-series notch filter plots ==="
rg -n "plot.*notch|notch.*time" --type rust -i

Length of output: 14490

---

🌐 Web query:

Betaflight dynamic notch filter how it works

💡 Result:

Short summary — how Betaflight's Dynamic Notch works

• Purpose: automatically find and remove narrow, time-varying gyro noise/resonance peaks (motor/prop or frame resonances) by placing one or two narrow notch filters around those frequencies to reduce oscillation without overly increasing control-loop delay. (betaflight.com)

• Detection: the code analyses gyro data (post‑filter/post‑notch) and detects dominant spectral peaks (FFT/peak tracking) to pick center frequency(ies) to suppress. It can track peaks as they move with throttle/RPM. (betaflight.com)

• Filtering action: it applies either a single narrow notch or a pair of closely spaced notches centered on the detected frequency. The notches’ center frequency, Q (sharpness), width, min/max operating range and count are configurable (CLI params like dyn_notch_q, dyn_notch_width_percent, dyn_notch_min_hz/max_hz, dyn_notch_range, dyn_notch_count). Wider/notch settings reduce residual noise but add more phase delay; narrower settings reduce delay but risk missing spread noise. (betaflight.com)

• Delay control / behavior tweaks: Betaflight’s dynamic notch runs on post-filter input, ignores very low-frequency pushes, will move higher when no peak is present to minimise delay, and provides LOW/MEDIUM/HIGH ranges to limit tracking. When RPM filtering is enabled, the dynamic notch is typically narrowed (or reduced to one notch) to focus on residual resonances and lower delay. (betaflight.com)

• Practical tuning tips: use blackbox/FFT logs (debug_mode = FFT_FREQ) to see peaks; increase dyn_notch_q and reduce width for narrow resonances; raise dyn_notch_min_hz or choose an appropriate range to avoid the dynamic notch tracking too-low frequencies (which add significant delay). Defaults are conservative; adjust gradually and verify with logs and careful test flights. (betaflight.com)

If you want, I can show the exact CLI settings that control each behavior and example starting values for common builds.

Citations:

• 1: https://www.betaflight.com/docs/wiki/tuning/4-0-Tuning-Notes?utm_source=openai
• 2: https://www.betaflight.com/docs/wiki/tuning/4-0-Tuning-Notes?utm_source=openai
• 3: https://www.betaflight.com/docs/wiki/tuning/4-0-Tuning-Notes?utm_source=openai
• 4: https://www.betaflight.com/docs/wiki/tuning/3-5-tuning-notes?utm_source=openai
• 5: https://www.betaflight.com/docs/wiki/tuning/3-5-tuning-notes?utm_source=openai

---

🌐 Web query:

Betaflight dynamic notch filter frequency tracking flight logs

💡 Result:

Short guide — how Betaflight’s dynamic notch frequency tracking appears in flight logs and how to log/interpret it:

1. What to log

• Enable Blackbox logging on your FC and record a flight. Use debug_mode = gyro_scaled (or gyro_filtered) to capture gyro data pre/post filtering for spectral analysis. [5].
• To log the dynamic notch’s tracked center frequency directly, set debug_mode = FFT_FREQ. This records the dynamic notch center frequency for each axis. [1][2].

2. How Betaflight decides center frequency

• The dynamic notch analyzes gyro data (FFT) to find the dominant noise peak and places a notch there; its behavior and tunable parameters are dyn_notch_quality, dyn_notch_width_percent (or dyn_notch_q / dyn_notch_width depending on BF version), dyn_notch_min_hz, and range (LOW/MEDIUM/HIGH). Defaults changed across 3.x → 4.x; RPM filtering changes the notch’s role. [1][2][4].

3. Interpreting the logs

• Use Blackbox viewers or PID Toolbox to view spectrums (FFT of gyro_scaled) to see peaks and confirm the notch location. Compare logs with dynamic notch ON vs OFF to see what peak it removed and how wide the notch was. [1][2][5].
• FFT_FREQ traces show the notch center over time; compare that trace to gyro spectral peaks to confirm correct tracking and to tune dyn_notch_min_hz, quality/Q and width to reduce delay while still removing resonance. [2][5].

4. Practical tuning tips (concise)

• When using RPM filtering, narrow the dynamic notch (single notch, small width, higher Q) because RPM notches remove motor harmonics; dynamic notch should handle frame resonances. Example recommendations are in Betaflight docs. Always test with Blackbox and monitor motor temps. [0][4].

Sources:
[0] Betaflight DShot / RPM filtering docs.
[1] Betaflight tuning notes (3.5) — dynamic notch details and FFT_FREQ debug_mode.
[2] Betaflight 4.0/4.1 tuning notes — dynamic notch role and tuning with RPM filter.
[5] Betaflight Blackbox logging & usage (debug_mode and how to log gyro/notch/FFT).

---

🏁 Script executed:

#!/bin/bash

echo "=== Search for any FFT_FREQ or debug mode parsing ==="
rg -n "FFT_FREQ|debug.*mode" --type rust -i | head -50

echo -e "\n=== Check if debug data fields are parsed from logs ==="
rg -n "debug\[|debug_mode" --type rust | head -50

echo -e "\n=== Look for any time-series plotting that could show filter tracking ==="
rg -n "time.*series|plot.*time" --type rust -i | head -50

echo -e "\n=== Check what header metadata is actually extracted ==="
cat src/data_analysis/filter_response.rs | grep -A 30 "extract_dynamic_notch_range\|extract_dterm_dynamic_notch_range"

Length of output: 14328

---

🏁 Script executed:

#!/bin/bash

echo "=== Check if FFT_FREQ debug mode is in the lookup table ==="
grep -n "FFT" src/debug_mode_lookup.rs

echo -e "\n=== Check if debug data columns are parsed from CSV ==="
rg -n "debug\[0\]|debug\[1\]|debug\[2\]|debug\[3\]" --type rust

echo -e "\n=== Look for what columns are actually read from CSV logs ==="
cat src/main.rs | grep -A 5 -B 5 "gyro\[0\]|gyro_unfilt" | head -50

Length of output: 711

---

🏁 Script executed:

#!/bin/bash

echo "=== Check what columns are actually parsed and stored ==="
cat src/data_input/log_parser.rs | head -150

echo -e "\n=== Check if debug data is stored in data structures ==="
rg -n "debug.*Vec|debug.*data" --type rust | head -30

echo -e "\n=== Check DataPoint struct to see if it includes debug fields ==="
cat src/types.rs | grep -A 30 "struct DataPoint\|pub struct DataPoint"

Length of output: 5782

---

🏁 Script executed:

#!/bin/bash

echo "=== Check full types.rs for DataPoint struct ==="
cat src/types.rs

echo -e "\n=== Check LogRowData struct in log_data.rs ==="
cat src/data_input/log_data.rs | head -100

Length of output: 4102

---

@nerdCopter, I've completed a deep analysis of the codebase and researched Betaflight's dynamic notch implementation. Here are my findings:

Critical Discovery: The Plot Doesn't Actually Exist

The "Dynamic Notch Filter Activity Over Time" plot referenced in this issue title does not currently exist in BlackBox_CSV_Render. What you have now is only:

• Static frequency range shading on spectrum plots (shows configured min_hz to max_hz)
• Configuration metadata displayed in legends

But Would It Be Useful If Implemented? YES - Very Different from Bode Plots

Dynamic notch filters work by automatically finding and removing narrow, time-varying gyro noise peaks through real-time FFT analysis and peak tracking, and Betaflight can log the tracked center frequencies directly using debug_mode = FFT_FREQ.

Key Differences from Bode Plots

Feature	Bode Plots (Transfer Function)	Dynamic Notch Tracking
Input Required	Controlled system-ID inputs (chirp/PRBS on secured craft)	Normal operational flight data
Data Source	Requires special test maneuvers	Standard flight logs with debug_mode=FFT_FREQ
Applicability	Formal system-identification experiments only	Every normal flight
What It Shows	System frequency response (unreliable with normal flights)	Actual real-time filter behavior

Why Dynamic Notch Tracking IS Useful

1. Uses operational data: Betaflight detects dominant spectral peaks through FFT/peak tracking and places notches to suppress them, and this happens during every normal flight

2. Validates filter performance: You can see:

   • Whether notches are tracking motor/prop resonances correctly
   • If notches are stuck at min/max frequency limits
   • How notch positions change with throttle/maneuvers
   • If your min/max Hz settings are appropriate

3. Data already parsed: Your code already stores debug[0-3] values in LogRowData, and recognizes FFT_FREQ debug mode (code 17). The debug fields contain notch center frequencies when that mode is active.

4. Practical tuning tool: Users can adjust dyn_notch_q, width, min_hz and max_hz settings and verify with logs

Implementation Would Be Straightforward

Since debug data is already parsed, you'd just need a new plot function that:

1. Checks if debug_mode == FFT_FREQ (mode 17)
2. Plots debug[0], debug[1], debug[2] (up to 3 notches) vs. time
3. Shows how notch frequencies track throughout the flight

This would be genuinely useful for real flight logs, unlike Bode plots which require controlled test inputs that your learning correctly flagged as incompatible with operational flights.

Recommendation: This feature is worth implementing. It provides actionable tuning insights from normal flight data without requiring special test procedures.

---

✏️ Learnings added

Learnt from: nerdCopter
URL: https://github.com/nerdCopter/BlackBox_CSV_Render/issues/109

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.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

---

🧠 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: 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: 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.

[coderabbitai]

Coding Plan

Approach

Create a time-series line plot that visualizes dynamic notch filter center frequencies over time, using data from the FFT_FREQ debug mode channels. This allows users to see where dynamic notches are tracking, identify stability or hunting behavior, and tune notch parameters.

Observations

The project is a Rust-based flight log analysis tool that parses Betaflight/EmuFlight/INAV blackbox logs (CSV format) and generates various diagnostic plots. The plot system uses a function-based architecture where each plot type is an independent module in src/plot_functions/. Time-series plots follow a pattern of extracting timestamps from row.time_sec, organizing data into PlotSeries structs, and rendering via draw_stacked_plot() from plot_framework.rs. Debug channels are already parsed as generic debug[0-3] arrays, and the debug_mode header value is available for determining which debug mode was active during logging.

Assumptions

Assumption 1: Debug mode validation approach

Options Considered:

• Use the existing lookup_debug_mode() function to convert the debug_mode integer to a name string and compare against "FFT_FREQ"
• Directly compare against multiple integer values based on firmware version detection

Chosen Option: 1

Rationale: Using the name-based lookup is more maintainable and already accounts for firmware-specific mappings in the lookup tables.

Assumption 2: Plot layout for single-axis debug data

Options Considered:

• Create a single-panel line chart with 3 series (Notch 1, 2, 3)
• Adapt the 3-axis stacked layout used by other time-series plots, showing the same data on one panel

Chosen Option: 1

Rationale: A single-panel chart is cleaner and more appropriate since FFT_FREQ data represents only one axis. This avoids empty panels or redundant displays.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Core Plot Implementation

Create the main plot function that extracts dynamic notch frequencies from FFT_FREQ debug channels and renders them as a time-series line chart.

Task 1: Create Dynamic Notch Activity Plot Module

Implement the new plot function following existing time-series patterns.

• Create src/plot_functions/plot_dyn_notch_activity.rs following the structure of plot_pid_activity.rs
• Define a public function plot_dyn_notch_activity() accepting log data, header metadata, sample rate, and output path
• Extract timestamps from row.time_sec and notch frequencies from row.debug[0], row.debug[1], row.debug[2]
• Filter out data points where debug values are None or zero (notch inactive)
• Create three PlotSeries instances for Notch 1, 2, and 3 with distinct colors
• Render using Plotters with time on X-axis and frequency (Hz) on Y-axis
• Add legend showing notch labels with min/avg/max frequency statistics
• Set Y-axis to auto-scale based on data with reasonable frequency bounds (50-600Hz typical range)

Task 2: Add Color Constants for Notch Visualization

Add constants for consistent notch frequency line colors.

• Add new color constants in src/constants.rs for COLOR_NOTCH_1, COLOR_NOTCH_2, COLOR_NOTCH_3
• Choose visually distinct colors that work well together and against the plot background
• Follow the existing color constant naming pattern used for PID terms

🤖 Prompt for AI agents

Implement the dynamic notch activity plot module that visualizes notch filter
frequencies over time from FFT_FREQ debug data.

Create `plot_dyn_notch_activity.rs` module:
- Define public function accepting log data, header metadata, sample rate, and
output path
- Extract timestamps from `row.time_sec` and notch frequencies from
`row.debug[0-2]`
- Filter out None or zero values (inactive notches)
- Create three PlotSeries for Notch 1, 2, 3 with distinct colors
- Render single-panel time-series plot with time on X-axis, frequency (Hz) on
Y-axis
- Add legend with min/avg/max statistics for each notch
- Auto-scale Y-axis with 50-600Hz typical bounds

Add color constants:
- Define `COLOR_NOTCH_1`, `COLOR_NOTCH_2`, `COLOR_NOTCH_3` in `constants.rs`
- Use visually distinct colors following existing patterns

Phase 2: Application Integration

Register the new plot in the application and add conditional execution based on debug mode validation.

Task 1: Export Plot Module

Add the new plot to the module system.

• Add pub mod plot_dyn_notch_activity; to src/plot_functions/mod.rs
• Follow existing module declaration patterns

Task 2: Integrate Plot Invocation in Main

Add the plot configuration and conditional execution logic.

• Import plot_dyn_notch_activity function in src/main.rs alongside other plot imports
• Add a boolean field (e.g., dyn_notch_activity: bool) to the PlotConfig struct
• Create a helper function to check if FFT_FREQ debug mode is active:
  • Retrieve debug_mode from header_metadata
  • Use lookup_debug_mode() to convert integer to name
  • Return true if name equals "FFT_FREQ"
• Add conditional plot invocation that:
  • Checks if plot_config.dyn_notch_activity is enabled
  • Validates FFT_FREQ debug mode is active using the helper
  • If debug mode mismatch, print informative message explaining which debug mode is needed
  • If valid, call plot_dyn_notch_activity() with required parameters
• Add the plot to the default enabled plots list

Task 3: Handle Edge Cases and User Feedback

Ensure graceful handling when FFT_FREQ debug mode is not active.

• When debug mode validation fails, output a clear message: "Dynamic notch activity plot requires FFT_FREQ debug mode (set debug_mode = FFT_FREQ in Betaflight CLI)"
• When plot is skipped due to wrong debug mode, do not treat it as an error—just skip with informational output
• If debug channels contain all zeros/None values, skip the plot with a message indicating no dynamic notch data was found

🤖 Prompt for AI agents

Integrate the dynamic notch activity plot into the application with debug mode
validation.

Export module:
- Add `pub mod plot_dyn_notch_activity;` to `plot_functions/mod.rs`

Integrate in main:
- Import `plot_dyn_notch_activity` function
- Add `dyn_notch_activity: bool` field to `PlotConfig` struct
- Create helper function to validate FFT_FREQ debug mode:
  - Retrieve debug_mode from header_metadata
  - Use `lookup_debug_mode()` to convert to name
  - Return true if name equals "FFT_FREQ"
- Add conditional plot invocation:
  - Check if enabled in config
  - Validate FFT_FREQ debug mode using helper
  - Print informative message if wrong debug mode
  - Call plot function if valid
- Add to default enabled plots

Handle edge cases:
- Print clear message when FFT_FREQ mode not active
- Skip gracefully without error on debug mode mismatch
- Skip with message if all debug data is zero/None

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement the dynamic notch activity plot module that visualizes notch filter
frequencies over time from FFT_FREQ debug data.

Create `plot_dyn_notch_activity.rs` module:
- Define public function accepting log data, header metadata, sample rate, and
output path
- Extract timestamps from `row.time_sec` and notch frequencies from
`row.debug[0-2]`
- Filter out None or zero values (inactive notches)
- Create three PlotSeries for Notch 1, 2, 3 with distinct colors
- Render single-panel time-series plot with time on X-axis, frequency (Hz) on
Y-axis
- Add legend with min/avg/max statistics for each notch
- Auto-scale Y-axis with 50-600Hz typical bounds

Add color constants:
- Define `COLOR_NOTCH_1`, `COLOR_NOTCH_2`, `COLOR_NOTCH_3` in `constants.rs`
- Use visually distinct colors following existing patterns
===============================================================================

Task: 2

Integrate the dynamic notch activity plot into the application with debug mode
validation.

Export module:
- Add `pub mod plot_dyn_notch_activity;` to `plot_functions/mod.rs`

Integrate in main:
- Import `plot_dyn_notch_activity` function
- Add `dyn_notch_activity: bool` field to `PlotConfig` struct
- Create helper function to validate FFT_FREQ debug mode:
  - Retrieve debug_mode from header_metadata
  - Use `lookup_debug_mode()` to convert to name
  - Return true if name equals "FFT_FREQ"
- Add conditional plot invocation:
  - Check if enabled in config
  - Validate FFT_FREQ debug mode using helper
  - Print informative message if wrong debug mode
  - Call plot function if valid
- Add to default enabled plots

Handle edge cases:
- Print clear message when FFT_FREQ mode not active
- Skip gracefully without error on debug mode mismatch
- Skip with message if all debug data is zero/None

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!