CryoSoft
The lab's cryostat measurement software used to be a flat sequence of hardcoded commands: swapping one instrument for another meant hours of rewriting code, and an unattended 20-to-30-hour overnight run had no automated safety net if something went wrong. I redesigned it as a layered system where swapping an instrument is a single config-file edit, added a safety-enforcing state machine that shuts the experiment down safely on its own, and got new lab members measuring independently in a day instead of a week.
CryoSoft is the primary measurement stack across my own cryogenic transport work since 2024, and the software that runs the fabrication and characterisation chain behind the exchange-bias and magnetoresistance research projects.
The problem
The old LabVIEW code was difficult to debug. Instrument parameters were distributed throughout the measurement sequence, and replacing an instrument often required changes in several places. The system did not save the full metadata needed for root-cause analysis of measurement artefacts. The cryogenic transport setup routinely runs measurements unattended for 20 to 30 hours at a stretch, where constant manual monitoring of parameters by an operator was tiring and unreliable. The cryostat also had no software-level state tracking and no automated safety enforcement. Nothing in the software would have stopped an unsafe magnet or temperature transition during a long run.
The approach
CryoSoft is built on PyQt6 and pyqtgraph for the GUI, PyVISA and PyMeasure for instrument I/O, h5py and numpy for data handling, ruamel.yaml for configuration, and pytest, pytest-qt, and mypy for testing and typing.
Six-layer architecture. L0 raw drivers, L1 typed virtual-instrument wrappers, L2 a YAML-driven station registry, L3 an orchestrator, L4 measurement procedures, L5 the GUI. Each layer depends only on the one below it. Swapping a core instrument is a YAML edit. Every real driver (Oxford Mercury iPS, ITC 503, ILM 200, Lakeshore 335, Keithley 6221 and 2182A) is paired with a simulated driver for offline development and testing.
Cryostat state machine. States are IDLE, INITIATING, RAMPING, MEASURING, SWEEPING, STANDBY, PAUSED, ERROR, and EMERGENCY, ticked by a single Qt QTimer. Per-tick safety checks force the system into EMERGENCY on a helium-low reading or a stale sensor reading. Ramp targets are validated through a RampableVI interface, with a custom CryoSoftSafetyError exception on violation.
Auto-generated GUI. Panels are generated by introspecting virtual-instrument methods decorated as monitored or control, using Python's inspect and typing. A new instrument's controls appear without hand-built GUI code.
Structured data output. HDF5 output, one file per run (procedure name plus ISO timestamp), with a metadata group, a data group (preallocated resizable float64 arrays with per-point timestamps), and a snapshots group holding a full instrument JSON snapshot per sweep point. Arrays trim cleanly on abort.
The outcome
- Swapping a core instrument, for example the magnet power supply or the temperature controller, went from hours of refactoring to a single config-file change.
- Intern onboarding on the cryogenic measurement bench went from one week to one day.
- Long unattended measurement runs (20 to 30 hours) no longer require active operator monitoring; safety is handled by the software.
CryoSoft is public and intended to be reusable by other researchers. Recent development has added a configuration editor and session management. I am currently building the agent side: a harness for adding new drivers and troubleshooting issues, and MCP tools that expose measurement status, so that software agents can work with the system.
The vault's own CV notes for CryoSoft ("Python based software for cryostat - Cryosoft - MCV.md") are empty stub files. All content on this page is sourced from the parallel, more detailed Master CV evidence block and project logs instead; see the content dossier for the full source trail.