Frequency response

Some sensors don't have a single reference-vs-measured relationship the way a pressure or temperature sensor does — an accelerometer or a microphone's output depends on the frequency at which it's excited as well as the amplitude. Frequency response is Step 2's fourth Input data method, alongside Reference vs Measured, Reference vs Indicated, and Model: instead of fitting a curve, you tune a platform and the sensor together at several frequencies and record the reference standard's and the sensor's output amplitude at each one. It's offered for every Calibration purpose, including After Repair — there's no as-found/as-left split for this mode.

Sweep entry (Step 2)

Choosing Frequency response replaces the usual point table with a settings row and a sweep table:

• Frequency unit — Hz, kHz, MHz, or GHz, applied to every row.
• Reference unit — the reference standard's physical quantity unit (e.g. g, Pa), from the channel's physical quantity.
• Measured unit — the sensor's own output unit (e.g. mV, V), from the channel's output signal type.
• Amplitude type — dB, RMS, Peak-to-Peak, or Peak, applied to both the reference and measured amplitude at every frequency (both must be read the same way for the sensitivity ratio below to mean anything).
• Include phase offset — off by default. When enabled, an extra Offset column appears in the table and an angle unit (° or rad) becomes selectable — use it if your reference/measurement setup also gives you the phase difference between the reference and the sensor's output at each frequency.

Below that, the same manual-entry-or-CSV-upload table every other mode uses, with one row per frequency point: Frequency, Reference, Measured, and Offset (only shown when enabled). At least 2 rows are required. A CSV upload expects a header row with columns named Frequency, Reference, Measured, and optionally Offset.

Sensitivity model (Step 3)

There's no curve to fit here — Step 3 shows one panel instead of the usual Method/Uncertainty/Conformity stack:

• Baseline frequency [#baseline-frequency] — a dropdown listing every frequency entered on Step 2. Pick the one your sensor's output is normally specified against (often the sensor's rated frequency, e.g. 100 Hz for many accelerometers).
• Sensitivity — the ratio between the measured and reference amplitudes at the baseline frequency (measured ÷ reference), in output unit per physical-quantity unit (e.g. mV/g). This is the calibration's saved result.

Every other frequency's sensitivity is expressed as a % deviation from the baseline: for a point with sensitivity s and the baseline's sensitivity g, deviation = (s − g) / g × 100. The baseline point's own deviation is always exactly 0.

Two charts, both with round markers connected by lines, an x-axis that switches to logarithmic automatically when the sweep spans a decade or more (linear otherwise), and hover tooltips:

• Sensitivity vs. frequency — always shown. Hovering a point shows its frequency, sensitivity, and % deviation from the baseline.
• Phase vs. frequency — shown only when Include phase offset is enabled, stacked below the sensitivity chart. Only points with an entered offset are plotted.

Since there's no uncertainty budget or decision rule for this mode, a Frequency response calibration is never marked as failing conformity — there's no specification to compare against. The saved record still goes through the normal approval workflow if a Checked by reviewer was assigned, and downloads a certificate like any other calibration.

Internal representation

Open Gauge stores every calibration's model the same way regardless of mode, so a Frequency response result is represented internally as a polynomial of order 1 with no offset — a pure gain: poly_order = 1, poly_coefficients = [gain, 0] (highest degree first, the same convention every other fitted model uses). No regression is actually run; the "fit" is just the baseline frequency's own measured/reference ratio. The full sweep — every frequency's reference/measured amplitude, optional offset, and computed sensitivity/deviation — is stored separately, one row per point, and is what powers the two charts above.