[BUG] - SG: Realtime frequency sweep with two oscillators not working

[GlaserN]

Describe the bug
For measuring the anharmonicity of the qubit we need the perform to pulses with different frequencies via the SHFSG.
For finding the resonance we want to sweep only the e-f transition but not the g-e transition.
Using realtime sweeps for the logical_signal_line with the g-e transition breaks however the behaviour of the outcome measured on the oscilloscope:
The first defined oscillator (for us the g-e) frequency is swept with the range defined for the LinearSweep of the e-f frequency, however around the g-e frequency. The pulse for the e-f frequency is played with the oscillator frequency 0, e.g., at the lo_frequency.

To Reproduce
Compare the output on channel 5 for the both experiments in neartime or realtime on the oscilloscope.
The neartime experiment produces the expected outcome, however being significantly slower.
realtime.zip
neartime.zip

Realtime:

Sweep between 50-150MHz on wrong pulse
Second pulse: at lo frequency: 600MHz.

Neartime:

Correct behaviour

Expected behavior
The realtime sweep should only sweep the oscillator connected to the associated logical signal line.

Versions used:

• laboneq: 2.2
• zhinst-core: 23.02

Context

• Do you know a workaround for the issue? If yes, please provide a short description.
• Does the issue block your experiments?

[polwel]

Hi Niklas!

This is a known limitation: when using the oscillator switching in combination with oscillator sweeping, the only oscillator that can be swept is the one with the alphabetically first UID.

For example, if you have two oscillators, named osc1 and osc2, only osc1 can be swept in the real time loop.

Can you, as a workaround, rename one of the oscillators to force the sorting?

We'll be working on a proper fix in the future.

[QuantumClemens]

@GlaserN can you confirm if the workaround proposed by @polwel is working for you?

[QuantumClemens]

@GlaserN could you please confirm of the workaround is working for you or if you need additional information?

[GlaserN]

We can make use of the this workaround. For the general application it would however be useful to have the flexibility to arbitrarily name the oscillators, especially as they are, in our setup, initialized in the order of usage.

[polw-zi]

Hi @GlaserN, you can expect a better solution for this issue coming in version 2.12 next week.

[kshirer]

Hi @GlaserN , with the release of 2.12, I'm closing this issue.