Need a way to bookkeep fixed_tones and keep them on

[msilvafe]

@swh76 has requested (a few times now) that we automate/integrate a standardized way to keep around fixed tones in the sodetlib standard operations to monitor background/environmental phase drifts that may couple into our data. @tristpinsm has volunteered to look into (and implement) this so I'm posting this issue here with what I think is holding us back from that at the moment and what I think would need to be added in order to get this into main.

Fixed tones can be used to track the background phase shifts in the cables and smurf warm electronics (see this paper for reference). They are additional probe tones turned on at locations where there are no cryogenic resonances and they have their feedback parameters disabled which then returns the I/Q stream at each fixed tone location since there's no resonator inducing a frequency shift the variation in the angle arctan(Q/I) comes from changes in the background phase delay (in the coaxial cabling and smurf electronics). To turn them on we need to modify some of the come sodetlib tuning functions to acknowledge the presence of fixed tones so that they're not turned off and get their feedback properly reset to disabled whenever relocking occurs. I think this basically would go as follows:

1. Normal UFM setup

sodetlib.uxm_setup.setup_amps(<normal_args>)
sodetlib.uxm_setup.setup_phase_delay(<normal_args>)
sodetlib.uxm_setup.setup_tune(<normal_args>)

2. Then turn on fixed tones and keep track of them

fixed_tones = np.zeros((8, 512)).astype(bool)
for fr in fixed_tone_frequencies:
    band, channel = S.set_fixed_tone(fr, tone_power=10)
    fixed_tones[band, channel] = True

3. Then setup tracking, which needs to now take an additional argument fixed_tones which does not turn these off at the df & fptp.

fixed_tones = True for that band/channel
sodetlib.tracking.setup_tracking_params(<normal_args>, fixed_tones)

4. For the tones that don't get turned off additionally we must reset their feedback to disabled after tracking setup is run as follows:

for band in bands:
    fea = S.get_feedback_enable_array(band)
    fea[fixed_tones[band]] = 0
    S.set_feedback_enable_array(band, fea)

The key steps are 3 and 4. Probably the fixed_tones boolean mask and/or the fixed_tone_frequencies should be stored in the device_cfg file. And if 4 is incorporated into a modification of sodetlib.tracking.setup_tracking_params then step 1 could be replaced with sodetlib.uxm_setup.uxm_setup if uxm_setup is also modified to take in the fixed tones and implement step 2. Relock will also need to be modified because the tune_file will not have the fixed tones in it so after load_tune is called step 2 will need to be run again right before the tracking step.

[tristpinsm]

Thanks for the super clear explanation! I've been looking through the code this morning and it does look like there could many possibilities for how to organise this.

A couple questions came up:

1. Is there a reason to set up the fixed tones before tracking? Or could you make it the last step and then not have to go back and forth with disabling feedback?
2. If we need to modify the tracking and relock functions, would it make sense to store the fixed tones in the tune file, so that it is a bit more transparent, or is that out of scope for that file?

[tristpinsm]

Looking at this some more, things that can disrupt the fixed tones are

• changing the central frequency of its channel
• changing the amplitude of its channel
• enabling feedback on its channel
• ? (that's as far as I know)

grep-ing through the sodetlib code, amplitude and feedback get set in tracking and relock. And channels shouldn't be reassigned since fixed tones will presumably not overlap with resonators.

One possible way to do this could thus be to add a setup_fixed_tones method, and add it to the sequence that is run in uxm_setup and uxm_relock. The fixed tone frequencies and channels could be in the device config then. I think in this scheme normal operations through OCS would not disrupt the fixed tones (TBC).

Alternatively, you could save them in the tune file and handle them in the tune / tracking / relock codes. This might be more robust (?) but also more disruptive to the code.

(sorry if I am thinking out loud, still wrapping my head around this)

[jlashner]

If its not very time consuming to setup fixed tones, then I think the most robust way to enable them is just to check / enable them in the g3 stream_on function. Like the downsample factor and downsample mode, we've found that any settings that we want to enforce while streaming should just be set in the stream function itself. Otherwise, like you say, there's always the possibility that the fixed tones are unintentionally disrupted by running a pysmurf function.

I think for applications like this, its easier to just check fixed tones are how we want them whenever we stream than to make sure all of our regular sodetlib and pysmurf operations preserve the fixed tone state.

[jlashner]

As far as where the fixed tones should be stored, I was thinking they could go into the device cfg file as opposed to the tune-file. The tunefile would technically work, but I like the device cfg file because we have more control of it and are tracking it more regularly, and its easier to modify things by hand if we need to.

Anything that's added to the tunefile after the initial tune is kind of a pain to integrate into our data packaging system, and will be difficult to track downstream.

[tristpinsm]

I drafted an implementation of this and wanted to open a draft PR, but I don't seem to have permissions to do so. @jlashner could you add me?

[jlashner]

Sure, can you try again? Added you to the readout and detectors group which should have write access.

[msilvafe]

Thanks for the super clear explanation! I've been looking through the code this morning and it does look like there could many possibilities for how to organise this.

A couple questions came up:

1. Is there a reason to set up the fixed tones before tracking? Or could you make it the last step and then not have to go back and forth with disabling feedback?

Yes, tracking setup needs to be run after turning on fixed tones for the readout to work. Perhaps you can figure out the exact parameters that get set during tracking and just do those steps to the fixed tones if you do this after tracking but I found it easier to just run the tracking setup after turning them on.

2. If we need to modify the tracking and relock functions, would it make sense to store the fixed tones in the tune file, so that it is a bit more transparent, or is that out of scope for that file?

And I'm not opposed to doing it in the tune file, but I think Jack brings up good points. In general how do we handling these tones down the line in data packaging though?