Raw acquisition and demodulation

[alecandido]

There is no Qibolab option to specify whether demodulation should be performed or not during raw waveforms' acquisition, and in Qibolab 0.1 likely there was not even any agreement among drivers' implementation.

https://qibo.science/qibocal/stable/protocols/signal/time_of_flight.html#acquisition

If useful, the most effective solution is certainly to expose an option, and leave the choice up to the user. But, if not needed, the option may be just overhead, and thus choosing the preferred mode would be just simpler.

It's not clear to me there is actually only one useful option, and the toggle may be useful in the development of new Qibocal routines (time-of-flight is the only one using the raw acquisition I'm aware of to date).

[alecandido]

I already discussed with @stavros11, and in both QM and Qblox it should be possible to choose.

Any opinion about whether we should have an option, and in case we don't, which should be the choice? @andrea-pasquale @Edoardo-Pedicillo @hay-k

[alecandido]

Just to remember: this is the reason why I began wondering

qibolab/src/qibolab/_core/instruments/qblox/config.py

Line 103 in fe62413

seq.demod_en_acq(acquisition is not AcquisitionType.RAW)

[andrea-pasquale]

It's not clear to me there is actually only one useful option, and the toggle may be useful in the development of new Qibocal routines (time-of-flight is the only one using the raw acquisition I'm aware of to date).

Having more flexibility will certaintly benefit qibocal. Recently I was having a look at both the time-of-flight and the kernels protocols, and it seems that in qua-libs they are using more specific instructions which are currently not exposed by qibolab (for example it is possible to extract directly the timestamps) Another example is the computation of the integration weights, I believe that also in laboneq there is an implementation (which is what Juan initially followed for the implementation in qibocal).

Going back to the initial question, since raw acquisition is currently used by qibocal only, we can have a closer look at the experiments which are using it and potentially modify it to have something at a driver level which matches the experiment outcome for all drivers.

[alecandido]

Going back to the initial question, since raw acquisition is currently used by qibocal only, we can have a closer look at the experiments which are using it and potentially modify it to have something at a driver level which matches the experiment outcome for all drivers.

Yes, I expect actually to be only two the protocols using AcquisitionType.RAW
https://github.com/search?q=repo%3Aqiboteam%2Fqibocal+AcquisitionType.RAW&type=code
though the search is not perfect. But it's hard to have any other one, and they should be scoped in signal_experiments (which may be little used anyhow...).

So, the question is more about your opinions on future experiments (and experiments development), rather than about the present use case, that may be extremely limited.

[Edoardo-Pedicillo]

So, the question is more about your opinions on future experiments (and experiments development), rather than about the present use case, that may be extremely limited

Except for the experiments mentioned, the protocols that we are planning to deploy (https://github.com/qiboteam/qibocal/blob/main/doc/dev/README.md) should not require the raw acquisition.