[Manasa, Masayuki]

We succeeded in stabilizing both the arms using ALS and get IR to resonate at the sametime.

Measurement

At each step we measured the _PHASE_OUT_Hz calibrated error signals for  Y in this configuration so as to get the in-loop noise of ALS control of YARM

1. we stabilized YARM off IR resonance by using ALS, misaligned ETMX, closed XARM green shutter. That means no IR flashing and no green in XARM.

2. we aligned the ETMX with XARM green shutter closed.

3. we opened the green shutter and locked the green laser with PDH to the XARM.

4. we stabilized the XARM using ALS and off resonance for IR.

5.We brought the XARM to IR resonance with YARM stabilized off IR resonance.

6. we brought the YARM to IR resonance

Beat frequencies when both the arms were stabilized and had IR resonating :
X arm beat frequency = 73.2 MHz; Y arm beat frequency = 26.6 MHz.

Attachment

1.the ALS in-loop noise in X and Y arms with IR off resonance and resonating.

2.the ALS in-loop noise in Y arm in each step from 1 to 6.(will follow soon)

Discussion

The Y arm ALS in-loop noise doesn't seem to be different in any of the configurations in step 1 to 6. This seems to mean that the ALS of the two arms are decoupled.

Actually we are not sure what changed from the last few days (when we were seeing some sort of coupling between the ALS of X and Y arm) except for YARM green PDH servo gain changed (see this entry),

[Manasa, Masayuki]

We locked MICH with 2 arms stabilized by ALS control.

Measurement

We measured the power spectrum of the LSC-MICH_IN1  at each step so as to know the in-loop noise of MICH. And also we measured the OLTF of MICH loop and the error signal with BS excited at 580 Hz and MICH notch filter at same frequency enabled to obtain the MICH calibration factor.

1. We locked  MICH using the AS55Q error signal and fedback to BS actuator. (Red curve)

2. We locked  MICH and locked both the arms using POX11 and POY11 error signals and fedback to ETMs actuators.(Blue curve)

3. We stabilized both the arms using ALS. We use the ALS error signals and fedback to ETMs actuators. And then we locked  MICH.(Magenta curve)

Attachment

The green and brown curve are the ALS in-loop noise, which is the _PHASE_OUT_Hz calibrated error signals. So for these two curves the unit of vertical axis is Hz/rHz. The other curves are the MICH in-loop noises and these are not calibrated. So for these curves the unit of vertical axis is counts/rHz.

Discussion

The UGF of MICH loop is 10 Hz with phase margin of 45 degrees (measured today). The FPMI noise with ALS stabilized arms is much larger than the FPMI with IR PDH locked arms above 30 Hz. That is because the ALS arm stability is not as good as the stability of PDH locked arms. We have to analyze and verify the calibrated numbers for FPMI + ALS with model.

[Steve, Masayuki]

We replaced the laser for optical lever of ETMY. And also we aligned the path so that beam spot hits the center for each optics. I attached the spectrum of the SUS-ETMY_OPLEV_SUM, the red curve is with old laser, and blue curve is with the new laser. We also measured without laser so as to measure the QPD dark noise (green curve). The change is significant, and seems much closer to other oplev spectrum.(Brown curve is the oplev spectrum of ITMY)

The new laser is:

Manufacture name: JDSU, Model number: 1103P, Serial number: PA892324

The injection power is 3.7 mW and the out coming power is 197 uW (measured just before the QPD). The output value of the SUS-ETMY_OPLEV_SUM is about 8500.

First we measure 2 spectrum ( including the dark noise). After that we replace the laser and align the optical lever path. We changed the post of one of the mirror (just before the QPD) because the hight was too low. Inside of the chamber is darker than before - actually we had scattering light inside the chamber before. We dumped the reflected light from QPD. And then we measured the spectrum of the oplev output. I also aligned oplev of ETMY after restoring the YARM configuration using IFO configure screen.

We don't know actually what was the problem, laser quality or the scattering light or some clipping. But the oplev seems to be better.

Steve:  Atm2 shows increased gains correction later for UGF elog 9206

I wrote the down script for ALS. This script is  (script)/ALS/ALSdown.py When this script is running, it watches the feedback signal of the ALS control loop so as to shut down the servo immediately when  the suspension is kicked. 

When  the value of  C1:ALS-X(Y)ARM_OUT  becomes larger than the threshold (right now it is 4500 counts), it changes the servo gain to 0, turns off all filters except for FM5 (the filter for phase compensation), resets the history of the phase tracker of each arm and prints the time on window when the suspension kicked

I put the switch on the C1ALS screen, and if you push this switch the window will open (like when you turn on the c1ass script) and the script start to run. For stopping this script, you have to close that window or press Ctrl + C on that window. This is little bit inconvenient, but we will make autolocker script for ALS and this downscript will be included that script soon. So I think it is enough to protect the suspensions right now.

 I modified the ALS down script. When  the value of  C1:ALS-X(Y)ARM_OUT  becomes larger than the threshold, it turn off the output ON/OFF switch immediately. That is because the ALS servo has ramp time. When script changes the gain to 0, it takes some seconds. That is not good for suspensions.

 After changing servo gain to 0 and turning off the filters, the script waits ramp time and turn on the servo output switch.

[Manasa, Masayuki]

- Motivation

Our goal is to realize PRMI+one arm again. However we found that the noise level of the Y-arm is worse than before (entry).
  Today we went through into the servo gains of the ALS related loops. 

- What we did

Step 1 to 6 is for Yarm
Alignment of the cavity and the green:
1. Locked arms using IR PDH, aligned the green beam to increase the transmission. Now the value of ALS-TRY_OUTPUT is more than 0.8.

Checking and adjustment of the end green PDH gain:
2. Measured the OLTF of green PDH loop.
3. The gain of the PDH box was 8.2. We found that the UGF was too high and the phase mergin was too low (20deg)
    Therefore, the gain was reduced to the gain to 6.8. Now, the UGF and phase margin are 17.7 kHz, 41.96 degree, respectively.

Phase tracker loop:
4. Measured the OLTF of the phase tracker loop. The UGF was 2 kHz, and phase margin was 45 degree.
    We found that these were already the nominal and optimized numbers.
    For a reference: the filter bank C1:ALS-BEATX_FINE_PHASE has the gain of 110.

ALS loop:
5. Disable the IR PDH lock, and stabilized Yarm by ALS. We measured the OLTF of the ALS loop (attachment 1).
    The UGF and phase margin were turned out to be 125 Hz and 41 degree. respectively. This looks pretty optimal.
    The ALS servo gain (the gain of the C1:ALS-YARM module) was 15.0.
6. We measured the in-loop noise of the ALS loop (C1:BEATY_FINE_PHASE_OUT_HZ) (attachment 2).
    The comparison of the in-loop performance is discussed below.

- Discussion

After these adjustment, we found that the ALS in-loop noise of Yarm decreased in high frequency band.
(see this entry for the comparison. Sorry for my laziness! I don't have the overlaid plot)

If we believe this is true, lowering the end PDH gain improved the noise level between 100Hz to 1kHz.
This sounds weird as we decreased the PDH gain, rather than increased. We should confirm this effect by increasing the gain.

Now the in-loop RMS is started to be dominated by the peaks at 3, 16, and 24 Hz.
We should compare the current in-loop spectrum with the previous spectrum when the ALS was working fine.

By the way:
We suffered from frequent disruptions of the ALS servo during our investigation.
As we speculated that this was caused by the malfunction of the green PDH loop, we left the arm still and observed
how the green PDH lock is robust. Our discovery was that the green PDH loop had frequent interruptions (every 5~10min).

From this observation, we strongly feel that we need to look into the entire end PDH loop.

I centered the oplev of the ETMY, because I found that Yarm lost lock every 10 minutes, and the ETMY oplev was misaligned very much. I attached the 40 minutes trend of oplev and LSC-TRY. Yarm looks more stable. After centering of the oplev, the YARM looks to be more stable.

 - Motivation

We found that we need to look into the entire end PDH loop to figure out what causes the worse noise level of the Y-arm than before.(entry)
Today, I measured in-loop noise of the end PDH loop and the ALS loop with different end PDH servo gain of Y-arm to make sure the PDH servo gain change the noise level of the ALS control loop.

- What I did

Measuring the OLTF of the end PDH loop:
1. Measured the OLTF of the PDH loop with the end PDH servo gain 6 and 7.

The UGF and  phase margine: 16 kHz and 53 degree(gain 7) 

                                             7.8 kHz and 86 degree(gain 6)

I couldn't measure the OLTF with higher servo gain than 7 because the loop was not stable enough. I guess that is because of the noise of the SR560, which I used for node of the excitation signal.

Calibration of the end PDH error signal
2. Locked the cavity using IR and turn on the notch filter at 580 Hz of the C1:LSC-XARM. Excited the ETMY using awg with sinusoidal signal at 580 Hz. Set the end PDH servo gain to 6 and measured error signal of the end PDH. The calibration factor of the end PDH error signal H is calculated by

H = abs(G + 1) / A * Verr / Vin

where G is the OLTF of the end PDH, A is the actuator response of the ETMY, Vin is the amplitude of the excitation signal and Verr is the error signal at 580 Hz. This H convert the  error signal to the fluctuation of the cavity length, so it has the unit of V/m. We can change that unit to V/Hz by multiplying f/L, where f is the laser frequency of IR and L is the length of the arm. In this case the H convert the error signal to the fluctuation of the resonant frequency of the cavity.
 The actual number was

H = 1.4e7 [V/m]  (2.0e-6 [V/Hz])

In-loop noise of the end PDH loop
3. Measured the error signal of the PDH loop with the end PDH servo gain of 6.0, 7.0, 8.0 and 9.0. I calibrated these signals with above H, so  these unit is Hz/rHz. I attached the result of these in-loop noise. When the end PDH servo gain is 9.0, the end PDH loop looks unstable. And 8.0 looks to be the optimal gain in terms of the in-loop noise of end PDH loop.

ALS in-loop noise:
4. Stabilized the Y-arm with ALS control loop with different end PDH servo gain, and measured in-loop noise of the ALS control loop. I attached these results and discussed about this results below.

- Discussion

 Now we can say that too high PDH servo gain makes ALS loop very noisy. Compare to when the PDH servo gain is 7 or 8, the ALS in-loop noise is roughly 4 times higher when the PDH servo gain is 9.0, which means the PDH loop is not stable. However between 100 Hz and the end PDH in-loop noise has no big difference between when the servo gain is 6 and 9. If this high frequency noise comes from the end PDH control and this effect is linear, these noises should be same level. Also the PDH servo gain of 7.0 looks optimal gain in terms of the in-loop noise of ALS control loop, although the 8.0 has smallest end PDH in-loop noise. Actually PDH in-loop noise are smaller than ALS in-loop noise.

 I'm wondering what causes the 60 Hz peak in black curve. When the gain become higher, the peak at 60 Hz looks to become larger. The UGF of the ALS loop is above 100Hz, so  it's not because of that. I feel there is some hint for understanding this result in this peak.

From this observation, I could make sure that the end PDH servo gain change the ALS in-loop noise, but that effect doesn't look so simple.

By the way
 We should take care about 60 Hz comb peaks.  You can see huge peaks in PDH in-loop noise and also in ALS in-loop noise.

I wrote the script to scan the cavity using ALS until it finds IR resonance . This script is  (script)/ALS/ALSfindIRresonance.py I attached the time series of the C1:ALS-OFFSETTER and IR transmission of XARM when the script was working.

When you start this script, it start rough scan. It steps the offset of the C1:ALS-OFFSETER with ramp time, and for each step it checks the value of C1:LSC-TR. At rough scan, one step is 0.1 count. When IR transmission become larger than threshold, this script start fine scan. In fine scan, this script steps the offset by 0.01 for the range of 2. For each step, C1:LSC_TR value is measured, and after fine scan it set the offset to the value which had the maximal C1:LSC-TR.

I put new button 'Scan %ARM'  to the ALS screen. You can run this script by pushing that button.

[Manasa, Masayuki]

- Motivation

For PRMI + 2arm, we tried to make the ALS control noise better. As this entry we had huge 60 Hz comb noise in PDH loop of YARM.

So we tried to figure out the problem and fix it.

- What we did

We checked which power supply the staff in Y-end are connected to, and change some of them to connect to 1Y4 AC power supply from wall AC. What we changed was
1.Main end laser
2.He-Ne laser
3.Green REFL PD

We checked error signal of PDH control and compared before and after. The 60 Hz peak get better from -80 dBVpk to -90 dBVpk. Also I attached the plot of XARM, privious YARM (the data of Yesterday night), and current YARM ALS in-loop noises. The RMS of ALS in-loop noise of Y-arm get better by factor of 2. However, even the 60 Hz comb noise get better than before, RMS get worse by comb noise. 

We would like to make these noise better at least until these noises don't affect to RMS, so we should continue to check.

[Manasa, Masayuki]

PSL temperature changed

The beat note of Xarm looked somehow strange before (elog). It should be the highest when the green transmission power is highest, in other words when the end green PDH locks with a TEM00 mode. But it was not like that. When the end PDH locked with other modes (GTRX: below 0.3), the beat note was higher than TEM00 mode (GTRX: around 0.5). 

We guessed that end green laser was somewhere around the point where there were 2 stable TEM00 modes . In order to move away from this unstable region of the end laser, we changed PSL temperature to obtain beat note at a different green laser frequency where we do not have any of the weird modes oscillating.

We changed the PSL temperature from 31.63 degree to 31.33 degree. We measured the in-loop noise of ALS loop and I attached it. There is not big difference in Yarm, but the Xarm in-loop noise become better in high frequency region. We think before the xend green laser was in a not-so-good state and the laser had more frequency noise then. 

ALS stability

After change PSL temperature, Xarm ALS is so stable. Actually Xarm is being locked right now and it is locked for more than 50 minutes!!
Although the Xarm ALS is so stable, Yarm ALS is not stable right now. It lost lock by ~5min. We don't know what is the reason, so we will try to fix it tomorrow.

[Manasa, Masayuki]

Purpose

As this entry, Yarm ALS is not stable enough to lock PRMI + 2 arms. We tried to figure out what is the reason.

What we did

Check connection and alignment

1. Check the Green REFL PD.
Reflection is hitting the center of PD.

2. Check all the BNC connections
All connection are fine.

3. Check which power supply the PDH box is connected to.
PDH box is connected to 1Y4 AC power supply.

Check the control signal and error signal

4. Connected the PZT OUTMON to PC
Before the PZT output was not connected to the monitor channel. We connected that.

5. Saw the time series of the error signal and control signal (PZT output)
 When the Yarm lost end PDH lock, we found that control signal kicked the PZT of end green laser. And also we saw the saturation of control signal. We are not sure where this saturation comes from.

Discussion

With these check, we couldn't find any problem in connection or alignment. But the PDH control signal looks somehow strange. We tried to compare the Yarm signals with that of the Xarm, but we could not conclude anything meaningful.

We don't understand right now but we will continue to check that. We will add more details to the discussion once we have looked into the PDH box signals using oscilloscope.

Summary
In 2arms + MICH configuration, residual motion of the cavity will couple with MICH signal. When cavity length change, the reflectivity of cavity also change. And that cause the phase shift in reflected light. That phase shift is detected in MICH signal. When we try to lock the DRMI + arm, that coupling will be problem for lock acquisition. For practice to estimate that coupling, I estimated the coupling between the cavity motion and the AS55Q signal.

What I did

- Measurement steps
  I did the same measurement as that of this entry. For the estimation below steps are needed. The detail of each step will be written below.
  --Measurement and calibration of the AS55Q error signal with MICH + 2arms locked by ALS control
  --Measurement of the ALS in-loop noise and estimation of residual motion of the cavities.
  --Calibration of the coupling from residual arm motion to AS55Q signal

- Calibration of  the AS55Q signal
1. Sensor gain estimation
  We used the same method as the previous entry,
  We excited the BS at 580 Hz with a given amplitude (Vin). We enabled the notch filter at 580 Hz in the LSC MICH servo. We measured  the peak height (Verr) of the AS55Q error signal. We used the actuator response (A_bs) of BS measured in this entry.
  We can get the sensor gain (H) of AS55Q in unit of count/m

          Verr    1
   H = ------- -------
          Vin   A_bs

By this calculation H = 4.2e+07.

2. Fitting of OLTF for the MICH loop
  We measured the OLTF of the MICH loop. Modelled OLTF is fitted into the measurement data. That modelled OLTF includes the actuator response of BS, the MICH servo filters, DAI,DAA,AI,AA filters, the TF of sample and hold circuit. (About DAI, DAA filters and S/H circuit please read this entry. About AI,AA filters please read this entry)  Also I put time-delay into that OLTF. I estimated that time-delay and the gain of OLTF by fitting.  The time delay was 311usec.

3. Estimation of the MICH free running noise
 With modeled OLTF, I estimated the MICH free running noise.

Estimation of the coupling from residual cavity motion to AS55Q signal
 The ALS in-loop noise data has the unit of Hz/rHz (disturbance of the cavity resonant frequency). By multiplying L_arm/f_laser we can convert the unit to m/rHz (disturbance of the cavity length) .
 I used the same coupling constant between residual motion of cavity and MICH noise as this entry. For estimation of the coupling constant, we excited ETMs  and measured the TF from excitation signal to AS55Q error signal.  I assumed the cavity pole as 4000 Hz. The result is discussed below

Discussion

  ALS in-loop noise include the sensor noise. in high frequency region the in-loop noise is dominated by the sensor noise. So in this region in-loop noise does not mean actual residual motion of the cavity.  And this sensor noise pushes the mirror. So we have to estimate the actual motion of the cavity by multiplying the servo transfer function of the control in this region.

 I made 2 plots. Both include the MICH free running noise and estimated coupling noise from both arms. In one plot, for estimation of the coupling I multiplied only coupling constant to calibrated in-loop noise of the ALS loop. In another plot,  I multiplied coupling constant and OLTF of ALS loop in order to estimate the actual motion of the cavity.  If the 3 curves are coincide in first plot, that means the ALS in-loop noise is same as the residual cavity motion in that region and the MICH free running noise is dominated by coupling from residual cavity motion. If those curves are coincide in second plot, that means the ALS in-loop noise is sensor noise in that region.

 Above 40 Hz, the 3 curves are totally in coincident in first plot. On the other hand in second plot the 3 curves look similar in this region. That may mean above 40 Hz the ALS noise are dominated by sensor noise and MICH free running noise is dominated by the coupling from residual cavity motion.  Also in the region between 10 Hz and 40 Hz, the MICH free running noise seems to be dominated by coupling from cavity motion.

Figure 1

Figure 2

In second plot, the coupling from cavity motion is overestimated. It's possibly because of overestimation of coupling constant, but I'm not sure.
Koji mentioned that we should measure the residual motion of the cavity by using POX and POY. Now the ALS is much more stable than before, so I think we can easily do the measurement again with out of loop measurement. That will be more strait forward measurement.

Control signal measurement of end PDH control

The Yarm ALS wasn't robust. Yesterdays night, we found that suspension kicked by something and that was the reason why the end PDH control lost lock. To make sure that the PDH loop itself is robust, I measured control signals of End PDH loops. When the gain inclease, the peak at UGF appeared and become unstable. Both arms does not seems unstable before the peaks appear.

 Xarm PDH servo gain optimization

I optimized the x end PDH servo gain with measuring OLTF. Now the servo gain is 5.0. UGF is around 10 kHz and phase margin is 40 degree.

Also I measured out of loop noise. I locked the arm using IR PDH, and measure the ALS error signal. The high frequency noise become better.

I calibrated the ALS-OFFSETTER output.
I measured the FSR of cavity in unit of counts. That was 395 counts. Our cavity FSR is 3.8 MHz, so 1 count of the OFFSETTER output is 9.7 kHz.

As Jenne's Elog we want to see Spectrum and time series of REFL 165 (our PRMI LSC locking PD) to see if the signal is saturated while bring the arms into resonance.
I started to connect the spectrum analyser and the 'scope to REFL165 output.

Directional coupler (Mini=-circuits ZMDC-10-2 ZMDC-20-3) was connected just before the dimod boad input. The main output of coupler is plugged into demod board's input.The other output of the coupler is connected to AG4395A using BNC cable.

The spectrum analyser output can be read using netgpibdata in control room. The IP address is 192.168.113.108 and the GPIB address is 17. For this I dissconected the network hub from another AG4395A, which is at the front of 1X2 lack.

I didn't connected the 300 MHz 'scope right now, but tomorrow it will be connected using power splitter and also be able to get data by internet. For connect 'scope to network, I disconected the network hub from SR785.

Summary

When PRMI + 2arms are locked yesterday, we heard the noise from suspension violin mode. For attenuation of that noise, we should design the resonant filter at that frequency and put into the ALS servo. I tried to measure the violin mode of ETMs SUS.

What I did

 1.The arms were locked by IR PDH. I used awggui to excite the suspention. I injected the Normal waveform, 10 Hz of bandwidth wave into C1:SUS-ETMs_ULCOIL_EXC. I put cheby filter in the FIlter of awggui. The order of that filter was 4, that has same bandwidth as that of injection wave and ripple was 4dB. I increase the injection gain with some ramp time(5sec). I swept from 600 Hz to 700 Hz. During that injection I saw the PDH error signal (POX11I and POY11I) in order to find resonance peak of violin mode.
 In ETMX resonances were easily found. That were at 631 Hz and 691 Hz. the 631 Hz peak was seen ALS error signal yesterday. On the other hand, I couldn't find ETMY violin mode. No peaks appeared any frequency.

2. For find the ETMY violin mode, I used dtt swept sine measurement. The excitation channel was C1:SUS-ETMs_ULCOIL_EXC. I measured the TF from excitation channel to POX11I and POY11I error signal. The measurement range was above 400 Hz and below 1000Hz,. The number of point is 600. I attached that result.
In ETMX curve, the coherence become bad near the resonant frequency of violin mode and also the TF is large. Although ETMX violin modes are obvious, ETMY violin modes are not visible. At 660 Hz, 780 Hz, 900 Hz the coherence is not good. That is because 60 Hz comb noise.

Discussion

 I attached the spectrum of the POX and POY error signal. Black and red curve is measured different time. I didn't inject any signal in both measurement, but the violin mode excitation has huge difference. Also there are peaks at beat frequency between violin mode and bounce mode(16 Hz), yaw motion(3 Hz). In ALS in-loop noise or XARM in-loop measurement, sometimes this region had big spikes. That was because of this resonance. And also that resonance peak couples to POY11I.

 I will measure the Q and design the resonant filter for ALS.

 I measured the spectrum of the REFL165 output using AG4395A. As this entry we put the directional coupler between REFL165 output and demod board input, so I measure the signal from the coupler during the PRMI was locked.

 After measure REFL165, I also measured REFL55 output in order to make sure that the signal is not smaller than noise because of coupler. I terminated the couple output of coupler on the REFL165, and take signal from REFL55 output port directly. Both plots seems same except for around the resonant frequency of each PDs. From this plot we cannot say that the coupler reduce signal to spectrum analyser too much.

 After this measurement I reconnected the REFL165 to analyser and reconnected the REFL55 output to demod board.

[Jenne, Masayuki]

We changed the Directional coupler from ZMDC-20-3 to ZMDC-20-5-S+ because that coupler seemed to introduce some high frequency noise.

 I connected the 'scope between REFL165 output and demod board input. I split the signal from coupler using the splitter (Mini-Circuits ZFSC-2-5). One signal is going to 'scope CH1 and the other is going to spectrum analyzer. I connected the 'scope to 40MARS. The IP adress is 192.168.113.25. I connected that by cabling from 1X2.

The command to get the data from spectrum analyzer right now

From command line, put ./netgpibdata -i 192.168.113.108 -d AG4395A -a 17 -f meas01

(EDIT JCD:  You must first be in the correct folder:  /opt/rtcds/caltech/c1/scripts/general/netgpibdata/)

(EDIT JCD again: "meas01" in the command line instruction will be the name of the filename.  Also, the output file meas01.dat has a comment in the first line that must be deleted before you can plot the data.  This sucks, and we should write a script to strip that line, then make nice plots.)

Please take notice that although IP address of AG4395A is same as written in the help of netgpibdata, the GPIB address is not same. It's 17.

How to use  'scope from control room.

Open the browser. Put the IP adress of 'scope (192.168.113.25) into adrress bar of the browser. If it's on the network, below screen will open.

You can control 'scope, get the data, and so on from control room.

Please take notice that Google Chrome cannot connect the 'scope. So you have to use the Firefox or other browser.

[Steve, Masayuki]

We lowered the c1iscey machine to make space upside of the computer for heat flow. 

First we turned off the computer. And then we droped the computer down by 1  notches in the rack. Now the upside and downside spaces are almost same. We restarted the computer after that and we leave the door open.

 [Masayuki, Manasa]

Estimation of free-running MICH displacement noise:

Method 1. Assuming AS55_Q_err to be a linear sensor, as shown in (1) of figure below, free-running MICH noise (V_d) can be estimated by measuring V_err and the OLTF G. H can be estimated by using method explained in elog

 Method 2. Considering that the AS55_Q signal might be distorted or saturated, method 1 may not be precise. In method 2, we will use the ASDC as the sensor (S' in (3)) instead and lock MICH using ASDC in mid-fringe to calibrate the ITM actuators.

Figure:1

Schematic:

What we did:

1. Estimate H' from free-running ASDC signal (bright to dark fringe).
2. With MICH locked on ASDC, give an excitation signal to C1:LSC-SUS_XXXX_EXC (XXXX could be ITMX or ITMY) and measure R'. [(3) of schematic]
3. Measure OLTF of MICH locked on ASDC (hence estimate L). [(3) of schematic]
4. With MICH locked on AS55_Q, give an excitation signal to C1:LSC-SUS_XXXX_EXC (XXXX could be ITMX or ITMY) and measure R1. [(2) of the schematic] 

Results/Plots: 

Figure:2

OLTF of MICH locked on ASDC

Figure2:

Actuator excitation to MICH transfer function (MICH locked using ASDC) 

* y axis (no units)

Figure 3:
Actuator excitation to MICH transfer function (MICH locked using AS55Q)

* y axis (no units)

Figure 4:
Free-running MICH noise

Discussion: 

1. By using the second sensor, we also eliminate the effect of the MICH servo loop locked on AS55_Q (Estimated V_d does not depend on G but only on G').

2. The free-running MICH noise is still suppressed at 1Hz. This should be coming from the effect of the UGF of the loop at ~10Hz and the vicinity to the pendulum frequency at 1Hz.

Edit/Masayuki// This noise curve is not collect, especially in low frequency region. We used the measured OLTF for compensating the free running noise, but that is not collect in low frequency region. So we should model the OLTF and fit that into the measured OLTF. We will fix this soon.

[Manasa, Masayuki]

The MC lost lock around 8+hrs ago. The transmission from PMC was 0.77 this morning, so we aligned the PSL to the PMC using the two steering mirrors before the PMC. We brought the PMC transmission to 0.841. We also aligned the MC, and the MC transmission reflection now is 0.59.

This week I wrote Matlab code, most of which can be found in /users/masha

First, I wrote a simulation seismicFilter.m which filters noisy seismic noise with a desired signal of non-seismic noise. The signals are purely simulated, so I played around with zero-pole-gain generation of transfer functions to obtain them. The function takes the number of taps, the filter type (Wiener or adaptive nlms) as well as an iteration step size and number of iterations, and generates PSD plots of the witness signal, the desired signal, the estimated (filtered) signal, and the error. I'm not sure that I am properly implementing the Wiener part of the code, and I assume the line "[W, R, P] = miso_firlev(TAPS, noisySeismicSignal1, seismicSignal2); " generates W, a filter with TAPS number of weights, but  then "[y, error] = filter(W, 1, noisySeismicSignal1);" generates an error signal of size TAPS rather than N, the size of the original signal. Perhaps I should calculate error using e(t) = d(t + a) - w(t)*x(t), where "a" is the delay.

I have various screenshots in my directory of what seismicFilter.m generates, and I will take a larger screenshot, as well as generate a learning curve (for error vs. number of taps) when I can use Sasha's computer for a bit, since it both has more computing power and a larger screen.

The funciton filterConvergence.m, meanwhile, is similar, except it takes two file names as real data, and uses realDataFilter.m to run the filtering. Currently, I am working with data from C1:IOO-MC_F_DQ-Online  and C1:PEM-SEIS_GUR1_X_IN1_DQ-Online, and I will include screenshots of these once I get on Sasha's computer.

In order to generate the data, meanwhile, I had to modify the python script, and thus wrote mashaImportingData.py for myself. Likewise, plotSignalFromFile.m visualizes this data, both in the time domain and in the frequency domain.

On the side, I wrote an NLMS filter in adaptiveFilterSimulationNLMS.m, and compared is to Matlab's NLMS filter in NLMStest.m (using generated data) and adaptiveFilterSimulation.m using twn input signals. Right now, it's faster on smaller inputs and smaller tap sizes, but then begins to choke and run slower than the Matlab one when these get to big. In order to improve it, I have to develop a better method of generating the initial weights.

As far as machine learning goes, once I find the number of taps for the convergence of both the Wiener filter and the NLMS filter, I will email Denis for further instructions. At some point, however, I should generate learning sets from the seismometers and the MCL (or the DARM), and thus have to find adequate times at which I can take data (probably not from the DARM, however, because it was rarely on).

Thanks for reading!

Hi everybody,

Last night I (with the help of Jenne and Jenne's advice - not to implicate her in this or anything) changed the filters for GUR1, GUR2, and STS in C1:PEM-RMS, adding a butterworth bandpass filter at each corresponding frequency band as well as a gain to convert from counts to micros/sec, and then adding a low pass filter in case of aliasing upon squaring.

Currently the seismic signals are going crazy, and producing "Nan" output on the strip graph (which leads to the instantaneously sharp spikes - which leads to the entire signal being filled on the visualizer on the wall). I checked the DataViewer output and the tdsdata output using both grep and wc, and it seems that both every single signal point is present and is a real number (also not a small real number, thereby debunking floating-point error). I'm currently not sure why seismic-strip reads out 'Nan' - perhaps because it's taking the log of 0, taking a negative log, taking the root of a negative number, or dividing by zero.

Does anyone know if the seismic-strip Nan issue is a program bug? If it's not (and therefore a filter bug), please let me know as well.

I'll be in lab for the rest of the night changing the butterworth filters to odd-order elliptic filters (at Rana's suggestion), as well as changing the cut-off frequency for the low-pass filters.

I'll E-log about it when I'm done.

Just to be sure that my numbers are correct - The STS, GUR1, and GUR2 channels all have gain 10, right? (I parsed through the e-log, and these seem to be the most recent numbers

Thanks for your help,

Masha

UPDATE: I changed all of the GUR1Z channels to order-5 elliptic filters. I approximated the attenuation for each one by setting the integral from _CutoffFrequency to 10^3 Hz of 10^(-Percent(f)/20) df to 0.01, where Percent(f) is a linear approximation of the relationship between the log of the frequency and the dB level (with the attenuation defining one of the points). Right now the Nan problem continues to persist, even after I loaded the coefficients. In Dataviewer, the channels look relatively normal for the past 10 minutes, as does the data when viewed with tdsdata.

 FIGURED IT OUT - THERE WAS A PROBLEM WITH THE LOW PASS FILTERS (TOO HIGH ORDER). FIXING IT NOW, SHOULD BE GOOD IN AN HOUR. 

Hi everybody,

Sorry for flooding the ELOG about the PEM channels. Today I

- Changed all of the GUR1 and GUR2 filters to elliptic, and lowered the orders of their low-pass filters.

- Lowered the order of the low-pass filters on the STS channels

- Changed the parameters in seismic.strip, which I saved as MashaTemplate2.

Attached is the most recent status of the channels as seen with StripTools:

I'm not currently sure how to apply my template to seismic.strip shown on the wall (I saved it as seismic.strip on Pianossa and copied the old file to seismic.stripOld). I understand the job is being run on Megatron. I'll play around with this later tomorrow. (In other words, the display currently on the wall, while it does not have the Nan spikes like yesterday and this morning does not currently display the template I made).

The RMS signals generated by the updated filtering process are now on the wall. The NaN issue is gone it seems, and the template has been changed. Thanks for your help, Jenne. 

Today I REPOSITIONED THE SEISMOMETERS in order to triangulate noise sources (as Rana suggested).

I re-levelled all of them, locked them, and turned them on. They should be located out of sight, but just in case:

GUR 1 IS DOWN THE X-ARM, behind the interferometer.

GUR 2 IS BETWEEN THE TWO ARMS, BEHIND THE CABLE TRAP THAT RUNS PARALLEL TO THE X-ARM.

STS 1 IS DOWN THE Y-ARM behind the interferometer.

I'll wait a day for them to stabilize (continuing to reset STS-1 every hour or so) and then begin taking data tomorrow morning, depending on the condition of the signal.

Ideally, I'd like a few days' worth of data, so I'll update when I've changed the configuration back to the way it was prior.

This week, my work fell into two categories: Artificial Neural Networks and lab-related projects.

Artificial Neural Networks

- I played around with radial basis functions and k-means classification algorithms for a bit in order to develop an algorithm to pick out various features of seismic signals. However, I soon realized that k-means is an extremely slow algorithm in practice, and that radial basis functions are thus difficult to implement since their centers are chosen by the k-means algorithm in practice.

- Thus, I moved on to artificial neural networks. Specifically, I chose to implement a sigmoidal neural network, where the activation function of each neuron is f(u) = 1/ (1 + e-u/T), T constant, which is nice because it's bounded in [0, 1]. Classification, then, is achieved by generating a final output vector from the output layer of the form [c1, c2, c3, ..., cN] where N is the number of classes, ci = 1 (ideally) if the input is of class i, and ck = 0 otherwise.

- First, I built a network with randomly generated weights, ten neurons in the one hidden layer, and two output neurons - to simply classify [1, 0] (earthquake) and [0, 1] (not an earthquake). I ran this on fake input I generated myself, and it quickly converged to error 0. Thus, I decided to built a network for real data.

- My current network is a 2-layer, 10 neuron / 2 neuron sigmoidal network that also classified earthquake / not an earthquake. It trains in roughly 80 - 100 iterations (it's learning curve on training data it attached). It decimates full data from DataViewer by a factor of 256 in order to run faster.

- Next steps: currently, my greatest limitation is data - I can use US Geological Survey statistics to classify each earthquake (so that N = 10, rather than 2, for example), but I would like definite training data on people, cars, trucks, etc. for supervised learning, in order to develop those classes. Currently, however, the seismometers are being used for mine and Yaakov's triangulation project, so this may have to wait a few days.

Lab-Related Projects

- I apologize for all of the E-logs, but I changed the filters in the RMS system (to elliptic and butterworth filters) and changed the seismic.strip display file.

- I repositioned the seismometers so that Yaakov and I can triangulate signals and determine seismic noise hot-spots (as a side-project).

Right now I'm going to try for more classes based on USGS statistics, and I will also explore other data sources Den suggested.

Thanks for your help, everybody in 40m!

I noticed on DataViewer today that GUR2 was outputting only noise (somewhere around 2 counts). Jenne suggested that GUR 2 might not be plugged in. I turned off the ADC, and tried several times to plug GUR 2 back in. I thought something might be wrong with the cable, but when I plugged the GUR1 cable into GUR2, there was still no readout (although the GUR1 cable works fine when I plug it into GUR1). Perhaps I'm just inept at plugging in GUR2, or perhaps there's another issue. Either way, I'll ask Jenne about it tomorrow and try again.

It seems that the STS-1 ADC channels had the same mismatch issue as the GUR-2 channels. The PEM_MONITOR has STS_1 listed as channels 6, 7, 8 (+1 on the actual ADC) whereas it was plugged into channels 13, 14, 15 (+1 on the actual ADC as well) with nothing in channels 6, 7, 8. Thus, I moved the cables and reset STS_1. The readout, however, is still only a magnitude of ~10 counts (I checked, however, that this is indeed the readout when the seismometer is plugged in vs. when it is unplugged), but hopefully it will stabilize during the day, as did GUR 2.

Den and investigated the STS-1 problem (which is currently plugged into ADC channels 13, 14, and 15, which correspond to the STS-3 channels in dtt). It turns out that I had plugged in the power to the monitor in the host box rather than the remote. The X, Y, and Z readout is currently approaching a mean of zero, and I will let it continue to do so overnight (pressing auto-zero as necessary). Attached is a plot of the coherence with GUR 1, and the time-domain signals.

The Streckeisen is currently plugged into ADC channels 13, 14, and 15 (corresponding to STS-3 in the channels). The X, Y, and Z components are correct. The signals is zeroed (it's been so for at least the past 10 hours), the coherence with GUR1 looks decent, and the signal looks similar to the GUR1 signal.

This week, I continued to work with my Artificial Neural Network. Specifically, I implemented a 3-hidden layer sigmoidal, gradient-descent supervised network, with 3 neurons in the final output layer, since I have introduced a new class, trucks. I have overcome my past data limitation, since I observed that there is a multitude of trucks that comes between 9 and 10 am, and thus I have observed a bunch of trucks after the fact (their seismic patterns are rather distinct, and thus there could prove to be a very large supply of this data - I have gathered data on the past 50 days so far, and have gathered 60+ truck patterns).

With 3 classes, the two-layer network converges in ~200 epochs, while the 3-layer network takes around ~1200 (and more time per iteration). Since the error gradients in the stochastic gradient descent are recursively calculated, the only real time limitation in the algorithm is just lots of multiplication of weight / input vectors, lots of computation of sigmoidal functions, and lots of data I/O (actually, since the sigmoidal function is technically an exponentiation to a decimal power and a division, I would be curious to know if theory or Matlab has any clever ways of computing this faster that can be easily implemented - I will look into this today). Thus, the networks take a long time to train. I'm currently looking at optimizing the number of layers / number of neurons, but this will be a background process for at least several days, if not the next week. In the greater scope of things, however, training time isn't really a problem, since the actual running of the algorithm requires only one pass through the network, and the network should be as well-trained as possible. However, due to the fact that I am only here until the end of August, it would be nice to speed things up.

As far as other classifications, I can simulate signals either by dropping the copper block from the Stacis experiment, or by applying transfer functions to general seismic noise. However, I would like more real data on noise sources, but the only other one plausible to LIGO that I can currently think of (cars don't show up very well) is the LA Metro. Perhaps I will take a day to clock trains as they come in (since the schedule is imprecise) and see if there is any visible seismic pattern.

I also, with the help of Yaakov, Jenne, and Den, now have three working, triangulated seismometers, which can now begin taking triangulation data (the rock tumblers are still working, so there should be opportunities to do this), both to find hot-spots as Rana suggested, and to measure the velocity and test out my algorithm, as Den suggested.