Continued checking out cables for electrical shorts and running cables.  Today worked on SUS TMS cables.  Other than observing I had a flip in the wires via the feedthru we were able to say we are happy with the two SUS/BOSEM cables for the TMS.  They are connected at the Cable Bracket & have been screwed together.

Since the cable gets flipped, the pins on the D1000223 (sei-responsible cable) yesterday (pin 13 & 16), are really (pin 1 & 23).  One of these is the shield and the other is a picomotor cable.  We don't want a short with this cable, so tried looking for tight clamps or crimps in the cable.  I didn't find anything other than possibly an issue near the Cable Bracket on the Optics Table.  When I moved the cable around I was able to get rid of the short every once in a while (but it mainly stayed shorted out).  So this may be a problem cable. 

Unfortunately, this is a cable we have run out of.  So we need to either figure out how to fix it, or see if another cable will work in its place. 

Notes:

• Made sure to tighten the set of (4) screws on cable connectors which will connect to Chamber Feedthru (it's been observed that the heads of these screws protrude out & ground out the cable.
• The two SUS Seismically-responsible-cables don't have screws on the Chamber feedhtru connectors (!).

DAQ was restarted for two reasons:

New h1 broadcaster channel list, removed 3 channels added 47 channels for ODC group.

Resync DAQ to h1asc model changes.

The h1fw1 frame writer was down from 15:25 to 15:36 PST for memory upgrade to 72GB.  Frame sizes have not changed yet.

Memory upgrades

Updated the arm inital alignment model and medm screens to include 
a) A threshold for automatic enabling
b) A threshold for stopping the servo - we need this to reject hops to the 10 mode.

asc/common/models/IAL_LOCKIN.mdl
SVN revision 6940

asc/common/medm/ASC_IAL.adl
SVN revision 6941

The EtherCAT chassis 6 in the corner has been installed. The system manager was updated and is running with the new configuration. The code has been added to the PLC but still needs testing. This chassis adds controls for 2 additional VCOs with PLL, a few RF amplifier readbacks and controls for the HAM6 fast shutter.

Pulling cables from electronics racks to VEA.

Back in the fall(2013) we realized we were consuming more LN2 than normal and homed in on CP3 as the culprit. We found that it's vacuum jacket had leaked up to ~1000 microns (1 torr).

After rough pumping down to <10 microns the consumption has fallen off to a more normal rate.

Before pumping the slope was 1.3 percent per day, after pumping; 0.76 per day.

Kyle is presently working around the site with the pumping gear and will pump each a week or more.

(Alexa, Daniel, Sheila)

We just returned from EX and did a few things:

1. Adjusted delay line for remote control
   • toggled switches: 8, 4, 1, 1/8 --> 210 steps
2. Adjusted phase on delay line to 115.3deg. We tried minimizing Q as best we could by adjusting the phase; however, we were not very sucessful since the arm was not staying well aligned
3. Returned the modulation frequency to 24.407079MHz
4. Took an open loop TF of the PDH. The UGF is about 5kHz with a phase margin of 70deg
5. We measured shot and dark noise (data to come...). With ITM misaligned green REFL A PD read 6.2mW with 3V at 30dB gain.
6. Measured an RF AM offset of 25mV at IMON with ITM misaligned. With ITM aligned, the error signal peak-to-peak was 1.9V out of IMON.

Written by Yuta, posted by Koji, while he is waiting for his ligo.org account:
 

In order to get the frequency noise from alignment fluctuation better than few Hz, the X arm should be aligned whithin ~0.02 urad. This requirement could be relieved by adjusting the sideband frequency.

[Motivation]
In a low finesse cavity, PDH signal from HOM adds an offset to the locking point of 00 mode. So, if the cavity alignment fluctuates, HOM content fluctuates and it will be converted into the frequency noise. This frequency noise was estimated for the current Xgreen situation.

[Method]
1. Calulate beam translation dx and tilt dtheta from ETM/ITM misalignments using the following formula;

dx=(R2*(R1-L1)*a2+R1*(R2-L2)*a1)/(R1+R2-L)
dtheta=(-R2*a2+R1*a1)/(R1+R2-L)

where

L1=L*(L-R1)/(2*L-R2-R1)
L2=L*(L-R2)/(2*L-R2-R1)

and a1,2,R1,R2,L is ETM misalignment, ITM misalignment, ETM RoC, ITM RoC, and cavity length.

2. Calculate HOM content upto 1st HOM using the following formula;

U00 power = (1-0.5*(dx/w0)**2-0.5*(dtheta/alpha0)**2)**2
U01 power = np.abs(dx/w0+i*dtheta/alpha0)**2

where w0 is the cavity wasit radius and alpha0 is the divergence angle.
Note that this calculation is only valid for small misalignment (dx < w0 and dtheta < alpha0).

3. Find zero crossing point of PDH signal for each mirror misalignment to get the dependance of zero crossing point on mirror misalignment.

4. Calculate derivative of 3. to get the coefficient for alignment induced frequency shift (in Hz/urad).


The parameters I used are the same as the ones listed in alog #9381, except for L=3994.5m (see alog #9386)

[Result]
1. zerocrossingPDH_sb24_4MHz.png: Upper plot shows the shift of zero crossing point by cavity misalignment. Lower plot shows the coefficient for alignment induced frequency shift.The blue curve is for ETM/ITM misalignment in v-shape (soft-mode-like). The green curve is for ETM/ITM misalignment in //-shape (hard-mode-like) and is valid only for misalignment < ~0.5 urad.

2. zerocrossingPDH_HighFinesse.png: Same plot for ETM transmission of 1%.

3. zerocrossingPDH_sbadjusted.png: Same plot for the adjusted sideband freqeuncy. The sideband frequency was adjusted to the precision of 1% to get minimum frequency noise (the zero crossing of PDH signal from 01 mode right at the 00 resonance).

[Discussion]
The following discussion is valid when the requirement for the frequency noise is few Hz and mirror angular motion is ~0.1 urad.

1. If we don't change anything, DC misalignment should be better than ~0.02 urad.

2. If we had high finesse cavity, requirement for the DC misalignment was ~0.8 urad.

3. If we can adjust the sideband frequency by 1%, the requirement for DC misalignment is relieved by 2 orders of magnitude.

Kitting up parts for OFI

Transitioning to laser safe.

I did the coil gain balancing on the M2 and M3 stages of PRM. Here are the results:

%% M2 stage

H1:SUS-PRM_M2_COILOUTF_UL_GAIN -0.961
H1:SUS-PRM_M2_COILOUTF_LL_GAIN 1.012
H1:SUS-PRM_M2_COILOUTF_UR_GAIN 0.987
H1:SUS-PRM_M2_COILOUTF_LR_GAIN -1.039
 

%% M3 stage

H1:SUS-PRM_M3_COILOUTF_UL_GAIN -0.999
H1:SUS-PRM_M3_COILOUTF_LL_GAIN 0.985
H1:SUS-PRM_M3_COILOUTF_UR_GAIN 1.015
H1:SUS-PRM_M3_COILOUTF_LR_GAIN -1.001
 

I used the same technique as Keita did for BS (see alog 9080), although WFS_REFL_B_LF was used in stead of an oplev because PRM doesn't have its own oplev.. In addition to it, because the WFS signals are not connected to the suspension LOCKINs, I simply used diaggui to check the amplitude of the excitation line. The excitation was introduced by the LOCKIN OSC with an amplitude of 500000 and 200000 counts for the M3 and M2 stages respectively. The frequency was at 4.1 Hz for both cases.

I launched a L2P(Y) transfer function measurement on PRM and BS.

The coil gains for the M2 stage of BS were set back to the ones Keita set on 24th of December (see alog 9079):

• H1:SUS-BS_M2_COILOUTF_UL_GAIN = 1.01
• H1:SUS-BS_M2_COILOUTF_LL_GAIN  = -0.985
• H1:SUS-BS_M2_COILOUTF_UR_GAIN  = -1.015
• H1:SUS-BS_M2_COILOUTF_LR_GAIN  = 0.99

Before I changed these numbers they had been:

• H1:SUS-BS_M2_COILOUTF_UL_GAIN = -1
• H1:SUS-BS_M2_COILOUTF_LL_GAIN  = 1
• H1:SUS-BS_M2_COILOUTF_UR_GAIN  = 1
• H1:SUS-BS_M2_COILOUTF_LR_GAIN  = -1

Therefore all the BS actuators on the M2 stage has now different sign. We should remember this, especially when locking the Michelson. I have no idea of why we kept using these funny +/-1 things instead of the balanced coil gains.

In order to ensure that the ODC bits are sending valid reports, I've visually confirmed the status of each subsystem module mentioned below. The ODC is currently reporting a happily locked mode cleaner and I confirm this is true. The goodness has been going on for a while now (as Stefan and Kiwamu are trying to lock the PRMI), but officially, we can say the goodness has been on-going since Jan 21 2014 6:00pm PST (Jan 22 2014 02:00:00 UTC, GPS 1074391216).

DetChar bonus tasks: 
- Post performance ASDs of all the components mentioned below as a comment. I wanna see what "good" looks like for these systems. 
- We should also be able to use tonight as an average reference ASD for recoloring the IMC_F / IMC_L data in to fake DARM.
- Show me spectra of the coil driver noise monitor channels. Show me what a "normal" coil output voltage ASD is for each of the driver stages. Let me know if there are any DAC saturations.
- For the IMC ODC, trend the H1:IMC-MC2_TRANS_SUM_OUTPUT, H1:IMC-IM4_TRANS_SUM_OUTPUT channels (which feed into ODC bits 10-13). Tell me where they average, and what the peak value is on the ~minute time-scale. Find out from the IO group what the expected power budget is from POWER IN to MC2 TRANS SUM, and from POWER IN to IM4 TRANS SUM, so we can stick that into the [W/W] gain and have these bits' thresholds be calibrated.

During this time there was no excitation on anything mentioned below.

IMC: IMC Locked, IMC WFS control ON, spitting out clean 00 mode light.
     ODC bits all green (0-13), bits 2-9 masked out (see LHO aLOG 9373), summary bit (bit 0) and bit 10 are masked out (why?)

HAM2:
HPI: well-performing, well-aligned to target values. Level 1 isolation filters, position-sensor-only ("Pos") blend filters. 
     ODC bits all green (0-3), but summary bit (bit 0) is masked out (why?).
ISI: well-performing [BLRMS lights are mostly green, with some yellow in upper-left corner], well-aligned to target values. Level 3 isolation filters, with "01_28" blend filters. 
     ODC bits all green (0-4), but summary bit (bit 0) is masked out (why?).
MC1: IMC locked, IMC WFS control ON, locally damped and aligned
     ODC bits all green (0-7) are green, but summary bit (bit 0) is masked out (why?).
MC3: IMC locked, IMC WFS control ON, locally damped and aligned
     ODC bits all green (0-7) are green, but summary bit (bit 0) is masked out (why?).

HAM3:
HPI: well-performing, well-aligned to target values. Level 1 isolation filters, position-sensor-only ("Pos") blend filters. 
     ODC bits all green (0-3), but summary bit (bit 0) is masked out (why?).
ISI: well-performing [BLRMS lights are mostly green, with some yellow in upper-left corner], well-aligned to target values. Level 3 isolation filters, with "01_28" blend filters. 
     ODC bits all green (0-4), but summary bit (bit 0) is masked out (why?).
MC2: IMC locked, IMC WFS control ON, locally damped and aligned
     ODC bits all green (0-7) are green, but summary bit (bit 0) is masked out (why?).


I don't imagine I'll get the chance tonight, but if possible I may put these components in various *bad* states tomorrow, to check that the ODC properly reports as such.