Tracking not working

[aashrita]

I am currently testing the SMB and SPB. I can't get the tracking to work. It finds the tones, but then tracks 0/60 channels. I probed the FR lines for continuity already. I am not sure what to do here. Thanks!

[msilvafe]

Please post plots. Are there any log messages indicating why it is cutting channels? We need more info than this to help.

[aashrita]

Ok sure. Here are screenshots from some relevant plots.

I think most of the SMB channels are bad to be honest, but it would be nice to confirm that this isn't a problem with how I have set things up. I used Jack's method outlined in LATR wiki, and I also checked device config files.

[msilvafe]

What is "Jack's method outlined in latr wiki"? Can you link to that and/or copy paste the code u ran?

[aashrita]

https://simonsobs.atlassian.net/wiki/spaces/PRO/pages/154566905/Readout+Setup+Logs

[msilvafe]

Got it thanks. What exactly is connected here? Are there 4 smbs/spbs in a single Smurf band? Can't see exactly since the find freq plot amp portion is cut off in your screenshot. Wondering if these boxes have different enough optimal flux ramp parameters so u can't run them at the same time easily

[aashrita]

Right, so I am just checking an SMB right now. I only sent a screenshot of band 0 because that's where it's doing its thing happily.

In the SAT right now we have one SMB, one SPB, and 2 UFMs. I am trying to just see if I can practice sodetlib stuff on the SMB and SPB before I try UFM stuff.

[jlashner]

Before running tracking, can you look at some of the resonator plots directly by disabling flux ramp, and running uxm_relock.plot_channel_resonance?

[aashrita]

yeah. but it still is tracking 0/60. I agree it's a bit better though.

[aashrita]

Let me know what else I can do try to play with this because I'm at the edge of my knowledge at this point :)

[msilvafe]

I'm surprised that with 6-10dB of added attenuation you still seem off in power. I wonder if your tone settings are different in your configs can you get what the synthesis scale, amplitude scale were. I seem to recall in loopback we were also seeing not quite what was expected so maybe related. Can you check those settings and report here synthesis_scale should be 1 and amplitude_scale should be 12.

May be worth leaving things for the weekend and Jack or I can walk through all the tuning steps with you on zoom sometime next week.

[aashrita]

synthesis_scale is 1 and tone_power is 12. I didn't see an amplitude_scale anywhere. i actually even copied over princeton's SMB config file and ran with that just to be sure i had settings correctly.

This is what would hold up deployment for us right now, so I really can't afford to hold off for a week on this. We have completed basically all other tests for this final cooldown. I can quote Adrian's support on the statement that this debugging is critical for deployment of SAT UHF.

[aashrita]

By the way, this is what led me to believe that the SMB channels are just bad, but perhaps I am wrong/missing something. I ran the following code to look at individual channel tracking info, and played around with fraction_full_scale as well. I've taken screenshots of a lot of channels -- most of them look bad and there are very few that look reasonable.

band = 0
S3.set_feedback_enable(band,0)
S3.tracking_setup(
        band, reset_rate_khz=cfg3.dev.bands[band]['flux_ramp_rate_khz'],
        fraction_full_scale=cfg3.dev.bands[band]['frac_pp'], make_plot=True,
        save_plot=False, show_plot=True, channel=S3.which_on(band),
        nsamp=2**18, lms_freq_hz=None, meas_lms_freq=True,
        feedback_start_frac=cfg3.dev.bands[band]['feedback_start_frac'],
        feedback_end_frac=cfg3.dev.bands[band]['feedback_end_frac'],
        lms_gain=cfg3.dev.bands[band]['lms_gain'],
    )

[jlashner]

Hi Aashrita, in the resonator plots you posted, like the one below:

it looks a lot like there is a linear slope in the phase. This is likely caused by the phase delay not being set correctly, and this screws up the resonance finding algorithm. In this plot you posted:

it looks to me like there are a lot of "channels" that it finds that are not real resonances. It is hard to tell but it also looks like deriv of the phase is slightly off from zero, which is another sign that the phase delay is not correct.

The tracking plots you post above where there is no resemblance of a SQUID curve could be channels that aren't real resonators.

I would re-run uxm_setup.setup_phase_delay and find-freq for the bands you expect resonators. You should only really get peak detections where it looks like there's a resonance and not all of those vertical lines away from the SPB.

[jlashner]

One simple way to check is to compare the number of channels detected compared to the number you expect from the SPBs. If they are very different then there are a lot of false channels.

[aashrita]

Hi Jack, I am running setup_phase_delay already. Also, I run full_band_resp after. I can run find_freq specifically if you prefer. As linked above for Max, I am running what you had linked on slack for the LATR instructions: https://simonsobs.atlassian.net/wiki/spaces/PRO/pages/154566905/Readout+Setup+Logs

Any deviations in my code are debugging suggestions from here/Daniel but shouldn't affect the setup.

[aashrita]

To clarify - do you want me to run setup_phase_delay twice in a row in case the first round doesnt update correctly?

[msilvafe]

The phase delay step probably failed to estimate it properly in the setup fn just run the phase delay estimation and then check a single channel to see that the slope went away. Then we can go from there.

[msilvafe]

It shouldn't be necessary in general to run twice in a row always