ISS

Yesterday I tried to get some pieces of the puzzle as to why the second loop ISS is not suppressing as
it should.  Starting off with the first loop.

    I confirmed that there are only 4 positions of the half waveplate in 360 degrees that correspond
to maximum output of one of the ISS photodiodes, PDA in this case.  There is no reason to believe why
this would be any different for PDB.  The positions of the rotation stage were 90 degrees apart,
indicative of the half waveplate rotating the plane of polarisation as it should.  Naively this would
confirm that only one polarisation is incident on the photodiode.  As a check a polarising beamsplitter
cube was inserted between the two mirrors that steer the output of the pre-modecleaner into the ISS
PD box.  Oriented to transmit horizontally polarised light, no reflected light was observed when an
IR viewer was used.  This would seem to confirm that there is only one output polarisation.  This
does not explain the lack of suppression with the second loop however.

    The UGF with the gain slider at 8.0 was measured to be 82 kHz with a phase of -170.6 deg.  Looking
at the power noise at 1 kHz, there was ~50 dB of suppression (as measured by the out of loop photodiode
PDA) with the integrators off.  With the integrators on, there did not appear to be any extra noise
suppression.  With the gain slider at 0.0, the UGF was 33.7 kHz with a phase of -137.4 deg.  At 1 kHz
there was ~40 dB of suppression with the integrators off and somewhere between 2 and 3 dB more with the
integrator on.

    The polariser was subsequently removed and the hardware restored.

Powering up tonight

Craig, Georgia

We tried to get back to high power tonight, but had three sudden death locklosses in CARM_TO_ANALOG.  Georgia tracked it down to ramping the SumNode A IN2 gain from 0 dB to 23 dB.
We took a bunch of CARM OLG measurements, and found that at 23 dB, we would put the CARM UGF directly on a notch.  
We lowered the max SumNode A IN2 gain from 23 to 17 dB in the guardian state, giving a UGF of 9 kHz.

We also noticed that the compensation filter on the LSC servo board (LSC-REFL_SERVO_COMCOMP) turn-on was still commented out in this state, which probably allowed the 1 Hz CARM oscillation we saw today.  We left it commented in guardian since we got through the state by hand.

Changed ISC_LOCK guardian code to reflect the new early shuttering of ALS:


State           Old Number     New Number
PARK_ALS_VCO            451            306
SHUTTER_ALS             452            307
CARM_OFFSET_REDUCTION   306            308
CARM_5_PICOMETERS       307            309

Powered up to 22W

Georgia, Craig, Stefan, Thomas, Danny, Stefan, Hang, Sheila

We powered up to 21 Watts input power, and were stable there for 10 minutes.  We lost lock powering up to 24W input power, but that may have been due to a transient that saturated the test masses while we are increasing the power. 

• We are using different soft offsets than what we had set at 2W input power, we probably just need to check for good offsets after powering up and set them that way.  
• Our power recycling gain at 2 W input power is 50.  We recalibrated the LSC_PR_GAIN channel based on the average of the two TR_X_NORM channels.  
• After powering up to 10 W at 3:44 Sept 26 UTC , we sat for about 25 minutes and our TCS team reduced the CO2 powers to 200mW CO2X and no power on CO2Y.  The AS power looked better and the OPO power became more stable with the reduced CO2, but we think that we overshot a little. 
• We powered up to 22W and were stable there for a bit over 10 minutes.  
• At each power increase step we saturated the suspensions.  We tried turning of the violin mode damping, and tried engaging the low pass on the power normalization.  We continued to saturated
• Based on the newly calibrated circulating power monitors there was 7kW in the X arm and 6 kW in the Y arm at 2W input power.  The asymmetry in the two arm powers seems suspicious. but as we powered up the recycling gain dropped to 43, the Y arm power was reported as 77kW while the X arm power was reported as 60kW.  
• We lost lock probably due to one of the saturations/transients as we tried to step the input power to 26W.  
• We left both the SRC ASC loops off while powering up, and at 10W we checked the lock point of BS, which seemed fine at that power.  The SRM error signal was still zero'd after powering up to 10W,, at 20W we saw a slow drift.  

Things that we want to do:

• Engaging the CARM boost
• Running A2L which might help prevent the saturations as we increased the power.  
• Phasing AS36 and AS72 and checking the lock point and sensing for BS and SRM after we power up. 
• Engaging the OMC low pass while we are locked on RF
• Centering the IMC WFS.

We've been struggling with ALS-X glitches again tonight, so on Keita's advice we looked at the X-end laser.
Laser diode power monitor 1 seems to become twice as noisy, but it's very hard to tell with the slow monitor channels.  
The glitches went away again, but it could be worth it to investigate the X-end laser itself the next time we see these glitches.

Laser frequency correction now feeds to OPO PZT

Daniel, Terry, Nutsinee

Yesterday we installed a PFD to (phase) lock our 158MHz VCO with the beat note (alog44135). As the result we now have a frequency correction signal to send to OPO PZT. This signal comes out of Dual Dsub Patch Panel (third from the left), goes through a 10Hz lowpass blue box (with gain of -10), and into in-vac PZT driver. In addition Terry also swapped the fibers from PSL at ISCT6 feed through after realizing that it was plugged in wrong (from the PSL end I think) so that the PSL that's used for beat note is 158MHz shifted coming in and the PSL LO has been down shifted (0Hz) coming in (which would be the same as what goes into the IFO). We also put back the motorized half waveplate we borrowed from the PSL beat note path. 

 

Next thing to do is to include feed forward from IMC VCO in the frequency locking loop. Once that's done we should be ready for 3MHz hand-off.

Common mode board error signal not saturating, but shows 1.1Hz residual oscillation

We looked at the common mode board error signal tonight to see whether we might be saturating the board. That turned out to be not the case.

However, we noticed a 1.1Hz signal in the error point, and realized the the CM board boost filter is not on yet.  

For Gabriele: DHARD works (once we turned off the new radiation pressure compensation filter banks in the ASC...)

Not much to add... sigh.

LSC / ASC Photodiode Electronics Dark Offsets Measured and Set

J. Kissel, reporting for the Commissioning Vanguard

Suspicious about problems with spurious CARM offset (see LHO aLOG 44134), and what electronics work was done today (was there really? not sure), the team re-ran the following script that measures the voltage offset on IR photo diodes in the absence of light (a.k.a the "Dark Offsets") and installs compensating digital offset in the corresponding segment / quadrant signal processing input filter bank (after first bringing the IMC to OFFLINE),
    /opt/rtcds/userapps/release/isc/h1/scripts/dark_offsets/dark_offsets.py

As such, there are ~30 new SDF values to accept in the LSC model, and ~120 in the ASC model, and ~8 OFFSETs in the IMCASC model, the SQZWFS model, and in the ISCEX and EY models.

I've accepted these all these new values into the SDF system. Attached is a screenshot for the LSC, IMCASC, SQZWFS, ISCEX, and ISCEY (I didn't screencap the acceptance of the ASC changes, apologies.)

CDS maintenance summary: Tuesday 25th September 2018

Recovery of front end DAQ bad status following 3am crash of h1lsc0

FRS11528

Dave:

Full details are in the separate alog. It took 90 minutes away from the CDS upgrade time to resolve this. However it was important to have a functioning FEC-DAQ system before continuing with the upgrade

CDS Upgrade Part-II

WP7815

Richard, Fil, Dave:

The remaining task for the CDS upgrade were completed today. The following front ends were upgraded to 8-core V4 computers:

h1lsc0, h1susb123, h1sush2a, h1sush2b, h1sush34, h1sush56

The procedure for each was:

power down computer and remove from rack

remove IRIG-B and IX-Dolphin cards, replace full-height plate with half-height (all except h1lsc0)

install cards into V4 replacement machine

put new computer into rack, connect original network, timing, IX-Dolphin.

Connect new v12 One Stop (OSS) fiber

Replace PS2 KVM cable with USB cable

In CER (Fil) pull OSS to IO Chassis, replace old OSS fiber with new.

Change DHCP to serve new computer's MAC address

Power up IO Chassis and computer, verify cards are seen and models start correctly.

Also h1oaf1 was connected to the Dolphin fabric. A new h1iopoaf1 model was started, but some Dolphin issues were encountered which will be addressed later.

The completes the CDS upgrade, many thanks to Rolf, Keith, Jamie, Richard, Jonathan, Fil, Ed for all the hard work to make it happen.

h1guardian1 reboot

T.J, Jamie and Dave:

We rebooted h1guardian1 after all the frontends had been recovered. Details in T.J.'s alog (summary: all nodes except two started)

BSC2 (Beam Splitter) digital camera

FRS-11520/FRS-11519 (duplicates)

Richard, Fil, Gerardo, Dave:

We replaced the h1cam29 digital camera (BSC2-Beam Splitter) with a new camera. Following a restart of the video server we are now getting an image from BSC2.

h1asc

Jenne, Dave:

A new h1asc model was installed.

h1sqz

WP-7835

Nutsinee, Dave:

A new h1sqz model was installed.

Beckhoff

Daniel, Dave:

Daniel has new code for C1-PLC1 (poll-corr) and C1-PLC4 (sqz). New DAQ INI files were generated.

New GDS channels

WP-7832

Thomas M, Dave:

The requested channels were added to H1BROADCAST.ini, obsolete channels were removed.

DAQ restart

Dave:

DAQ was restarted for all the the changed above which needed it.

Stopped auto DIAG_RESET

Dave:

Now that we do not expect any further front end glitching, I completed disabled the automatic reset of these (which was running as a cronjob on h1fescript0).

Shift Summary

16:00 LSC model was dead, which caused problems for a lot of other systems, delaying maintenance start

16:30 Peter transition to laser safe

16:30 Chandra to LVEA

17:00 Ed pullig HAM5 coil driver

17:00 Dave done with LSC model recovery, all corner sus, all seismic take to safe state

17:00 Marc, Dick hunting RF in racks

17:00 Chris taking HFD around site for extinguisher checks

17:30 Nutsinee, Daniel to ISCT6

18:30 Nutsinee to ISCT6

18:45 Ed to HAM7

18:45 Guardian machine reboot

19:45 Sheila, Nutsinee, Terry to PSL racks

21:30 Craig to PSL to turn off excitation

22:00 Marc to HAM6

22:30 Kyle to turn off turbo mag lev

 

 

 

 

~1535 hrs. local -> De-energized Vertex MTP (levitiation) and valved-out NEG1, NEG2 and NEG3

NEG pumps valved-out at Chandra R's request (due to nitrogen loading of , now known, air leak?)

Requested PSL Power Low; ISS AOM Diffracted Power High; ISS Reference Had New Offset after This Morning's PSL Work

J. Kissel reporting for P. King and S. Ballmer

During recovery of the IFO after this morning's CDS, PSL, and VAC work, we noticed that the reported power into the IMC (H1:IMC-PWR_IN_OUT16) was 1.6 W when we requested 2.0 W. We first suspected a mis-calibration of the rotation stage, but after some detective work by Peter and Stefan, they found that 
 - the sum of the reflected and transmitted power around the PMC (H1:PSL-PWR_PMC_REFL_OUTPUT) was also low, reporting ~54 W instead of the 61.5 W it was ~12 hours ago, and 
 - the diffracted power from the ISS AOM (H1:PSL-ISS_DIFFRACTION_AVG) was high at ~3.5% instead of 1.3% (again 12 hours ago).
Peter suspects this may be a result of a different electronics voltage offset as a result of his work this morning (aLOG pending).

To fix, they adjusted the offset to the ISS loop (H1:PSL-ISS_REFSIGNAL) from -2.1 to -2.445 V, to restore the diffracted power.

Attached is 
- A trend of the relevant channels
- The PMC overview that shows the power surrounding the PMC (now in its nominal state)
- The ISS overview showing the REFSIGNAL in the lower left corner, and the now nominal diffracted power diffracted power
- The accepting of the new offset value for the REFSIGNAL

ALS noise mitigated

After diagnosing the ALS COMM and DIFF noise as being related to beat note slip in the COMM PLL (see alog 44140), we tried to lower the COMM and DIFF PLL gains by 20dB (from +26 to +6).  This pretty much killed the excess noise. The attached plot shows both COMM and DIFF PLL locked.

We now should have more than a factor of 10 headroom on the ETM drive.

Some may recall an issue we had back in July and August when we were testing the new green arms, where the out-of-loop X-arm frequency noise measurements we were making made little sense:

In-loop COMM Frequency Noise
IR Frequency Noise measurement using COMM as out-of-loop sensor
COMM Frequency Noise measurement using IR as out-of-loop sensor

Our out-of-loop witnesses of X-arm frequency noise disagreed by about a factor of 10: COMM frequency noise was ~2 green Hz RMS, but IR frequency noise was 12.4 red Hz RMS (~25 green Hz RMS).  They also did not show the same spectral features, leading us to believe that our out-of-loop IR measurements were not limited by X-arm noise.

After Stefan reduced the COMM and DIFF PLL gain from 26 to 6 dB, the in-loop COMM frequency noise plummeted, and we start to see some of the same spectral features as seen in alog 43214.  In-loop COMM now reports 6.7 green Hz RMS noise, which is still slightly higher than the ~2 Hz reported by our out-of-loop IR witness in August.  Could be worth it to try an reduce the gain further, then redo this measurement.

Also plotted is the ETMX coil master monitor now as opposed to this morning.  ETMX actuation is greatly reduced.

Questions remaining: It doesn't make sense that the in-loop sensor would see higher noise than the out-of-loop sensor, particularly when we have proof that the COMM PLL was actuating hard on ETMX.  Could be that COMM and DIFF PLL CTRL OUT are calibrated incorrectly, further investigation required.

Here's a plot of ALS COMM and ALS DIFF control signals (H1:ALS-C_COMM_PLL_CTRL_OUT_DQ and H1:ALS-C_DIFF_PLL_CTRL_OUT_DQ that come "pre-calibrated" into um) when they have the arm cavities under control, holding with a 200 Hz and 1.4 kHz detuning offsets in place, respectively, later in the day during IFO lock acquisition. 

Assuming a conversion from frequency to length using the green wavelength, that's an offset of 
   COMM
   200 Hz * L_arm* lambda_g / c =
   200 Hz * 4000 * 532e-9 / 3e8 = 1.42e-9 m = 1.4 nm.

   DIFF
   1481 ct * (0.11802 ct / Hz)^-1 = 12549 Hz
   12549 Hz * L_arm* lambda_g / c =
   12549 Hz * 4000 * 532e-9 / 3e8 =  8.9e-8 m = 90 nm.

The COMM offset comes from H1:ALS-C_COMM_VCO_CONTROLS_SETFREQUENCYOFFSET on the COMM VCO (pre-calibrated into Hz), and the DIFF offset comes from the H1:ALS-C_DIFF_PLL_CTRL_OFFSET, which is uncalibrated ADC counts.

EDIT as a result of Daniel's comment (LHO aLOG 44163) below
P.S. now that I've found Kiwamu's LHO aLOG 20629, and compared it against the calibration filters installed in the PLL_CTRL filter bank I'm skeptical that the filters are correct.
    - Kiwamu measures 0.11802 ct / Hz.
    - The filters have gains of "cnts2V" = 3.05176e-4 V/ct and "V2Hz" = 1.90146e4 Hz/V whose product is 5.8028 ct / Hz Hz / ct. Which makes the inverse 0.1723 ct / Hz.
Thus the "pre-calibrated" ASD of the performance as reported by the DIFF PLL CTRL may in fact be too high by a factor of 6.
Thus the percent difference is 
    100*abs(0.11802 - 0.1723)/0.11802 = 45.9%
So, to correct the calibration of the H1:ALS-C_DIFF_PLL_CTRL_OUT_DQ channel, one must multiply by
    0.11802 ct / Hz
    ---------------- = 0.68497 [Hz / "Hz"] (or [m / "m"] assuming the conversion from frequency to displacement is correct).
    0.1723 ct / "Hz"
The calibration is off by a "about a factor of 2" (not the factor of 6 as mentioned in the striken comment).

One area of suspicion that would resolve the remaining discrepancy: "cnts2V" is 3.05176e-4 V/ct which is equivalent to 20 V / 2^16 ct. 
The LIGO-standard differential input 16 bit ADCs have a calibration of 40 Vpp / 2^16 ct = 6.1035e-4 V/ct, as demonstrated in T1100538.
If "cnts2V" were changed to match that value, the product would be 6.1035e-4 V/ct * 1.90146e4 Hz/V = 11.606 Hz / ct, and the inverse = 0.086166 ct / Hz. 
That reduces the percent difference to 100*abs(0.11802 - 0.086166)/ 0.11802 = 26.9% and reduces the correction factor to 0.11802 / 0.086166 = 1.3697.

Isn't it the inverse?
"cnts2V" = 3.05176e-4 and "V2Hz" = 1.90146e4 whose product is 5.8028 Hz / ct => 0.17 ct/Hz.

vertex air leak found

{Kyle, Gerardo, Chandra}

We spent Tuesday maintenance morning hunting for a big air leak causing the pressure in vacuum system to bottom out at mid e-8 Torr range, and finally found what we were looking for. The leak measures 7.3e-5 Torr-L/s of He at an original 12" CFF blank flange next to NEG #1. This is a new leak since the post O2 vent and we are still unsure how to started. The N2 gas load from this range of leak even with all six ion pumps ON (15,000 l/s total) may be too big to ignore beam tube gas noise (according to M. Zucker), so a vertex vent may be required before O3. If all goes well with the fix, we could vent and be pumping back down in one day and open beam tube gate valves ~ one week later.

The procedure for leak testing included soft closing GV 1,2, valving in main turbo, backed by leak checker (background measuring 1e-8 Torr-L/s of He), valving out four IPs and three NEGs, and then spraying flanges for many seconds each with helium. We started spraying the (new) NEG adaptors (BT side of their isolation GVs) since we saw an increase in signal last time we leak checked near the RGA, which is very near this 12" blank. Gerardo noticed an increase in signal when Kyle was spraying around NEG 1 and asked him to spray that 12" blank where the He signal rose significantly. In the end we bagged the conflat joint with ameristat and sprayed until the He signal maxed out at 7.3e-5 Torr-L/s. We also sprayed the weld at the joint where the port tube mates with beam tube, and also the short tube seam, and did not see a rise in signal. The leak is likely coming from the copper gasket knife edge. 

We valved the four IPs back into main volume but will leave NEGs valved out due to high N2 load. We scanned the RGA the entire morning to capture He rise. Text file attached - not - file size too big.

 

 

SOFT loop engagement now smooth for arbitrary large initial position offsets

The SOFT loop engagement has in the past always been a source of trouble, mostly because the initial offsets can be really big. Together with the double-integrator design (in control filters and suspension top stage filters) this usually is a recipe for disaster.

This should now be a thing of the past:

- re-ordered the filter modules to keep the switchable integrator and lead filters ahead of the always-on low-pass (see alog 44124).
- Set error point limiters before the control modules, but after the input matrix (in the blend filters) to 0.02.
- During engagement only a 0.1Hz pole integrator in FM5 (along with the DC gain, inverted plant and 10Hz LP in FM1, FM9 and FM10) are on. Plot 1 (red traces) show the total control filter frequency and step response. After this filter, we still have a gain of 2.5 and the suspension top stage 1/f integrator.
- Thus, during engagement with limiters on, the max signal to the suspensions can only be
   0.02 (limiter) x 10000 (control filter) x 2.5 (gain) = 500 cts
  This is small enough that the suspensions don't run away. Instead they perform a constant velocity move to shrink the SOFT error signals.
- The Guardian then looks for
   a) convergence of the SOFT control signals below 100cts, and
   b) convergence of the SOFT error signals below 75% of the limiter (or 0.015)
  When these conditions are met, Guardian turns the limiters off and turns on the true integrator and lead filter (changing the transfer function and step response to the blue trace in plot 1).
- Finally, after waiting for the 10 sec filter ramp time of the lead filter, Guardian turns up the gain to the nominal values of 4 for DSOFT and 6 for CSOFT.

Plot 2 shows the turn-on sequence for all SOFT control and error signals

Here is another run of the new SOFT engage code. Worked flawlessly. Also, we once tried it with the final gains (4 & 6 respectively). That worked too.