Home lab DAQ

When I built the data acquisition system for our home-built ARPES setup, the main motivation was not to make a prettier control panel for an analyzer. It was to fix a scientific problem that kept getting in the way of real measurements: time-dependent metadata.

In ARPES, time-dependent changes in experimental conditions such as temperature, sample position, photon flux, and pressure are often associated with direct changes in the spectrum. If that information is not preserved together with the scan, then the data file is missing part of the experiment, and this is critical for reproducibility, interpretation, and comparison.

The first problem: metadata preservation

That became especially obvious to me when working with the vendor software for our hemispherical analyzer, Scienta Omicron’s SES. The first task was to figure out how to attach metadata to the ARPES data. This was done through a custom SES extension that I built, which receives metadata from the DAQ layer through a socket-based header server and writes it into the data files at save time. That way, the evolving experimental state is preserved together with each saved spectrum.

However, the problem was the lack of a good native way to repeat scans along a time axis while retaining the metadata in the way I wanted. SES does provide functionality for time-dependent measurements such as “Add dimension”, but that did not solve the problem I actually cared about. In particular, the metadata I needed were not retained across the time axis, or any motor scan axis in the way I wanted. You can collect the spectra, but the experimental context gets flattened away or detached from the data.

The second problem: lack of real-time data analysis

There was another frustration pushing this project forward. SES did not give me a good native way to open and browse in-progress scans. And for deflector scans, the built-in interface felt too rudimentary for properly browsing volumetric data. I did not want to launch a scan, wait passively, and only inspect the result after everything had finished writing to disk; that workflow makes the experiment much more inefficient.

What I wanted instead was this:

• start a scan,
• watch the data build up in real time,
• slice through it while the acquisition is still running,
• decide whether the scan parameters are good,
• and adjust the next step based on what I am already seeing.

What the project became

The repository is a huge monorepo that contains a lot of different software components. The core program, src/erpes_daq, is an acquisition layer built around the needs of the experiment rather than the boundaries of the vendor software.

It launches scans through SES, but it also coordinates with the rest of the instrument stack, gathers experimental state from external services, and visualizes the evolving dataset while the experiment is still alive. It also communicates with other software components to allow performing non-trivial motor scans and polarization control as part of the same workflow.

With this program, I can run scans along multiple axes while browsing the data in real time inside an application that actually supports slicing and full-fledged data analysis including curve fitting and symmetrization, rather than just showing a false color image of the latest spectrum. The measurement becomes something I can inspect and steer as it unfolds.

One reason the repository is a monorepo is that the DAQ frontend is only one piece of a broader ecosystem of tools that support the experiment. The software is designed around the fact that the analyzer is just one component of a complex system. ARPES data need to include not just the spectrum, but also the context, which comes from temperature controllers, pressure gauges, position encoders, motorized optics, beam flux monitors, and more. The repository includes python GUIs and services for each one of those components, and the DAQ layer pulls them into the metadata that is preserved with the ARPES data.

Challenges

What I find satisfying about projects like this is that the real work is rarely the flashy part. The challenge was about making the whole thing dependable enough to trust during an actual experiment that somebody’s career depends on. That meant dealing with all the awkward problems that show up when software has to work seamlessly with a commercial Windows application:

• the correct metadata had to be available at the right moment, not just eventually
• files had to be handled while they were still being written
• viewer tools had to remain stable even during long-running scans
• the whole system had to respond gracefully when one of the supporting services was misbehaving

Looking back through the project history, what stands out to me is not a single dramatic rewrite, but the accumulation of many small battles: improving timing, making scan completion detection more robust, preventing edge cases from breaking a run, integrating metadata more cleanly, and adapting to new hardware.

Takeaways

I think this project says something important about how I work as an experimental physicist. I care a lot about the boundary between measurement and instrumentation. Good experiments do not only depend on having good physical intuition; they also depend on whether the software and instrumentation preserve the context that makes the data meaningful. What I enjoy most is building tools that reduce that gap. In this case, that meant turning a commercial program into part of a more thoughtful acquisition workflow.

More broadly, I believe that small, targeted improvements can accumulate into a system that works remarkably well. The most meaningful progress often comes not from one sweeping redesign, but from patiently identifying the points where an experiment loses clarity, reliability, or usability, and improving them one by one. To me, that is not just software engineering in support of physics. It is part of doing the physics well.