Ed, Jeff, Fil, Dave:

I'm not sure if this is a coincidence, but the h1iopsush2a IRIG-B excursion had almost completed its recovery (after almost 3 hours) when the IOP glitched again. The IRIG-B had gone up to about 1500 and was down at 75 at the time of the glitch (24 is the start of the good range).

This time all user models showed an FE error (see attachment).

I stopped all the models and ran h1iopsush2a by itself, verifying there was not an IRIG-B error.

As an unconnected problem, I noticed that the second 18bit DAC AI chassis was reporting an ON status even though the IOP was commanding all AI's to be OFF (see attachment). Jeff verified the AI rack locations, and it was found that the second 8-channel block of the AI was permanently ON, even with the DAC cable disconnected from the rear. Fil replaced the AI chassis with a spare, the switching function has been restored.

Around this time h1sush2b  glitched. Its models were restarted with no problems.

I restarted the remaining models on h1sush2a (h1susmc[1,3], h1suspr[m,3]).

Corner station RGA scan attached. N2 peak is high. We will monitor to see how it decreases with time. SEM voltage set to 1300V.

Marissa Walker, Josh Smith, Alex Macedo, Oli Patane 

We looked at recent data to see if we could measure new violin mode frequencies. We used the DRMI 3f lock stretch mentioned in this alog . We made long (~10mHz frequency resolution) spectra of H1:LSC-DARM_IN1_DQ (Figure 1) and many ALS channels, but the violin modes were not clearly visible in any of them. 

We also measured spectra during a longer time from Aug 3rd (1217291534.25 to 1217297671.19) when there was ALS DIFF data but not DRMI, but again no violin modes were visible. So it seems, if we’ve chosen channels wisely, that the sensitivity is not yet sufficient to spot the new violin modes. 

We will continue to look at data as we get longer times and better sensitivity.

Sheila, Dave:

A new h1ascimc model was started with a new DAQ configuration:

+: fast channel H1:ASC-AS_A_RF45_I_SUM_OUT_DQ added to the DAQ
+: fast channel H1:ASC-AS_A_RF45_Q_SUM_OUT_DQ added to the DAQ

the DAQ was restarted.

This reminded me of the RCG3.2.3 work I had done on h1pemmx some time ago. It was a test system for the RCG3.2.3 upgrade of the SUS-QUAD models. Both its models and its mx_stream had been upgraded to 3.2.3 to show that the DAQ error could be cleared if the new mx_stream is ran. After the DAQ was restarted it was left running 3.2.3 models and 3.2 mx_stream (like the SUS-QUADs are). I recompiled h1ioppemmx and h1pemmx using rcg3.2 and restarted them, clearing the DAQ error on these models.

In DRMI without the arms, REFL_A and REFL_B phases are fine, both 9MHz and 45MHz.

I heard a chiller alarming while I was passing through receiving. Added 250mL to the crystal chiller. This is worrying since someone added 100mL yesterday. Ed checked the relative humidity and it spiked 4 hrs ago. The PSL team as been informed.

   With the green light shuttered (gate valves shut) took the opportunity to take a few shots of ITM-X and ITM-Y. The objective of these photos was to understand how the ITM OpLevs light pollutes the images of the ITM optics. When these shots were taken, there was a little 1064nm light present, which is visible as the purple areas on the optics. There is a small amount of OpLev light on the ITM optics from the up and down stream OpLevs. This light does not represent an issue for ITM optics face photos.

   These photos demonstrate the ITM OpLevs will need to be switched off to get good images of the entire optic face. Need to repeat this study with stronger 1064nm light on the optic to see if it can dominate over the OpLev scatter.

[TCS Team]

The CO2X laser tripped last night before we could not inject some heating for a couple minutes.  However, the pre-heating guardian for CO2X was turned on for about 3 hours at 500 milliwatts with central heating so we can get some preliminary information about the centering.

This is the heating up:

This is the cool down:

There doesn't seem to be any apparent clipping/fringing of the CO2 beam, and centering isn't terrible.  The edge on the upper right side is due to clipping of the HWS beam.

Around 08:30 PDT h1iopsush2a had an ADC-DAC timing glitch. Pressing DIAG_RESET cleared the ADC error, but the glitch was large enough to desynchronize the DAC channels and the IOP went into its safe state of not driving any DAC channels.

At 09:24 I did a simple stop-all-models, start-all-models restart. Within 5 minutes the IOP glitched again. /proc/h1iopsush2a/status showed a large ADC timeout of 180uS at 09:34.

At 09:48 I performed a full power cycle of the cpu and IO Chassis. Sequence was: stop-all-models, take node out of Dolphin fabric, power down cpu, power down IO Chassis*, power up IO Chassis (wait for good timing lock), power up cpu (autostarts models).

* before powering the IO Chassis down, I noted it had a good timing status on the timing slave card.

This time the IOP IRIG-B went into a positive excursion, it had topped out at 1500 and is on its way down. System has been running for 25 minutes with no repeat of the ADC-DAC timing issues.

I noted that the auto-calibration of the 18bit DACS are all good, but the third card consistently takes longer to calibrate:

controls@h1sush2a ~ 0$ dmesg|grep CAL
[   50.143460] h1iopsush2a: DAC AUTOCAL SUCCESS in 5341 milliseconds
[   55.506760] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   62.536318] h1iopsush2a: DAC AUTOCAL SUCCESS in 6572 milliseconds
[   67.899590] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   73.693450] h1iopsush2a: DAC AUTOCAL SUCCESS in 5344 milliseconds
[   79.056792] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds
[   84.425154] h1iopsush2a: DAC AUTOCAL SUCCESS in 5345 milliseconds

This morning I installed the modified pre-modecleaner servo.  In short, I could not lock the pre-modecleaner with it.

    The difference between the modified board and the in-service one, is the addition of two active notches to notch
out the pre-modecleaner PZT resonances.  The phase delay switches were changed to DDDDDDUUU to restore the sign of the
error signal.  Despite what I think is the correct feedback sign, I could not get the pre-modecleaner to lock.  The
(original) in-service pre-modecleaner was re-installed, along with restoration of the phase delay switch settings in
order not to delay commissioning work for this morning.

    Back to the EE Lab with this one.

At ~15:28 the IMC suffered a DAC and DK error causing OSEM values in MC1 and MC3 to change drastically. Slider values have not changed. WFS history was cleared. The Drift_Mon panel on the right (in the figure below) is from 2 hours prior. The diag reset function on the CDS overview reset the DAC error but it seems that some models and computers need to be restarted. Currently I'm waiting or Dave Barker to arrive.

Throttled GV15 by running the gate down for 4 min. 15 sec. (not quite soft closed) to block the laser beam from reaching EX for commissioning activities. Will reopen around noon or when commissioners inform VAC team they are ready.

TITLE: 08/03 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 18mph Gusts, 15mph 5min avg
    Primary useism: 0.04 μm/s
    Secondary useism: 0.06 μm/s
QUICK SUMMARY:

Sheila Craig Georgia Hang

This evening we continued trying to improve the CARM handover from ALS-COMM to LSC-TR, following on from last night's work (alog-43190).

We fixed an error where the LSC-RELFBIAS input matrix elements were left on, and now the the arm transmissions (LSC-TR_X and Y) are much quieter at the CARM_TO_TR step. We retook the TR_CARM open loop transfer function which looks better than yesterday. We tried skipping the step added yesterday which brought the arms to a 100Hz offset in the PREP_TR_CARM before handing over, but found this step was necessary to find the IR.

We went to the next guardian state: REDUCE_CARM_OFFSET, and could not maintain this for very long before losing lock (after ~1 minute).

We tried to get to the DARM_TO_RF state but found the ETMX HEPI tripped, it looks like there might be a timing error as the watchdog trips before the tidal monitor saturates. The sensor in this stage of locking is ASC-AS_A_RF45_Q_SUM_OUT16, which is not a DQ channel, it would be handy to store this channel so we can look back at the locklosses.

Sheila, Craig

We retook the ALS COMM frequency noise measurement using the IR PDH signal of REFL_9_I at an out-of-loop witness.  In my old measurement, I hadn't removed the 42 Hz IR arm pole from the spectrum.  This time it's removed using a DTT calibration filter which is just a zero at 42 Hz.

This time we requested 10 watts input power while resting on the fringe to try and suppress REFL_9 sensor noise, and we were successful.



Out-of-loop ALS_COMM Frequency Noise RMS = 1.5 Hz

Measured Input Power August 2 = 9.6 W
Measured Input Power July 29  = 2.6 W
REFL_9_I_ERR_DQ Calibration August 2 =  2.0 Hz/cts
REFL_9_I_ERR_DQ Calibration July 29  = 18.0 Hz/cts 

It seems our broadband suppression above 1 Hz goes linearly with power, which suggests we're limited by dark noise.  More investigation of the REFL_9 signal chain required.

I was only able to integrate RMS starting at 900 Hz since we used the REFL_9_I_ERR_DQ channel this time.  Still unclear what's happening above 1 kHz, probably REFL_9 noise was killing our measurement there as well, but it could also be COMM sensor noise starting to take over.