Keita, Evan

We installed a mixer-based 45 MHz RFAM monitor using two spare 45 MHz spigots on the distribution amplifier on the ISC rack. This provides an unobtrusive way to look for 45 MHz amplitude glitches on the ISC rack (i.e., it does not require inserting anything into the main 45 MHz drive that goes to the EOM driver and the EOM). On the other hand, if the glitches are only on the main 45 MHz drive, this monitor will not tell us anything.

Set-up is as follows:

• Spigot #7 is attenuated by 5 dB and goes to mixer LO. Spigot #8 is attenuated by 12 dB and goes to mixer RF. The spigots are nominally 13 dBm, so the mixer (ZAD-1, level 7) should get 8 dBm in its LO port and 1 dBm in its RF port.
• IF of mixer is sent through an 11 MHz minicircuits LPF, and then is terminated with 50 Ω. The dc component of this output is 175 mV.
• The output is then sent into an ac-coupled SR560 with a gain of 1000. This produces a signal whose voltage ASD is 18 µV/Hz^1/2 at 100 Hz, as measured with an SR785. If the SR560 is terminated at the input with 50 Ω, the voltage ASD is 5 µV/Hz^1/2 at 100 Hz.
• The output of the SR560 is sent into LSC-EXTRA_AI_1. This should add an additional 4 µV/Hz^1/2 of noise.

I have calibrated LSC-EXTRA_AI_1_OUT so that it is in volts. This channel is not dequeued, but if we have another hours-long episode of glitching we can watch the test points in real time.

Evan and Keita are disconnecting the RF AM monitor in the PSL enclosure.
Running a2l.

The ISC_LOCK guardian was stuck at DC Readout Transition because the OMC wasn't ready, although the guardian log only said "not ready", and there was no notification that popped up.  Patrick re-requested the OMC guardian to go to Ready For Handoff (which worked), but I also added a notify to the ISC_LOCK guardian to say "OMC not ready" if this happens again.

Lost lock trying to engage ISS second loop by hand.

SUS SR2 saturating 17:48:35 UTC

Did this yesterday afternoon (11/18) but forgot to log it then.

17:10 UTC Out of observing for Keita to test grounding configurations for RF AM monitor. Not going into PSL enclosure. (WP 5616)

TITLE:   Nov 19 Owl Shift 08:00-16:00UTC (00:00-08:00 PST), all times posted in UTC

STATE Of H1: Observing at 80 Mpc

SUPPORT: David, Laura, TJ, Andy, Dan (sorry if I missed any of you!)

LOCK DURATION: 7 hrs 53 mins

INCOMING OPERATOR: Patrick

END-OF-SHIFT SUMMARY: We have nasty stationary lines between ~100-1000Hz since we started locking 12 hours ago. Few Detcharians gathered this morning to follow this up. Keita arrived and shed the light to this mystery that it is in fact the newly installed RF monitor injecting noise into DARM (alog 23555).

ACTIVITY LOG:

15:16 Bubba driving along the arms to check on tumbleweed

15:29 Bubba back. The landscape crew is taking care of it. They're working from 250m from EX towards Corner station.

TITLE: 11/19 [DAY Shift]: 16:00-24:00 UTC (08:00-16:00 PDT), all times posted in UTC
STATE Of H1: Observing @ ~ 80 MPc.
OUTGOING OPERATOR: Nutsinee
QUICK SUMMARY: From the cameras the lights are off in the LVEA, PSL enclosure, end X, end Y and mid X. I can not tell if they are off at mid Y.
Earthquake seismic band is between ~ 0.01 and 0.03 um/s. Microseism has been coming down and is between 0.1 and 0.4 um/s.
Winds are between ~ 0 and 5 mph.
ITMX, ITMY and BS ISI blends are on 45mHz. EMTX X and ETMY Y ISI blends are on 45mHz. ETMX Y and ETMY X ISI blends are on Quite_90.

I've been noticing all night but not sure where from. Those nasty little lines seem to have come with a broad peak at 1040Hz. It's not the violin mode second harmonics (which ends at ~1010Hz).

Found damp settings for 1009.0273 Hz and 1009.6825 Hz (ETMY). Both lines have very low amplitudes to begin with (only a magnitude above the noise floor) so once I was able to damp them slightly I turned the damping off. Here's the table. The BP filters live in ETMY L2 DAMP MODE4 FM7 and FM10.

Livingston seems to be having problems with their front end and won't be up for a while. I'll take some time to work on the 2nd harmonics violin modes.

Ed, Kiwamu,

During the course of relocking effort today, we ran into three issues associated with the guardian automation. Two of them are fixed/improved by editing the guardian codes while we were not able to fix the last one.

Here is some notes.

• Issue 1 (fixed), INPUT_ALIGN of IFO_ALIGN does not lock the X arm.
  • We found that this was due to a too high gain which had been increased in this afternoon (alog 23532) with an aim to improve the loop stability. We reverted the gain back to the nominal of 0.05 in lscparams.py.
  • The new code is submitted to SVN. It works fine with the nominal gain so far. We have no idea why it needed to be increased by a factor of 3. Perhaps related to the bad input pointing (alog 23538) ?
• Issue 2 (fixed), OMC_LOCK was consistently unable to find the carrier resonance.
  • This was found to be due to a unfortunate PZT scan range -- the peak-finding algorithm was unable to identify three high peaks (two from 45 MHz sidebands and one from the carrier). We have been mitigating this issue by adjusting the scan range so that the three peaks are separately captured in different segmented time series. This time, one of the segmented data chunk tended to capture one of the 45 MHz sideband as well as carrier. This situation ended up forcing the algorithm to pick only one of them and abondon the other. This in turn let the algorithem think there were only two peaks. I changed the scan starting voltage from -30 to -24 V so that three peaks are captured in different segments.
  • The latest code (OMC_LOCK.py) and parameter file (omcparams.py) are checked into SVN.
• Issue 3 (not fixed), CAGE_SERVO did not warn us that it was railing.
  • No idea why. It is supposed to give us a notification message when the amount of feedback is high. However it did not behave that way and simply kept servoing SR3 without giving a notification/warning message. We reloaded the code, but it did not seem to enter the if statement in which the warning message is given.
  • We manually offloaded the control signal to the upper stage in SR3.