You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Audrey/Clemens/Chris met with Shawn Henderson twice in Dec. 2018 to understand their software for calibration/readout of the CMB TES.  They reuse many of the SLAC hardware/software tools that LCLS will use (rogue, KCU1500) so it feels like an excellent opportunity to reuse.  Our systems will only be different once the data enters the DRP node KCU1500, at least to first order.

Chris' Rough Notes on Software Usage

- calibration moving to python
- shawn/mitch/ed/cindyyu/arizuckerman/stevesmith
- edward young (kipac postdoc) ported to python, leads software
- github private repo
- public (old) matlab
- 500MHz: 30-40 minutes, can achieve <5 minutes

turn-on steps:
- power on

- "tune"
- calibrate bias voltages for cryogenic amplifiers (could change
with large number of tones)
- setup: setupGen2 (matlab) smurfControl.setup (python)
- faster version of findFreqs and setupNotches (in pysmurf it's called tune_band)
- findFreqs.m (fast)
o sweep tone looking for dips (e.g. from 5 to 5.5GHz) one dip per pixel
o each TES pixel has a dip
o have faster version of findFreqs in python called "tune_band".
injects white noise into the resonators to get a faster rough
estimate of frequencies.
- setupNotches_umux16 (slow)
o improves results from findFreqs
o need correct refPhaseDelay value for setupNotches to work (one
global number for all channels that reflects things like cable
lengths)
o map I/Q circle, change to I'/Q' to max i' is at top of circle
o slow because of pyrogue measuring lots of points on the circle
o have a faster setupNotches: if have a rough estimate of eta
can just look in part of the circle. "runParallelEtaScan" in
the pyrogue gui (parallel over channels).
- measure "eta" which transforms I/Q to I'/Q', and tweak eta to stay on
resonance
- different eta for each notch from findFreqs
- 10-80kHz (MHz for x ray) sweep frequency back and forth ("tracking").
we call this "flux ramp"
- determine_demo_carrier_frequency drives the tracking above
- in python pysmurf.smurfControl.tracking_setup does the above
- turn on the flux ramp modulation
- don't know how often we would run it (6 hours). maybe less often
with "dilution" refrigerator which cycles less.

also calibrate the TES to get them near the critical point, I think:
- generate I/V curve to find out where it goes non superconducting
- need to set bias voltages for TES pixels

three biases:
- RF amplifier bias (very rarely)
- tes voltage biases (more frequently than the tune calibration).
called "IV curves", takes 1-5 minutes. at SSRL the bias voltages are
pretty static.
o this is done in python with the smufControl.slow_iv() command
- flux ramp bias (or "carrier") (change very rarely)

what quantities they use for quality monitoring while taking data:
- look flux ramp curves (frequency vs time sine waves with "reset" per flux-ramp)
- OR maybe the error produced from the flux-ramp curves? this comes
from the rogue epics.

  • No labels