The complete eprcontrol toolbox is developed object-oriented and organised as a package with subpackages. Furthermore, for each subpackage, at least one rather general class is provided serving as starting point for the concrete implementation of the actual classes.

In a simple picture, the user wants to perform a measurement, i.e. run an experiment that uses a particular setup, recording and displaying data during the experiment, and eventually saving these data in some way or other. All the boldface words in the previous sentence correspond to a subpackage with a general class used as starting point for own concrete developments. Furthermore, a setup consists of components that each have connections to the respective hardware. Several components can share one and the same connection.

Eventually, all the different objects will be configurable using configuration files. This should allow users to create different experiments by only changing configuration files, with no need to program in more detail. Furthermore, all parameters that change between different experiments should never be stored in classes and best be saved as human-readable configuration files.


Measurements are currently the main user interface to the eprcontrol toolbox. A measurement is defined in a YAML file setting the experiment and display according to the user’s needs. Furthermore, parameters and settings for the experiment (and the display) can be put in there.

From the user’s perspective, the parameters of the measurement are defined in a YAML file somewhere convenient in a directory of the user. Thus, measurement parameters that need to change according to the specific needs are fully separated from the eprcontrol software and can be stored together with the data, providing a minimal documentation of the setup used and experiment performed.


Experiments are at the heart of the eprcontrol toolbox. They are in a certain sense the main interface between the user and the spectrometer. For sure, the experiment requires a setup consisting of components that have each a connection interfacing to the hardware and underlying software. Furthermore, an experiment will usually have one or several saver to persist the recorded data and one or more displays.


Setups consist of components that each represent part of the overall hardware used to perform the experiment. Here, while some of these components might be integrated in one device or be controlled via the same software (that is in turn talked to from the eprcontrol toolbox side), they each have a set of methods typical for this kind of component.


Components are the individual building blocks a setup consists of. Usually, although often those components are rarely or never changed, in principle, they are modular and can be replaced. Typical components from a (time-resolved) EPR spectrometer perspective are: the microwave bridge, the field controller, and the digitizer.

Each of the components has a connection that is used to talk to the hardware (or underlying software). As mentioned, several components can share one and the same connection.


Connections are the interface between the eprcontrol toolbox and the hardware (and underlying software) of the compoennts of the setup. While pretty peripheral, usually, these connections require additional (commercial) toolboxes such as the Instrument Control Toolbox™, or, e.g. in case of an XML RPC connection, Java libraries that can be accessed from within MATLAB®.

Connections can be shared between components. Furthermore, components provide methods for connecting and disconnecting that activate/deactivate the underlying connection.


Data obtained during an experiment shall be displayed in one way or other. Be it during the running experiment or afterwards. However, an experiment should be completely independent of any display. Therefore, displays are implemented using the event–listener model, with the experiment issuing an event each time its data get updated, and the display acting as listener to this event.


Recorded data need to be stored to be accessible afterwards for display, processing, and analysis. However, the file formats as well as the general ways to store the data are different for different experiments and often due to external constraints. Hence, saver provide a modular way of peristing the data obtained during an experiment.

Even more, an experiment can contain a list of different saver objects each saving the data in a different way.


Many things need configuration, and changing values in a configuration file can at the same time be much easier than having to hard-wire something in code. Eventually, each part of the eprcontrol package should be fully configurable, allowing the end user to only change parameters in configuration files to change not only experimental parameters, but the composition of setups as well.