It seems clever, but I wonder why use DTT and command line perl, instead of using the FE lockins or just demod the offline data or all of the other sensing matrix scripts made for the LSC (at 40m) or ASC (at LLO) ?

There are several non scientific reasons.

Lock ARMs

• Try IFO Configure ! Restore Y Arm (POY) and saw XARM lock, not YARM. Looks like YARM biases on ITMY and ETMY are not optimal, so we slide C1:SUS-ETMY_OFF from 3.0 --> -14.0 and watch Y catch its lock.
• Run ASS scripts for both arms and get TRY/TRX ~ 0.95
  • We ran X, then Y and noted that TRX dropped to ~0.8 so we ran it again and it was well after that. From now on, we will do Y, then X.

WFS1 noise injection

• Turn WFS limits off by running switchOffWFSlims.sh
• Inject broadband noise (80-90 Hz band) of varying amplitudes from 100 - 100000 counts on C1:IOO-WFS1_PIT_EXC
• After this we try to track its propagation through various channels, starting with
  • C1:LSC-XARM_IN1_DQ / C1:LSC-YARM_IN1_DQ
  • C1:SUS-ETMX_LSC_OUT_DQ / C1:SUS-ETMY_LSC_OUT_DQ
  • C1:IOO-MC_F_DQ
  • C1:SUS-MC1_**COIL_OUT / C1:SUS-MC2_**COIL_OUT / C1:SUS-MC3_**COIL_OUT
  • C1:IOO-WFS1_PIT_ERR / C1:IOO-WFS1_YAW_ERR
  • C1:IOO-WFS1_PIT_IN2

** denotes [UL, UR, LL, LR]; the output coils.

• Attachment 1 shows the power spectra with IMC unlocked
• Attachment 2 shows the power spectra with the ARMs (and IMC) locked

Rana came and helped us figure us where to inject the noise. Following are the characteristics of the test we did:

• Inject normal noise at C1:IOO-MC1_PIT_EXC using AWGGUI.
• Excitation amplitude of 54321 in band 12-37Hz with Cheby1 8th order bandpass filter with same limits.
• Look at power spectrum of C1:IOO-MC_F_DQ, C1:IOO-WFS1-PIT_OUT_DQ and the C1:IOO-MC1_PIT_EXC itself.
• Increased the gain of the noise excitation until we see some effect in MC_F.
• Diaggui also showed coherence plot in the bottom, which let's us have an estimate of how much we need to go further.

Attachment 1 shows a screenshot with awggui and diaggui screens displaying the signal in both angular and longitudinal channels.

Attachment 2 shows the analogous screenshot for MC2.

We redid the WFS noise injection test and have compiled some results on noise contribution in arm cavity noise and IMC frequency noise due to angular noise of IMC.

Attachment 1: Shows the calibrated noise contribution from MC1 ASCPIT OUT to ARM cavity length noise and IMC frequency noise.

• For calibrating the cavity length noise signals, we sent 100 cts 100Hz sine excitation to ITMX/Y_LSC_EXC, used actuator calibration for them as 2.44 nm/cts from 13984, and measured the peak at 100 hz in time series data. We got calibration factors: ETMX-LSC_OUT: 60.93 pm/cts , and ETMY-LSC_OUT: 205.0 pm/cts.
• For converting IMC frequency noise to length noise, we used conversion factor given by where L is 37.79m and lambda is wavelength of light.
• For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise (see attachment 3 for awggui config) from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. See Attachment 2 for the diaggui plots.
• Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
• However, something must be wrong because the MC_F noise in length units is coming to be higher than cavity length noise in most of the frequency band.
  • It can be due to the fact that control signal power spectrum is not exactly cavity length noise at all frequencies.  That should be only above the UGF of the control loop (we plan to measure that in afternoon).
  • Our calibration for ETMX/Y_LSC_OUT might be wrong.

We today measured the calibration factors for XARM_OUT and YARM_OUT in nm/cts and replotted our results from 16117 with the correct frequency dependence.

Calibration of XARM_OUT and YARM_OUT

• We took transfer function measurement between ITMX/Y_LSC_OUT and X/YARM_OUT. See attachment 1 and 2
• For ITMX/Y_LSC_OUT we took calibration factor of 3*2.44/f² nm/cts from 13984. Note that we used the factor of 3 here as Gautum has explicitly written that the calibration cts are DAC cts at COIL outputs and there is a digital gain of 3 applied at all coil output gains in ITMX and ITMY that we confirmed.
• This gave us callibration factors of XARM_OUT: 1.724/f² nm/cts , and YARM_OUT: 4.901/f² nm/cts. Note the frrequency dependence here.
• We used the region from 70-80 Hz for calculating the calibration factor as it showed the most coherence in measurement.

Inferring noise contributions to arm cavities:

• For converting IMC frequency noise to length noise, we used conversion factor given by where L is 37.79m and lambda is wavelength of light.
• For converting MC1 ASCPIT OUT cts data to frequency noise contributed to IMC, we sent 100,000 amplitude bandlimited noise  from 25 Hz to 30 Hz at C1:IOO-MC1_PIT_EXC. This noise was seen at both MC_F and ETMX/Y_LSC_OUT channels. We used the noise level at 29 Hz to get a calibration for MC1_ASCPIT_OUT to IMC Frequency in Hz/cts. This measurement was done in 16117.
• Once we got the calibration above, we measured MC1_ASCPIT_OUT power spectrum without any excitaiton and multiplied it with the calibration factor.
• Attachment 3 is our main result.
  • Page 1 shows the calculation of Angle to Length coupling by reading off noise injects in MC1_ASCPIT_OUT in MC_F. This came out to 10.906/f² kHz/cts.
  • Page 2-3 show the injected noise in X arm cavity length units. Page 3 is the zoomed version to show the matching of the 2 different routes of calibration.
  • BUT, we needed to remove that factor of 3 we incorporated earlier to make them match.
  • Page 4 shows the noise contribution of IMC angular noise in XARM cavity.
  • Page 5-6 is similar to 2-3 but for YARM. The red note above applied here too! So the factor of 3 needed to be removed in both places.
  • Page 7 shows the noise contribution of IMC angular noise in XARM cavity.

Conclusions:

• IMC Angular noise contribution to arm cavities is atleast 3 orders of magnitude lower then total armc cavity noise measured.

Edit Mon May 10 18:31:52 2021

See corrections in 16129.

A few corrections to last analysis:

• The first plot was not IMC frequency noise but actually MC_F noise budget.
  • MC_F is frequency noise in the IMC FSS loop just before the error point where IMC length and laser frequency is compared.
  • So, MC_F (in high loop gain frequency region upto 10kHz) is simply the quadrature noise sum of free running laser noise and IMC length noise.
  • Between 1Hz to 100 Hz, normally MC_F is dominated by free running laser noise but when we injected enough angular noise in WFS loops, due to Angle to length coupling, it made IMC length noise large enough in 25-30 Hz band that we started seeing a bump in MC_F.
  • So this bump in MC_F is mostly the noise due to Angle to length coupling and hence can be used to calculate how much Angular noise normally goes into length noise.
• In the remaining plots, MC_F was plotted with conversion into arm length units but this was wrong. MC_F gets suppressed by IMC FSS open loop gain before reaching to arm cavities and hence is hardly present there.
• The IMC length noise however is not suppresed until after the error point in the loop. So the length noise (in units of Hz calculated in the first step above) travels through the arm cavity loop.
• We already measured the transfer function from ITMX length actuation to XARM OUT, so we know how this length noise shows up at XARM OUT.
• So in the remaining plots, we plot contribution of IMC angular noise in the arm cavities. Note that the factor of 3 business still needed to be done to match the appearance of noise in XARM_OUT and YARM_OUT signal from the IMC angular noise injection.
• I'll post a clean loop diagram soon to make this loopology clearer.

• looking at some IMC WFS swept sines, it seems like there is poor margin around 1 Hz
• increasing the overall gain (input) by 2x makes the whole system shake a lot at ~1Hz
• increasing the input gain from 1 to 4 makes the lock break due to oscillations
• I have turned the input slider to 0.5 just now, but it will revert to 1 after the next lock loss for tonights testing
• we can use the observations from now for an hour or so to see if 0.5 is better for the 1 Hz behavior (lets look at the summary pages)

In the middle of aportioning gains and signs in the IMC WFS screen, so beware. More updates soon.

On Wednesday, I did some rework of the MC WFS gains. I think it should still work as before as long as the overall input gain is set to 0.1 (not 1.0 as the button on the screen sets it to).

1. The MC_TRANS P/TY signals were very small because they are normalized by the SUM. I added a '+80 dB' gain filter to the MC2_TRANS_PIT and MC2_TRANS_YAW filter banks which increase the signal gain before the digital signals are sent from the MC2 model to the MC_WFS control screen's Input Matrix. Now if you plot the MC_TRANS and WFS signals on dataviewer, the time series all have roughly the same magnitude.
2. I put a "-80 dB" gain button into the MC2_TRANS servo filter banks. This should make it have the same overall gain as before, since the (sensor to servo) Input Matrix is diagonal.
3. The servo gains (WFS1_PIT, WFS2_YAW, etc.) had some negative signs. To make all the servo gains positive, I moved those signs into the Output Matrix.
4. The Output Matrix had some values with 4-5 significant digits. I think its not necessary to have more than 2 places after the decimal point since out measurements are not that accurate, so I rounded them off. We can/should change that screen to reduce the PREC field on the matrix element display.
5. Now, if the overall INPUT_GAIN slider is increased beyond 0.1, there is some pitch oscillation. I think that is happening because the Output Matrix is not that great. In principle, if we have diagonalized the system, putting offsets into the various loops' error points won't make offsets in the other loops, but this is not the case. The pitch loops have a lot of cross coupling (my guess is that the off-diagonal elements are of order 0.1); the yaw loops are several times better. I suggest someone redo the Output Matrix diagonalization and then use the error point offset method to check that they are diagonal.

We mainly want these loops to work well at DC, so it is perhaps better if we can measure the matrix at DC. Its less automatic than at 13 Hz, but I think it could be done with a script and some iterative matrix inversion:

1. IMC locked, IMC ASC loops all open (by setting the overall input gain slider to zero)
2. apply an offset in the WFS1_P basis (turn off the integrators in all the servo loops, and apply a ~400 count offset in the error point)
3. tweak the WFS1_P output matrix until the WFS2_P and MC2_TRANS_P signals go to zero.
4. repeat for all 6 loops.

I haven't tried this procedure before, but I think it should work. You can use something like "cdsutils servo" to slowly adjust the Output Matrix values.

I tried following the steps and the method I was using converged to same output matrix upto 2 decimal points but there is still left over cross coupling as you can see in Attachment 1. With the new output matrix, WFS loop can be turned on with full overall gain of 1.

Changes:

• I switched off +20dB FM2 on C1IOO-WFS1_PIT and increased gain C1:IOO-WFS1_PIT_GAIN from 0.1 to 1 to be uniform with other filters.
• Output matrix change:
  • Old matrix:

    -2.   4.8 -7.3
     3.6  3.5 -2. 
     2.   1.  -6.8

  • New Matrix:

    3.44  4.22 -7.29
    0.75  0.92 -1.59
    3.41  4.16 -7.21

• I think the main change that allowed the WFS loop to become stable was the 0,0 element sign change.

Method:

• I made overall gain C1:IOO-WFS_GAIN 0
• Switched of (0:0.8) FM3 on PIT filter modules (IOO-WFS1_PIT, IOO-WFS2_PIT, IOO-MC2_TRANS_PIT)
• Changed ramp time to 2 seconds on all these modules
• Used offset of 10000 for WFS2 and MC2_TRANS, and 30000 for WFS1 (for some reason, response to WFS1 step was much lower than others)
• Measured the following sensor channels
  • C1:IOO-WFS1_I_PIT_OUT
  • C1:IOO-WFS2_I_PIT_OUT
  • C1:IOO-MC_TRANS_PIT_OUT
• First I took 30s average of these channels, then applied the offsets in the three modules one by one and recorded steps in each sensor.
• Measured step from reference value taken before, and normalized each step to the DOF that was actually stepped to get a matrix.
• Inverted this matrix and multiplied with existing output matrix. Made sure column norm1 is same as before and column signs are same as before.
• Repeated a few times.

Note: The standard deviation on the averages was very high even after averaging for 30s. This data should be averaged after low passing high frequencies but I couldn't find the filter module medm screens for these signals, so I just proceeded with simple averaging of full rate signal using cdsultis avg command.

Fri Nov 25 12:46:31 2022

The WFS loop are unstable again. This could be due to the matrix balancing done while vacuum was disrupted. The above matrix does not work anymore.

IMC WFS tuning

- IMC was aligned manually to have maximum output and also spot at the center of the end QPD.
- The IMC WFS spots were aligned to be the center of the WFS QPDs.
- With the good alignment, WFS RF offset and MC2 QPD offsets were tuned via the scripts.

Last night the sensing matrix for IMC WFS&QPD were measured.

C1:IOO-MC(1, 2, 3)_(ASCPIT, ASCYAW)_EXC were excited at 5.01Hz with 100 count
The output of the WFS1/WFS2/QPD were measured. They all looked well responding
i.e. Pitch motion shows pitch error signals, Yaw motion shows yaw error signals.

The below is the transfer function from each suspension to the error signals

MC1P      MC2P     MC3P
-3.16e-4  1.14e-2  4.62e-3 -> WFS1P
 5.43e-3  8.22e-3 -2.79e-3 -> WFS2P
-4.03e-5 -3.98e-5 -3.94e-5 -> QPDP

MC1Y      MC2Y     MC3Y
-6.17e-4  6.03e-4  1.45e-4 -> WFS1Y
-2.43e-4  4.57e-3 -2.16e-3 -> WFS2Y
 7.08e-7  2.40e-6  1.32e-6 -> QPDY

Taking the inverse of these matrices, the scale was adjusted so that the dc response.



 I took some spectra of the error signals and MC2 Trans RIN with the loops off (blue) and on (red) during the current conditions of daytime seismic noise.

Today I started looking into the WFS problem and improvement, after being briefed by Koji and Nicholas. I started taking some measurements of open loop transfer functions for both PIT and YAW for WFS1, WFS2 and MC2_TRANS. For both WFS1 and 2 there is a peak in close proximity of the region with gain>1, and the phase margin is not very high. Tomorrow I will make measurements of the local damping open loop transfer functions, then we'll think how to improve the sensors' behaviour.

[Diego,Koji]

Today we took some measurements of transfer functions and power spectra of suspensions of the MC* mirrors (open loop), for all the DOFs (PIT, POS, SIDE, YAW); the purpose is to evaluate the Q factor of the resonances and then improve the local damping system.

To check out the bandwidths and cross-coupling in the WFS loops, I made a script (attached) to step the offsets around, sleeping between steps. Its also in the scripts/MC/WFS/ dir.

You can see from the steps that there is some serious cross coupling from WFS1-PIT to MC_TRANS PIT. This cross-coupling is not a disaster because we run the MC2 centering loop with such a low gain. This gain hirearchy means that you can effectively consider the IMC with the WFS loops closed to be an "open loop" plant that the MC TRANS loop is trying to control.

I've started another run at 4:40 UTC since my previous one only paused for 30 seconds after turning each offset OFF/ON. This is clearly not long enough to grab the MC_TRANS loop; although you can tell sort of how slow it is from the slope of the error signal after the step is applied.

To make the plot, I used diaggui in the time series mode, with a 3 Hz BW. I applied a 4th order Butterworth filter at 0.3 Hz to low pass the data using the foton string in the time series tool.

Also reply to: 40m/17255

I ran the toggleWFSoffsets.py script to generate a step response of the WFS loops in operation. Attachment 1 shows the diaggui measured time response following the parameters mentioned in 40m/17255. There are few things to quickly note from this measurement without doing detailed analysis:

• WFS2_PIT is heavily cross-coupled with WFS1_PIT and MC2_TRANS_PIT. This was also the inference from the previous post based on loop shape for WFS2_PIT loop. This needs to be fixed.
• Weirdly enough, it seems that WFS2_PIT is also cross coupled with MC2_TRANS_YAW.
• MC2_TRANS_PIT is not coupled to WFS1_PIT or WFS2_PIT. This was the major issue in last measurement in 40m/17255.
• WFS1_PIT is coupled to MC2_TRANS_PIT by about half, but is not cross-coupled to WFS2_PIT.
• For YAW, the DOFs are mostly disentangled except for a cross coupling of WFS1_YAW to MC2_TRANS_YAW by about 60%.

To get out the UGF of the loops from the step responses, I need to read this into python and apply the same filters and analyze time constants. I still have to do this part, but I thought I'll put out the result before spending more time on this.

GPSTIME: 1354314478

With all of the shaking (man-made and divine), it was a hard to debug this problem. Summary of fixes:

1. The beam was misaligned on the WFS 1 and 2 heads, as well as the MC2 trans QPD. I re-aligned the former with the IMC unlocked, the latter (see Attachment) with the IMC locked (but the MC2 spot centering loops disabled).
2. I reset the WFS DC and RF offsets, as well as the QPD offsets (once I had hand-aligned the IMC mirrors to obtain good transmission).

At least the DC indicators are telling me that the IMC locking is back to a somewhat stable state. I have not yet checked the frequency noise / RIN.

I resume my IMC ringdown activities now that the IMC is aligned again.

To avoid any accidental misalignments Gautam turned off all the inputs to the WFS servo.

I set up a PD and a lens as in attachment 1 (following Gautam's setup).

I connect the REFL, TRANS and INPut PDs to the oscilloscope.

I connect a Siglent function generator to the AOM driver. I try to shut off the light to the IMC using 1V DC waveform and pressing the output button manually. However, it produced heavily distorted step function in the PMC trans PD.

I use a square wave with a frequency of 20mHz instead with an amplitude of 0.5V offset of 0.25V and dutycycle of 1% so there will be minimal wasted time in the off state. I get nice ringdowns (attachment 2) - forgot to take pictures. The autolocker slightly misaligns the M2 every time it is acting, so I manually align it everytime the IMC gets unlocked.

Data analysis will come later.

I remove the PD and lens and reenable the WFS servo inputs. The IMC locks easily. The WFS outputs are very different than 0 now though.

changed some y-scale limits on the WFS summary pages to zoom in better

- Updated the circuit diagrams:

IMC WFS Demodulator Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600503

IMC WFS Whitening Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600504

- Measured the noise levels of the whitening board, demodboard, and nominal free running WFS signals.

- IMC WFS demod phases for 8ch adjusted

Injected an IMC PDH error point offset (@1kHz, 10mV, 10dB gain) and adjusted the phase to have no signal in the Q phase signals.

- The WFS2 PITCH/YAW matrix was fixed

It was found that the WFS heads were rotated by 45 deg (->OK) in CW and CCW for WFS1 and 2, respectively (oh!), while the input matrices were identical! This made the pitch and yaw swapped for WFS2. (See attachment)

- Measured the TFs MC1/2/3 P/Y actuation to the error signals

Noise analysis of the WFS error signals.

Attachment 1: All error signals compared with the noise contribution measured with the RF inputs or the whitening inputs terminated.

Attachment 2: Same plot for all the 16 channels. The first plot (WFS1 I1) shows the comparison of the current noise contributions and the original noise level measured with the RF terminated with the gain adjusted along with the circuit modification for the fair comparison. This plot is telling us that the electronics noise was really close to the error signal.

I wonder if we have the calibration of the IMC suspensions somewhere so that I can convert these plots in to rad/sqrtHz...?

WFS1 / WFS2 demod phases and WFS signal matrix

Signal transfer function measurements

C1:SUS-MC*_ASCPIT_EXC channels were excited for swept sine measurements.

The TFs to WFS1-I1~4, Q1~4, WFS1/2_PIT/YAW, MC2TRANS_PIT/YAW signals were recorded.

The MC1 and MC3 actuation seems to have ~30Hz elliptic LPF somewhere in the electronics chain.
This effect was compensated by subtracting the approximated time delay of 0.022sec.

The TFs were devided by freq^2 to make the response flat and averaged between 7Hz to 15Hz.
The results have been summarized in Attachment 3&4.

Attachment 4 has the signal sensing matrix. Note that this matrix was measured with the input gain of 0.1.

Input matrix for diagonalizing the actuation/sensor response

Pitch

e.g. To produce pure WFS1P reaction, => -1.59 MC1P + 0.962 MC2P + 0.425 MC3P

Yaw

Now, the output matrices in the previous entry were implemented.
The WFS servo loops have been engaged for several hours.
So far the REFL and TRANS look straight. Let's see how it goes.

It didn't go crazy at least for the past 24hours.

• For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.
• It seems from the noise plots that the demod board is now dominating over the whitening board noise.
• If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.
• We should look at the out-of-lock light power on the WFS and re-examine what the 'safe' level is. We used to do this based on the dissipated electrical power (bias voltage x photocurrent).

At Hanford, there is this issue with laser jitter turning into an IMC error point noise injection. I wonder if we can try out taking the acoustic band WFS signal and adding it to the MC error point as a digital FF. We could then look at the single arm error signal to see if this makes any improvement. There might be too much digital delay in the WFS signals if the clock rate in the model is too low.

Koji responding to Rana

> For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.

I can believe the calibration for the individual OSEMs. But the input matrix looked pretty random, and I was not sure how it was normalized.
If we accept errors by a factor of 2~3, I can just naively believe the calibration factors.

> If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.

The demod chip has the conversion factor of about the unity. We increased the gains of the AF stages in the demod and whitening boards. However, we only have the RMS of 1~20 counts. This means that we have really small RF signals. We should check what's happening at the RF outputs of the WFS units. Do we have any attenuators in the RF chain? Can we skip them without making the WFS units unstable?

The WFS gains are supposedly maximized already. If we remotely try to increase the gain, the two MAX4106 chips in the RF path will oscillate with each other.

We should insert a bi-directional coupler (if we can find some LEMO to SMA converters) and find out how much actual RF is getting into the demod board.

The whitening board saids it is Rev B, but the actual component values are more like Rev. C.

The input stage (AD602) has an input resistor of 909 Ohm.
This is causing a big attenuation of the signal (x1/10) because the input impedance of AD602 is not high. And this screws up the logarithm of the gain.
I don't think this is a right approach.

The input resistor 909Ohm of AD602 was shorted. I've confirmed that the gain (= attenuation by voltage division) was increased by a factor of 10.
This modification was done for WFS2-I1 and WFS2-Q1. Also the thick film resistors for the WFS2-I1 channel was all replaced with thin film resistors.

Attachment 1 shows the comparison of the noise levels. The curves were all calibrated referred to the response of the original whitening filter configuration.
(i.e. measurement done after the gain change was compensated by the factor of 10.)

Now the AF chain is not limited by the noise in the whitening filter board. (Brown)
In fact, this noise level was completely identical between I1 and Q1. Therefore, I don't think we need this resistor replacement for the whitening filter board.

We can observe the improvement of the overall noise level below 10Hz. (Comparison between green and red/blue)
As the signal level goes up, the noise above 100Hz was also improved.

Now we need to take care of the n x 0.7Hz feature which is in the demod board...
 

I have implemented the same modification (shorting the input resistor of AD602) to the two whitening boards.

Rana pointed out that this modification (removal of 900Ohm) leave the input impedance as low as 100Ohm.
As OP284 can drive up to 10mA, the input can span only +/-1V with some nonlinearity.

Rather than reinstalling the 900Ohms, Rana will investigate the old-days fix for the whitening filter that may involve the removal of AD602s.
Until the solution is supplied, the IMC WFS project is suspended.

https://dcc.ligo.org/LIGO-D1400414

As it turns out, its not so old as I thought. Jenne and I reworked these in 2014-2015. The QPD whitening is the same as the IMC WFS whitening so we can just repeat those fixes here for the IMC.

The IMC lock survived overnight and the WFS servo loops kept it aligned. The IMC was unlocked in the morning.
The left 6 plots are the WFS servo outputs and the right most two plot show the transmission and reflection of the IMC.

If the WFS is making the lock unstable under high seismic conditions, please turn the loops off.

[Anchal, Radhika, Jamie, Chris]

We conducted a test of three alternative controllers for the IMC pitch DOFs on Friday. These were loaded into a new RTS model c1sbr, which runs on the c1ioo front end as a user-space program at 256 Hz. It communicates with the c1ioo controller via shared memory IPCs to exchange error and control signals.

The IMC maintained lock during the handoffs, and we were able to take one minute of data for each (circa GPS 1349807926, 1349808426, 1349808751; spectra attached), which we can review to assess the performance vs the baseline. (On the first trial, lock was lost at the end when the script tried to switch back to the baseline controller, because we did not take care to clear the integrators. On subsequent trials we did that part by hand.)

The method of setting up this test was convoluted, but now that we see it working, we can start putting in the merge requests to get the changes better integrated into the system. First, modifications were required to the realtime code generator, to get controllers running at the new sample rate of 256 Hz. (This was done in a separate filesystem image on fb1, /diskless/root.buster256, which is only loaded by c1ioo, so as to isolate the changes from the other front end machines.) The generated code then needed hand-edits to insert additional header files and linker options, so that the alternative controllers could be loaded from .so shared libraries. Also, the kernel parameters had to be set as described here, to allow the user-space controller to have a CPU core all to itself. Finally, isolating the core was done following the recipe in this script (skipping the parts related to docker, since we didn’t use it).

Five more mode cleaner alignment controllers were tested this morning (remotely). These were designed to run in tandem with the standard controller, instead of supplanting it. Before the test, c1ioo was burt restored back to the settings of the previous test on Oct 28, and in MC TRANS PIT/YAW filter banks the 80 dB gain filters were disengaged and outputs were enabled. Subsequently, all settings were returned to the original values. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled. GPS times for each phase of testing are the following:

• musgo
  • OL start 1353602764
  • CL start 1353603074
  • policy start 1353603410
• musgo_ghost
  • OL start 1353604697
  • CL start 1353605007
  • policy start 1353605355
• musgo_stumble
  • OL start 1353606574
  • CL start 1353606884
  • policy start 1353607229
• musgo_goldfish
  • OL start 1353608446
  • CL start 1353608756
  • policy start 1353609099
• musgo_late
  • OL start 1353610321
  • CL start 1353610631
  • policy start 1353610971

Another five mode cleaner alignment controllers were tested last night (remotely), running in tandem with the standard controller. As before, c1ioo was burt restored to Oct 28 and the MC TRANS PIT/YAW 80dB gain filters were disabled before the test. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled.

The first four tests went smoothly, but the last controller (goldfish_short) repeatedly broke the lock. Eventually I got it running with an output gain of 0.5, strong enough to see the misbehavior without unlocking the mode cleaner.

GPS times for each phase of testing were the following:

1. ichabod
   • Open loop 1354165556
   • Closed loop 1354165866
   • Policy 1354166241

1. ichabod_2
   • Open loop 1354167462
   • Closed loop 1354167772
   • Policy 1354168113

1. ichabod_3
   • Open loop 1354169357
   • Closed loop 1354169667
   • Policy 1354170006

1. goldfish_long
   • Open loop 1354171297
   • Closed loop 1354171607
   • Policy 1354172022

1. goldfish_short
   • Open loop 1354173255
   • Closed loop 1354173565
   • Policy 1354173924 (output gain 1.0, immediately unlocked the cavity)
   • Policy 1354175008 (output gain 0.1, 2 min)
   • Policy 1354175189 (output gain 0.3, 2 min)
   • Policy 1354175376 (output gain 0.5, 20 min)

Three additional mode cleaner alignment controllers were tested Sunday night (remotely). They were run in tandem with the (recently improved) standard controller. Each test consisted of five minutes with pitch alignment uncontrolled, five minutes with the standard controller only, and twenty minutes with both controllers enabled.

GPS times for each phase of testing were the following:

1. slug_functional
   • Open loop 1355466269
   • Closed loop 1355466579
   • Policy 1355466987
2. slug_hippocamp
   • Open loop 1355468210
   • Closed loop 1355468520
   • Policy 1355468849
3. slug_hippocamp_slow
   • Open loop 1355470093
   • Closed loop 1355470403
   • Policy 1355470855

I checked the IMC alignment following the vent, for which the manual beam block placed on the PSL table was removed. The alignment is okay, after minor touchup, the MC Trans was ~1200 cts which is roughly what it was pre-vent. I've closed the PSL shutter again.

Today, I did the following tests (and so was touching electronics/cables at/around 1X2):

• Measured the IMC OLTF.
• Measured the TF from injection at IN2 to response at the IMC error point (T-eed the I out of the IMC demodulator as there is no longer a monitor point available).
• Measured the IMC in loop error signal with 0.25 Hz resolution from DC-2kHz.
• Confirmed that the IMC IN2 (a.k.a. AO path) gain slider performs as advertised. This is a useful test to run post Acromag switchover on Friday.

Results to follow.

After this work, I reverted the EPICS channels to the usual values. The IMC can be locked.

In the style of the KA characterization of the CM board, the AO path gain EPICS slider (IN2) of the IMC servo board was stepped by 1 dB through the full available range of -32 dB to +31 dB. For each value of the requested gain, I measured the TF from the injected signal (to IN2) to TP1A on the IMC servo board. I used the BNC connector for this test, whereas we use the LEMO connector for the AO path. The source was tee-d off at the SR785 side, with one leg going to IN2 of the IMC servo board, and the other going to CH1A of the SR785. TP1A of the IMC board was connected to CH2A of the SR785. 

Attachment #1 - Measured gain vs requested gain.

• When debugging the CM board, it was this kind of test that revealed the faulty latch ICs.
• -12 dB to -11 dB gain step looks anomalous, but overall the trend seems linear.
• I was confused by why there should be a discontinuity at this stage of the gain stepping - seems like the scanning script I use changes the SR785 excitation amplitude at this point (from 300mV to 100mV). But why should the size of the excitation signal change the magnitude of the transfer function? Is this indicative of some loading issue?
• There is an overall offset between the requested gain and measured gain of ~2-3 dB. This seems large.
• There is nothing in the schematic which would have me expect this - there is a 1/2 divider at the positive input of the differential receiving stage, but this just cancels out the non-inverting gain of x2.

Attachment #2 - Frequency dependent transfer functions

• There seem to be two families of curves - they correspond to <-12 dB and >-12 dB.
• The feature at 90 kHz is strange - need to look at the schematic to see what this could be.

The motivation here is to try and figure out why I cannot engage the AO path smoothly in the CARM handoff part of lock acquisiton. I plan to use this information to do some loop modeling and project laser frequency noise coupling in various stages of the lock acquisition process.

Came this morning, opened the PSL and there was not even a beam on the MC REFL.

Looking at the big monitor it seems like the WFS signals went through the roof during the "auto-alignment" night session.

I restored the MC alignment from before the misalignment happen and wait for the SUS to damp. Once the RMS values went below 200 I enabled the watchdog and the coil outputs.

I opened the PSL shutter and the IMC locked immediately. I turned on the WFS servo and the MC REFL DC went down to 0.3. I run the WFS relief script.

I briefly managed to lock the IMC today - it stayed locked for ~10 minutes. Attachment #1 shows spectra of a few error and control signals for today's lock, and from a stretch yesterday before the problems surfaced*. The 60 Hz lines are much bigger, and MC_F signals broadband excess noise above a few Hz. I suspect a problem somewhere in the electronics.

*I confess the comparison isn't entirely valid because I had to tweak the FSS FAST gain from its nominal value of 22 to 25 in order to get the PC drive RMS down to the ~1.5V level. At the nominal gain setting, with the laser frequency locked to the cavity length, the PC Drive RMS was ~4 V. Still, indicative of something being off in the electronics.

As per Gautam's request, I looked at the IMC situation.

Locking path

• Acquisition: IMC IN1 Gain +4 (nominal), Boost 0, VCO Gain (-32), FSS Common +6 (nominal), FSS FAST +20
  This is too low gain. So oscillate VCO Gain between -32 and ~0 until TEM00 lock is acquired
• Once lock is acquired, bring the VCO gain to +11 (new nominal), and increase the FSS FAST to +23 (new nominal). Change the IMC BOOST to 3 (nominal)

Diagnosis

• The PMC servo gain was checked. The control signal monitor for the PMC actuation was hooked up to SR785. The nominal gain was +18dB. Increasing the gain to 20dB made the servo oscillating. So the nominal gain of +18dB seems still reasonable.
• The status of NOISE EATER was checked. Both the PMC REFL and TRANS were looked at by AG4395A. The power spectrum of them did not change much around the kHz~MHz region. It made the PSD slightly (x2~3) improved below 1kHz. I also did not recognize the relaxation oscillation peak. So I could not figure out where to see. NOISE EATSER was on and is still on.
• IFO Modulation Freq: I took this chance to look at the IMC absolute length using the peak at 3.6MHz. The TP1A output of the IMC servo board was hooked up to AG4395A.
  The new FSR of the IMC (and thus the modulation frequency for the IFO) is 11.066275MHz (instead of the previous 11.066209MHz).
  This corresponds to 0.16mm difference in the roundtrip length.
• (*Still working) IMC SERVO configuration:
  • FAST 25 (nominal) sometimes invoke the oscilattion. 24 has gain peaking ~30kHz. There is a big line peak at 35kHz so wanted to avoid the servo bump (PZT-EOM cross over). So decided to use 23dB. (This is not optimal for the CM servo as we need as much as bandwidth for CM servo.)
  • IMC VCO GAIN (bad name. this is actually overall output gain for IMC) was increased from the nominal 7 to 11. Increasing this above 11 makes the servo oscillating at ~200kHz.
• (*Still working) Measured power spectrum of the error signal. Too many line peaks.
• (*Still working) Single trigger observation: Oscilloscope monitoring started from 35kHz going up and ~20kHz oscillation +/-6V of the IMC servo output was observed. Could not capture good data for this. Try the other day.

I'll complete the entry later.

Continuing this investigation of the IMC, today I am getting familiar with the PMC and FSS. I'd like to measure the frequency noise of the PSL referenced to the PMC.

I checked that the PSL shutter is off, so no light reaches the IMC.

I'm not really sure what I'm looking for on the FSS boxes. I found a few documents to guide:

• On the tabletop testing of FSS for LIGO
• 40m wiki

I ran the FSS autolock script from C1PSL_FSS, nothing obvious changes when I do so. The FSS error signal (which I think is PSL-FSS_MIXERM) is flatlined, and the RC-RF_PD has no LO (PSL-FSS_LOCALC is nan).

The circuit diagram for the PMC servo card is D980352. From this diagram, I see that I can send an excitation from the network analyzer to FP2TEST (9.09 kOhm input impedance) where it is added to the PMC error signal before going to the loop filters.

I hook up the following

• Agilent 4395A output to SR560 (300 Hz HP, gain of 1)
• SR560 to FP2TEST and to Agilent's channel R
• PMC error signal IF (mixer box mounted to rack, I noticed the IF BNC->SMA were a bit loose/stressed by a hanging LP RF filter) to SR560 (also 300 Hz HP, gain of 2)
• SR560 to Agilent channel A

I 'Enable' Test 2 on the PSL screen, so FP2TEST gets added to the error signal.

PDH signal

• TDS 3034B with four channels
  • 1. PMC servo box external drive (split off from the function generator)
  • 2. PMC servo box output monitor (mirrors the drive, shows when drive is saturating)
  • 3. IF signal (split off after the mixer)
  • 4. PMC Trans (long BNC from the PSL table)
• SRS DS345 function generator (into the PMC servo box' external drive)
  • 100 Hz signal (there's a 10 Hz pole on the PZT drive, so any faster than this and I can't see both sidebands without the HV output mon clipping)
  • 3.19 Vpp amplitude (smallest amplitude at 100 Hz such that both sidebands are well resolved)
  • 1.52 V offset (center the carrier's PDH error signal at pi/2 out of phase with the drive)

I was able to see the carrier and both sidebands.

I tried to grab this data from the scope via ethernet, but was unsuccessful (timeout errors, I'm using the scripts from scripts/tektronix/tek-dump, and the GPIB box that Kruthi had been using for the GigE cam; I also tried plugging in directly scope->ethernet. Never got anything but timeout errors, so maybe I'm not specifying the port correctly. Anyway the trace is frozen on the scope for later use, or I can easily repeat this now that I know how).

Spectrum

Next, I locked the PMC (Test1 is off, tune DC output adjust until I get some transmission, turn on the loop at Test1, increase the gain to before the loop goes unstable). I'm sending the following channels to SR560 (gain = 2, no filtering, high dynamic reserve, 50 Ohm outputs), and reading spectra from the Agilent 4395A:

• R-- PMC TRANS PD
• A-- PDH IF
• B-- PMC PZT HV MON

The HV mon was always saturating the preamp, so I disconnected it; I added a 50 Hz (6db) high pass to the Trans PD signal, since it has a DC component.

I got to take a look at the traces on the spectrum analyzer front panel, but too tired to do the GPIB for now. There are peaks, things look reasonable.

Grabbed the PMC data

I went to set up the spectrum analyzer measurements through GPIB, but inadvertently deleted the contents of ~/Agilent/netgpibdata/ (made a soft link in my folder, decided I wanted it gone but rm'ed instead of unlink). I copied what I think was in that folder back (from /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata).

Again, the spectra are:

• R-- PMC TRANS PD into SR560 with G=2 DC coupled, no filtering
• A-- PDH IF into SR560 with G=2, DC coupled, no filtering
• B-- PMC PZT HV MON into SR560 with G=2, AC coupled, no filtering

I recorded the three spectra with the following parameters:

• Three separate spans:
  • 10 Hz to 150 kHz
  • 100 to 550 kHz
  • 500 kHz to 2.5 MHz
• bwSpanRatio = 0.1 %
• averages: 10
• number of points: 801
• spec type: noise (PSD units)

I then ran AGmeasure with the above parameters in the yaml, with the rest following the defaults in AgilentTemplate.yaml. I saved the data in /users/aaron/40m/data/PMC/190617/

Looks like the header contains all of the parameters, so I shouldn't have trouble distinguishing the spectra. I didn't get the instant plotting working, but the data seem to be there.

I'm still having trouble getting the data from the oscilloscope. I'm not sure why the tektronix scrips I've used before aren't working, I'm checking it now.

update: Grabbed the data, the issue was just using the wrong IP address. 

I made a script (/users/aaron/40m/GPIB/tds_dump.py) that grabs data from a Tektronix scope and packages into a pickled dict with the following structure:

1. ch1
   1. times ("ts")
   2. values ("vals")
   3. channel info ("info")
2. ch2
   1. ""
3. etc

I made a python notebook that does the following:

1. Grab the data from the pickle above
2. Fit a triangle wave to the drive signal
3. Determine the (change in Volts) / second from the triangle wave, as well as define the times of a single sweep of the PDH error signal
4. Trim the error signal data to contain the PDH signal from the carrier and two sidebands only (the original trace was for three periods).
5. Fit the functional form of the PDH signal to the trimmed error signal. 
   1. The sideband frequency is fixed at 35.5 MHz, and the scaling of Volts-to-Hz is left free, so this fit gives the calibration of IF volts to Hz.
6. Grab the spectra (already saved from the Agilent with the netgpib scripts) and apply this V-to-Hz scaling
7. Plot the spectra

The fit in step (5) is still looking quite bad, despite the fitted values being close to the expected. Since we really just want a calibrated spectrum, I'll instead fit a line to the linear portion of the PDH error signal for the carrier and both sidebands, then determine the scaling from that.