Added fixed frequency readout mode (CW mode) to ZNB driver

[GitJaap]

The ZNB20 VNA driver currently supports only the 'linear' sweep mode. This is by default set when instantiating a channel. For things like two tone spectroscopy we would then hack a linear frequency trace with 1 Hz span such that we could do readout at a single point.

It turns out the VNA has internal support for fixed frequency readout so I added that to the driver. I added it in a way that the current way the VNA is used should still function as it did, but you now have the option to switch to Continuous wave mode (CW mode). In CW mode there is no AVG setting(defaults to 1) and the integration time per point is set by 1/bandwidth. This allows for doing measurements of at the minimum 1us(max BW=1MHz) integration time at a fixed frequency and doing time resolved traces with the VNA or a crude version of single shot measurements. Also two tone can be faster (depending on how you implemented it with the vna before) since this reduces overhead (e.g simulating extremely small frequency stepping). And a small bonus: now you can go to 100k points instead of the 30k that is the limit in linear frequency sweep mode.

For this added three parameters similar to the existing ones:

• trace_fixed_frequency -> measures the raw real and imag part of the signal and sets time as the x-axis.
• point_fixed_frequency -> basically averages the trace_fixed_frequency into a single point which is useful if you don't care about the individual I-Q outcomes but you just want the average for e.g two-tone spectroscopy.
• point_fixed_frequency_mag_phase -> same as point_fixed_frequency but returns the mag/phase instead of I-Q if you are more used to that.

@mention one core developer

• @lakhotiaharshit @astafan8 Could you have a look if this is in any way according to the qcodes protocol and if you have suggestions for additions.
• Also, I some example code, but where should i put that preferably?

Example

pwr=-20
npts=700
bw=1e5
frequency=4.823e9

exp = new_experiment("VNA fixed freq P=%d dBM,N=%d,BW=%d KHz" % ( pwr,npts,bw/1e3), sample_name)
meas = Measurement()

meas.register_parameter(vna.channels.S21.trace_fixed_frequency)

#setup vna CW mode
vna.S21.setup_cw_sweep()
#set vna params
vna.S21.cw_frequency(frequency)
vna.S21.npts(npts)
vna.S21.bandwidth(bw)
vna.S21.power(pwr)
vna.rf_on()

with meas.run() as datasaver:
    get_v = vna.S21.trace_fixed_frequency.get()
    datasaver.add_result((vna.S21.trace_fixed_frequency, get_v))
    
vna.S21.power.set(-60)
#reset the vna back to linear mode so you can use if for frequency traces again
vna.S21.setup_lin_sweep()
vna.rf_off()

result:

Note the time axis is here determined by npts/BW, but there is a little overhead so for very fast measurements one should note that the time might not perfectly correspond to the time the point was taken. I tested it with %timeit and the overhead was about 3 to 5ms minimum, but I'm not sure where that happens (communication or internally.) I'm guessing in communication since when you increase npts the overhead scales sub-linearly.

[codecov]

Codecov Report

Merging #2007 (0e25d60) into master (6b96ac3) will decrease coverage by 0.13%.
The diff coverage is 16.30%.

@@            Coverage Diff             @@
##           master    #2007      +/-   ##
==========================================
- Coverage   62.36%   62.23%   -0.14%     
==========================================
  Files         200      200              
  Lines       26248    26342      +94     
==========================================
+ Hits        16370    16394      +24     
- Misses       9878     9948      +70     

[abargerbos]

@astafan8 We are currently using this fork on 3 (that I know of) measurement setups in Delft (QT3, K1, K2), it has been a very useful addition to the driver!

[astafan8]

@abargerbos @GitJaap thanks for reminding, I'll have a look at it!

[astafan8]

as a first step:

• please go through the todo comments and either removed them if they are not necessary or make the improvements that they suggest if possible
• the example measurement and explanation of how this works, that is in the PR (thanks!), should be added to the example notebook for this instrument. If there's none, feel free to create one (qcodes docs on "writing drivers" explains how to do that)

[LGruenhaupt]

Hi @astafan8,
just pinging you again to ask about the status of this. As Arno already mentioned, we are running this fork still on three setups (K1, K2/QT6, QT3). Is there some additional work to be done before this gets pulled into the qcodes master branch?

[astafan8]

@LGruenhaupt thanks for reminding! we'll sync with @Akshita07 and let you know :)

[Akshita07]

@LGruenhaupt thank you for reminding. This PR will be merged in the qcodes master the upcoming week.
@astafan8 please have a final look at the driver code. For the example notebook, I'll create a separate PR so that this merge is not stalled more.

[jenshnielsen]

Added a few small comments. This will also need full types for all the new functions that were added

[GitJaap]

@astafan8 yup that worked!