[Bug] missing documentation on FastCounterInterface constraints

[qku]

Version

current main

What is affected by the bug?

The constraints for fast counter hardware are a dictionary. The keys are nowhere specified however. Therefore I am having difficulty in writing a hardware module implementing the FastCounterInterface.

When does the bug occur?

not applicable

How do we replicate the issue?

not applicable

Expected behavior

The structure of the dictionary returned by get_constraints() is documented in the interface, e.g. in the docstring of this method.

Relevant log output

No response

Additional Comments

Looking through existing hardware implementations, I could find the following keys in FastComtec:

constraints['hardware_binwidth_list'] = list(self.minimal_binwidth * (2 ** np.array(np.linspace(0,24,25))))
constraints['max_sweep_len'] = 6.8
constraints['max_bins'] = 6.8 / 0.2e-9

If this implementation is correct, the docstring for get_constraints() is actually incorrect, since it states:

The items of the keys are again dictionaries which have the generic
dictionary form:
{'min': ,
'max': ,
'step': ,
'unit': ''}

Only the key 'hardware_binwidth_list' differs, since they
contain the list of possible binwidths.

Contact Details

No response

[timoML]

I started overhauling the FastCounterInterface in this branch.

[qku]

@timoML I have two questions on the fast counter interface:

1. How should stop_measure and pause_measure behave differently? Should the data on the device be cleared if stop_measure was called?
2. Should the data also be cleared on the device after get_data_trace was called?

[timoML]

1. pause_measure should guarantee that the measurement can be continued. So both the data needs to be stored on the hardware and the device needs a way to continue this measurement later on. Clearing of data needs to happen any time before start_measure. For fastcomtech fast counters, that happens while starting a new measurement, but other hw could do it at stop_measure.
2. No. The hardware is expected to perform averaging or summing over repeated shots of the experiment. get_data_trace is just a query to the device memory.

[qku]

For the time tagger we use in the lab (quTAG from qutools), hardware_binwidth_list does not make a lot of sense actually. The device can do any multiple of 1 ps as a binwidth.

There are TODO comments in the Swabian and Pi3 fast counter hardware files suggesting that this constraint also makes no sense for this hardware.

[Neverhorst]

For the time tagger we use in the lab (quTAG from qutools), hardware_binwidth_list does not make a lot of sense actually. The device can do any multiple of 1 ps as a binwidth.

That depends on the hardware implementation. If the hardware directly samples the signal with a clock, you usually end up with an integer fractional (M/D) of a base clock frequency (non-linear increments).
This is the standard method in older devices.
The newer ones usually sample with maximum accuracy and implement software binning, which enables linear increments.

A revision of this constraint should introduce case sensitive handling to cover both cases.
The easier and not necessarily worse solution would be to keep it a discrete set of allowed values since this works for both cases.

[timoML]

I agree, the reworked FastCounterInterface should definitely have better support for linear binwidth increments.
I see two solutions:

1. Linear increment could be a constraints flag that changes the behavior of the pulsed_gui, and replace the binwidth comboBox with a single float input.
2. Hardware with linear increment could emulate the current behavior by a "lazy" list object that makes use of a generator. This "list" could be very long or even infinite and the pulsed_gui could show the first ~100 binwidth list elements. This would come with the drawback that free configuration of the binwidth (with values outside of the binwidth list elements sampled in the combobox) is only possible by a script that calls pulsed_logic.set_binwidth().