40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 2 of 346  Not logged in ELOG logo
ID Date Author Type Category Subject
  17404   Thu Jan 19 14:58:40 2023 ranaSummaryBHDIQ demod orthogonal

the problems with these circle plots:

  1. you have to make the aspect ratio of the PDF correct or else it doesn't look like a circle
  2. what we care about is the deviation from circle, so you should plot the difference in a way that let's us see the difference, not just that it sort of looks like a circle. This is similar to how we plot the residual when doing fits.
  17403   Thu Jan 19 12:12:09 2023 AnchalSummaryBHDIQ demod orthogonal

By sending two frequencies offset from eachother to LO input and RF input, we measured the remaining phase difference between I and Q outputs of this demod board and correct that by setting C1:LSC-BH44_PHASE_D to 86.2 degrees and balancing the amplitudes by putting C1:LSC-BH44_Q_GAIN to 1.747. See attached for XYPlot after correction.

  17402   Wed Jan 18 20:57:53 2023 PacoSummaryBHDIQ demod orthogonal

I tested a spare IQ demod board labeled 33.3 MHz (closer to 44 MHz than the 165 MHz we had started using) and using the Moku adjusted the trim caps after the transformer T1 to adjust orthogonality (using an oscilloscope). The orthogonality seems quite good on this board and it seems to be working fine, so I decided to swap out the BH44 (previously AS165) IQ demod board for this one. To do this I first unpowered the amplifier, then disconnected the load (IQ demod board) then release from the Eurocrate, then add the new board.

Finally, using Marconi at 11.066195 * 4 to get close to the 44 MHz LO frequency, I measured a 63.9 Hz tone at the C1:LSC-BH44_I_IN1 and C1:LSC-BH44_Q_IN1 channels (whitening gain 0 dB). The measured angle between these two channels was 86.97 deg, so the orthogonality is much better now. The gain imbalance is also relatively better, Q/I ~ 0.57

  17401   Tue Jan 17 20:03:19 2023 yutaSummaryBHDBH44 installations: IQ demodulator is not orthogonal

[Anchal, Paco, JC, Yuta]

We have started hardware installations for BH44 RF PD. 44 MHz LO generation and signal chain from IQ demodulator was checked successfully, but found that IQ demodulator is not orthogonal.

RF PD Interface:
 - We have unplugged Ch2 of the RFPD Interface (labeled "Special") to re-use it for BH44. Ch2 was used for "UNIDENTIFIED" RFPD. DB15 cable was routed to ITMY table and connected to BH44 RF PD (40m/17398) now sitting on the cover of ITMY table. See Attachment #1.
 - Finding a DB15 RF PD interface cable was easy because of the organization work!

44 MHz LO generation:
 - LO for BH44 was generate following the scheme proposed in 40m/17319.
 - 11 MHz LO from RF distributor labeled "+16 dBm" (measured to be 16.5 dBm) and 55 MHz LO labeled "SPARE 55" (measured to be 2.26 dBm) was mixed with a mixer ZFM-1H-S+ (using 11 MHz as LO, and 55 MHz highpass filtered with SHP-50+ as RF). The mixer output was lowpass filtered with SLP-50+, and amplified with ZFL-500LN+, which gave 8.07 dBm at 44 MHz. The second heighest peak was -11.53 dBm at 22 MHz, which seems low enough. See Attachment #2 for the photo of the setup.

IQ demodulation:
 - We have used unused IQ demodulator labeled "AS165" to use it for BH44. See Attachment #3.
 - We have quickly checked if the IQ demodulator is working or not with LO from BH55, PD input of 55 MHz generated using Moku to see I and Q outputs. The outputs are sine waves at frequency consistent with the difference between LO frequency and "PD input" frequency, and the phase was off as expected. Q output was ~4 dBm higher than I output.

Measured diff of BH44:
 - After CDS modifications where done, BH44 IQ demodulator was tested by using 44 MHz LO generated in a method mentioned above, and injecting 11.066195 * 4 MHz signal from Moku as PD input. This gave ~75 Hz signal in C1:LSC-BH44_I and C1:LSC-BH44_Q.
 - With 0dB whitening gain and whitening/unwhitening filters off, gain imbalance was measured to be Q/I=137.04/62.49=2.19, and measured phase difference to be PHASE_D=27.21 deg (see Attachment #4; gpstime=1358051213).
 - With 0dB whitening gain and whitening/unwhitening filters on, gain imbalance was measured to be Q/I=138.44/63.21=2.19, and measured phase difference to be PHASE_D=26.95 deg (see Attachment #5; gpstime=1358051325138). This is consistent with whitening/unwhitening off, and noise is smaller, which mean whitening/unwhitening filters are probably working fine.
 - IQ demodulator board might be not working properly, as I and Q signals are not quite orthogonal.

Model changes:

  • We modified c1lsc, c1hpc and c1cal model for BH44.
  • BH44 ADC pins were identified and connected for RFPD phase rotator.
  • The signals are sent to c1hpc through IPC where BH44 is now available for feedback loops in single and dual demodulation.
  • The whitening filter controls and anti-aliasing filter enable buttons were created in c1iscaux slow machine db files.
  • MEDM screens are updated accordingly (see Attachment #6).

Next:
  - Use different IQ demodulator board that has better IQ orthogonality.
  - Connect BH44 RF PD and use 44 MHz test input to check the signal chain.
  - Install BH44 RF PD optical path.
  - Try locking LO_PHASE with BH44.

  17400   Fri Jan 13 18:54:59 2023 yutaSummaryLSCInvestigations of LO phase locking in FPMI BHD

[Paco, Yuta]

After several hours of unattended IFO, we realigned the IFO and somehow BH55_Q error signal looked better, LO_PHASE locking was more robust, and we could lock FPMI BHD.

Sensing matrix:
 - Attached #1 is the sensing matrix with FPMI BHD locked, with LO_PHASE locked with BH55_Q using AS4, and below is the calibrated one.

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': -168.5, 'REFL55': 92.32, 'BH55': -110.0}
Sensors       DARM @307.88 Hz           CARM @309.21 Hz           MICH @311.1 Hz           LO1 @315.17 Hz           
AS55_I       (+0.43+/-2.22)e+11 [90]    (+5.26+/-1.26)e+11 [0]    (-0.15+/-5.88)e+10 [0]    (+0.05+/-1.94)e+09 [0]    
AS55_Q       (-3.73+/-0.19)e+11 [90]    (-0.09+/-1.06)e+11 [0]    (+0.21+/-6.82)e+09 [0]    (-0.24+/-2.41)e+08 [0]    
REFL55_I       (+0.08+/-1.17)e+12 [90]    (+3.14+/-0.07)e+12 [0]    (-0.01+/-1.31)e+11 [0]    (+0.07+/-1.03)e+09 [0]    
REFL55_Q       (+0.51+/-1.09)e+10 [90]    (+1.80+/-2.35)e+10 [0]    (+0.01+/-1.44)e+09 [0]    (-0.79+/-5.41)e+07 [0]    
BH55_I       (+1.20+/-0.34)e+11 [90]    (+0.26+/-1.07)e+11 [0]    (-0.04+/-1.33)e+10 [0]    (-1.07+/-1.82)e+09 [0]    
BH55_Q       (+1.12+/-1.52)e+11 [90]    (-3.40+/-1.98)e+11 [0]    (-0.01+/-4.16)e+10 [0]    (-5.55+/-1.66)e+09 [0]    
BHDC_DIFF       (+6.95+/-0.25)e+11 [90]    (+0.01+/-1.60)e+11 [0]    (-0.70+/-4.49)e+09 [0]    (+4.24+/-4.14)e+08 [0]    
BHDC_SUM       (+7.06+/-2.64)e+10 [90]    (-0.32+/-3.24)e+10 [0]    (+0.05+/-4.26)e+09 [0]    (+1.30+/-6.33)e+08 [0]    

BH55_Q:
 - We are not sure why BH55_Q error signal got better. Peak to peak amptidue of BH55_Q when LO_PHASE is not locked is at around 800 (even if LO_PHASE locking cannot be stably locked), but when we couldn't lock LO_PHASE stably, it was noisier. This suggests that BHD alignment is not bad.
 - Attachment #2 shows the spectrum of BHDC_DIFF, BH55_Q (measured at LO_PHASE_IN1) and AS55_Q when FPMI is locked with AS55_Q, and LO_PHASE is locked with BH55_Q. Dashed darker curves are when we could not lock LO_PHASE stably. You can see broad noise in BH55_Q at around 60 Hz and its harmonics when it is noisy, but they are not present when LO_PHASE can be locked stably. Also, AS55_Q stays the same, which suggests that the cause is not in FPMI to AS55, but in BHD path to BH55.

Sensitivity comparison with different LO_PHASE locking actuator:
  - We compared FPMI sensitivity with LO_PHASE locked with LO1 (red) vs with AS4 (orange). Didn't change, as expected (Attachment #3).

Next:
 - Investigate what is causing noisy BH55. Is it FPMI alignment, BHD alignment, suspensions in LO/AS paths, or electronics?
 - Try locking LO_PHASE with an offset to BH55_Q to see if BHD_DIFF sensitivity to DARM changes, and to see if we can reduce BHD_DIFF dark noise contribution to FPMI sensitivity
 - Try BH55+audio and BH44 to lock LO_PHASE.
 - PRMI and PRFPMI

  17399   Fri Jan 13 14:20:34 2023 yutaSummaryLSCCalibration friendly FPMI BHD

[Paco, Yuta]

Gains in DARM are corrected to make it more calibration friendly.

DARM error signals
 - 0.19 * POX11_I - 0.19 * POY11_I
 - 1 * AS55_Q
 - -0.455 * BHD_DIFF (needs to be checked if LO phase is different)

DARM gain:
 - C1:LSC-DARM_GAIN = 0.04 (it was 0.015 to have UGF of ~150 Hz)

Online calibration:
 - FM2 for C1:CAL-DARM_CINV was turned on, which is a calibration for AS55_Q in FPMI; 1 / (3.64e11 counts/m) = 2.747e-12 m/counts (see sensing matrix below; consistent with 40m/17369).
 - FM2 for C1:CAL-DARM_A was updated to 10.91e-9 (40m/16977).
 - C1:CAL-DARM_W_OUT will be our calibrated FPMI displacement in meters. This is correct with BHD_DIFF locking, if the BHD_DIFF is balanced with AS55_Q before DARM_IN1.

FPMI sensitivity:
 - Attached plot shows the sensitivity of FPMI with AS55_Q and BHD_DIFF, plotted together with their dark noise.
 - The sensisitivty was measured with calibration lines off and notches off, which removed the forest of lines we saw on Jan 11 (40m/17392).

FPMI sensing matrix:
 - Attached is a screenshot of uncalibrated sensing matrix MEDM screen. Audio demodulation phase for DARM was tuned to have stable sign.
 - The following is calibrated sensing matrix measured today with FPMI locked with AS55_Q. BH55 and BHD_DIFF have large uncertainties because LO_PHASE locking is not stable.

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': -168.5, 'REFL55': 92.32, 'BH55': -110.0}
Sensors       DARM @307.88 Hz           CARM @309.21 Hz           MICH @311.1 Hz           LO1 @315.17 Hz           
AS55_I       (-3.28+/-0.90)e+11 [90]    (-0.05+/-2.53)e+11 [0]    (+0.47+/-2.14)e+10 [0]    (-0.06+/-1.76)e+09 [0]    
AS55_Q       (-3.64+/-0.08)e+11 [90]    (-0.09+/-8.30)e+10 [0]    (-0.28+/-2.24)e+09 [0]    (+0.12+/-1.16)e+08 [0]    
REFL55_I       (+0.07+/-1.24)e+12 [90]    (+3.32+/-0.06)e+12 [0]    (-0.01+/-1.39)e+11 [0]    (+0.00+/-1.12)e+09 [0]    
REFL55_Q       (-0.98+/-2.46)e+09 [90]    (-4.68+/-2.04)e+09 [0]    (+0.08+/-1.00)e+09 [0]    (+1.73+/-5.69)e+07 [0]    
BH55_I       (-6.84+/-2.47)e+11 [90]    (+0.43+/-2.32)e+11 [0]    (-0.33+/-6.21)e+10 [0]    (-2.51+/-8.09)e+09 [0]    
BH55_Q       (+5.68+/-1.57)e+11 [90]    (-0.17+/-2.52)e+11 [0]    (-0.46+/-4.39)e+10 [0]    (+0.73+/-5.01)e+09 [0]    
BHDC_DIFF       (-2.48+/-3.47)e+11 [90]    (-0.09+/-1.99)e+11 [0]    (+1.56+/-4.11)e+10 [0]    (-0.49+/-6.78)e+09 [0]    
BHDC_SUM       (-2.12+/-1.84)e+10 [90]    (+0.35+/-1.44)e+10 [0]    (-1.30+/-4.18)e+09 [0]    (-0.03+/-8.17)e+08 [0]  
 


Current status:
 - After locking FPMI BHD to get the FPMI sensitivity today, we are struggling to re-lock again. LO_PHASE locking is glitchy today for some reason. To be investigated.
 

  17398   Fri Jan 13 13:34:12 2023 AnchalSummaryBHDBH44 tuned and transimpedance measured

I've tuned one gold box RFPD to be resonant at 44.26 MHz and I left the notch to be near 66 MHz, however, it is only effective by 10 dB. Attached is the measured transimpedance using the test port. This measurement should be updated with PD testbed measurement.

This photodiode is ready to be installed for the dual RF lO phase locking scheme.


Thu Jan 19 15:06:43 2023 Updating the measurement with Moku:Pro calibration TF

  17397   Thu Jan 12 18:51:17 2023 PacoUpdateALSDFD and Phase tracker AM coupling

[Anchal, Paco]

We measured DFD AM coupling; it seems to be minimum at higher RF input and low modulation depths as expected.

To do this, we set up Moku:Lab for AM ext with a spare DAC channel (C1:BAC-SPARE_CH14_OUT) which we send a swept sine excitation using diaggui. We vary the carrier level, and the modulation depth (every time we changed the level, we run the phaseUGF.py script to allow the phase tracker to adjust its loop gain properly). Attachment #1 shows the results, showing the finite bandwidth effect of the phase tracker as well as the mean magnitudes of the AM coupling below 100 Hz. This measurement and the script live in

/opt/rtcds/caltech/c1/Git/40m/measurements/ALS/DFD_calibration/

What this means for ALS calibration:

It seems the residual AM coupling for a typical RF input level from our ALS beatnote corresponds to the couplings of ~ 2 Hz/V. This means that if the RF input level is fluctuating by 100mV, our residual beat frequency fluctuations only move by 200 mHz. This is not the case when the arms are locked... there the beat level stability is closer to 1 mV (so 2 mHz coupling to the phase tracker). Under previous SNR conditions, our lines are typically at a few 100 Hz of amplitude, with a noise floor comparable to a few 100 mHz (SNR ~ 100s), so AM coupling seems not to be statistically limiting for 0.1% calibration.

Next:

  • To further reject this residual coupling, it may be worth balancing the demodulated IQ amplitudes, by using the digital gains "C1:ALS-BEATX_FINE_Q_GAIN, C1:ALS-BEATX_FINE_I_GAIN".
  • For now, this effect (and its frequency dependence above 300 Hz) can probably be neglected for ALS calibration purposes.
  17396   Thu Jan 12 15:31:27 2023 RadhikaUpdateALSXARM green laser lock debugging

[Radhika, Anchal, Paco]

AUX PDH Loop Stability

Today I tried aligning the XEND green beam into the arm cavity. Using M1 and M2 steering mirrors, I reached a max transmission ~1.2 of TEM00. In this configuration there was a "donut" mode also flashing, with transmission exceeding that of TEM00. Scanning all 4 degrees of freedom, I couldn't get TEM00 transmission to exceed 1.2, or significantly suppress the other modes. Not great mode matching. (PD gain: 20 dB; servo gain: 10.0.) 

In an earlier conversation Paco had recommended I preamplify the green REFL signal with an SR560 before feeding it to the RF mixer. (For yarm this is done with an SR560 gain of 1000.) I did so and raised the gain on the SR560 until it overloaded (PD: 0 dB; SR560: 100). This didn't immediately improve the lock quality, but because alignment still needed work I wasn't surprised. 

Anchal suggested the laser mode might be distorted by some lenses further upstream. We noticed some vertical spreading/distortion of the green beam by the first lens after SHG. I adjusted the pitch of an IR steering mirror until it disappeared. We then used the irises by the entrance to the arm cavity to coarsely align the input beam with M1 and M2. This time, fine alignment brought green transmission to just under 4. After slightly adjusting the half-wave plate, green transmission peaked at 4. (This is the highest I've seen it - previous max was 3.) The final combination of PD gain, SR560 gain, and servo gain that maximized transmission and duration of lock was (PD: 10 dB; SR560: 20; servo: 4.0). At its longest, lock on TEM00 was maintained for ~10 seconds.

AUX PDH Loop OLTF

In parallel with above, I was trying to take an OLTF of the loop whenever it was temporarily locked. I set up the measurement configuration like in the previous ELOG (injection at error point). Like last time, the loop would not lock when summing the PDH error signal with the excitation. I confirmed this was true even when I turned off the Moku excitation output. Checking the summed signal output, the Moku was adding an offset to the error signal. Buffering the excitation with an SR560 solved this issue.

The locked mode was switching pretty rapidly during the time I tried to measure the OLTF, and I ended up moving onto trying to improve lock. I might return today to try to take a measurement - I'll post it here.

  17395   Thu Jan 12 12:00:09 2023 PacoSummaryLSCFPMI BHD sensitivity curve with higher resolution upto 6.9 kHz

Here's the same sensitivity plot from yesterday (40m/17392), but with higher frequency resolution, upto 6.9 kHz, using GPS times from yesterday.
Now curves from FPMI with AS55_Q are also from yesterday, just before switching to BHD, so it will be more direct comparison

  17394   Thu Jan 12 10:06:10 2023 PacoUpdateALSDFD discriminant calibration

[Paco, Anchal] Log from yesterday work around 1Y2 rack; note that while this work was ongoing, TT2 position drifted slowly and misaligned the IFO input over the course of less than an hour. I suspect the DB9 breakout board and temporarily present components noted below may have introduced a floating ground in 1Y2, making the TT coil drivers misbehave. To support this claim, we noted that after removing the breakout board the drift disappeared!


We calibrated the DFD discriminant as a function of RF input level. The configuration was as follows:

  1. Break out IQ demod board RF output (in the rear chassis on 1Y2), looking at Ch1 board outputs (for BEATX). The two differential outputs were broken into two BNCs (pairs 1,6 and 2,7 for Q and I respectively), and fed into the Moku:Lab. A Marconi 2023A was used as a VCO, with FM ext mode enabled and a FreqDVN (modulation slope) of 200 kHZ / Vrms (1 Vrms = 1.41 Vp = 0.705 Vpp). The FM ext input on the Marconi was sourced by the OUT1 of Moku:Lab, and the IQ demod outputs were connected to IN1 and IN2 on Moku:Lab.
  2. After measuring the TF using a swept sine, I verified that the frequency response was flat up to 150 kHz (Marconi cuts FM ext at 275 kHz), so I switched to the oscilloscope instrument and setup OUTPUT to a 211.1 Hz sine wave, 1.41 Vpp to dither the 40 MHz by +- 100 kHz.
  3. Using the arbitrary math function in Moku:Lab Scope, I computed the DFD output magnitude = sqrt(I**2 + Q**2), and measured its mean over 3 seconds.

The results are summarized in Attachment #1.

  17393   Wed Jan 11 17:05:55 2023 AnchalUpdateASCWFS demodulation board 112B - Working as expected

The other modified board 112B has been fixed and tested now. See the results attached. The issue was in some malfunctioning OP284 which have been replaced by AD8672.

  17392   Wed Jan 11 16:56:57 2023 yutaSummaryLSCFPMI BHD recovered, LO phase noise not limiting the sensitivity

[Paco, Yuta]

We recovered FPMI BHD, and sensitivity was estimated. High frequency sensitivity is improved by an order of magnitude compared with AS55 FPMI.
We also estimated the contribution from LO phase noise, and found that LO phase noise is not limiting the sensitivity.

Locking sequence:

1. Lock electronic FPMI

DARM:
 - 0.5 * POX11_I - 0.5 * POY11_I
 - DARM filter module, FM4,5 for acquisition, FM1,2,3,6,8 triggered, C1:LSC-DARM_GAIN = 0.015 (gain lowered from BHD FPMI in December (was 0.02) to have more gain margin)
 - Actuation on 0.5 * ETMX - 0.5 * ETMY
 - UGF ~ 150 Hz

CARM:
 - 0.5 * POX11_I + 0.5 * POY11_I
 - CARM filter module, FM4,5 for acquisition, FM1,2,3,6,8 triggered, C1:LSC-CARM_GAIN = 0.012
 - Actuation on -0.734 * MC2

2. Lock MICH

MICH:
 - 1.1 * REFL55_Q
 - MICH filter module, FM4,5,8 for acquisition, FM2,3,6 triggered, C1:LSC-MICH_GAIN = +10
 - Actuation on 0.5 * BS
 - UGF ~35 Hz (Attachment #1)

3. Hand over to real DARM/CARM

DARM:
 - 2.617 * AS55_Q

CARM:
 - 0.496 * REFL55_I
 - UGF ~200 Hz (Attachment #2)

4. Lock LO_PHASE

LO_PHASE:
 - 1 * BH55_Q (demod phase: -110 deg; this was chosen by hand to maximize fringe in BH55_Q when FPMI is locked. This seemed to make more robust LO_PHASE lock, compared with December)
 - FM5,8, C1:HPC-LO_PHASE_GAIN=-1
 - Acuation on 1 * LO1
 - UGF ~110 Hz (Attachment #3)

5. Hand over to BHD_DIFF

DARM:
 - -1.91 * BHD_DIFF (ratio between AS55_Q to BHD_DIFF was measured with a DARM line at 575.125 Hz, which was measured to be -0.455; BHD_DIFF was zeroed by balancing A and B before the measurement)
 - UGF ~150Hz (Attachment #4)


Measured sensing matrix:

/opt/rtcds/caltech/c1/Git/40m/scripts/CAL/SensingMatrix/ReadSensMat.ipynb

Sensing matrix with the following demodulation phases (counts/counts)
{'AS55': -168.5, 'REFL55': 92.32, 'BH55': -110.0}
Sensors       DARM @307.88 Hz           CARM @309.21 Hz            MICH @311.1 Hz        LO1 @315.17 Hz           
AS55_I       (-0.35+/-1.44)e-02        (+3.23+/-1.09)e-02        (-0.18+/-9.84)e-03    (+0.02+/-1.33)e-03    
AS55_Q       (-0.45+/-3.48)e-02        (-0.19+/-1.23)e-02        (+0.05+/-1.43)e-03    (-0.02+/-2.03)e-04    
REFL55_I     (+0.05+/-1.31)e-01        (+4.51+/-0.07)e-01        (-0.03+/-3.44)e-02    (+0.11+/-1.01)e-03    
REFL55_Q     (-0.39+/-4.74)e-04        (-1.36+/-0.50)e-03        (+0.16+/-2.80)e-04    (+0.10+/-4.92)e-05    
BH55_I       (-1.90+/-5.00)e-03        (+0.80+/-8.82)e-03        (-0.50+/-2.29)e-03    (-4.61+/-9.52)e-04    
BH55_Q       (-0.31+/-4.86)e-02        (-3.13+/-3.04)e-02        (-0.06+/-1.07)e-02    (-1.42+/-2.11)e-03    
BHDC_DIFF    (-5.56+/-0.21)e-02        (+0.10+/-1.64)e-02        (+0.10+/-1.40)e-03    (+0.77+/-2.27)e-04    
BHDC_SUM     (+1.75+/-3.90)e-03        (-1.22+/-3.22)e-03        (-0.35+/-1.52)e-03    (-0.36+/-6.42)e-04

 

Sensing matrix with the following demodulation phases (counts/m)
{'AS55': -168.5, 'REFL55': 92.32, 'BH55': -110.0}
Sensors       DARM @307.88 Hz           CARM @309.21 Hz           MICH @311.1 Hz        LO1 @315.17 Hz           
AS55_I       (-0.30+/-1.25)e+11        (+2.18+/-0.73)e+11       (-0.07+/-3.59)e+10    (+0.08+/-5.02)e+09    
AS55_Q       
(-0.39+/-3.03)e+11        (-1.27+/-8.32)e+10       (+0.20+/-5.23)e+09    (-0.06+/-7.66)e+08    
REFL55_I     (+0.04+/-1.14)e+12        (+3.05+/-0.05)e+12       (-0.01+/-1.26)e+11    (+0.42+/-3.82)e+09    
REFL55_Q     (-0.34+/-4.12)e+09        (-9.20+/-3.37)e+09       (+0.06+/-1.02)e+09    (+0.04+/-1.86)e+08    
BH55_I       (-1.65+/-4.34)e+10        (+0.54+/-5.95)e+10       (-1.83+/-8.36)e+09    (-1.74+/-3.59)e+09    
BH55_Q       (-0.27+/-4.23)e+11        (-2.11+/-2.05)e+11       (-0.21+/-3.91)e+10    (-5.36+/-7.98)e+09    
BHDC_DIFF    (-4.83+/-0.18)e+11        (+0.07+/-1.11)e+11       (+0.35+/-5.09)e+09    (+2.90+/-8.56)e+08    
BHDC_SUM     (+1.52+/-3.39)e+10        (-0.82+/-2.17)e+10       (-1.29+/-5.56)e+09    (-0.14+/-2.42)e+09

NOTE that some of sensing matrix element (e.g. DARM to AS55_Q) is wrong, because of ill defined sign in C1:CAL-SENSMAT_XXXX_XXXX_AMPMON channels.


Locked GPS times:
 - 1357511737 to 1357513050
 - 1357513448 to 1357518188 (intentionally unlocked)


Sensitivity estimate:
 - See Attachment #5 and #6 (high frequency zoomed), dashed traces with darker colors are of AS55_Q FPMI from 40m/17369.
 - DARM_IN1 was calibrated using DARM content in BHD_DIFF, with 1 / (1.91 * 4.83e11 counts/m) = 1.086e-12 m/counts (which should be similar to DARM_IN1 calibration for AS55_Q, because we are balancing the error signals going to DARM_IN1, and it is as expected; see 40m/17369).
 - DARM_OUT calibration is the same as 40m/17369; ETM plant = 10.91e-9 / f^2 m/counts.
 - LO phase noise was estimated using BH55_Q, with the collowing calibration factor (BH55_Q calibrated into LO1 motion, into BHD_DIFF, and then into DARM).

1/5.36e9*2.9e8/4.83e11 = 1.15e-13 m/counts

 - Seismic noise was estimated using C1:IOO-MC_F_DQ, with the same calibration factor found in 40m/16975.
 - Dark noise was estimated using DARM_IN1 when the PSL shutter is closed.

Discussion:
 - Sensitivity below ~10 Hz is probably limited by seismic noise
 - Noise above 1 kHz might be limited by dark noise of BHD_DIFF, but not below 1 kHz. For AS55_Q FPMI, sensitivity above ~300 Hz was limited by dark noise.
 - LO phase noise is not limiting the sensitivity, from the estimated noise using BH55_Q.
 - Both BH55_Q and BHD_DIFF have funny structure like forest above ~100 Hz. This might be from suspensions in the AS path and LO path to BHD. It could also be that calibration lines for measuring sensing matrix were too much (BHD FPMI sensitivity was measured with calibration lines around ~310 Hz on).

Next:
 - Update the c1cal model to put correct signs to C1:CAL-SENSMAT_XXXX_XXXX_AMPMON channels.
 - Measure BHD FPMI sensitivity with calibration lines off.
 - Find better LO phase to improve the sensitivity.
 - Lock LO phase with RF+audio and RF44 and compare the sensitivity.
 - Move on to PRFPMI BHD.

  17391   Tue Jan 10 20:24:29 2023 AnchalUpdateASCWFS demodulation board 111B - Working as expected

I've completed the modifications on two WFS demod boards. This required replacing all 8 mixer ICs on each board. I also tuned each channel to get less than 2 mV offset on all of them.

I was able to complete testing the board SNo. 111B today. The results are attached. The test was done by feeding the board 22 MHz LO generated by frequency doubling. A signal at 11 MHz was generated using Moku:Lab at 1mVpp and then further attenuated by 10 dB to make a fair comparison with the previous testing of the IMC WFS board at 29.5 MHz. This board has the same response as the IMC WFS board at 29.5 MHz. I tested all four channels in the second plot.

I'll complete the testing of the second board SNo 112 B and then move on to setting up the optical path for AS WFS.

  17390   Tue Jan 10 16:06:58 2023 yutaSummaryPSLPMC transmission dropped to 0.68

[JC, Paco, Yuta]

It seems like PMC transmission (C1:PSL-PMC_PMCTRANSPD) dropped to ~0.68 from ~0.74 on Dec 27.
We tried to tweak PZT offset for PMC loop and input alignment to PMC, but PMC transmission didn't increased.
PSL laser temperature was also sweeped in the range 30.3 - 31.6 degC, but didn't help. The PSL temperature was reverted to original 30.61(1) degC.
Power measured at PSL output now is 893 mW (measured at our standard place shown in 40m/16672), which used to be 951 mW in June 2022 (40m/16886).
Power measured at PMC input (see attached photo) now is 1.18 W.

Next:
 - What was the previous PMC input power we had?
 - Sweep PSL laser temperature for larger range

  17389   Tue Jan 10 15:07:33 2023 JCUpdateGeneralClean Large Optical Table

I have been working on cleaning the large optical table next to the PSL table. I have placed the known optics along in the optical cabinets Section Y5. Post and pillars have been placed in a cabinet along X-Arm. (I will work on gathering optics and optical hardware into a single area in the future, having them separated is only temporary.) I found some optics that were chipped and/or unlabeled. These have been placed in a box. 

There were cables coming into this table from the wire rack above, I plan on removing this. If there are any issues with me doing this, please message me. 

My main purpose for cleaning this is to potentially have an open area to place OMC for the next vent. We can also move the PD Testing table here. 

  17388   Mon Jan 9 19:41:01 2023 AnchalUpdateSUSNull stream (butterfly/pringle) row added and DQed

I updated the suspension model (/cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control_new.dml) to add a 5th row in the input matrix so that we can put in the calculated NULL stream vector (also have been called as Butterfly mode or Pringle mode in the past). The output of this row would go through a filter module and then is sent to the testpoint named 'C1:SUS-OPT_SENSOR_NULL' where OPT is the optic acronym. This channel is acquired in frames at 256 Hz and would be available as C1:SUS-OPT_SENSOR_NULL_DQ. After the update in the model, I built, installed and restarted models c1sus, c1mcs, c1scx, c1scy, c1su2, and c1su3. Then I restarted daqd, and everything came up nicely. After but restore, I added the null stream vector for the optics it was already known from a free swing test. ITMX, ITMY, ETMX, PRM, and SRM null stream vectors needs to be calculated from the other 4 rows. It is set to zero right now. Medm screen for the input matrix was also updated to allow seeing this row.

 

  17387   Thu Jan 5 14:30:32 2023 PacoHowToDAQnds2 server restart

After being unable to fetch data offsite using the nds40 server, I found enlightment here. Our nds2 server is running on megatron and the link before should be sufficient to restore it after any hiccups. yes

  17386   Wed Jan 4 17:15:41 2023 KojiConfigurationCDSunknown dhcp request to fb1

The dhcpd error on the log file stopped when the yellow (DAQ) ethernet cable was removed. With Chris's permission I left it unconnected (Attachment 1).

Chris pinted that the IPMI on c1shimmer is supposed to be exposed to 192.168.113. net rather than DAQ net.

From dhcpd.conf on chiara:

host c1shimmer-ipmi {
  hardware ethernet 3c:ec:ef:c8:44:78;
  fixed-address 192.168.113.37;
}

So the ethernet connections of c1shimmer is still questionable. The next person to work with c1shimmer needs to check them.

 

This would also be related?
https://lanforge.wordpress.com/2015/11/10/turning-off-ipmi-dhcp/

  17385   Wed Jan 4 15:10:19 2023 KojiConfigurationCDSunknown dhcp request to fb1

Jamie reported that:

The logs (/var/log/daemon.log) on fb1 are filling with this line:

Jan 03 14:11:51 fb1 dhcpd[1152]: DHCPDISCOVER from 3c:ec:ef:c8:44:78 via enp3s0: network 10.0.113.0/24: no free leases

It seems that some machine on the network is trying to get an IP address but can't

  • The MAC address 3c:ec:ef:xx:xx:xx indicates this is one of the supermicro units.
  • The IP address indicates this is on the DAQ network which fb1 is spanning.
  • There is a switch for this DAQ network. 
  • There are 8 machines connected to the switch. fb1 is via optical, and the other 7 have yellow ethernet cables (Attachment 1).
  • fb1 and other 6 RT machines already have 10.0.113.x assigned.
  • The rest is c1shimmer. I can't ssh into it from martian. KVM on rack 1X7 shows a black screen assuming 1-7 is c1shimmer. I wonder what's the status of this machine, but left untouched so far.
  17384   Wed Jan 4 12:12:57 2023 PacoSummaryCalibrationALS calibration error from DFD

[Paco, Anchal]

One of the crucial and currently limiting calibration errors is in the ALS beat. We think a major driver of calibration uncertainty may be the DFD TF calibration since it depends on the RF beat power.

The RF beat power as monitored by C1:ALS-BEATY_RF_POW shows relative fluctuations of 0.02% at the 16 Hz sampling rate (actually 0.09% rms from Attachment #1) once the single arm and YAUX laser are both locked. This sounds ok, but that's just a statistical estimate. The beat frequency changes every time we break and reacquire the lock, making the BEAT PD frequency response and DFD overall calibration change their nominal TF. This changes can be significantly larger than 0.02% (e.g 4.9% = observed change in the RF power after breaking and reacquiring the YAUX lock this morning). This is far more significant than the contribution from the RIN on the two lasers.

This kind of systematic error could be addressed by either/all:

  • Stabilizing the ALS BEAT absolute frequency (offset locking using freq counter and simple integrator or equivalent)
  • Rejecting RF beat amplitude fluctuations by mixing a stable DC voltage in the DFD, or using a comparator. 
    • Our plan this afternoon is to quickly measure the RF AM rejection level from a simple mixer and a stable voltage reference and plan ahead.
  • ISS on both lasers
  17383   Wed Jan 4 08:52:11 2023 JCUpdateOPLEV TablesETMX laser has died

Koji mentioned to me that this laser has a degraded output. I removed this replacement laser and put in a new laser from the Y Arm Cabinets, Attachment #1. I placed the degraded laser back to its visitor setup and tested with the power supply, this is shown in Attachment #2. Along with this, I also labeled this laser as degraded.

  17382   Tue Jan 3 17:41:55 2023 KojiUpdateCDSChiara local backup

Chris modified the fstab so that the disk is automatically mounted. The key was that these two disks have an identical UUID and use this UUIS for mounting. I confirmed that /cvs/cds was properly backup-ed on Jan 4th.

controls@chiara:~$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0  1.8T  0 disk
├─sda1    8:1    0  512M  0 part  /boot/efi
├─sda2    8:2    0  1.8T  0 part  /
└─sda3    8:3    0 31.9G  0 part  [SWAP]
sdb       8:16   0  5.5T  0 disk
└─sdb1    8:17   0  5.5T  0 part  /home/cds
sdc       8:32   0  5.5T  0 disk
└─sdc1    8:33   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1 /media/40mBackup
sdd       8:48   0  5.5T  0 disk
└─sdd1    8:49   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1 /media/40mBackup


controls@chiara:~$ sudo blkid
/dev/sdc1: UUID="052f9129-f2eb-6ef1-473d-a748a1ffa5d3" UUID_SUB="9ac96976-e1d5-cc01-13f7-10944d5d6735" LABEL="chiara:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="5cf6aac7-3f29-42e0-8db6-de2978ca84f0"
/dev/sdd1: UUID="052f9129-f2eb-6ef1-473d-a748a1ffa5d3" UUID_SUB="9f124649-ff79-e406-54ab-6374b4acddf1" LABEL="chiara:0" TYPE="linux_raid_member" PARTLABEL="primary" PARTUUID="01296513-46cf-4210-8d59-6f6bc25934ee"

/dev/sda1: UUID="69C0-DD2F" TYPE="vfat" PARTUUID="00ac6b04-2675-4842-9193-ee5c4575b4b4"
/dev/sda2: UUID="75f19654-1504-4548-b9a7-95f22d507cb4" TYPE="ext4" PARTUUID="f5022aff-7f84-4e72-9dfa-44b0412e907b"
/dev/sda3: UUID="e9d6a5b7-78e7-4373-9bac-0509458860cd" TYPE="swap" PARTUUID="f7388c20-b17e-4f21-9093-1df58d00d9e3"
/dev/sdb1: LABEL="cvs" UUID="eceb000f-9493-45fd-85f1-2c95c6819f4a" TYPE="ext4" PARTUUID="2e090790-7d03-406d-8ee9-5a5c96e14258"
/dev/md0: UUID="6d16f518-1332-42c3-ad16-0a9d384c6dad" TYPE="ext4"

controls@chiara:~$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda2 during installation
UUID=75f19654-1504-4548-b9a7-95f22d507cb4 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=69C0-DD2F  /boot/efi       vfat    defaults        0       0
# swap was on /dev/sda3 during installation
UUID=e9d6a5b7-78e7-4373-9bac-0509458860cd none            swap    sw              0       0
UUID=eceb000f-9493-45fd-85f1-2c95c6819f4a    /home/cds    ext4    errors=remount-ro    0    1
UUID=6d16f518-1332-42c3-ad16-0a9d384c6dad    /media/40mBackup    ext4    errors=remount-ro    0    1

  17381   Tue Jan 3 16:11:05 2023 KojiUpdateCDSChiara local backup

I checked how the local backup of our /cvs/cds is done. The last backup was taken on 2022-12-15 and it kept failing since 2022-12-16.

controls@chiara:/opt/rtcds/caltech/c1/scripts/backup$ tail -100 localbackup.log

....
2022-12-15 07:00:02,404 INFO       Updating backup image of /cvs/cds
2022-12-15 07:17:51,901 INFO       Backup rsync job ran successfully, transferred 1,352 (reg: 1,288, dir: 64) files.
2022-12-16 07:00:01,650 INFO       Updating backup image of /cvs/cds
2022-12-16 07:00:01,668 ERROR      External drive not mounted!!!

....

The backup destination is /media/40mBackup according to /opt/rtcds/caltech/c1/scripts/backup/localbackup
During the power outage on Dec 15, 2022 (<- not well elogged), the volume was probably unmounted.
This disk is missing although some spare disks exist. The disks are indicated as RAID1. I'll ask Chris if he knows what the current configuration is and how to add it to fstab.

controls@chiara:/opt/rtcds/caltech/c1/scripts/backup$ df
Filesystem      1K-blocks       Used  Available Use% Mounted on
udev             16394928          0   16394928   0% /dev
tmpfs             3283044     123944    3159100   4% /run
/dev/sda2      1888292368   13161244 1779137424   1% /
tmpfs            16415220          0   16415220   0% /dev/shm
tmpfs                5120          0       5120   0% /run/lock
tmpfs            16415220          0   16415220   0% /sys/fs/cgroup
/dev/sda1          523248       3620     519628   1% /boot/efi
/dev/sdb1      5814157460 2604230900 2916884052  48% /home/cds
tmpfs             3283044          8    3283036   1% /run/user/1001
tmpfs             3283044          4    3283040   1% /run/user/114

controls@chiara:/opt/rtcds/caltech/c1/scripts/backup$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0  1.8T  0 disk
├─sda1    8:1    0  512M  0 part  /boot/efi
├─sda2    8:2    0  1.8T  0 part  /
└─sda3    8:3    0 31.9G  0 part  [SWAP]
sdb       8:16   0  5.5T  0 disk
└─sdb1    8:17   0  5.5T  0 part  /home/cds
sdc       8:32   0  5.5T  0 disk
└─sdc1    8:33   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1
sdd       8:48   0  5.5T  0 disk
└─sdd1    8:49   0  5.5T  0 part
  └─md0   9:0    0  5.5T  0 raid1

  17380   Tue Jan 3 15:28:12 2023 JCUpdateOPLEV TablesETMX laser has died

Seems that the ETMX laser died over the break and took an extended vacation. I swapped the laser out with one Koji would use to model Suspension wires.

The laser which died out seems a bit new though, it was manufactured in Jan 2019. A photo of this laser is attached.

  17379   Tue Jan 3 12:10:46 2023 JamieUpdateCDSYearly DAQD fix 2023, did not work :(

This whole procedure is no longer needed after the CDS upgrade.  We don't do things in the old hacky way anymore.  The gpstime kernel module does not need to be hacked anymore, and it *should* keep up with leap seconds properly...

That said, there was an issue that @christopher.wipf id'd properly:

  • The front end models were not getting the correct GPS time because the offset on their timing cards was off by a year.  This is because the timing cards do not get the year info from IRIG-B, so the offset they had when the models were loaded in 2022 was no longer valid as soon as the year rolled over to 2023.
  • This meant that the data sent from the front ends to the DAQ was a year old, and the DAQ receiver process (cps_recv) was silently dropping the packets because the time stamps were too off.

So to resolve the issue the /usr/share/advligorts/calc_gps_offset.py program needed to be run on the front ends, and all the models needed to be restarted (or all the front ends need to be restarted).  Once that happens the data should start flowing properly.

NOTE the DAQD no longer uses the gpstime kernel module, so the fact that the gpstime module was reporting the wrong time on fb1 did not affect anything.

Anchel restarted the front ends which fixed the issue.

We got new timing hardware from Keith at LLO which will hopefully resolve the year issue (if it's ever installed) so that we won't have to go through these shenanigans again when the year rolls over.  The sites don't have to deal with this anymore.

Issues reported upstream:

  •  better logging from the cps_recv process to report why there is no data coming through
  •  fix packaging for advligorts-daqd to not depend on the gpstime kernel module

Also note that the code in /opt/rtcds/rtscore is completely obsolete and is not used by anything and that whole directory should be purged

  17378   Tue Jan 3 11:32:32 2023 AnchalUpdateCDSYearly DAQD fix 2023, did not work :(

Every year some changes need to be done manually in a driver c code file for daqd to work. The gpstime offset needs to be changed on fb for some package.

We followed the procedure on this thread, but this year it did not work. Here is a summary of our findings:

We first confirmed this is indeed the issue by doing:

controls@fb1:~$ cat /proc/gps
946926959.95

This is clearly wrong gpstime. We went to the file /opt/rtcds/rtscore/release/src/include/drv/spectracomGPS.c in fb1 and added following lines after line 110:

/* 2022 has no leap seconds or leap days, so adjust for that */
       pHardware->gpsOffset += 31536000;

After this, we went to  /opt/rtcds/rtscore/release/src/drv/symmetricom and ran:

controls@fb1:/opt/rtcds/rtscore/release/src/drv/symmetricom$ sudo make
make -C /lib/modules/4.19.0-6-rtcds-amd64/build SUBDIRS=/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom modules
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-6-rtcds-amd64'
  CC [M]  /opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.o
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:59:27: error: initialization of ‘long int (*)(struct file *, unsigned int,  long unsigned int)’ from incompatible pointer type ‘int (*)(struct inode *, unsigned int,  long unsigned int)’ [-Werror=incompatible-pointer-types]
         .unlocked_ioctl = symmetricom_ioctl,
                           ^~~~~~~~~~~~~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:59:27: note: (near initialization for ‘symmetricom_fops.unlocked_ioctl’)
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘get_cur_time’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:89:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  int sync = getGpsTime(&timeSec, &timeUsec);
  ^~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_ioctl’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:116:23: error: implicit declaration of function ‘copy_to_user’; did you mean ‘raw_copy_to_user’? [-Werror=implicit-function-declaration]
                   if (copy_to_user ((void *) arg, &res,  sizeof (res))) return -EFAULT;
                       ^~~~~~~~~~~~
                       raw_copy_to_user
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c: In function ‘symmetricom_init’:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:175:26: error: implicit declaration of function ‘create_proc_entry’; did you mean ‘remove_proc_entry’? [-Werror=implicit-function-declaration]
         proc_gps_entry = create_proc_entry("gps", PROC_MODE, NULL );
                          ^~~~~~~~~~~~~~~~~
                          remove_proc_entry
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:175:24: warning: assignment to ‘struct proc_dir_entry *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
         proc_gps_entry = create_proc_entry("gps", PROC_MODE, NULL );
                        ^
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:181:23: error: dereferencing pointer to incomplete type ‘struct proc_dir_entry’
         proc_gps_entry->read_proc = procfile_gps_read;
                       ^~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:188:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
  struct pci_dev *symdev = pci_get_device (SYMCOM_VID, SYMCOM_BC635_TID, 0);
  ^~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:222:3: warning: label ‘out_remove_proc_entry’ defined but not used [-Wunused-label]
   out_remove_proc_entry:
   ^~~~~~~~~~~~~~~~~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:158:22: warning: unused variable ‘pci_io_addr’ [-Wunused-variable]
  static unsigned int pci_io_addr;
                      ^~~~~~~~~~~
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:156:6: warning: unused variable ‘i’ [-Wunused-variable]
  int i;
      ^
At top level:
/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.c:158:22: warning: ‘pci_io_addr’ defined but not used [-Wunused-variable]
  static unsigned int pci_io_addr;
                      ^~~~~~~~~~~
cc1: some warnings being treated as errors
make[4]: *** [/usr/src/linux-headers-4.19.0-6-common-rtcds/scripts/Makefile.build:315: /opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom/symmetricom.o] Error 1
make[3]: *** [/usr/src/linux-headers-4.19.0-6-common-rtcds/Makefile:1534: _module_/opt/rtcds/rtscore/branches/branch-3.4/src/drv/symmetricom] Error 2
make[2]: *** [Makefile:146: sub-make] Error 2
make[1]: *** [Makefile:8: all] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-6-rtcds-amd64'
make: *** [Makefile:28: all] Error 2

We don't know how to deal with these error messages. This did not happen last year, so this might have to do with the change in fb1 or our cds setup. Chris and/or Jamie, please help.

  17377   Sat Dec 31 20:00:03 2022 ranaSummaryCalibrationETMY actuation strength cal with 5 lines
  1. how much frequency dependent variation in the transfer function do we expect? Are there resonances in the mechanical suspension cage or the violin modes?
  2. it would be interesting to make the same TF, but from counts to coil current, and see if the variation is there. I don't expect to see much variation in the electronics, but there might be something. In principle, we can just measure the voltage at the satellite box, but the coil cable's capacitance and the coil inductance make for some wiggle. I think the resonant frequency ought to be ~ 100 kHz, but perhaps there are some wiggles due to frequency response in the AI filter or something.
  17376   Sat Dec 31 19:27:32 2022 PacoSummaryCalibrationETMY actuation strength cal with 5 lines

Calibrated ETMY actuation strength using ALS. Attachment #1 shows the result, in close agreement with this previous measurement and a combined uncertainty estimate of 0.88%. The data was taken with 5 oscillators on, at slightly different strengths than with the ITMY run, and the actuation was on ETMY.

The ETMY actuation strength is

10.843e-9 / f^2 +- (0.88)% [m/count]

Note: gpstimes for raw data are 1356490036 to 1356495400 (a little bit over an hour and a half).

  17375   Fri Dec 30 12:53:47 2022 KojiUpdateGeneral40m avoided the power outage

Received the campus power outage this (Dec 30, 2022) morning.
- ELOG is still up
- 6 CDS machines are up
- Vacuum system and pressure all look good

I believe this power outage happened on the other side of the campus and did not affect the 40m.

  17374   Fri Dec 30 11:38:45 2022 PacoSummaryCalibrationALS Calibration errors -- single arm actuation

Here are my thoughts on calibration errors. This applies to the single arm actuation calibration, but may easily be extended to calibrate the DARM residual noise for example.

According to the math in this post, there are four parameters whose estimates build the total calibration uncertainty: arm length, wavelength, loop gain, and beatnote fluctuation. Below is a table for how each is measured, what the sources of statistical versus systematic error are, how large each relative contribution roughly is, and how we may improve on them.

  Arm Length Wavelength ALS beat fluctuation AUX Loop gain
Current Estimate FSR scan using ALS, reference to POX/POY (11 MHz) sideband. NPRO Specification DFD + Phase tracker Swept sine
Statistical error Limited by scan range (e.g. DFD range) and resolution. No statistical error from specification Shot noise limited measurement ? Bendat Piersol Table 9.6 (depends on coherence)
Systematic error Limited by freq reference offsets (Marconi), and residual POS-PIT coupling NPRO half tuning range Flicker noise (electronics, other) Swept sine bias and servo drift (thermal, flicker)
Improvements More FSRs per scan at best possible resolution Iodine spectrsocopy Lower ALS residual frequency noise Higher AUX servo gain

Arm length

Statistical

The arm length has been estimated before by locking the arm with the ALS beat, scanning the arm length and looking at the IR resonances. From the statistical uncertainty standpoint the limit seems to be number of measurable FSRs. Using these numbers, the statistical uncertainty comes to ~ 0.6%. Other attempts claim to have improved on this by almost an order of magnitude giving ~ 0.02%. Simply scanning over more FSRs should improve this as the usual square root number of measurements statistical error reduction.

Systematic

Systematic error comes from the frequency referenced on this measurement (the Marconi 11 MHz sideband oscillator), nonlinearities in the mostly linear scan (e.g. POS to PIT coupling). I think it's safe to neglect frequency offsets > 1 Hz because of the Rb clock reference and the Marconi's own calibration. I'm not sure about the POS to PIT coupling magnitude and whether F2A filters are helping here, but offset scan nonlinearities should distort the FSR nonuniformly and this error may have sneaked into the statistical estimate above. From the posts referenced above,  the scan result seems extremely linear, but repeating the measurement and plotting the residuals may give an accurate estimate of the nonlinearity. I think either of the systematic errors discussed here should be below or around the ppm (0.0001%) level, but this should be confirmed.

Wavelength

Statistical

If we use the NPRO specification Mephisto's wavelength is 1064 nm and there is no statistical error.

If on the other hand we do iodine absorption spectroscopy, we may be able to see ~ 4 lines throughout the 30 GHz tuning range of the NPRO. Fun fact: 30 GHz correspond to 1 cm-1 (inverse centimeter). Assuming we can scan our laser with a 0.01 cm-1 resolution, it may be possible to estimate the absolute wavelength to 10 better than any line center. The ATLAS of iodine spectroscopy gives strong absorption lines around 532 nm to 0.001 cm-1, or 0.00001% accuracy. A simple Doppler broadened absorption should improve this further.

Systematic

If we use the NPRO specification the systematic error comes from the number of known significant figures ~ 0.047 %. A slightly better estimate comes from the Prometheus model with a frequency doubled output hitting near the P 83(33-0) line of iodine, at 18787.814 cm-1. This gives a nominal wavelength of 532.259 nm, or 1064.518 nm on the seed. Because the tuning range is 30 GHz, our systematic error may be +0.03 nm - 0.07 nm from 1064.52 nm. Taking the median of 0.05 nm, the relative systematic error from the Nd:YAG specification is 46.9 ppm = 0.0047%.

If on the other hand we do iodine spectroscopy, the systematic error will be dominated by the residual shifts on the iodine vapor, which are negligibly small compared to the Doppler broadened lines. They might add sub-ppm uncertainty to the absolute calibration.

Beat fluctuations

Statistical

The error in estimating beatnote fluctuations is statistically dominated if our beat detection is shot noise limited for example. Other stationary noises with power law spectra decaying faster than 1/f are subject to this effect. The allan deviation discriminates the timescales at which our measurement is dominated by statistical error. Currently our calibration lines have SNR of 10 to 100. Averaging seems to be limited to ~ 100 second timescales, so the statistical error on these measurements is ~ 0.1 to 1.0 %.

Systematic

As suggested in the above, the allan deviation discriminates the statistical dominated timescales for this measurement. There is a correspondence between noise spectra and allan deviation, so we should be able to point out what noises contribute to systematic drift in our ALS noise budget.

Loop gain

Statistical

Invoking Bendat and Piersol, Table 9.6 gives the statistical estimate of loop gain estimate with coherence gamma, and n_avg number of averages. Because of our resonant OL gain filters, assuming G ~ 100 there, and high coherence on the OLTF measurement so gamma ~ 0.9, with 12 averages we should get a relative loop gain error of 9.8%.

Systematic

Also from B&P, we should estimate how biased our TF is. This depends on delays, bandwidths, measurement device noises, etc. Furthermore, the analog electronics in the AUX servo should drift, but we neglect this contribution for now. A simple bias estimate (eq 9.75) tells us that the coherence is biased by the number of averages such that in our estimate above the unbiased coherence is roughly 0.897. This means our systematic contribution from TF bias is ~ 0.17 %.

We should remember that in the case of loop gain, the total error (systematic + statistical) gets an extra suppression factor of the order of the loop gain itself. Radhika's resonant digital gain filters should easily allocate 40 dB (or ~ 100) on every calibration line such that our total calibration error drops to the 0.1% level.


Conclusions

  • The main calibration error (at the 1% level) seems to be from the ALS beat frequency. We can simply crank the SNR up, but we should work on the ALS relative stability. I think the low frequency end of the ALS residual frequency noise is currently limited by DFD... I wonder if we can improve on this by implementing a digital PLL (e.g. using a Moku)
  17373   Wed Dec 28 19:50:06 2022 PacoUpdateCDSAnother CDS crash -- restored by model restart

Stopped by lab today. Found all suspensions undamped (even though watchdogs never tripped), same symptom as CDS crash from earlier this month. Fixed as per last ocurrence--- by restarting all models and burt restoring.

  17372   Thu Dec 22 15:52:48 2022 KojiSummaryDetCharSummary on the summary pages

[Tega Koji]

Last week, Tega gave me a brief introduction to the configuration of the summary pages. So this is the summary of the conversation.


1. General info resources

40m wiki https://wiki-40m.ligo.caltech.edu/DailySummaryHelp
40m wiki https://wiki-40m.ligo.caltech.edu/40mLDASaccount
40m git lab https://git.ligo.org/40m/40m-summary-pages

2. How the frame files are transfered

The frame files are created in /frames on fb1. ==> If the frame files are not found on fb1, it's the problem of FB/CDS.
This directory is exported to nodus (as /frames) via NFS. ==> If the frame files are not found on nodus (i.e. /frames is not found), it's the NFS problem between fb1 and nodus.
rsync executed on LDAS comes to nodus to pull the files to /hdfs/40m on LDAS. ==> If the frame files are not found on ldas, it's the rsync problem. We are not controllying this file transfer. Contact with Dan Kozak

3. How to get into LDAS

Look at the LDAS account wiki page on the 40m wiki. For me "ssh -J" approach didn't work. So I used "multi-step login", starting from "ssh albert.einstein@ssh.ligo.org"

4. How the proess is running

This summarizes the workflow very well: https://wiki-40m.ligo.caltech.edu/DailySummaryHelp#Technical_info

I am still not sure how the main script "gw_daily_summary_40m" is running every 30min as well as gw_daily_summary_40m_rerun.
Otherwise, the following scripts are running via crontab of the 40m account
0,30 * * * * /home/40m/DetectorChar/bin/plot-summary-job-duration ~/public_html/detcharsummary/summaryDiag.pdf
5,35 * * * * /home/40m/DetectorChar/bin/checkstatus
6,36 * * * * /home/40m/DetectorChar/bin/plot-temperature
7,37 * * * * /home/40m/DetectorChar/bin/pushnodus
27 18 * * * /home/40m/DetectorChar/bin/cleanLogs

The produced files are not in /home/40m/public_html/detcharsummary , the data processing has a problem.
If the files are there but not pushed to the 40m (by pushnodus), the file transfer has an issue.

  17371   Wed Dec 21 12:38:32 2022 ChrisUpdateOptimal ControlIMC alignment controller testing

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

GPS times for each phase of testing were the following:

  1. slug_functional
    • Open loop 1355466269
    • Closed loop 1355466579
    • Policy 1355466987
  2. slug_hippocamp
    • Open loop 1355468210
    • Closed loop 1355468520
    • Policy 1355468849
  3. slug_hippocamp_slow
    • Open loop 1355470093
    • Closed loop 1355470403
    • Policy 1355470855
  17370   Wed Dec 21 12:35:49 2022 ChrisConfigurationCDSTiming trigger test

While recovering from the power outage, I took the opportunity to try having the timing system trigger on the rising edge of the 1 PPS signal from the GPS receiver (rather than the falling edge, as it had been doing since before the CDS upgrade). This was done in order to eliminate a timing offset between the clock used by the ADCs and the IRIG-B timestamps from the Spectracom boards. It was successful in that regard, and cleared the timing errors seen in the IOP statewords on most of the front ends.

The two exceptions were c1lsc and c1sus, where something is broken with the DuoTone readbacks. The attached plot shows the DuoTone signal in the last channel of ADC 0 on c1x01 (working normally) vs c1x02 and c1x04 (busted).

However, this change apparently also had some unexplained effect on the way the c1sbr model runs. There were frequent CPU time overruns and IPC errors. So on Sunday afternoon I reverted to the falling-edge trigger. This caused the timing errors to return, but allowed c1sbr to run normally.

  17369   Wed Dec 21 12:18:44 2022 PacoSummaryLSCFPMI locked, but FPMI BHD not locked

[Yuta, Paco]

We tried restoring the FPMI BHD readout from yesterday but failed. Below is a summary of what we did.

Steps

  1. Align arms, MICH and LO (using ITMY single bounce).
  2. Lock both CARM and DARM with POX/POY to restore the "electronic" FPMI.
  3. Lock MICH with REFL55_Q.
  4. Handoff DARM to AS55_Q and CARM to REFL55_I.
  5. Lock LO_PHASE using BH55_Q
  6. Balance BHD_DCPD to remove offset in BHD_DIFF
  7. Measure the C1:LSC-BHDC_DIFF_OUT / C1:LSC-AS55_Q_ERR ratio to get the DARM content in BHD DIFF.
  8. Attempt DARM control handoff from AS55_Q to BHDC_DIFF  --- this step didn't work today despite our several attempts.

We found LO fringe alignment to be really important, as sometimes we would try to calibrate the DARM content of BHD DIFF and found almost no coherence between AS55_Q and BHD_DIFF, but after realigning the coherence was increased and the lock was better. Another difference with respect to yesterday was the sign flip implied by the measured ratio from step 7.

Calibrated FPMI noise spectra

In anticipation to restoring FPMI BHD, we took a calibrated FPMI noise spectra (error and control point). The saved diaggui template that produces Attachment #1 is on /cvs/cds/rtcds/caltech/c1/Git/40m/measurements/LSC/FPMI/FPMI_calibrated_noise.xml Our calibration was based on sensing matrix measuring the DARM content on AS55_Q which was 1 / (2.617 * 3.64e11 counts/m) =  1.0497e-12 m/count, and the (balanced) ETM plant = 10.91e-9 / f^2 m/counts.

Next steps

Sadly we couldn't take a FPMI BHD calibrated noise spectra, but things to look into next time are

  • Take TFs for FPMI CARM, DARM and MICH loops. We skipped this today, perhaps wrongfully so.
  • Measure the FPMI sensing matrix to check demod phases and optical gains (related to the above).
  17368   Tue Dec 20 23:32:58 2022 ranaUpdateASCWFS demodulation board modification - further study

That's great - I think this solution will be best. Having the PLLs actually gives us some problems - the square wave action in these demod boards because of the ECL drives pollutes the air with all the harmonics.

In the future, it would be best to get rid of these boards and just use the new aLIGO boards with a direct LO feed.

Quote:

I played with the PLL bit more today to understand the issue. From what I understand, the following is the summary:

 

Second harmonic generation using mixer and bandpass filter

  17367   Tue Dec 20 18:27:14 2022 AnchalSummaryLSCFPMI locked, DARM calibration data taken, FPMI BHD locked!

[Anchal, Paco, Yuta]

FPMI locked with BHD readout!!!


Paco and I figured the repeatable recipe for locking FPMI today. The settings are saved as snapshot file. In short, we first lock fake FPMI using POX+POY and POX-POY and then locking MICH to REFL55_Q. We make sure there are no offsets in AS55Q or REFL55Q. Then we handoff CARM and DARM loops to 0.496*REFL55_I and 2.617*AS55_Q by changing gains on A and B paths simultaneously with tramp time of 5s. WE have pushed new measurements of CARM, DARM and MICH loop OLTFs to measurement repo.

We turned on 5 oscillators all sending calibration lines to ITMY at different frequencies to calibrate DARM readout. WE took this data for about 90 minutes and then decided to try locking FPMI with BHDC DIFF.

A simple handoff to 0.68*BHDC_DIFF at error point for DARM loop worked. The OLTF for DARM loop remained the same.

I need to run now, so more detailed elog will come later.

On another news, this was last day of Tega, a warm farewell to him.

  17366   Tue Dec 20 09:20:18 2022 PacoSummaryLSCFPMI locked and cal

[Anchal, Yuta, Paco]

Late elog (from yesterday) -- We locked FPMI, YAUX, and turned on calibration lines from gpstimes = 1355539386 to 1355539594 (lost lock because IMC unlocked angry)


We followed the steps in this elog and handed off from an electronic FPMI (POX, POY) to the RF one (REFL55 and AS55). We will continue this work today and try to finish a restore FPMI script to make it more robust.

  17365   Sat Dec 17 16:56:19 2022 AnchalUpdateASCWFS demodulation board modification - further study

I played with the PLL bit more today to understand the issue. From what I understand, the following is the summary:

Moku as VCO in WFS demod board PLL:

  • Moku input in VCO mode is actually limited to ~ +/-21 V contrary to what it says on the app (10 Vpp)
  • Whenever the VCO tuning signal goes beyond this range, Moku just ignores the input and sends a pure sine wave at the carrier frequency.
  • I think because of this rail point behavior, the PLL goes off to a bad mode where the VCO tuning signal from demod board rails to +15 or -15V, and thus Moku does nothing to correct for it.
  • I found a deterministic way of catching lock with Moku VCO:
    • With whatever carrier frequency, set the VCO slope to at least 1 MHz/V (10 MHz/V is better).
    • The VCO tuning signal most probably would rail to +15V or -15V.
    • Reduce +/- 15V supply, this moves the railing voltage with it.
    • When the voltage rails reach +/2 V, the PLL catches the lock.
    • Now slowly ramp back the power supply back to +/- 15V.
  • This way I was able to repeatedly catch the lock (see attachment 1), but of course, this can't be done when our board is mounted in the Eurocrat.
  • So I thought if I attenuate the VCO tuning signal by 20 dB and pass it through an SR560, I can control the VCO tuning signal amplitude. This approach however did not work. It was always required to reduce the +/- 15V supply to the board to catch the lock.
  • This makes me think that the phase detector chip AD9901 needs to be turned off initially or supplied with low voltage rails. I'm not sure why.
  • With this, I think we should scrap this idea of using Moku as VCO, it will be just too unreliable.
  • So we need to move to the possibility of feeding 22 MHz signals to the WFS demod board where VCO output goes.

Basically, we make our own PLL outside the board to generate 2 times LO frequency or we create 2 times LO frequency by second harmonic generation.

Moku:Pro as a frequency multiplier

This white paper from liquid instruments describes how Moku:Pro can be used as a frequency multiplier in the phasemeter app now. This functionality however has not been extended to Moku:Lab, so in 40m, we can not do this right now. If we get access to Moku:Pro, following will be required:

  • Send 11 MHz LO signal to Moku:Pro input 1 with phasemeter app on.
  • Select frequency multiplier option of 2 at the output 1. Set voltage to 2 Vpp and feed this signal to VCO RF out port on the modified demod board.
  • Leave VCO tuning port unconnected.
  • This way we would replace the internal PLL with Moku digital PLL. Moku's PLL can be run upto 10 kHz bandwidth and would be very robust for such use.

Second harmonic generation using mixer and bandpass filter

  • Split the 14 dBm 11 Mhz output from frequency generation box (I simulated this with benchtop function generator) using a splitter.
  • Send both outputs to ZP-3+ mixer (level 7).
  • Filter the output with SBP-21.4 band pass filter. Koji has measured this filter in 2013. See elog 40m/9010.
  • Amplify the output twice, first with ZFL-500HLN+ (20dB amplification), then with ZFL-1HADX (11 dB).
  • This setup provides enought output amplitude for the comparator chip AD96687 to generate clean ECL signal at 22 MHz without slipping. With only 20dB amplification, I could see the phase slip by 180 degrees enough times that the oscilloscope shows both outputs overlapped.
  • Attachment 2 shows the ICLK and QCLK signals generated by the board with this setup.

Next steps:

  • I'll modify one more board for sending in LO like this.
  • I'll test the demodulation performance of the board with LO input from the second harmonic generation.
  • Setup the optical path for AS WFS.
  17364   Fri Dec 16 22:06:55 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-16 22:06:53.830911 PST
UTC: 2022-12-17 06:06:53.830911 UTC
GPS: 1355292431.830911


Tuned on HEPA again:

PST: 2022-12-17 14:39:57.974212 PST
UTC: 2022-12-17 22:39:57.974212 UTC
GPS: 1355352015.974212


I've turned off HEPA fan and all lights at:

PST: 2022-12-17 17:26:28.740675 PST
UTC: 2022-12-18 01:26:28.740675 UTC
GPS: 1355362006.740675
 

I also started WFS relief script at this time. This script would end in 600s from the above time.

  17363   Fri Dec 16 21:55:54 2022 AnchalUpdateASCWFS demodulation board modification attempt 2 - sort of working

[Koji, Anchal]

short version: We checked signals at different points in the circuit to make sense of why it was not working. We found out that teh comparator chip AD96687BR was not working as expected and was not converting the analog signal from our VCO or LO inputs to ECL. We tested 2 other spare board with same behavior. We decided to try replacing the comparator chip with a new one, and indeed that was the issue. The new chip was working as expected and we are able to get PLL lock on the board with Moku:Lab as the VCO. However, there are some issues that need to be ironed out. The PLL does not catch lock right away and we could not figure our a systematic way of reaching to a locked state. That smells fishy to me as in my experience, when PLLs work, they work very robustly. More analysis with data and figures will follow. For now, we have some hope that this can work.

There is always the option of not closing PLL loop and injected twice the demodulation frequency at the VCO port that we have access two. For this, I'll need to create a SHG unit for 11 MHz with 21.4 MHz BLP. I'll look into this solution as well.

  17362   Fri Dec 16 18:48:49 2022 yutaSummaryGeneralIFO alignment after power loss

[Paco, Yuta]

We have recovered the IFO alignment (FPMI and BHD) for the first time after the power loss on Dec 15th 11:30 AM PST.

PMC and IMC transmission
~>cdsutils avg -s 10 C1:PSL-PMC_PMCTRANSPD C1:IOO-MC_TRANS_SUMFILT_OUT
C1:PSL-PMC_PMCTRANSPD 0.7332153499126435 0.0004376671844386436
C1:IOO-MC_TRANS_SUMFILT_OUT 14370.22451171875 38.87278766402092

BHDC PDs with LO beam only
~>cdsutils avg -s 10 C1:HPC-BHDC_A_OUT C1:HPC-BHDC_B_OUT
C1:HPC-BHDC_A_OUT 111.07633819580079 2.916326545853983
C1:HPC-BHDC_B_OUT 96.85788955688477 2.4419271045522506

Arm transmissions
~>cdsutils avg -s 10 C1:LSC-TRY_OUT C1:LSC-TRX_OUT
C1:LSC-TRY_OUT 1.0163812279701232 0.02008742269699207
C1:LSC-TRX_OUT 0.9274496018886567 0.027689954466601815

MICH fringe with ETM misaligned
See Attachment #1

LO-ITMX single bounce fringe with ITMY misaligned
See Attachment #2

  17361   Fri Dec 16 14:52:42 2022 PacoSummarySUSMC1 and MC3 coil dewhitening filters added, location corrected

I corrected the filter module location for 28 Hz ELP filter on MC1 and MC3 coil output filter banks to FM8 (from FM9). FM9 is always reserved for SimDW (which is simulated dewhitening filter and is supposed to be a copy of the dewhitening filter on the analog side). FM10 is also reserved for InvDW filter which performs the anti-dewhitening before DAC. This filter module, FM10, shoudl remain on always. When FM9 is on (SimDW), the analog dewhitening turns off and we get a flat digital response as well. When FM9 is off, the analog dewhitening is turned on. Nominal operation configuration right now is to not use the coil dewhitening and keep FM9 and FM10 on always.

 

  17360   Thu Dec 15 08:37:52 2022 JCUpdateDaily ProgressIMC Misalignment

PMC seems to have gotten very misaligned over the last 12 hours. I'm going in to align now.

  17359   Wed Dec 14 17:01:39 2022 PacoSummaryLSCFPMI in the post-cds upgrade era

[Paco, Anchal, Koji]

A possible long-hidden bug of MC2 dewhitening switching was found and fixed.
MC2 coil dewhitenings were always on without proper compensation.
MC1/3 also had a similar issue.
Now "SimDW" and "IncDW" filters were set on FM9 and FM10, and they properly deal with the DW state, which is switched by FM9.


We tried restoring FPMI configuration this afternoon. For this we tried the following:

1. Lock PSL to YARM (through MC2) using the CARM LSC filter.
    a. Input: 1 from POY11_I
    b. Output: -17.5  to MC2
    c. Gain: 0.009
    d. Locking FM: FM5 only
    f. Trigger: TRY with 0.3, 0.1 thresholds
    e. FM Trigger: FM1, FM2, FM3, FM6, and FM8
2. We lock XARM to PSL (through ETMX) using the DARM LSC filter.
3. A simple handoff of the error and control points didn't work at first.

    a. We decided to look at the actuation strength of MC2 relative to ETMY. By locking the YARM using POY11, we measured the actuation transfer functions on two control points ETMY and MC2  referenced to the YARM cavity. Our expectation was a flat response in the ETMY control point, and a scaled, nominally flat response on MC2 so the ratio between the two give us the right output gain.
    b. A first suprise was found when exciting at MC2; here we observed a steep frequency dependent response, which suggested the MC2 actuation was weaker by over an order of magnitude.... Since this didn't make sense, after a little investigation and Koji's help, we figured out the issue was with the MC2_COIL SimDW and InvDW filters! These filters were on FM7 and FM8, but their outputs were not affecting the state of the analog electronics DW filter! After reviewing the model and comparing against ETMY, we figured we should change them to FM9 and FM10. This change successfully addressed the bogus frequency dependence (which was just the oblivious electronic DW filter gain).

  17358   Wed Dec 14 12:37:20 2022 RadhikaUpdateALSXARM green laser lock debugging

On Monday I aimed to measure the transfer function of the x-arm AUX PDH loop while momentarily locked, with a Moku:Go. I re-aligned the XEND green beam input to the arm cavity with M1 and M2 steering mirrors. I got GTRX to ~1.4 and the TEM00 mode nominally locked (back to ~5 seconds of lock, like last time). Previously Paco and I had achieved transmission of 3, so there was still a good way to go in mode matching. 

However I noticed the backwards-propagating beam started to drift relative to the opening of the Faraday isolator (located after the shutter). During manual alignment the backwards beam cleared through the aperture of the FI, but around 5 minutes later it had drifted too high and the beam spot was visible against the FI body, missing the aperture. At this point transmission had dropped to 0, and I realigned the beam to clear through the opening. I tried to further increase transmission but the drift continued to occur within a few minutes of re-alignment. I double checked that there was no dithering of ITMX or ETMX. It seemed there was high residual motion of the ETM, but I was not sure how to decrease this (damping filters were on). I moved on to setting up the TF measurement and decided to return to alignment once the loop excitation was configured.

I chose to inject an excitation from the Moku at the error point of the PDH servo box. I set up the measurement from 100 kHz to 100 Hz, zoomed in around the loop UGF. I passed the mixer output / error signal (alpha) to a T-splitter and sent one copy to input A of an SR560, and routed the Moku excitation to input B. The summed output of the SR560 was sent to the PDH servo input (beta). I passed the second copy of the error signal (alpha) to the Moku, along with the servo input monitor signal (beta) from the PDH box. The Moku measured the transfer function alpha/beta to obtain G_OLG. 

I returned to align the green beam and recovered flashing of the TEM00 mode. However when I closed the loop (with excitation), it didn't catch lock. I quickly reverted the loop back to its original state and confirmed that TEM00 locked for ~5 seconds. This made me think the excitation signal was too large relative to the error signal, so I reduced its amplitude to 500 mVpp. This still didn't recover the lock, and at this point the alignment had drifted again so I decided to wrap up. 

TODO:

- Investigate alignment drift; confirm ITM/ETM motion within expected range
- Recover GTRX of ~3
- Calculate optimal excitation amplitude relative to error signal
- Inject excitation at control point if the previous step doesn't recover lock.

I am working remotely for the next week, so I can carry out these steps in January.

 

  17357   Tue Dec 13 23:49:17 2022 AnchalUpdateSUSLow noise state

I've turned off HEPA fan and all lights at:

PST: 2022-12-13 23:49:12.955214 PST
UTC: 2022-12-14 07:49:12.955214 UTC
GPS: 1355039370.9552


Turned HEPA back on:

PST: 2022-12-14 10:47:49.944161 PST
UTC: 2022-12-14 18:47:49.944161 UTC
GPS: 1355078887.944161

  17356   Fri Dec 9 23:44:14 2022 ranaSummaryASCMC WFS sensing matrix measurement

with the new output matrix, we repeated the diagonalization script that Anchal ran previously. In the attached plot you can see that as we successively apply offsets to the WFS1, WFS2, and MC_TRANS Pitch loops, there is the offset in the loop we offset, but there is no appreciable step seen in the other loops.

Maybe we could do better, but this is the best DC diagonalization I have ever seen in this system. So we should just keep it for now.

At some point, we should run this procedure for YAW as well, but not urgent.

 

  17355   Fri Dec 9 21:54:40 2022 RadhikaUpdateASCMoku digital filter for low-frequency resonances (ALS/calibration)

[Radhika, Paco]

I modeled a digital filter for adding a resonance at a desired frequency (Q~100), with a complex-conjugate pole pair and 2 real zeros (2nd order system). Paco suggested I start with a 575 Hz resonance. I loaded the digital filter onto the Moku using the Moku python API (script at labutils/moku/mokuGoPro/mokuDigitalFilter.py). I tested the filter by feeding the Moku a 2 Vpp signal around 575 Hz and looking for some noticeable gain - however the signal passed though unchanged. There might be an additional Moku command for enabling the filter - I'll look into this.

TODO:

- Debug deployment of digital filter to Moku:Go
- Test on preset low-pass filter, before custom filter
- Once successful, add multiple resonances helpful for calibration
- Deploy filters in xarm AUX-PDH loop
ELOG V3.1.3-