Varying Notch Filter — Control Systems/Continues
Control_Systems/Continues/Varying_Notch_Filter · 4 input / 1 output port(s) at insert · exports to Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text
Description#
The block's own DESCRIPTION_HTML, rendered verbatim — the same text the config dialog's info panel and the library navigator show. Fix a wrong sentence in the block's .cpp (R-D9), never here.
Varying Notch Filter
Control Systems / Continues
A second-order notch whose centre frequency, depth and width are all signals rather than settings, so the filter retunes continuously while the model runs:
H(s) = (s² + 2·gmin·ζ·ω₀·s + ω₀²) ÷ (s² + 2·ζ·ω₀·s + ω₀²)
At s = jω₀ the ratio collapses to exactly gmin – that is what makes it the notch depth – while the gain at DC and at high frequency is 1. Typical use is notching out a resonance whose frequency moves with an operating point.
Ports
- u – the signal to filter. Scalar.
- w0 – ω₀, the notch centre frequency in rad/s. Scalar, and expected positive.
- gmin – gmin, the gain AT the notch. 1 is no notch at all, 0 is a perfect null, and values above 1 make it a peak rather than a notch.
- damping – ζ, which sets how WIDE the notch is: larger is wider. Scalar, and expected positive.
- Output – y, the filtered signal, scalar.
All four inputs are scalars; a matrix signal is reported rather than filtered entry by entry, because each entry would need a state pair of its own.
Parameters
- The block has no parameters of its own – everything it needs arrives on a port, which is the whole point of it. Its Simulink counterpart has none either.
- Sampling Time (s) – zero or less inherits the solver's rate; a positive value runs the block at that period.
Code export
All ten targets: Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog and PLC Structured Text. Every one integrates the two states with forward Euler at the block's period, reading the three coefficients from their ports each step. That differs from the fixed-coefficient continuous blocks, which export an exact ZOH discretization: a ZOH needs a matrix exponential of a CONSTANT A, and here A moves every sample, so there is no constant to take it of. The in-app run integrates with the solver's Runge-Kutta, so export and simulation agree to the step's order rather than exactly.
Simulink bridge
Import and export, mapped to cstblocks/Linear Parameter Varying/Varying
Notch Filter – note the library is cstblocks, not the
"Control System Toolbox" display name, which add_block rejects.
There are no parameters to map: both sides take everything on ports, so
the bridge carries the connection alone and cannot lose a setting.
"Sampling Time (s)" does NOT cross – this Simulink block defines no
SampleTime parameter, so the rate stays on the ICore side.
Notes
- Continuous and stateful: two states, both starting at zero, realized in observer canonical form (transposed direct form II) – the same realization the Simulink block integrates. That matters here in a way it would not on a fixed filter: every coefficient is a signal, and two realizations of one transfer function stop being the same system the moment the coefficients move.
- Linear at any instant but not time-invariant, so it deliberately carries no state space – a stored A/B/C/D would be a snapshot of one sample. Model reduction reports it as unmergeable, which is the honest answer.
- Feedthrough is direct: D = 1, so u reaches y within the same step and the block cannot break an algebraic loop.
Code facts#
| Fact | Value |
|---|---|
| registered type | Control_Systems/Continues/Varying_Notch_Filter |
| family | Control_Systems/Continues |
| solver environment class | ICoreBlock_0_Control_Systems_1_Continues_2_Varying_Notch_Filter |
| source | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/Varying_Notch_Filter/ICoreBlock_0_Control_Systems_1_Continues_2_Varying_Notch_Filter.cpp |
| header | src/ICoreSDK/ICoreBlockLibrary/Blocks/Control_Systems/Continues/Varying_Notch_Filter/ICoreBlock_0_Control_Systems_1_Continues_2_Varying_Notch_Filter.h |
| default size on canvas | 120 × 110 px |
| ports at insert | 4 in, 1 out |
| code generators implemented | Python, MATLAB, Java, Rust, C, C++, VHDL, Verilog, SystemVerilog, PLC Structured Text |
Ports#
| # | Direction | Signal type | Description label |
|---|---|---|---|
| 1 | in | ICoreDouble | u |
| 2 | in | ICoreDouble | w0 |
| 3 | in | ICoreDouble | gmin |
| 4 | in | ICoreDouble | damping |
| 5 | out | ICoreDouble | y |
Ports the constructor creates. A block whose port list changes with its configuration adds or removes ports at load time; the count above is the one a freshly inserted block has.
Configuration variables#
No config variable beyond the Sampling Time (s) every block carries.
Every block also carries Sampling Time (s) from ICoreBlockSolverEnvironment: zero or less inherits the solver's rate, a positive value runs the block at that period.
Simulink bridge#
| support | Support::Both |
| Simulink path | cstblocks/Linear Parameter Varying/Varying Notch Filter |
| port-count rule | PortsParam::None |
SampleTime parameter | no — the counterpart defines none; the rate stays on the ICore side |
Caveat (shown to the user): every coefficient travels on a port on both sides, so nothing can be lost in the mapping; "Sampling Time (s)" does not cross, because this Simulink block defines no SampleTime parameter
Catalog contract: src/ICoreSDK/ICoreCoder/ICoreCommandSystem/SimulinkBridge/ICoreSimulinkBlockCatalog.h
Description vs code#
The lists agree. check_block_descriptions.py finds no disagreement between the description's Ports, Parameters, Code export and Simulink bridge lists and the code's.
The verdict above is
tools/docs/check_block_descriptions.py(P7.1), which compares LISTS. It cannot read a sentence: "stateless" on a block with a state, an initial-value semantic the recursion does not implement, a "not synthesizable" caveat the HDL banner contradicts. That is the agent audit (P7.3) on BLOCK_DESCRIPTION_AUDIT.md, and this tool's green is not a substitute for one.
File banner (developer view)#
The top comment of the block's .cpp — the maths, the realization and the export strategy, addressed to whoever changes it. It must not contradict the description above (P7.5).
Varying Notch Filter — second-order notch retuned from its ports every sample H(s) = (s^2 + 2*gmin*zeta*w0*s + w0^2) / (s^2 + 2*zeta*w0*s + w0^2)
OBSERVER canonical form (transposed direct form II), with a1 = 2*zeta*w0, a0 = w0^2 and bet = 2*zeta*w0*(gmin-1) — that last being b1 - a1, the numerator's s term once the D = 1 feedthrough is split off. The b0 - a0 term is exactly zero and cancels, which is why dz2 reads no input at all: y = z1 + u dz1 = -a1*z1 + z2 + bet*u dz2 = -a0*z1
⚠ THE REALIZATION IS THE WHOLE POINT, not an implementation detail. This block was first written in the CONTROLLABLE form (dx1 = x2; dx2 = -a0*x1 - a1*x2 + u; y = bet*x2 + u), which has the identical transfer function and passed export verification 10/10 — and failed Simulink parity by 0.464, because export verification compares ICore against ICore and cannot see a realization difference at all. Two realizations of one transfer function are the same system only while the coefficients hold still; here every coefficient is a port. Measured against the real R2026a block with w0, gmin and damping ALL moving (ode1, h = 0.01): observer form 0.000e+00, controllable form 4.5e-01. Do not "simplify" it back.
See the header for why this block carries a state but NO state space, and for the numeric evidence behind the transfer function.
Sample results#
The same rig also ran:
| Stimulus | What it is | Output range |
|---|---|---|
impulse | Impulse: one sample of 1 at k = 5, 0 elsewhere (Repeating Sequence Stair) | -0.0155 … 0.9922 |
ramp | Ramp: slope 1 from t = 0 | 0 … 1.873e17 |
sine | Sine Wave: amplitude 1, 2 rad/s, no phase, no bias | -1.215 … 1.279 |
table | Repeating Sequence Stair: [-2 -1 -0.5 0 0.5 1 2 3], one entry per sample | -1.632 … 6.691 |
Plotted: step — Step: 0 -> 1 at t = 1 s
Category dynamic · sample time 0.1 · 60 steps · commit ccf005c8 · produced by docsSample --out <folder> --steps 60 · data docs/generated/samples/Control_Systems__Continues__Varying_Notch_Filter.json · the SVG is generated from those numbers by tools/docs/plot_svg.py, so it is a run and not a drawing (R-D10).