Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update tracking.py changing the frac_pp for bands in setup_tracking_params #372

Closed
wants to merge 1 commit into from

Conversation

yuhanwyhan
Copy link
Contributor

this pull request includes work done in LATR high bay cooldown, Princeton testbed, TSAT (led by @yuhanwyhan) and Cornell testbed led by @yaqiongl

We noticed a failure mode during the LATR high bay cooldown of the setup_tracking_params.
The failure mode was then repeated in TSAT.
The core issue is setup_tracking_params shouldn't set different fraction_full_scale for different SMuRF bands, since that parameters controls the FR current magnitude and there is only one FR current flowing trough each half of the UFM.
(There should be one fracc_pp for all bands, otherwise the previous band will have tracking issue since the tracking is done from band 0~7 in series but there is only one current flowing through all of them. Currently setup_tracking_params assigns 8 different numbers to all 8 bands )

Instead, the script should set one fixed fraction_full-scale for half UFM and set different lms_freq for each individual smurf band.

the failure mode was recorded using Mv12 in TSAT.
when running
tracking_res = tracking.setup_tracking_params( S, cfg, [0,1,2,3,4,5,6,7], show_plots=True, update_cfg=True )

the script returns to a good tracking summary plot since the result shown in this plot is from the individual result of the band being tracked.
Screenshot 2023-07-18 at 1 51 13 PM

However, when taking noise right after, the noise is high for multiple bands
Screenshot 2023-07-18 at 1 52 04 PM

this failure mode remains the same even with a more accurate intial frac pp

without changing anything related to RF power but only tracking all bands again with the same frac_pp:
for band in [0,1,2,3,4,5,6,7]: S.tracking_setup(band,reset_rate_khz=4,fraction_full_scale=0.368, make_plot=True, save_plot=True, show_plot=True,channel=S.which_on(band)[0:3], nsamp=2**18, lms_freq_hz=None, meas_lms_freq=True,feedback_start_frac=1/12,feedback_end_frac=1,lms_gain=1)
Screenshot 2023-07-18 at 1 59 55 PM

This pull request is a fix of this failure mode by calculating the frac_pp using the first band, using it for all smurf bands, and then applying different lms_freq to suit individual band

@jlashner
Copy link
Collaborator

I don't believe this is right. It is correct for each band to have a separate optimal frac-pp value, since the correct fraction full scale may be different for different bands (we've definitely seen this across AMCs).

However, when we set the frac-pp for operation we need to take into account the different optimal frac-pp values for each individual band to get a single frac-pp for the whole wafer. This is done in relock_tracking_setup here:

# Arrays containing the optimized tracking parameters for each band
frac_pp0 = np.zeros(nbands)
lms_freq0 = np.zeros(nbands) # Hz
reset_rate_khz0 = exp['flux_ramp_rate_khz']
init_nphi0 = exp['nphi0']
for i, b in enumerate(bands):
bcfg = cfg.dev.bands[b]
frac_pp0[i] = bcfg['frac_pp']
lms_freq0[i] = bcfg['lms_freq_hz']
# Choose frac_pp to be the mean of all running bands.
# This is the frac-pp at the flux-ramp-rate used for optimization
fpp0 = np.mean(frac_pp0)
lms_freq0 *= fpp0 / frac_pp0
S.log(f"Using frac-pp={fpp0}")
# Adjust fpp, lms_freq, and flux-ramp-rate depending on desired
# flux-ramp-rate and nphi0
fpp, lms_freqs = fpp0, lms_freq0
if nphi0 is not None:
fpp *= nphi0 / init_nphi0
lms_freqs *= fpp / fpp0
if reset_rate_khz is not None:
lms_freqs *= reset_rate_khz / reset_rate_khz0
else:
reset_rate_khz = reset_rate_khz0

So actually you should always run relock_tracking_setup after setup_tracking_params to choose a good global frac-pp value. We may want to just add a relock_tracking_setup call to the end of the function to put you in a good state.

@jlashner
Copy link
Collaborator

jlashner commented Jan 4, 2024

Checked with Yuhan decided we could close this. This should be fixed with #388

@jlashner jlashner closed this Jan 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants