40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 74 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  16988   Mon Jul 11 19:29:23 2022 PacoSummaryGeneralFinalizing recovery -- timing issues, cds, MC1

[Yuta, Koji, Paco]

Restarting CDS

We were having some trouble restarting all the models on the FEs. The error was the famous 0x4000 DC error, which has to do with time de-synchronization between fb1 and a given FE. We tried a combination of things haphazardly, such as reloading the gpstime process using

controls@fb1:~ 0$ sudo systemctl stop daqd_*
:~ 0$ sudo modprobe -r gpstime
controls@fb1:~ 0$ sudo modprobe gpstime
controls@fb1:~ 0$ sudo systemctl start daqd_*
controls@fb1:~ 0$ sudo systemctl restart open-mx.service

without much success, even when doing this again after hard rebooting FE + IO chassis combinations around the lab. Koji prompted us to check the local times as reported by the gpstime module, and comparing it to network reported times we saw the expected offset of ~ 3.5 s. On a given FE ("c1***") and fb1 separately, we ran:

controls@c1***:~ 0$ timedatectl
  Local time: Mon 2022-07-11 16:22:39 PDT
  Universal time: Tue 2022-07-11 23:22:39 UTC
       Time zone: America/Los_Angeles (PDT, -0700)
       NTP enabled: yes
       NTP synchronized: no
 RTC in local TZ: no
       DST active: yes
 Last DST change: DST began at
                  Sun 2022-03-13 01:59:59 PST
                  Sun 2022-03-13 03:00:00 PDT
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2022-11-06 01:59:59 PDT
                  Sun 2022-11-06 01:00:00 PST
controls@fb1:~ 0$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
============================================================================== .BCST.          16 u    -   64    0    0.000    0.000   0.000

which meant a couple of things:

  1. fb1 was serving its time (broadcast to local (martian) network)
  2. fb1 was not getting its time from the internet
  3. c1*** was not synchronized even though fb1 was serving the time

By looking at previous elogs with similar issues, we tried two things;

  1. First, from the FEs, run sudo systemctl restart systemd-timesyncd to get the FE in sync; this didn't immediately solve anything.
  2. Then, from fb1, we tried pinging google.com and failed! The fb1 was not connected to the internet!!!

We tried rebooting fb1 to see if it connected, but eventually what solved this was restarting the bind9 service on chiara! Now we could ping google, and saw this output

controls@fb1:~ 0$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
+tor.viarouge.ne   2 u  244 1024  377  144.478    0.761   0.566
*ntp.exact-time. .GPS.            1 u   93 1024  377  174.450   -1.741   0.613
 time.nullrouten .STEP.          16 u    - 1024    0    0.000    0.000   0.000
+ntp.as43588.net      2 u  39m 1024  314  189.152    4.244   0.733 .BCST.          16 u    -   64    0    0.000    0.000   0.000 

meaning fb1 was getting its time served. Going back to the FEs, we still couldn't see the ntp synchronized flag up, but it just took time after a few minutes we saw the FEs in sync! This also meant that we could finally restart all FE models, which we successfully did following the script described in the wiki. Then we had to reload the modbusIOC service in all the slow machines (sometimes this required us to call sudo systemctl daemon-reload) and performed burt restore to a last Friday's snap file collection.

IMC realign and MC1 glitch?

With Koji's help PMC locked, and then Yuta and Paco manually increased the input power to the IFO by rotating the waveplate picomotor to 37.0 deg. After this, we noticed that the MC REFL spot was not hitting the camera, so maybe MC1 was misaligned. Paco checked the AP table and saw the spot horizontally misaligned on the camera, which gave us the initial YAW correction on MC1. After some IMC recovery, we saw only MC1 got spontaneously kicked along both PIT and YAW, making our alignment futile. Though not hard to recover, we wondered why this happened.

We went into the 1X4 rack and pushed MC1 suspension cables in to disregard loose connections, but as we came back into the control room we again saw it being kicked randomly! We even turned damping off for a little while and this random kicking didn't stop. There was no significant seismic motion at the time so it is still unclear of what is happening.

  16991   Tue Jul 12 13:59:12 2022 ranaSummaryComputersprocess monitoring: Monit

I've installed Monit on megatron and nodus just now, and will set it up to monitor some of our common processes. I'm hoping that it can give us a nice web view of what's running where in the Martian network.

  16992   Tue Jul 12 14:56:17 2022 TomislavSummaryElectronicsElectronics noise measurements

[Paco, Tomislav]

We measured the electronics noise of the demodulation board, whitening board, and ADC for WFSs, and OPLEV board and ADC for DC QPD in MC2 transmission. We were using SR785.

Regarding the demodulation board, we did 2 series of measurements. For the first series of measurements, we were blocking WFS (attachment 1) and measuring noise at the output of the demod board (attachment 2a). This measurement includes dark noise of the WFS, electronics noise of demod board, and phase noise from LO. For the second series of the measurements, we were unplugging input to the demod board (attachment 2b & 2c is how they looked like before unplugging) (the mistake we made here is not putting 50-ohm terminator) and again measuring at the output of the demod board. This measurement doesn't include the dark noise of the WFS. We were measuring it for all 8 segments (I1, I2, I3, I4, Q1, Q2, Q3, Q4). The dark noise contribution is negligible with respect to demod board noise. In attachments 3 & 4 please find plots that include detection and demodulation contributions for both WFSs.

For whitening board electronics noise measurement, we were terminating the inputs (attachment 5) and measuring the outputs (attachment 6). Electronics noise of the whitening board is in the attachments 7 & 8.

For ADC electronics noise we terminated ADC input and measured noise using diaggui (attachments 9 & 10). Please find these spectra for WFS1, WFS2, and MC TRANS in attachments 11, 12 & 13.

For MC2 TRANS we measured OPLEV board noise. We did two sets of measurements, as for demod board of WFSs (with and without QPD dark noise) (attachments 14, 15 & 16). In the case of OPLEV board noise without dark noise, we were terminating the OPLEV input. Please find the electronics noise of OPLEV's segment 1 (including dark noise which is again much smaller with respect to the OPLEV's electronics noise) in attachment 17.

For the transfer functions, demod board has flat tf, whitening board tf please find in attachment 18, ADC tf is flat and it is (2**16 - 1)/20 [cts/V], and dewhitening tf please find in attachment 19. Also please find the ASD of the spectral analyzer noise (attachment_20).

Measurements for WFS1 demod and whitening were done on 5th of July between 15h and 18h local time. Measurements for WFS2 demod and whitening were done on 6th of July between 15h and 17h local time. All the rest were done on July 7th between 14h and 19h. In attachment 21 also find the comparison between electronics noise for WFSs and cds error signal (taken on the 28th of June between 17h and 18h). Sorry for bad quality of some pictures.

Attachment 1: attachment_1.jpg
Attachment 2: attachment_2a.jpg
Attachment 3: attachment_2b.jpg
Attachment 4: attachment_2c.jpg
Attachment 5: attachment_3.png
Attachment 6: attachment_4.png
Attachment 7: attachment_5.jpg
Attachment 8: attachment_6.jpg
Attachment 9: attachment_7.png
Attachment 10: attachment_8.png
Attachment 11: attachment_9.jpg
Attachment 12: attachment_10.jpg
Attachment 13: attachment_11.png
Attachment 14: attachment_12.png
Attachment 15: attachment_13.png
Attachment 16: attachment_14.jpg
Attachment 17: attachment_15.jpg
Attachment 18: attachment_16.jpg
Attachment 19: attachment_17.png
Attachment 20: attachment_18.png
Attachment 21: attachment_19.png
Attachment 22: attachment_20.png
Attachment 23: attachment_21.png
  16993   Tue Jul 12 18:35:31 2022 Cici HannaSummaryGeneralFinding Zeros/Poles With Vectfit

Am still working on using vectfit to find my zeros/poles of a transfer function - now have a more specific project in mind, which is to have a Red Pitaya use the zero/pole data of the transfer function to find the UGF, so we can check what the UGF is at any given time and plot it as a function of time to see if it drifts (hopefully it doesn't). Wrestled with vectfit more on matlab, found out I was converting from dB's incorrectly (should be 10^(dB/20)....) Intend to read a bit of a book by Bendat and Piersol to learn a bit more about how I should be weighting my vectfit. May also check out an algorithm called AAA for fitting instead.

  16994   Tue Jul 12 19:46:54 2022 PacoSummaryALSHow (not) to take NPRO PZT transfer function

[Paco, Deeksha, rana]

Quick elog for this evening:

  • Rana disabled MC servo .
  • Slow loop also got disengaged.
  • AUX PSL beatnote is best taken with *free running lasers* since their relative frequency fluctuations are lowest than when locked to cavities.
  • DFD may be better to get PZT transfer funcs, or get higher bandwidth phase meter.
  • Multi instrument to be done with updated moku
  • Deeksha will take care of updated moku
  16997   Wed Jul 13 12:49:25 2022 PacoSummarySUSSUS frozen

[Paco, JC, Yuta]

This morning, while investigating the source of a burning smell, we turned off the c1SUS 1X4 power strip powering the sorensens. After this, we noticed the MC1 refl was not on the camera, and in general other vertex SUS were misaligned even though JC had aligned the IFO in the morning to almost optimum arm cavity flashing. After a c1susaux modbusIOC service restart and burt restore, the problem persisted.

We started to debug the sus rack chain for PRM since the oplev beam was still near its alignment so we could use it as a sensor. The first weird thing we noticed was that no matter how much we "kicked" PRM, we wouldn't see any motion on the oplev. We repeatedly kicked UL coil and looked at the coil driver inputs and outputs, and also verified the eurocard had DC power on which it did. Somehow disconnecting the acromag inputs didn't affect the medm screen values, so that made us suspicious that something was weird with these ADCs.

Because all the slow channels were in a frozen state, we tried restarting c1susaux and the acromag chassis and this fixed the issue.

  16998   Wed Jul 13 13:26:44 2022 ranaSummaryElectronicsElectronics noise measurements

as I said to you yesterday, I don't think image 2a shows the output of the demod board. The output of the demod board is actually the output connector ON the demod board. What you are showing in 2a, is the signal that goes from the whitening board to the ADC I believe. I may be msitaken, so please check with Tega for the signal chain.

  17002   Thu Jul 14 00:10:08 2022 yutaSummaryLSCFPMI with REFL/AS55 trial continued

[Paco, Koji, Yuta]

We managed to lock MICH using REFL55_Q by setting the demodulation phases and offsets right.
The following is the current FPMI locking configuration we achieved so far.

DARM: POX11_I / gain 0.007 / 0.5*ETMX-0.5*ETMY (or 1*ETMX) / UGF of ~100 Hz
CARM: POY11_I / gain 0.018 / 1*MC2 / UGF of ~200 Hz
MICH: REFL55_Q / gain -10 / 0.5*BS / UGF of ~30 Hz

Transitioning DARM error signal from POX11_I to 0.5*POX11_I+0.5*POY11_I was possible with FM4 filter off in DARM filter bank, but not to AS55_Q yet.

REFL55 and AS55 demodulation phase tuning:
 - We found that both AS55 and REFL55 are contaminated by large non-MICH signal, by making a ASDC vs RF plot (see 40m/16929).
 - After both arms are locked with POX and POY, MICH was locked with AS55_Q. ASDC was minimized by putting an offset to MICH filter.
 - With this, REFL55 offsets were zeroed and demodulation phase was tuned to minimize REFL55_Q.
 - Locked MICH with REFL55_Q, and did the same thing for AS55_Q.
 - Resulting ASDC vs RF plots were attached. REFL55_Q now looks great, but REFL55_I and AS55 are noisy (due to signals from the arms?).

Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/MICH/MICHOpticalGainCalibration.ipynb

Sensing matrix:
 - With FPMI locked using POX/POY, DARM and CARM lines were injected at around 300 Hz to measure the sensing gains. For line injection, C1:CAL-SENSMAT was used, but for the demodulation we used a script. The following is the result.

 Sensors              DARM (ETMX)         CARM (MC2)        
C1:LSC-AS55_I_ERR    3.10e+00 (-34.1143 deg)    1.09e+01 (-14.907 deg)    
C1:LSC-AS55_Q_ERR    9.96e-01 (-33.9848 deg)    3.30e+00 (-27.9468 deg)    
C1:LSC-REFL55_I_ERR    6.75e+00 (-33.7723 deg)    2.92e+01 (-34.0958 deg)    
C1:LSC-REFL55_Q_ERR    7.07e-01 (-33.4296 deg)    3.08e+00 (-33.4437 deg)    
C1:LSC-POX11_I_ERR    3.97e+00 (-33.9164 deg)    1.51e+01 (-30.7586 deg)    
C1:LSC-POY11_I_ERR    6.25e-02 (-20.3946 deg)    3.59e+00 (38.4207 deg)

Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/SensingMatrix/MeasureSensMat.ipynb

 - By taking the ratios of POX11_I and AS55_Q for DARM, POY11_I and REFL55_I for CARM, we tried to find the correct gains for REFL55 and AS55 for DARM and CARM. x3.96 more gain for AS55_Q than POX11_I and x0.123 less gain for REFL55_I than POY11_I.

 - Try locking the arms with no triggering, and then try locking FPMI with REFL/AS without triggering. No FM4 for this, since FM4 kills gain margin.
 - Lock single arm with AS55_Q and make a noise budget. Make sure to misalign ITMX(Y) completely when locking Y(X)arm.
 - Lock single arm with REFL55_I and make a noise budget.
 - Repeat Xarm noise budget with Yarm locked with POY11_I and MC2 (40m/16975).
 - Check IMC to reduce frequency noise (40m/17001)

Attachment 1: AS55_I.png
Attachment 2: AS55_Q.png
Attachment 3: REFL55_I.png
Attachment 4: REFL55_Q.png
  17007   Fri Jul 15 19:13:22 2022 PacoSummaryLSCFPMI with REFL/AS55 demod phase adjust

[Yuta, Paco]

  • We first zero the offsets in ASDC, AS55, REFL55, POX11, and POY11 when PSL shutter is closed.
    • After this, we checked the offsets with only ITMX aligned. Some of RFPDs had ~2 counts of offsets, which indicate some RFAM of sidebands, but we decided not to tune Marconi frequencies since the offsets were small enough.
  • We went over the demod phases for AS55, REFL55, POX11, and POY11.
    • For POX11/POY11 first we just minimized the Q in each locked XARM/YARM individually. The newfound values were
      • C1:LSC-POX11_PHASE_R = 106.991
      • C1:LSC-POY11_PHASE_R = -12.820
    • Then we misaligned the XARM by getting rid of the MICH fringe in the ASDC port with ITMX yaw offset, and locked YARM using AS55_Q and REFL55_I and found the demod phase that minimized the AS55_I and REFL55_Q. The newfound values were
      • C1:LSC-AS55_PHASE_R = -65.9586
      • C1:LSC-REFL55_PHASE_R = -78.6254
    • Repeating the above, but now misaligning YARM with ITMY yaw offset, locking XARM with AS55_Q and REFL55_I, we found the demod phases that minimized AS55_1 and REFL55_Q. The newfound values were
      • C1:LSC-AS55_PHASE_R = -61.4361
      • C1:LSC-REFL55_PHASE_R = -71.0434
  • The above demod phases difference, Schnupp asymmetry between X and Y were measured. We repeated the measurement three times to derive the error.
    • Optimal demod phase difference between X arm and Y arm for both AS55 and REFL55 were measured to be -4.5 +/- 0.1 deg, which means that lx-ly = 3.39 +/- 0.05 cm (Marconi frequency: 11.066195 MHz).
  • We measured the gain difference between AS55_Q and POX11/POY11 = -0.5
  • We measured the gain difference between REFL55_I and POX11/POY11 = -2.5

After this, we locked DARM, CARM and MICH using POX11_I, POY11_I and AS55 error signals respectively, and actuating on ETMX, MC2, and BS with NO TRIGGERS (but FM triggers were on for boosts as usual). Under this condition, FM5 is used for lock acquisition, and FM1, FM2, FM3, FM6 are turned on with FM triggers. No FM4 was on. We also noticed:

  • CARM FM6 "BounceRoll" is slightly different than "YARM" FM6 "Bounce". The absent roll resonant gain actually makes it easier to control the CARM, we just had to use YARM filter for locking it.
  • When CARM is controlled, we often just kick the ETMX to bring it near resonance, since the frequency noise drops and we otherwise have to wait long.
  17008   Fri Jul 15 22:36:04 2022 ranaSummaryLSCFPMI with REFL/AS55 demod phase adjust

Very nice!

DARM feedback should go to ETMY - ETMX, not just a single mirror: Differential ARM.

For it to work with 1 mirror the UGF of the CARM loop must be much larger than DARM UGF. But in our case, both have a UGF of ~150 Hz.

In principle, you could run the CARM loop with higher gain by using the CM servo board, but maybe that can wait until the X,Y -> CARM, DARM handoff.


  17012   Mon Jul 18 16:39:07 2022 PacoSummaryLSCFPMI locking procedure using REFL55 and AS55

[Yuta, Paco]

In summary, we locked FPMI using REFL55_I, REFL55_Q, and AS55_Q. The key to success was to mix POX11_I and POY11_I in the right way to emulate CARM/DARM, and to find out the correct demodulation phase for AS55.


  1. Close PSL shutter and zero offsets in AS55, REFL55, POX11, POY11, and ASDC
    • For ASDC run python3 resetOffsets.py -c C1:LSC-ASDC_IN1, otherwise use the zer offsets on I and Q inputs from the RFPD medm screen.
  2. Lock XARM/YARM using POX/POY to tune demodulation phase.
    • Today, the demode phase in POX11 changed to 104.801, and POY11 to -11.256 deg.
  3. XARM and YARM are used in the following configuration
    • INMAT
      • 0.5 * POX11_I - 0.5 * POY --> XARM
      • 0.5 * POX + 0.5*POY --> YARM
      • REFL55_Q --> MICH (** this should be turned on after POX11/POY11)
    • LSC Filter gains
      • XARM = 0.012
      • YARM = 0.012
      • MICH = +40 (note the sign flip from last time)
    • OUTMAT
      • XARM --> 0.5 * ETMX - 0.5 * ETMY
      • YARM --> MC2
      • MICH --> BS
    • UGFs (sanity check)
      • XARM (DARM) ~ 100 Hz
      • YARM (CARM) ~ 200 Hz
      • MICH (MICH) ~ 40 Hz
  4. Run MICHOpticalGainCalibration.ipynb to see if ASDC vs REFL55_Q looks nice (ellipse in the XY plot), and find any residual offset in REFL55_Q.
    • If the plot doesn't look nice in this regard, the IFO needs to be aligned.
  5. Sensing matrix for CARM/DARM and MICH.
    • With the DARM, CARM and MICH lines on, verify the demod error signals look ok both in mag and phase.
    • For example, we found that CARM error signals were correctly represented by either 0.5 * POX11_I + 0.5 * POY11_I or 0.5 * REFL55_I.
    • Similarly, we found that DARM error signal was correctly represented by either 0.5 * POX11_I - 0.5 * POY11_I or 2.5 * AS55_Q.
    • To find this, we minimized CARM content in AS55_Q, as well as CARM content in REFL55_Q.
  6. We acquired the lock by re-configuring the error point as below:
    • INMAT
      • 0.5*REFL55_I --> YARM (CARM)
      • 2.5 * AS55_Q --> XARM (DARM)
    • During the hand-off trials, we repeatedly ran the sensing matrix and UGF measurements while stopping at various intermediate mixed error points to check how the error signal calibrations changed if at all.
      • Attachment #1 shows the DARM OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
      • Attachment #2 shows the CARM OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
      • Attachment #3 shows the MICH OLTF using POX/POY (blue), only with CARM handoff (green), and after DARM handoff (red)
    • The sensing matrix after handoff is below:
Sensing Matrix with the following demodulation phases
{'AS55': 192.8, 'REFL55': 95.63177865911078, 'POX11': 104.80089727128349, 'POY11': -11.256509422276006}
Sensors          	           DARM     	           CARM     	            MICH     	
C1:LSC-AS55_I_ERR_DQ	5.09e-02 (89.6761 deg)	2.03e-01 (-114.513 deg)	1.28e-04 (-28.9254 deg)	
C1:LSC-AS55_Q_ERR_DQ	4.78e-02 (88.7876 deg)	3.61e-03 (-68.7198 deg)	8.34e-05 (-39.193 deg)	
C1:LSC-REFL55_I_ERR_DQ	5.18e-02 (-92.2555 deg)	1.20e+00 (65.2507 deg)	1.15e-04 (-102.027 deg)	
C1:LSC-REFL55_Q_ERR_DQ	1.81e-04 (59.0854 deg)	1.09e-02 (-114.716 deg)	1.77e-05 (-23.6485 deg)	
C1:LSC-POX11_I_ERR_DQ	8.51e-02 (91.2844 deg)	4.77e-01 (67.1709 deg)	7.97e-05 (-72.5252 deg)	
C1:LSC-POX11_Q_ERR_DQ	2.63e-04 (114.584 deg)	1.32e-03 (-113.505 deg)	2.10e-06 (118.146 deg)	
C1:LSC-POY11_I_ERR_DQ	1.58e-01 (-88.9295 deg)	6.16e-01 (67.6098 deg)	8.71e-05 (172.73 deg)	
C1:LSC-POY11_Q_ERR_DQ	2.89e-04 (-89.1114 deg)	1.09e-03 (70.2784 deg)	3.77e-07 (110.206 deg)	

Lock gpstimes:

  1. [1342220242, 1342220260]
  2. [1342220420, 1342220890]
  3. [1342221426, 1342221574]
  4. [1342222753, 1342223230]

Sensitivity estimate (NANB)

Using diaggui, we look at the AS55_Q error point and the DARM control point (C1:LSC-XARM_OUT). We roughly calibrate the error point using the sensing matrix element and actuation gain at the DARM oscillator freq 4.78e-2 / (10.91e-9 / 307.880^2). The control point is calibrated with a 0.95 Hz SUS pole. Attachment #4 shows the sensitivity estimate.

Attachment 1: DARM_07_18_2022_FMPI.pdf
DARM_07_18_2022_FMPI.pdf DARM_07_18_2022_FMPI.pdf DARM_07_18_2022_FMPI.pdf
Attachment 2: CARM_07_18_2022_FPMI.pdf
CARM_07_18_2022_FPMI.pdf CARM_07_18_2022_FPMI.pdf CARM_07_18_2022_FPMI.pdf
Attachment 3: MICH_07_18_2022_FPMI.pdf
MICH_07_18_2022_FPMI.pdf MICH_07_18_2022_FPMI.pdf MICH_07_18_2022_FPMI.pdf
Attachment 4: fpmi_darm_nb_2022_07.pdf
  17016   Mon Jul 18 21:41:42 2022 AnchalSummaryLSCFPMI locking procedure using REFL55 and AS55

Now that you have found a working configuration, I suggest we update CARM and DARM filter banks so that they are used in locking those degrees of freedom instead of repurposing XARM/YARM banks. It would be bit easier to understand and leaves room for future changes for one configuration while keeping single arm lock configurations untouched.

  17021   Wed Jul 20 11:58:45 2022 PacoSummaryGeneralJenne laser kaput?

[Paco, Yehonathan, JC]

We were trying to setup the Jenne laser to characterize the response of three 1811s that Yehonathan is using for his WOPA experiment (in QIL). We hooked up a ~ 5 VDC power supply to the bias tee and looked to see if there was any DC response in the REF PD. We used a DB9 breakout board and a DB9 cable, and saw some current being drawn. The DC current was a bit too high (500 mA), so we turned the DC voltage off, and realized the VDC power was reversed, probably along the DB9 cable which we didn't check before. As we flipped the power supply leads and turned power back on, we could no longer see any current even though the voltage was now right (or was it???). We would like to debug this laser, and continue using it if it still works (!), but there is negligible documentation either here or in the wiki, so if there are any known places to look at it would be helpful to know them.

  17022   Wed Jul 20 14:12:07 2022 PacoSummaryGeneralJenne laser kaput!

[Koji, Yehonathan, Paco]

Koji pointed out that this laser was always driven with a current driver (which was not nearby), and after finding it on one of the rolling carts, we hooked up the system but found that the laser driver displayed open circuit near the usual 20mA operating point. We therefore have to conclude that this laser is no more. We will look for a reasonable replacement.


[Paco, Yehonathan, JC]

We were trying to setup the Jenne laser to characterize the response of three 1811s that Yehonathan is using for his WOPA experiment (in QIL). We hooked up a ~ 5 VDC power supply to the bias tee and looked to see if there was any DC response in the REF PD. We used a DB9 breakout board and a DB9 cable, and saw some current being drawn. The DC current was a bit too high (500 mA), so we turned the DC voltage off, and realized the VDC power was reversed, probably along the DB9 cable which we didn't check before. As we flipped the power supply leads and turned power back on, we could no longer see any current even though the voltage was now right (or was it???). We would like to debug this laser, and continue using it if it still works (!), but there is negligible documentation either here or in the wiki, so if there are any known places to look at it would be helpful to know them.


  17023   Wed Jul 20 15:58:52 2022 KojiSummaryGeneralJenne laser kaput!

For troubleshooting, the proper laser driver (found beneath the AG network analyzer) was connected.
The current ~1mA was provided and the driver detected the "open circuit", which means the laser diode was busted.


The laser diode in the parts list is: "GTRAN GaAs Strained QW Laser Diode, Part # LD-1060".

  17030   Mon Jul 25 09:05:50 2022 PacoSummaryGeneralTesting 950nm laser found in trash pile

[Paco, Yehonathan]

==== Late elog from Friday ====

Koji provided us with a QFLD-950-3S (QPHOTONICS) salvaged from Aidan's junk pile (LD is alive according to him). We tested the Jenne laser setup with this just to decide if we should order another one, and it worked.

The laser driver anode and cathode pins (8/9, 4/5 respectively) on the rear DB9 port from the  ILX Lightwave LDX-3412 driver were connected to the corresponding anode and cathode pins in the laser package (5, and 9; note the numbers are reversed between driver and laser). Then, interlock pins 1 and 2 in the driver were shorted to enable operation. This is all illustrated in Attachments #1-2.

After setting a limit of 27.6 mA current in the driver, we slowly increased the actual current to ~ 19 mA until we could see light on a beam card. We can go ahead and get a 1060 nm replacement.

Attachment 1: PXL_20220722_234600124.jpg
Attachment 2: PXL_20220722_234551918.jpg
  17035   Mon Jul 25 18:22:30 2022 DeekshaSummaryWikiMeasured the PZT TF Successfully

Measured the PZT beatnote using the setup mentioned in elog post 17031. Attached is the data taken from 10kHz to 1MHz, decadewise data was also taken that I'm not including in this post. A_R refers to the transfer function taken of channel A wrt the voltage reference (the swept sine we are inputting which has an IF of 30kHz). A and B correspond to the I and Q components of the signal taken from the DFD, respectively. I am currently working on plotting the data, and will shortly update this post with plots. Next steps - 

- quantify the uncertainty in the signal (I think)

- vectfit the data to find poles and zeroes

(and possibly find a better way to print/obtain data)

Edit: first pass of data plotted

Attachment 1: A_R_MAG.txt
"4395A REV1.12"
"DATE: Sep 17 2017"

"SWEEP TIME:  385.3 ms"
... 811 more lines ...
Attachment 2: A_R_PHASE.txt

"SWEEP TIME:  385.3 ms"
... 808 more lines ...
Attachment 3: B_R_MAG.txt
"4395A REV1.12"
"DATE: Sep 17 2017"

"SWEEP TIME:  385.3 ms"
... 809 more lines ...
Attachment 4: B_R_PHASE.txt

"SWEEP TIME:  385.3 ms"
... 807 more lines ...
Attachment 5: freq_resp_I.png
Attachment 6: freq_resp_Q.png
  17051   Mon Aug 1 17:19:39 2022 CiciSummaryGeneralRPitaya Data on Jupyter Notebook

Have successfully plotted data from the Red Pitaya on Jupyter Notebook! Have lost years of my life fighting with PyQt. Thanks to Deeksha for heavy contribution. Next task is to get actually good data (seeing mostly noise right now and haven't figured out how to change my input settings) and then to go to set up the RPi in the lab.

  17064   Fri Aug 5 17:03:31 2022 YehonathanSummaryGeneralTesting 950nm laser found in trash pile

I set out to test the actuation bandwidth of the 950nm laser. I hooked the laser to the output of the bias tee of PD testing setup. I connected the fiber coming out of the laser to the fiber port of 1611 REF PD.

The current source was connected to the DB9 input of the PD testing setup. I turned on the current source and set the current to 20mA. I measured with a fluke ~ 2V at the REF PD DC port.

I connected the AC port of the bias tee to the RF source of the network analyzer and the AC port of the REF PD to the B port of the network analyzer. Attachment 2 shows the setup.

I took a swept sine measurement (attachment) from 100kHz to 500MHz.

It seems like the bandwidth is ~ 1MHz which is weird considering the spec sheet says that the pulse rise time is 0.5ns. To make sure we are not limited by the bandwidth of the cables I looped the source and the input of the network analyzer using the cables used for the previous measurement and observed that the bandwidth is a few 100s of MHz.

Attachment 1: 20220805_164434.jpg
Attachment 2: LaserActuation_TF_Measurement.drawio.pdf
  17069   Tue Aug 9 19:54:31 2022 yutaSummaryLSCFPMI locking tonight

[Tega, Anchal, Yuta]

We resored FPMI locking settings. Below is the summary of locking configurations tonight.
To ease the lock acquisition, the step to feedback POX11_I to ETMX and POY11_I to MC2 before POX and POY mixing was necessary tonight.

 - 0.5 * POX11_I + 0.5 * POY11_I handed to 0.5 * REFL55_I
 - YARM filter module, FM4,5 for acquisition, FM1,2,3,6,8 triggered, C1:LSC-YARM_GAIN = 0.012
 - Actuation on -0.77 * MC2
 - UGF ~ 250 Hz

 - 0.5 * POX11_I - 0.5 * POY11_I handed to 4.6 * AS55_Q (it was 2.5 in 40m/17012)
 - XARM filter module, FM5 for acquisition (no FM4), FM1,2,3,6,8 triggered, C1:LSC-XARM_GAIN = 0.015
 - Actuation on 0.5 * ETMX - 0.5 * ETMY
 - UGF ~ 120 Hz

 - 1 * REFL55_Q (turned on after XARM and YARM acquisition)
 - MICH filter module, FM4,5,8 for acquisition, FM2,3 triggered, C1:LSC-MICH_GAIN = +40
 - Actuation on 0.5 * BS
 - UGF ~ 100 Hz

Measured sensing matrix:
Sensing Matrix with the following demodulation phases
{'AS55': 200.41785156862835, 'REFL55': 93.7514468401475, 'POX11': 105.08325063571438, 'POY11': -11.343909976281823}
Sensors              DARM                    CARM                   MICH
C1:LSC-AS55_I_ERR_DQ 5.27e-02 (-154.105 deg) 2.83e-01 (132.395 deg) 1.17e-04 (-40.1051 deg)
C1:LSC-AS55_Q_ERR_DQ 3.99e-02 (-151.048 deg) 1.42e-02 (125.504 deg) 1.41e-04 (-2.42846 deg)
C1:LSC-REFL55_I_ERR_DQ 5.59e-02 (77.6871 deg) 1.15e+00 (-44.589 deg) 3.55e-04 (69.2585 deg)
C1:LSC-REFL55_Q_ERR_DQ 1.84e-03 (16.3186 deg) 3.35e-03 (125.67 deg) 4.59e-05 (4.18718 deg)
C1:LSC-POX11_I_ERR_DQ 1.54e-01 (-157.852 deg) 6.07e-01 (-42.1078 deg) 5.55e-05 (73.3963 deg)
C1:LSC-POX11_Q_ERR_DQ 6.83e-05 (-148.591 deg) 6.37e-04 (121.983 deg) 1.35e-06 (43.7201 deg)
C1:LSC-POY11_I_ERR_DQ 1.85e-01 (36.1624 deg) 5.73e-01 (-43.1776 deg) 2.12e-04 (82.16 deg)
C1:LSC-POY11_Q_ERR_DQ 2.16e-05 (130.937 deg) 6.38e-05 (-173.194 deg) 1.40e-06 (47.5416 deg)

FPMI locked periods:
  - 1344129143 - 1344129520
  - 1344131106 - 1344131305
  - 1344133503 - 1344134020

- Restore CM servo for CARM

  17073   Wed Aug 10 20:30:54 2022 TegaSummarySUSCharacterisation of suspension damping

[Yuta, Tega]

We diagnosed the suspension damping of the IMC/BHD/recycling optics by kicking the various degree of freedom (dof) and then tuning the gain so that we get a residual Q of approx. 5 in the cases where this can be achieved.

MC1: Good
MC2: SIDE-YAW coupling, but OK
MC3: Too much coupling between dofs, NEEDS ATTENTION
LO1: Good
LO2: Good
AS1: POS-PIT coupling, close to oscillation, cnt2um off, NEEDS ATTENTION
AS4: PIT-YAW coupling, cannot increase YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION
PR2: No cnt2um, No Cheby
PR3: POS-PIT coupling, cannot increase POS/PIT/YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION
SR2: No cnt2um

Attachment 1: BHD_SUSPIT_KICK.png
Attachment 2: BHD_SUSPOS_KICK.png
Attachment 3: BHD_SUSSIDE_KICK.png
Attachment 4: BHD_SUSYAW_KICK.png
Attachment 5: IMC_SUSPIT_KICK.png
Attachment 6: IMC_SUSPOS_KICK.png
Attachment 7: IMC_SUSSIDE_KICK.png
Attachment 8: IMC_SUSYAW_KICK.png
Attachment 9: PRSR_SUSPIT_KICK.png
Attachment 10: PRSR_SUSPOS_KICK.png
Attachment 11: PRSR_SUSSIDE_KICK.png
Attachment 12: PRSR_SUSYAW_KICK.png
  17089   Thu Aug 18 14:49:35 2022 YehonathanSummaryLSCFPMI Sensitivity

{Yuta, Yehonathan}

We wrote a notebook found on Git/40m/measurements/LSC/FPMI/NoiseBudget/FPMISensitivity.ipynb for calculating the MICH, DARM (currently XARM), CARM (currently YARM) sensitivities in the FPMI lock which can be run daily.

The IN and OUT channels of each DOFs are measured at a certain GPS time and calibrated using the optical gains and actuation calibration measured in the previous post.

Attachment shows the results.

It seems like the UGFs for MICH and DARM (currently XARM) match the ones that were estimated previously (100Hz for MICH, 120Hz for DARM) except for CARM for which the UGF was estimated to be 250Hz and here seems to be > 1kHz.

Indeed one can also see that the picks in the CARM plot don't match that well. Calculation shows that at 250Hz OUT channel is 6 times more than the IN channel. Calibrations for CARM should be checked.

MICH sensitivity using REFL55 at high frequencies is not much better than what was measured with AS55.

DARM sensitivity at 10Hz is a factor of a few better than the single arm lock sensitivity.

Now it is time to do the budgeting.

Attachment 1: Sensitivity_Plot_1344133503.pdf
  17091   Thu Aug 18 18:10:49 2022 KojiSummaryLSCFPMI Sensitivity

The overlapping plot of the calibrated error and control signals gives you an approximately good estimation of the freerun fluctuation, particularly when the open-loop gain G is much larger or much smaller than the unity.
However, when the G is close to the unity, they are both affected by "servo bump" and both signals do not represent the freerun fluctuation around that frequency.

To avoid this, the open-loop gain needs to be measured every time when the noise budget is calculated. In the beginning, it is necessary to measure the open-loop gain over a large frequency range so that you can refine your model. Once you gain sufficient confidence about the shape of the open-loop gain, you can just use measurement at a frequency and just adjust the gain variation (most of the cases it comes from the optical gain).

I am saying this because I once had a significant issue of (project-wide) incorrect sensitivity estimation by omitting this process.

  60   Sun Nov 4 23:22:50 2007 waldmanUpdateOMCOMC PZT and driver response functions
I wrote a big long elog and then my browser hung up, so you get a less detailed entry. I used Pinkesh's calibration of the PZT (0.9 V/nm) to calibrate the PDH error signal, then took the following data on the PZT and PZT driver response functions.:

  • FIgure 1: PZT dither path. Most of the features in this plot are understood: There is a 2kHz high pass filter in the PZT drive which is otherwise flat. The resonance features above 5 kHz are believed to be the tombstones. I don't understand the extra motion from 1-2 kHz.
  • Figure 2: PZT dither path zoom in. Since I want to dither the PZT to get an error signal, it helps to know where to dither. The ADC Anti-aliasing filter is a 3rd order butterworth at 10 kHz, so I looked for nice flat places below 10 KHz and settled on 8 kHz as relatively harmless.
  • Figure 3: PZT LSC path. This path has got a 1^2:10^2 de-whitening stage in the hardware which hasn't been digitally compensated for. You can see its effect between 10 and 40 Hz. The LSC path also has a 160 Hz low path which is visible causing a 1/f between 200 and 500 Hz. I have no idea what the 1 kHz resonant feature is, though I am inclined to point to the PDH loop since that is pretty close to the UGF and there is much gain peaking at that frequency.
Attachment 1: 071103DitherShape.png
Attachment 2: 071103DitherZoom.png
Attachment 3: 071103LSCShape.png
Attachment 4: 071103DitherShape.pdf
Attachment 5: 071103DitherZoom.pdf
Attachment 6: 071103LSCShape.pdf
Attachment 7: 071103LoopShape.pdf
  61   Sun Nov 4 23:55:24 2007 ranaUpdateIOOFriday's In-Vac work
On Friday morning when closing up we noticed that we could not get the MC to flash any modes.
We tracked this down to a misalignment of MC3. Rob went in and noticed that the stops were
still touching. Even after backing those off the beam from MC3 was hitting the east edge of
the MC tube within 12" of MC3.

This implied a misalignment of MC of ~5 mrad which is quite
large. At the end our best guess is that either I didn't put the indicator blocks in the
right place or that the MC3 tower was not slid all the way back into place. Since there
is such a strong stickiness between the table and the base of the tower its easy to
imagine the tower was misplaced.

So we looked at the beam on MC2 and twisted the MC3 tower. This got the beam back onto the
MC2 cage and required ~1/3 if the MC3 bias range to get the beam onto the center. We used
a good technique of finding that accurately: put an IR card in front of MC2 and then look
in from the south viewport of the MC2 chamber to eyeball the spot relative to the OSEMs.

Hitting MC2 in the middle instantly got us multiple round trips of the beam so we decided
to close up. First thing Monday we will put on the MC1/MC3 access connector and then
pump down.

Its possible that the MC length has changed by ~1-2 mm. So we should remeasure the length
and see if we need to reset frequencies and rephase stuff.
  62   Mon Nov 5 07:29:35 2007 ranaUpdateIOOFriday's In-Vac work
Liyuan recently did some of his pencil beam scatterometer measurements measuring not the
BRDF but instead the total integrated power radiated from each surface point
of some of the spare small optics (e.g. MMT, MC1, etc.).

The results are here on the iLIGO Wiki.

So some of our loss might just be part of the coating.
  63   Mon Nov 5 14:44:39 2007 waldmanUpdateOMCPZT response functions and De-whitening
The PZT has two control paths: a DC coupled path with gain of 20, range of 0 to 300 V, and a pair of 1:10 whitening filters, and an AC path capacitively coupled to the PZT via a 0.1 uF cap through a 2nd order, 2 kHz high pass filter. There are two monitors for the PZT, a DC monitor which sniffs the DC directly with a gain of 0.02 and one which sniffs the dither input with a gain of 10.

There are two plots included below. The first measures the transfer function of the AC monitor / AC drive. It shows the expected 2 kHz 2d order filter and an AC gain of 100 dB, which seems a bit high but may be because of a filter I am forgetting. The high frequency rolloff is the AA and AI filters kicking in which are 3rd order butters at 10 kHz.

The second plot is the DC path. The two traces show the transfer function of DC monitor / DC drive with and with an Anti-dewhitening filter engaged in the DC drive. I fit the antidewhite using a least squares routine in matlab constrained to match 2 poles, 2 zeros, and a delay to the measured complex filter response. The resulting filter is (1.21, 0.72) : (12.61, 8.67) and the delay was f_pi = 912 Hz. The delay is a bit lower than expected for the f_pi = 3 kHz delay of the AA, AI, decimate combination, but not totally unreasonable. Without the delay, the filter is (1.3, 0.7) : (8.2, 13.2) - basically the same - so I use the results of the fit with delay. As you can see, the response of the combined digital AntiDW, analog DW path is flat to +/- 0.3 dB and +/- 3 degrees of phase.

Note the -44 dB of DC mon / DC drive is because the DC mon is calibrated in PZT Volts so the TF is PZT Volts / DAC cts. To calculate this value: there are (20 DAC V / 65536 DAC cts)* ( 20 PZT V / 1 DAC V) = -44.2 dB. Perfect!

I measured the high frequency response of the loop DC monitor / DC drive to be flat.
Attachment 1: 07110_DithertoVmonAC_sweep2-0.png
Attachment 2: 071105_LSCtoVmonDC_sweep4-0.png
Attachment 3: 07110_DithertoVmonAC_sweep2.pdf
07110_DithertoVmonAC_sweep2.pdf 07110_DithertoVmonAC_sweep2.pdf
Attachment 4: 071105_LSCtoVmonDC_sweep4.pdf
071105_LSCtoVmonDC_sweep4.pdf 071105_LSCtoVmonDC_sweep4.pdf
  68   Tue Nov 6 14:51:03 2007 tobin, robUpdateIOOMode cleaner length
Using the Ward-Fricke variant* of the Sigg-Frolov method, we found the length of the mode cleaner to be 27.0934020183 meters, a difference of -2.7mm from Andrey, Keita, and Rana's measurement on August 30th.

The updated RF frequencies are:
3  fsr =  33 195 439 Hz
12 fsr = 132 781 756 Hz
15 fsr = 165 977 195 Hz
18 fsr = 199 172 634 Hz
* We did the usual scheme of connecting a 20mVpp, 2 kHz sinusoid into MC AO. Instead of scanning the RF frequency by turning the dial on the 166 MHz signal generator ("marconi"), we connected a DAC channel into its external modulation port (set to 5000 Hz/volt FM deviation). We then scanned the RF frequency from the control room, minimizing the height of the 2 kHz line in LSC-PD11. In principle one could write a little dither servo to lock onto the 15fsr, but in practice simply cursoring the slider bar around while watching a dtt display worked just fine.
  69   Tue Nov 6 15:36:03 2007 robUpdateLSCXARM locked
Easily, after resetting the PSL Uniblitz shutters. There's no entry from David or Andrey about the recovery from last week's power outage, in which they could have indicated where the procedure was lacking/obscure. Tsk, tsk.
  76   Wed Nov 7 09:38:01 2007 steveUpdateVACrga scan
pd65-m-d2 at cc1 6e-6 torr
Attachment 1: pd65d2.jpg
  81   Wed Nov 7 16:07:03 2007 steveUpdatePSLPSL & IOO trend
1.5 days of happy psl-ioo with litle bumps in C1:PSL-126MOPA_HTEMP
Attachment 1: psl1.5dtrend.jpg
  82   Thu Nov 8 00:55:44 2007 pkpUpdateOMCSuspension tests
[Sam , Pinkesh]

We tried to measure the transfer functions of the 6 degrees of freedom in the OMS SUS. To our chagrin, we found that it was very hard to get the OSEMs to center and get a mean value of around 6000 counts. Somehow the left and top OSEMs were coupled and we tried to see if any of the OSEMs/suspension parts were touching each other. But there is still a significant coupling between the various OSEMs. In theory, the only OSEMS that are supposed to couple are [SIDE] , [LEFT, RIGHT] , [TOP1, TOP2 , TOP3] , since the motion along these 3 sets is orthogonal to the other sets. Thus an excitation along any one OSEM in a set should only couple with another OSEM in the same same set and not with the others. The graphs below were obtained by driving all the OSEMS one by one at 7 Hz and at 500 counts ( I still have to figure out how much that is in units of length). These graphs show that there is some sort of contact somewhere. I cant locate any physical contact at this point, although TOP2 is suspicious and we moved it a bit, but it seems to be hanging free now. This can also be caused by the stiff wire with the peek on it. This wire is very stiff and it can transmit motion from one degree of freedom to another quite easily. I also have a graph showing the transfer function of the longitudnal degree of freedom. I decided to do this first because it was simple and I had to only deal with SIDE, which seems to be decoupled from the other DOFs. This graph is similar to one Norna has for the longitudnal DOF transfer function, with the addition of a peak around 1.8 Hz. This I reckon could very be due to the wire, although it is hard to claim for certain. I am going to stop the measurement at this time and start a fresh high resolution spectrum and leave it running over night.

There is an extra peak in the high res spectrum that is disturbing.
Attachment 1: shakeleft.pdf
Attachment 2: shakeright.pdf
Attachment 3: shakeside.pdf
Attachment 4: shaketop1.pdf
Attachment 5: shaketop2.pdf
Attachment 6: shaketop3.pdf
Attachment 7: LongTransfer.pdf
LongTransfer.pdf LongTransfer.pdf LongTransfer.pdf
Attachment 8: Shakeleft7Nov2007_2.pdf
Attachment 9: Shakeleft7Nov2007_2.png
  83   Thu Nov 8 11:40:21 2007 steveUpdatePEMparticle counts are up
I turned up the psl HEPA filter to 100%
This 4 days plot shows why
Attachment 1: pslhepaon.jpg
  87   Fri Nov 9 00:23:12 2007 pkpUpdateOMCX and Z resonances
I got a couple of resonance plots going for now. I am still having trouble getting the Y measurement going for some reason. I will investigate that tommorow. But for tonight and tommorow morning, here is some food for thought. I have attached the X and Z transfer functions below. I compared them to Norna's plots - so just writing out what I was thinking -

Keep in mind that these arent high res scans and have been inconviniently stopped at 0.5 Hz Frown.

Z case --

I see two small resonances and two large ones - the large ones are at 5.5 Hz and 0.55 Hz and the small ones at 9 Hz and 2 Hz respectively. In Norna's resonances, these features arent present. Secondly, the two large peaks in Norna's measurement are at 4.5 Hz and just above 1 Hz. Which was kind of expected, since we shortened the wires a bit, so one of the resonances moved up and I suppose that the other one moved down for the same reason.

X case --

Only one broad peak at about 3 Hz is seen here, whereas in Norna's measurement, there were two large peaks and one dip at 0.75 Hz and 2.5 Hz. I suspect that the lower peak has shifted lower than what I scanned to here and a high res scan going upto 0.2 Hz is taking place overnight. So we will have to wait and watch.

Pitch Roll and Yaw can wait for the morning.
Attachment 1: Xtransferfunc.pdf
Xtransferfunc.pdf Xtransferfunc.pdf Xtransferfunc.pdf
Attachment 2: Ztransferfunc.pdf
Ztransferfunc.pdf Ztransferfunc.pdf Ztransferfunc.pdf
  88   Fri Nov 9 09:37:55 2007 steveUpdatePSLhead temp hiccup
Just an other PSL-126MOPA_HTEMP hiccup.
The water chiller is at 20.00C
Attachment 1: headtempup.jpg
  93   Mon Nov 12 10:53:58 2007 pkpUpdateOMCVertical Transfer functions
[Norna Sam Pinkesh]

These plots were created by injected white noise into the OSEMs and reading out the response of the shadow sensors ( taking the power spectrum). We suspect that some of the additional structure is due to the wires.
Attachment 1: VerticalTrans.pdf
VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf
  96   Mon Nov 12 15:18:34 2007 robUpdatePSLISS

After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.
Attachment 1: ISS.png
  97   Mon Nov 12 23:44:19 2007 JohnUpdatePSLISS


After John soldered a 3.7 MHz notch filter onto the ISS board, I took a quick TF and RIN measurement. The out-of-loop RIN is attached, including a dark noise trace, and with the gain slider at 10dB. The UGF is 35kHz with a phase margin of 30deg. John is currently doing a more thorough inspection, and will detail his findings in a subentry.

No progress on the ISS tonight. I tried to implement a new filter (attached)to try and gain some phase before the notch. If anything this made things worse. More work is needed.

The ISS loop is off and the power is off at the chassis.
Attachment 1: ISSfilter.jpg
  98   Tue Nov 13 14:33:40 2007 JohnUpdatePSLISS filter
The transfer function from 'In Loop Error Point Monitor' to TP3 the filter out test point on the ISS board.

-33dB at 3.715MHz.
Attachment 1: PB130035.JPG
Attachment 2: DSC_0165.JPG
  101   Wed Nov 14 12:47:19 2007 tobinUpdatePSLISS
John, Tobin

With John's notch filter installed and the increased light on the ISS sensing diode, we were able to get a UGF of about 60 kHz with the gain slider set to about 20 dB. This morning we met with Stefan to learn his ISS-fu.

His recommendations for the ISS include:
  • Replace the cables from the board to the front panel connectors if this hasn't already been done.
  • Replace the input opamps with 4131's. Be sure to test both positive and negative input signals.
  • Check that all the compensation capacitors are in place and are 68 pF
  • Make sure all the feedback loops have high frequency rolloff
  • The ISS board reads the PDs differentially; make sure the PD sends differentially.
  • Add a big (ie 10uF tantalum) capacitor to the PD to suppress power supply noise
  • Add bigger power supply bypass caps to the ISS
I just took sensing noise spectra (from the PD DC bnc ports) and then took the photodiodes off the table to check that they have the negative end of the differential line connected to ground. (I placed black metal beam blocks on the table in place of the ISS PD's. Also, from the ISS schematic, it looks like it sends a differential output to the PD DC bnc ports, but we have been plugging them directly into the SR785 (grounding the shield). We should make a little BNC-doodle that separates the signal+shield to go into the A and B inputs on the spectrum analyzer.) Opening up one of the photodiodes, it appears that the negative line of the differential output is not connected. Will continue later this afternoon.
  102   Wed Nov 14 16:54:54 2007 pkpUpdateOMCMuch better looking vertical transfer functions
[Norna Pinkesh]

So after Chub did his wonderful mini-surgery and removed the peek from the cables and after Norna and I aligned the whole apparatus, the following are the peaks that we see.
It almost exactly matches Norna's simulations and some of the extra peaks are possibly due to us exciting the Roll/longitudnal/yaw and pitch motions. The roll resonance is esp prominent.

We also took another plot with one of the wires removed and will wait on Chub before we remove another wire.
Attachment 1: VerticalTransPreampwireremovedNov142007.pdf
VerticalTransPreampwireremovedNov142007.pdf VerticalTransPreampwireremovedNov142007.pdf VerticalTransPreampwireremovedNov142007.pdf VerticalTransPreampwireremovedNov142007.pdf
Attachment 2: VerticalTranswiresclampedNov142007.pdf
VerticalTranswiresclampedNov142007.pdf VerticalTranswiresclampedNov142007.pdf VerticalTranswiresclampedNov142007.pdf VerticalTranswiresclampedNov142007.pdf
  103   Wed Nov 14 17:50:00 2007 tobinUpdatePSLISS
Here's the current wiring between the ISS and its PDs:

pin cable PD ISS
1 blue +5 +5
2 red +15 +15
3 white -15 -15
4 brown OUT IN PD +
5,6,7,8 no connection no connection GND
9 black GND IN PD -

The schematics for the ISS and the PDs are linked from our wiki.

We'll connect the ISS GND to the PD GND.
  105   Thu Nov 15 17:09:37 2007 pkpUpdateOMCVertical Transfer functions with no cables attached.
[Norna Pinkesh]

The cables connecting all the electronics ( DCPDs, QPDs etc) have been removed to test for the vertical transfer function. Now the cables are sitting on the OMC bench and it was realigned.
Attachment 1: VerticaltransferfuncnocablesattachedNov152007.pdf
VerticaltransferfuncnocablesattachedNov152007.pdf VerticaltransferfuncnocablesattachedNov152007.pdf VerticaltransferfuncnocablesattachedNov152007.pdf VerticaltransferfuncnocablesattachedNov152007.pdf
  106   Thu Nov 15 18:06:06 2007 tobinUpdateComputersalex: linux1 root file system hard disk's dying
I just noticed that Alex made an entry in the old ilog yesterday, saying: "Looks like linux1 root filesystem hard drive is about to die. The system log is full of drive seek errors. We should get a replacement IDE drive as soon as possible or else the unthinkable could happen. 40 Gb IDE hard drive will be sufficient."
  109   Thu Nov 15 18:37:06 2007 tobinUpdateComputerspossible replacement for linux1's disk
It looks like the existing disk in linux1 is a Seagate ST380013A (this can be found either via the smartctl utility or by looking at the file /proc/ide/hda/model). It appears that you can still buy this disk from amazon, though I think just about any ATA disk would work. I'll ask Steve to buy one for us.
  110   Fri Nov 16 11:27:18 2007 tobinUpdateComputersscript fix
I added a tidbit of code to "LIGOio.pm" that fixes a problem with ezcastep on Linux. Scripts such as "trianglewave" will now work on Linux.
# On Linux, "ezcastep" will interpret negative steps as command line arguments,
# because the GNU library interprets anything starting with a dash as a flag.
# There are two ways around this.  One is to set the environment variable
# POSIXLY_CORRECT and the other is to inject "--" as a command line argument
# before any dashed arguments you don't want interpreted as a flag.  The former
# is easiest to use here:

if (`uname` =~ m/Linux/) {
    # Add an environment variable for child processes
  111   Fri Nov 16 14:11:26 2007 tobinUpdateComputersop140
Alan called to say that Phil Ehrens will be coming by to take op140 off our hands.
  112   Fri Nov 16 14:31:43 2007 tobinUpdateComputersop140 disks
Phil Ehrens stopped by and took op140's disks.
Attachment 1: DSC_0173.JPG
  117   Tue Nov 20 11:10:07 2007 tobinUpdateComputersepics access from matlab
I installed "labca", which allows direct access to EPICS channels from within Matlab. It comes with both Linux and Solaris binaries (and source) but I've only tried it on linux.

To set it up, run these shell commands:
pushd /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86
setenv PATH ${PATH}:`pwd`
cd /cvs/cds/caltech/users/tf/build/labca_2_1/lib/linux-x86
Then start matlab, and within matlab type:
addpath /cvs/cds/caltech/users/tf/build/labca_2_1/bin/linux-x86/labca
help labca
foo = lcaGet('C1:PSL-FSS_RCTRANSPD')
It seems like reasonably well-written software, and is being actively maintained right now. If we like it, I can build a more recent version, install it in a more permanent location, etc.
  121   Wed Nov 21 14:31:41 2007 robUpdatePSLFSS twiddle

I `tweaked' the FSS path today. Here's what I did:

1) Shut down the FSS autolocker

2) Turn off FSS servo

3) Assume the beam coming back from the AOM is double-first-order, and don't make any changes large enough to lose it.

4) Tweak the alignment of these components to maximize the incident power on the RC reflected diode:

a) PBS before AOM
b) AOM
c) curved mirror after the AOM

5) Translate the AOM such that the beam moves away from the PZT, then when it levels off (no more power gains with movement),
move it back just a little bit so there's a teensy drop in power. This should but the beam as close to the edge as possible,
but whether or not it's the best place is still to be determined.

6) Lock the FSS, and align the mirrors into the frequency reference cavity.

After all this, the RC transmitted power went from .57 to .73 -- probably not a big enough change to account for the missing loop
gain, but we'll know more once the loop gets measured (after Alberto stops hogging the Agilent network analyzer).

Other possible routes include a systematic check of the upstream path (e.g., the Pockels cell) and just increasing the pickoff fraction for the FSS.
ELOG V3.1.3-