Scanning Transfer Cavity Laser Lock

Junior & Senior Year · 2024–2025 Red Pitaya Python Feedback Control Optics SCPI / Sockets Piezo Tuning

Motivation

High-precision atomic physics experiments, such as optical atomic clocks using ytterbium ions, require lasers whose frequencies are extremely stable over time. Even tiny thermal or mechanical drifts can shift a laser's frequency enough to disrupt an experiment. The lab I worked with needed a way to continuously monitor and correct the relative frequency difference between two lasers, keeping it locked to a user-defined target value.

The goal of this project was to design and implement a Scanning Transfer Cavity Lock (STCL) which is a feedback system that uses a Fabry-Pérot interferometer to track the frequency difference of two lasers simultaneously and apply real-time corrections via a piezoelectric actuator on one laser.

Project Outline

The core idea is to sweep a Fabry-Pérot cavity through a range of lengths using a piezo driver, causing each laser to constructively transmit at a slightly different moment in the sweep. By precisely measuring the time difference (or sample differnce) between these two transmission peaks, the relative frequency difference of the lasers can be found, then used to create an appropriate voltage correction.

Hardware signal chain:

Function Generator
(238 Hz triangle wave)
Piezo Driver
(cavity length sweep)
Fabry-Pérot Cavity
(two lasers in)
Photodiode
Red Pitaya ADC
Red Pitaya DAC
(correction voltage)
Laser Piezo
(frequency tuning)

The function generator also sends a trigger to the Red Pitaya so that the data acquisition is synchronized with the upward slope of each triangle wave cycle. The 238 Hz rate was chosen to align with the Red Pitaya's minimum acquisition duration, allowing the sample window to exactly match the sweep.

The repeated locking loop ran in four steps:

  1. Signal Acquisition — The Red Pitaya records the photodiode signal over one upward sweep of the triangle wave, capturing both laser transmission peaks in a single buffer read.
  2. Peak Detection — Python code running on-board identifies the timestamp of each voltage peak and determines which peak belongs to which laser.
  3. Error Evaluation — The time separation between the two peaks is computed and subtracted from the user-defined target separation. This time difference is integrated to form the error signal, making the feedback robust to slow drifts.
  4. Feedback — A correction voltage proportional to the accumulated error is output from the Red Pitaya's DAC and sent to the piezo on the tunable laser, nudging its frequency back toward the target difference.

The software was split between the Red Pitaya (on-board Python server, hosted via Python's 'socket' package and controlled through SCPI) and a PC-side Python client for user interaction. Running the locking loop on-board was ideal in order to avoid the bottleneck of transferring large raw data buffers over the network during each cycle.

In order to test this on my own I built a benchtop simulation by injecting two voltage spikes into the Red Pitaya's input and verifying that the correction voltage responded correctly. This is was a useful way to validate the logic independently of the optical setup.

Outcome & Reflection

Performance bottleneck: The locking loop ran at approximately 1.5 Hz — far below the ~238 Hz cavity sweep rate and too slow for the lab's requirements.

To diagnose the issue I used timers in the code to find where the delta was coming from was going. The bottleneck turned out to be the buffer read step: transferring the acquisition data from the Red Pitaya's FPGA into Python was consuming the majority of each cycle's time. This pointed to the need to simpliment a different method of coding, either implementing the peak detection directly in FPGA firmware, or using a lower-level interface that could access the data without the Python overhead.

What I would do differently: Move the peak detection logic into an FPGA block design (e.g., using Vivado) so the comparison and error signal generation happen in hardware, with only the correction value passed to Python. This would eliminate the buffer transfer entirely.

Ultimately, pivoting to a full FPGA implementation exceeded the scope and timeline of the project. In the meantime, the lab adopted an updated stabilization method by optimising their current software, so the project concluded without being integrated into production use.

Despite this I felt that this project was a great learning experience. I gained hands-on exposure to: designing a real-time feedback control loop, working with the Red Pitaya's Python/SCPI ecosystem and synchronizing hardware signals across multiple instruments. I found it very valuable to work on a project that combined optics, FPGAs, and software.