Today, Carlos P. fixed the LAN setup IP address issue for me and I was able to connect to the X-end RGA electronics using the dedicated laptop.  This allowed me to confirm that the RGA still functioned following its removal and re-installation the other day (prerequisite to performing the bake operation).  I then wrapped the whole assembly in aluminum foil (it's an art - performed by artists).  At the next opportunity, I will wrap the assembly in heat tapes (also and art - performed by artists!) followed by the final layer of aluminum foil.  At that point, it will sit idle awaiting the next 5-day window of IFO down time to perform the actual bake.

A reminder that we are in the testing phase of operator control of remote access to LHO CDS. This is a soft roll-out, it is only in effect while an operator is on duty and it does not kill any running sessions. 

Here is part of an email which was sent to remote access users on 8/30

Dear All,

this email is being sent to everyone who has logged remotely into LHO CDS in the past calendar year. Starting today we are testing an enhanced security system which requires remote users to call the control room operator before remote access is permitted. During this testing phase the additional restrictions will only be in place when an operator is on shift, 8am to 4pm Pacific Local Time Monday through Friday. Outside of these times, access will be unrestricted. Open sessions which span these time boundaries are unaffected.

Note that this applies to secure copy (scp) as well as secure shell (ssh) sessions.

The operator’s phone number is (509) 372 8202

Dave, Nutsinee

Today we did a little test to confirm that there's no way to aviod CO2 laser tripping when oaf computer and IO chasis are bering restarted by unplugging the chillers from the front end which we thought might have worked at one point. Turned out as soon as the chillers were unplugged from the cables the CO2 controller box tripped immediately and the drawn currents went down to 0.7 A for TCSX and 0.8 A for TCSY (from their nominal at ~22A). Funny thing is when I went back to restart the controller boxes after plugging the chillers back in there're no red lights indicating that they had been tripped. They simply stopped lasing. The laser status looks like it's never tripped. So if somebody unplug the chillers and the lasers don't work, there's currently no obvious way to know from the control room that the chiller(s) have been unplugged (except that TCS laser locking guardian might throw fist and unreasonable DAC outputs).

Before I went out to the mezzanine I paused TCS guardian so that they won't try to talk to the chillers when they're disconnected. As soon as the chillers were disconnected (10:52 AM local) DAC output 1(ITMX pzt), 4(ITMX chiller), 9(ITMY pzt), 12(ITMY chiller) freaked out and dropped/jumped far from nominal. They didn't come back to their nominal values until I restarted the TCS laser locking guardian nodes after bringing everything back to normal.

We need Alastair's magic box to prevent TCS from tripping everytime oaf/dac is powered down.

TCS CO2 system layout can be fround here

WP6171: Ryan, Carlos, Dave:

h1fw0 writes data to the /ldas-h1-frames QFS disk system (located in warehouse)

h1fw1 writes data to the /cds-h1-frames QFS disk system (located in OSB-MSR)

both h1nds0 and h1nds1 were serving /cds-h1-frames (historic from when h1fw0 was unstable).

This morning I reconfigured both nds servers to serve h1fw0's frames(ldas-h1-frames). We then powered down h1fw1 started cloning its boot drive. Since this is 1TB this may take a few hours.

Reset HAM2 and ITMX.

The 56.8406 Hz comb that Keith pointed to in recent data shows up in End-X magnetometers, and seems to be an isolated spike repeating at that rate.

Keith's recent alog 29783 points to a comb with a spacing of 56.8406 Hz that has been seen before in ER9 and in the one-arm tests. TJ's Bruco results in alog 29828 show that the 56 Hz region of DARM is coherent with the SEIRACK and FLOOR magnetometers. The first plot shows the coherence just at the fundamental frequency.

The line seems strongest in SEIRACK_Y, so I tried folding the channel. The frequency doesn't seem to be an exact multiple of anything digital. But taking 1153 samples at 8192 Hz comes very close to 8 times the comb spacing, so I used that. The result is in plot two, which is four hours of mag data from today folded over 1153 samples. Eight spikes show up very clearly, so there does seem to be some kind of spike happening every 0.01759 seconds.

There are some other channels showing up in Bruco that may not be connected to anything - PEM-EX_ADC_{8,12,13}. I think these are spares. At EY there are some magnetometers on these channels but these look too dead for that. They seem to see the same line, so maybe this really is some kind of DAC problem, or maybe there's just some electronic pickup.

We should get an independent magnetometer out to EX and look around for this comb, and also just confirm that it's not native to the DAC.

We can rule out any mechanical mode around 17.7 kHz causing instability. Any mode around 17.7 kHz does not have good overlap with 3rd order mechanical mode. It most probably aliased mode from ~ 47.7 kHz. Interestingly, according to my FEA model of ETM, there are three candidates: 47.767 kHz, 47.811 kHz, and 47.827 kHz mode. These modes corresponds to the mode number #542, #544, and #545, respectively. Mode shapes are attached. All of them have reasonably high overlap factor:  
#     freq, kHz       TEM    Overlap ITM    Overlap ETM  
542    47.767          02     0.028            0.026
544    47.811          02     0.057            0.050
545    47.827          02'    0.026            0.024

'-see figure
The overlap with 2nd order confirms that one of these modes must ring up. The parametric gain for tuned ETM is shown in attached figure. It is not possible to pinpoint  which  of these modes is observed. According to the overlap value there is slightly better chance that this mode belongs to ITM and it's mode #544. However, mode #542 is the closest to the observed frequency (I do not expect to see error of computed frequency larger than 0.1% at 50 kHz range).  Using ring heater we should be able to rule out at leas one of the three modes. 

WP 6166

This gauge pair has been replaced with a Inficon BPG402 gauge.

The ITMX ESD and HAM6 HV supplies have been reset.

Dave will remove the channels from the DAQ.

PSL tripped at 16:14:52 UTC (9:14:52 PDT).  Apparent cause according to the interlocks is a glitch in the power meter flow.  The first attachment shows the power meter flow dropping just before all the other flows fall off.  The second attachment shows the power meter flow dropping just before (<1 second) the NPRO turns off.  It should be noted that there has been work around the PSL racks this morning, although the NPRO does not at this time appear to be the cause of this trip.

When restarting the laser, I had to reset the Beckhoff PC to get the control software to accept input from the mouse.  I haven't seen this occur before.  In turning the crystal chiller on and off (restart after the trip, then restart after the Beckhoff PC restart), I had to add water in 2 stages: 250mL after the initial trip, and 220mL after the Beckhoff PC reset.  This is standard procedure after the crystal chiller is reset; when the chiller shuts off the pressure in the line causes water to leak out of the chiller reservoir fill port.  There is no indication that there is a leak in the PSL.

The PSL is now back up and running.

WP 6164

When h1brsex reboots, it appears that the C# code starts before the PLC and therefore fails. This does not appear to be case for h1brsey. I have taken out the automatic starting of the C# code and EPICS IOC at h1brsex. I have left the PLC to automatically restart.

I restarted h1brsey twice to check that it had not worked by random coincidence, and it worked both times. I restarted h1brsex more than once and each time it failed.

LHO WP 6151 has been completed. The external links have been upgraded from 1Gb to 10Gb transceivers. Monitoring and tuning of the new connections will be performed in a non-disruptive manner.
Current transceiver light levels:
plugged: SFP/SFP+/SFP28 10G Base-ER (LC)
module temperature: 62.46 C Voltage: 3.25 Volts
RX: 0.13 mW (-8.80 dBm) TX: 1.28 mW (1.09 dBm)

This laser tripped this morning at around 03:00.  Found the NPRO power supply was off.  Suspected problem is either
a mains power glitch or the UPS for the NPRO power supply had a hiccup.

System came up okay except for the ISS, which I am guessing is related to changes made to the sensors as described
by Keita in a previous entry.

Sheila, Jenne, Terra, Matt, Lisa

More complete entries will follow, but the bottom line is that we are still missing the main source of noise below 200 Hz (above 200 Hz jitter/intensity noise should explain most of the noise we see).

We had another long lock today at 50W (broken by  a new PI ) and we tried several things:

- the reduction of the flow rate done in the PSL this morning didn't really last (see  here ), so the PSL table motion is only very very marginally better than it was; 

- Jenne played more with MICH and SRCL FFs, the subtraction is not perfect, but their contribution is negligible at 100 Hz;

- we did AL2, and that reduced a lot the noise below 30 Hz;

- we checked that all the actuators were in their nominal low noise state state; the ITMs ESD had the low pass OFF, so we engaged them (no impact on the noise) - the ESDX bias was at zero as expected, all coils where in nominal low noise states;

- Jenne lowered the 9 MHz modulation depth (see https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=29817), getting rid of the 900 Hz peak;

- Sheila did some exploration of POP offset and IMC WFS offset to minimize jitter (to be continued) - OMC alignment to be checked as well;

- I believe the calibrators have checked the low frequency calibration, and they are confident that it is not off by more than 20%;

- Matt tried to close the ISS with the photodiode in the new location (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=29812), but that didn't work.

 Data around Sep 20, 6 UTC should be good to look at, close to the best low noise state achieved so far. Bruco, actuator noise estimates, checks of couplings with (new wrt O1) TCS-related electronics, and other suggestions are very welcomed. 

Matt, Terra

We have 2 modes which are very close in frequency (both around 15540kHz) and we have had some trouble damping them.  To help with this, I modified the PLL filters for these modes to support a lower bandwidth loop, which I hope will be less easily "distracted" by the nearby mode.  The low-pass in FREQ_FILT1 (usually a 1Hz pole) is a modified elliptic which provides significant attentuation at 0.5Hz (ELF0.5), and requires a UGF of about 100mHz.  To support this, the integrator in FREQ_FILT2 is moved down to 30mHz and the gain is reduced to 0.3.  (Note that ELF0.5 has a gain of 0.5 below the cutoff.  This helps to move the UGF down when this filter is on.)

So far this configuration has been working, but should it prove problematic the old filters can be moved back from FM2 to FM3 (which is the FM operated by the guardian).

   Posted are the ISI HAM & CPS Spectra Checks. Did not notice anything that appeared out of the ordinary.