According to the TCS measurement we did last night (29901), a good CO2X power to minimize the intensity noise coupling is 240 mW. This should give us an additional factor of 3 suppression.
For the frequency noise coupling, we did not reach an optimum point, but with the240 mW CO2X, it will give us a small supression of 20% or so.
[The test]
See the first attachement or a screenshot of trend below for how things were stable during the measurement.
[Intensity noise couplings]
As seen in the animation below, the transfer function did not change its shape. As the defocus on ITMX compensation plate changed, the overall scaling factor changed.
To show that we passed an optimum point (where the coupling is minimized almost all the frequencies), the following plot is the evolution of the transfer coefficient at 650 Hz.
The minimum point was achieved at t = 24 min. or so where the defocus dropped by about 4 uD from the initial value. According to the recent calibration of the CO2X actuator efficiency (29648), this change corresponds to (-4 uD) / (25 uD/W) = -160 mW. Because the initial CO2X power was 400 mW, the optimum point in terms of the CO2X operating power is 400 - 160 mW = 240 mW.
[Frequency noise coupling]
Here are the same analysis for frequency noise. Similarly to the intensity noise coupling, the shape of the transfer function did not change during the measurement.
Similarly to intensity noise coupling, the frequency noise coupling also decreased. See the plot below.
The coupling monotonically decreased as a function of time. In the end the coupling was lower than the initial value by roughly a factor of two.
Sheila, Keita
The 3rd whitening filter does not switch for AS_C segment 3. The readbacks look OK.
Last Tuesday we pulled the chassis and verified everything worked. This wee we pulled the chassis and verified everything worked. Finally while watching the binary switches we were able to trace it down to a pin in the cable pulling out of its socket. This was very troublesome because it would work as long as we had a breakout board inserted in between the cable and the chassis. Watching the signals while re-assembly took place we per able to narrow it down and found the problem. We have removed the back-shell of the connector and shoved the pin back in place. Next Tuesday we will crimp on a new pin. So we have not closed the work permit yet.
Work Permit 6180
TITLE: 09/22 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: Jeff
SHIFT SUMMARY: Maintenance for the first half of the day, then commissioning took full affect and now we are locked in NLN at 60Mpc!
LOG: (see attached)
3pm local CP4 = cryopump #4 at mid Y John, Chandra First, this morning we installed type K thermocouples along the exterior of the nitrogen exhaust pipe outside - one ~1 ft the exit of the building, one mid way down, one at the end of the SS exhaust line, and the last inserted inside the plastic flex tube (also the flow meter measures temperature). We repeated yesterday's CP4 experiment by doubling LLCV (66% open) and allowing CP to overfill beyond 100% until LN2 came out the exhaust. I was physically at the exhaust line during the violent transition taking temp. measurements along exhaust. LN2 sputtered into plastic flex tube, so I quickly opened bypass exhaust valve and closed manual LN2 fill line on main Dewar (temporarily). It didn't help that during this chaos there were reverberations from an airplane or big truck in the distance that sounded like the entire arm coming up to air. Temp measurements along the exhaust line (degC): Time TC1 (wall) TC2 (mid) TC3(end) TC4 (flex tube) TC5 (flow meter) 14:07 -27.4 5.8 21.9 22.8 - 14:43 -25.2 11.1 25.9 26.1 28.xx 14:55 -27.5 10.1 26.2 26.2 - 15:01* -57.5 -49.3 -57.6 -193.8 -0.5 15:30 -23.1 13.7 15.6 16.3 19.7 *LN2 out the exhaust Flow meter seems to be functioning still John and I are considering installing a TC inside the end of the exhaust pipe at CP3 to use both this signal and the exhaust pressure to develop an automated fill every 2-3 days (no flow meter).
Only we vacuum people can fully appreciate that awful feeling of dread when a potentially risky vacuum activity, along with the heightened senses awareness that accompanies it, coincides in time with other, unrelated, noises which serve only to reinforce our premeditated worst case scenarios. "I hate when that happens!"
These were planned events but still makes the heart beat a little faster than usual when LN2 boils out of the exhaust.
After alleviating the clipping of the PCal beams yesterday (aLog 29873), TJ and I performed the end station calibration today during the spontaneous maintenance day period. See attached report for full data, but the good news is that the optical efficiency of both PCal beams has returned to 98%. The previous total optical efficiency for both beams was 62%.
The diffracted power versus ISS offset slider value was measured. Attached is the plot for the percent diffracted power versus AOM drive signal. Unfortunately the plot isn't really parabolic. Looking at the plot it looks like the best region for the AOM drive is somewhere between 0.65 and 0.75 V. Which represents somewhere between 8.5 and 17%. A better characterisation of the AOM drive involves adjusting a pot on the ISS board to better linearise the output of the multiplier chip. That's a somewhat iterative process between measuring the diffracted output and adjusting the pot. The full power of the laser was measured to be 167.5 W.
Pulled network/power cables from the Vacuum rack to the RGA's at the end stations. This is to connect the RGA's to the vacuum network. Cables still need to be terminated.
We seem to have discovered a new issue with the fast shutter. When the fast shutter is set to the blocked (closed) state by the user and the trigger is enabled for 5 sec or longer, it will open.
This is a known condition relating to the need to sense a disconnected input trigger cable. That being said, we should examine if this really needs fixing. There is probably a reason you lowered the shutter controller trigger threshold and caused the shutter to be in a triggered mode for greater than 5 seconds, but is this essential to the operation of the IFO? Many factors govern the operation of the shutter including: The ability to sense obvious configuration faults like disconnected input or output cables, anti-collision logic to prevent simultaneously driving the shutter up and down causing self destruction of the drive circuitry, determination of sufficient charge to safely fire the shutter, and others. The point is that we should think long and hard about making a change to support an operational configuration outside that which is strictly required.
I just recentered IM4, by moving the picomotor +400 counts in the X direction and +4100 counts in the Y direction.
The QPD started at -0.47 PIT and 0.12 YAW, now both are fluctuating around 0.
model restarts logged for Wed 21/Sep/2016
2016_09_21 10:24 h1fw1
2016_09_21 10:47 h1calcs
2016_09_21 18:18 h1nds0
2016_09_21 20:36 h1fw0
2016_09_21 21:24 h1fw0
return of fw1 after cloning work was abandoned. Jeff and Darkhan's calcs C code change (no daq restart). Unexpected restart of h1nds0, continuing fw0 instability.
model restarts logged for Tue 20/Sep/2016
2016_09_20 13:37 h1psliss
2016_09_20 13:43 h1broadcast0
2016_09_20 13:43 h1dc0
2016_09_20 13:43 h1fw0
2016_09_20 13:43 h1fw2
2016_09_20 13:43 h1nds0
2016_09_20 13:43 h1nds1
2016_09_20 13:43 h1tw0
2016_09_20 13:43 h1tw1
2016_09_20 13:53 h1susprocpi
2016_09_20 13:55 h1broadcast0
2016_09_20 13:55 h1dc0
2016_09_20 13:55 h1fw0
2016_09_20 13:55 h1fw2
2016_09_20 13:55 h1nds0
2016_09_20 13:55 h1nds1
2016_09_20 13:55 h1tw0
2016_09_20 13:55 h1tw1
2016_09_20 14:48 h1psliss
2016_09_20 14:50 h1broadcast0
2016_09_20 14:50 h1dc0
2016_09_20 14:50 h1fw0
2016_09_20 14:50 h1fw2
2016_09_20 14:50 h1nds0
2016_09_20 14:50 h1nds1
2016_09_20 14:50 h1tw0
2016_09_20 14:50 h1tw1
2016_09_20 15:18 h1psliss
2016_09_20 17:05 h1calcs
2016_09_20 17:06 h1broadcast0
2016_09_20 17:06 h1dc0
2016_09_20 17:06 h1fw0
2016_09_20 17:06 h1fw2
2016_09_20 17:06 h1nds0
2016_09_20 17:06 h1nds1
2016_09_20 17:06 h1tw0
2016_09_20 17:06 h1tw1
2016_09_20 17:07 h1broadcast0
2016_09_20 23:16 h1fw0
2016_09_20 23:29 h1fw0
Maintenance day. Several rounds of PSL-ISS model and DAQ restarts. Addition of epics chans to SUSPROCPI. CALCS model change. FW1 powered down for cloning (not shown). Start of FW0 instability.
model restarts logged for Mon 19/Sep/2016
2016_09_19 02:25 h1nds0
2016_09_19 11:46 h1fw2
2016_09_19 11:49 h1fw2
2016_09_19 11:56 h1ascimc
2016_09_19 11:56 h1fw2
2016_09_19 11:58 h1fw2
2016_09_19 12:00 h1broadcast0
2016_09_19 12:00 h1dc0
2016_09_19 12:00 h1fw0
2016_09_19 12:00 h1fw1
2016_09_19 12:00 h1fw2
2016_09_19 12:00 h1nds0
2016_09_19 12:00 h1nds1
2016_09_19 12:00 h1tw1
unexpected restart of NDS0. FW2 cloning for Rolf. ASCIMC code change with DAQ restart.
I ran Hveto over the earlier lock, firstly from 01:00-06:00 UTC and then from 07:45-08:15 UTC to avoid TCS injections, here are the results pages:
https://ldas-jobs.ligo-wa.caltech.edu/~laura.nuttall/detchar/hveto/20160922/1158541217_1158559217/
https://ldas-jobs.ligo-wa.caltech.edu/~laura.nuttall/detchar/hveto/20160922/1158565517_1158540787/
Sadly there is nothing obvious standing out, and the signifiances of the round winners are not particularly high
sadly after several weeks of fault-free running we have had frame writer issues starting late Tuesday night. Only h1fw0 and h1fw1 are showing the problems, with h1fw2 stable. All three are running RCG2.3 code, the only difference is that fw2 has a local (non-QFS) disk. Some of the error messages from fw0 and fw1 suggest disk access issues.
One quick thing to try (which has helped in the past) is to power cycle the Solaris QFS-NFS servers. Under WP6179 we performed the following:
We have noticed that some recent DAQ restarts appear to cause the Seismic BLRMS control room plot to lose its past data. The usual behaviour is to just show a gap while the DAQ was down (just a few minutes) and preserve all other times.
as a reminder that we have enhanced remote access controls in place during the hours of 8am to 4pm Mon-Fri, ssh sessions to lhocds.ligo-wa.caltech.edu now have a banner text display (see image). We have included the operator's phone number to call (we think this is already in the public domain).
Many thanks to Ryan for suggesting the use of the banner feature in SSHD.
We have made another round of modifications to the ISS second loop board to have a bit of more gain at 1kHz.
Boost 1 zero was increased by a factor of 2, BOOST 2 was added, and a bit of phase compensation for high frequency to allow us to push the UGF to 20kHz-ish (details of the mod will be attached to this entry).
In the attached, black is the measurement from yesterday at 50W, 7dB of VGA gain, boost on.
Blue is today with 13dB of VGA gain, first boost on.
Red is today with 13dB of VGA gain, second boost on.
All in all, the modifications bought us about 13dB at 1kHz.
If we really need more, we should be able to push the UGF even higher, but that needs some serious thinking.
Here is a measurement of the open loop transfer function with SR785 at the floor. The UGF was at 18 kHz and the phase margin was roughly 50 deg.
The data, plotting script and figure are attached as a zipped file.
Boost 2 and boost 3 have been rewired in series to yield a double integrator. Each of them has a 50Hz pole and unity gain at 2kHz. The model has been changed to enable stages 2 and 3 simultaneously with the boost 2 switch. This boost does not work without boost 1. It would generate a notch near 2kHz but together with boost 1 the two zeroes become complex. Therefore engaging boost 2 will enforce boost 1.
At 1kHz the higher bandwidth increases the gain by 2. The higher frequency knee in boost 1 adds another factor of 2. The second boost adds 1-2dB at 1kHz and and additional 20dB at 100Hz.
A new filter modules has been added after the integrator of the AC coupling, called DRIVE. This allows the an easy hold of this output, when the AC coupling is off.
In order to combat the weirdness with the diode chiller temperature not reaching its desired set point of 20 degC, I raised the set point to 21 degC. This seems to have brought the chiller temperature to ~19 degC. Trending the diode chiller temperature, one can see that there's an oscillation in the actual temperature. It might be to fool the system we ought to change the temperature set point to 22 degC. From the trend data one can easily see the temperature oscillations that are apparent when one looks at the chiller control panel.
Filed FRS #6292.