40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 274 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  15126   Wed Jan 15 15:04:31 2020 gautamUpdatePSLPMC Linewidth measurement

For the ringdowns, I suggest you replicate the setup I had - infrastructurally, this was quite robust, and the main problem I had was that I couldn't extinguish the beam completely. Now that we have the 1st order beam, it should be easy.

  15127   Wed Jan 15 16:08:40 2020 not gautamUpdatePSLAssembly underway for c1psl upgrade

You're right. We had the right idea before but we got confused about this issue. I changed all the XT1121s to XT1111 and vice versa. We already know which channels are sourcing and which not. Updated the wiring spreadsheet. The chassis seems to work. It's time to pass it over to Chub.

Quote:

I don't think this is an accurate statement. XT1111 modules have sinking digital outputs, while XT1121 modules have sourcing digital outputs. Depending on the requirement, the appropriate units should be used. I believe the XT1111 is the appropriate choice for most of our circuits.

For digital outputs, one should XT1121. XT1111 should be used for digital inputs.

  15131   Fri Jan 17 21:56:22 2020 YehonathanUpdatePSLAOM first order beam alignment

Today I noticed that the beam reflected from the PMC into the RFPD has a ghost (attachment) due to reflection from the back of the high transmission beam splitter that stirs the beam into the RFPD.

The two beams are focused into the RFPD.

In the past, the ghost beam was probably blocked by the BS mirror mount.

I put an iris to block the ghost beam.

Attachment 1: 20200117_174841.jpg
20200117_174841.jpg
  15132   Fri Jan 17 22:11:19 2020 YehonathanUpdatePSLRingdown measurements

I prepare for the ringdown measurement of the PMC according to Gautam's previous experiments.

1. I assembled the needed PDs and power supplies, lenses, beamsplitters and optomechanics needed for the measurement.

2. I surveyed the laser power with an Ophir power meter in the different parts of the experiment. All the measurements were done with the AOM driver excited with 1V DC.

For the PMC reflection, we chose to split off the beam that goes into the reflection camera. The power in that beam is ~ 0.11mW when the PMC is locked and 2.1mW otherwise.

For the PMC transmission, we chose to split the beam that is transmitted through the second steering mirror after the PMC. The power in that beam is 2mW.

For the peak off before the PMC, we chose to split the beam that goes into the fiber coupler. That path contains also the other AOM diffraction orders: 2.26mW in the 0th order beam, 6.5mW in the 1st order beam, 0.14mW in the 2nd order beam.

3. I placed a 10% beam splitter in the peak-off path such that 90% still goes into the fiber coupler (Attachment 1). I place a lens and PDA255 to measure the peak-off (Attachment 2).

It's getting late, I'll continue with the PD placements on Tuesday.

Attachment 1: 20200117_192455.jpg
20200117_192455.jpg
Attachment 2: 20200117_192448.jpg
20200117_192448.jpg
  15133   Mon Jan 20 12:16:50 2020 gautamUpdatePSLPMC input reverted to AOM zeroth order beam

Summary:

  1. The input beam to the PMC cavity was changed back to the zeroth order beam from the AOM. 
  2. The PMC was locked and nominal transmission levels were recovered.
  3. The AOM driver voltage was set to 0V DC. 
  4. A razor beam dump was placed to catch the first (and higher order) beams from the AOM (see Attachment #1), but allow the zeroth order beam to reach the PMC cavity.
  5. Some dangling cabling was cleared from the PSL enclosure.

Details

  • HEPA turned to 100% while work was going on in the PSL enclosure.
  • Input power to the PMC cut from ~1.3 W to ~20 mW using the first available HWP downstream of the laser head, before any realignment work was done.
  • Next, the beam dump blocking the undeflected zeroth order beam was removed.
  • Triangle wave was applied to the PZT servo board "EXT DC" input to sweep the cavity length to make the alignment easier.
  • After some patient alignment, I could see a weak transmitted beam locked to some high order mode, at which point I increased the input power to 200mW, and did the fine alignment by looking at the mode shape of the transmitted beam.
  • Once I could lock to a TEM00 mode, I bumped the power back up to the nominal 1.3W, I fine tuned the alignment further by minimizing PMC REFL's DC level. 
  • Dialled the power back down (using HWP) for installation of the beam block to catch the AOM's first (and higher order) beams.
  • Checked that the reflected beam from the PMC cavity is well centered on the PMC REFL PDH photodiode. The ghost from the AR coating of the high-T beamsplitter is blocked by the iris installed by yehonathan on Friday. 
  • The beam was a little low on the PMC REFL CCD camera - I raised the camera by ~1cm.
  • With the beam axis well matched to the PMC, I measured 1.33 mW going into the cavity, and 1.1 W transmitted, so T_{\mathrm{PMC}} \approx 83 \, \%. Whatever loss numbers we extract should be consistent with this fact.
  • HEPA turned back down to 30% shortly after noon.

Note that for all the alignment work, only the two steering mirrors immediately upstream of the PMC cavity were touched.

Attachment 1: IMG_8362.JPG
IMG_8362.JPG
  15134   Mon Jan 20 15:11:20 2020 gautamUpdatePSLPMCT photodiode grounding issue

For a few days, I've noticed that the PSL overview StripTool panel shows PMC transmission and FSS RMTEMP channels with variation that is too large to be believable. Looking at these signals on an oscilloscope, there was no such fuzziness in the waveform. I ruled out flaky connections, and while these are the only two channels currently being acquired by the temporary Acromag setup underneath the PSL enclosure, the Acromags themselves are not to blame, because once I connected a function generator to the Acromag instead of the PMC transmission photodiode, both channels are well behaved. So the problem seems to be with the PMC transmission photodiode, perhaps a grouding issue? Someone please fix this.

Attachment 1: PMCT_anomaly.pdf
PMCT_anomaly.pdf
  15135   Mon Jan 20 20:20:36 2020 gautamUpdatePSLPMC servo checkout

Summary:

The PDH discriminant of the PMC servo was measured to be ~0.064 GV/m. This is ~50 times lower than what is reported here. Perhaps this is a signature of the infamous ERA decay, needs more investigation.

Details:

  • Calibration of the error and control points were done using 1 Hz triangle wave injection to the "EXT DC" input of the PMC servo. Two such sweeps are shown in Attachment #1 (measured data as points, fits as solid lines). For the control signal monitor, I've multiplied the signal obtained on the scope by 49.6, which is the voltage divider implemented for this monitor point.
  • The PDH discrimiannt was calibrated into physical units knowing the modulation frequency of the PMC, which is 35.5 MHz. The error in this technique due to the free-running NPRO frequency noise is expected to be small since the entire fringe is crossed in <30 ms, in which time the laser frequency is expected to change by < 5 kHz.
  • The drive to the PZT was calibrated into physical units using the same technique. This number is within a factor of 2 of the number reported here
  • Attachment #2 shows the loop OLTF measured using the usual IN1/IN2 prescription (with an SR560). In fact, the 8kHz feature makes the loop unstable. For convenience, I've overlaid the OLTF from March 2017, when things were running smoothly. It is not clear to me why even though the optical gain is now lower, a smaller servo gain results in a larger UGF.

The light level hasn't changed by a factor of 50, leading me to suspect the modulation depth. Recall that the demodulation of the PMC is now done off the servo board using a minicircuits mixer (hence, the "C1:PSL-PMC_LODET" channel isn't a reliable readback of the LO signal strength over time). Although there is a C1:PSL-PMC_MODET channel which looks like it comes from the crystal reference card, and so should still work - this, however, shows no degradation over 1 year.

Somebody had removed the BLP-1.9 that I installed at the I/F output of the mixer to remove the sum frequency component in the demodulated signal, I reinstalled this. I find that there are oscillations in the error signal if the PMC servo gain is increased above 14.5 on the MEDM slider.

Attachment 1: PMCsweep.pdf
PMCsweep.pdf
Attachment 2: OLTFmeas.pdf
OLTFmeas.pdf
  15138   Wed Jan 22 11:00:21 2020 gautamUpdatePSLPMC REFL ghost beam

I looked into this a little more today.

  1. The steering optic used to route PMC REFL to the RFPD is in fact a window (labelled W1-PW-1025-UV-1064-45P), not a High-T beamsplitter.
  2. With the PMC unlocked, I measured ~10.70 mW in the stronger of the two beams, 5.39 mW in the weaker one. 
    • The window spec is Tp > 97%. Since we have ~1.3 W incident on the PMC, the primary reflection corresponds to T=99.2%, which is consistent with the spec.
    • There is no spec given for the coating on the back side of this window. But from the measured values, it seems to be R = 100* 5.39e-3 / (1.3*T^2) ~ 0.4%. Seems reasonable.

Currently, the iris is set up such that the stronger beam makes it to the PMC RFPD, while the weaker one is blocked by the iris. As usual, this isn't a new issue - was noted last in 2014, but who knows whether the new window was intalled...

Quote:

Today I noticed that the beam reflected from the PMC into the RFPD has a ghost (attachment) due to reflection from the back of the high transmission beam splitter that stirs the beam into the RFPD.

  15139   Wed Jan 22 11:22:39 2020 gautamUpdatePSLPMC modulation depth measurement

Summary:

I estimate the PMC servo modulation depth to be approximately 50 mrad. This is only 15% lower than what was measured in Jan 2018, and cannot explain the ~x50 reduction of optical gain measured earlier in this thread. Later in the day, I also confirmed that the LO input to the ZAD-6 mixer is +7 dBm. So the crystal is not to blame.

Details:

  1. PSL frequency is locked to the IMC length.
  2. Arm lengths are locked to the PSL frequency using POX/POY.
  3. EX green laser locked to the X arm length using end PDH servo. GTRX was ~0.4 in this measurement, which is the nominal value.
  4. The 20dB coupled port of the beat between the EX and PSL lasers was monitored using the AG4395A in "Spectrum" units.
  5. The beat was set at ~90 MHz, and a spectrum was taken for ~100 MHz span centered at the beat frequency.
  6. The modulation depth is estimated by considering the ratio of power at the beat frequency relative to that 35.5 MHz away. See Attachment #1.

Assuming a finesse of 700 for the PMC, we expect an optical gain of 2*Pin*J0(50e-3)*J1(50e-3)/fp  ~ 1.2e-7 W/Hz (=0.089 GW/m). I can't find a measurement of the PMC RFPD transimpedance to map this onto a V/Hz value. 

Attachment 1: modDepth.pdf
modDepth.pdf
  15143   Wed Jan 22 20:12:36 2020 gautamUpdatePSLPMC demodulator electrical characterization

Summary:

The mixer + LPF combo used to demodulate the PMC PDH error signal seems to work as advertised.

Details:

Measurement setup --- Attachment #1. The IF signal was monitored using the scope in High-Z mode.

Results --- Attachment #2.

So the next step is to characterize the RF transimpedance of the PMC RFPD.

Attachment 1: demodChar.pdf
demodChar.pdf
Attachment 2: mixerChar.pdf
mixerChar.pdf
  15144   Thu Jan 23 14:37:05 2020 gautamUpdatePSLPMC VGA chip damaged?

[jordan, gautam]

Summary:

The AD602 chip which implements the overall servo gain for the PMC seems to be damaged. We should switch this out at the next opportunity.

Details:

  1. According to the PSL cross connect wiring diagram, the VME DAC that provides the control voltage to the VGA stage goes to pins 7/8 of cross connect J16.
    • Jordan and I verified that the voltage at this point [Vout], is related to the PMC_GAIN EPICS slider [dB] value according to the following relationship: V_{\mathrm{out}} = (10-\mathrm{dB})/2.
  2. On the PMC servo board, this voltage is scaled by a factor of -1/10. 
    • This was confirmed by peeking at this voltage using a DMM (I clipped onto R31) while the gain slider was varied.
    • This corresponds to +/- 1000 mV reaching the AD602.
    • However, the AD602 is rated to work with a control voltage varying between +/- 625 mV.
    • What this means is that the EPICS slider value is not the gain of the AD602 stage. The latter is given by the relation G [\mathrm{dB}] = 32 \times V_{\mathrm{G}} + 10.
    • @team PSL upgrade: this should be fixed in the database file for the new c1psl machine.
  3. Using TP1 and TP2 connected to the SR785, I measured the transfer function of the AD602 for various values of the EPICS slider.
    • Result is shown in Attachment #1.
    • I did this measurement with the PMC locked, so I'm using the in-loop error signal to infer the gain of the VGA stage.
    • As expected, the absolute value of the gain does not match that of the EPICS slider (note that the AD602 has an input impedance of 100 ohms. So the 499 ohm series resistor between TP1 and the input of AD602 makes a 1/5 voltage divider, so the gain seen between TP1 and TP2 has this factor folded in).
    • Moreover, the relative scaling of the gain for various slider values also doesn't appear to be liner.
    • For the highest gain setting of +15 dB, the servo began oscillating, so I think the apparent non-flatness of the gain as a function of frequency is an artefact of the measurement.
    • Nevertheless, my conclusion is that the IC should be changed.

I will pull the board and effect the change later today.

I pulled the board out at 345pm after dialling down all the HV supplies in 1X1. I will reinstall it after running some tests.

Attachment 1: VGAchar.pdf
VGAchar.pdf
  15146   Thu Jan 23 16:37:14 2020 ranaUpdatePSLPMC VGA chip damaged?

doesn't seem so anomolous to me; we're getting ~25 dB of gain range and the ideal range would be 40 dB. My guess is that even thought this is not perfect, the real problem is elsewhere.

  15147   Thu Jan 23 18:52:31 2020 gautamUpdatePSLPMC RFPD characterization

Summary:

The RF transimpedance of the PMC PDH RFPD was measured, and found to be 1.03 kV/A

Details:

With the new fiber coupled PDFR system, it was very easy to measure the response of this PD in-situ 🎉 . The usual transfer function measurement scheme was used, with the AG4395 RF out modulating the pump current of the diode laser, and the measured transfer function being the ratio of the response of the test PD to the reference PD.

I assume that the amount of light incident on the reference NF1611 photodiode and the test photodiode were equal - I don't know what the DC transimpedance of the PMC REFL photodiode is (can't find a schematic), but the DC voltage at the DC monitor point was 16.4 mV (c.f. -2.04 V for the NF1611). The assumption shouldn't be too crazy because assuming the reference PD has an RF transimpedance of 700 V/A (flat in the frequency range scanned), we get a reasonable shape for the PMC REFL photodiode's transimpedance.

The fitted parameters are overlaid in Attachment #1. The 2f notch is slightly mistuned it would appear, the ratio of transimpedance at f1/2*f1 is only ~10. The source files have been uploaded to the wiki.

Knowing this, the measured PDH discriminant of 0.064 GV/m is quite reasonable:

  • expected optical gain from modulation depth assuming a critically coupled cavity is 0.089 GW/m.
  • Assume 0.7 A/W responsivity for InGaAs.
  • Account for the fact that only 0.8 % of the reflected light reaches the PMC photodiode because of the pickoff window.
  • Account for a conversion loss of 4.5 dB in the mixer.
  • Account for the voltage division by a factor of 2 at the output of the BLP-1.9 filter due to the parallel 50 ohm termination.
  • Then, the expected PDH discriminant is 0.089e9 W/m * 0.7 A/W * 0.8e-2 * 1.03kV/A * 10^(-4.5/20) * 0.5 ~ 0.15 GV/m. This is now within a factor of ~2 of the measured value, and I assume the total errors in all the above assumed parameters (plus the cable transmission loss from the photodiode to the 1X1 rack) can easily add up to this. 

So why is this value so different from what Koji measured in 2015? Because the monitor point is different. I am monitoring the discriminant immediately after the mixer, whereas Koji was using the front panel monitor. The latter already amplifies the signal by a factor of x101 (see U2 in schematic). 

Conclusion:

I still haven't found anything that is obviously wrong in this system (apart from the slight nonlinearity in the VGA stage gain steps), which would explain why the PMC servo gain has to be lower now than 2018 in order to realize the same loop UGF.

So the next step is to characterize the RF transimpedance of the PMC RFPD.

Attachment 1: PDresp.pdf
PDresp.pdf
  15149   Thu Jan 23 22:10:01 2020 gautamUpdatePSLPMC servo pulled out

While I have the board out, I'll try and do a thorough investigation of TFs and noise of the various stages. There is no light into the IFO until this is done.

I pulled the board out at 345pm after dialling down all the HV supplies in 1X1. I will reinstall it after running some tests.

  15150   Thu Jan 23 23:07:04 2020 JonConfigurationPSLc1psl breakout board wiring

To facilitate wiring the c1psl chassis and scripting loopback tests, I've compiled a distilled spreadsheet with the Acromag-to-breakout board wiring, broken down by connector. This information is extractable from the master spreadsheet, but not easily. There were also a few apparent typos which are fixed here.

The wiring assignments at the time of writing are attached below. Here is the link to the latest spreadsheet.

Attachment 1: c1psl_feedthrough_wiring.pdf
c1psl_feedthrough_wiring.pdf c1psl_feedthrough_wiring.pdf c1psl_feedthrough_wiring.pdf c1psl_feedthrough_wiring.pdf
  15152   Fri Jan 24 15:42:08 2020 gautamUpdatePSLPMC servo restored

The PMC servo was re-installed at ~345pm. HV supplies were re-energized to their nominal values. I will update the results of the investigation shortly. The new nominal PMC servo gain is +9dB.

Quote:

While I have the board out, I'll try and do a thorough investigation of TFs and noise of the various stages. There is no light into the IFO until this is done.

I pulled the board out at 345pm after dialling down all the HV supplies in 1X1. I will reinstall it after running some tests.

  15154   Sat Jan 25 11:54:42 2020 YehonathanUpdatePSLRingdown measurements

Zero order beam PMC ringdown

On Wednesday I installed 3 PDs (see attached photos) measuring: 

1. The input light to the PMC. Flip-mirror was installed (sorry Shruti) on the beam path to the fiber coupler.

2. Reflected light from the PMC.

3. PMC transmitted light.

I connected the three PDs to the oscilloscope and the AOM driver to a function generator. I drive the AOM with a square wave going from 1V to 0V.

I slowly increased the square wave frequency. The PMC servo doesn't seem to care. I reach 100KHz - it seems excessive but still works. In any case, I get the same results doing a single shut-down from a DC level.

I download the traces. I normalize the traces but I don't rescale them (Attachment 4) so that the small extinction can be investigated.

I notice now that the PDs show the same extinction. It probably means I should have taken dark currents data for the PDs.

Also, I forgot to take the reflected data when the PMC is out of resonance with the laser which could have helped us determine the PMC transmission.

Again, the shutdown is not as sharp as I want. There is a noticeable smoothening in the transition around t = 0 which makes the fit to an exponential difficult. I suspect that the function generator is the limiting device now. I hooked up the function generator to the oscilloscope which showed similar distortion (didn't save the trace)

I try to fit the transmission PD trace to a double exponential and to Zucker model (Attachment 5).

The two exponentials model, being much less restrictive, gives a better fit but the best fit gives two identical time constants of 92ns.

The Zucker model gives a time constant of 88ns. Both of these results are consistent with more or less with the linewidth measurement but this measurement is still ridden with systematics which hopefully will become minimized IMC ringdowns.

Attachment 1: Input_beam_path.jpg
Input_beam_path.jpg
Attachment 2: Reflected_Beam_Path.jpg
Reflected_Beam_Path.jpg
Attachment 3: Transmitted_Beam_Path.jpg
Transmitted_Beam_Path.jpg
Attachment 4: PMCRingdownNormalizedRawdata.pdf
PMCRingdownNormalizedRawdata.pdf
Attachment 5: TransPDFits.pdf
TransPDFits.pdf
  15156   Sun Jan 26 13:47:00 2020 gautamUpdatePSLPMC servo characterization

Summary:

  1. I investigated the stage-by-stage transfer functions of the PMC servo up till the HV stage. See Attachment #1. There were no unexpected features.
  2. I replaced the AD602 used to implement the VGA capability. After the replacement, the gain of the VGA stage had the desired performance, see Attachment #2, Attachment #3.
  3. The servo board was re-installed and the OLTF of the PMC loop was measured. See Attachment #4.

​To avoid driving the PA85 without the HV rails connected, I removed R23. This was re-installed after my characterization.

Input stage:

Since we do the demodulation of the PMC PDH signal off this servo board, the I/F mixer output is connected to the "FP1test" front panel LEMO input.

  • A DG190 is used to enable/disable this path.
  • Initially I tried checking the enable/disable functionality by measuring the resistance across the IC's I/O pins. However, this method does not work - the resistance read off from a DMM varied from ~23 ohms in the "ON" state to ~123 ohms in the "OFF" state. While the former value is consistent with the spec, the latter is confusing.
  • But I confirmed that the switch does indeed isolate the input in the "OFF" state by injecting a signal with a function generator (100 Hz sine wave, 100mVpp) and monitoring the output on an oscilloscope.

Electronic TFs:

Using some Pomona mini-grabbers, I measured the electronic TFs between various points on the circuit. There were no unexpected features, the TFs all have the expected shape as per the annotations on the DCC schematic. I did not measure down to 0.1 Hz to confirm the low frequency pole implemented by U6, and I also didn't measure the RF low pass filter at the input stage (expected corner frequency is 1 MHz). 

VGA characterization:

After replacing the IC, I measured the transfer function between TP1 and TP2 for various values of the control voltage applied to pin 4A on the P1 connector, varying between +/- 5 V DC. 

  • Pin 9A on the P1 connector has to be grounded for the signal to be allowed to pass through the VGA. 
  • Note that there is an overall gain of -1/10 applied to the control voltage between pin 4A and pin #1 of the AD602, which is what actually sets the gain.
  • Furthermore, the input impedance of the AD602 is spec-ed to be 100 ohms. Because of the series resistance of 500 ohms from TP1 to the input of the AD602 (so that the upstream OP27 isn't overdrawn for current), the relation between the control voltage applied to Pin 4A and gain (measured between TP1 and TP2) is modified to G [dB] = 32*(-0.1 * V_pin4A) - 6. 
  • The gain behavior after the IC swap is as expected, both in terms of absolute gain, and the linearity w.r.t. the control voltage.
  • Note that in Attachment #2, each color corresponds to a different control voltage to the AD602, varying from -5V DC to +5V DC in 1V steps. 

PZT Capacitance measurement

I confirmed that the PZT capacitance is 225 nF. The measurement was made using an LCR meter connected to the BNC cable delivering the HV to the PZT, at the 1X1 rack end.

OLTF measurement

After re-soldering R23, I put the board back into its Eurocrate, and was able to lock the PMC. For subsequent measurements, the PSL shutter was closed.

  • I measured the OLTF using the usual IN1/IN2 prescription, implemented with the help of an SR560.
  • At the original PMC Servo gain of +12dB, I found that the feature at ~8kHz results in an OLTF with multiple unity gain crossings.
  • So I lowered it to +9dB. This yields an OLTF with ~60deg phase margin, ~2.3 kHz UGF. 
  • The feature that sets the gain margin is actually not any of the peaks fit by LISO, but is one of the high frequency features at ~40 kHz. At the new setting of +9dB gain, the gain margin is ~10 dB.
  • The measured TF (dots in Attachment #5) was fit with LISO (solid lines in Attachment #5) to allow inferring the out-of-loop servo noise by monitoring the in-loop noise (that plot to follow).
Attachment 1: elecTFs.pdf
elecTFs.pdf
Attachment 2: VGAchar_postFix.pdf
VGAchar_postFix.pdf
Attachment 3: VGAlinearity_postFix.pdf
VGAlinearity_postFix.pdf
Attachment 4: newOLTFs.pdf
newOLTFs.pdf
  15160   Mon Jan 27 21:35:06 2020 YehonathanUpdatePSLRingdown measurements

Zeroth order IMC ringdown setup

Following Gautam's IMC ringdown setup, I took the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).

I also ran a BNC cable from the transmission PD that Gautam installed on the IMC table to the vertex where the signals are measured on the scope. 

I offloaded the WFS servo output values onto the MC alignment (using the WFS servo relief script) so that its dc values would be correct when the servo is off.

Unfortunately, it seems like the script severely misaligned the MC mirrors at some point when the MC got unlocked. We should fix the script such that it stops when the offloading is complete.

We got the MC realigned but left it in a state where it is not locking easily.

Attachment 1: IMC_REFL_Beam_Path.jpg
IMC_REFL_Beam_Path.jpg
  15161   Mon Jan 27 21:48:49 2020 gautamUpdatePSLRingdown measurements

It's fine to block the WFS while doing ringdowns but please return the config to normal so I don't have to spend time every night recovering the interferometer before doing the locking. As I mention in that post, it is possible to do this in a non-invasive way without having to run any extra cables / permanently block any beams. If there is some issue with the data quality, then we can consider a new setup. But I see no reason to re-invent the wheel.

The IMC was also massively misaligned. I had to re-align both MC1 and MC2 to recover the lock. I took this opportunity to reset the WFS offsets. Please do not disturb the alignment of the existing optical layout unless you verify that everything is working as it should be after your changes.

And for whatever reason, ITMX was misaligned. If you do something with the interferometer, no matter how minor it seems, please leave a note on the ELOG. It will save many painful debugging hours.

As I fix these, the seismic activity has gone up no. I'll wait around for an hour, but not an encouraging restart to the locking 😢 

Quote:

Zeroth order IMC ringdown

Following Gautam's IMC ringdown setup, I took the the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).

Attachment 1: elevatedSeis.pdf
elevatedSeis.pdf
  15163   Tue Jan 28 14:33:24 2020 gautamUpdatePSLInferred free-running frequency noise

To conclude my PMC noise investigations: Attachment #1 shows the PMC noise inferred from the calibrations earlier in this thread and the fitted OLTF for the PMC loop. Attachment #2 compares the frequency noise (inferred from the error point of the PMC servo) when the IMC is locked / unlocked. I don't know what to make of the fact that the PMC suggests improvement from ~20 Hz onwards already - does this mean that the NPRO noise model is wrong by 1 order of magnitude at 30 Hz?

  • The IMC was locked for the measurement shown in Attachment #1.
  • The in-loop spectra of the error (at the I/F output of the mixer) and control (at TP3) signals were measured with the SR785.
  • The control signal voltage monitors don't seem to work - neither the front panel LEMO nor the signals hooked up to the CDS system show me sensible shapes for the spectra between 1-3 Hz.
  • To convert in loop to free-running, I multiplied the measured error (control) signal spectra by \left | 1-L \right | (\left | \frac{L}{1-L} \right |), where L is the OLTF. THe control signal was pre-processed by multiplying by a pole at 11.3 Hz, corresponding to the LPF formed by the 63.3 kohm series resistor and the 225 nF PZT capacitance.
  • The "NPRO noise model" curve is 10^4/f Hz/rtHz.

While I initially thought the 1/f^2 rise below ~100 Hz is attributable to the IMC cavity length fluctuations, I found that this profile is present even in the measurement with the PSL shutter closed. I am not embarking on a detailed PMC noise budgeting project for now. Note however that we are not shot noise limited anywhere in this measurement band.

  • The measured TF (dots in Attachment #5) was fit with LISO (solid lines in Attachment #5) to allow inferring the out-of-loop servo noise by monitoring the in-loop noise (that plot to follow).
Attachment 1: inLoopNoise_IMClocked.pdf
inLoopNoise_IMClocked.pdf
Attachment 2: freqNoiseComparison.pdf
freqNoiseComparison.pdf
  15168   Tue Jan 28 19:12:30 2020 JonConfigurationPSLSpare channels added to c1psl chassis

After some discussion with Gautam, I decided to build more spare channels into the new c1psl machine. This is anticipation of adding new laser and ISS channels in the near future, to avoid having to disconnect the installed chassis and pull it out of the rack. The spare channels will be wired to DB37M feedthroughs on the front side of the chassis, with enough wire length to be able to pull the breakout boards out of the front to reconfigure their wiring as needed (e.g., split off channels onto a separate connector).

To have enough overhead, this will require installing 1 additional ADC unit (XT1221) and 1 additional DAC (XT1541). We have enough spare BIO channels among the existing units (both sinking and sourcing). This will give us:

  • 13 spare ADC channels
  • 14 spare DAC channels
  • 16 spare sinking BIO channels
  • 12 spare sourcing BIO channels

The updated c1psl chassis wiring assignments are attached. It adds 4 new DB37M connectors for the spare channels (highlighted in yellow) and fixes one typo Jordan found while wiring today. The most current spreadsheet is available here.

Attachment 1: c1psl_feedthrough_wiring_v2.pdf
c1psl_feedthrough_wiring_v2.pdf c1psl_feedthrough_wiring_v2.pdf c1psl_feedthrough_wiring_v2.pdf c1psl_feedthrough_wiring_v2.pdf c1psl_feedthrough_wiring_v2.pdf
  15178   Thu Jan 30 17:31:28 2020 JonUpdatePSLErrant FSS_INOFFSET change

A script I was testing errantly set C1:PSL-FSS_INOFFSET => 10 V at about 5:30 pm. I manually reverted the channel value to 0, but I don't know what the value was initially. Someone please check this value if there are problems locking the FSS.

  15179   Thu Jan 30 17:41:10 2020 gautamUpdatePSLErrant FSS_INOFFSET change

You can trend the data for the past few hours and see what the appropriate value. I think these tests should only be done when whoever is running a test is in the lab.

P.S. I was surprised that the IMC didn't lose lock when this step was applied. I manually stepped this voltage between +/- 10 V and didn't see any response in the FSS readbacks. Either the channel doesn't work, or there is a divide by 40 in the physical circuit or something...

Quote:

A script I was testing errantly set C1:PSL-FSS_INOFFSET => 10 V at about 5:30 pm. I manually reverted the channel value to 0, but I don't know what the value was initially. Someone please check this value if there are problems locking the FSS.

  15184   Mon Feb 3 15:22:39 2020 JonUpdatePSLc1psl progress/Acromag ADC grounding

I tested the c1psl AO channels on the electronics bench on Friday. While I found all the wiring to be correct, some of the channels exhibited excess noise with all appearances of a grounding problem.

Today Jordan, Gautam, and I investigated this further. It is indeed a grounding problem, but actually with the Acromag ADCs. The Acromag DAC outputs are single-ended (return is grounded), so (for the purpose of a loopback test) I would expect to leave the ADC inputs ungrounded. This is the configuration I tested Friday. Today we also tested driving the ADC with a floating source. The ADC noise behavior is exactly the same, whether the source end is grounded or not.

However, grounding the minus pin of the ADC channel eliminates the noise. We don't understand why this seems to be required irrespective of the driving source, so there something we're missing about the ADC design. As it turns out, this same fix was made to the AI channels of the previously-upgraded Acromag machines. I know Chub and I had to do this for the AI channels of c1vac, but at the time we thought the source grounding was causing the issue. However, today Jordan and I looked inside c1iscaux, which Chub wired, and confirmed that its AI channels are wired in the same way.

So in any case, Jordan is grounding the c1psl AI channels in the same way as c1iscaux. Once this is done, we'll continue with the bench testing tomorrow.

gautam: here are my notes about this issue when i was doing the c1iscaux testing. As I note there, "previously-upgraded Acromag machines" in the plural may be a bit of a stretch - I have no idea what the grounding situation is in c1susaux / c1auxex for example.

  15186   Tue Feb 4 18:13:01 2020 YehonathanUpdatePSLBench testing of PSL ai channels

{Yehonathan, Jon, Jordan}

I tested the ai channels of the new PSL Acromag by looping an already-tested ao channel (C2:PSL-FSS-INOFFSET) back to the different ai channels.

I use Jon's IFOTest with /users/jon/ifotest/PSL.yaml.

I created a spreadsheet for the testing based on the current wiring spreadsheet. I added two columns for the high and low readings for each ai channel (attached pdf).

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

I redid the test on the channel that seemed disconnected to confirm.

I created a yaml file with all the failed channels for retesting called /users/jon/ifotest/PSL_failed_channels.yaml.

Attachment 1: c1psl_wire_testing_-_By_Connector.pdf
c1psl_wire_testing_-_By_Connector.pdf c1psl_wire_testing_-_By_Connector.pdf c1psl_wire_testing_-_By_Connector.pdf c1psl_wire_testing_-_By_Connector.pdf
  15187   Wed Feb 5 08:57:11 2020 YehonathanUpdatePSLBench testing of PSL ai channels

I checked the failed channels against the EPICS database definitions and the yaml file inputted to IFOTest. The channels where the readings are something other than +10/0 V, but the high/low values do change, I think can be attributed to one of two things:

  • An incorrect gain and/or offset conversion parameter in the yaml file
  • The EPICS SMOO parameter (smoothing) is set to some long value

I fixed the channel gains/offsets in the master yaml file (PSL.yaml). I also disabled smoothing in the EPICS defintions of the new PSL channels for the purpose of testing. We can uncomment those lines after installing the new chassis if noise is a problem. Please go ahead and re-test the channels again.

Quote:

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

  15189   Wed Feb 5 21:04:10 2020 YehonathanUpdatePSLBench testing of PSL ai channels

{Yehonathan, Jon}

We retested the failed ai channels. Most of them got fixed by applying the inverse calibration in the yaml file.

We still find some anomalous channels, mostly in the DB25 connector. Turns out, their limits were ill-defined in the EPICS database. Specifying the right limit fixed the issue.

We find one miswired channel (BNC4). We connected the BNC to the right channel on the Acromag unit which fixed the issue.

Overall all the ai channels were successfully bench-tested.

Quote:

I checked the failed channels against the EPICS database definitions and the yaml file inputted to IFOTest. The channels where the readings are something other than +10/0 V, but the high/low values do change, I think can be attributed to one of two things:

  • An incorrect gain and/or offset conversion parameter in the yaml file
  • The EPICS SMOO parameter (smoothing) is set to some long value

I fixed the channel gains/offsets in the master yaml file (PSL.yaml). I also disabled smoothing in the EPICS defintions of the new PSL channels for the purpose of testing. We can uncomment those lines after installing the new chassis if noise is a problem. Please go ahead and re-test the channels again.

Quote:

I marked in red the failed channels. Some of them are probably calibration issues, but the ones that show the same voltage for high and low are probably disconnected wires.

  15194   Thu Feb 6 21:54:13 2020 JonUpdatePSLc1psl bench testing complete

Today I engineered the last piece of the new c1psl system: the multi-bit binary output (mbbo) channels that control the MC servo board gains. These 6-bit channels have to be split across two 4-bit Acromag registers. To enforce synchronous switching, I adapted the latch.py script developed by Gautam to address this problem in c1iscaux. Analogously to the c1iscaux implementation, I scripted the code to automatically run as a systemd service which is launched by the main modbusIOC service. I tested this all using the DB37 LED test board and confirmed it to work.

This now completes the electronics bench testing.

There are still several DB37 connectors to be wired, which carry only spare channels for future use and are not interfaced with the EPICS IOC. Jordan and I discussed this today and he or Chub will complete it shortly. To allow time for the spare channel wiring to be completed (as well as for more locking progress before interruption), Gautam and I think Monday/Tuesday next week would be the earliest possible window to install the new system.

  15202   Mon Feb 10 10:07:20 2020 gautamUpdatePSLPMC re-locked

I found the PMC unlocked this morning. It was re-locked using the usual procedure. I feel like this has been happening more frequently in the last month than before. In the past, the cause seems to have been the PZT voltage drifting too close to one of the rails - however, in this case, it looks like an IMC unlock event is what triggered the PMC lockloss (admittedly the PZT voltage was somewhat close to the rail). It would be good if someone can re-connect the PMC Transmission photodiode, it was a useful diagnostic channel we had working fine before the ringdowns started.

I also tweaked the input pointing into the PMC and ran the WFS DC offset relief script.

Attachment 1: PMCunlock.png
PMCunlock.png
  15204   Mon Feb 10 15:54:47 2020 JordanUpdatePSLCompleted Acromag Wiring

All spare channels on the PSL acromag chassis are connected with ~12in of spare wiring for future use.

  15205   Mon Feb 10 15:55:46 2020 JordanUpdatePSLPMCTRANSPD

[Gautam, Jordan]

Gautam showed me how the PMCTRANSPD signal was reading zero, and he suspected it might have to do with the acromag wiring. Disconnected the acromag box underneath the PSL table and checked the ADC wiring. Side note: When benchtesting the c1psl acromag chassis there was excess noise in the AI channels, and grounding the minus pin of the ADC channel eliminates the noise.

So I grounded the (-) pins on the ADC1 (192.168.113.122), which PMCTRANSPD is connected to and that seemed to fix the problem. As of right now PMCTRANSPD is reading ~.75 V.

See attached pictures

gautam: While this fix seems to have worked, I wonder why this became necessary only in the last month. Note that the problem was a noisy readback on the PMC transmission PD, which also made the FSS_RMTEMP channel noisy, leading me to suspect some kind of ground loop issue.

Attachment 1: ADC1.jpg
ADC1.jpg
  15231   Thu Feb 27 17:50:36 2020 gautamUpdatePSLc1psl setup setup

[many people]

in prep for the install tomorrow, we did the following:

  • Install the c1psl Supermicro in the 1X2 rack (Attachment 1). To make room we removed the anti-image filter and mounted it on the OMC rack.
  • Set up a local workstation (monitor+mouse+keyboard) for the Supermicro so we can do some local testing (Attachment 2).
  • Clear up the immediate area around the 1X1/1X2 rack, setup a cart for the Acromag.
  • Make sure there are sufficient adaptor boards cables (DB37, DB15, DB9, DB25, ethernet) etc available at the cart.
  • Label cables, connect on Acromag chassis end (Attachment 3).
  • Keep some large (A3) printouts of the channel mapping handy by the cart.
  • made sure we have open fuse-able DIN rail connectors for +/-15 V DC and +/-24 V DC for the Acromag box (we are waiting on some thinner gauge cabling for the 24V supply, once that arrives, we will power the box from the Sorensens. For now, they are powered by bench supplies on the cart).
  • made sure c1psl1 (still this name for the Supermicro) is ssh-able.

Barring objections, tomorrow (Friday 28 Feb 2020) morning I will commence the switch (I still want to work on the IFO tonight).

Attachment 1: 20200227_173535.jpg
20200227_173535.jpg
Attachment 2: 20200227_173454_HDR.jpg
20200227_173454_HDR.jpg
Attachment 3: 20200227_172659.jpg
20200227_172659.jpg
  15234   Fri Feb 28 08:05:22 2020 gautamUpdatePSLc1psl setup setup

And so it begins.

Quote:

Barring objections, tomorrow (Friday 28 Feb 2020) morning I will commence the switch

  15235   Fri Feb 28 10:04:41 2020 gautamUpdatePSLc1psl setup setup

Summary:

There are several problems evident already.

  1. Several EPICS database entries were missing. WTF.
  2. After fixing the missing entries, the PMC could be locked. However, the IMC could not be locked.
  3. I think the FSS Interface card is not configured correctly.

For now, I've returned the old c1psl connections, the PMC and IMC are both locked. Need to do some debugging on the bench.

  15236   Fri Feb 28 19:37:18 2020 gautamUpdatePSLNew c1psl installed
  1. The new c1psl Acromag crate is now interfaced to the Eurocrate electronics in 1X1 (formerly VME c1psl) and 1X2 (formerly c1iool0).
  2. The PMC and IMC can be locked. We will investigate stability / duty cycle over the weekend.
  3. There were a few issues with the wiring - specifically, the worng kind of Acromag BIO unit (sourcing, whereas we want sinking) was used for the FSS board switches. Once Jordan fixed this issue, the IMC could be locked.
  4. I began to do the detailed tests of the IMC Servo card channels - there may be some issues with the boost stages, but I ran out of time yesterday, so tbc Monday.

On Monday, we will remove the old c1psl and c1iool0 machines from the electronics rack and install the Acromag crate in a more permanent way. We will also clean up some of the old cabling and cross connects, althoug the situation seems so complicated (some cross connects are also used by the rtcds c1ioo expansion chassis) that I am inclined not to remove any cables.

The area around 1X1/1X2 has a lot of dangling cables and general detritus. Be careful if you are walking around there. We will clean up on monday.

  15247   Wed Mar 4 11:16:37 2020 gautamUpdatePSLPMC realignment

I realigned the input pointing into the PMC this morning. Usually, the way I do this is to minimize any discernible mode structure in the PMC reflection CCD image. Today, I noticed that making the DC reflection go down also makes the DC transmission go down. Possibilities:

  • we are sampling slightly different spots inside the PMC cavity which change the buildup by ~2-3%.
  • we are misaligned on the transmission/reflection photodiode.
  • ??
Attachment 1: PMCrealignment.png
PMCrealignment.png
  15253   Wed Mar 4 22:38:31 2020 JonUpdatePSLc1psl communications problem resolved

I investigated the problem reported earlier today with the BIO1 channels. By logging the systemd messages generated when the IOC starts, I was immediately able to determine that the problem was not limited to BIO1. The modbus communications were failing for several other units as well.

Because some in-situ rewiring of a handful of channels had recently been done (more on this soon), I initially suspected that one of the Acromags had been damaged in the process. However, removing BIO1 (or other non-communicating modules) did not restore communications with the rest of the modules. To test whether the chassis was the source of the problem at all, we set up a fresh ADC (new out of the package) and directly connected it to the secondary Ethernet interface of c1psl. With only the one new ADC connected, the modbus IOC failed in exactly the same way.

To confirm that the new ADC did in fact work, we connected it to c1auxex in the same configuration. The unit worked fine connected to c1auxex. This established that the source of the problem was the c1psl host. After some extensive debugging, I traced the problem to a pre-execution script (part of the modbus IOC systemd service) which resets the secondary network interface (the one connected to the Acromag chassis) prior to launching the IOC. This was to ensure the secondary interface always had the correct IP address. It appears this reset was somehow creating a race condition that allowed the modbus initializations (first communications with the Acromags) to sometimes start before the network interface had actually come back up.

I still don't understand how this was happening, or why the pre script worked just fine up until yesterday, but eliminating the network interface reset fixes the problem in 100% of the trials we ran. Unfortunately we lost the entire day to debugging this problem, so the final round of testing is still to be completed. We plan to pick it back up tomorrow afternoon.

  15256   Thu Mar 5 19:45:23 2020 JonSummaryPSLC1PSL in-situ test results

We've completed almost all of the in-situ testing of the c1psl channels. During this process, we identified several channels which needed to be rewired to different Acromags (BIO sinking v. sourcing). We also elected to change the connector type of a few channels for practical advantages. Those modifications and other issues found during testing are detailed below. Also attached are the updated channel assignments, with a column indicating the in-situ testing status of each channel.

Post-installation modifications

  • All four channels connected to the sourcing BIO module were found to in fact require sinking I/O. They were reassigned to sinking BIO modules. Affected channels:
    • C1:PSL-FSS_FASTSWEEP
    • C1:PSL-FSS_SW1
    • C1:PSL-FSS_SW2
    • C1:PSL-PSL_Shutter
  • Added a new AI channel:
    • C1:PSL-FSS_MIXERM
  • Removed an unneccessary AI channel:
    • C1:PSL-FSS_LODET
  • Moved two AI channels from BNC connectors to a new Dsub connector (labelled DB25M-2 in the spreadsheet).
    • C1:PSL-FSS_RCTEMP
    • C1:PSL-FSS_RMTEMP_VOLTS

Issues identified during testing

  • Digital calibration. The following channels work, but we need to verify their EPICS calibration parameters (EGUF/EGUL):
    • C1:PSL-FSS_FASTGAIN
    • C1:PSL-FSS_FAST
    • C1:PSL-PMC_RFADJ
    • C1:PSL-PMC_MODET
  • IMC servo board. The Acromag channels themselves were found to work, but the linearity of the mbbo gain stages are in question (i.e., a potential problem with the board). GV is currently testing the servo board.
  • PSL QPD board apears to be dead. We connected a scope directly to the test points on the board and measured a high level of noise and no signal (for all four of the QPD channels). I understand this QPD has not been used in some time, so it may not have been noticed before.
  • WFS DC channels are saturating when the IMC is unlocked. The acceptance range of the Acromag ADC is only +/-10 V, but we measured sensor voltages as high as ~14 V. It appears that the old ADCs were somehow accepting a range of 0 to +20 V instead of -10 to +10 V. However, the Acromags do not support the input range 0-20 V. Since SNR is not critical for these channels (they're used only for initial alignment), I propose we simply install a voltage divider inside the chassis, just before the Acromag, for each of these signals.
Attachment 1: c1psl_feedthrough_wiring_-_By_Connector_(3).pdf
c1psl_feedthrough_wiring_-_By_Connector_(3).pdf c1psl_feedthrough_wiring_-_By_Connector_(3).pdf c1psl_feedthrough_wiring_-_By_Connector_(3).pdf c1psl_feedthrough_wiring_-_By_Connector_(3).pdf
  15266   Wed Mar 11 18:12:53 2020 gautamSummaryPSLWFS Demod board modifications

[koji, gautam]

Attachment #1 shows the relevant parts of the schematic of the WFS demod board (not whitening board). 

  • The basic problem was that the switchable gain channels were not accounted for in the Acromag channel list 😒.
  • What this meant was that the DC gain was set to the default x100 (since the two DG211s that provide the switchable x10 and x1 gain options had their control logic pins pulled up to +5V because these pins weren't connected to any sinking BIO channel).
  • Rather than set up new connections to Acromags inside the chassis (though we have plenty of spares), Koji and I decided to make these fixed to x1 gain.
  • The actual fix was implemented as shown in the annotated schematic. There are some pictures 📷 of the PCB in the DCC entry linked above.
  • Amusingly, this board will now require a sourcing BIO unit if we want to still have the capability of switching gains.

Before removing the boards from the eurocrate: 

  • I dialled down the Kepco HV supplies
  • disconnected all the cabling to these boards after noting down cable numbers etc.

After Koji effected the fix, the boards were re-installed, HV supplies were dialled back up to nominal voltage/currents, and the PMC/IMC were re-locked. The WFS DC channels now no longer saturate even when the IMC is unlocked 👏 👏 . I leave it to Yehonathan / Jon to calibrate these EPICS channels into physical units of mW of power. We should also fix the MEDM screen and remove the un-necessary EPICS channels.

Later in the evening, I took advantage of the non-saturated readbacks to center the beams better on the WFS heads. Then, with the WFS servos disabled, I manually aligned the IMC mirrors till REFLDC was minimized. Then I centered the beam on the MC2 transmission QPD (looking at individual quadrants), and set the WFS1/2 RF offsets and MC2 Trans QPD offsets in this condition.

Quote:

WFS DC channels are saturating when the IMC is unlocked.

Attachment 1: D980233-B_Mar2020Mods.pdf
D980233-B_Mar2020Mods.pdf
  15272   Thu Mar 12 16:13:16 2020 gautamUpdatePSLTemperature sensors connected to Acromag

[jordan, gautam]

the long DB25 cable to connect the Acromag chassis to the temperature sensor interface box arrived. We laid it out today. This cable does the following:

  1. Supply the box with +/- 24 V DC from the chassis. The pin arrangement here is rather unfortunate (the +/-24 V DC and GND pins are in close proximity), so if you're not careful, you'll create a short as you plug this cable in (as we found out today). So the best practise is to power down the crate before connecting/disconnecting this cable. Jordan will label this accordingly tomorrow.
  2. Pipe the "TAMB" and "TCAV" signals, corresponding to temperature sensors mounted to the PSL table-top and reference cavity exterior respectively, to the Acromags. We found during some initial testing that the "TAMB" signal was reaching the DB25 connector on the Acromag chassis, but wasn't going to any ADC channel - this was rectified.

Both signals now show up in the EPICS channels, but are noisy - I suspect this is because the return pin of the Acromag is not shorted to ground (this is a problem I've seen on the bench before). We will rectify this tomorrow as well.

We took this opportunity to remvoe the bench supply and temporary Acromag crate (formerly known as c1psl2) from under the PSL table. While trying to find some space to store the bench supply, we came across a damaged Oscilloscope in the second "Electronics" cabinet along the Y-arm, see Attachment #1. 

After this work, I found that the IMC autolocker was reliably failing to run the mcup script at the stage where the FSS gains are ramped up to their final values. I was, however, able to smoothly transition to the low-noise locked state if I was manipulating the EPICS sliders by hand. So I added an extra 2 seconds of sleep time between the increasing of the VCO gain to the final value and the ramping of the FSS gains in the mcup script (where previously there was none). Now the autolocker performs reliably.

Attachment 1: P_20200317_153736_vHDR_On_2.jpg
P_20200317_153736_vHDR_On_2.jpg
  15275   Fri Mar 13 14:28:39 2020 gautamUpdatePSLAdded tees to PMC Trans and REFL

I want to monitor the PMC TRANS and REFL levels on the PSL table - previously there were some cables going to the oscilloscope on the shelf but someone had removed these. I re-installed them just now. While there, I disconnected the drive to the AOM - there must've been some DC signal going to it because when I removed the cable, the PMC and IMC transmission were recovered to their nominal levels.

  15310   Wed Apr 22 17:29:14 2020 gautamUpdatePSLFSS debugging attempts

Summary:

On Monday, I hooked up an AG4395 to the PMC error point (using the active probe). The idea was to take a spectrum of the PMC error point every time the FSS PC drive RMS channel indicated an excursion from the nominal value. An initial look at the results don't suggest that this technique is particularly informative. I'll have to think more about a workaround, but please share your ideas/thoughts if you have some.

Also, the feature in the spectrum at ~110 kHz makes me suspect some kind of loop instability. I'll measure the IMC loop OLG at the next opportunity.

Details:

  • The PMC servo bandwidth is ~2 kHz, so above this, the PMC error point should be a faithful monitor of the PSL frequency noise, provided the sensing noise is low enough.
  • The PMC error point sensing noise is ~100nV/rtHz (I'm monitoring this straight after the Minicircuits mixer+bandpass filter that we are using as a demodulator). This corresponds to ~2 Hz/rtHz, using the ~10 MHz/V PDH discriminant calibration from January. Seems consistent with this elog.
  • I was hoping to see if there was a particular frequency band in which the noise gets elevated, and if the crossover frequency is a few kHz and the IMC servo BW is ~110 kHz, I would have expected this to be in the 10-100 kHz region. Possibly my frequency resolution isn't good enough? But with the Agilent, doing a finer grid would mean a longer measurement time, in which case the IMC might lose lock before the measurement is done.
  • But, as shown in Attachment #1, there isn't any clear evidence, from the ~20 excursions that were recorded last night. The color of the line is meant to be indicative of the average value of the PC drive RMS channel in the measurement time.
  • A significant bottleneck in this whole process is that it takes ~1 minute to initiate the GPIB measurement, and download the data. The pseudo-code I used is:
    • While the IMC is locked, watch PCdrive RMS EPICS channel's "ALARM" state, which becomes non-zero when the PCdrive RMS exceeds 1 V (this is how it is defined in the EPICS db record right now).
    • Make sure this isn't a transient feature - I do this by waiting 5 seconds and checking that the ALARM flag is still flagged.
    • Initiate a AG4395 measurement over GPIB - I use the measurement span of 1 kHz - 1 MHz with a BW/span ratio of 0.1%, 5 averages.
    • Check that the IMC is still locked (if it got unlocked while the measurement was made, presumably the measurement is garbage).
  • Is there a better monitor of the laser frequency noise? I can imagine using POX/POY which I think have a lower electronics noise floor but I'm not sure if that's true at 100 kHz and having the arms locked in addition to the IMC seems more complicated...
  • Since we are planning a laser upgrade, is this worth spending more time on? I may leave the measurement running on pianosa in a tmux session while I'm not in the lab...
Attachment 1: FSSspec.pdf
FSSspec.pdf
  15312   Thu Apr 23 10:42:02 2020 ranaUpdatePSLFSS debugging attempts

I had set up the 4395 to do this automatically a few years ago, but it looked at the FSS/IMC instead. When the PCDRIVE goes high there is this excess around ~500 kHz in a broad hump.

But the IMC loop gain changes sometimes with alignment, so I don't know if its a loop instability or if its laser noise. However, I think we have observed PCDRIVE to go up without IMC power dropping so my guess is that it was true laser noise.

This works since the IMC is much more sensitive than PMC. Perhaps one way to diagnose would be to lock IMC at a low UGF without any boosts. Then the UGF would be far away from that noise making frequency. However, the PCDRIVE also wouldn't have much activity.

  15570   Tue Sep 15 10:57:30 2020 gautamUpdatePSLPMC re-locked, RGA re-enabled

The PMC has been unlocked since September 11 sometime (summary pages are flaky again). I re-locked it just now. I didn't mess with the HEPA settings for now as I'm not using the IFO at the moment, so everything should be running in the configuration reported here. The particulate count numbers (both 0.3um and 0.5um) reported is ~x5-8 of what was reported on Thursday, September 10, after the HEPA filters were turned on. We don't have logging of this information in any automated way so it's hard to correlate things with the conditions in Pasadena. We also don't have a working gauge of the pressure of the vacuum envelope.

The RGA scanning was NOT enabled for whatever reason after the vacuum work. I re-enabled it, and opened VM1 to expose the RGA to the main volume. The unit may still be warming up but this initial scan doesn't look completely crazy compared to the reference trace which is supposedly from a normal time based on my elog scanning (the timestamp is inherited from the c0rga machine whose clock is a bit off).


Update 1500: I checked the particle count on the PSL table and it barely registers on the unit (between 0-20 between multiple trials) so I don't know if we need a better particle coutner or if there is negligible danger of damage to optics due to particulate matter.

Attachment 1: RGAscan.pdf
RGAscan.pdf
  15592   Mon Sep 21 16:40:52 2020 gautamUpdatePSLHEPAs are no longer running

The HEPA filters on the PSL enclosure are no longer running. I tried cycling the power switch on the NW corner of the enclosure, and also turned the dial on the Variac down to zero and back up to maximum, no effect. Judging by the indicator LED on it, the power is making it to the Variac - bypassing the Variac and directly connecting the HEPA to the AC power seems to have no effect either.

I can't be sure, but I'm almost certain I heard them running at max speed an hour ago while I was walking around inside the VEA. Probably any damage that can happen has already been done, but I dialled down the Innolight injection current, and closed its shutter till the issue can be resolved.

  15662   Fri Nov 6 14:08:44 2020 gautamUpdatePSLPMC re-locked

The PMC servo railed and so I re-locked it at ~half range. I've been noticing that the diurnal drift of the PZT control voltage has been larger than usual - not sure if it's entirely correlated with temperature on the PSL table. Anyway the cavity is locked again so all is good.

  16016   Mon Apr 12 08:32:54 2021 Anchal, PacoSummaryPSLPMC unlocked at 2pm on Sunday; ~ Restored

PMC lost lock between 21:00 and 22:00 UTC on April 11th as seen in the summary pages:

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20210411/psl/#gallery-4

That's between 2pm and 3pm on Sunday for us. We're not sure what caused it. We will attempt to lock it back.


Mon Apr 12 08:45:53 2021: we used milind's python script in scripts/PSL/PMC/pmc_autolocker.py. It locked the PMC in about a minute and then IMC catched lock succefully.

However, the PMC transmission PD shows voltage level of about 0.7V. On medm, it is set to turn red below 0.7 and yellow above. In Summary pages in the past, it seems like this value has typically been around 0.74V. Simil;arly, the reflection RFPD DC voltage is around 0.063 V right now while it is supposed to be around 0.04 nominally So the lock is not so healthy.

We tried running this script and the bashscript version too (scripts/PSL/PMC/PMCAutolocker) a couple of times but it was unable to acquire lock.

Then we manually tried to acquire lock by varying the C1:PSL-PMC_RAMP (with gain set to -10 dB) and resetting PZT position by toggling Blank. After a few attempts, we were able to find the lock with transmission PD value around 0.73V and reflection RFPD value around 0.043. PZT control voltage was 30V and shown in red in medm to begin with. So we adjusted the output ramp again to let it come to above 50V (or maybe it just drifted to that value by itself as we could se some slow drift too). At Mon Apr 12 09:50:12 2021 , the PZT voltage was around 58V and shown in green.

We assume this is a good enough point for PMC lock and move on.

  16019   Mon Apr 12 18:34:26 2021 YehonathanSummaryPSLPMC unlocked at 2pm on Sunday; ~ Restored

PMC lost lock again at around 16:00 April 12. I was able to lock it again but the transmission is only 0.6 now and REFL is 0.14.

Rana came in and realigned the PMC stirring mirrors. Now the transmission is 0.757V, and the REFL is 0.03V.

I noticed that the PZT was around 250V. Given that the PMC got unlocked at 16:00, which is around the peak temperature time in the lab (lagging behind the outside weather), due to the PZT voltage going down to 0V, I figured that the PZT voltage would go up during the night when the lab gets cold and therefore will likely go out of range again.

I found a different working point at 150V and relocked the PMC.

 

  16023   Tue Apr 13 19:24:45 2021 gautamUpdatePSLHigh power operations

We (rana, yehonathan and i) briefly talked about having high power going into the IFO. I worked on some calcs a couple of years ago, that are summarized here. There is some discussion in the linked page about how much power we even need. In summary, if we can have

  • T_PMC ~85% which is what I measured it to be back in 2019
  • T_IMC * T_inputFaraday ~60% which is what I estimate it to be now
  • 98% mode matching into the IMC
  • power recycling gain of 40-45 once we improve the folding mirror situation in the recycling cavities
  • and a gain of 270-280 in the arm cavities (20-30ppm round trip loss)

then we can have an overall gain of ~2400 from laser to each arm cavity (since the BS divides the power equally between the two arms). The easiest place to get some improvement is to improve T_IMC * T_inputFaraday. If we can get that up to ~90%, then we can have an overall gain of ~4000, which is I think the limit of what is possible with what we have.

We also talked about the EOM. At the same time, I had also looked into the damage threshold as well as clipping losses associated with the finite aperture of our EOM, which is a NewFocus 4064 (KTP is the Pockel medium). The results are summarized in Attachments #1 and #2 respectively. Rana thinks the EOM can handle factor of ~3 greater power than the rated damage threshold of 20W/mm^2.

Attachment 1: intensityDist.pdf
intensityDist.pdf
Attachment 2: clippingLoss.pdf
clippingLoss.pdf
ELOG V3.1.3-