Varying the DARM offset by a factor of 2 has no effect on the unexplained noise above 70 Hz.
Nominally we run with 20 mA of DCPD sum current, which (with an optical gain of 3.2 mA/pm) corresponds to a DARM offset of 13 pm. I took quiet data (15 minutes at a time) with sum currents varying from 10 to 40 mA, which corresponds to DARM offsets from 9 to 18 pm.
Thanks to the automatic gain scaling that Dan and Stefan installed before O1, no manual gain adjustment is needed either for the DARM loop or the calibrated freerunning channels. At each offset, I remeasured the DARM OLTF just to be sure.
I did not adjust the SRCL feedforward during this test, and indeed the coherence below 70 Hz between DARM and the SRCL control signal is increased at DARM offsets other than 13 pm. At 40 mA sum current, the coherence is >0.3 from 25 to 40 Hz. Therefore, the excess noise below 70 Hz during this test is due almost certainly to the SRCL feedforward becoming mistuned.
also true for the opposite sign of the offset?
Does the SRCL or MICH noise change during the DARM offset changes?
As part of the locking sequence, we switch the sensor for the SRM yaw loop from AS B 36I to a combination of AS B 36I and AS A 36I. This is necessary because pure AS B 36I is not a good sensor for SRM alignment at 20+ W of PSL power. Conversely, the combination of A and B is a slightly inferior sensor for SRM alignment at 2 W; one can see that POP90 increases slightly after switching.
So far, we've been doing this switch as part of the 2 W ASC engagement sequence, which (under normal conditions) occurs five minutes or so before increasing the power to 20+ W. However, over the past week, this switch seems to make the interferometer less stable, and tonight alone has caused two lock losses in a row.
Therefore, I moved this sensor switch later, so that it occurs just before increasing the PSL power. So far it's worked twice in a row.
1500 -1520 hrs. local -> To and from Y-mid Next over-fill to be Monday, Feb. 8th before 4:00 pm
Started my shift with the IFO locked at NLN for the first ~2.5 hours. After an EQ knocked us out, this was followed by another ~1.5 hour lock. This was lost due to commissioning efforts. Since then, we have been struggling a bit to get past ENGAGE_ASC. There have been several largish spikes (~1 um/s) in the 0.03-0.1 Hz seismic plot, but only at EY. Winds are gusting to 30 mph and microseism is trending down. Evan and I aren't sure what could be causing these spikes, maybe it is wind. The spikes seem larger than I am used to seeing for winds in this range.
I spent some time this evening measuring OLTFs of our beamsplitter loops and the SRC pointing loops. We might find it helpful to refer back to these measurements when trying to reconstruct the ASC later.
As a reminder, the beamsplitter loops the 36 MHz AS WFS. The SRC pointing loops use the ASC QPD as a sensor, and feed signal to both SR2 and SRM (in such a way as to be decoupled from the 36 MHz SRM loop).
The beamsplitter OLTFs seem pretty straightforward; the UGFs are about 2 Hz for pitch and 3 Hz for yaw.
The SRC pointing loops seem to show complex plant dynamics, so it is difficult to quote a single UGF. There are UGFs ranging from 0.5 Hz to 3 Hz or so. Presumably another UGF in each loop exists at some frequency below the plant dynamics, as with the differential hard loops.
Between Jenne and me, I believe we have either OLTF measurements or step response measurements for all the ASC loops except the four soft loops.
Our first lock in several days was short lived. Apparently mother nature had other plans. 5.5 EQ near Fiji.
Attached are plots of the ETM charge measurements Betsy took earlier this week.
Carlos, Jim, Dave, Aidan:
Carlos installed an Ubuntu14 boot drive in the h1hwsey computer this afternoon. The old Ubuntu10 HDD was left loose in one of the unused SATA bays if we need to go back to the old OS.
This system is now ready for Aidan and the TCS team to test their latest HWS software. The controls account is setup on this machine, and /data is mounted from h1hwsmsr.
BTW: The DAQ EDCU is running RED because it is not connecting to the missing ETMY HWS channels.
We've finally gotten to NomLowNoise for the first time in days, which is great.
I was poking through SDFs in case we're ready to leave the IFO locked overnight, and there were a bunch on TCSCS from Team TCS's work this week. I have accepted all of them into the Observe.snap, but I attach the differences here just in case.
Activity Log: All Times in UTC (PT) 15:15 (07:15) Chris – Beam tube sealing ~ 100 to 150 yards from End-X 17:06 (09:06) Reset H1SUSETMY Timing error 17:24 (09:24) Alastair & Nutsinee – Going to IO table near HAM4. 17:26 (09:26) Hugh – Doing Guardian restarts WP #5723 18:06 (10:06) Kyle – Going to Y-Arm compressor room 19:08 (11:08) Alastair & Nutsinee – Out of the LVEA 19:43 (11:43) Ken (K&S Electrical) – Going to Y-Arm compressor room 20:15 (12:15) Kyle – Back from Y-Arm 20:20 (12:20) Ken – Back from Y-Arm 20:41 (12:41) Nutsinee – Going to check HWS in the LVEA 21:12 (13:12) Jim & Carlos – Going to check HWS computer at End-Y 21:28 (13:29) Kyle – Going out to Y-Arm compressor room 21:40 (13:40) Jim & Carlos – Back from End-Y 22:29 (14:29) Carlos – Going to End-Y to swap hard drive on HWS computer 23:47 (15:47) Kyle – Back from End-Y 23:57 (15:57) Locked at NOMINAL_LOW_NOISE 00:00 (16:00) Turn over to Travis End of Shift Summary: Title: 02/05/2015, Day Shift 16:00 – 00:00 (08:00 – 16:00) All times in UTC (PT) Support: Kiwamu, Jim, Masayunki, Jenne, Jim W. Incoming Operator: Travis Shift Detail Summary: After an initial alignment, spent most of the morning trying to relock. Still losing lock at DRMI_LOCKED. Kiwamu looking into the problem, found the SR3 Cage Servo was noisy, which may be causing the lock loss problems. About this time, there was a mag6.4 earthquake in Taiwan, with an R-Wave velocity of 5.3um/s. The seismic signal rang up to ~ 3.0um/s. Put the IFO into down until things settle down. After seismic rang down from EQ tried relocking. Had to tune MITCH_DARK. All other alignments were OK. Relocked at NOMINAL_LOW_NOISE. Turnover to Travis and the commissioners.
Moved controller to permanent location and cut the HV pump cable to length (6' extra down from 120' extra). Opted to install a new controller-end HV connector as opposed to making a butt splice. For reasons that I cannot explain, following the instructions seems to have helped! Time will tell if my connector job can survive the 7100 volt day-in day-out. The controller dust cover doesn't fit and will need to be modified and the AC pwr cord is too short (using extension cord for now). Will "tweek" these two issues and move on to the X2-8 flavor next week.
This A-Log will cover the past 2 weeks. The crew cleaned 385 meters of tube including bellows ending at HSW-1-073, and vacuumed out and capped the support tubes in that length. Test results for the above area posted here.
Evan and Kiwamu,
We have been unable to lock the interferometer since this Tuesday (alog 25431). We finally identified and fixed the problem.
It was the cage servo of SR3 which for some reason had a too high control gain and therefore kept feeding sensing noise to the suspension up to 1 Hz. We are happy now.
[Symptoms]
The symptoms were described in Evan's original alog.
In addition, today we noticed that the lock loss in DRMI often happened with a mode hop, indicating that some kind of misalignment was involved. Since the mode hop can be easily triggered by the large optics (i.e. BS, ITMs, PR3 and SR3), we suspected the large optics. Then, we found that we could stably lock PRMI which pointed us to SR3.
[Something happened in this Tuesday]
Trend data showed increase in the pitch motion of SR3. See the attached. The increase of noises occurred at around 4 pm local time of this Tuesday. We have no idea what triggered this situation.
By the way, the UR OSEM seemed as if it had reduced noise, but it turned out that this was due to the 60 Hz power line for some reason decreased at the same time. We then switched off the cage servo to see if it improves the situation. Indeed it did. In fact DRMI was able to lock more stably.
We have checked the damped spectra of the top and bottom stages without the cage servo comparing against the past ones (alog 17781). We did not find any obvious issues with the suspension when the cage servo was off. At this point, we concluded that the problem is in the cage servo code rather than the suspension or its damping system.
[The fix]
We lowered the control gain in the guardian by a factor of 100 which may sound big to some readers, but this gave us a good control time scale of 3 minutes according to a coarse impulse response test.
The resulting spectra at the top and bottom stages seemed as quiet before. So this is good. The code is checked into SVN.
We still don't understand why this happened.
Later, Jeff B locked the interferometer all the way to low noise state where we did a simple test of switching the cage servo off and on to see if it has some effect on the cavity build ups. We did not see any obvvious effect. Good.
A followup study.
I checked the following items to investigate what could possiblly change the cage servo. Nonetheless, still no clue.
Cao, Ellie, Dave O and Aidan
From llo alog 21927, Aidan found that the ratio between s an p polarizations is higher than expected. The polarization at the output port has been observed to change over time during lock stretches. In particular the s polarization reduces by 30-50% over the course of 1-2 hours and p polarization slowly increases. Due do various polarization-depenent optical elements in the interferometer, the s-polarization pick up different phase shifts. Excess of p-polarized light may couple to DC readout and introduces excess of noise at the output. Given the time dependent behaviour of the s-polarisation we would expect the DARM noise to change with time if polarization noise was contributing in a major way to the DARM spectrum. The DARM power spectra were inspected a number of times during post power up to investigate the dependency of the noise on the polarization the state of the interferometer.
DARM power spectra from 19Dec15, 26Dec15 and 9Jan16 lock stretches show no apparent changes over time after power up. These lock stretches were during the O1 run and were chosen because the interferometer went to observing mode very quickly after the power was increased. Power spectra are recorded at 0.19 Hz bandwidth, 10 averages. The interferometer went to observing mode at 7, 5 and 2 minutes after power up on 19Dec15, 26Dec15 and 9Jan16 respectively.
There is no clear correlation between the polarization drift and the DARM spectra. Whereas there is a 30%-50% decrease in s-polarization over the course of 1-2 hours after power up, the DARM noise spectra remains stable in the 10 to 70 Hz range.
The DARM spectra also indicates no effect due to thermal lensing as the DARM spectra is very stable during self-heating of the interferometer. Thermal lensing relaxation time is approximately 20 minutes after power up. DARM power spectra after stabilization (occurring at minimum 2 minutes after power up) remains constantst during thermal lensing relaxation period and beyond.
We will be looking into the same problem at Livingston, which has a stronger polarization drift.
The time evolution of the self-heating is given here: aLOG 14634
More generally, the TCS actuator couplings are given here: T1400685
After today's commissioning meeting, JoeB pointed me to LLO alog 19578, where he describes the change that LLO made that seems to have solved the BS coil driver switching problem.
For whatever reason, it seems that the analog output is not zero until some time after the digital output has been zeroed. So, LLO added an extra 7 second wait time after the matrix has finished ramping. I have now implemented this here, and we'll see what happens next time we try to lock.
model restarts logged for Thu 04/Feb/2016
2016_02_04 11:13 h1lsc
2016_02_04 11:13 h1omc
2016_02_04 11:15 h1dc0
2016_02_04 11:17 h1broadcast0
2016_02_04 11:17 h1nds0
2016_02_04 11:17 h1nds1
2016_02_04 11:17 h1tw1
LSC/OMC model change and associated DAQ restart
model restarts logged for Wed 03/Feb/2016 No restarts reported
model restarts logged for Tue 02/Feb/2016
2016_02_02 11:24 h1susauxb123
2016_02_02 11:30 h1asc
2016_02_02 11:54 h1isietmx
2016_02_02 11:58 h1susauxex
2016_02_02 12:00 h1susauxey
2016_02_02 12:33 h1dc0
2016_02_02 12:35 h1broadcast0
2016_02_02 12:35 h1nds0
2016_02_02 12:35 h1nds1
2016_02_02 12:35 h1tw1
2016_02_02 13:18 h1psliss
2016_02_02 13:32 h1psliss
2016_02_02 13:36 h1isietmy
2016_02_02 13:38 h1isiitmx
2016_02_02 13:38 h1isiitmy
2016_02_02 13:40 h1isibs
2016_02_02 13:46 h1dc0
2016_02_02 13:48 h1broadcast0
2016_02_02 13:48 h1nds0
2016_02_02 13:48 h1nds1
2016_02_02 13:48 h1tw1
2016_02_02 14:51 h1psliss
2016_02_02 16:55 h1broadcast0
2016_02_02 16:55 h1dc0
2016_02_02 16:55 h1nds0
2016_02_02 16:55 h1nds1
2016_02_02 16:55 h1tw1
Tuesday maintenance. SUSAUX model rate change and DAQ reconfigure. ASC new model. ISI bug Fix. PSL ISS model change. Associated multiple DAQ restarts.
model restarts logged for Mon 01/Feb/2016 No restarts reported
Masayuki and I noticed that ADC noise in OMC was too high. It turned out that the whitening filters turned off for no obvious reason at around 17:00 pm local according to trend.
Looking at the control screen, we noticed that some channels were not accessible. See the attached. We seem to be able to toggle the analog whitenings and digital anti-whitenings independently now. The rest of the PDs seem OK -- they don't have inaccessible channels.
Dave, JimB, Kiwamu,
We investigated a bit more today. Interestingly, we discovered that these blank channels never existed before. The only remaining oddity is the fact that we were unable to synchronously switch the analog and digital whitenings by clicking the buttons in the OMC_DCPD screen.
[Jenne, Cao]
What was once the 90 MHz local oscillator for just the ASAIR 90 WFS now goes to a distribution amplifier box. 3 of the outputs of that board now go to the local oscillator inputs for each of ASAIR_90, AS_A_90 and AS_B_90. The local oscillator inputs want 10dBm each, so we measured the output of the distribution box, and each output was 15dBm. So, we put 5dB RF attenuators on each spigot. Next up, we'll lock DRMI and look at phasing.
Looks like the RF amp gets overdriven at the input. The outputs should be around 13dBm.