Measurement data models¶
This reference organizes mpylab’s persisted data containers. It describes the supported read interface of a measurement history, not every internal attribute that Python happens to store when pickling a measurement class.
Basic structure¶
Measurement classes store several named datasets in one shared history object. The usual access path is:
history.<data_container>[description]
description is a freely chosen name that is unique within its container.
Below it, workflows typically use numeric frequency keys in hertz and further
keys for ports, tuner positions, points, detectors, or generator levels. The
respective domain reference documents the exact order.
A description can collect several measurement acquisitions, including runs
made after the setup changed. The compact acquisition reference on each
bundled raw sample associates it with a timestamped configuration snapshot;
Measurement history and output files defines this shared provenance structure.
Raw-data containers normally start with rawData. They hold instrument
values, workflow metadata, and the provenance needed for repeated evaluation.
processedData contains quantities derived from those raw values. An
evaluation does not replace or delete the raw data.
Persisted containers¶
Measurement class |
Containers |
Content |
Detailed reference |
|---|---|---|---|
|
|
TEM-mode verification and power references |
|
|
|
measured GTEM field factor |
|
|
|
exposure, reference selection, and EUT assessment |
|
|
|
emission scan, detectors, and field correlation |
|
|
|
amplifier power, gain, and compression |
|
|
|
empty-chamber and loading calibration |
|
|
|
EUT-specific chamber calibration |
|
|
|
tuner autocorrelation and independent positions |
|
|
|
exposure, thresholds, and EUT assessment |
|
|
|
received power and derived emission |
TEMCell additionally stores geometry, uniform_areas,
verification_datasets, and reference_datasets. These attributes bind
geometry and provenance to the measurement history and are relevant when
interpreting verification and reference data.
Supported contract and internal state¶
The paths, types, units, and meanings described on these pages are supported.
Later mpylab versions may add keys. Fields marked as optional can be absent
from older pickles or another measurement mode; applications should read them
with mapping.get(...).
Runtime objects such as open files, loggers, UI adapters, and instrument
instances are not a data-reading interface. An attribute currently visible in
__dict__ is not a stable contract unless this reference includes it.
Established keys are not silently renamed or assigned a new technical
meaning. An unavoidable incompatible change requires a migration strategy and
an explicit versioning decision. This documentation does not introduce a
global schema version for the pickle history; individual interchange formats
or nested documents can have their own schema_version fields.
Changing the data model¶
A change to a persisted attribute, key, index, type, unit, or meaning must update the German and English documentation in the same commit. Its virtual runtime contract test must be updated as well. New containers must appear in the table above.
See Maintaining the documentation for maintenance rules and check commands. Measurement history and output files documents pickle, autosave, and resume; Inspecting pickles with PExplorer explains interactive inspection of a trusted history.
Path-correction quantities keep their existing units and dictionary keys.
Newly computed corrections retain SCUQ expressions, including shared-input
and real/complex transfer dependencies, rather than independent evaluated
inputs. Their pickle representation may include the internal transfer
expression classes in mpylab.tools.ratio_conversion; readers need a
version providing those classes. Existing saved numerical results are not
rewritten. See Conditions, switching matrix, and path corrections for the corrected coherent
power semantics and the limits of first-order uncertainty at cancellation.