Scott L. Ed P. Chris S. Relocated lights and equipment to next section of tube, single door to X-1-7 double doors. Refilled D I water tank and cleaned 15 meters of tube this afternoon. Tube pressures monitored by control room operator during cleaning operations.
I added a simple script to /opt/rtcds/userapps/release/isi/h1/scripts/ called BRSswitch.py
You can use this to turn ON or OFF the BRS sensor correction. All this does is change the X2 and X3 matrix values in the STS2CART matrix so that when it is ON the the BRS signal is subtracted, and when it is OFF the signal stops there.
To run this script, navigate to /opt/rtcds/userapps/release/isi/h1/scripts/
Then:
python BRSswitch.py ON
or
python BRSswitch.py OFF
The purpose of this script is to eliminate confusion over how to turn it on or off and to allow for a method that can adapt to changes in the BRS system. As of now this script is specific to this BRS at EX, but can easily be made more general when/if there are more here or at LLO.
J. Kissel, F. Clara, E. Hall The commissioning vanguard had discovered that a portion of the ITMX M0 Top Driver's Binary Input/Output (BIO), which is control of the low-pass and test/coil enable switches, was malfunctioning a few days ago (see LHO aLOG 17449). This afternoon, Fil, Evan, and I ventured into the CDS highbay to diagnose the problem. After a cable-to-cable swap at the coil driver between ITMX M0 F1F2F3SD BIO cables and the ITMY R0F1F2F3SD BIO cables, and cycling both suspensions' top mass digital control and readbacks, we identified that *one* bit (the F1 bit) of the ITMX M0 F1F2F3SD BIO remained stuck (with the otherwise functional ITMY cables). This made us suspicious of the BIO chassis. However, due to time constraints, we couldn't diagnose further. Instead, we restored the nominal configuration -- and this FIXED the problem. Thus, happily, the problem is gone and all of ITMX driver channels can switch as expected, but, sadly, we don't know why our cable Chinese fire drill fixed the problem. ----------- Other details: Follow along using pgs 8 through 14 of D1100022 where the BIO connections happen. Remember that the top mass cabling -- even through the SUS have 6 OSEMs on the main and reaction chain -- is grouped in groups of four OSEMs. For a given QUAD, the break down is Set 1: M0F1 M0F2 M0F3 M0SD Set 2: M0LF M0RT R0LF R0RT Set 3: R0F1 R0F2 R0F3 R0SD thanks to the mechanical arrangement of the cabling in vacuum (see T1100327). What we saw initially: When we requested to switch the M0 "coil driver" (the main chain uses one-and-a-half top drivers) filter state request to go from State 1 to 2, it switched only the M0F1F2F3SD set, and it switched the test/coil enable bits instead of the filter state. This was reproducible over many attempts. All other functionality -- switching ITMX R0 state and test/coil enable was functional -- indicating a problem only with this cable/OSEM set. We confirmed that all cables were connected and secured screwed in as designed in D1100022 before doing anything. We swapped the cables at the coil driver, namely (on pg 9 of D1100022) we exchanged cables CAB_L1:SUS_ITMX-102 and CAB_L1:SUS_ITMX-103 in the SUS-C5-37C top driver position/chassis with the CAB_L1:SUS_ITMY-100 and CAB_L1:SUS_ITMY-101 in the SUS-C5-39C top driver position/chassis. With all cables connected in this fashion, the ITMY M0 and R0 BIO was entirely functional bhaving as expected. The ITMX M0 and R0 BIO was *more* functional, in that switching the filter state request actually switched the filter, EXCEPT that the F1 LP bit remained stuck. We then quickly assumed that this series of events was symptomatic of a problem with the ITMX BIO chassis, but we ran out of time to create enough test scenarios that we're confident. Running out of time, we re-exchanged the cabling, restoring everything to how it was, and to how its laid out in D1100022. However, after toggling the ITMX and ITMY BIO switches again, to confirm that functionality had been restored to ITMY and the same broken behavior was present on ITMX, we found that all problems had been fixed. YUCK. Well, YAY, but... YUCK. We'll keep an eye on this BIO chassis to see if it goes screwy again, but for now we consider the problem (dis-satisfyingly) fixed.
The BRS software was restarted at ~12:30PM. The device is currently disabled. The INMON signal is very clipped/saturated. The wind speed at EX is currently 20mph+. We still think there is a fault with the equipment. Krishna should be contacted.
Here is my contribution to the range worsening during the last long lock, following up on Lisa's and Sheila's entries.
Basically, my conclusion is that high wind affects the angular stability of the interferometer, the noise gets very non stationary (as visible from the summary page spectrogram and as it was observed in the past).
I loaded all 4 hours of lock data, computed the band-limited RMS of DARM in the 100-200 hz region and correlate it with angular signals (both local sensors and WFS/QPD). For the first couples of hours the noise is lower and more stationary (still, there is some fluctuation that is correlated with angular motion). The first attached plot shows the trend of the BLRMS during the whole lock, together with the reconstruction using the WFS and QPD signals. The second and third plots are zooms into a quiet and a not so quiet time periods.
The final attachment is the usual ranking of the signals that contribute most to the fit. AS_B_45_YAW is the clear winner, both I and Q.
P.S. The second attachment is broken and I can't remove it, ignore it.
Looking at the DARM spectrogram, there are few lines that wander around in frequency over long periods of time:
The attache spectrograms show all these lines. I wrote I simple peak identification script (attached) to extract the frequency as a function of time. It's not perfect, so the traces are kind of noisy, but they should be good enough to try to correlate them with some slow channels (power, temperature, angular drifts, etc.). Unfortunately it's too painful to access remote data for me right now, so I'll let this analysis to somebody else...
Attached a txt file with the frequency of the lines a function of time (firt column) measured in seconds from GPS time 1111224616
Sheila and Dan made this nice plot to show how the range degradation during the lock the other night was well correlated with the wind going from 0 to 20 mph. This plot has the calibrated DARM spectrum, zoomed in two regions (10 mHz - 1 Hz) and (20 - 200 Hz), showing how the excess of noise in the low frequency region is up-converted in band. Here we had the "nominal no wind" 45 mHz blend for the ISI, as there was no wind when we left.
Here are this week's PSL DBB/ISS scans.
Now the whole initial alingment procedure can be done using ALIGN_IFO, which will hopefully reduce confusion and the need to init different guardians. We have replaced the ISC DOF with the new diagnostic guardian on the ISC overview screen.
Also, the states which used to be called SRM ALIGN and OFFLOAD SRM ALIGN are now SRC ALIGN ect since they are really aligning both SR2 and SRM. Nutsinee and Ed are working on updating the procedure for operators.
I've edited the operator WIki instructions to reflect this change. If anyone catches something that I missed while trying to align/lock please let me know. -E
J. Kissel Following the installation of the front-end infrastructure for calibration lines and optical gain compensation for the DELTA L EXTERNAL calibration (see LHO aLOGs 17114, 17179, and ), I've modified the CAL_CS_OVERVIEW.adl MEDM screen, and created newer lower-level screens for the details of the generation of calibration lines and the computation of the optical compensation (i.e. the "gamma" factor). See attached screen shots. Also, for the record I've started to put together documentation of this stuff, check out T1500121. Now that the MEDM interface is established, we'll begin filling out the parameters of the infrastructure, and finally get some calibration lines in the DELTA_L_EXTERNAL spectra. Stay tuned!
model restarts logged for Tue 24/Mar/2015
2015_03_24 10:15 h1asc
2015_03_24 12:22 h1sushtts
2015_03_24 12:44 h1broadcast0
2015_03_24 12:44 h1dc0
2015_03_24 12:44 h1fw0
2015_03_24 12:44 h1fw1
2015_03_24 12:44 h1nds0
2015_03_24 12:44 h1nds1
no unexpected restarts. Maintenance day: asc and sushtts cleanup, Beckhoff changes, associated DAQ restart.
Laura, Josh, Andy, Joe, Detchar
We took a look at the 28 Mpc lock on 24th March to see if there was any evidence of arches that we have seen previously at LLO (for example LLO alog 17090).
The first attachement shows a histogram of the rate of glitches (omicron triggers) binned by the value of IMC-F at the same time. The plot looks pretty Gaussian, except for a few bins specifically between IMC-F values of -37.5 to -41.7 and -45.8 and -50. Between these values we see evidence of arches in DARM. The second attachment is a pdf file showing the arches in DARM lining up with values of IMC-F in the second bin. Here are links to many spectograms confirming the arches in the IMC-F bins outlined (spectrograms for IMC-F bin -37.5 to -41.7 / spectrograms for IMC-F bin -45.8 to -50). Each spectrogram time corresponds to a glitch as seen by omicron.
LLO has dramatically reduced the effect of these arches, see LLO alog 17191.
Also the value IMC-F has when these arches appear in DARM seems to drift, i.e. there does not appear to be a specific value of IMC-F which produces the arches (this is evident in the second attachement). This is not what we have seen at LLO, does anyone know what could be causing this?
Andy, Laura, DMac Here's a look at one of the whistles, and the putative cause as an RF beatnote with IMC-F. The idea is that the IMC VCO is beating against another (nearly) fixed RF oscillator, and that's what we see in DARM. In that case, the frequency track should look like the difference between IMC-F (calibrated in kHz) with some fixed value. In fact, the whistle clearly seems to match half of the frequency difference (black trace) rather than the full difference (red trace). Perhaps this hints at the type of coupling? Here, the fixed value is about -46.9 kHz (relative to whatever IMC-F's reference is), but we think this drifts during the lock. We can look in detail at some more of these, and find out.
Why not use the frequency readbacks of the oscillators and VCOs rather than the somewhat arbitrary IMC_F? The radbacks are only once per second, but they can still tell you which units are close in frequency.
I'd be happy to look at the readbacks, as long as they are recorded and available offsite. Can tell me what the channel names are?
I put some notes about these channels in the summary of the ISC F2F last fall. ("RF crosstalk" section)
The channel names and labels are in the attached code. There, I look at the time around the event that Andy sent around to the DetChar mailing list yesterday. It's not totally obvious what VCO is beating against the PSL VCO, the closest one is ALS COMM, but it's about 400kHz away at the time of the glitch.
The first plot shows the value of all the corner station VCOs in the ten minutes around the glitch, the second plot is a zoom around the PSL VCO frequency.
It seems like H1:SYS-TIMING_C_FO_A_PORT_11_SLAVE_CFC_FREQUENCY_5, which Dan has labeled as the PSL readback, is the best candidate. This seems to be roughly equal to (1/2)*IMC-F + 79.225 MHz, delayed by one second (i.e. I can line those two things up and they overlap). Is the one second delay due to some loop or is it just a quirk of the recording system? The whistles occur whenever this readback crosses 79.2 MHz, which is the fixed fiber AOM frequency from the talk referenced in Dan's notes from above.
Kiwamu, Dan, Daniel, Elli
Today we locked SRMI using H1:LSC-REFLAIR_A_RF45_I_MON for SRCL and H1:LSC-ASAIR_A_RF45_Q_MON for MICH. This configuration is more stable than previous locks where we were locking MICH to ASAIR_A_LF and it was clearer where the locking point is. We retook transfer function of AUX laser and carrier beatnote at OMC_REFL path against AUX laser offfset with and without beam clipping. MICH offset was 20 counts of normalised H1:LSC-ASAIR_A_RF45_Q_MON so we were locked very close to the MICH dark fringe. The raw data is available in /ligo/home/controls/elli.king/SRClengthdata.
I have unlocked SRMI and I am leaving the guardians in the down state. We changed the whitening gain on REFL_A_RF45 for the measurement but I have set it back to zero and have reset the dark offsets H1:LSC-REFLAIR_A_RF45_I_OFFSET H1:LSC-REFLAIR_A_RF45_Q_OFFSET to tTuesday morning's values.
Kiwamu, Lisa, Sheila, Dan, Evan
A preliminary measurement shows that we are not quite limited by intensity noise between 50 Hz and 1 kHz, but we need to take another round of measurements in order to say anything conclusive.
This was taken before switching to the ETMY ESD and before feedforward subtraction of MICH.
This result is roughly consistent with Gabriele's conclusion that the intensity noise coupling above 100 Hz is a factor of a few below the total DARM noise.
Kiwamu wired up the extra LSC DAC channel (LSC-EXTRA_AO_2) to drive the excitation point of the ISS second loop (PSL-ISS_TRANSFER2_INJ).
Then we drove a swept sine using this DAC channel and looked at the transfer function IMC-IM4_TRANS_SUM → LSC-DARM_IN1. The data aren't great, since it seems hard to get good coherence around 120 Hz and below 50 Hz. I've attached a calibrated version of the transfer function. IM4 trans is nominally calibrated into microwatts, and the conversion to DARM_IN1 from OMC-DCPD_SUM for this lock is 5.4×10−7 ct/mA (the DCPD_SUM channel is nominally calibrated into milliamps). The transfer function looks very feature-rich, and we would greatly benefit from a more careful measurement.
A good time to look at IM4 during this lock configuration is 2015-03-24 05:08:20 to 05:10:20 UTC. Using the ASD of the IM4 sum power during this time, one can use the above TF to propagate it forward to DCPD sum photocurrent. This can be propagated foward to DARM noise using the coefficient 4.6×10−13 m/mA. I've undone the DARM pole, but not the DARM loop (since our measurement is more or less above the loop UGF).
Few months ago I did some simulations to understand the large coupling of intensity noise at Livingston. Details are in LLO alog 13768, 13963, 13985, 14091 and 14188.
At Livinston the dominant cause of increased coupling was the mismatch of the lenses in the two ITMs. At LHO the shape of the coupling seems different. It is very similar to the simulation result I got with a MICH offset, see the linked alog entry and the attached plot.
