The clock can become part of the problem
Cold-atom experiments depend on precisely ordered changes to lasers, shutters, magnetic fields and moving optical components. Some actions last seconds, while others must occur within microseconds. General-purpose computers are not designed to guarantee that kind of timing, so laboratories commonly send instructions to specialized real-time controllers. The hardware can be exact while the program describing the experiment becomes difficult to maintain.
Wigner Time, an open-source Python package presented in a preprint submitted September 5, tries to separate those concerns. Researchers at the HUN-REN Wigner Research Centre for Physics and collaborating institutions represent an experimental procedure as a table of timed changes. Scientists can compose that table in Python and convert it into the numerical arrays required by the controller only at the final stage. The authors report that the system has run two cold-atom setups for more than two years. This is operating laboratory software, not merely a proposed architecture, although its performance claims remain first-party results from a preprint without independent replication.
Why absolute schedules become fragile
A conventional real-time program may express every event against one global cycle counter. The end of a cooling stage becomes the sum of all durations before it. A shutter command may then be scheduled slightly earlier to compensate for the shutter's mechanical delay. Changing one early stage can shift every later absolute time, while conversions among seconds, milliseconds, microseconds and controller cycles may be scattered across multiple files.
The paper illustrates the problem with an optical-pumping stage from the implementation Wigner Time replaced. Hardware channel definitions, shutter delays, stage boundaries, events and coil-ramp logic occupied separate parts of the program. The arrangement could operate the experiment, but understanding one physical stage required reconstructing relationships across the code. It also used shared state for ramps, preventing a second coil ramp from running concurrently without additional work.
Wigner Time instead lets a stage describe events relative to its own beginning or to a named reference point. An anchor marks a physically meaningful instant, such as the end of cooling. Another operation can be positioned relative to that anchor without calculating its global time by hand. If an earlier stage becomes longer, later stages move with it while their internal offsets remain unchanged.
The experiment becomes a table
Each Wigner Time row records a variable, time, value and context. A variable might be an optical shutter or a magnetic-coil current. Context labels the experimental stage. Additional tables hold device calibration and physical wiring, keeping a scientific instruction such as setting a laser power separate from the voltage, module and channel that implement it.
That division is valuable because calibration, wiring and experimental intent change for different reasons. Recalibrating an analog device should not require rewriting the physics sequence. Moving a cable should not alter the function describing optical cooling. At the conversion boundary, Wigner Time combines the timeline with those hardware tables, converts physical values into controller voltages or digital codes and produces an array for the ADwin system used by the researchers.
The table is also an inspectable artifact. Researchers can plot it, filter it, compare it with an earlier run or save it beside the resulting measurements. That creates a clearer connection between a dataset and the commands that produced it. In laboratories where students and researchers inherit years of specialized software, preserving the actual timeline can be as important as making the initial program shorter.
Precomputation bought finer timing
The paper reports a concrete performance change. The previous ADbasic implementation calculated ramp trajectories, including relatively expensive mathematical functions, inside the real-time event loop while also checking dozens of conditions. It operated with a 5-microsecond cycle. Wigner Time expands ramps before they reach the controller, leaving the real-time program mainly to update an output when its requested value changes. The authors say the same experiments then ran with a 1-microsecond cycle.
Calling that a fivefold improvement in achievable temporal resolution is reasonable within the reported setup, but it should not be interpreted as making the underlying atoms respond five times faster or every experiment five times more accurate. The result concerns how finely the controller can schedule output changes. Its scientific value depends on whether a particular experiment needs the added timing resolution.
The improvement also has a cost. Expanding a smooth ramp into precomputed points consumes more memory than calculating values as the controller runs. The authors argue that this trade is favorable on their present hardware. That assessment may vary with sequence length, available memory, required resolution and the number of controlled channels.
Composition can support reproducible changes
Wigner Time builds stages as ordinary functions that return timelines. Operations can be stacked sequentially or interwoven around named events. A realistic example in the paper assembles initialization, magneto-optical trapping, detuned growth, optical molasses cooling, optical pumping, magnetic trapping and shutdown. The resulting table is saved, converted for ADwin and sent to the controller.
This functional structure makes parameter scans a natural extension of one experiment. The same composition can be regenerated with different inputs rather than copied and edited into multiple scripts. In principle, an optimizer could use measurements from one run to choose parameters for the next without requiring a different timing framework. The paper explains that possibility as an extension of the software design, not as evidence that Wigner Time has independently solved experimental optimization.
The authors also describe a maintenance failure from their previous system. Initial and final apparatus states had been written separately and quietly diverged, disagreeing about some shutters and omitting others. Wigner Time can apply one shared default-state function at both ends, with an explicit argument for any intended difference. That is an unglamorous improvement, but avoiding hidden disagreement in inherited control software can protect experiments from preventable errors.
Portability is a design goal, not a finished feature
The central representation is intended to remain independent of hardware until conversion, but the current implementation does not yet provide complete ready-made support for every controller. The paper says it uses pandas and presently assumes ADwin as its timing target. Raw output can be used with other systems, including National Instruments hardware, but those paths are not explicitly supported or optimized. Integrations for ARTIQ and National Instruments controllers remain a gap.
Another limitation involves peripherals controlled through serial protocols rather than a direct voltage. A frequency synthesizer, for example, may require a tuning word to be clocked across several digital lines before an update pulse. The authors describe how the conversion layer could expand a high-level instruction into those bit-level operations, but identify that capability as future work.
As of September 12, the official repository labels Wigner Time as beta and says it is not yet distributed through the Python Package Index. The maintainers report open known issues, including several cases in which incorrect behavior may occur without an explicit failure, found during a systematic code review. They also anticipate deliberately compatibility-breaking corrections, especially to the origin mechanism. Those first-party warnings do not show that every use is unreliable, but they make testing essential before adoption. A laboratory would need to inspect the known issues, pin the code version and validate generated timelines and controller outputs against its own hardware and safety procedures.
Wigner Time also does not attempt to replace a complete instrument-orchestration suite. It focuses on composing hardware-timed sequences. Laboratories still need measurement logic, device interfaces, user controls, data handling and safeguards suited to their apparatus. Open-source availability makes inspection and adaptation possible, but it does not guarantee compatibility or safe operation on unfamiliar equipment.
Software infrastructure can be experimental progress
The practical advance is not a new quantum device. It is a method for expressing the sequence that operates one. By turning a schedule into readable, versionable data, Wigner Time gives researchers a chance to see the relationship between physical intent and controller output before a run begins. Its reported deployment on two cold-atom setups shows that the design can survive real laboratory use under the authors' conditions.
The evidence remains bounded. There is no multi-laboratory benchmark, independent replication or systematic measurement of programming time, error rates or experimental reproducibility. The fivefold timing figure comes from replacing one hand-written implementation on the team's hardware. Wider value will depend on resolving known beta issues, adding back ends, strengthening documentation and testing, and adoption by laboratories with different instruments.
Still, the direction is constructive. Scientific progress depends not only on sensors and physical apparatus but also on whether researchers can understand, reproduce and safely modify the software between an experimental plan and the hardware. Wigner Time makes that often-hidden layer visible and testable.