I wanted to make a post about since this was quite an interesting experience. To give a bit of background on the motivation for this post, in our clean room we have a probe station which is used for resistance measurements. Currently, our setup is run with with two probes which you then hook up to a sourcemeter and run current through, and from the IV curve you can extract a resistance measurement. The reason this is important is because the room temperature resistance of your JJ can tell you about its resonant frequency, which is important so you know which frequency signals to send in to drive your qubit. The sourcemeter is connected via USB to a computer from which you can control the IV sweep, and typically this used to be your personal computer that you had to bring into the clean room.

This is non-ideal for several reasons: firstly, this means that the data collection code is not centralized (every personal device must have its own version of the code), and also the collected data isn’t being stored in some central location that everybody can access. This is particularly an issue in groups, since it makes it hard for one person to access a collaborator’s data should they need to. More importantly though, bringing your laptop into a clean room is just inherently a bad idea – your laptop traps dust naturally through the built-in keyboard and fan vents that it’s better to keep it out of the clean room if possible.

So, recently we finally decided to get a dedicated PC for the probe station, which came pre-installed with NixOS, a relatively niche Linux distribution. This blog is a documentation of what that journey looked like.

Why NixOS?

I guess before I start talking about the configuration I should go over why we chose this particular operating system, and that’s basically down to two things: it’s lightweight, and it’s declarative. Because this PC (which I will refer henceforth as “the box”) only needs to run Jupyter notebooks, save data, and upload that data to a shared drive, you don’t need all the “bloat” that comes with established operating systems like Ubuntu or Arch, let alone Windows or MacOS. NixOS is perfect for this, since one of its core philosophies is that it’s lightweight so you can add exactly what you need and nothing more.

That leads me to the second benefit of NixOS, its declarative nature. Installing and configuring the system is extremely easy, done entirely through /etc/nixos/configuration.nix. All the configuration you do goes into this one file, from the wifi settings to the packages you want to install to custom scripts you want to run. This is much easier compared to other Linux distributions, where it really feels like navigating through a maze to figure out how to control each component of the OS.

There are several other benefits that I’ll lightly touch upon. First, the fact that all the config lives in a single file means that it’s reproducible, in that two NixOS systems running the same configuration.nix will end up with the exact same operating system. So, if the computer were to break for some reason, as long as you have the configuration.nix saved somewhere you can just reinstall it on a new PC and you’re back to where you left off. Second, NixOS also gives you multiple fail-safe ways to modify configuration.nix so you can test any changes you want to make. You can use the nix-shell to make temporary modifications without committing them to configuration.nix, and even if you do make the change permanent NixOS saves previous builds of the OS you can revert to earlier versions in case you do break something upon reboot. It’s also a very energy efficient OS, which is a nice plus for a system that will be persistently turned on.

So that’s essentially the motivations behind why we chose NixOS for this box. The trade off though? Configuring this means I had to learn how to interface with it and configure it to do what I want, which was definitely easier said than done.

Connecting to the Sourcemeter

The first order of business was trying to figure out how to connect the box to the sourcemeter. As with all Linux issues, what is a simple install on Windows/MacOS turned into a two-day ordeal to try and figure out. First off, I spent the better part of three hours trying to get NI-VISA, the proprietary backend that allows your system to communicate with instruments like the sourcemter, to install on the NixOS box, only to realize that you can’t install it on a this specific Linux distribution.

I then found that there’s an way to connect using pyvisa and pyvisa-py, which does everything that NI-VISA does but is open source.¹ Installing it on NixOS took a little bit of figuring out; I ultimately went with an approach that just installs it in the Jupyter session that houses the Python code which takes the measurements.

There’s also one extra layer in all of this is that because the Jupyter session runs inside a docker container, trying to get the sourcemeter to connect to the box was also quite tricky. I learned that docker doesn’t allow USB connections by default, so you have to manually identify the kind of USB device you’re trying to connect, then configure the docker container to allow that specific USB connection. This seems simple enough, but without knowing that docker does this to begin with, finding this subtlety took me nearly three hours of debuggin to find.

Connecting to the Probe Station

Once I got the communication with the sourcemeter established, the next thing to figure out was how to connect the box to an already existing PC on the probe station. Without going into too much detail, we essentially have a separate PC that controls the stage of the probe station that already has screens set up, so the most logical thing to do is to set up the linux box in a headless mode, and run every process through the probe station PC.

This meant I had to figure out how to connect the two machines together and get them talking via an ethernet cable. This was easy enough, I just had to find the private IP that both devices set for each other, and assign a public IP so that they can talk to each other. Ironically enough, this was harder to do on the windows PC than the Linux box, which was done in a single command. In roughly 30 minutes though, the whole thing was set up.

Using Rclone

Finally, the last thing I had to set up was linking the box to google drive using rclone, another very cool piece of software I got to learn from this experience. rclone is an open-source cloud storage management software, and allows you to upload files from your local system to the cloud, including Google Drive. Setting this up was also quite easy, all it required me to do was to set up a google API that allows me to upload to our specific shared drive and the files would start syncing on command.

The last thing to do here was to modify the system configuration to automatically run this script every 15 minutes, which is done through configuration.nix (who would’ve guessed): you basically just set a service using systemctl to run the rclone copy command, and attach a timer that calls it at pre-defined intervals. After that, it’s as easy as running sudo nixos-build switch to activate the script.

Final Remarks

This was a pretty fun experience, and my first time really doing any sort of configuration on a Linux system. I have some familiarity with UNIX systems since I use MacOS, a lot of basic commands are the same, but learning the Linux-specific CLI commands like systemctl was really fun, not to mention that feeling when I finally understood the logic behind how to configure using configuration.nix. Overall, if I ever get a new laptop and decide to run Linux on it, I’ll seriously consider NixOS as a candidate daily driver.

1. Side note, it’s awesome that something like this is open source so you don’t have to put up with proprietary BS. ↩