Open-source tools from Oxford Instruments NanoScience to aid low-temperature system control and measurement integration

By Tony Matthews

What are the new tools that Oxford Instruments is developing?

Oxford Instruments has a long history of producing ultra-low temperature and high magnetic field systems for physics research. In recent years we have been deploying a new control system to these platforms, entitled oi.DECS.

As well as taking care of the operation of the system (e.g. running the routines necessary to cool a refrigerator from room temperature into the millikelvin region), oi.DECS was designed to facilitate multi-user environments and remote connections allowing systems to be monitored, operated, and managed more easily.

To accomplish this, oi.DECS incorporates concepts such as authentication, authorisation and session management. Briefly: authentication deals with who is allowed to connect to a given system, authorisation determines what they can do once connected, and session management prevents multiple remote users from stepping on each other’s toes.

You have adopted open standards for this system - why?

Open-source matters because science is based on collaboration. There is a continual push for ‘open’ science with publicly-available data via platforms like Zenodo, for example. Open-source promotes transparency, encourages skill development and lowers barriers to adoption.

Businesses have also identified value in open-source projects. For example, Meta observed how the wide adoption of open-source software solutions often leads to them becoming an industry standard, and Microsoft’s VSCode editor is moving towards becoming the standard choice for developers. In short, adopting open standards allows more people to contribute to a project, and to devote a greater proportion of their time to innovation.

This was the driver behind the Microsoft QCoDeS initiative. The goal of QCoDeS is to build a common framework for physics experiments so that time is saved on learning software needed to participate in experiments, code can be contributed back to the framework, and experiments can take advantage of modern software and best practices.

The Microsoft QCoDeS project already contains many instrument drivers developed by the research community. A large number of these contributed drivers are for instruments our customers are already using to perform measurements with our cryogenic and magnet platforms.

That all sounds good, so what exactly do these tools add?

Usually, our systems are integrated into a wider measurement or data acquisition system. For example, in an electrical transport measurement, the aim might be to determine the resistivity of a sample as a function of both temperature and applied magnetic field. In addition to a low-temperature and high magnetic-field environment, the experimenter would want to include equipment such as a current source, voltage pre-amplifier, and perhaps a couple of lock-in amplifiers – all of which may come from different vendors.

Given that modern cryogen-free dilution refrigerator systems such as Oxford Instruments’ Proteox product line can operate over a temperature range spanning four orders of magnitude, from <4 mK to >40 K, whilst applying a magnetic field from -14 T to +14 T, there is a significant parameter space to explore. This expands further if the aim is to record voltages as function of, for example, the current and frequency for each measurement. Such measurements are only practical if they are automated, hence the need for an Application Programming Interface (API).

The kinds of test and measurement equipment described above often have a high degree of interoperability through standards such as the Virtual Instrument Software Architecture (VISA) and the Standard Commands for Programmable Instruments (SCPI), but these standards don’t have provision for the additional features of oi.DECS.

To simplify the integration of systems running oi.DECS with instrumentation built around VISA, we have produced ‘DECS<->VISA’. This is a simple ‘wrapper’ that can provide access to the oi.DECS API in a way that is directly compatible with existing code and frameworks written for VISA instruments.

So it is about getting experiments running quickly?

Exactly. We know measurements are about the integration of multiple pieces of equipment, so it is an effort to make that process as smooth as possible.

Anybody can now access the project ‘DECS<->VISA’ on github.

Is QCoDeS integration also something Oxford Instruments NanoScience is working on?

Absolutely. With the DECS<->VISA wrapper complete, adding a QCoDeS driver for oi.DECS based systems is relatively straightforward.

We expect to have a pull request shortly at the QCoDeS contributed drivers repository.

Dr Stefanos Dimitriadis, a Research Associate in Quantum Devices at Imperial College London, our first beta-tester of this QCoDeS driver, said “I have been using Oxford Instruments’ QCoDeS driver to remotely control the temperature of our ProteoxMX dilution refrigerators, allowing for the automation of series of measurements and seamless integration with other instruments. The driver proved especially useful while investigating the temperature-dependence of the critical current of novel Josephson junctions, whereby the dominant mode of transport in the device was inferred through a temperature series of millikelvin steps, with each measurement at a set temperature taking approximately 6 hours."

Interesting, what else can you build with QCoDeS?

As the oi.DECS platform is intended to be remote and multi-user, we’d like to provide the same approach to data acquisition too. At the APS March Meeting last year we had a demonstration system that consisted of a JupyterLab /JupyterHub server that allows users to remotely access a coding environment. From there QCoDeS was used to control an example oi.DECS-based environment as well as measurement equipment to run experiments. The structured database storage provided by QCoDeS also allows for measurement ‘dashboards’ to be accessed via the web.

Having control of one’s measurements, and access to the resulting data, all within a programming environment that can be used for any subsequent data processing means not needing to worry about where individual data files are saved nor swapping between systems used for running measurements and those used to analyse the data produced.

The feedback on this set-up was very positive, so we’ll be back at the March Meeting this year with another demonstration including more instrumentation from Lake Shore – stop by the stand to check it out.

You mentioned Lake Shore – how are you working with them?

We have an ongoing collaboration with Lake Shore that aims to integrate Lake Shore measurement equipment with our environments: by working together we can ensure an optimal solution both in terms of sample thermalisation and wiring. This means having the complete signal chain taken care of out-of-the-box.

Does that mean there are QCoDeS drivers for Lake Shore products too?

Almost! Lake Shore has a set of open-source Python drivers for most of their instruments which means the “heavy lifting” of constructing QCoDeS drivers has been done already. As part of these developments, we have made some QCoDeS drivers that provide basic functionality. Once we have extended these a little further, we will submit them as contributed drivers too.

What are the next steps?

We are rolling out oi.DECS across our product range. The next step will then be to incorporate our TeslatronPT system. This is a cryogen-free variable temperature insert (VTI) integrated with a superconducting magnet for fields of up to 14 T. With a VTI, the sample temperature is continuously controllable between ~ 1.4 K and 300 K. Such systems are very useful for materials characterisation measurements and these measurements are often electrical transport.

Having a QCoDeS driver for oi.DECS means an API for TeslatronPT will be available immediately. QCoDeS drivers for the Lake Shore M81 and M91 instruments combined with the JupyterHub server can provide a complete measurement solution. Through our close collaboration with Lake Shore, we can ensure optimal performance.

Are you planning to offer integrated measurement capability for your systems?

Yes. Our end users are interested in measurements, so offering a more complete solution, beyond the sample environment, should be advantageous. The flexibility of QCoDeS and their contributed drivers means that the functionality of such a system could be easily extended by end users to construct more complex measurement arrangements.

Does that mean users will need to be ‘programmers’?

Not at all. On the one hand, we know many of our end users are already using QCoDeS for their measurement automation, and Python is essentially the lingua franca of data analysis, so we would anticipate many, if not most, of our users to be very comfortable getting ‘under the hood’ to adjust things to their liking. On the other hand, we also want to ensure the barrier to entry is low.

Using JupyterHub means we can deploy pre-prepared measurement ‘templates’ and the ipywidget system allows for ‘GUI’-like input fields:

This would be familiar to users of ‘black box’ systems. Our aim is for a much more open and adaptable ‘grey box’ solution whereby users can operate the system and get the standard functionality without needing to know too much about the intricacies, but still have a system that is extensible in terms of the hardware integration and measurement routines for those who’d like to extend the functionality.

Do you anticipate users modifying these systems?

Absolutely. We know our systems remain in service for a very long time, and so the measurements being performed with them today might be very different to the original application when the system was first purchased. Often wiring is added or modified with different measurement equipment connected to the system and new measurement routines developed.

Having a system in which this extensibility is designed in and can leverage work from a wider community makes adaptability a lot easier.

Could you call this a measurement ecosystem then?

Well why not, the seeds are already being sown. If researchers are actively sharing instrument drivers, then sharing measurement routines, tips, and techniques is certainly something that Oxford Instruments wants to be part of.

Come and see Tony and Abi at Oxford Instruments' booth #717 at the APS March Meeting, Minneapolis, MN, March 3 – 8, 2024 and follow us on LinkedIn for our latest product news.