FIR Identification — System Identification/Offline

FIR Identification (offline)

System Identification / Offline

Fits the least-squares impulse response of a measured input/output pair: y[k] ≈ Σ_i b_i·u[k−i] over Filter Length taps. The block buffers both signals for the whole run and performs the fit once the run ends.

This is the robust first look that precedes any parametric fit. The model is linear in its parameters, so there is no iteration to converge and no denominator to go unstable – the solve has a single minimum and either succeeds or reports why. Use it to see the shape and length of a plant's response before choosing an order for IIR Identification or a structure for the recursive estimators.

Ports

• u – the excitation, a [1,1] scalar per step. A PRBS Generator or Multisine Generator is the usual source.
• y – the measured response, a [1,1] scalar per step, sampled at the same rate as u.
• b – the fitted taps, a [N,1] column where N is Filter Length. ⚠ It holds zeros for the whole run – see Notes.

Parameters

• Filter Length – N, the number of taps to fit, at least 1. Choose it to cover the plant's settling time in samples: too short truncates the response and biases every remaining tap, too long fits noise into the tail. The run must supply at least N samples, and comfortably more than N for the fit to mean anything.
• 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 of them emits what the block actually does each step: a zero coefficient vector on the output port.

The fit itself is deliberately not ported. A deployable core is a per-step scan with no end-of-run hook to run a batch solve in, and the three fixed-point HDL targets could not carry a normal-equations solve meaningfully. When the identified coefficients have to exist in generated code, export Recursive Least Squares instead – its update is per-step by construction.

Simulink bridge

None. Simulink's identification blocks belong to the System Identification Toolbox, which is not installed here, so a mapping could not be parity-verified even if it were written. The bridge reports the block rather than dropping it silently, and it has no parity testbench, which is the documented consequence of Support::None rather than a gap. Code export verification still covers it across all ten languages.

Notes

• ⚠ The output port carries zeros for the entire run, by design. The fit completes at the end of the run, after the last step, so there is no step at which a meaningful coefficient could be placed on a port. The run log is the result surface – the fitted taps and the residual are written there when the run finishes. The offline IIR Identification block publishes exactly the same contract, deliberately, so the two agree on what a not-yet-fitted output means.
• Stateful and inherently discrete: samples are collected per step, so the block declares setDiscreteOnlyBlock(true).
• The fit is a single symmetric positive-definite solve of the normal equations. It is reported as failed, with the reason, if the run supplied fewer than N samples, or if the conditioning of those equations says the excitation cannot determine N taps – a constant input, for instance, cannot identify more than one of them. That second check is explicit rather than inherited: a least-squares solver returns a solution for a singular system without complaining, so an unchecked fit would report meaningless taps as though they had been measured.