---+!! Example of One Bolometer / Readout System Tuning Session
Start the Software
Launch the core readout software on stolichnaya.physics.berkeley.edu (SPT receiver PC).
[root@stolichnaya init.d]# /etc/init.d/fMUX restart
Stopping DIODaemon: [ OK ]
Stopping HardwareManagerDeamon: [ OK ]
Stopping WatchDogDeamon: [ OK ]
Starting errorServer: [ OK ]
Starting DIODaemon: [ OK ]
Starting HardwareManagerDaemon: [ OK ]
Starting WatchDogDaemon: [ OK ]
and run the script that sends the command to start recording data
MuxUI/scripts/StartADC.py
, which picks up its directives at
/usr/local/src/fMUX/Config/CURRENT/ADCConfig.xml
(this python script replaces the old
MuxReadoutSoftware/scripts/StartADC.sh
script, which is no longer
used).
Heat the SQUIDs
Run the script which turns off all of the SQUID biases and DDS outputs (
prepare_for_heat.py
) and then bring all of the bolometers normal so that no current is flowing through them (
bring_uchead_abovetc.py
) and then heat the SQUIDs to get rid of any trapped flux. (
heatsquids.py
). This sends several mA of current to a heater resistor which sits on the SQUID pc-boards next to each SQUID in the cryostat.
~/MuxUI/scripts/prepare_for_heat.py [-f ChannelList.all]
~/MuxUI/scripts/heatsquids.py [-f ChannelList.all]
~/fridge/tools/bring_uchead_abovetc.py
It takes about 20 minutes for the SQUID pc-boards to cool down again afterwards - so don't exercise the SQUIDs in this time.
Tune the SQUIDs
There are two SQUID tuning algorithms that we use commonly. The first and preferred tuning algorithm is a parallel version of the SQUID tuning, which is invoked as
~/MuxUI/scripts/SqTuneparallel.py [-f ChannelList.all]
it does many of the operations in parallel, so it is considerably faster than
tune_squids.py
. It will produce a single output file called
sqtunings.$PROCESS_ID.dat
. You can graphically look at the tuning results with
~/MuxUI/scripts/show_tuning.py sqtunings.$PROCESS_ID.dat
Or, to get a table of results for all the SQUIDs you've tuned, do
~/MuxUI/scripts/parseTuning.py sqtunings.$PROCESS_ID.dat
then emacs the file and look for outliers. Nominal values for things are: Bias current[mA]
(70-105) Vpp[mV]
{3-5.5} Phi_0 = {1.1-1.3}
Note that it may not be necessary to tune the squids every cycle - instead, we might be able to simply reload the previous tuning. To store a tuning, do
~/MuxUI/scripts/summarize_parameters.py -f ChannelList > parameters.out
Do this when you're pretty happy with the state of the system. Then, when you find yourself with similar temperatures and conditions, you can restore the parameters by doing
~/MuxUI/scripts/restore_from_parameters.py parameters.out
If you pass in the -ro option, the bolometer frequencies, biases, and nulling parameters will also be restored.
The second method of squid tuning is much slower, very roughly three minutes per SQUID, and it does all of the tuning in series one SQUID at a time. It should be used only when you have a few squids to tune. You can run it with the script
tune_squids.py
. Like most algorithms, there are three ways to invoke this script-- the syntax is
-
~/MuxUI/scripts/tune_squids.py
the script will look for a file called ChannelList, and read all of the readout channels from this file.
-
~/MuxUI/scripts/tune_squids.py -f file_with_channel_list
the script reads a list of readout channels from the file file_with_channel_list
-
~/MuxUI/scripts/tune_squids.py e8:ra8 e8:ra2
the script will tune only the squids that are attached to readout channels (e8:ra8 e8:ra2)
The heart of this script is the python command
response=squidChannel.alg_tune(flux_step, bias_step, num_samples, max_bias, vperphi),
which instructs the hardware manager to invoke the squid tuning algorithm, walking through the possible flux bias currents with steps of flux_step, and squid bias currents with steps of bias_step.
Each time the script tunes a SQUID, it writes a new ascii file. For SQUID channel 52:sa8, the file is called tune.52\:sa8, and you can get a visual view of the results using the python script
show_tuning.py
.
~/MuxUI/scripts/show_tuning.py tune.52\:sa8
MUX Network Analyses
For the first run in a cooldown, the next task is to find the resonance frequencies of each MUX LCR tank circuit by scanning across all frequencies in a MUX module. This needs to be done only once per cooldown, and is described at
SWNetworkAnalysisFitter.
Lock the squids and fix those that have Flux Jumped ¶
The SQUID tuning algorithm leaves the SQUIDS open loop. One easy way to close the loop is to use same script that we use to fix flux jumps.
~/MuxUI/scripts/fix_all_flux_jumps.py [-f ChannelList.all]
This program will close the SQUID loop using the 10K feedback resistor (default, or specify -5K to use the 5K resistor).
You can also use it to fix flux jumps. It will look at each SQUID, and if the DC level is outside of range (usually +-100 ADC counts), then it will try to open and close the loop (up to 7 times), stopping when the DC level falls within range. You can also specify the -zero option, which will pause to rezero the first stage amplifier after opening the loop. This is often necessary, and in practice there is no reason not to do it unless there is a big un-nulled signal going through the SQUID.
In general, a high DC level indicates a SQUID has flux jumped - which can usually be fixed with the scripts. If the DC level has a high RMS (e.g. you see it fluctuating around), our experience is that the SQUID is pathological (perhaps trapped flux or a bolometer in its comb has gone superconducting), and the SQUID should be shut down until it can be tuned again.
To see the AC and DC outputs for each channel, run
~/MuxUI/scripts/flag_fluxJumps_demodRails.py [-f ChannelList]
This will put an XXX by the channels it thinks are either flux jumped or railed. To turn off a bad squid comb use:
~/MuxUI/scripts/open_and_unbias_some_squids.py [your list of channels here]
be very careful with the above command - if you accidentally gave it the full channel list, it would turn off all of your beautifully tuned squids, and you'd have to go to smoker's bar and drink yourself silly.
Over-bias the bolometers and null the carriers
~/MuxUI/scripts/biasupBolos.py [-f ChannelList]
(biases and nulls the bolometers in parallel using the C++ algorithm "MOffsetNull")
This biases the bolometers normal (by default, carrier pot 180 and carrier amplitude 0.6) and nulls them.
After this script has been run, you need to again check for flux jumps and for failed attempts at nulling.
~/MuxUI/scripts/quick_summary_of_parameters.py [-f ChannelList]
will give you a table with some of the most important settings for each channel, plus its AC and DC output. If the DC output has an absolute value above about 150, chances are the SQUID is either (a) flux jumped, or (b) flux burdened by some failed attempts at nulling its bolometers.
Try to fix as many flux jumps and flux-burdened SQUIDS before cooling the stage, since at this point you can always unbias the bolometers to try to fix the SQUID if necessary. To fix flux jumps, run
~/MuxUI/scripts/fix_all_flux_jumps.py [-zero] [-f ChannelList | addr1 addr2 addr3]
To try to renull a bolometer that has not nulled successfully (as indicated by a high AC value, <-250 or >250; or by a nuller pot that is set at one of its rails, 0 or 255), use matt_offset_null.py, which is a slow but robust python nulling script:
~/MuxUI/scripts/matt_offset_null.py addr_to_fix sacrificial_channel_addr
Any channels that you are not able to fix should be removed from your working
ChannelList.
Cool the UC stage
~/fridge/tools/bring_uchead_tobasetemp.py
While the stage is cooling, it's not unusual for the DC outputs to change since the mainplate temperature is probably rising due to the heat from the UC Pump. By the time the stage reaches its base temperature, however, the SQUID DC levels should go back to normal (i.e. between -150 and +150).
Once the stage is cold again, repeat the check for flux jumps.
Bring combs of bolometers into their transition
Run
~/MuxUI/scripts/operateBolos.py [-f ChannelList]
It will take offset boloiv curves in order to bring all the connected channels in your list into their transitions, and will then null them using quadratic interpolation. It's highly parallelized, and it's been tested successfully on three wedges. It puts its output in
/home/spt/data/[YYMMDD]/[YYMMDD-HH.MM.SS]
. For now, ignore the "percent Rnormal" and "Rnormal estimates" it spits out--there's an error in that part of the algorithm. Fortunately, that doesn't impact its effectiveness--it biases about 80% of the combs successfully. By default, it takes each bolometer down to (0.9 + 0.05*(freq-300000)/1000000)*Rnormal. This means that the highest-frequency channels go down to about 0.94, compensating for the kickback they get upon nulling. One other thing to note about this script is that it uses the carrier potentiometer to dial down the voltage bias, as opposed to the older algorithms which use the IDAC amplitude.
To look at the Bolo IV's use gnuplot and the following information; The bolo IV script saves the data in the format:
bias_pot offset_amplitude_channel1 ADC_amplitude_channel1 offset_amplitude_channel2 ADC_amplitude_channel2 ...
So to plot the IV curve for channel 1, you would open up gnuplot and type: gnuplot> plot 'BoloIV-1.1' using 1:2 For channel 2: gnuplot> plot 'BoloIV-1.1' using 1:4 etc. The columns should be labeled according to their readout address.
To do one comb at a time, you can use
~/MuxUI/scripts/bring_comb_into_transition.py addr_base
(this script uses the slower Python offset boloiv algorithm, whereas operateBolos uses MOBoloIV (Multiple Offset BoloIV), which is implemented in C++)
Addr_base is, for example, 23:ra or 62:rb or some such thing. This will bring all bolometers attached to this SQUID down to 0.9 Rnormal, null them, and save the IV curves in the current working directory under the name offset_boloiv-addr-timestamp (e.g. offset_boloiv-23:ra4-2007-02-16T00-51-22).
The script runs pretty slowly, so you may want to open up the bolo IV curves in gnuplot to look at them while you wait. If the curve is smooth and you can see a turnaround at the end, chances are you've succeeded. If you see a large blip at the end of the curve, or if the curve looks choppy, you have probably latched a bolo on this comb, and you might want to unbias it and give up. Leaving it running could compromise your noise performance.
Fixing or getting rid of bad combs
- look at the bolo-iv's for at least the last biassed up bolometer in the comb to see if there has been a flux jump
- re-null the channel and then open and close the loop using "fix_all_flux_jumps.py -zero CHANNEL"
- if nothing works, take note of the comb and unbias it using
=openupandunbiassomesquids.py -f ChannelList.to.open =
Turn up the demodulator gains
~/MuxUI/scripts/set_oscdemod_parameter.py -dg zero [-f ChannelList]
Gain setting zero is the highest gain setting, about 150x gain setting three, and it's what you want if you care about the noise performance of the instrument. At lower gain settings, the noise will be dominated by readout noise; at gain setting zero, you should be dominated by shot noise.
Once the gain setting is high, it's possible you will have a number of channels on the demodulator rail. To fix this for one channel, do
~/MuxUI/scripts/matt_offset_null.py -finenullpot addr
and for a whole ChannelList, do
~/MuxUI/scripts/fine_tune_nulling.sh ChannelList
We reccomend that you only fine tune null those channels with counts above 6000
Please do not use the firmware nulling routine yet, as under some conditions it can lock up an entire readout board, necessitating a hard restart.
--
MattDobbs - 02 Dec 2006
This topic: AnalogFMux
> WebHome >
FMuxSoftwareGuide > SWExampleTuning
Topic revision: r5 - 2007-03-01 - MattDobbs