Sweeping and Setup Code Doesn't Optimally Support Reduced Channel Set

[JennySmith888]

With some of these tests, my waveform config has many tones but I only want to rotate, center, sweep, etc. 1 or a few channels.

For example, here my waveform config has 2048 tones but I only want to sweep, rotate, and center 1: ro_tone. I am assigning empty OPFB bins to the other channels and essentially turning the DDC off for all but channel 0 (to conserve power).

# Bin2Res + DDC
empty_bin = opfb_bin_number(tones.max() + 100e6, ssr_raw_order=True)
bins = np.zeros(2048, dtype=int)+empty_bin
bins[0] = opfb_bin_number(ro_tone, ssr_raw_order=True)

chan = ChannelConfig(bins=bins)
ol.photon_pipe.reschan.bin_to_res.configure(**chan.settings_dict())

ddc_tones = np.zeros(2048)
ddc_tones[0] = ro_tone

ddc = DDCConfig(tones=ddc_tones)
ol.photon_pipe.reschan.ddccontrol_0.configure(**ddc.settings_dict())

I have added some minimal support for this in the setup code (mostly cutting out unused channels from plots) but we might want to think about integrating channels as an argument in the sweep functions so the unused channels are not captured, saved, etc. I wouldn't mind saving the unused data but I'm finding sweeping with a waveform config with 2048 tones is significantly slower than sweeping with a waveform config with 1 tone so it might be a worthwhile optimization to not do this if we don't have to.

As a side note, the setup code should probably not rely on or apply default_ddc_config because it would be inconsistent with / wipe a customization like shown above. As of recently the ddc driver supports independent writing of the tones, offsets, and centers (thanks @baileyji). I have fixed all instances of that except in the "new tones" and "tone label" features in the plots.

I'm not sure how typical this use case is. For sure it's helpful for characterization and it may be helpful to "spot check" a few resonators' setup in the future but I wouldn't consider this a top priority.

[baileyji]

Before trying to add a new feature I am interested in better understanding two things:

1. What does an all channels sweep flow and associated functions look like
2. Where is the actual slowdown? Is it actually data transmission overhead or something else?

[JennySmith888]

Yea the slowdown might be something else. Probably wise to investigate that first. You can check out this notebook Section 3.0: Paramp + HEMT MKID Measurments to see how we've been running sweeps.

[ld-cd]

On the board the time it takes is roughly linear in the number of channels with the overwhelming majority of time spent in n int to float conversion which appears to be memory bound. I usually just reprogram the DAC table to have the tones I want, but in scenarios where I do want the other tones there I have constructed a real waveform and a fake waveform which has only the tones I want to read out which I agree is not the best way to handle this.

[ld-cd]

The way I would modify this to integrate well with ddc setting routines and similar in the same way is to subclass FreqListWaveform and introduce something like a shadow_tones/amplitudes/phases argument that get added to the generated waveform but don't show up in the default ddc config or in the .frequencies attribute