40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 217 of 341 Not logged in
ID Date Author Type Category Subject
14007   Fri Jun 22 15:13:47 2018 gautamUpdateCDSDTT working

Seems like DTT also works now. The trick seems to be to run sudo /usr/bin/diaggui instead of just diaggui. So this is indicative of some conflict between the yum installed gds and the relic gds from our shared drive. I also have to manually change the NDS settings each time, probably there's a way to set all of this up in a more smooth way but I don't know what it is. awggui still doesn't get the correct channels, not sure where I can change the settings to fix that.

14009   Fri Jun 22 18:30:21 2018 gautamUpdateSUSITMY_UL sensor

I think if the magnet fell off, we would see high DC signal, and not 0 as we do now. I suspect satellite box or PD readout board/cabling. I am looking into this, tester box is connected to ITMY sat. box for now. I will restore the suspension later in the evening.

Suspension has now been restored. With combination of multimeter, octopus cable and tester box, the problem is consistent with being in the readout board in 1X5/1X6 or the cable routing the signals there from the sat. box.

• Tester box hooked up to sat box ---> UL coil still shows 0 in CDS.
• Tester box hooked up to sat box ---> Mon D-sub on sat box shows expected voltages on DMM. So tester box LEDs are being powered and seem to work.
• Sat box re-connected to test mass ---> Mon D-sub on sat box shows expected voltages on DMM. So OSEM LEDs are being powered and seem to work.
• Sat box remains connected to TM ---> Front panel LEMO monitor points on readout board shows 0 for UL channel, other channels are okay.
 Quote: We may lost the UL magnet or LED

14012   Sun Jun 24 20:02:07 2018 gautamUpdateSUSSome notes about coil driver noise

Summary:

For a series resistance of 4.5 kohm, we are suffering from the noise-gain amplified voltage noise of the Op27 (2*3.2nV/rtHz), and the Johnson noise of the two 1 kohm input and feedback resistances. As a result, the current noise is ~2.7 pA/rtHz, instead of the 1.9 pA/rtHz we expect from just the Johnson noise of the series resistance. For the present EX coil driver configuration of 2.25 kohm, the Op27 voltage noise is actually the dominant noise source. Since we are modeling small amounts (<1dB) of measurable squeezing, such factors are important I think.

Details:

[Attachment #1] --- Sketch of the fast signal path in the coil driver board, with resistors labelled as in the following LISO model plots. Note that as long as the resistance of the coil itself << the series resistance of the coil driver fast and slow paths, we can just add their individual current noise contributions, hence why I have chosen to model only this section of the overall network.

[Attachment #2] --- Noise breakdown per LISO model with top 5 noises for choice of Rseries = 2.25 kohm. The Johnson noise contributions of Rin and Rf exactly overlap, making the color of the resulting line a bit confusing, due to the unfortunate order of the matplotlib default color cycler. I don't want to make a custom plot, so I am leaving it like this.

[Attachment #3] --- Noise breakdown per LISO model with top 5 noises for choice of Rseries = 4.5 kohm. Same comments about color of trace representing Johnson noise of Rin and Rf.

Possible mitigation strategies:

1. Use an OpAmp with lower voltage noise. I will look up some candidates. LT1028/LT1128? LISO library warns of a 400 kHz noise peak though...
2. Use lower Rin and Rf. The values of these are set by the current driving capability of the immediately preceeding stage, which is the output OpAmp of the De-Whitening board, which I believe is a TLE2027. These can source/sink 50 mA according to the datasheet . So for +/-10V, we could go to 400 ohm Ri and Rf, source/sink a maximum of 25mA, and reduce the Johnson noise contribution by 40%.

I've chosen to ignore the noise contribution of the high current buffer IC that is inside the feedback loop. Actually, it may be interesting to compare the noise measurements (on the electronics bench) of the circuit as drawn in Attachment #1, without and with the high current buffer, to see if there is any difference.

This study also informs about what level of electronics noise is tolerable from the De-Whitening stage (aim for ~factor of 5 below the Rseries Johnson noise).

Finally, in doing this model, I understand that the observation the voltage noise of the coil driver apparently decreased after increasing the series resistance, as reported in my previous elog. This is due to the network formed by the fast and slow paths (during the measurement, the series resistance in the slow path makes a voltage divider to ground), and is consistent with LISO modeling. If we really want to measure the noise of the fast path alone, we will have to isolate it by removing the series resistance of the slow bias path.

Comment about LISO breakdown plots: for the OpAmp noises, the index "0" corresponds to the Voltage noise, "1" and "2" correspond to the current noise from the "+" and "-" inputs of the OpAmp respectively. In future plots, I'll re-parse these...

 Quote: I will upload more details + photos + data + schematic + LISO model breakdown tomorrow to a DCC page.

14019   Tue Jun 26 16:28:00 2018 gautamUpdateSUSCoil driver protoboard characterization

I wanted to investigate my coil driver noise measurement technique under more controlled circumstances, so I spent yesterday setting up various configurations on a breadboard in the control room. The overall topology was as sketched in Attachment #1 of the previous elog, except for #4 below. Summary of configurations tried (series resistance was 4.5k ohm in all cases):

1. Op 27 with 1kohm input and feedback resistors.
2. LT1128 with 1kohm input and feedback resistors.
3. LT1128 with 400 ohm input and feedback resistors.
4. LT1128 with 400 ohm input and feedback resistors, and also the current buffer IC LM6321 implemented.

Attachments:

Attachment #1: Picture of the breadboard setup.

Attachment #2: Noise measurements (input shorted to ground) with 1 Hz linewidth from DC to 4 kHz.

Attachment #3: Noise measurements for full SR785 span.

Attachment #4: Apparent coupling due to PSRR.

Attachment #5: Comparison of low frequency noise with and without the LM6321 part of the fast DAC path implemented.

All SR785 measurements were made with input range fixed at -42dBVpk, input AC coupled and "Floating", with a Hanning window.

Conclusions:

• I get much better agreement between LISO and measurement at a few hundred Hz and below with this proto setup. So it would seem like the excess noise I measure at ~200 Hz in the Eurocrate card version of the coil driver could be real and not simply a measurement artefact.
• I am puzzled about the 10 Hz comb in all these measurements:
• I have seen this a few times before - e.g. elog13655.
• It is not due to the infamous GPIB issue - the lines persist even though I disconnect both power adaptor and GPIB prologix box from the SR785.
• It does not seem to be correlated with the position of the analyzer w.r.t. the DC power supply (Tektronix PS280) used to power the circuit (I moved the SR785 around 1m away from the supply).
• It persists with either of the two LN preamp boxes available.
• It persists with either "Float" or "Ground" input setting on the SR785.
• All this pointed to some other form of coupling - perhaps conductive EMI.
• The only clue I have is the apparent difference between the level of the coupling for Op27 and LT1128 - it is significantly lower for the latter compared to the former.
• I ruled out position on the breadboard: simply interchanging the Op27 and LT1128 positions on the breadboard, I saw higher 10 Hz harmonics for the Op27 compared to the LT1128. In fact, the coupling was higher for the DIP Op27 compared to an SOIC one I attached to the breadboard via an SOIC to DIP adapter (both were Op27-Gs, with spec'ed PSRR of 120 dB typ).
• To test the hypothesis, I compared the noise for the Op27 config, on the one hand with regulated (via D1000217) DC supply, and on the other, directly powered by the Tektronix supply. The latter configuration shows much higher coupling.
• I did have 0.1uF decoupling capacitors (I guess I should've used ceramic and not tantala) near the OpAmp power pins, and in fact, removing them had no effect on the level of this coupling
• As a quick check, I measured the spectrum of the DC power used to run the breadboard - it is supplied via D1000217. I used an RC network to block out the DC, but the measurement doesn't suggest a level of noise in the supply that could explain these peaks.
• The regulators are LM2941 and LM2991. They specify something like 0.03% of the output voltage as AC RMS, though I am not sure over what range of frequencies this is integrated over.
• But perhaps the effect is more subtle, some kind of downconversion of higher frequency noise, but isn't the decoupling cap supposed to protect against this?
• The 19.5 kHz harmonics seem to originate from the CRT display of the SR785 (SVGA).
• The manual doesn't specify the refresh rate, but from a bit of googling, it seems like this is a plausible number.
• The coupling seems to be radiative. The box housing the Busby preamp provides ~60dB attentuation of this signal, and the amplitude of the peaks is directly correlated to where I position the Busby box relative to the CRT screen.
• This problem can be avoided by placing the DUT and preamp sufficiently far from the SR785.

Punchlines:

1. The actual coildriver used, D010001, doesn't have a regulated power supply, it just draws the +/- 15V directly from Sorensens. I don't think this is good for low noise.
2. The LM6321 part of the circuit doesn't add any excess noise to the circuit, consistent with it being inside the unity gain feedback loop. In any case, with 4.5 kohm series resistance with the coil driver, we would be driving <2.5 mA of current, so perhaps we don't even need this?
14024   Wed Jun 27 18:12:04 2018 gautamUpdateElectronicsCoil driver dewhitening

Summary:

I've been thinking about what we need to do to the de-whitening boards for the ITMs and ETMs, in order to have low noise actuators. Noting down what I have so far, so that people can comment / point out things I've overlooked.

Attachment #1: Block diagram schematic of the de-whitened signal path on D000183 as it currently exists. I've omitted the unity gain buffer stage at the output, though this is important for noise considerations.

Some considerations, in rough order of priority:

1. Why do we need de-whitening?
• Because we want the Johnson noise of the series resistor (4.5 kohm) in the coil driver path to dominate the current noise to the coils at ~200 Hz where we want to measure the squeezing.
2. What should the shape of this de-whitening filter be?
• The DAC noise was measured to be ~1 uV/rtHz at 200 Hz.
• The Johnson noise spectral density of 4.5 kohm at 300 K is ~9 nV/rtHz
• So we need ~60dB of attenuation at 200 Hz relative to DC. Currently, they have ~80dB of attenuation at 200 Hz.
• However, we also need to consider the control signal multiplied by the inverse of this shape in the digital domain (required for overall flat shape). This should not saturate the DAC range.
• Furthermore, we'd like for the shape to be such that we don't have a large transient when transitioning between high range and low noise modes. We should use the DARM control signal estimate to inform this choice.
3. What about the electronics noise of the de-whitening filter itself?
• This shows up at the input of the coil driver stage, and gets transmitted to the coil with unity gain.
• So we should aim for < 3nV/rtHz at 200 Hz, such that we are dominated by the Johnson noise of the 4.5 kohm series resistance [the excess will be 5%].
• This can be realized by using the passive network which is the final stage in the de-whitening (there is a unity gain output buffer stage implemented with LT1128, which we also have to account for).

I will experiment with a few different shapes and investigate noise and de-whitened digital signal levels based on these considerations. At the very least, I guess we should remove the x3 gain on the ETM boards, they have already been bypassed for the ITMs.

14027   Wed Jun 27 21:18:00 2018 gautamUpdateCDSLab maintenance scripts from NODUS---->MEGATRON

I moved the N2 check script and the disk usage checking script from the (sudo) crontab of nodus to the controls user crontab on megatron .

14032   Thu Jun 28 16:48:27 2018 gautamUpdateSUSSOS cage towers

For the upcoming vent, we'd like to rotate the SOS towers to correct for the large YAW bias voltages used for DC alignment of the ITMs and ETMs. We could then use a larger series resistance in the DC bias path, and hence, reduce the actuation noise on the TMs.

Today, I used the calibrated Oplev error signals to estimate what angular correction is needed. I disabled the Oplev loops, and drove a ~0.1 Hz sine wave to the EPICS channel for the DC yaw bias. Then I looked at the peak-to-peak Oplev error signal, which should be in urad, and calibrated the slider counts to urad of yaw alignment, since I know the pk-to-pk counts of the sine wave I was driving. With this calibration, I know how much DC Yaw actuation (in mrad) is being supplied by the DC bias. I also know the directions the ETMs need to be rotated, I want to double check the ITMs because of the multiple steering mirrors in vacuum for the Oplev path. I will post a marked up diagram later.

Steve is going to come up with a strategy to realize this rotation - we would like to rotate the tower through an axis passing through the CoM of the suspended optic in the vertical direction. I want to test out whatever approach we come up with on the spare cage before touching the actual towers.

Here are the numbers. I've not posted any error analysis, but the way I'm thinking about it, we'd do some in air locking so that we have the cavity axis as a reference and we'd use some fine alignment adjust (with the DC bias voltages at 0) until we are happy with the DC alignment. Then hopefully things change by so little during the pumpdown that we only need small corrections with the bias voltages.

SoS tower DC bias correction
Optic

EPICS excitation

[V pk-pk]

ETMX 0.06 110 1.83 -5.5305 -10.14
ITMX 0.02 180 9 -1.4500 -13.05
ITMY 0.02 120 6 -0.3546 -2.13
ETMY 0.06 118 1.97 0.5532 1.09

Some remarks:

1. Why the apparent difference between ITMs and ETMs? I think it's because the bias path resistors are 400 ohms on the ETMs, but 100 ohms on the ITMs
2. If we want the series resistance for the bias path to be 10 kohm, we'd only have ~800 urad actuation (for +10V DC), so this would be an ambitious level of accuracy.
14038   Thu Jul 5 10:15:30 2018 gautamUpdateSUSPRM watchdog tripped

PRM watchdog was tripped around 7:15am PT today morning. I restored it.

14055   Thu Jul 12 11:13:39 2018 gautamUpdateGeneralOMC revival

Aaron and I are going to do the checkout of the OMC electronics outside vacuum today. At some point, we will also want to run a c1omc model to integrate with rtcds. Barring objections, I will set up this model on one of the spare cores on the physical machine c1ioo tomorrow.

14061   Thu Jul 12 23:59:14 2018 gautamUpdateGeneralVent objectives and prep

Vent objectives:

1. Install radiative heater setup in EY chamber.
2. Re-direct 50% of AS beam to OMC
• First, we need to check if the OMC trans PDs work. Else, we have to consider using some in-air PDs for the transmon.
• Check that OMC length PZT works.
• Check that OMC steering PZTs work (Koji and I have used this in 2016 to check AS beam clipping so they should work).

We only anticipate opening up the IOO chamber and the EY chamber.

Vent preparation: see here.

14063   Fri Jul 13 02:52:11 2018 gautamUpdateGeneralVent objectives and prep

[KA, GV]

1. Arm scan setup moved from West side of PSL table to North side of AP table
• Marconi is now providing the LO for the loop. A ~5m 50ohm BNC cable needs to be laid out from the PLL area to the NW corner of the AP table where the Agilent is for the TF measurement scheme which allows phase discrimination.
• We took this opportunity to characterize/improve the setup a bit, and also clean up the 10s of cables around the PSL table. There were some Video cables (75ohm instead of 50ohm ) that were part of the scanning setup which we excised.
• Mode matching onto beat PD on PSL table was improved - beat signal Vpp increased by factor of 2. PLL gain was adjusted accordingly.
• AUX power @AP table ~37mW (before recombination BS), ~3.7mW onto SRM, ~200uW onto ITMY.
• We got a beatnote in transmission of ~120uV (rms?) after optimizing alignment into Y arm cavity with the AUX frequency on an arm FSR.
• From Sandrine's calculations, I expected ~20mV of beat signal. We leave it to Annalisa and Terra to square that circle. Probably the MM into the arm isn't stellar either, and we didn't check the polarization of the aux beam (that it is matched to the IFO's p-pol).
• The entire AUX injection chain needs careful characterization before
2. Vent prep
• Both arms were locked to IR, TRY maximized using ASS, TRX maximized by hand.
• GTRY and GTRX were also maximized.
• All test mass/PRM/SRM oplevs were centered with this "good" alignment.
• PSL power into the IMC was cut from 1.07 W (measured after G&H mirror) to 97 mW, by rotating the waveplate immediately after the PSL (original angle 180deg, new angle 216 degrees).
• PMC was locked. I did not need to change any of the gain settings.
• 2" R=10% BS in the IMC REFL path was replaced with a Y2, so there is no MCREFL till we turn the power back up.
• IMC was locked. I touched up my IMC low power autolocker, but this probably needs a bit more touching up tomorrow. MC has remained locked at low power for ~25mins, but as I typed this, I jinxed it and it lost the lock. anyway we have good alignment references.
• PSL shutter will remain closed.

@SV, we are ready to vent tomorrow. Aaron is supposed to show up ~830am to assist.

14068   Fri Jul 13 18:01:13 2018 gautamUpdateGeneralLow power MC

After getting the go ahead from Steve, I removed the physical beam block on the PSL table, sent the beam into the IFO, and re-aligned the MC to lock at low power. I've also revived my low power autolocker (running on megatron), seems to work okay though the gains may not be optimal, but it seems to do the job for now. Nominal transmission when well aligned at low power is ~1200cts. I briefly checked Y arm alignment with the green, seems okay, but didn't try locking the Y arm yet. All doors are still on, and I'm closing the PSL shutter again while Keerthana and Sandrine are working near the AS table.

14075   Tue Jul 17 01:07:40 2018 gautamUpdateSUSETMY EQ stops

For the heater setup on EY table, I EQ-stopped ETMY. Only the face EQ stops (3 on HR face, 2 on AR face) were engaged. The EY Oplev HeNe was also shutdown during this procedure.

14085   Thu Jul 19 01:56:25 2018 gautamSummaryVACAUX pump shutdown

[koji, gautam]

Per Steve's instructions, we did the following:

• TP3fl pressure reading was 65 torr.
• TP3 controller reported pumping current of ~0.18A, temperature of 24C.
• We throttled the manual valve which was connecting the "AUX" pump to the TP3fl.
• The TP3fl pressure went up to 330 torr.
• TP3fl controller reported current of 0.22A, temperature of 24C.
• After ~5mins, we shut the AUX pump off.
• We have monitored it over the last 1hour, no red flags.
• (Before stopping AUX RP)
0:56AM TP3 I=0.18A, P=6W, 23degC, TP3FL: 66
• 0:59AM TP3 I=0.22A, P=7W, 23degC, TP3FL: 336
• 1:15AM TP3 I=0.21A, P=7W, 23degC, TP3FL: 320
• 1:31AM TP3 I=0.21A, P=7W, 23degC, TP3FL: 310
• 2:06AM TP3 I=0.21A, P=7W, 23degC, TP3FL: 301
• 5:06AM TP3 I=0.21A, P=7W, 23degC, TP3FL: 275
14094   Sat Jul 21 01:06:49 2018 gautamSummaryThermal CompensationY arm locking

I implemented this today. For now, the LSC output matrix is set to actuate on MC2 for Y arm locking. As expected, the transmission was much more stable, and the PLL control signal RMS was also reduced by factor of ~3. MC2 control signal does pick up a large (~2000 cts) DC component over a few hours, so we need to relieve this periodically.

Now that we have a workable ASS for the Y arm as well, we should be able to have more confidence in returning to the same beam spot position on the ETM and staying there during a scan using this technique.

The main improvement to be trialled next in the scanning is to improve the speed of scanning. As things stand, my script takes ~2.5 seconds per datapoint. If we can cut this in half, that'd be huge. On Wednesday night, we were extraordinarily lucky to avoid MC3 glitching, EPICS/slow machine failures, and GPIB freezes. Today, the latter reared its head. Fortunately, since I'm dumping data to file for each datapoint, this means we at least have data till the GPIB freeze.

 Quote: For future measurements, we should consider locking the IMC length to the arm cavity - this would eliminate such alignment drifts, and maybe also make the PLL control signal RMS smaller.

Not related to this work: Terra, Sandrine, Keerthana and I cleaned up the lab a bit today, and made better cable labels. Aaron and I have to clean up the OMC area a bit. Huge thanks to Steve for taking care of our mess elsewhere in the lab!

14095   Sat Jul 21 01:14:02 2018 gautamUpdateOMCPZT Jena driver board check

[Aaron, gautam]

We did a quick check of this board today. Main takeaways:

• There are two voltages (HV pos and HV neg) that are output from this unit.
• Presumably, these goto different piezoelectric elements, referenced to ground. Are there any spec sheets for these describing the geometry/threshold voltages?
• The outputs are:
• $\mathrm{HV_{+}} = 10(V_{\mathrm{DAC}}+V_{\mathrm{offset}}), \mathrm{HV_{-}} = 10(-V_{\mathrm{DAC}}+V_{\mathrm{offset}})$
• So with $V_{\mathrm{offset}} = 7.5 \mathrm{V}$, we expect to be able to use +/- 7.5 V of DAC range.
• The trim pot had to be adjusted to realize $V_{\mathrm{offset}} = 7.5 \mathrm{V}$​.
• I assume 150V is some kind of damage threshold of the PZT, so there is no benefit to using 10V offset voltage (as this would result in 200 V at full range DAC voltages).

With the correct $V_{\mathrm{offset}} = 7.5 \mathrm{V}$, we expect 0V from the DAC to result in 0 actuation on the mirror, assuming that an equal 75V goes to 2 PZTs mounted diametrically opposite on the optic. Hopefully, this means we have sufficient range to scan the input pointing into the OMC and get some sort of signal in the REFL signal (while length PZT is being scanned) which indicates a resonance.

We plan to carve out some IFO time for this work next week.

14101   Tue Jul 24 09:47:51 2018 gautamUpdateCamerasDeveloping neural networks on simulated video

I was thinking a little more about the way we are training the network for the current topology - because the network has no recurrent layers, I guess it has no memory of past samples, and so it doesn't have any sense of the temporal axis. In fact, Keras by default shuffles the training data you give it randomly so the time ordering is lost. So the training amounts to requiring the network to identify the center of the Gaussian beam and output that. So in the training dataset, all we need is good (spatial) coverage of the area in which the spot is most likely to move? Or is the idea to develop some tools to generate video with spot motion close to that on the ETM in lock, so that we can use it with a network topology that has memory?

 Quote: This looks like good progress. Instead of fixed sines or random noise, you should generate now a time series for the motion which is random noise but with a power spectrum similar to what we see for the ETM pitch motion in lock. You can use inverse FFT to get the time series from the open loop OL spectra (being careful about edge effects)
14104   Wed Jul 25 22:46:15 2018 gautamConfigurationComputersNDS access from outside

After this work, I've been having some trouble getting data with Python NDS. Eventually, I figured out that the nds connection request has to be pointed at '131.215.115.200' (the address of the NAT router which faces the outside world), port 31200 (it used to work with 'nds40.ligo.caltech.edu' or '131.215.115.189'). So the following snippet in python allows a connection to be opened. Offline access of frame data via NDS2 now seems possible.

import nds2
conn = nds2.connection('131.215.115.200',31200)
 Quote: So far, ssh (22), web services (30889), and elog (8081, 8080) were tested. We also need to test megatron NDS port forwarding and rsync for nodus, too.Finally I turned off the firewall rules of shorewall on nodus as it is no longer necessary.
14107   Fri Jul 27 02:30:51 2018 gautamUpdateGeneralGlitchy MC

Kevin and I saw some weird IMC / PEM BLRMS behaviour today - see Attached screenshot. Not sure what was happening with the IMC, but MCtrans was oscillating at ~3Hz for a good 20 minutes or so. I just killed the lock, and restarted MCautolocker on megatron. There was a strange feature in the 3-10Hz BLRMS around that time as well. All seems back to normal now...

14115   Mon Jul 30 11:05:44 2018 gautamUpdateSUSIFO SUS wonky

When I came in this morning:

• PMC was unlocked.
• Seis BLRMS were off scale.
• ITMX OSEM LEDs were dark on the CRT monitor even though Sat Box was plugged in.

Checking status of slow machines, it looked like c1sus, c1aux, and c1iscaux needed reboots, which I did. Still PMC would not lock. So I did a burtrestore, and then PMC was locked. But there seemed to be waaaaay to much motion of MCREFL, so I checked the suspension. The shadow sensor EPICS channels are reporting ~10,000 cts, while they used to be ~1000cts. No unusual red flags on the CDS side. Everything looked nominal when I briefly came in at 6:30pm PT yesterday, not sure if anything was done with the IFO last night.

Pending further investigation, I'm leaving all watchdogs shutdown and the PSL shutter closed.

A quick look at the Sorensens in 1X6 revealed that the +/- 20V DC power supplies were current overloaded (see Attachment #1). So I set those two units to zero until we figure out what's going on. Possibly something is shorted inside the ITMX satellite box and a fuse is blown somewhere. I'll look into it more once Steve is back.

14117   Mon Jul 30 16:11:54 2018 gautamUpdateSUSTrillium interface box is broken

[koji, steve, gautam]

We debugged this in the following way:

1. Disconnect all fuses in the terminal blocks coming from the +/- 20 VDC Sorensens.
2. Check that they are indeed isolated using DMM.
3. Test blocks of fuses in order to identify where the problem is happening (i.e. plug fuses in, turn up Sorensen voltage knobs, look for current overload). We did things in the following order:
• MC suspensions
• BS, PRM and SRM
• ITMY
• ITMX
• Trillium interface box.
4. Turns out that the Trillium box is the culprit.
5. Confirmed that the problem is in the trillium interface box and not in the seismometer itself by unplugging all cables leading out of the interface box, and checking that the problem persists when the box is powered on.

So for now, the power cable to the box is disconnected on the back end. We have to pull it out and debug it at some point.

Apart from this, megatron was un-sshable so I had to hard reboot it, and restart the MCautolocker, FSSslowPy and nds2 processes on it. I also restarted the modbusIOC processes for the PSL channels on c1auxex (for which the physical Acromag units sit in 1X5 and hence were affected by our work), mainly so that the FSS_RMTEMP channel worked again. Now, IMC autolocker is working fine, arms are locked (we can recover TRX and TRY~1.0), and everything seems to be back to a nominal state. Phew.

14122   Wed Aug 1 19:41:15 2018 gautamSummaryComputersRTCDS recovery, c1ioo changes

[Gautam Koji]

After this work, we recovered the nominal RTCDS state. The main points were:

1. We needed to restart the bind9 service on chiara such that the FEs knew their IP addresses upon reboot and hence, could get their root filesystems over NFS.
2. We recovered suspension local damping, IMC locking and POX/POY locking with nominal arm transmission.

Some stuff that is not working as usual:

1. The EX QPD is reporting strange transmission values - even with the PRM completely misaligned, it reports transmission of ~30. But we were able to lock the Xarm with the Thorlabs PD and revover transmission of ~1.15.
2. The X arm green does not stay locked to the cavity - the alignment looks fine, and the green flashes are strong, but the lock does not hold. This shouldn't be directly connected to anything we did today since the Green PDH servo is entirely analog.

I made a model change in c1x03 (the IOP model on c1ioo) to add a DAC part. The model compiled, installed and started correctly, and looking at dmesg on c1ioo, it recognises the DAC card as what it is. Next step is to use a core on c1ioo for a c1omc model, and actually try driving some signals.

Note that the only change made to the c1ioo expansion chassis was that a DAC card was installed into the PCIe bus. The adaptor card which allows interfacing the DAC card to an AI board was already in the expansion chassis, presumably from whenever the DAC was removed from this machine.

*I think I forgot to restart optimus after this work...

14123   Wed Aug 1 20:44:57 2018 gautamSummaryComputersc1omc model (re?)created

The main motivation behind adding a DAC card in c1ioo was to setup an RTCDS model for the OMC. Attachment #1 shows the new look CDS overview screen. Here is what I did.

Mostly, I followed instructions from when I setup the model for the EX green PZTs.

The model is just a toy for now (CDS parameters, ADC block and 2 CDS filter modules). I leave it to Aaron to actually populate it, check functionality etc. The path to the model is /opt/rtcds/caltech/c1/userapps/release/isc/c1/models/c1omc.mdl. I am listing the parameters set on the CDS_PARAMETERS block:

• host = c1ioo
• site = c1
• rate = 16k
• dcuid = 27 (which I chose after making sure that this dcuid was not used on this list which I also updated by adding c1omc and moving c1imc to "old")
• specific_cpu = 6 (again chosen after checking the available CPUs in the above list and confirming using the cset utility).
• shmem_daq = 1
• no_rfm_dma = 1

Building and installing model:

Once the model was installed, I logged into c1ioo, and built and installed the models using the usual rtcds make and rtcds install instructions. Before starting the model, I edited /diskless/root.jessie/etc/rtsystab to allow c1omc to be run on c1ioo. Using sudo cset set, I verified that CPU #6 is no longer listed (if I understand correctly, the RTCDS system takes over the core).

MEDM:

To reflect all this on the MEDM CDS OVERVIEW screen, I just edited the screen.

• Moved the orange explanation of bits over to the c1iscey panel to make space in the c1ioo panel.
• Edited the macros to reflect the c1omc parameters.

DAQD:

Finally, I followed the instructions here to get the channels into frames and make all the indicators green. Went into fb and restarted the daqd processes. All looks good . I'm going to leave the model running overnight to investigate stability. I forgot to svn commit the model tonight, will do it tomorrow.

The testing plan (at least initially) is to install the AA and AI boards from the OMC rack in 1X1/1X2. Then we will have short SCSI cables running from the ADC/DAC to these. The actual HV driving stages will remain in the OMC rack (NE corner of AS table).

@Steve, can we get 10 Male-Female D9 cables so that we can run them from 1X1/1X2 to the OMC rack?

Unrelated to this work: There were 2 crashes of the models on c1lsc, one ~6pm and one right now ~1030pm. The restart script brought everything back gracefully  ...

14125   Thu Aug 2 20:47:29 2018 gautamSummaryElectronicsX Green "Mystery" solved

I walked down to the X end and found that the entire AUX laser electronics rack isn't getting any power. There was no elog about this.

I couldn't find any free points in the power strip where I think all this stuff was plugged in so I'm going to hold off on resurrecting this until tomorrow when I'll work with Steve.

 Quote: The X arm green does not stay locked to the cavity - the alignment looks fine, and the green flashes are strong, but the lock does not hold. This shouldn't be directly connected to anything we did today since the Green PDH servo is entirely analog.
14126   Thu Aug 2 20:54:18 2018 gautamSummaryComputersc1omc model looks stable

Actually, c1lsc had crashed again sometime last night so I had to reboot everything this morning. I used the reboot script again, but I increased the sleep time between trying to start up the models again so that I could walk into the VEA and power cycle the c1lsc expansion chassis, as this kind of frequent model crash has been fixed by doing so in the past. Sure enough, there have been no issues since I rebooted everything at ~1030 in the morning.

The c1omc model itself has been stable as well, though of course, there is nothing in there at the moment. I may do a check of the newly installed DAC tomorrow just to see that we can put out a sine wave.

Steve has ordered the D-sub cabling that will allow us to route signals between AA/AI boards in 1X1/1X2 to the HV PZT electronics in the OMC rack. Things look setup for a measurement next week. Aaron will post a block diagram + photoz of what box goes where in the electronics racks.

14128   Fri Aug 3 14:35:56 2018 gautamSummaryElectronicsEX AUX electronics power restored

Steve and I restored the power to the EX AUX electronics rack. The power strip on the lowest shelf of the AUX rack now goes to another power strip laid out vertically along the NW corner of 1X9. The EX green locks to the arm just fine now.

14129   Fri Aug 3 15:53:25 2018 gautamUpdateSUSLow noise bias path idea

Summary:

The idea we are going with to push the coil driver noise contribution down is to simply increase the series resistance between the coil driver board output and the OSEM coil. But there are two paths, one for fast actuation and one that provides a DC current for global alignment. I think the simplest way to reduce the noise contribution of the latter, while preserving reasonable actuation range, is to implement a precision DC high-voltage source. A candidate that I pulled off an LT application note is shown in Attachment #1.

Requirements:

• The series resistance in the bias path should be $10 k\Omega$, such that the noise from this stage is dominated by the Johnson noise of said resistor, and hence, the current noise contribution is negligible compared to the series resistance in the fast actuation path ($4.5 k\Omega$).
• Since we only really need this for the test masses, what actuation range do we want?
• Currently, ETMY has a series resistance of $400\Omega$ and has a pitch DC bias voltage of -4 V.
• This corresponds to 10 mA of DC current.
• To drive this current through $10 k\Omega$, we need 100 V.
• I'm assuming we can manually correct for yaw misalignments such that 10mA of DC current will be sufficient for any sort of corrective alignment.
• So +/- 120 V DC should be sufficient.
• The current noise of this stage should be negligible at 100 Hz.
• The noise of the transistors and the HV supply should be suppressed by the feedback loop and so shouldn't be a significant contribution (I'll model to confirm).
• The input noise of the LT1055 is ~20nV/rtHz at 100 Hz, while the Johnson noise of $10 k\Omega$ is ~13nV/rtHz so maybe the low-passing needs to be tuned, but I think if it comes to it, we can implement a passive RC network at the output to achieve additional filtering.
• To implement this circuit, we need +/- 125V DC.
• At EX and EY, we have a KEPCO HV supply meant to be used for the Green Steering PZTs.
• I'm not sure if these can do bipolar outputs, if not, for temporary testing, we can transport the unit at EY to EX.

If all this seems reasonable, I'd like to prototype this circuit and test it with ETMX, which already has the high series resistance for the fast path. So I will ask Steve to order the OpAmp and transistors.

14131   Fri Aug 3 18:54:58 2018 gautamUpdateSUSGlitchy MC1

The wall StripTool indicated that the IMC wasn't too happy when I came in today. Specifically:

• MC1 watchdog was tripped.
• Even in the tripped state, MC REFL spot on the camera showed spot motion that was too large to be explained as normal seismic driven motion (i.e. with local damping supposedly disabled).
• Strange excursions were observed in the MC1 shadow sensor signal levels as well, see Attachment #1 - negative values don't make any sense for this readout.

The last time this happened, it was due to the Sorensens not spitting out the correct voltages. This time, there were no indications on the Sorensens that anything was funky. So I just disabled the MCautolocker and figured I'd debug later in the evening.

However, around 5pm, the shadow sensor values looked nominal again, and when I re-enabled the local damping, the MC REFL spot suggested that the local damping was working just fine. I re-enabled the MCautolocker, MC re-locked almost immediately. To re-iterate, I did nothing to the electronics inside the VEA. Anyways, this enabled us to work on the X arm ASS (next elog).

14132   Fri Aug 3 19:02:11 2018 gautamUpdateASSX arm ASS recovery

[koji, gautam]

After I effected the series resistance change for ETMX, the X arm ASS didn't work (i.e. IR transmission would degrade if the servo was run). Today, we succeeded in recovering a functional ASS servo .

So both arms have working dither alignment servos now. But remember that the Y arm ASS gains have been set for locking the Y arm with MC2 as the actuator, not ETMY.

Details:

• Koji pointed out that the demodulated signals from the ETM dither are only used to center the spot on the ETM, and that we should first run the servo with existing settings with the ETM pitch and yaw spot centering loops disabled.
• This improved TRX level from ~0.8 to 1.1
• Next, we tried increasing the LO amplitudes by x5 to account for the reduced actuation of the dither on ETMX
• We then re-enabled the two loops that were earlier disabled.
• This resulted in TRX degrading very quickly.
• So we decided to try going back to the nominal LO gains, and reducing the gain of the two ETM spot centering loops.
• This did the trick, TRX went from 1.1 --> ~1.23, which is the nominal maximum pre-vent value.
• The snap file used to recover the correct settings to run the dither alignment servos have been updated, the old one has been backed up with today's datestamp.

We then tried to maximize GTRX using the PZT mirrors, but were only successful in reaching a maximum of 0.41. The value I remember from before the vent was 0.5, and indeed, with the IR alignment not quite optimized before we began this work, I saw GTRX of 0.48. But the IR dither servo signals indicate that the cavity axis may have shifted (spot position on the ITM, which is uncontrolled, seems to have drifred significantly, the Pitch signal doesn't stay on the StripTool scale anymore). So we may have to double check that the transmitted beam isn't falling off the GTRX DC PD.

14133   Sun Aug 5 13:28:43 2018 gautamUpdateCDSc1lsc flaky

Since the lab-wide computer shutdown last Wednesday, all the realtime models running on c1lsc have been flaky. The error is always the same:

[58477.149254] c1cal: ADC TIMEOUT 0 10963 19 11027 [58477.149254] c1daf: ADC TIMEOUT 0 10963 19 11027 [58477.149254] c1ass: ADC TIMEOUT 0 10963 19 11027 [58477.149254] c1oaf: ADC TIMEOUT 0 10963 19 11027 [58477.149254] c1lsc: ADC TIMEOUT 0 10963 19 11027 [58478.148001] c1x04: timeout 0 1000000  [58479.148017] c1x04: timeout 1 1000000  [58479.148017] c1x04: exiting from fe_code()

This has happened at least 4 times since Wednesday. The reboot script makes recovery easier, but doing it once in 2 days is getting annoying, especially since we are running many things (e.g. ASS) in custom configurations which have to be reloaded each time. I wonder why the problem persists even though I've power-cycled the expansion chassis? I want to try and do some IFO characterization today so I'm going to run the reboot script again but I'll get in touch with J Hanks to see if he has any insight (I don't think there are any logfiles on the FEs anyways that I'll wipe out by doing a reboot). I wonder if this problem is connected to DuoTone? But if so, why is c1lsc the only FE with this problem? c1sus also does not have the DuoTone system set up correctly...

The last time this happened, the problem apparently fixed itself so I still don't have any insight as to what is causing the problem in the first place . Maybe I'll try disabling c1oaf since that's the configuration we've been running in for a few weeks.

14134   Sun Aug 5 13:45:00 2018 gautamUpdateSUSETMX tripped

Independent from the problems the vertex machine has been having (I think, unless it's something happening over the shared memory network), I noticed on Friday that the ETMX watchdog was tripped. Today, once again, the ETMX watchdog was tripped. There is no evidence of any abnormal seismic activity around that time, and anyways, none of the other watchdogs tripped. Attachment #1 shows that this happened ~838am PT today morning. Attachment #2 shows the 2k sensor data around the time of the trip. If the latter is to be believed, there was a big impulse in the UL shadow sensor signal which may have triggered the trip. I'll squish cables and see if that helps - Steve and I did work at the EX electronics rack (1X9) on Friday but this problem precedes our working there...

14135   Sun Aug 5 15:43:50 2018 gautamUpdateSUSAnother low noise bias path idea

• Attachment #1 shows the proposed schematic.
• It consists of a second order section with Gain x10 to map the +/-10V DC range of the DAC to +/- 100V DC such that we preserve roughly the same amount of DC actuation range.
• Corner frequency of the SOS is set to ~0.7 Hz. In hindsight, maybe this is more aggressive than necessary, we can tune this.
• DC gain is 20 dB (typo in the text where I say the DC gain is x15, though we could go with this option as well I think if we want a larger series resistance).
• A first order passive low-pass stage is added to filter out the voltage noise of the PA91, which dominates the output voltage noise (next bullet).
• Attachment #2 shows the transfer function from input to output
• The two traces compare having just a single SOS filtering stage vs the current topology of having two SOS stages.
• The passive output RC network is necessary in either case to filter the voltage noise of the PA91 OpAmp.
• For the DAC noise, I just assumed a flat noise level of $5 \mu V / \sqrt{\mathrm{Hz}}$, I don't actually know what this is for the Acromag DACs.
• Attachments #3 shows a breakdown of the top 5 noise contributions.
• The PA91 datasheet doesn't give current noise information so I just assumed $1 fA / \sqrt{\mathrm{Hz}}$, which was what was used for the PA85 in the existing opamp.lib file.
• The voltage noise is modelled as $4.5 \sqrt{1+\frac{80}{f}} nV / \sqrt{\mathrm{Hz}}$, which seems to line up okay with the plot on Pg4 of the datasheet.
• So the model suggests we will be dominated by the voltage noise of the PA91.
• Attachment #4 translates the noise into current noise seen by the actuator.
• I add the Johnson noise contribution of the series resistance for this path, which is assumed to be $10 k \Omega$.
• For comparison, I add the filtered DAC noise contribution, and Johnson noise of the proposed series resistance in the fast path.
• For the bias path, we are dominated by the Johnson noise of the series resistor from ~60 Hz upwards.
• It's not quite fair to say that the Johnson noise of the resistance in the fast path dominates, the quadrature sum of fast and bais paths will be ~1.2 times of the former alone.
• Bottom line: we will be in the regime of total current noise of ~2.2 pA/rtHz, where I think Kevin's modeling suggests we can see some squeezing.

The question still remains of how to combine the fast and bias paths in this proposed scheme. I think the following approach works for prototyping at least:

• Remove the series resistance on the existing coil driver boards' bias path, hence isolating this from the coil.
• Route the DB15 output connector from the coil driver board (which is now just the fast actuation signals) into a sub-sattelite box housing the bias path electronics.
• Sum the two signals as it is done now, by simply having a conductor (PCB trace) merge the two paths after their respective series resistances.

In the longer term, perhaps the Satellite Box revamp can accommodate a bias voltage summation connector.

 Quote: Bah! Too complex.

I have neglected many practical concerns. Some things that come to mind:

1. Is it necessary to protect the upstream DAC from some potential failure of the PA91 in which the high voltage appears at the input?
2. What is the correct OpAmp for this purpose? This chart on Apex's page suggests that PA15, PA85, PA91 and PA98 are all comparable in terms of drive capability, and the spec sheets don't suggest any dramatic differences. Some LIGO circuits use PA85, some use PA90, but I can't find any that use PA91. Perhaps Rana/Koji can comment about this.
3. What kind of protection is necessary for the PA91 power?
4. What is the correct way to do heat management? Presumably we need heatsinks, and in fact, there is a variant of the packaging style that has "formed" legs, which from what I can figure out, allow the heat sink plane on the PA91 to be parallel to the PCB surface. But I think the heat-sink wisdom suggests vertical fins are the most efficient (not sure if this holds if the PCB is inside a box though). What about the PCB itself? Are some kind of special traces needed?
5. Can we use the current-limiting resistor feature on the PA91? The datasheet seems to advice against it for G>10 configurations, which is what we need, although our requirement is only at DC so I don't know if that table is applicable to this circuit.
6. Are 3W resistors sufficient? I think we require only 10mA maximum current to preserve the current actuation range, so 100 V * 10mA = 1W, so 3W leaves some safety margin.
7. All capacitors should be rated for 500 V per the datasheet.
14136   Mon Aug 6 00:26:21 2018 gautamUpdateCDSMore CDS woes

I spent most of today fighting various CDS errors.

• I rebooted c1lsc around 3pm, my goal was to try and do some vertex locking and figure out what the implications were of having only ~30% power we used to have at the AS port.
• Shortly afterwards (~4pm), c1lsc crashed.
• Using the reboot script, I was able to bring everything back up. But the DC lights on c1sus models were all red, and a 0x4000 error was being reported.
• This error is indicative of some timing issue, but all the usual tricks (reboot vertex FEs in various order, restart the mx_streams etc) didn't clear this error.
• I checked the Tempus GPS unit, that didn't report any obvious problems (i.e. front display was showing the correct UTC time).
• Finally, I decided to shut down all watchdogs, soft reboot all the FEs, soft reboot FB, power cycle all expansion chassis.
• This seems to have done the trick - I'm leaving c1oaf disabled for now.
• The remaining red indicators are due to c1dnn and c1oaf being disabled.

Let's see how stable this configuration is. Onto some locking now...

14139   Mon Aug 6 14:38:38 2018 gautamUpdateCDSMore CDS woes

Stability was short-lived it seems. When I came in this morning, all models on c1lsc were dead already, and now c1sus is also dead (Attachment #1). Moreover, MC1 shadow sensors failed for a brief period again this afternoon (Attachment #2). I'm going to wait for some CDS experts to take a look at this since any fix I effect seems to be short-lived. For the MC1 shadow sensors, I wonder if the Trillium box (and associated Sorensen) failure somehow damaged the MC1 shadow sensor/coil driver electronics.

 Quote: Let's see how stable this configuration is. Onto some locking now...
14140   Mon Aug 6 19:49:09 2018 gautamUpdateCDSMore CDS woes

I've left the c1lsc frontend shutdown for now, to see if c1sus and c1ioo can survive without any problems overnight. In parallel, we are going to try and debug the MC1 OSEM Sensor problem - the idea will be to disable the bias voltage to the OSEM LEDs, and see if the readback channels still go below zero, this would be a clear indication that the problem is in the readback transimpedance stage and not the LED. Per the schematic, this can be done by simply disconnecting the two D-sub connectors going to the vacuum flange (this is the configuration in which we usually use the sat box tester kit for example). Attachment #1 shows the current setup at the PD readout board end. The dark DC count (i.e. with the OSEM LEDs off) is ~150 cts, while the nominal level is ~1000 cts, so perhaps this is already indicative of something being broken but let's observe overnight.

14142   Tue Aug 7 11:30:46 2018 gautamUpdateCDSMore CDS woes

Overnight, all models on c1sus and c1ioo seem to have had no stability issues, supporting the hypothesis that timing issues stem from c1lsc. Moreover, the MC1 shadow sensor readouts showed no negative values over a ~12hour period. I think we should just observe this for another day, in any case I don't think there is any urgent IFO related activity scheduled.

14143   Tue Aug 7 22:28:23 2018 gautamUpdateCDSMore CDS woes

I am starting the c1x04 model (IOP) on c1lsc to see how it behaves overnight.

Well, there was apparently an immediate reaction - all the models on c1sus and c1ioo reported an ADC timeout and crashed. I'm going to reboot them and still have c1x04 IOP running, to see what happens.

[97544.431561] c1pem: ADC TIMEOUT 3 8703 63 8767 [97544.431574] c1mcs: ADC TIMEOUT 1 8703 63 8767 [97544.431576] c1sus: ADC TIMEOUT 1 8703 63 8767 [97544.454746] c1rfm: ADC TIMEOUT 0 9033 9 8841
 Quote: Overnight, all models on c1sus and c1ioo seem to have had no stability issues, supporting the hypothesis that timing issues stem from c1lsc. Moreover, the MC1 shadow sensor readouts showed no negative values over a ~12hour period. I think we should just observe this for another day, in any case I don't think there is any urgent IFO related activity scheduled.
14146   Wed Aug 8 23:03:42 2018 gautamUpdateCDSc1lsc model started

As part of this slow but systematic debugging, I am turning on the c1lsc model overnight to see if the model crashes return.

14147   Wed Aug 8 23:06:59 2018 gautamUpdateSUSAnother low noise bias path idea

Today while Rich Abbott was here, Koji and I had a brief discussion with him about the HV amplifier idea for the coil driver bias path. He gave us some useful tips, perhaps most useful being a topology that he used and tested for an aLIGO ITM ESD driver which we can adapt to our application. It uses a PA95 high voltage amplifier which differs from the PA91 mainly in the output voltage range (up to 900V for the former, "only" 400V for the former. He agrees with the overall design idea of

• Having a LN opamp with the HV amp inside the feedback loop for better voltage noise at low frequencies.
• Having a passive RC network at the output of the HV amp to filter out noise at high frequencies.

He also gave some useful suggestions like

• Using the front panel of the box that as a heatsink for the HV amps.
• Testing the stability of the nested opamp loop by "pinging" the output of the opamp with some pulses from a function generator and monitoring the response to this perturbation on a scope.

I am going to work on making a prototype version of this box for 5 channels that we can test with ETMX. I have been told that the coupling from side coil to longitudinal motion is of the order of 1/30, in which case maybe we only need 4 channels.

14148   Thu Aug 9 02:12:13 2018 gautamUpdateCOCSouth East or West?

Summary:

For operating the SRC in the "Signal-Recycled" tuning, the SRC macroscopic length needs to be ~4.04m (compared to the current value of ~5.399m), assuming we don't do anything fancy like change the modulation frequencies and not transmit through the IMC. We're putting together a notebook with all the calculations, but today I was thinking about what the signal extraction path should be, specifically which chamber the SRM should be in. Just noting down the thoughts I had here while they're fresh in my head, all this has to be fleshed out, maybe I'm making this out to be more of a problem than it actually is.

Details:

• For the current modulation frequencies, if we want the reosnance conditions such that the f2 sideband is resonant in the SRC (but not f1, i.e. small Schnupp asymmetry regime) while the carrier is resonant in the arms (required for good sensing of the SRC length), the macroscopic length of the SRC needs to be changed to ~4.04m.
• Practically, this means that the folded SRC would only have one folding mirror (SR2).
• There is a shorter SRC length of ~1.something metres which would work, but that would involve changing the relative position between ITMs and BS (currently ~2.3m) so I reject that option for now.
• So the SR2 would be roughly where it is right now, ~20cm from the BS.
• The question then becomes, where do we direct the reflection from the SR2? We need an optical path length of ~1.5m from SR2. So options are
• ITMY table (East)
• ITMX table (South)
• IMC table (West)
• Moreover, after the SRM, we have to accommodate:
• Some kind of pickoff for in-air PDs.
• OFI.
• OMC MMT.
• OMC.
• Some kind of CBA (as of now I think going to the ITMY table is the best option):
ITMY
• Easy to direct beam from BS/PRM chamber to the ITMY table (i.e. we don't have to worry too much about avoiding other optics in the path etc).
• ITMY table probably has the most room to work out an OFI + OMC MMT + OMC solution.
• AS beam extraction to air will be more complicated, possibly have to do it on ITMY optical table.
• Not sure if the ITMY table can accommodate all of the output optics subsystems I listed above.
• Routing the LO beam to this table would be tricky I guess.
ITMX
• Routing the LO beam for homodyne detection is probably easiest in this chamber.
• Allows for small AoI on folding mirror, reducing the impact of astigmatism.
• Pain to work in this chamber because of IMC tube.
• Steering beam from SR2 to ITMX table means threading the needle between PRM and PR3 possibly.
IMC
• Probably allows the use of (almost) the entire existing OMC chamber for the output optics (OFI, OMC MMT, OMC).
• IMC table is crowded (2 SOS towers, several steering optics for the input beam, input faraday).
• Not sure what is the performance of the seismic isolation stacks on these tables vs the larger optical tables.
• Painful to work in these smaller chambers.
14149   Thu Aug 9 12:31:13 2018 gautamUpdateCDSCDS status update

The model seems to have run without issues overnight. Not completely related, but the MC1 shadow sensor signals also don't show any abnormal excursions to negative values in the last 48 hours. I'm thinking about re-connecting the satellite box (but preserving the breakout setup at 1X6 for a while longer) and re-locking the IMC. I'll also start c1ass on the c1lsc frontend. I would say that the other models on c1lsc (i.e. c1oaf, c1cal, c1daf) aren't really necessary for basic IFO operation.

 Quote: As part of this slow but systematic debugging, I am turning on the c1lsc model overnight to see if the model crashes return.
14150   Thu Aug 9 12:40:14 2018 gautamUpdateSUSETMX trip follow-up

A brief follow-up on this since we discussed this at the meeting yesterday: the attached DV screenshot shows the full 2k data for a period of 2 seconds starting just before the watchdog tripped. It is clear that the timescale of the glitch in the UL channel is much faster (~50 ms) compared to the (presumably mechanical) timescale seen in the other channels of ~250 ms, with the step also being much smaller (a few counts as opposed to the few thousand counts seen in the UL channel, and I guess 1 OSEM count ~ 1 um). All this supports the hypothesis that the problem is electrical and not mechanical (i.e. I think we can rule out the Acromag sending a glitchy signal to the coil and kicking the optic). The watchdog itself gets tripped because the tripping condition is the RMS of the shadow sensor outputs, which presumably exceeds the set threshold when UL glitches by a few thousand counts.

14151   Thu Aug 9 22:50:13 2018 gautamUpdateCDSAlignSoft script modified

After this work of increasing the series resistance on ETMX, there have been numerous occassions where the insufficient misalignment of ETMX has caused problems in locking vertex cavities. Today, I modified the script (located at /opt/rtcds/caltech/c1/medm/MISC/ifoalign/AlignSoft.py) to avoid such problems. The way the misalign script works is to write an offset value to the "TO_COIL" filter bank (accessed via "Output Filters" button on the Suspension master MEDM screen - not the most intuitive place to put an offset but okay). So I just increased the value of this offset from 250 counts to 2500 counts (for ETMX only). I checked that the script works, now when both ETMs are misaligned, the AS55Q signal shows a clean Michelson-like sine wave as it fringes instead of having the arm cavity PDH fringes as well .

Note that the svn doesn't seem to work on the newly upgraded SL7 machines: svn status gives me the following output.

svn: E155036: Working copy '/cvs/cds/rtcds/userapps/trunk/cds/c1/medm/MISC/ifoalign' is too old (format 10, created by Subversion 1.6)

Is it safe to run 'svn upgrade'? Or is it time to migrate to git.ligo.org/40m/scripts?

14152   Fri Aug 10 01:10:56 2018 gautamUpdateLSCSome vertex locking restored

For the first time after the whirlwind vent, I managed to lock the PRMI.

• First, I did POX/POY locking, dither aligned the arms to maximize TRX and TRY.
• Next, I misaligned the ETM and tested the Michelson locking
• Since we've lost ~70% of power on the AS55 PD, I set the whitening gain for AS55 I and Q channels to +6dB (old value was 0dB).
• worked alright. In this new config, the peak-to-peak Michelson fringe count is ~80 cts, while I reported ~60cts-pp a couple of months ago, so all seems good on that front.
• But the config script in the IFOconfigure MEDM screen somehow doesn't set the AS55_Q ----> MICH_A element in the LSC input matrix anymore.
• I edited the .snap file for this configuration to set the relevant matrix element EPICS channel to +1.0.
• I also edited the overall loop gain for this configuration from +30 to +2 (for bright fringe, use -2 for dark fringe).
• Feeling adventerous, I decided to try PRMI in the carrier resonant tuning (to be clear, PRCL on REFL11_I, MICH on AS55_Q).
• Finding the REFL spot on the camera took a while since the PRM has been macroscopically misaligned for the mode-scanning
• Went out to the table and centered the REFL beam onto REFL11 and REFL55 PDs - didn't need much tweaking, which is a good sign, since we shouldn't have screwed anything up on the symmetric side by any of the vent activities.
• Restored PRMI locking using the IFOconfigure MEDM screen - lock caught almost immediately.
• Ran the dither alignment servos for MICH and PRCL - BS needed a bit of encouragement to make the dark spot dark, but POP has been pretty stable over ~15mins.
• I didn't take any loop transfer functions, to do.

I don't have the energy to make a DRMI attempt tonight - but the signs are encouraging. I'd like to use the IFO in the next few days to try and recover DRMI locking. The main concern is that the optical path on the AS beam has changed by ~0.3m I estimate. So the demod phase for AS55 may need to be adjusted, but the change due to optical path length only should be ~10degrees so the DRMI locking with the old settings should still work. Perhaps we also want to scan the PRC and SRC with the phase information from the Trans/Refl transfer functions as well.

Don't want to jinx it, but the c1lsc FE models have been stable. Tomorrow, I'd like to re-enable c1cal, since it has some useful channels for NBing. Could c1daf/c1oaf which have significant amounts of custom C code be the culprits?

14154   Fri Aug 10 16:43:50 2018 gautamConfigurationUpgradeParts list for BHD

Can we use the leakage beam from MMT2 on the OMC table as the LO beam? I can't find the spec for this optic, but the leakage beam was clearly visible on an IR card even with the IMC locked with 100 mW input power so presumably there's enough light there, and this is a cavity transmission beam which presumably has some HOM content filtered out.

 Quote: My current thought is to use the MC reflection, the beam that heads from MC1 to MCR1, as the LO beam
14157   Mon Aug 13 11:44:32 2018 gautamUpdateComputer Scripts / ProgramsPatch updates on nodus

Larry W said that some security issues were flagged on nodus. So I ran

on nodus. The exclude flag is because there were some conflicts related to that particular package. Hopefully this has fixed the problem. It's been a while since the last update, which was in January of this year.

controls@nodus|~> sudo yum history
ID     | Command line             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
29 | upgrade --exclude=elog-3 | 2018-08-13 11:36 | E, I, U        |  136 EE
28 | install yum-utils        | 2018-08-13 11:31 | Update         |    1
27 | install nmap             | 2018-06-29 01:57 | Install        |    2
26 | install grace            | 2018-05-31 16:52 | Install        |   11
25 | install https://dl.fedor | 2018-05-31 16:51 | Install        |    1
24 | install perl-Digest-SHA1 | 2018-05-31 15:34 | Install        |    1
23 | install python-devel     | 2018-01-13 15:33 | Install        |    1
22 | install gcc              | 2018-01-13 15:32 | Install        |    6
21 | install git              | 2018-01-12 18:11 | Install        |    4
20 | update                   | 2018-01-12 18:01 | I, U           |   39
19 | install motif            | 2018-01-05 17:35 | Install        |    3
18 | install sendmail sendmai | 2017-12-03 05:11 | Install        |    6
17 | install vim              | 2017-11-21 18:12 | Install        |    3
16 | reinstall mod_dav_svn    | 2017-11-21 17:40 | Reinstall      |    1
15 | install mod_dav_svn      | 2017-11-21 17:39 | Install        |    1
14 | install subversion       | 2017-11-21 15:36 | Install        |    2
13 | -y install php           | 2017-11-20 22:15 | Install        |    4
12 | install links            | 2017-11-20 19:10 | Install        |    2
11 | install openssl098e.i686 | 2017-11-18 18:28 | Install        |    1
10 | install openssl-libs.i68 | 2017-11-18 18:26 | Install        |   11
history list
14160   Tue Aug 14 00:27:55 2018 gautamUpdateLSCLocking prep

In preparation for attempting some DRMI locking, I did the following:

• Slow machine reboots for unresponsive c1psl, c1susaux and c1iscaux. The latter requried a manual burtrestore to recover the usual LSC PD whitening settings.
• Shuttered AUX laser (which was on Standby anyways) - we should really install a remotely controllable shutter for this on the AS table.
• Re-aligned PMC (half turn of knob in yaw, full turn in pitch) - IMC transmission 15,000cts ---> 15,600cts.
• Squished sat. box cables at ITMX and ETMX.

Not related to this work, but I turned the Agilent NA off since we aren't using it immediately.

14161   Tue Aug 14 00:50:32 2018 gautamUpdateASSX arm ASS still not quite right?

While working on the single arm alignment, I noticed that today, i was able to get the X arm transmission back to ~1.22, and the GTRX to 0.52. These are closer to the values I remember from prior to the vent. Running the dither alignment promptly degrades both the green and IR transmissions. Since the pianosa SL7 upgrade, I can't use the sensoray to capture images, but to me, the spot looks a little off-center in Yaw on ETMX in this configuration, I've tried to show this in the phone grab (Atm #2). Maybe indicative of clipping somewhere upstream of ITMX?

Anyways, I'm pushing onwards for now, something to check out in the daytime.

 Quote: [koji, gautam] After I effected the series resistance change for ETMX, the X arm ASS didn't work (i.e. IR transmission would degrade if the servo was run). Today, we succeeded in recovering a functional ASS servo . We then tried to maximize GTRX using the PZT mirrors, but were only successful in reaching a maximum of 0.41. The value I remember from before the vent was 0.5, and indeed, with the IR alignment not quite optimized before we began this work, I saw GTRX of 0.48. But the IR dither servo signals indicate that the cavity axis may have shifted (spot position on the ITM, which is uncontrolled, seems to have drifred significantly, the Pitch signal doesn't stay on the StripTool scale anymore). So we may have to double check that the transmitted beam isn't falling off the GTRX DC PD.
14162   Tue Aug 14 02:01:12 2018 gautamUpdateLSCDRMI locking - partial success

After tweaking the AS55 demod phase, SRM alignment, triggering settings, I got a few brief DRMI locks in tonight, I'm calling it a success (though this isn't really robust yet). The main things to do now are:

• turn on all the boosts on the LSC loops - today I only managed to trigger the PRCL boost filters successfully without blowing up the lock.
• measure all 3 loops, tweak gain as necessary.
• Run some sensing lines, tune the demod phase.
• The SRCL triggering is strange to me - SRCL loop is currently triggered on POP22_I, but the 2f1 buildup in the symmetric side does not say anything about the linearity of the SRCL error signal? Or are we just hoping the SRM is in the correct place and engaging the servo? Anyway, this setting seems to work but perhaps once the locking is more robust the triggering can be fixed.
• do a quick NB - I expect the main change to be that the AS55_Q dark noise contribution would have gone up on account on the reduced amount of light at this port.

I think the main IFO characterization remaining to be done to determine the status of the IFO post vent is to measure the losses of the arm cavities. IMO, we will need to certainly fix the clipping at ETMY before we attempt some serious locking.

14164   Wed Aug 15 12:15:24 2018 gautamUpdateCOCMacroscopic SRC length for SR tuning

Summary:

It looks like we can have a stable SRC of length 4.044 m without getting any new mirrors, so this is an option to consider in the short-term.

Details:

• The detailed calculations are in the git repo
• The optical configuration is:
• A single folding mirror approximately at the current SR3 location.
• An SRM that is ~1.5m away from the above folding mirror. Which table the SRM goes on is still an open question, per the previous elog in this thread.
• The SRC length is chosen to be 4.044 m, which is what the modeling tells us we need for operating in the SR tuning instead of RSE.
• Using this macroscopic length, I found that we could use a single folding mirror in the SRC, and that the existing (convex) G&H folding mirrors, which have a curvature of -700m, happily combine with our existing SRM (concave with a curvature of 142m) to give reasonable TMS and mode-matching to the arm cavity.
• The existing SRM transmission of 10% may not be optimal but Kevin's calculations say we should still be able to see some squeezing (~0.8 dB) with this SRM.
• Attachment #1 - corner plot of the distribution of TMS for the vertical and horizontal modes, as well as the mode-matching (averaged between the two modes) between the SRC and arm cavity.
• Attachment #2 - histograms of the distributions of RoCs and lengths used to generate Attachment #1. The distributions were drawn from i.i.d Gaussian pdfs.

gautam 245pm: Koji pointed out that the G&H mirrors are coated for normal incidence, but looking at the measurement, it looks like the optic has T~75ppm at 45 degree incidence, which is maybe still okay. Alternatively, we could use the -600m SR3 as the single folding mirror in the SRC, at the expense of slightly reduced mode-matching between the arm cavity and SRC.

ELOG V3.1.3-