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.

Electronics testing.

TMS Cabling

Turns out the 6dBm readback from the FIBR_A broadband PD was due to an oscillation of the noise eater at ~1MHz. Toggling the noise eater servo fixed the problem. Since the normal PLL beat note is at the -7dBm level, we should be able to use this as a noise eater oscillation monitor.

Did an SVN clean up of the slow Controls directory, and an update.  (apparently this happens when svn update fails) Made new bootprojects for all three PLCs.  Restarted the computer, PLCs seem to be running the current version of the code, but I couldn't caget anything on the beckhoff machine (channel not found).  Restarted the EPICS database twice, and now I can caget locally, but I get zero when I can see in the PLC that the channel is not zero. 

Problem solved by renaming the target directory (same effect as deleting it) and starting from scratch with the install scripts)

Now the PFD says it is getting 6 dBm input, this doesn't make any sense so we are headed down the X end. 

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.

Kiwamu, Stefan

We locked the PRMI on the sidebands today. The locks lasted for about 1min at a time. Lock acquisition is still slow, so more work is needed.
The first lock started at UTC 2014 Jan 22, 01:59:42, and lasted until 02:00:25. There were several additional locks after that.
Attached is a large screen shot with all relevant screens.

We managed to get a preliminary OLG measurement for PRCL, the UGF seems to be around 55Hz (plot attached.)
We were not successful with a MICH OLG measurement yet.

Finally, attached is also a plot of error and control signals for the two loops.

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.