Jeff K., Edgard B.

We added DTT templates to measure the Open Loop gain of the L and P filters for the IM1 suspensions. We did this to investigate a potential miscalibration between the real filters and the ones obtained through GWFilt.  No mismatch was found after using the calibration described in G1100968.

_______________________________________________________________________

The templates live in the svn under:  /ligo/svncommon/SusSVN/sus/trunk/HAUX/H1/IM1/SAGM1/Data/

2018-08-16_H1SUSIM1_M1_WhiteNoise_Y_OLG_0p05to50Hz.xml
2018-08-16_H1SUSIM1_M1_WhiteNoise_P_OLG_0p05to50Hz.xml

NOTE: To use these templates, it is necessary to turn off the limiter for the output of the IM1 Damping loops filter bank.

Jeff K., Edgard, Lee (by providing IIRrational for fitting), Hang

During today's locking we got a brief moment to test the ISIFF at the GRD state RESONANCE (CARM on resonance, DARM on AS45, DHARD ctrl w/ ~ 3 Hz).

In the attached plot, the top-left panel shows the DHARD ctrl output for two consecutive measurements. The red/blue were curves for the ISI to TOP L2P FF on, and pink/cyan ones were without the FF. Also shown in the bottom-left panel was the coherence between DHARD ctrl and the ISI SUSPOINT L. For clarlity we only showed the ones for the DHARD coherence with the ETMs, but the reduction in coherence with the ITMs were similar. In the bottom-right we showed the similar on/off comparison for the local ISI to OPLEV reduction for the ITMs.

It seemed that we could get ~ x2 to x3 reduction of the DHARD ctrl in 0.1 - 0.6 Hz band, and ~ 20% in the total rms (note that our current microseismic was still much lower than average). This should open up the possibilitiy of reducing DHARD ctrl BW in the future when we start to tune the ASC. The price we had to pay was the contamination in the <0.1 Hz band as we were injecting tilt motion to the ASC loops. However, we should be able to do turn on a second boost stage at ~ 0.1 Hz without eating too much phase at UGF of ~ 1 Hz. Thus this should contamination should not be too much an issue.

We edited the guardian to turn on the ISIFF in the RESONANCE stage. Will try to mitigate the contamination to the earthquake band in the future.

Peter K, Craig

We've been thinking about the stability of our CARM loop, since we recently had to lower the gain of our IMC from 100 kHz to ~30 kHz to avoid IMC locklosses.  The CARM frequency noise suppression at this level should still be fine, but we should be able to push the CARM UGF to at least 20 kHz as we acquire and the IMC should not limit us.  However, cursory investigation of the IMC yielded no immediate solutions, so a deeper look into the CARM loop is required.

Peter K took some TFs through the FSS while changing the fast gain.  Attached is the FSS OLG, TTFSS Fast (PZT) and Ultrafast (EOM) paths.  The TTFSS schematic currently in use at the LHO PSL lives here.

The FSS in it's current state seems healthy and stable.  We probably could stand to increase the UGF slightly. 

We are currently running the FSS loop with common gain of 20 dB and fast gain of 9 dB.  With those settings, we have an FSS UGF of ~200 kHz (Plot 1), which is slightly lower than before.  Changing the fast gain does not affect the UGF.
There is a gain dip at 20 kHz that develops when the fast gain is turned too high, probably as a result of the PZT fighting the EOM.

In plot 2, for gains above 9 dB, the fast gain appears to not be able to further amplify the fast signal.  In plot 3 we see the 20 kHz hump develop in the ultrafast EOM path as we increase the PZT gain.

I parked the temperature where seed and pump transmission had dual resonance (at 32.16 C). Later fine tuned temperature for best NLG while looking at CLF 6 MHz beat note level. The dual resonance for maximum CLF amplification is 32.06 C. The dual resonance outside non-linear gain region for seed is 41C.

The CLF 6MHz beat note is now at -10 dBm. The loop hasn't been characterized yet.

[Hang, Gabriele, Sheila, Jenne, Georgia, PatrickG, Marc, Alex-the-job-shadow-student]

Summary: As a result of being concerned that the CARM transition to TR signals doesn't work when the green WFS have high bandwidth (we failed twice this morning, in addition to the night crew's several), we looked a little more closely at the green WFS.  For most of the morning we thought that the Yarm WFS A had a problem, but in the end it looks like there was a filter setting that should be the same for all 4 WFS (X A&B, Y A&B), but this lowpass filter was on for 3 of them, and not on for one.  So, when I looked at the WFS outputs after this filter bank, we were seeing differences.  As part of our diagnostics, we removed the HWPs that had been temporarily put in on the Yarm when trying to figure out the DIFF glitches (see alog 42978). 

The filters that are different are 0.3Hz lowpasses that are limiting the bandwidth of the WFS loops.  They should be off for all the WFS, but the were only off for Yarm WFS A.  This made the PIT and YAW outputs of WFS A look more noisy in comparison to the others.  These lowpass filters were on throughout O1 and O2, but Hang's new WFS designs should have them off. 

Tomorrow morning, in parallel with TCS work, we'll likely work more on increasing the bandwidth of the green WFS loops.  Hang has been doing a bunch of good design work today, and we should know the settings that we need to try out tomorrow.  This will hopefully make the first part of initial alignment much faster than the ~45 minutes it sometimes takes for the loops to converge right now. 

For tonight, we're sticking with the low bandwidth version that we've been using so that we can work on locking. 

As a follow-up investigation, Gabriele is looking at the digital loops that we use to center the input green beam.

Commissioning team

This morning we removed the half waveplates from the Y-arm green path that were installed on July 19. These were installed in an attempt to remove ALS COMM glitches (alog-42978), but they did not fix that problem. There was one waveplate on ISCT1, and one on the ALS table, between the periscope and the polarising beam splitter that combines the ALS and HWS paths.

We removed the waveplates because we thought that there was additional noise on the Y-arm WFSs after their installation but this turned out to also be unrelated.

E. Bonilla,
 

I took a couple passive transfer functions to see if the ISIFF was behaving well after a month of being installed at ETMX and ITMY (LHO:42906) .

The subtraction at the microseism is still good after a month of operation, as can be appreciated both in the transfer functions and the coherence in the attached figures:
In the figures, the Red (and Magenta) traces correspond to no FF, the Blue (and cyan) ones correspond to FF on.

For ITMY we can see that the filters still achieve good performance at the microseism. However, below ~50 mHz the ISIFF seems to hurt rather than help.

For ETMX it is good from 0.2-0.6 Hz, but it is not good below 0.2 Hz. These behaviors were also observed for ETMY when ISIFF is used together with the ALS (LHO:43114)

   Georgia transitioned the End-Y VEA to laser hazard.

Terry, Nutsinee

A pick-off mirror is mounted on a manual Thorlabs flipper. The beam is then sent to a non-polarizing beam splitter then to Thorlabs PDA100A and a camera. They are there for additional/optional diagnostic so they're there for good. The PD is temporary hooked up to CH3 of the mad box (in place of CLF) for co-resonance temperature tuning.

Edgard, Hang.

On Tuesday, we designed and installed the ISIFF filters for ITMX. The procedure followed was similar to the one described in LHO:42875.

The attachment shows the filter installed in the ISIFF_L2P filter bank. The data points correspond to (ISI-L --> L3OPLEV_P)/(M0-P --> L3OPLEV_P), while the orange trace was fitted using IIRational.

The fitting code only used data points with a coherence >0.5, which was set as an arbitrary cutoff. The fit is reasonably good up to ~1 Hz.

More details on the performance of the filter, as well as information on the script used for the fitting will be posted soon.

_______________________________________________________________________________________________________________

I have run a 2W ITMX CO2 test from 07:05:41 UTC to 07:08:32 (and briefly sent in 2.8 Watts a few minutes before that). Then I remembered to shutter ALS and ran a 1 minute 1W test at 07:17:41 UTC (1218439079)

I have also scheduled ITMX and ITMY ring heater tests, for 1 hour at 3W, for 07:54:49 UTC (1218441307).

Sheila, Craig, Georgia, Hang

Durin gthe large EQ this afternoon green WFS gains were increased by about a factor of 2 or less.  For some reason, this made the TR_CARM transition fail very consistently.  We reverted them to this morning and it worked on the first try, but not the second. 

We added the ITM's back to DHARD, but on this first attempt where MICH ASC was on during CARM offset reduction and DHARD went to the ITMs didn't go well, we lost lock as the DHARD gain was ramping up once we got to resonance.  We have removed the ITMs from DHARD again.  

Peter K, Fil, Danny, TVo

TCS Electronics block diagram: E1100892

Yesterday's trouble with the CO2Y led us to investigating the RF signal chain for the laser.  Fil checked that the signal coming from the function generator in the chiller mezzanine is giving us a clean ~40.6 MHz sine wave all the way to the table.  However, once it reached a Pulse Research Lab comparator that turns the sine wave into a TTL square wave (or close to one), we found the signal did not match CO2Xs' RF signal and was an odd shape as well, it looked more like a wave packet shape instead of a square wave like we'd expect.

So we pulled the PRL comparator as well as the RF splitter/amplifier box from Access to test the units in the EE lab.  In the LVEA, the signals looked terrible but once we tested it in the lab, they seemed to do what was expected.  Then we hooked everything back up at the CO2 table and the RF signals looked a lot cleaner, even though we haven't really made any changes!.  At this point we decided to try to test out the laser out again but there were still no lasing, unfortunately.

The next steps we're going to try to debug is the RF Driver outputs to the laser, however, there isn't a lot of documentation on how this driver actually works and I'm not sure what we should expect as far as power out but we can try to compare the signals to CO2X for reference and try to narrow down what could be wrong.  The drivers and lasers are paired together so  if either are broken, we'll need to swap both and re-align the table.

Note to self: We can try to measure the control signals that enable the RF Drive, usually it's controlled by our TCS Controller box via a DB15 cable but we can test that the interlocks and gates are properly enabled with a breakout board directly at the RF driver.

We have seen this happen several times today that when we are trying to acquire DRMI the SCRL1 INPUT is not engaged.  

Here is an example of the guardian log from one of these times:

2018-08-16_02:26:16.482989Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-MICH1_SW1 => 4
2018-08-16_02:26:16.483443Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-MICH1 => ON: INPUT, OUTPUT
2018-08-16_02:26:16.484120Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-MICH2 => ON: INPUT, OUTPUT
2018-08-16_02:26:16.484522Z ISC_DRMI [ACQUIRE_DRMI_1F.main] setting gains for DRMI with arms
2018-08-16_02:26:16.484900Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-MICH1_GAIN => 2.8
2018-08-16_02:26:16.485747Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-PRCL1_SW1 => 4
2018-08-16_02:26:16.486142Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-PRCL1 => ON: INPUT, OUTPUT
2018-08-16_02:26:16.489634Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-PRCL2 => ON: INPUT, OUTPUT
2018-08-16_02:26:16.490422Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-PRCL1_GAIN => 16
2018-08-16_02:26:16.491160Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-SRCL1_SW1 => 4
2018-08-16_02:26:16.491516Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-SRCL1 => ON: INPUT, OUTPUT
2018-08-16_02:26:16.492437Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-SRCL2 => ON: INPUT, OUTPUT
2018-08-16_02:26:16.493309Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-SRCL1_GAIN => -30
2018-08-16_02:26:16.494002Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-SRCL1_SW1 => 0
2018-08-16_02:26:16.744942Z ISC_DRMI [ACQUIRE_DRMI_1F.main] ezca: H1:LSC-SRCL1 => OFF: OFFSET
2018-08-16_02:26:30.405918Z ISC_DRMI [ACQUIRE_DRMI_1F.run] flashed, waiting to proceed
2018-08-16_02:26:30.410829Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] = 0.5
2018-08-16_02:26:30.916934Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] done
2018-08-16_02:26:58.930257Z ISC_DRMI [ACQUIRE_DRMI_1F.run] flashed, waiting to proceed
2018-08-16_02:26:58.930964Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] = 0.5
2018-08-16_02:26:59.430789Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] done
2018-08-16_02:27:20.292016Z ISC_DRMI [ACQUIRE_DRMI_1F.run] flashed, waiting to proceed
2018-08-16_02:27:20.292626Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] = 0.5
2018-08-16_02:27:20.793482Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] done
2018-08-16_02:27:51.890241Z ISC_DRMI [ACQUIRE_DRMI_1F.run] flashed, waiting to proceed
2018-08-16_02:27:51.891743Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] = 0.5
2018-08-16_02:27:52.393734Z ISC_DRMI [ACQUIRE_DRMI_1F.run] timer['lockpause'] done
 

Attached is also a plot of SRCL1_SWSTAT and the guardian state at this time, from Aug 16 2018 02:26:14 UTC on the SRCL1_SWSTAT is 37632, which is:

FM9
FM10
OUTPUT
DECIMATION

The input really was off, Hang manually turned it on.