Low temp baking RGA on BSC6 during maintenance periods -> Also, temporarily shut off instrument air to X-mid VEA while re-routing copper line
J. Oberling, P. King
Summary
We tweaked the beam alignment into the PMC in the horizontal direction using both mirrors M06 and M07. Final PMC transmitted power was 22.3 W with a visibility of 91.5%. This did not recover the FSS RevCav TPD voltage, so we transitioned to realigning the FSS RefCav. We found the beam clipped between mirror M26 and the 21.5MHz EOM. We corrected this using mirror M25 and the used mirror M26 and the top input periscope mirror to tweak the alignment into the FSS RefCav. Final RefCav TPD was 1.37V. Still unclear where the drift in the RefCav TPD is coming from.
Details
We measured the power before the FSS AOM, after the AOM (single pass), and at the base of the RefCav input periscope. Peter also measured the power between M34 and L05 (after the 35W pickoff for the DBB)
According to Peter this is all reasonable, so we moved on to the PMC. Motive here is to make the reflected beam shape more concentric, thereby improving the beam alignment into the PMC, and increasing the transmitted power (and hopefully the FSS RefCav TPD in the process). We tweaked the horizontal alignment using mirrors M06 and M07, and ended with a final transmitted power of 22.3 W, an improvement of about 0.3 W. We then had to adjust the alignment into the PMC Refl PD, PD03, by adjusting mirror M20 and thin film polarizer TFP03 (to keep the unlocked voltage reading of the PD at ~-1.5V).
This gives a PMC visibility of 91.5%. Unfortunately this did not significantly increase the FSS RefCav TPD, so it seems we really do have an alignment issue.
This first thing we did was to check the beam position on various irises in the beam path. We found the beam clipping on the iris high and to the west between M26 and the 21.5 MHz EOM. We corrected this with M25, and then used M26 and the top periscope mirror to tweak the RefCav TPD. While a small bit of lateral adjustment was needed, the majority of the adjustment was to pitch. The final TPD voltage was 1.37 V, and the RefCav Refl PD read 0.060 V while the RefCav was locked. Unfortunately we are still unclear where the RefCav drift is coming from...
Jason, Kiwamu (WP 5199)
PR3 oplev is now back to functional.
As reported in the last week (alog 18246), PR3 was found to be not functional. This morning we took a look at the PR3 oplev and found that the beam had been clipped. We fixed it by steering the launcher telescope and recalibrtated both pit and yaw signals.
[Unclipping]
Looking at the returning beam, we found that the beam was largely clipped on the west side and its bottom side. Apparently this was causing the nonideal cross-coupled behavior as reported in alog 18246. We could not identify what object was occulting the returning beam, but according to Jason, it could be somewhere around the viewport for the return beam. We decided to steer the launcher telescope to unclip the beam. The unclipping went smooth and no major issue was found. Since we moved the beam toward the East, we had to recenter the QPD stage afterwards. The beam is now about 1 cm away from the clipping edge, meaning we can move PR3 by several 100 urads until clipped. This is good enough.
After the unclipping, Jason checked the beam shape and confirmed that there was no sign of clipping. We also briefly checked the responsivity of each segment by placing the beam on each segment by steering PR3. This convinced us that the responsivity is almost the same among the four segments. We physicallyt locked the launcher telescope as a part of the normal procedure so that it is not going to move.
[Recalibration]
After the unclipping, I recalibrated the oplev. Here is a summary of the new calibration:
| old calibration [urad/cnts] | new calibration [urad/cnts] | |
| PR3 pit | 38.86 | 26.90 |
| PR3 yaw | 38.53 | 29.60 |
I also updated the SDF accordingly. The data and fitting code are attached as a zip file.
One thing I found during the calibration is that there is still some cross-coupling between pitch and yaw at 10% level. I don't think this is a big issue, but those who use PR3 oplev should be aware of it. I am not sure what part of it is causing the cross-coupling.
SudarshanK, DaveB, JeffK,
We made changes to psl iss model to include the DC signal from the eight photodiodes on the array. These DC signals are acquired before the whitening in the transimpedance amplifier. This psliss model restart didnot affect the psl itself, which we were afraid it might. Good to know for future restartts. The DAC restart was made around 11:30 local time. These 8 additional channels will be available to trend via epics channel. These signals are also used to normalize the ISS PD signals to obtain the RPN. The channel names are as follows:
H1:PSL-ISS_SECONDLOOP_PD1_DC
........
H1:PSL-ISS_SECONDLOOP_PD8_DC
Attached is the new front end model that includes the changes.
Had to add H1:TCS-ITMX_HWS_POSITIONDETECTOR2SUM and H1:TCS-ITMY_HWS_POSITIONDETECTOR2SUM to the exclude list. Looks like we may need to change the HartmannSensor library again at some point to make these read only. They change (rapidly) now that the gain is no longer 0. Added 242 channels. Removed 45 channels.
Daniel, Elli, Patrick, Nutsinee I changed the OPC_PROP_RIGHTS of PostionDetector2SUMGain from 1 (read only) to 3 (read/write) in the HartmannSensor library code. I checked the change into SVN. I updated from source, recompiled and restarted PLC3 on h1ecatc1. Yesterday Nutsinee made a code change to PLC1 on h1ecatc1 and checked it into SVN. This was to fix the picomotor labels. I updated from source, recompiled and restarted PLC1 on h1ecatc1. I restarted the EPICS IOC on h1ecatc1. I did caputs to H1:TCS-ITMX_HWS_POSITIONDETECTOR2SUMGAIN and H1:TCS-ITMY_HWS_POSITIONDETECTOR2SUMGAIN to change them from 0 to 1. WP 5199, 5200
Did before its expected biweekly crash. Burtrestored to 10:10 am.
Well, it still crashed anyway. Restarted the computer again. This time the IOC failed to start. The IOC reports 'Failed to start', 'Failed to open ADS ports' for each PLC.
Logged into h1ecatx1. Opened the LIGO TwinCAT Target Configuration. Selected h1ecatx1, PLC1, PLC2, PLC3. Hit Restart EPICS database. This time it worked. Burtrestored again to 10:10 am.
The ETMX ESD driver medm screen 'Active light' has been flickering when it is OFF. To fix this issue, I pushed this lower threshold to +/-325 from +/-200.
I also changed this in SYS_DIAG.
While talking about SYS_DIAG, I have made a wiki page for troubleshooting the usermessages that it will bring up. This is a page mainly to help operators find the source of the problem and how to resolve it.
It can be found here: https://lhocds.ligo-wa.caltech.edu/wiki/SYS_DIAG%20Guardian
My usual image of ASD and coherence between the three corner station STS2s.
Great coherence pretty much on everyone from 1 hz down to .002hz except HAM2 Y. HAM2 X is better but still not as good as Z or the other instruments. With this signal size, there is no excuse for poor coherence. I'm going to move the HAM2 sensor back to the BierGarten for one final check.
Sheila, Kiwamu, Evan, Stefan
Today we first recommissioned the QPD transmon to ITM loops.
- We set the transmon QPD offsets to zero at 10W input power and engaged all four loops. This brought the recycling gain up to about 40 consistently.
- The optimal QPD offset seems to slightly depend on input power, which is why we set them at 10W for now.
- We want to see whether this type of QPD loop is consistent from day to day before we physically center them.
- The loops are now engaged at low bandwidth in the script.
- We haven't designed propper plant inversion and roll-off filters for the loops..
Next we went to low noise and re-examined the SRCL coupling For some reason the SRCL coupling gave no subtraction at all - just some noise reshaping. (It could be due to our QPD-to-ITM loop.)
- We remeasured the coupling by i) first driving SRC_EXC, and measuring the TF from SRCL_OUT to DARM_IN1, and ii) SRCFF to DARM_IN1. iii) the ratio i/ii should be the desired FF path.
- We first hand-fitted the TF:
poles: 0,0, 800 (Q=2) zeros: 32 (Q=7) , -180
or
zpk([2.28571+i*31.9183;2.28571-i*31.9183;-180],[0;0;200+i*774.597;200-i*774.597],1,"n")gain(5)
- Note the negative frequency zero - a clear indication that we have two coupling paths. We should just design two separate FF path - this would allow for easy individual tuning of low and high frequency feed-forward.
- Unfortunately an earthquake struck during the filter designing, so we couldn't test them.
Related alog: https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=18269
Summary:
During long lock stretches where POPAIR_B_RF90 slowly drifts up, SR3 pitches up, and this seems to be a real PIT motion, not some bogus signal, even though SR3 is not touched by ASC nor LSC.
Turning SR3 back to the original angle when in lock doesn't restore POP90 (see the above alog by Evan), so this PIT is not the cause of POP90 drift, but rather the result of something else affecting both SR3 and POP90.
The time constant of SR3 drifting in-lock is much slower than the time constant of SR3 getting back after lock loss as was pointed out by Evan. The former looks as if it could be the mirror heating, and the latter could be the wire cooling.
The power buildup in the SRC itself is about 120mW or so according to Kiwamu and probably is not enough to cause wire heating by some scattered light.
Based on these, one possibility that Stefan came up with is that the heating of the ITMs changes the amount of higher order mode spilling over on the SR3 wires, causing PIT. Since wire heating is much quicker than the mirror, the time constant is equial to that of the mirror. Once the lock is lost, the power is lost immediately, and the cooling is determined by the wire alone.
We could play with TCS during a long lock to see how POP90 responds, and/or scan OMC to see the mode change during a long RF lock.
Details:
The two plots show the same set of signals. The first one is from last night and the second one is when Evan changed SR3 PIT manually while in lock.
If you look at POP90 (ch2), SR3 OPLEV PIT (Ch6) and SR3 M3 witness BOSEM PIT signal (ch9) in the first plot, they are almost perfectly correlated, and in this case SR3 moved by 0.7 urad. The fact that the motion is seen by oplev and bosem suggests that this is real. Also, if the oplev signal is caused by e.g. some scattered light caught by oplev, the oplev sum (ch.8) should change at least 2% over the lock stretch, but in reality it changed by less than 0.2%.
SR2 PIT (Ch. 13) and SRM YAW (Ch.12) are also coherent with POP90.
SR2 PIT should be the result of ASC feeding back to SR2. In the second plot, when Evan turned SR3 back, SR2 also moved back.
SRM YAW might be the similar effect as SR3.
How about using the SR3 oplev as a reference and feed back to the mirror to hold alignment as the mirror pitches forward? It might serve to obtain longer locks during which you could tune the TCS to reduce this effect. At present the SR3 oplev does not glitch and can be used during lock. It has less than 0.01 microrads in pitch drift over 1000 seconds as shown in the LLO alog 18097. The mirror motion and microseismic motion are also clearly visible above the noise floor.
Maybe it was not clear, but the point is that the SR3 motion itself isn't probably a serious problem, but the differential heating of ITMs might be, causing something funny in SRC, eventually causing the IFO to unlock.
SudarshanK, DarkhanT
We introduced two Pcal lines at 240 Hz and 310 Hz on photon calibrator at Y end. The Pcal lines are about a factor of 10 above the DARM sensitivity at those frequencies. We will look into any changes in the amplitude and phase of these lines to determine the the position of cavity pole frequency. The cavity-pole has been observed at frequencies listed in alog LHO #18360.
Since the pole frequency is at about 300 Hz, it would be useful to have a high frequency line, for example at about 1 kHz. This will allow a better reconstruction of the pole frequency.
If you haven't already, I recommend also putting a notch in the DARM loop at 310 Hz. That way any phase change that occurs at 310 Hz in DARM should be a direct measurement of changes in the sensing phase (which would presumably come from a chang in cavity pole). I probably would have gone a little higher with the 2nd line, closer to 400 Hz. Why did you choose what you did?
Gabriele, We also have a permanent Pcal line at around 540 Hz. We thought it should be enough. Is there any advantage of going close to1 KHz?
Peter, I will have to talk to Jeff about putting a notch on the DARM loop, I am not sure how to go about it. Regarding the choice of 240 Hz and 310 Hz, knowing we already had one line at around 540 Hz we picked a pair of line between one of the non-vetoed frequency band of pulsars. We could easily shift the second line to 400 Hz.
Larry Price did an analysis of just this situation, i.e. at what frequencies should you measure the transfer function to most optimally extract the features in the frequency response. His analysis showed that the most optimal place is at the feature itself. In other words, the best place to put your calibration line to most efficiently measure the cavity pole is at the expected cavity pole frequency. See: LIGO-G1400084
In light of this optimal, Fisher-matrix-based approach, Kiwamu and I have installed a notch in DARM at 322.1 Hz (actually an 80 dB elliptic bandstop from 321 Hz to 323 Hz). The goal is to inject a calibration line digitally into DARM control, so that we can use an LSC lock-in to demodulate the line.
We have set up LSC oscillator #3 to take OMC DC and demodulate it at 322 Hz. Both I and Q have 4th order butterworth low-pass filters. The lock-in output drives ETMX and ETMY differentially. The lock-in drive is currently 0 ct. It has not been set yet.
Better check the assumptions here. Doesn't Larry's result assume an open-loop measurement, white actuator strength, and white measurement noise (none of which holds in this case)?
Chris,
Thank you for pointing it out. We also noticed that the assumptions were not quite valid in our case. On the other hand, Larry's analysis still gives us a good idea of what frequency we should excite. According to his Fisher matrix analysis, the measured transfer coefficient exhibits a maximum response to change in the cavity pole frequency when the excitation is at the exact pole frequency. This led us to a frequency at around 322 Hz. If you take the spectral shape of sensor noise (or DARM residual) and the actuator transfer function into account, probably a slight lower frequency than the current choice may be better, but since we wanted to have a notch in DARM far from the UGF, we chose it to be close to the cavity pole.
Last week we put the EY HWS on it's own separate power supply to see if this would reduce the 57Hz coupling of the HWS into DARM. This workes. When the EY HWS is on, we see no coupling into DARM at 57Hz. (See attached sprectum.) EX is still on the shared power supply, and the 57Hz line is clearly present. The current setup at EY is only as temporary setup. It looks like we should permanantly move all the HWS onto their own power supplies.
On Sunday evening Elli and Nutsinee logged another PSL trip here. Taking trends over this time shows that again the chillers appear to not be bringing down the PSL (first attachment). I've also attached trends over the same time period of all the flow rates: diode and crystal chillers, front end, HPO heads, and power meters. All these flow rates are where they are supposed to be. The third attachment shows all the interlock signals we capture. Only the H1:PSL-IL_OK trips, all other interlock signals indicate no problems.
Rick covered the PSL trip early Sunday morning in alog 18346.
One thing to consider is that the EtherCAT safety terminals go to their nominal safe position, if communication is interrupted. Assuming that the safe state of the terminal corresponds to the tripped state, any communication error between the safety PLC and any of its safety terminals can trigger a PSL shutdown. Maybe check the system for lost frames?