About Quatm

Quatm is a control framework for quantum-physics experiments. A compact experiment description is carried through instruments, timing, acquisition and analysis. Whether the laboratory already runs on an FPGA card, a real-time controller or a custom board, the experiment keeps the same shape.

What it does, and where it stops

Quatm is a software framework. It does not require a particular vendor or controller: instruments can be integrated through their existing interfaces or vendor libraries, by selecting or writing a driver. The framework supplies the control architecture, driver interface, desktop and browser clients, data pipeline and automation infrastructure. The integration effort depends on the instrument protocol and vendor SDK.

The open core is deliberately software-only. It does not attempt to be an instrument catalogue or a turnkey apparatus; that restraint keeps the runtime clear and dependable. When a laboratory wants more, Quatm Platform and Quatm Systems carry the same care into the rest of the laboratory.

From core to complete

Quatm Core

The open-source runtime for teams who want to build directly on the experiment model. It provides the experiment lifecycle, physics models, services and shared utilities, and runs without a desktop environment.

Quatm Platform

The complete software environment: desktop interface, browser console, driver catalogue, licensing and support for a working laboratory.

Quatm Systems

Our engineering team can design and deliver real-time controllers, lasers, high-field magnets, RF sources, integrated ion-trap and ultracold-atom systems, and complete experimental systems.

A laboratory can begin with a single instrument or a simulation. The same experiment description can later grow into an integrated system, without a second beginning.

Where experiments find their order

Quatm is at home in laboratories where several instruments, a precise sequence and a growing body of data have to remain intelligible together.

  • Cold atoms and ion traps — loading, cooling, imaging, state detection and long experimental campaigns.
  • Quantum optics — lasers, modulators, cameras and feedback loops described through one device model.
  • Quantum chemistry — measurement workflows that need the same care in timing, provenance and analysis.
  • A single workstation or a distributed laboratory — services can share a machine or a network without changing the experiment description.
  • Simulation, commissioning and production — the same experiment can begin without hardware and continue on the real apparatus.

The common thread is not a particular apparatus. It is the desire to keep the experiment legible as it grows.

A quieter laboratory

  • The apparatus is described once. A new instrument becomes a configuration and a driver, not another private script.
  • The experiment reads like an experiment. Parameters, scans and timing live in a small, reviewable description.
  • The record keeps its context. Parameters, task descriptions and acquisition metadata travel with the data.
  • Automation remains supervised. Runs can be queued, paused, resumed or stopped; long campaigns do not become a black box.
  • Remote access is not a second implementation. The desktop and browser clients share the same queue, properties and live data.

These are quiet improvements individually. Together they change what a laboratory can maintain.

From where the experiment stands

A laboratory does not arrive empty-handed. Years of LabVIEW or MATLAB code, NI cards, real-time controllers and home-grown scripts are not obstacles to remove; they are knowledge to carry forward.

Quatm can meet that work where it stands. Begin with one instrument, one experiment, or one part of the sequence. Keep the calibration, the hardware and the habits that already serve you; let the framework take over the parts that have become fragile. Migration does not have to be a leap of faith — it can be a walk, experiment by experiment.

What we believe

  • Clarity is a form of care. An operator should be able to see what the experiment is doing, why it is doing it and how to stop it.
  • The experiment belongs to the laboratory. The apparatus, the calibration and the physics remain the laboratory’s work; Quatm provides the structure around them.
  • Automation should inform, not obscure. A long run is useful only if its state, history and failures remain legible.
  • Software should age gracefully. Interfaces, data and experiments are meant to outlive the machine that first ran them.

From instrument to experiment

  1. Describe the instruments — register them in the laboratory project.
  2. Write the experiment — declare parameters and the sequence in a small experiment definition.
  3. Open the interface — choose the experiment, adjust parameters and submit a run.
  4. Run and observe — follow live curves, camera images and task state.
  5. Analyse — data is archived automatically and can move into fitting and image analysis.
  6. Continue from elsewhere — monitor progress, adjust parameters or stop the queue from the browser console.

No compilation step is required. A change takes effect at the next run.

A conversation, at your pace

Quatm is developed in the open. The public core is at quatm-team/quatm-core; its issue tracker is the place for reproducible bugs and considered feature proposals.

TopicContact
Documentation and usageDocumentation
General enquiries and collaborationcontact@quatm.com
Commercial licensing and deploymentsales@quatm.com
Security reportssecurity@quatm.com — please report privately

More: Licensing and commercial use · Roadmap · Security policy · Release notes

If you are unsure where your experiment fits, write to us. A short description of the apparatus and the problem is enough to begin the conversation.