40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 2 of 344  Not logged in ELOG logo
ID Datedown Author Type Category Subject
  17282   Thu Nov 17 20:02:10 2022 yutaSummaryBHDMICH optical gain measurements with different LO phases

MICH optical gain was measured with different LO phases over ~90 degrees.
Zero crossing of BH55_Q_ERR seems to be roughly 55 degrees away from optimal LO phase.

What we did:
 - Locked MICH with AS55_Q with no offset, with UGF at ~10 Hz (same as configuration in 40m/17279).
 - Injected BS calibration line at amptilude of 300 counts at 211.1 Hz.
 - Locked LO Phase with BH55_Q with different offsets added at C1:HPC-LO_PHASE_OFFSET.
 - Measured sensing matrix at that frequency. Counts are calibrated into meters using actuator efficiencies as described in 40m/17279.
 - LO phase was obtained using a DC value of BH55_Q. This was calibrated into degrees from the following:

Amplitude of LO-AS fringe in BH55_Q was calculated to be

A = BH55optgain*lamb/(4*pi) = 60 counts

where BH55optgain is 7.12e8 counts/m, which is optical gain of BH55_Q for LO1 measured in 40m/17279.
(Actually, BH55_Q goes upto ~ +/-200 counts in time series data, but maybe 60 is the nominal fringe amplitude, considering alignment fluctuations and fluctuation in AS darkness? Note that, no offset in BH55_Q is assumed in this calculation, but AM etc can create an offset.) 
LO phase can be obtained by

LOphase = arcsin(BH55_Q/A)

where BH55_Q a DC value (10 sec average) of BH55_Q.

Result:
 Attachment #1 is uncalibrated plot C1:HPC-LO_PHASE_OFFSET of around +/- 50 was the maximum we could add, and more offset gave unstable lock.
 Attachment #2 is calibrated plot. AS55_Q does not depend on LO phase, as expected. BH55_Q and BHDC_DIFF depend on LO phase as expected. BH55_I and AS55_I stay at low level, as expected (this means that our RF demodulation phase is OK).
 Dotted gray line is an eyeball fit of expected curve (40m/17170) to fool your eyes.
 This tells you that we are roughly 55 deg away from LO phase which gives maximum MICH signal for BHDC_DIFF.
 Error bar in x-axis is from standard deviation of BH55_Q fluctuations. Error in y axis is probably ~20% at maximum.
 Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/MeasureSensMatBHD.ipynb

Next:
 - Repeat the measurement with
   - MICH locked with higher UGF, with notch at 211.1 Hz, for more robust AS dark fringe
   - DCPD A and B balanced at 211.1 Hz (null MICH signal for BHDC_SUM to balance?)
   - Measure optical gain also for BHDC_SUM and BH55_Q demodulated at audio dither
   - Lock LO phase at different sign so that we can sweep LO phase over ~180 deg
   - Sign-sensitive optical gain measurement (demodulation with BS motion necessary)
 - Compare with expected values from simulations
 - Why do we have 55 degrees offset? Expected offset is 90 degrees...
   - Check if there is any RAM in 55 MHz in the input beam by measuring AM with ITM single bounce

  17281   Thu Nov 17 16:48:07 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo running Now

I've moved the FSS Slow PID script running to megatron through systemd daemons. The script is working as expected right now. I've updated megatron motd and the always running scripts page here.

  17280   Thu Nov 17 15:53:47 2022 JCConfigurationCamerasITMX Camera -- attempt at fix

The issue was the power supply.

Quote:

I found that an old BNC cable for ITMXF video existed so I first tried swapping both ends of the cable, one on the ITMX viewport and the other one in the video MUX input in the rear. This didn't fix the issue.

I searched around in the CCD cabinet by XARM and found an identical analog camera so I swapped it and got the same image ...

I then searched for a AC/DC supply cable, but couldn't find one.

 

  17279   Thu Nov 17 14:12:58 2022 yutaSummaryBHDOptical gain calibrations for BHD MICH with lower UGF

[Paco, Yuta]

We found that MICH UGF was unexpectedly high, ~200 Hz, in the measurement yesterday, which makes the closed loop gain to be more than one at MICH line injection at 211.1 Hz.
We did optical gain calibrations for AS55, BH55 and BHDC_DIFF in BHD MICH again with UGF at around 10 Hz.
This solved the inconsistent result with free swing calibration.

What we did:
 Did the same measurement for BHD MICH as written in 40m/17274, but with MICH UGF of ~10 Hz and LO PHASE UGF of ~15 Hz (see OLTFs in Attachment #1, and filter configurations in Attachment #2).
 Updated sensing matrix is as follows

Sensing Matrix with the following demodulation phases (counts/counts)
{'AS55': -163.52789698340882, 'BH55': 152.7860744565449}
      Sensors        	MICH @211.1 Hz       	LO1 @287.1 Hz       	AS1 @281.79 Hz       	
C1:LSC-AS55_I_ERR_DQ	1.85e-05 (-118.82 deg)	3.31e-07 (-32.19 deg)	7.86e-07 (112.27 deg)	
C1:LSC-AS55_Q_ERR_DQ	7.32e-04 (59.57 deg)	1.19e-06 (158.17 deg)	9.07e-07 (-92.25 deg)	
C1:LSC-BH55_I_ERR_DQ	5.02e-04 (-123.21 deg)	1.79e-05 (-26.73 deg)	1.76e-05 (-120.23 deg)	
C1:LSC-BH55_Q_ERR_DQ	1.75e-03 (59.57 deg)	2.71e-04 (-22.64 deg)	2.56e-04 (-114.37 deg)	
C1:HPC-BHDC_DIFF_OUT	1.00e-03 (-115.93 deg)	3.09e-05 (-14.99 deg)	2.84e-05 (-110.23 deg)	

 Using BS actuation efficiency of 26.08e-9 /f^2 m/counts (40m/16929), optical gain for AS55_Q and BHDC_DIFF for MICH is

7.32e-03 / (26.08e-9/(211.1**2)) = 1.25e9 counts/m (AS55_Q for MICH) This is consistent with freeswing measurement (1.24e9 m/counts) 40m/17274
1.00e-03 / (26.08e-9/(211.1**2)) = 1.71e9 counts/m (BHDC_DIFF for MICH)

 Using LO1 and AS1 actuation efficiencies of 3.14e-8 /f^2 m/counts (40m/17206), optical gains for BH55_Q for LO1 and AS1 are

2.71e-04 / (3.14e-8/(287.1**2)) = 7.12e8 counts/m (BH55_Q for LO1)
2.56e-04 / (3.14e-8/(281.79**2)) = 6.47e8 counts/m (BH55_Q for AS1)

  (Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/MeasureSensMatBHD.ipynb)

Next:
 - Compare them with expected values
 - Measure them with different locking points (different LO phases, MICH offsets; LO phase can be calibrated using optical gain calibration of BH55_Q)

  17278   Thu Nov 17 12:24:48 2022 PacoConfigurationCamerasITMX Camera -- attempt at fix

I found that an old BNC cable for ITMXF video existed so I first tried swapping both ends of the cable, one on the ITMX viewport and the other one in the video MUX input in the rear. This didn't fix the issue.

I searched around in the CCD cabinet by XARM and found an identical analog camera so I swapped it and got the same image ...

I then searched for a AC/DC supply cable, but couldn't find one.

Quote:

Coming in this morning, I found ITMX Camera malfunctioning.

 

  17277   Thu Nov 17 11:24:39 2022 JCHowToLSCLocking MICH

[Yuta, JC]

Here is the Yuta's Alignment Scheme from elog 17056  with these slight adjustments:

Current alignment scheme:
Current alignment scheme I figured out is the following.
 - Check Y green. If it is transmitted at good spot on GTRY camera, Yarm is OK. If not, tweak ITMY/ETMY. alignment.
 - Mis-align AS4, align TT1, TT2, LO1 to have BHDC_A_OUT of ~115 and BHDC_B_OUT of ~95.
 - Align PR3, PR2 to maximize TRY_OUT to ~1.0
 - Tweak ITMY/ETMY if the beam spot on them are not good.
 - Align BS, ITMX to have good MICH fringe and TRX_OUT to ~1.0.
 - Tweak ITMX/ETMX if the beam spot on them are not good.
 - Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs. From Sitemap --> BHD --> Homodyne Phase Ctrl --> LO_PHASE --> Turn ON LO Phase Servo (This will lock LO and ITMX fringe) --> align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6 for YAW, with ratio of AS4/SR2= 4.5 for PITCH to have BHDC_A_OUT ~ 50.
 - Restore ITMY alignment, and lock MICH.

  17276   Thu Nov 17 09:06:35 2022 JCSummaryGeneralLight Replace

Electrical Shop came in today to replace the lightbulbs around 40m. I supervised the entire visit, inside and outside the lab area. I was sure to use the ladders which were already inside the lab area. Although, while I was crawling under the MC beam tube, I came up too quickly and bumped it. This may have caused MC to become misaligned. Anyways, Yehonathan and I are realigning now.

 

  17275   Thu Nov 17 07:39:01 2022 JCConfigurationCamerasITMX Camera

Coming in this morning, I found ITMX Camera malfunctioning.

  17274   Wed Nov 16 18:41:17 2022 yutaSummaryBHDOptical gain calibrations for BHD MICH

Optical gains of AS55 and BH55 are calibrated for BHD MICH.

LO-ITM single bounce:
 With LO-ITM signle bounce fringe, optical gain of BH55_Q is measured using a method similar to MICH calibration in AS55 (40m/16929).
 Demodulation phase for BH55 is tuned to minimize I when LO-ITM is freeswinging (using getPhaseAngle.py).
 (Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/BHDOpticalGainCalibration.ipynb)
 Results are the following:

 LO-ITMY fringe: 7.84e9 counts/m (demod phase 147.1 +/- 0.3 deg) See Attachment #1
 LO-ITMX fringe: 8.44e9 counts/m (demod phase 149.6 +/- 0.4 deg) See Attachment #1

 Difference in the optimal demodulation phase 2.5 +/- 0.5 deg agrees with half of Schnupp asymmetry, as expected (40m/17007).
 Difference in the optical gain for LO-ITMY and LO-ITMX is probably from statistical fluctuation.


BHD MICH:
 Sensing matrix was measured by injecting a line at BS (300 counts @ 211.1 Hz), LO1 (5000 counts @ 287.1 Hz) and AS1 (5000 counts @ 281.79 Hz), when MICH is locked with AS55_Q and LO PHASE is locked with BH55_Q (both with no offset).
 Using the sensing matrix, demodulation phase was tuned to minimize I phase for MICH signal in AS55 and LO1 signal in BH55.
 After the demodulation phase tuning. sensing matrix was measured to be the following.
 See, also Attachment #3 for injected peaks. I phase signal is successfully suppressed by at least an order of magnitude.
 (Notebook: /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/MeasureSensMatBHD.ipynb)

Sensing Matrix with the following demodulation phases (counts/counts)
{'AS55': -160.15695076011946, 'BH55': 154.13916838400047}
      Sensors           MICH @211.1 Hz          LO1 @287.1 Hz            AS1 @281.79 Hz           
C1:LSC-AS55_I_ERR_DQ    1.22e-05 (120.53 deg)   7.24e-07 (85.64 deg)     1.26e-06 (40.42 deg)    
C1:LSC-AS55_Q_ERR_DQ    2.95e-03 (-101.62 deg)  1.24e-06 (-80.43 deg)    1.69e-06 (152.31 deg)    
C1:LSC-BH55_I_ERR_DQ    1.28e-03 (80.95 deg)    3.44e-06 (109.31 deg)    2.22e-06 (154.40 deg)    
C1:LSC-BH55_Q_ERR_DQ    7.44e-03 (77.38 deg)    2.56e-04 (-59.85 deg)    2.42e-04 (6.40 deg)    
C1:HPC-BHDC_DIFF_OUT    2.21e-03 (82.45 deg)    4.37e-05 (121.87 deg)    3.61e-05 (-169.09 deg)

 Using BS actuation efficiency of 26.08e-9 /f^2 m/counts (40m/16929), optical gain for AS55_Q and BHDC_DIFF for MICH is

2.95e-03 / (26.08e-9/(211.1**2)) = 5.04e9 counts/m (AS55_Q for MICH)
2.21e-03 / (26.08e-9/(211.1**2)) = 3.78e9 counts/m (BHDC_DIFF for MICH)

 For AS55_Q, this is a factor of 4~5 higher than the previous measurement from free swing (40m/16929). Why?
 Free swing measurement was done again, and this gave 1.24e9 counts/m, which is consistent with the previous measurement (see Attachment #3).

 Using LO1 and AS1 actuation efficiencies of 3.14e-8 /f^2 m/counts (40m/17206), optical gains for BH55_Q for LO1 and AS1 are

2.56e-04 / (3.14e-8/(287.1**2)) = 6.72e8 counts/m (BH55_Q for LO1)
2.42e-04 / (3.14e-8/(281.79**2)) = 6.12e8 counts/m (BH55_Q for AS1)

Next:
 - Compare them with expected values
 - Measure them with different locking points (different LO phases, MICH offsets)
 - Investigate why MICH optical gain in AS55 is 4~5 times higher than free swing measurement (use different modulation frequency?)

Summary of actuation calibration so far (counts from C1:LSC-xx_EXC or C1:SUS-xx_LSC_EXC):
BS   : 26.08e-9 /f^2 m/counts (see 40m/16929)
ITMX :  5.29e-9 /f^2 m/counts (see
40m/16929)
ITMY :  4.74e-9 /f^2 m/counts (see
40m/16929)
ETMX : 10.91e-9 /f^2 m/counts (see 40m/16977 and 40m/17014)
ETMY : 10.91e-9 /f^2 m/counts (see 40m/16977)

MC2 : -14.17e-9 /f^2 m/counts in arm length (see 40m/16978)
MC2 :   5.06e-9 /f^2 m/counts in IMC length (see 40m/16978)
LO1 : 3.14e-8 / f^2 m/counts
(see 40m/17206)
LO2 : 2.52e-8 / f^2 m/counts (see 40m/17206)
AS1 : 3.14e-8 / f^2 m/counts (see 40m/17206)
AS4 : 2.38e-8 / f^2 m/counts (see 40m/17206)

  17273   Wed Nov 16 15:09:08 2022 yutaUpdateBHDBHD fringe contrast measured with unwhitening filters

BHD fringe visibility was measured again with unwhitening filters on on BHDC_A and B, which removed signal leakage to zero (40m/17265).
The result didn't change much from previous measurement (40m/17067) thanks to using the 'mode' of signal to calculate visibility.
Measured constrast of 74% indicate mode-matching AS beam to LO beam of 56%.

ITMX-LO fringe (10% percentile)
Contrast measured by C1:HPC-BHDC_A_OUT is 74.46 +/- 0.07 %
Contrast measured by C1:HPC-BHDC_B_OUT is 74.25 +/- 0.07 %
Contrast measured by all is 74.35 +/- 0.07 %

ITMY-LO fringe (10% percentile)
Contrast measured by C1:HPC-BHDC_A_OUT is 74.01 +/- 0.10 %
Contrast measured by C1:HPC-BHDC_B_OUT is 73.85 +/- 0.09 %
Contrast measured by all is 73.93 +/- 0.08 %

Errors are from standard deviation of 3 measurements.
The notebook lives in /opt/rtcds/caltech/c1/Git/40m/scripts/CAL/BHD/measureContrast.ipynb

  17272   Wed Nov 16 12:53:36 2022 ranaUpdateASCIMC WFS ongoing

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

  17271   Wed Nov 16 11:56:21 2022 RadhikaUpdatePSLPMC input beam aligned again, IMC

[Yuta, JC, Radhika]

PMC input beam was aligned again, bringing transmission from 0.70 to ~0.75. To avoid blocking the PMC refl beam, I found success handling the yaw knob of the first steering mirror from below.

  17270   Tue Nov 15 19:00:56 2022 yutaSummaryBHDMICH locked with balanced homodyne readout at some LO phase

[Paco, Yuta]

MICH was locked with BHD DCPD A-B signal with LO phase controlled.
Locking procedure and configuration was as follows (see Attachment #1).

1. Lock MICH with AS55_Q, with C1:LSC-MICH_GAIN=-3, FM4, FM5, FM8, FM10 (boost filters are turned off to have more phase margin).

2. Lock LO PHASE with BH55_Q, with C1:HPC-LO_PHASE_GAIN=6, FM5, FM8, feeding back to AS1.
  - C1:LSC-BH55_PHASE_R=136.136 deg was tuned to minimize I when AS-LO is fringing with MICH locked with an offset of 50 (we first thought 136.136 deg - 90 deg is better from 40m/17216, but today, 136.136 deg seems to work better; Reason needs to be investigated).
  - We are supposed to use C1:HPC-BH55_Q_AS1_DEMOD_I_OUT to control the LO phase to give maximum MICH signal on BHD_DIFF (40m/17170), but somehow BH55_Q without audio dither was OK to get MICH signal. Line injection at 211.1 Hz on BS was seen in BHDC_DIFF (and AS55_Q), even if we use BH55_Q to lock LO PHASE (see Attachment #2; MICH_B is BHDC_DIFF and MICH_A is AS55_Q) or BH55_Q_AS1_DEMOD_I to lock LO PHASE (with both signs). Reason needs to be investigated.
  - Audio dither was done using AS1 with excitation of 15000 counts at 281.79 Hz. C1:HPC-BH55_Q_AS1_DEMOD_PHASE=60 deg was tuned to minimize Q with injection of line at 13 Hz using LO1.

3. Handed over MICH lock from AS55_Q to 0.66 * C1:LSC-DCPD_A - 1 * C1:LSC-DCPD_B. This was done by using C1:LSC-MICH_A and MICH_B gains. C1:LSC-MICH_A_GAIN=1 was handed over to C1:LSC-MICH_B_GAIN=-1.
  - 0.66 * A - B was tuned so that BHDC_DIFF will be zero (as it supposed to be with MICH offset of zero).
  - AS55_Q and BHDC_DIFF had roughly the same optical gain at 211.1 Hz (actually, BHDC_DIFF had higher optical gain; see Attachment #2), so we used MICH_A_GAIN=1 and C1:LSC-MICH_B_GAIN=-1
  - After handing over of BHDC_DIFF, OLTF was measured. UGF was ~70 Hz (Attachment #3).

Next:
  - Investigate how to get optimal LO phase. With BH55_Q or BH55_Q + audio dithering? How to optimize demod phases?
  - How do we balance DCPD A and B? What is the effect of BHD BS being 44:56 not 50:50?
  - Measure amount of MICH signal in BHDC_DIFF with different LO phases.
  - Improve SNR in BH55.
  - It will be much simpler if we send BHDC_SUM and BHDC_DIFF to c1lsc from c1hpc, instead of sending un-unwhitened BHDC_A and B.

  17269   Tue Nov 15 17:58:00 2022 PacoConfigurationCamerasPOP camera realignment after IFO alignment

[Paco, Yuta]

I swapped the 1 inch BS and lenses along the POP beam to clear the apertures and avoid clipping this beam. The results are illustrated by the attached pictures; this was done right after Yuta had optimized IFO alignment so it's hopefully a good reference from now on. Yuta also tuned the alignment of BHDC path in ITMY table, which mostly improved the alignment to DCPD A (90-ish counts improved to 100-ish counts with ITMY single bounce).

  17268   Tue Nov 15 17:08:59 2022 PacoUpdateBHDRequest for estimates

[Yehonathan, Yuta, Paco]

We would like to estimate:

  • LO phase sensitivty (for RF55 + audio dither scheme), as a function of RF demod angle (both I and Q); not to be confused with audio dither angle.
  • LO phase sensitivity (for all schemes like in Attachment #2 of this previous post) but with some nonzero MICH offset.
  • LO phase sensitivity (for RF55 + audio dither scheme) but with the uBHDBS (44:56) values from this post.
  17267   Tue Nov 15 16:34:55 2022 alexUpdateGeneralDebian with Sensoray

I have confirmed the ability to install the sensoray drivers on Debian 11 in a virtual machine environment. I will do testing with the sensoray device on this tomorrow and if all works, begin working on code for capturing images. I will then test this out on Donatella once Tega finishes installing Debian across all computers in the coming week or so. 

  17266   Tue Nov 15 11:04:01 2022 PacoSummaryCalibrationSingle arm cal with 5 lines

YALS Hardware inspection

The ALS Cal for ITMY actuation was off by ~ 1000, so I decided I don't trust / understand what this beatnote is seeing. Then, I went in the lab to inspect things;

  1. ALS DFD and DEMOD: The demod box was off no perhaps on purpose, more likely by accident... the switch was off in the rear of the 1U box in the LSC rack... Also, the DB9 cable labeled ALS was disconnected. Fixed both these bugs and verified it worked all the way into cds.
  2. YARM Green injection: Did some re-alignment, and noted the mode was hopping a bit too much (once every couple of seconds) so I rotated the half waveplate before the green PZT steering mirrors by  ~ 8 deg and used the latter to get a GTRY transmission of > 0.320 (counts), about 75% more than last time. Finally I made sure the mode is robustly locked for several minutes.

Beatnote calibration

The factor above may be explained by the bogus signals coming into the beat fine phase channels on the ALS model. After locking the YARM with POY11, and locking the YAUX to the YARM cavity, I turned on the LSC oscillators -- all five of them see Attachment #1 for the screenshot -- and looked for the lines in the C1:ALS-BEATY_FINE_PHASE_OUT channel. Here, again the sensing output matrix was set up to actuate on ITMY, while the ETMY (control point of YARM loop) had all the output notches on. Once all lines were visible in the YAUX beatnote, I had to reduce the LSC filter gain from 0.012 to 0.011 to prevent loop oscillations... Then I recorded the gpstimes below with different conditions.

  • HEPA ON (JC Inside lab)
    • gpstime = 1352575798 to 1352576046
  • HEPA OFF (JC Inside lab)
    • gpstime = 1352576125 to 1352576216
  • HEPA OFF (JC in the control room)
    • gpstime = 1352576641 to 1352577591

Analysis

Basically, only the DARM line was recorded (DQ channs) so I modified the c1cal to store the SIG_OUT and DEMOD_I_IN1 channels for both BEATX and BEATY cal signals. This means I need to repeat this measurement. In the meantime I am also going to try and rerun calibrate the BEAT HZ transfer function.

  17265   Mon Nov 14 17:45:02 2022 yutaUpdateBHDBHD DC PD unwhitening and removing cables to c1lsc

[Paco, Yuta]

We removed splitter to route BHD DC PD signals to c1hpc and c1lsc. This was necessary to circumvent IPC error, but this is no longer necessary. Now BHD DC PD signals are ADC-ed with c1hpc, and sent to c1lsc via IPC.
We also found that BHD DC PD signals have whitening filters as described in LIGO-T2000500 (Readout board is LIGO-D1400384).
We added unwhitening filter zpk([151.9;3388],[13.81],1,"n") to C1:HPC_BHDC_A and B, based on measured whitening stage gain (see Sec 3.1 of characterization reoprt in LIGO-T2000500).
This solved the signals leaking to minus (40m/17068).

Next:
 - Modify c1hpc model to send BHD DCPD signals to c1lsc after unwhitening. (Note added on Nov 15: The same unwhitening filter is also added to C1:LSC-DCPD_A and B for now. See attached.)
 - Redo visibility measurements,

  17264   Mon Nov 14 14:52:56 2022 PacoConfigurationSUSBHD SUS Coil output balance

[JC, Paco]

We installed a steering mirror intersecting the BHD beam path and put the AS beam on the ITMY Oplev QPD (see Attachment #1 for a photo of this temporary hack) . This is done to do coil balancing of AS1/AS4, LO1/LO2. QPD sees ~ 10000 counts when the beam is centered.


[Paco, Yuta]

We follow this procedure -- but with different sensors for all BHD suspension coil output balancing.

AS1/AS4

We dither BUTT first, lock the LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign LO beam and look at the hijacked Oplev (ITMY) while dithering POS to minimize PIT and YAW couplings.


LO1/LO2

We dither BUTT first, lock thChangeset summarye LO-AS fringe (DC lock), and look at the residual LO_PHASE spectrum to minimize POS coupling. We then unlock, misalign AS beam and look at the hijacked Oplev (ITMY) PIT/YAW residual noise while dithering POS to minimize PIT/YAW coupling.


Changeset summary

The new coil output gains are summarized in the table below:

Optic / Coil UL UR LR LL
AS1 -0.939 1.040 -1.026 0.995
AS4 -0.9785 0.9775 -1.0695 0.9745
LO1 -0.939 1.003 -1.074 0.984
LO2 -1.051 1.342 -0.976 0.631

Finally, I reverted the hacked QPD setup to restore the ITMY OPLEV.

  17263   Sat Nov 12 21:59:24 2022 AnchalFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I stopped the Docker PID script and started the old python script on megatron. Instructions on how to do this are here.

On optimus I ran:

sudo docker stop scripts_PID_FSS_Slow_1

On megatron I ran:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

However, the daemon service keeps failing and restarting. So currently the FSSSlow is not running. I do not know how to debug this script.


On a side note, I tested the docker service by restarting it, and it was working. From the logs, it seems like it got stuck because it could not find C1:IOO-MC_LOCK channel which occurs when c1psl epics servers fail or get stuck. The blinker on this script runs when the script is running but it does not stop if the script gets stuck somewhere. If someone decides to use this script in the future, they would need to correct error catching so that no reply from caget looks like an error and the script restarts rather than keep trying to get the channel value. Or the blinker implementation should change in the script so that it displays a stuck state.

Quote:
 

 Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.

 

  17262   Fri Nov 11 20:59:13 2022 ChrisFrogsComputer Scripts / ProgramsFSS SLOW servo not running

The problem with trends was due to the epics data collection process (standalone_edc) that runs on c1sus. When all the FEs were rebooted earlier this week, this process was started automatically, but for some reason it hasn’t been doing its thing and sending epics data to the framebuilder. I restarted it just now, and it’s working again. Until this problem is sorted out, we need to remember to check on this process after rebooting c1sus.

Quote:

I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.

  17261   Fri Nov 11 20:01:56 2022 ranaFrogsComputer Scripts / ProgramsFSS SLOW servo not running

I was trying to debug why the NPRO PZT is all over the place, and it turns out that the new FSS SLOW script is not actually running.

The BLINKY is blinking, but the script is not running. I wasn't able to figure out how to kill the broken Docker thing, but if the code reports that its running but actually does not, we should probably just put back the old perl or python script that ran before. I don't know how to debug this current issue, but the IMC locks will be limited in length due to this servo being broken. Whoever knows about this, please stop that Docker PID and we can just run the old python script on megatron.

I also tried to post a trend plot, but the minute trends don't yet reach the current date (!!!). They seem to have stopped recording a few days ago, so I guess the Framebuilder still needs some help or its tough to figure out things like when exactly the new SLOW servo stopped working.

  17260   Fri Nov 11 19:47:04 2022 ranaUpdateSUSMC SUS were overdamped: damping gains all reduced

After clicking on the extra MC1 unwhitening filter, I was going to retune the damping gains to give a Q ~ 5 for the suspension. I found it was very over damped. I also checked the other MC SUS. They were all overdamped.

A Q ~ 5 means that the amplitude of the oscillation should drop by 1/e after 5 oscillations. Most of the DOFs were damping in 1-2 cycles. This is good for lock acquisition impulses, but because it ties the suspension to the frame, it reduces the seismic isolation that we get from the pendulum. So we normally want the Q to be ~4-7. Someone more clever can figure out a better local damping servo that minimizes the overall MCF and IMC WFS signals, but that is a project that takes some thought.

  17259   Fri Nov 11 19:20:23 2022 ranaUpdateSUSMC1 OSEMs output is weird

I turned on the extra un-whitening filter (not the same as dewhitening) which Anchal has installed in the XXSEN filter banks of MC1. Seems good, so I'm leaving them on.


Anchal determined that the new satellite for MC1 was whitening, and also the old one was whitening, which made the whole thing non-white. So, I turned on the FM3 filter. I then checked that the ADCs were not saturating by looking at the spectrum of the IN1 channels (before the un-whitening). They are very far from saturating, but we should trend the ADC overflows on MC1 to make sure that this is not an issue (someone besides Tega should ask Tega how to add these to the summary pages so that not only Tega can edit summary pages).

In the attached plot, we can see that the reference trace for the unwhitened MC1 (FM1 ON, FM3 OFF) (black) sensor looks noisier than the others at 16 Hz, where we expect the suspensions to be mostly the same. This is because the analog whitening (amplification) was not being compensated properly. With FM1 and FM3 ON (RED) we can see that the spectra line up nicely below 20 Hz. Above 20 Hz the MC1 sensor is quieter than the others because the ADC noise is being reduced more.

Clearly, the other sensors could use some more whitening. If we find a reason to need lower damping noise in the future, let's remember this elog and remember that we ought to do proper signal conditioning on all our OSEMs. For now, probably doesn't matter.

  17258   Fri Nov 11 19:11:50 2022 JCUpdateGeneralWFS Whitening and Demod Boards

WFS Whitening and Demod boards were scavenged. ' iLIGO WFS cards are in big plastic boxes placed on the north wall around Section Y5 or Y6 (not under the arm). The WFS head PCBs, empty WFS housing, WFS components, I/Q demod components are at SectionY10 under the arm tube. ' - Koji . I have taken pictures of the boards and will upload them to the DCC once I find a way to add a Serial Number . (I will upload this to the eLog as a HowTo) The next step is to search for at least 2 extender boards to troubleshoot these board and find if there are any issues. We may have replace some components and retune the boards. Attachment #1 is an example of the WFS Whitening Filter and Attachment #2 is and example of the the WFS Demod Board.

If you use the Camera DO NOT remove the strap. I have also purchased lens caps for the camera, so after usage PUT THE LENS CAP BACK ON. 

  17257   Fri Nov 11 14:15:45 2022 PacoSummaryCalibrationSingle arm cal with 5 lines

I turned all the LSC oscillators on and used the digital demod for BEATYF (fine y als beat) to grab the data. For this I added notches onto SCY ETMY LSC filter banks FM6-10 to account for these lines at 30.92, 211.10, 313.31, 315.17 Hz (basically just reusing the osc models) and adjusted the sensing matrix to actuate on ITMY.

I aligned and locked YARM, and then I aligned and locked the YAUX. The lock seems pretty robust with an avg green transmission GTRY ~ 0.185 counts for TEM00.


Trying to see other lines appear on the BEATYF demod channels, but so far no luck. I scaled down the exc gain from 500 counts (snr ~ 20 at 575 Hz) and verified the notches are working. Since I am unsure of the issue here and WFS tests are happening at 4 today, I decided to take some beat data under different conditions -->

HEPA OFF and PSL Shutter Open

gpstime start = 1352244763 gpstime end = 1352245405

HEPA OFF and

PSL Shutter Closed

gpstime start = 1352245574

gpstime end = 1352246216

HEPA ON and

PSL Shutter Closed

gpstime start = 1352246240 gpstime end = 1352246882
  17256   Fri Nov 11 11:29:11 2022 AnchalUpdateSUSMC1 OSEMs output is weird

Late elog; original time Thursday, Nov 10 16:00 2022

MC1 is using a new satellite amplifier which was a whitening circuit on it with 3 Hz zero and 30 Hz pole. But to read out this signal, we use the old whitening board as it serves as the interface board with the ADC too. This is D000210 Whitening and Interface Board. This board has a switchable whitening filter which our RTS models supply GND as the switch input. It was not immediately clear to me if the GND input to this switch means whitening is ON or not.

I disconnected inputs and outputs to the whitening Board used for MC1 OSEM PDs, and I used a moku:go to measure the transfer function for the UR channel. This confirmed that whitening is turned ON on this interface board as well, which means the MC1 OSEM signals are whitened twice, while digitally we have been dewhitening only once. To fix this there are two possible solutions:

  • We turn on another identical dewhitening filter in MC1 OSEM input filter modules (a 3:30 at FM3)
  • We can change the MC1 Simulink model to stop keeping whitening on by default.
  17255   Thu Nov 10 20:46:32 2022 ranaUpdateASCIMC WFS servo diagnosis

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

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

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

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

  17254   Thu Nov 10 18:09:28 2022 ranaUpdateSUSMC WFS settings all weird

Today I found the MC WFS settings all weird. Not only was the input slider set to zero, but the filter bank outputs were off, and also the ON/OFF buttons after the output matrix.

I think we may have been hacked, because there was not mention of this settings change in the ELOG, even though we have this scary red sign.

I am now trying to recover things as best as I can, but I'm not sure exactly which settings the hacker changed. Stay tuned...

  17253   Thu Nov 10 17:40:31 2022 PacoSummaryCalibrationCalibration Plan

Plan to calibrate single arm actuation strength

  1. Lock single arm cavity (e.g. YARM)
  2. Lock YAUX laser to arm cavity (actuation point is ETMY)
  3. With the notch on the YARM loop filter (actually on ETMY),
  4. Turn on cal line (e.g. DARM osc) to move ITMY; here the frequency is chosen to be away from 600 Hz (line harmonic) and from violin modes for ITMY (642 Hz). The lower value of 575.17 Hz was chosen to avoid demodulating noise peaks at 455 Hz and 700 Hz.
  5. Get raw YALS beatnote (we chose the demod angle of -35 deg to minimize Q).

The analysis is as follows:

  1. Get demodulated IQ timeseries for the duration of the locks before lowpass filter (C1:CAL-SENSMAT_DARM_BEATYF_I_DEMOD_I_IN1); we are also storing the raw beatnote if we want to do software demodulation.
  2. Look at the allan deviation of I and Q to establish the timescale over which our measurement is dominated by statistical uncertainty -- after this time, the uncertainty is expected to be due to systematic error / drift. In this case as shown by Attachment #1 the time is around 60.6 seconds.
  3. At this frequency and with 500 gain the ITMY coils should be actuating 7.32 pm of amplitude displacement.
  4. The minimum allan deviation does indeed predict the statistical uncertainty limited rms if we look at the power spectra of the demodulated cal line over different time periods (Attachment #2), notice I lowpassed the raw timeseries.
  5. I think the next step is to get the nominal calibration value and repeat the measurment for more than a single cal line.
  6. Roughly from the deviation plot, our fractional beatnote deviation is a proxy for the calibration uncertainty. 1.15e-16 of beatnote stability should translate to a fractional displacement stability of ~4.57e-15 at 60 seconds; giving an ultimate statistical calibration uncertainty of 0.06% at this particular frequency when averaging for this long. It might be interesting to see a calibration frequency dependent allan deviation plot.
  17252   Wed Nov 9 20:29:20 2022 AnchalUpdateSUSMC2 and MC3 set to undergo free swing test tonight

I have set a free swing test for MC2 and MC3 to trigger at 1 am tonight. The test should last for about 4.5 hrs upto 5:30 am. It will close the PSL shutter, perform the test, and open the shutter afterwards. To cancel or interrupt the test, go to rossa and do:

tmux a -t FST
ctrl+c
exit

 

  17251   Wed Nov 9 20:01:38 2022 AnchalUpdateSUSMC1 OSEMs output is weird

I took a coil to OSEM transfer function for MC1 osems  (LL, UR) today and again the slope of the transfer function was -1.4 instead of -2 as expected. I compared this with MC3 coil to osem transfer function (LL) which correctly had the slope of -2. See attachments 1 and 2 for the results. This measurement was taken with PSL shutter closed and local damping loops turned off.

As I mentioned earlier, MC1 is using new satellite amplifier box (S2100029-v2) whose transfer function data exists and was actually measured by me in 40m/15776. Using this transfer function data, and the foton 3:30 (FM1) filter, I tried to recreate the product transfer function that should happen if both filters are working correctly. Attachment 3 shows these transfer function plots. I overlayed on top of this the measured transfer function of OSEM to position displacement as done in 40m/17238 by making the magnitude equal at 1 Hz. It is suspicious how nicely the measured transfer function overlay with the satellite amplifier measured transfer function, both in magnitude and phase. I'll investigate more tomorrow.

 

  17250   Wed Nov 9 14:19:18 2022 TegaUpdateCDSfb1 OS migration

[Tega, Chris]

We migrated fb1 OS from the teststand fb1 drive to the internal 2TB RAID of fb1. We then rebooted twice to check that we no longer have the fb1 booting issue. 

The next step is to set up software RAID and backup for chiara, which we plan to complete this week. Then we would work on nodus and workstation OS upgrade next week.

  17249   Wed Nov 9 11:07:16 2022 AnchalUpdateSUSIMC test

Following configurations were kept today morning:

Start Time Stop Time HEPA PSL Shutter WFS Loops

1352046006

08:19:48 PST
16:19:48 UTC

1352050278

09:31:00 PST
17:31:00 UTC

OFF OPEN OFF

1352050393

09:32:55 PST
17:32:55 UTC

1352054538

10:40:00 PST
18:40:00 UTC

OFF OPEN ON

1352054537

10:41:59 PST
18:41:59 UTC

1352058724

11:51:46 PST
19:51:46

OFF CLOSED OFF

f2a filters with Q=10 (FM3) were turned on all IMC optics.

  17248   Wed Nov 9 07:49:59 2022 ranaUpdateSUSMC2 OSEMs calibrated using MC_F

It would be good if you can post the uncertainties with these measurements (and for generally any measurements). This is so that we can propagate that uncertainty later for other measurements. From your entry, it looks like there are something like 7 digits of precision, which would be astounding.

I suggest that we adopt the convention of reporting Uncertainty properly by number of significant figures and the parantheses notation.

  17247   Tue Nov 8 21:39:12 2022 alexSummaryGeneralSensoray & SDI Video Encoder selection

I have been looking at various replacements for the sensoray, and have found that the majority of new usb video encoders don't have drivers anymore and now just work through being embedded with video-capturing software. This means that the hardware must be used with a compatible video player such as VLC or OBS. VLC can natively be run with terminal commands, and because OBS is open source, there are packages that can be downloaded to use terminal commands to control the software as well. I am not sure to what extent the usb video encoder can then be controlled with these commands, but this seems to be the easiest method so far. I will finish picking which new unit we should purchase tomorrow, and order it through JC. 

  17246   Tue Nov 8 19:39:34 2022 AnchalUpdateSUSMC3 OSEMs calibrated using MC_F

I did the same measurement for MC3 with one difference that OSEMs report \sqrt{2} more motion than IMC cavity length change due to it being at 45 degrees. Following are the new cts2um gain values

  • UL 0.36 -> 0.39827(0.00045)
  • UR 0.36 -> 0.33716(0.00038)
  • LL 0.36  -> 0.34469(0.00039)
  • LR 0.36 -> 0.33500(0.00038)

 

  17245   Tue Nov 8 18:12:01 2022 AnchalUpdateSUSMC2 OSEMs calibrated using MC_F

I reran this measurement at low frequency 0.1016 Hz. Following were the cts2um gain changes:

  • UL 0.28510 -> 0.30408(0.00038)
  • UR 0.26662 -> 0.28178(0.00027)
  • LL 0.34861  -> 0.38489(0.00049)
  • LR 0.71575 -> 0.80396(0.00681)

Edited AG: Wed Nov 9 12:17:12 2022 : Uncertainties added by taking coherence of each channel and MC_F with excitation, using \sqrt{\frac{1-\gamma}{2 \gamma n_{avg}}} to get fractional error in ASD values I used for taking ratios(where \gammais coherence and n_{avg} is number of averages (5 in this case)), and adding MC_F ASD frac error to all sensor's frac error, and finally multiplyingit witht he ratios obtained above to get error in cts2um gain values.

RXA: I don't believe it. This is more accurate than the LIGO calibration of strain and also more accurate than the NIST calibration of laser power.

 

  17244   Tue Nov 8 16:56:33 2022 ranaUpdateAUXAUX PZT transfer function fitting + filtering

This looks really good to me. Rather than fully invert the plant, what we would like to do is now design a filter which allow this loop to have a high UGF and a high gain below 1 kHz. Anchal and Paco probably have gain requirements for this loop in the ALS-CAL paper they are writing. The loop would have the cavity transfer function, as well as the demod electronics for the green PDH loop.

In addition to the gain requirements, we would also like to have a phase margin > 30 deg, and a gain margin of > 10 dB.

 

  17243   Tue Nov 8 11:18:39 2022 RadhikaUpdateAUXAUX PZT transfer function fitting + filtering

Here I describe efforts to cancel the AUX laser PZT mechanical resonances from ~200 kHz-400kHz. While these may not be the resonances we end up wanting to suppress, I chose this region as an exercise because it contains the most significant peaks.

The PZT transfer measurement was taken on 09/06 by myself and Anchal. The Moku:Go outputted a swept-sine (1kHz - 1MHz) I sent to the AUX laser PZT. The beat note between the AUX and frequency-doubled PSL was sent to the DFD, and the I and Q channels were routed back as input to the Moku:Go. We also took a calibration transfer function of the Moku:Go, sending output 1 to inputs 1 and 2. 

Almost all of the signal was present in the I channel, so I proceeded to use the I data for fitting/next steps. After normalizing the measured frequency response by the calibration measurement (and adjusting for the calculated time delays in the loop - see [17131]), I fit the resulting data using vectfit [Attachment 1]. I supplied the function with n_poles=16, which in reality fit for 16 complex pairs of poles. This complexity of fit was not necessary to capture the 3 prominent peaks, but would likely be needed to fit any of the more heavily-damped resonances. 

I chose to invert all fitted poles between 200 kHz and 367 kHz and the corresponding fitted zeros. The result of this filter applied to the original frequency response data can be seen in Attachment 2, where the blue-shaded region contains the inverted poles/zeros. In total, 9 pairs of poles and 9 pairs of zeros were inverted. 

Next steps:

- Determine which resonances we want to suppress
- Send filter coefficients to Moku:Go (write scripts to streamline)
- Set up Moku:Go in series in loop; take TF measurement
  17242   Tue Nov 8 10:35:26 2022 AnchalUpdateSUSIMC F2A test

This time the test was succesful but I have reverted MC3 f2a filters back to with Q=3, 7, and 10. The inital part of the test is still useful though. I'm attaching amplitude spectral density curves for WFS control points and C1:IOO-MC_F_DQ in the different configurations. The shaded region is the 15.865 percentile to 84.135 percentile bounds of the PSD data. This corresponds to +/- 1 sigma percentiles for a gaussian variable. Also note that in each decade of freqeuncy, the FFt bin width is different such that each decade has 90 points (eg 0.1 Hz bin width for 1Hz to 10 Hz data, 1 Hz binwidth  for 10 Hz to 100 Hz and so on.)

The WFS control points do not show any significant difference in most of the frequency band. The differences below 10 mHz are not averaged enough as this was 30min data segments only.

C1:IOO-MC_F_DQ channel also show no significant difference in 0.1 Hz to 20 Hz. Between 20-100 Hz, we see that higher Q filters resulted in slightly less noise but the effect of the filters in this frequency band should be nothing, so this could be just coincidence or maybe the system behaves better with hgiher Q filters. In teh lower frequency band, we would should take more data to average more after shortlisting on some of these f2a filters. It seems like MC1 Q=10 (red curve) filter performs very good. For MC2, there is no clear sign. I'm not sure why MC2 Q=3 curve got a big offset in low frequency region. Such things normally happen due to significant linear trend presence in signal.

I'm not sure what other channels might be interesting to look at. Some input would be helpful.

  17241   Tue Nov 8 10:23:42 2022 AnchalUpdateSUSMC3 damping loop step responses

I tuned MC3 local damping gains by looking at step responses in the DOF bassis. The same procedure was followed as described in 40m/17133. The gains were changed as following:

  Old Gains New Gains
C1:SUS-MC3_SUSPOS_GAIN 100 200
C1:SUS-MC3_SUSPIT_GAIN 24 10
C1:SUS-MC3_SUSYAW_GAIN 8 30
C1:SUS-MC3_SUSSIDE_GAIN 125 75

Attachement 1 shows the step responsed with the old gains and attachment 2 shows the step responses with the new gains. There is considerable cross coupling between SIDE OSEM and Coil to the face DOFs (POS, PIT, YAW). I think the high SIDE gain earlier was the culprit that started ringing with the f2a filters.

I agree that POS and SIDE step responses could look better but this was the best I was able to achieve. Further attempts by others is most welcome.

I also verified running f2a filter with Q=3 and it has been stably running with no ringing for past few minutes. More long term behavior is yet to be seen.C1:SUS-MC3_SUSSIDE_GAIN

  17240   Tue Nov 8 08:57:18 2022 ranaUpdateSUSMC2 OSEMs calibrated using MC_F

this measurement is not valid because of the coil to sensor coupling that I mentioned before. This is why I suggested you make the measurement at low frequencies (like 0.1 Hz).

Quote:

MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC.

  17239   Mon Nov 7 21:57:42 2022 alexUpdateGeneralSensoray

I have made little progress in getting the sensoray driver installed on Donatella. I have confirmed that it is indeed the reason why none of the hardware is working. I am now working through changes on a virtual machine that is running Scientific Linux to find something that may work. If no progress is made soon, I will ensure that software for a replacement video encoder is able to be installed before requesting we order one.

  17238   Mon Nov 7 20:00:37 2022 AnchalUpdateSUSMC1 OSEMs output is weird

Following up, I tried to do this exercise with MC1 and MC3. While MC3 shows expected minute corrections to the previous value, MC1 showed much alrger corrections which led me to investigate further. Koji suggested to take a transfer function between MC_F and the OSEM outputs for both MC1 and MC3 the same way to see if something is different. And Koji was absolutely right. MC1 MC_F to OSEM outptu transfer function has a frequency dependent value, with a slope of ~0.6. Very weird. I'm holding on to doing OSEM calibration on both MC1 and MC3 until we know better on what is happening. See attached transfer functions.

Reminder, MC1 is using new satellite amplifier box, but OSEM outputs are read through single ended PDMon outputs rather than the differential ended PD Output port, because rest of the MC1 electronics is still last generation and the whitening board for them take in single ended input.

  17237   Mon Nov 7 19:53:12 2022 AnchalUpdateSUSMC2 OSEMs calibrated using MC_F

MC2 OSEM outputs were calibrated today using MC_F to get the output values in microns. This was done using this diaggui file. We drive a sine wave at 13 Hz and 5000 cts at C1:SUS-MC1_BIASPOS_EXC. This signal is read at C1:IOO-MC_F and the C1:SUS-MC1_ULSEN_OUT and similar OSEM output channels. MC_F calibration in Hz is assumed to be correct. In diaggui, a calibration conversion of 4.8075e-14 m/Hz is added to convert MC_F signal into meters. This is then used to calibrate the OSEM outputs and necessary gain changes were done in teh cts2um filter module in all of the face OSEM input filters. Following are the new gains:

  • UL 0.36 -> 0.28510
  • UR 0.36 -> 0.26662
  • LL 0.36 -> 0.34861
  • LR 0.36 -> 0.71575

Note that this measurement was done after the coil strengths for MC2 have been balanced in 40m/17223.

  17236   Mon Nov 7 17:10:41 2022 AnchalSummaryBHDQPD installation seems like lost cause

The new QPD installation is turning out to be much more hard than it originally seemed. After finsing the cable, QPD and interface board, when I tried to use the cable, it seems like it is not powered or connected to the interface board at all. I tried both QPD ports on the QPD interface board (D990692) both none worked. I measured the output pins of IDC style connector on the interface board and they seem to have the correct voltages at the correct pins. But when I connect this to our cable and go to the other side of the cable which is a DB25, use a breakout board and see for the voltages, I see nothing. The even pins which are supposed to be connected to each other and to GND are also not connected to each other. I pulled out teh DB25 end of the cable and brought it close to the IDC end to do a direct conitnuity test and this test failed too.

I even foudn another IDC end of a spare QPD cable hanging near 1Y2, but could not find the other end of this cable either.

So moving forward, we have following options:

  • Assume the cable is bad and try to find another cable.
    • It is very hard to find these cables in the lab. Koji and I have already done one sweep.
  • Source 26 pin 2 row IDC female connector and make a ribbon cable ourselves.
    • We probably will need to buy this connector for this to work.
    • Downs has apparantely thrown away all IDC connectors.
  • Use clean room QPD that does not use this interface.
    • The QPD used in clean room tests for suspension hanging used a different board.
    • This board is just lying on the floor, mounted on one slot of a big 6U chassis.
  • Use AS WFS
    • If used in current position, it would not be useful for BHD port or tuning LO1, LO2, and AS4.
    • If taken to ITMY oplev table, we will need to source LO and opther connections right at the PD head as that is design for these PDs.
  • Use GigE camera
    • We can replace the analog camera with a GigE camera on the BHD output.
    • We will need to revide GigE camera code and medm screens for this, and run an ethernet cable to ITMY oplev table.
  • Someone verify that the cable is indeed not working as I am seeing above. If I am wrong, I would be a happier person.
  17235   Mon Nov 7 16:14:43 2022 AnchalUpdateSUSF2A filter with Q=1, 0.3 stable with MC3

I tired running for a few hours F2A filter with Q=1 and for maybe 30 min Q=0.3 on MC3 today and that keeps the suspension stable. So I'm going to put in Q=0.3 at FM1, Q=0.7 at FM2, and Q=1 filter on FM3. I am setting the test again for tonight with some modifications. Now the separate set of filters will be tried one by one on the three different optics so that we know the best Q filter for each optic. It is set to trigger at 1 am tonight in tmux sessions f2aMC1Test, f2aMC2Test, f2aMC3Test on rossa. To cancel the test or interrupt, do:

tmux a -t f2aMC1Test
ctrl+C
exit
tmux a -t f2aMC2Test
ctrl+C
exit
tmux a -t f2aMC3Test
ctrl+C
exit
  17234   Mon Nov 7 14:38:59 2022 AnchalUpdateSUSMC3 coil strengths rebalanced

I checked again today by sending excitation at POS and reading back from C1:IOO-MC_TRANS_P and C1:IOO-MC_TRANS_Y. I found that there was some POS->PIT and POS->YAW coupling remaining that I was to remove by same method. New coil gains are:

C1:SUS-MC3_ULCOIL_GAIN: 0.942
C1:SUS-MC3_URCOIL_GAIN: -1.042
C1:SUS-MC3_LRCOIL_GAIN: 1.076
C1:SUS-MC3_LLCOIL_GAIN: -0.94

 

  17233   Mon Nov 7 12:37:26 2022 KojiUpdateGeneralBorrowed the fiber tester for the OMC lab

I am borrowing the fiber illuminator / fiber tester / VisiFault for the OMC lab. It has been stored in the top drawer at the center work bench.

==> Returned

ELOG V3.1.3-