patrick.thomas@LIGO.ORG - posted 15:42, Tuesday 04 August 2015 (20218)
Added PSL ISS ref signal to SDF
Added H1:PSL-ISS_REFSIGNAL to the set of monitored channels in SDF. Accepted value of -2.06.
Added H1:PSL-ISS_REFSIGNAL to the set of monitored channels in SDF. Accepted value of -2.06.
This morning's maintenance included the addition of Filter modules to he cooling fan circuits in the Ring Heater chassis. Mods were made to Chassis S1201851(End-Y), S1201852(End-X), S1201847(CS) and S1201848(CS). Filter Module # D0902458
Hannah, Nutsinee, John, Elli
We moved the IR sensor for the CO2Y laser from the electronics rack to the viewport on BSC1, which is where it is meant to be located. The IR sensor checks whether the CO2 laser is heating the viewport(!). We took a side panel off of the CO2Y table to install the temperature sensor onto the viewport. The IR sensor cable runs out of the tube connecting the viewport to the table, up to a small "TCS IR controller box" which is taped to the top of the CO2Y table. The IR sensor has been tested and is working. As this procedure was relatively straightforward, we should move the CO2X sensor next Tuesday, time permitting.
Keita, Kiwamu,
We updated the lists of the sceice frame channels on the LSC, OMC and ASCIMC models. This means that we edited the following master blocks:
asc/common/models/ASCIMC_MASTER.adllsc/common/models/lsc.mdllsc/common/models/lscimc.mdlomc/common/models/omc.mdlomc/common/models/omclsc.mdlThen we recompiled, reinstalled and restarted the three models. Additionally, burtrestored them back to 10:10 PT of this morning. After we double-checked the ini files to make sure that the right channels were selected, we checked in the above common blocks to the SV
Additionally, we added commissioning frame for the EOM driver signals such as LSC-MOD_RF9_AM_ERR and etc
The followings are lists of the science frame channels after the update. Note that we did not edit ALSEX or ALSEY but they are listed for completeness:
kiwamu.izumi@opsws5:/opt/rtcds/lho/h1/chans/daq$ grep -B 1 "^acquire=3" H1LSC.ini | grep DQ
[H1:IMC-F_OUT_DQ]
[H1:IMC-I_OUT_DQ]
[H1:IMC-L_OUT_DQ]
[H1:IMC-REFL_DC_OUT_DQ]
[H1:IMC-TRANS_OUT_DQ]
[H1:LSC-ASAIR_B_RF90_I_ERR_DQ]
[H1:LSC-MCL_IN1_DQ]
[H1:LSC-MCL_OUT_DQ]
[H1:LSC-MICH_IN1_DQ]
[H1:LSC-MICH_OUT_DQ]
[H1:LSC-ODC_CHANNEL_OUT_DQ]
[H1:LSC-POPAIR_B_RF18_I_ERR_DQ]
[H1:LSC-POPAIR_B_RF90_I_ERR_DQ]
[H1:LSC-POP_A_LF_OUT_DQ]
[H1:LSC-POP_A_RF45_I_ERR_DQ]
[H1:LSC-POP_A_RF45_Q_ERR_DQ]
[H1:LSC-POP_A_RF9_I_ERR_DQ]
[H1:LSC-POP_A_RF9_Q_ERR_DQ]
[H1:LSC-PRCL_IN1_DQ]
[H1:LSC-PRCL_OUT_DQ]
[H1:LSC-REFL_A_LF_OUT_DQ]
[H1:LSC-REFL_A_RF45_I_ERR_DQ]
[H1:LSC-REFL_A_RF45_Q_ERR_DQ]
[H1:LSC-REFL_A_RF9_I_ERR_DQ]
[H1:LSC-REFL_A_RF9_Q_ERR_DQ]
[H1:LSC-REFL_SERVO_ERR_OUT_DQ]
[H1:LSC-REFL_SERVO_SLOW_OUT_DQ]
[H1:LSC-SRCL_IN1_DQ]
[H1:LSC-SRCL_OUT_DQ]
kiwamu.izumi@opsws5:/opt/rtcds/lho/h1/chans/daq$ grep -B 1 "^acquire=3" H1OMC.ini | grep DQ
[H1:LSC-DARM_IN1_DQ]
[H1:LSC-DARM_OUT_DQ]
[H1:LSC-REFL_SERVO_CTRL_OUT_DQ]
[H1:OMC-ASC_ANG_X_OUT_DQ]
[H1:OMC-ASC_ANG_Y_OUT_DQ]
[H1:OMC-ASC_P1_I_OUT_DQ]
[H1:OMC-ASC_P2_I_OUT_DQ]
[H1:OMC-ASC_POS_X_OUT_DQ]
[H1:OMC-ASC_POS_Y_OUT_DQ]
[H1:OMC-ASC_Y1_I_OUT_DQ]
[H1:OMC-ASC_Y2_I_OUT_DQ]
[H1:OMC-DCPD_A_OUT_DQ]
[H1:OMC-DCPD_B_OUT_DQ]
[H1:OMC-DCPD_NULL_OUT_DQ]
[H1:OMC-DCPD_SUM_OUT_DQ]
[H1:OMC-LSC_DITHER_OUT_DQ]
[H1:OMC-LSC_I_OUT_DQ]
[H1:OMC-LSC_SERVO_OUT_DQ]
[H1:OMC-ODC_CHANNEL_OUT_DQ]
[H1:OMC-PZT1_MON_AC_OUT_DQ]
[H1:OMC-PZT1_MON_DC_OUT_DQ]
[H1:OMC-PZT2_MON_AC_OUT_DQ]
[H1:OMC-PZT2_MON_DC_OUT_DQ]
kiwamu.izumi@opsws5:/opt/rtcds/lho/h1/chans/daq$ grep -B 1 "^acquire=3" H1ASCIMC.ini | grep DQ
[H1:IMC-DOF_1_P_IN1_DQ]
[H1:IMC-DOF_1_Y_IN1_DQ]
[H1:IMC-DOF_2_P_IN1_DQ]
[H1:IMC-DOF_2_Y_IN1_DQ]
[H1:IMC-DOF_3_P_IN1_DQ]
[H1:IMC-DOF_3_Y_IN1_DQ]
[H1:IMC-DOF_4_P_IN1_DQ]
[H1:IMC-DOF_4_Y_IN1_DQ]
[H1:IMC-DOF_5_P_IN1_DQ]
[H1:IMC-DOF_5_Y_IN1_DQ]
[H1:IMC-IM4_TRANS_PIT_OUT_DQ]
[H1:IMC-IM4_TRANS_SUM_OUT_DQ]
[H1:IMC-IM4_TRANS_YAW_OUT_DQ]
[H1:IMC-ISS_QPD_PIT_OUT_DQ]
[H1:IMC-ISS_QPD_SUM_IN1_DQ]
[H1:IMC-ISS_QPD_SUM_OUT_DQ]
[H1:IMC-ISS_QPD_YAW_OUT_DQ]
[H1:IMC-MC1_PIT_OUT_DQ]
[H1:IMC-MC1_YAW_OUT_DQ]
[H1:IMC-MC2_PIT_OUT_DQ]
[H1:IMC-MC2_TRANS_PIT_OUT_DQ]
[H1:IMC-MC2_TRANS_SUM_OUT_DQ]
[H1:IMC-MC2_TRANS_YAW_OUT_DQ]
[H1:IMC-MC2_YAW_OUT_DQ]
[H1:IMC-MC3_PIT_OUT_DQ]
[H1:IMC-MC3_YAW_OUT_DQ]
[H1:IMC-ODC_CHANNEL_OUT_DQ]
[H1:IMC-PWR_IN_OUT_DQ]
[H1:IMC-PZT_PIT_OUT_DQ]
[H1:IMC-PZT_YAW_OUT_DQ]
[H1:IMC-WFS_A_DC_PIT_OUT_DQ]
[H1:IMC-WFS_A_DC_SUM_OUT_DQ]
[H1:IMC-WFS_A_DC_YAW_OUT_DQ]
[H1:IMC-WFS_A_I_PIT_OUT_DQ]
[H1:IMC-WFS_A_I_YAW_OUT_DQ]
[H1:IMC-WFS_A_Q_PIT_OUT_DQ]
[H1:IMC-WFS_A_Q_YAW_OUT_DQ]
[H1:IMC-WFS_B_DC_PIT_OUT_DQ]
[H1:IMC-WFS_B_DC_SUM_OUT_DQ]
[H1:IMC-WFS_B_DC_YAW_OUT_DQ]
[H1:IMC-WFS_B_I_PIT_OUT_DQ]
[H1:IMC-WFS_B_I_YAW_OUT_DQ]
[H1:IMC-WFS_B_Q_PIT_OUT_DQ]
[H1:IMC-WFS_B_Q_YAW_OUT_DQ]
kiwamu.izumi@opsws5:/opt/rtcds/lho/h1/chans/daq$ grep -B 1 "^acquire=3" H1ALSEX.ini | grep DQ
[H1:ALS-X_ODC_CHANNEL_OUT_DQ]
[H1:LSC-X_ARM_OUT_DQ]
[H1:LSC-X_TIDAL_OUT_DQ]
kiwamu.izumi@opsws5:/opt/rtcds/lho/h1/chans/daq$ grep -B 1 "^acquire=3" H1ALSEY.ini | grep DQ
[H1:ALS-Y_ODC_CHANNEL_OUT_DQ]
[H1:LSC-Y_ARM_OUT_DQ]
[H1:LSC-Y_TIDAL_OUT_DQ]
LSC, OMC, and ASCIMC were all burt restored to 10:10am this morning.
JimW, HughR
We took all the SEIs down with guardian. Ran foton -c foton hepifile and then loaded the modified file. Re-isolated all platforms.
I've looked at a few archived foton files to see if this caused any significant changes in any coefficients. Mostly what I've found are changes in the order of header information, but H1HPIBS.txt show a bunch of changes, all at the ~10^-6 level , so probably still harmless. Also, these changes are likely the result of a known (and now resolved) issue with quacking foton files with Matlab.
Leo, Jeff Some charge measurements was done on both ETMs. We found ETMX ESD driver non functional, Betsy fixed it (see 20203) Measurements results are in attachments. For most quadrants we have the same trend as discussed in 20067
The guardian core and cdsutils packages were upgraded today:
After a couple of small issues were ironed out, the guardian machine was rebooted and all nodes are up and running with the new versions:
Notable fixes/features in the new version:
guardian:
cdsutils:
FRS3410. Jenne, Jim, Carlos, Dave
Jenne found that certain digital cameras were not snapshotting correctly. After power cycling the digital video servers and the ITMX spool camera, we tracked the problem down to the "Frame Type" setting in the digital video configuration file. The cameras which fail their tiff snapshotting have this setting set to "Mono12", those which work have "Mono8"
In fact the majority of cameras are set to "Mono8", listing is below.
Question to the digital video experts, what does this setting mean and what have we broken by reverting back to "Mono8"?
A few months ago, Kiwamu and I set some of the images to mono12, because 12 bit images have a slightly better SNR than the 8 bit images. We can switch them all back to mono8, except for the green ITM cameras, which we use for beam position refercences. It might be better if we didn't change those settings (ie keep the ITM green cameras set to mono 12.)
Fewer programs will open the 12 bit images than 8 bit images, but you can open them in python or matlab. Attached is a matlab script for opening the mono12 images, for them what don't want to write their own.
THIS TIME, the fix that is suggested by Richard as a comment lower in the alog 19487 worked:
"powered the unit off, removed the DAC cable, powered the unit on, reattached the DAC cable and all seems to be working.
Note, a trend shows this railed negative at almost 1am last night (Aug 4, 07:47 UTC)
I don't remember the exact time but sometime before ~midnight last night, Sheila and I had found the ETMX ESD driver railed negative, and drove to the end station to fix it. All we did was power cycle the box - no cable plug/unplugging, and it came back for us.
Sorry we didn't log this last night. We left around 12:30am, so the railing that Betsy mentions happened when no one was on site, although we left the guardian request somewhere in a fully-locked state (probably Nom. Low Noise).
We don't see button pushing which would have lead to the rail in the middle of the night last night... see attached 24 hour plot.
In talking to Sheila, she fesses up to having an ETMx ESD neg rail earlier at ~11pm (shown on the plot if you look closely), which they caught and went down to Ex to clear in the same manner as above. They left just before it railed neg again - hence the no-auto-locking from then on.
J. Oberling, P. King
Today we measured the OLTF of the ISS inner loop and the PMC. This was done in response to LLO's recent measurement of the same documented here. Peter has all the TF data and will post it as a comment to this report. For the ISS inner loop, the gain was changed from 6dB to 16dB in the last couple of days, so we measured the TF at 6dB and at 16dB of gain to see how the increased gain changed things. For the PMC we ended up increasing the gain to 22dB (up from 18dB). This brought the UGF to ~7.5 kHz, closer to what we expect from E1200385.
I also had a chance to turn off the ISS without disturbing anything else and calibrate the 2 PDs discussed in alog 20043, and therefore complete the work in WP 5391. The new gain values for the these PDs are as follows:
Attached is the measured pre-modecleaner OLTF. Two values of gain slider were used. The initial one, 18 dB was where it was set to when we started the measurements. To increase the UGF we increased the gain to 22 dB. With the gain slider at 18 dB, the UGF is ~3.56 kHz with a phase margin of 70 deg. With the gain slider at 22 dB, the UGF is 7.7 kHz with a phase margin of 75 deg. We could push the gain a bit higher but that comes at the cost of robustness.
Attached is the first loop OLTF. It should be noted that this measurement was performed whilst Robert and Cheryl were working inside the PSL Enclosure and so the HEPA fans were on (ditto for the PMC measurement). Plots are for the old value of gain slider and for the current value. Currently the UGF is about ~65 kHz with a phase margin of ~25 deg. The measurements are consistent with those taken around the time installation was completed and more recent measurements done by Kiwamu and Sudarshan. We took a high frequency measurement but unfortunately the results don't seem right.
Jim Batch, Carlos Perez The newer faster h1susey computer has been replaced with the more stable original h1susey computer. The h1susetmy model is still running within the 60uS window, but not by much. We will be watching this to see if there are problems that arise over the next week. Also, the h1susetmypi models runs well within it's maximum time, so no problems are anticipated with that model.
I've added the rest of the SUSes to the SUS guardian overview screen such that it is easier to quickly see the state of each SUS guardian (very useful for Tuesdays).
Recall that this screen is found via the GRD drop down from the site map.
Jenne, Nergis, Stefan We hooked up monitoring points for measuring the 9MHz and 45MHz RIN going into the interferometer. Here is the rig: 9MHz: - We inserted a 10dB coupler into the 9MHz cable feeding the EOM. This dropped the drive signal from 4.7Vpkk to 4.5Vpkk - small enough the interferometer didn't care. - It's output we directed into a two-way splitter, and fed both signals into a level 1 mixer. - The output was low-passed through a 10MHz low pass. - This gave us a DC level of 0.195V, and a noise of ~4.9nV/rtHz, resulting into a RIN of 2.5e-8. - We hooked it up to an SR560 (Gain=1e4, AC coupled, band-passed with poles at 300Hz and 30kHz), and stuck it into LSC-EXTRA_AI_1 (IOP-LSC0_MADC2_TP_CH8) - the ADC gain is 16384cts/10V 45MHz: - We used the two remaining spare spigots of the 45MHz distribution rack, and mixed them in a level 3 mixer. - Low-passed at 15MHz, we got a DC level of 0.57V, and a noise level of 120nV/rtHz... - ... resulting in an outrageous RIN of 2e-7/rtHZ - Again into an SR560 (Gain=1e3, AC coupled, band-passed with poles at 300Hz and 30kHz) - and into LSC-EXTRA_AI_2 (IOP-LSC0_MADC2_TP_CH9) Plot 1 shows the RIN measured through the digital system Calibration: LSC-EXTRA_AI_1 (IOP-LSC0_MADC2_TP_CH8): Gain=9.39e-5; p= 1, 728.178 65532 ; z= 300, 30000, 10062, 4973.6 9356.4, 33157, 426840 (dtt notation) Calibration: LSC-EXTRA_AI_2 (IOP-LSC0_MADC2_TP_CH9): Gain=3.21e-4; p= 1, 728.178 65532 ; z= 300, 30000, 10062, 4973.6 9356.4, 33157, 426840 (dtt notation) Note: the AA chasis itself has p= 728.178 65532 ; z= 10062, 4973.6 9356.4, 33157, 426840 (dtt notation) Next Evan locked the interferometer, and we found a coherence of 0.9 between the 45MHz RIN (IOP-LSC0_MADC2_TP_CH9) and ASC_AS_C (IOP-ASC0_MADC6_TP_CH11) - this was oue best monitor for mystery noise.... BINGO We also calibrated OMC_DCPD_A (IOP-LSC0_MADC0_TP_CH12) in Amps (today the whitening filters were off): Calibration:Gain=7.726e-7; p= 7.689, 7.689, 728.178 65532 ; z= 78.912, 90.642, 13700, 17800, 10062, 4973.6 9356.4, 33157, 426840 (dtt notation) The noise level in OMC_DCPD_A was 7e-8mA/rtHz. Shot noise would be 5.7e-8mA/rtHz at 10mA. Using the coherence between OMC_DCPD_A and RF45 RIN we estimated the ransfer function to be about 9e-5 A/RIN per photo diode. (Plot2) This let's us estimate the RF45 RIN contribution: 9e-5 A/RIN * 2e-7RIN/rtHz = 1.8e-8mA/rtHz. Very close to the 1.4mA/rtHz estimated in alog 19856. We are a bit puzzled by the fact that this doesn't seem enough the explain the full elevated noise in DCPD_A: sqrt(1.8^2 + 5.7^2) = 6.0 < 7 (everything x1e-8mA/rtHz). (Plot3) Plot 4 shows the coherence (ignore below 300Hz - the interferometer wasn't completely in low noise mode.
We removed the the 9MHz RIN setup, but left the (cleaner) 45MHz one in place. We also verified that the RIN is bad right out of the frequency multiplier. Is that unit simply broken? if so - can we just get a spare?
For reference, the harmonics generator is specked to have an amplitude noise of −150 dBc/Hz at 100 Hz: https://awiki.ligo-wa.caltech.edu/aLIGO/HarmonicGenerator
The ISS at the output of the IMC won't see RF AM, since it is fundamentally phase modulation. It will change the ratio between carrier and RF sideband strength. However, once the RF sidebands are stripped off by the OMC, we are left with just the fluctuations on the carrier. We can calculate the RIN of the carrier in the presence of RF AM with:
There have been some questions about how to run the HWS code.
The HWS code runs on one of three HWS computers, we have one at each end station and one at the corner station. I have set up a tmux session to run the HWS code constantly at the corner station. If the code is running, the heartbeat will flash on the TCS HWS ITMX/Y medm screens, and the seidel aberrations will update once a second on the HWS ITMX/Y CODE screen. To take a measurement using the HWS, in addition to having thr HWS code running, you also need to turn on the RCX link framegrabber power, the Dalsa 1M60 Camera power, and the Superluminescent diode (SLED) power switched on the HWS medm screen. To increase the lifetime of the SLED and to avoid injecting 1Hz noise into the PEM channels (we are working on filters on the camera power supply to fix this one), we are leaving the HWS hardware off if we are not using it.
If you want to stop or restart the corner station code for some reason, you can ssh into the cornerstation hws computer:
>> ssh -X controls@h1hwsmsr
and attach to the tmux session
>> tmux attach
This webpage (http://www.dayid.org/os/notes/tm.html) has a list of tmux commands. We are running two sessions, one for ITMX and one for ITMY. Go to the relevant session, go to the folder ~/temp, and run the HWS code with the command
>> Run_HWS_H1ITMX (or ITMY....)
Jim and Dave have installed tmux on the end station HWS computers (thanks guys), so the code is running at these computers now too. It is intialized with the command >> Run_HWS_H1ETMX or >>Run_HWS_H1ETMY in ~/temp, after you log into controls@h1hwsey (or h1hwsex).
