The uncertainty budget

Open Gauge expresses measurement uncertainty as an itemized budget (GUM Annex H.1 table format), not a single opaque number. Every calibration stores an array of budget rows, one per contribution, each expressed as a standard uncertainty in the measurand's own units.

Type A vs. Type B

Per GUM §0.7/§3.3.3, "Type A" and "Type B" describe how an uncertainty was evaluated, not whether it's "random" or "systematic" (GUM explicitly deprecates that older distinction):

• Type A — evaluated by statistical analysis of a series of observations (e.g. the spread of calibration-fit residuals).
• Type B — evaluated by any other means: manufacturer specs, calibration certificates, handbook data, resolution, judgement.

Contributions

Resolution as a rectangular distribution

A digital reading's resolution defines a range within which the true value could equally likely fall — a rectangular (uniform) distribution, not normal. Per GUM §4.3.7, its standard uncertainty is:

$$u_{\text{resolution}} = \frac{\text{resolution}}{\sqrt{12}}$$

Combination

All budget rows are combined via root-sum-square (GUM Eq. 10), assuming the contributions are uncorrelated:

$$u_c(y) = \sqrt{\sum_i u(x_i)^2}$$

This is the combined standard uncertainty, stored as combined_uncertainty ("Combined (RSS)" in the wizard).

Expansion

The expanded uncertainty is:

$$U = k \cdot u_c(y)$$

giving an interval expected to encompass a stated fraction (the confidence level) of values reasonably attributable to the measurand.

Coverage factor

The coverage factor $k$ is always derived from the requested confidence level and distribution — there's no separate "coverage factor" input anywhere in Open Gauge, because a user-picked $k$ independent of confidence level and distribution shape isn't statistically meaningful:

• Normal distribution — the normal quantile for the requested confidence level (GUM §6.3.3's "simple case"):

  $$k = \Phi^{-1}\!\left(0.5 + \frac{\text{confidence \%}}{200}\right)$$

  e.g. 95% confidence → $k \approx 1.96$, 99% → $k \approx 2.58$.

• t-distribution / χ² distribution — $k$ is derived from the effective degrees of freedom $\nu_{\text{eff}}$, via the Welch-Satterthwaite formula (GUM Eq. G.2b):

  $$\nu_{\text{eff}} = \frac{u_c(y)^4}{\displaystyle\sum_i \frac{u(x_i)^4}{\nu_i}}$$

  Rows with unknown (infinite) degrees of freedom — exactly-known Type B contributions — drop out of this sum entirely. If no row has finite degrees of freedom, $\nu_{\text{eff}}$ is undefined and Open Gauge falls back to the normal-distribution quantile above (the correct limit as $\nu \to \infty$).

  The wizard shows the resulting $k$ (2 decimal places) directly under the Confidence % input, so its effect on the interval is visible immediately, without waiting for the full analysis to re-render below.

Filling in an uncertainty box

The Sensor nominal accuracy box shows its value next to a fixed unit label — the channel's own configured unit, from its Uncertainty (±) field (or the channel's base unit, if that field was expressed as %FS). That isn't necessarily the same unit this calibration's own reference values are entered in (Step 2's reference unit) — Open Gauge converts it to that scale internally before combining it into the budget, so the two never need to match. A refresh icon next to the label resets the value back to the channel's own datasheet default, discarding any manual edit.

The Reference standard uncertainty box, by contrast, is always expressed directly in the calibration's own reference unit — a reference standard's certificate value is entered on the same scale the calibration itself is recorded in, so no conversion is needed there.

Switching Sensor nominal accuracy on does more than add its contribution to the budget: it also locks the Conformity assessment panel's Tolerance box (see Filling in the conformity boxes) to mirror the same value, converted into the reference unit, since in that configuration the sensor's own accuracy spec is the pass/fail threshold. Switching it back off leaves Tolerance at whatever it last mirrored, now freely editable again.

The Sensor nominal accuracy conversion is for magnitudes (accuracy/uncertainty deltas), not readings — a 1 °C uncertainty converts to 1.8 °F, not 33.8 °F. Converting a delta never applies the offset an absolute-reading conversion would (20 °C ≠ 1.8 × 20 °F; but an uncertainty of 20 °C really is an uncertainty of 36 °F).

Not every unit pairing converts cleanly. A handful of quantities in Open Gauge's unit list mix genuinely different physical concepts under one label — e.g. humidity's %RH (a vapor-pressure ratio) and dew point °C (a temperature) aren't related by a constant factor, and radiation's Gy (absorbed dose) and Sv (equivalent dose) differ by a radiation-type-dependent weighting factor. If the channel's own unit and the calibration's reference unit fall into different groups like these, Open Gauge can't convert between them and excludes the contribution from the budget rather than risk a silently wrong number.

Worked example. A flow sensor's channel is configured in m³/h. Its datasheet states an accuracy of ±0.5% of full scale over a 0–200 m³/h range, i.e. ±1 m³/h — Sensor nominal accuracy shows 1 next to m³/h once switched on. If this calibration's own data happens to be entered in gal/min instead (Step 2's reference unit), Open Gauge converts that 1 m³/h into ≈4.40 gal/min automatically before combining it into the budget.

Reporting rounding

Per GUM §7.2.6, combined and expanded uncertainty are rounded to at most 2 significant figures for display and on the certificate — everywhere else (R², RMSE, max error, hysteresis, ...) uses a plain fixed-decimal display. See Rounding for exactly how this plays out in practice.