Miriam, Jenne

*SUMMARY*

We check the L1 and L2 FASTIMON channels introduced in Feb 2016 and the L3 LVESDAMON at the times of blip glitches (found on data from Feb 11 and Feb 13). This investigation suggests that the actuation electronics are not the cause of blip glitches, but their origin must be in the interferometer.

*DETAILS*

We investigate 5 different times: 1139199176.774658, 1139240197.712158, 1139246246.086670, 1139400338.701172, 1139412012.846924

The channels we look into are of the kind H1:SUS-(E/I)TM(X/Y)_L(1/2)_FASTIMON_(UL/UR/LL/LR)_OUT_DQ and H1:SUS-ETM(X/Y)_L3_LVESDAMON_(UL/UR/LL/LR)_OUT_DQ.
These channels show the actuation on the mirrors. 

We plot the whitened data from the H1:OMC_DCPD_A_OUT_DQ as well as the whitened data from the channels mentioned above. The vertical lines show the times listed above. In the attachment we show only the channels that showed something significant. When the blip glitches are loud (higher SNR), it can be observed in the plots that the actuation starts pushing on the mirrors only after the DCPD has seen the blip glitch. 
Therefore, the blip glitch must have originated in the interferometer and not in the actuation electronics.

Layout is O1 version.  Current O2 version has a second high power beam dump, in preparation for up to 50W input power.

DCC# is D1300357-v1, O1 version

The two new BRS status Guardian nodes have been added to the Guardian Overview. The purpose of these nodes is to give the condition of the BRS in the node's state (ie. READY, DAMPER_ON, FAULT). The nodes seemed to have ran well over night so I added them and we'll see what they do over the weekend.

I attached a screenshot of the important code for BRS X. I would still like to make a way to check if the software has crashed since this was a big issue previously, but there are plans to change the computer soon anyway.

The code is simpler for the BRS Y, and the node only really looks at the DAMPCTRLMON channel. If this channel is above 8000 then it is in good shape, if around 3000 then the damper is on, and if less then it is in some type of fault.

1/2 open LLCV bypass valve, and the exhaust bypass valve fully open.

Flow was noted after 1 minute and 11 seconds, closed LLCV valve, and 2 minutes later the exhaust bypass valve was closed.

I isolated the aux pump cart yesterday afternoon to let the HAM6 annulus ion pump run on its own.

Today at 21:30 utc the aux pump cart and accesories were shut down.  All hardware is decoupled from the chamber.

Extended, routed and terminated CDS signal cable for HAM5 annulus ion pump controller.

With the need for heat in the LVEA low we took Heater 5 offline to convert it over to the variac system.  To protect the components we have limited the unit to 440V AC.
Must have a bad heater on C phase as the current draw was too low.  I have to talk to the vendor about adjusting the span on the controller.  We now max out at 14ma instead of 20ma.

4ma off <.5A
6ma 2.41 A 90V
8ma 8.6 A 175V
10ma 19.1A 265V
12ma 33.5A 355V
14ma 50.1 A 439V

No issues unlocking and no issues reisolating the platforms.  I'll run range of motion & linearity tests; possibly transfer function too, just because.

Late entry from yesterday. We discovered that h1pemcs's channel H1:PEM-CS_ADC_4_26_16K_OUT_DQ was railed at +20V. It was determined that this channel in the AA chassis was bad. I demoted this channel in the model back to 2048Hz and promoted H1:PEM-CS_ADC_4_28_16K_OUT_DQ to 16384Hz so Robert continues to have two 16kHz channels for his microphone work.

SEI - HAM6-5 still locked - to be unlocked. Hugh doing PEM inventory

PSL - touching base on beam availability at lunch time

Attached are plots of the power fluctuations from the HPO and its PZT.  The fluctuations in the HPO
power seem to coincide with the variations in the PZT voltage.  Both have a period of about 70 minutes.
We may have to reduce the injection locking servo gain.

    Also attached is a plot of the free running power fluctuations transmitted by the pre-modecleaner
and the output of the HPO.

In trying to engage the power stabilisation servo, we found that its behaviour was
somewhat erratic.  The servo would lock for brief periods of time before a low frequency
change would cause the servo to go out of lock.  Engaging the integrator, when possible,
did not prevent the low frequency fluctuation from knocking the servo out of lock.
Coincidentally the free running power fluctuations through the pre-modecleaner exhibited
large (~2-5%) fluctuations too.

    Thinking that these fluctuations were perhaps caused by diffraction effects associated
with the corona aperture within the laser, a number coronia apertures were tried and their
effects on the beam were examined with a CCD camera.  Whilst looking at the beam profile of
both the oscillator and the front end, it was observed that the profile of the front end
laser was terrible.  Whilst the beam profile from the oscillator was good, it would change
at random intervals.  The front end (seed) beam was re-aligned and the overlap between the
seed beam and the oscillator output improved.

    Without re-doing the mode matching to the pre-modecleaner, the pre-modecleaner was locked.
Its transmitted power appeared more stable.  The power noise spectrum after the pre-modecleaner
appeared more stable too.  The power stabilisation servo was engaged and could be locked.
Its behaviour was noticeably better than previously.

    We could not engage the frequency stabilisation, for reasons unknown at the moment.  But
we will pursue this later this morning.





Jason, Peter