J. Kissel, reporting for  F. Clara, R. McCarthy (Tappers), J. Driggers, S. Dwyer T. Shaffer (Witnesses), K. Kawabe (Photographer)

After pictured recently by Keita (LHO:46607), Richard and Fil drive down to similar spots along the exposed Y-arm communication fiber bundle -- which includes the PSL to ALS laser optical fiber connection -- and tapped on it while we happened to be locked on ALS.

The attached screenshot shows a time series of (among other things) the Y ARM power transmission in green laser power [Brightest Orange Trace], usually the canary in the coal mine when we're having "ALS glitches" and "it's raining." A T=16 sec are the beginnings of taps. At T=0 sec are the most invasive taps. At T=+11 sec there is more tapping. The times are all around 2019/01/24 19:05 UTC. These taps, and corresponding response of the Y arm transmitted power are representative of the range of impact that we've seen that impacts locking of ALS, which has cost us many an evening of frustration. 

This is likely the source of *some* (if not all) problems with ALS glitches, and was associated with rain (presumably the wind / rain would cause the same level of tapping Richard and Fil were inducing).

This issue is related to the following FRS Tickets: FRS:11113, FRS:12209

Previous reports of ALS Y vs. Rain: LHO:46554, LHO:46302, LHO:45924, LHO:45891

I've examined the time series of the control signal to the ETMX ESD, which is being used alone to control the DARM degree of freedom. There is some evidence the dynamic range might be too small. Every time the ESD control signal nears the end of its dynamic range (+/-2^19), an IFO glitch occurs, but the ESD signal does not rail every time a glitch occurs. This would suggest that an insufficient ESD actuation range is, at worst, one of several causes of glitching. It's worth investigating further.

I've written a code for scanning past actuator-channel data and identifying saturation events. It generates an ASCII catalog containing the timestamp and value of every saturation occurring within a specified time range. It filters data based on Guardian state to only include data taken during "low noise" operation.

https://git.ligo.org/jonathan.richardson/dac_saturation_scanner

The figure below was generated using this code for a 6-hour lock on Jan. 13.

In the attached, top two traces  are EPICS of the HAM6 fast shutter readback (top is the state of the shutter, next one is the trigger voltage, threshold is set to 2V). According to these, the shutter was triggered between -0.2 and -0.13 second.

If you look at the bottom two traces (ISI sensors to listen to the banging of the toaster and OMC PZT voltage readback), the actual triggering time was at around 0 second.

I've pushed a change to the DetChar summary pages that adds a spectral comparison of the following intermediate data products from calibration:

• CAL-DELTAL_EXTERNAL_DQ
• CAL-DELTAL_RESIDUAL_DBL_DQ
• CAL-DELTAL_CTRL_UIM_DBL_DQ
• CAL-DELTAL_CTRL_PUM_DBL_DQ
• CAL-DELTAL_CTRL_TST_DBL_DQ

An example is available here with the plot attached below; this should be up on the summary pages within an hour.

• Found IFO trying to acquire DRMI, wasn't well enough aligned to catch.  Far enough from catching that normal low-level alignment tweaks weren't getting me close enough, so doing an initial alignment.
  • Notable thing: I had to move the PR3 sliders a lot more than usual, and moved both pit and yaw. Often this optic doesn't need  touching, but today I moved it by about half a microradian in each pitch and yaw.
• Still couldn't catch even PRMI lock with good flashes.  Looked at error signal, and there's nothing there.
  • Out on the floor, the REFLAIR_9 RF_In at the demod board was totally loose, and making no electrical connection at all.  After I grabbed the torque wrench to tighten it, I had a mini-campaign of checking SMA connections, and several other REFL connections were finger tight but not torqued.  All the POP diodes seemed okay. 
• I spent some time this morning trying to get a better measure of DHARD_P, while we were in the POWER_30W state. 
  • First figure, plot_ASC-DHARD_P.png shows the OLG as-is, with several measurements stitched together.
  • Second figure, plot_ASC-DHARD_P_new.png shows the same data in blue.  In orange, that data is multiplied by a gain factor of 0.9, and FM4 (the less aggressive cutoff filter).  You can see that if we didn't lower the gain, we'd ring up an instability by just engaging FM4. 
  • After these measurements, I let the guardian do LOWNOISE_ASC, which currently has no gain or filter changes for DHARD_P. 
  • I have by-hand done this, first lowering the gain from -50 to -45, and then engaged FM4. 
  • Seems good, and I have gone up to NomLowNoise and handed the IFO off to JeffK for some calibration measurements.
• New DHARD_P settings are in the guardian, in LOWNOISE_ASC.

TITLE: 01/25 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    Wind: 7mph Gusts, 5mph 5min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.24 μm/s
QUICK SUMMARY: Locked at 30W with Jenne hard at work.

Koji, Georgia, Craig

This evening we ran several tests of the electronics handling the CARM signal around the PSL racks.

----------------------------------------------
Analog to Digital REFL Calibrations
----------------------------------------------

We looked at a bunch of peak values while injecting a 9.101 MHz sine wave into the demod boards.

Our biggest confusion was probably the factor of 500 response difference of the REFL A and B 9 demod boards to the same input signal.
We unplugged and terminated the signal coming from the photodiodes, and set the Agilent to give a 9.101 MHz, -20 dBm signal into RF In on each demod board.  Then we read out the signal seen on REFL {A,B} {I,Q} MON demod board analog outputs, as well as the digital channels.  Peaks read out with flattop windows power spectra, not PSDs.

Channel                          Response
----------------------------------------------
H1:LSC-REFL_SERVO_ERR_OUT_DQ     1.59e-3 cts
H1:LSC-REFL_A_RF9_I_ERR          4.38e-1 cts
REFL A 9 I analog monitor        346.7 μVrms

Moved injection to REFL B RF In:

H1:LSC-REFL_B_RF9_I_ERR          1.17e-1 cts
REFL B 9 I analog monitor        120.0 mVrms

Moved injection to REFL A RF In again:

REFL A 9 I analog monitor        340.3 μVrms
REFL A 9 Q analog monitor        342.1 μVrms

Moved injection to REFL B RF In again:

REFL A 9 I analog monitor        120 mVrms
REFL A 9 Q analog monitor        120 mVrms


Demod boards are DCC D1000181, Serial numbers are S1000772 for REFL A, S1000771 for REFL B.

We also note the frequency response ratio of CARM OUT2/REFL A 9 I analog monitor = 13.1 dB, while the Sum Node A Input 2 gain = 8 dB and CMB IN1 gain = 6 dB.  Not bad.

----------------------------------------------
CARM Circuit Voltage Noise
----------------------------------------------

Basic CARM Path
9 MHz Beatnote ---------> REFL A PD ---------> REFL A 9 Demod Board ---------> Sum Node ---------> Common Mode Board (CMB) ---------> IMC Board ---------> IMC VCO


We measured the intrinsic electronics noise of the REFL A demod board, Sum Node, and first part of the Common Mode Board.  Sum Node A Input 2 gain = 8 dB, CMB IN1 gain = 6 dB.  We preamplied the circuit signal by 100 with an SR560 to avoid the SR785 noise floor.  We took four sets of spectra:
1) Demod RF In 50 Ω terminated, CMB OUT2 measured
2) Sum Node A Input2 50 Ω terminated, CMB OUT2 measured
3) CMB Input1 50 Ω terminated, CMB OUT2 measured
4) Demod RF In 50 Ω terminated, REFL A 9 I analog monitor measured

The (scaled to remove the SR560 gain) results of these measurements are shown in attachment one.  It appears that the worst circuit noise originates in the Sum Node.  
The big hump in the dark orange spectrum is probably a random RF line wandering through DC during our measurement, it is not present in the other measurements at low frequency.

During these measurements with OUT2, we noticed an mysterious peak wandering around at 60-80 kHz.  Georgia was able to toggle the frequency of the line with the Sum Node B Input1 being turned on and off, even though IN2 on the CMB was NOT connected.

----------------------------------------------

What does any of this mean for the CARM path?  The question came up when I measured REFL A 9 IMON and CARM OUT2 paths, and found that CARM OUT2 had lower noise than REFL A 9 IMON would have predicted. (red and blue in attachment two)
All it likely means is there is some additional sensing noise in the CARM path that we are just now understanding.  
Also somehow the responses of REFL A and B analog monitors are vastly different to the same input.

J. Kissel

I've used the results from recent ETMX actuation function measurements (LHO:46605) and Sensing Function measurements (LHO:46632) to build a parameter set for the current (well, at least the 2019-01-18, last week Friday) interferometer's DARM loop:
    /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/params/modelparams_H1_20190118.py

The attached plot shows the result of comparing this loop model against the 2019-01-18 measurement. One can see a frequency-dependent ~5% wiggle in magnitude, and a phase discrepancy increasing with frequency up to 10 deg by 1 kHz. 

Comments and (educated) guesses as to what's going on:
    - 10-40 Hz Magnitude: We don't have the actuation gains just right and/or the frequency-dependent ripples are a result of the similar ripples in the PUM and TST stages of the actuator measurements. As mentioned in LHO:46605, 
"" We have not measured, and thus not well-compensated, any stage of SUS ETMX's driver electronics. We're still using the "off-the-shelf," "same compensation for each quadrant" compensation. ""
    Once we clean up these known systematic errors in the actuator (I'm schedule to take over EX next-week-Tuesday to gather the neccessary measurements), then we should be able to better estimate the gain of these two stages and I suspect we'll reduce the residuals in this frequency band.
    - 330 Hz Magnitude: We still have a massive notch in the DARM loop around 300 Hz for (a) the calibration line frequency, and (b) the beam splitter violin modes. It's not really important that we get this particular frequency right.
    - >500 Hz Magnitude and Phase: It's not clear to be yet what's going on here. At these frequencies, it's either the DARM loop filter or the Sensing Function accuracy, and the sensing function is accurately measured and fit to within 1% and 1 deg. Further, the high frequency data from the PCAL 2 DELTAL sweep (left panels of second attachment from LHO:46632 indicates that there's nothing wrong with the sensing function from 2018-12-05 (the post-ER13, 20W, split actuator model, as long as it's scaled to match the optical gain). I've, of course, checked that I've recreated the DARM loop filters correctly, but I can't find any issue as of yet. 

As mentioned in the aLOG documenting the processing of the sensing function, and in addition to cleaning up the actuator, I'd really like to get a open loop gain TF with more densely populated frequency points to help understand what's going on at low frequencies. Hopefully the high frequency issue is just a bug in the analysis script somewhere, and I can clean that up once I sleep on it over night.

J. Kissel

Using data taken by Sheila last week Friday (LHO:46537), I've fit that day's sensing function (for a 30W IFO, with all actuation on ETMX) and now have new values for its parameters. As always, there are a caveats. Details below. 

Var.  Units    Value      Abs. Unc.             Rel. Unc.              Description
------------------------------------------------------------------------------------
H_c   (ct/m)   3.046e+06  (+1421,-1420)         (+0.04665%,-0.04661%)  Optical gain,            
H_c   (mA/pm)  3.77       (+0.001759,-0.001757) (+0.04665%,-0.04661%)  Optical gain,            

f_cc  (Hz)     424.9      (+1.042,-1.05)        (+0.2453%,-0.247%)     Cavity pole,             

f_s   (Hz)     0.2573     (+0.261,-0.1148)      (+101.5%,-44.63%)      Detuned SRC spring frequency
Q_s   (  )     0.4263     (+0.3431,-0.2164)     (+80.48%,-50.77%)      Detuned SRC spring quality factor   

tau_c (usec)   3.299      (+0.5827,-0.5765)     (+17.66%,-17.47%)      Residual time delay

The four attached plots support this information:
pg 1: the MCMC fit compared against the data
pg 2: the same plot, but with me copying the MCMC fit results into the 20180118 parameter file, and thus showing the model against the data (essentially just proving that I can copy-and-paste with good fidelity)
pg 3: the guassian process regression of the residual between model and measurement which would quantify any unmodeled systematic error (there are none -- the residuals are consistent with unity magnitude and zero phase)
pg 4: a corner plot of the MCMC fit showing the covariance of the parameters

Several comments:
(1) The fit detuned optical spring is completely bogus. I don't believe it! The fit is essentially saying there's no SRC detuning, which H1 has never seen. What has happened: In order to minimize time with the IFO, I created a set of measurement templates with a frequency vector that was sparse at low frequencies. Thus, there are only 2 data points below ~15 Hz, and they're of high uncertainty -- resulting in a poorly informed fit for this 5-10 Hz, low frequency feature. I'll change this for the next round of templates.

(2) The optical gain is reported in both (DARM IN1) / (DARM DELTAL), [ct/m], as well as (OMC DCPD Current) / (DARM DELTA L), [mA/pm] ("milliAmperes per picometer"). The latter is merely the former divided by the transfer function value between OMC_DCPD_SUM_OUT_DQ and LSC-DARM_IN1_DQ at 5 Hz, at the time of the PCAL sweep. That value is 1.23781e6 [mA/ct] (and then the meters are converted to picometers). However, the calibration of the OMC DCPDs into [mA] is NOT an accurate, rigorously verified calibration, and thus neither is the [mA/pm] number, so be wary of making any precise statements when using this number. I suspect it's good to the 10-20% level.

Other than this -- I'm pretty happy with the accuracy of the model -- roughly 1% in magnitude, and 1-ish degrees in phase. Nice! 

I'm actually a little surprised by this because we haven't updated any of the uncompensated OMC DCPD whitening chassis poles after modifying the the whitening stage (Jun 2018, LHO:42361); we're still using the average frequencies of the two DCPD paths from LHO:28087 -- 14.47 kHz, 18.625 kHz and 99.695 kHz. Maybe these poles come from a part of the chassis that wasn't modified. We know that the transimpedance amplifiers' poles at 13.7 and 17.8 kHz have not changed since O2, so these need not change. And I guess if the model matches the data, who am I to argue!

Using these results -- If we *must* update the sensing path immediately, one can install the following foton string in the H1:CAL-CS_DARM_ERR bank (please do it in a different filter bank, don't over-write what's in the "O3_D2N" and "O3Gain" filters that are in use).
   D2N filter (SRCD2N): zpk([424.8532;0.2094;-0.3190],[0.1;0.1;7000],1,"n")gain(6.68)
           Gain filter: gain(3.283e-07)
(and needless to say, one should make the EPICs gain of the filter 1.0).

I would prefer to have a complete DARM loop model that matches the total DARM open loop gain transfer function before launching forth with the install. 
SPOILER ALERT -- I've already made the plot, and model doesn't match the data in a frequency-dependent ~5% wiggle in magnitude, and a phase discrepancy increasing with frequency up to 10 deg by 1 kHz. More details in a subsequent aLOG.

Slow output to the laser is now coming from the PFD TTFSS. That part seems to be working fine. I can't seems to stop the error signal from saturating. I stacked 20+10 dB attenuator at the RF input but no luck. RF mon is showing the 158MHz beat note at -22dBm on the RF spectral analyzer. The power okay icon shows read and the beat note strength read back is wrong. 

Also attached drawings of what we had and what's supposed to happened next (with doodles on it).

TITLE: 01/24 Day Shift: 16:00-00:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY: Commissioning continues. Wind and microseism are low.
LOG:

1550 Chris S moving forklift near X arm past OSB
1739 Kara to EY to troubleshoot shaker
1820 Chris S to EY fan room
1827 Kara back
1836 Dave restarting broadcaster
1846 Richard, Fil to drive inside of arms
1905 Richard, Fil poking ALS fiber
2012 Richard, Fil back
2042 Nutsinee to ISCT6
2235 Amber and guests to drive on the overpass
2302 Kara to EY to check on shaker
2322 Kara back

Sometimes it seems like the FSS gets noisy, and I don't think anything else is happening in the IFO.

I caught it happening again, and am posting a quick time series and spectrum to show that it's definitely changing.  Does anyone in PSL-land know what this might be?  Perhaps (as Sheila suggests) someone could take a look at PSL PEM sensors to see if anything changed in there?

Nutsinee Daniel

Sometime back Marc implemented the changes of ECR E1800041 to the spare VCXO D1600500 with S/N S1700238. We then promptly forgot about it, until we encountered a calibration discrepancy in the VCXO drive that indicated that we were missing a factor of 1/25 in gain. Today, we swapped the current unit S1700237 with the spare, which eliminates the 1.6Hz/40Hz pole-zero pair and uses an AT cut crystal. As an added benefit we now need a lot less gain in the CLF CM board and the DAQ readbacks no longer overflow.

As is apparent in alog 46530, DARM calibration is off by about 10% at 100Hz, and it's hard to make comparison between now and Dec 2018 as is until a good calibration model is made.

I made a FOM dtt template with two new calibrations, one starting December 08 2018 and the other Jan 01 2019.

/opt/rtcds/userapps/trunk/isc/h1/scripts/H1_DARM_FOM_PcalScanCorrected.xml

It should be OK for f>10Hz.

What I did:

From dtt, export CAL-DELTAL_EXTERNAL_DQ/CAL-PCALY_RX_PD_OUT_DQ transfer function of

/ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/O3/H1/Measurements/FullIFOSensingTFs/
        2019-01-16_H1_PCAL2DARM_TF_5t1100Hz_3min.xml

to a text file in /opt/rtcds/userapps/trunk/isc/h1/scripts/tempCalibForDtt20190123/.

Export the default TF calibration of the above transfer function to another text file.

Export the latest calibration of CAL-DELTAL_EXTERNAL_DQ dated 2018/10/4 22:28:48 from H1_DARM_FOM.xml to yet another text file.

Combine these three files and save into yet another file (newstopgapcal.txt) using

/opt/rtcds/userapps/trunk/isc/h1/scripts/tempCalibForDtt20190123/makeStopGapCalForDtt.m

Do the same for 2018-12-05_PCAL2DARM_TF_5t1100Hz_2min and save into yet another file (oldstopgapcal.txt).

Open DARM_FOM.xml using dtt.

Make a new calibration for H1:CAL_DELTAL_EXTERNAL_DQ at 2019 Jan 01 00:00:00.

Click "Trans. Func." tab, click "Edit", click "File" and "Open", load newstopgapcal.txt.

Repeat it, this time 2018 Dec 08 00:00:00, load oldstopgapcal.txt.

Save the dtt template as H1_DARM_FOM_PcalScanCorrected.xml

Following on from yesterday's attempt.  I made transfer function and spectra measurements with the input modecleaner locked and
unlocked.  In summary, there wasn't too much difference in the noise spectra above 100 kHz with the input modecleaner locked
or unlocked.

    Attached are transfer function measurements when the input mocdecleaner was unlocked and locked respectively (IMCULKD1.tif,
IMCLKD1.tif).  The noise spectra measurements are IMCULN1.tif and IMCLN1.tif respectively.  The mixer calibration was measured
to be 1.93/77.4 V/kHz.

    More to follow ...