40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 31 of 339 Not logged in
ID Date Author Type Category Subject
16928   Fri Jun 17 13:07:08 2022 KojiUpdateBHDComparison of MICH OLTF model with measurement

I'm curious why the actual OLTF included the 60Hz comb...? It is undesirable to have such structure in the OLTF around the UGF as it can cause servo instability.
And if you remove them, you don't need to model them :-)

16932   Tue Jun 21 14:17:50 2022 yutaConfigurationBHDBHD DCPDs re-routed to c1sus2

After discussing with Anchal, we decided to route BHD related PD signals directly to ADC of c1sus2, which handles our new suspensions including LO1, LO2, AS1, AS4, so that we can control them directly.
BHD related PD signals will be sent to c1lsc for DARM control.

Re-cabling was done, and now they are online at C1:X07-MADC1_EPICS_CH16 (DC PD A) and CH17 (DC PD B) with 15ft DB9 cable.
Here, DC PD A is the transmission of BHD BS for AS beam, and DC PD B is the reflection of BHD BS for AS beam (see attached photo).

Attachment 2: BHDDCPDs.JPG
16935   Tue Jun 21 21:17:16 2022 yutaUpdateBHDRTS models for BHD added but PCIE error remaining

[Anchal, Yuta]

RTS models for BHD homodyne phase control (c1hpc) and angular control (c1bac) are created and added to c1sus2.
c1su2 and c1lsc models were modified accordingly.
We still have issues with IPC PCIE connection sending DCPD A and B signals to c1lsc and DC error 0x2000 in c1su2 model.

c1hpc (host: c1sus2) Attachment #1
This model is for homodyne phase control.
It can dither LO1, LO2, AS1, AS4 in POS and demodulate mixture of DCPD A/B signals for the phase control to feedback to those optics.
It also sends DCPD A/B signals to c1lsc via cdsIPCx_PCIE.
Dither and controls signals are sent to the optics via cdsIPCx_SHMEM.

c1bac (host: c1sus2)
This model is for BHD angular control.
It is basically the same as c1hpc, but it is for PIT and YAW dithering of LO1, LO2, AS1, AS4.

c1su2 (host: c1su2) Attachment #2
LSC and ASCPIT/YAW feedback signals from c1hpc and c1bac via shared memory were added to send them to corresponding optics.
Somehow Mux/Demux didn't work to send SHMEM signals inside the subsystem in the Simulink model (this works for ADC, but probably not for IPC stuff?), and we had hard time make-install-ing this model.

c1lsc (host: c1lsc) Attachment #3
DCPD A/B signals from c1hpc via PCIE were added for our new error signals for LSC.

Starting and restarting the models
After having some troubles make-install-ing modified models (be careful of goto and from tags!), we stopped all the models in c1sus, c1ioo, c1lsc, c1sus2 and started all of them, including new c1hpc and c1bac models.
This somehow created RFM errors in c1scx and c1scy.
So, we proceeded to do the same step we did in 40m/16887 and 40m/15646, now including c1sus2 for the restart.
Initial attempt made c1lsc, c1sus, c1ioo mostly red, so scripts/cds/rebootC1LSC.sh was run again on pianosa.
RFM issues for c1scx and c1scy were solved.
Shared memory within c1sus2 seems to be working, but sending DCPD A/B signals from c1hpc to c1lsc is not working (see Attachement #4).

Next:
- Fix C1:HPC-LSC_DCPC_A/B issue
- Make/modify MEDM screens

Attachment 1: Screenshot_2022-06-21_20-12-55_C1HPC.png
Attachment 2: Screenshot_2022-06-21_20-14-56_C1SU2.png
Attachment 3: Screenshot_2022-06-21_20-13-38_C1LSC.png
Attachment 4: Screenshot_2022-06-21_20-34-44_RED.png
16938   Wed Jun 22 14:44:03 2022 AnchalUpdateBHDFixed DC error in c1su2, added new library model for suspensions

The 0x2000 error in c1su2 happens whenever we make it and install it as the default data acquisition rates are too much in the suspension model. Earlier we used activateSUS2DQ.py to fix this. I followed the suggestion in 40m/16537 to include COIL_OUT at 16k, damping channels at 256 Hz and OL channels at 1024 Hz. I created new suspension model at /cvs/cds/rtcds/userapps/trunk/sus/c1/models/lib/sus_single_control_new.mdl. The model also contains filter modules names C1SUS_OPT_BIASPOS, C1SUS_OPT_BIASPIT, C1SUS_OPT_BIASYAW which acts on the alignment offsets so that a low pass filter can be added there and alignment offsets always happen slowly. The new suspension model is now used inc1su2 for teh 7 new suspensions, and now the model starts without errors.

Still remaining to fix: IPC communication between c1hpc and c1lsc.

16954   Tue Jun 28 14:24:23 2022 yutaUpdateBHDBHD DC PD signals now also sent to c1lsc to circumvent IPC error

[JC, Yuta]

To circumvent IPC error sending BHD DC PD signals from c1sus2 to c1lsc, DB9 cable from BHD DC PD box sent to c1sus2 is now split and sent also to c1lsc.
They are now available in both

C1:X07-MADC1_EPICS_CH16 (DC PD A) and CH17 (DC PD B)

C1:X04-MADC1_EPICS_CH4 (DC PD A) and CH5 (DC PD B)

Next:
- Add battery powered SR560 to decouple c1sus2 and c1lsc to avoid the ground loop

Attachment 1: C1LSC.JPG
Attachment 2: C1SUS2.JPG
Attachment 3: Screenshot_2022-06-28_16-03-16_BHDDCPDcopied.png
16960   Tue Jun 28 22:27:11 2022 YehonathanUpdateBHDMeasurement of input and output electronics noise

{Yuta, Yehonathan}

For MICH noise budgeting we measure the input electronics noise which includes the AS55 RFPD, preamp, demod board, the whitening, and the AA filters, and the ADC noises. To do so we simply close the laser shutter and take the spectrum of C1:LSC-AS55_I_ERR_DQ and C1:LSC-AS55_Q_ERR_DQ shown in attachment 1.

Next, we measured the output electronics noise which includes the DAC, dewhitening and AI filters, and coil driver noises. We disabled the BS watchdog and went to 1X4 rack. We measured the spectrum of one of the lemo outputs on the BS coil driver module using an SR785. Attachment 2 shows the spectrum together with the SR785 dark noise.

Attachment 1: input_noise_spectrum.pdf
Attachment 2: output_noise_spectrum.pdf
16961   Tue Jun 28 23:10:34 2022 YehonathanUpdateBHDMeasurement of AS55 demod board conversion factor

{Yuta, Yehonathan}

We measured the AS55 demod board conversion from the amplitude of a 55MHz signal to a demodulated signal. We hooked the unused REFL55 LO into the PD input port on the AS55 demod board.

The REFL55 LO was measured to be 1.84 Vpp. The IQ outputs were: I = 0.86 Vpp, Q = 2.03 Vpp giving an amplitude of 2.205 Vpp. The overall conversion factor is sqrt(0.86**2+2.03**2)/(1.82/2)=2.422.

We also set to measure the loss in the RF cable from AS55 PD to the demod board on 1Y2. REFL55 was connected with a long BNC cable to the input of the cable under test. REFL55 at the input was measured to be 1.466 Vpp and 1.28 Vpp at the output signifying a transmission of 87.6%.

16984   Mon Jul 11 11:56:40 2022 he YehonathanUpdateBHDMICH AS55 noise budget

I calculated a noise budget for the MICH using AS55 as a sensor. The calculation includes closed-loop TF calculations.

The notebook and associated files can be found on https://git.ligo.org/40m/bhd/-/blob/master/controls/compute_MICH_noisebudget.ipynb.

Attachment 1 shows the loop diagram I was using. The equation describing the steady-state of the loop is

$\left[\mathbb{I}-G \right]\begin{pmatrix} \gamma \\ \delta \\ \Delta\end{pmatrix} = \begin{pmatrix} \alpha \\ \beta \\ \epsilon\end{pmatrix}$

, where G is the adjacency matrix given by

$G=\begin{pmatrix} 0 & 0 & AE_2\\ 0 & 0 & BE_2 \\ E_1C & E_1D & 0 \end{pmatrix}$

First, the adjacency matrix G is constructed by stitching the small ABCDE matrices together. Once the inverse of (I-G) is calculated we can simply propagate any noise source to $\delta$ and then calculate $\left[\mathbb{I}-E(CA+DB)\right]B^{-1}\delta$ to estimate the displacement of the optics.

Attachment 2 shows the calculated noise budget together with Yuta's measurement.

All the input and output electronics are clumped together for now. Laser noise is irrelevant as this is a heterodyne measurement at 55MHz.

It seems like there is some mismatch in the calibration of the optical gain between the measurement and model. The missing noise at 3-30Hz could be due to angle-to-length coupling which I haven't included in the model.

Attachment 1: Control_Diagram.pdf
Attachment 2: MICH_AS55_Noise_Budget.pdf
16989   Tue Jul 12 09:14:50 2022 ranaUpdateBHDMICH AS55 noise budget

Looking good:

• I think the notches you see in he measured noise are a clue as to the excess noise source. You can try turning some notches on/off.
• Laser noise does matter a bit more subtley: the low freq noise couples to AS55 through the RMS deviation of the MICH loop from the zero crossing, and the noise of the 55 MHz modulation.
• Jitter in the IMC couples to MICH through the misalignment of the Michelson.
• As you rightly note, the optical lever feedback on the ITMs and BS also make length noise through the suspension actuator imbalance and the spot mis-centering.
16996   Wed Jul 13 10:54:39 2022 YehonathanUpdateBHDMICH AS55 noise budget

I fixed some mistakes in the budget:

1. The BS pendulum resonance was corrected from 0.8Hz to 1Hz

2. Added missing X3 filter in the coil filters

3. Optical gain is now computed from MICH to AS55 instead of BS to AS55 and is calculated to be: 9.95e8 cts/m.

4. Coil driver gain is still unmeasured but it is found to be 1.333 to make the actuation calibration from BS to MICH match the measurement (see attachment 1).

Attachment 2 shows the resulting MICH OLTF.

Laser noise was added to the budget in a slightly ad-hoc fashion (will fix later): Yuta and I measured MC_F and computed MC_F*(Schnupp asymmetry)/(Laser frequency). Attachment 3 shows the updated noise budget.

Attachment 1: BS_MICH_ACtuation_Calibration.pdf
Attachment 2: MICH_AS55_Model_Measurement_Comparison.pdf
Attachment 3: MICH_AS55_Noise_Budget.pdf
16999   Wed Jul 13 13:30:48 2022 YehonathanUpdateBHDadd Laser RIN to MICH budget

the main laser noise coupling for a Michelson is because of the RIN, not the frequency noise. You can measure the RIN, in MC trans or at the AS port by getting a single bounce beam from a single ITM.

17013   Mon Jul 18 16:49:57 2022 YehonathanUpdateBHDadd Laser RIN to MICH budget

I measured the RIN by taking the spectrum of C1:MC_TRANS_SUMFILT_OUT and dividing it by the mean count on that channel (~13800 cts). Attachment 1 shows the result.

I updated the MICH AS55 noise budget but got a very low contribution (gold trace in attachment 2).

It seems too low I think. What could've gone wrong? Finesse calculates that the transfer function from laser amplitude modulation to AS55 is ~ 1.5e-9 at DC. If I turn off HOMs I get 1e-11 at DC, so this coupling is a result of some contrast defect. Should I include some RMS imbalances in the optics to account for this? Should I include it as a second-order effect due to MICH RMS deviation from zero crossing?

 Quote: the main laser noise coupling for a Michelson is because of the RIN, not the frequency noise. You can measure the RIN, in MC trans or at the AS port by getting a single bounce beam from a single ITM.

Attachment 1: Laser_RIN.pdf
Attachment 2: MICH_AS55_Noise_Budget.pdf
17015   Mon Jul 18 18:33:38 2022 KojiUpdateBHDadd Laser RIN to MICH budget

You should measure the coupling by noise injection. Noise budgeting does not need any modeling:

1) Measure the power spectrum density of the target signal (i.e. DARM) and the source noise (i.e. RIN this case)

2) Calibrate both using a calibration peak to convert 1) into the physical units (m/rtHz, 1/rtHz, etc)

3) Measure the transfer function from source to target using the noise injection. (i.e. RIN injection this case and look at the injection to RIN and injection to DARM)

4) Measure open-loop transfer functions if necessary. (i.e. DARM control open-loop transfer function to convert the error signal into the free running noise level)

Primarily, these are measured noise levels and noise couplings there is no room to involve a model there.
Once the noise budget was done, you can compare it with the model and say "the coupling is big/small/comparable".

Also, why don't you use C1:MC_TRANS_SUMFILT_IN1_DQ instead? Your _OUT signal seems affected by the bunch of comb notch filters to artificially remove the 60Hz harmonics. It's not a fair RIN measurement.

17018   Tue Jul 19 16:00:34 2022 yutaConfigurationBHDFast channels for BHD DCPDs now available in c1lsc but not in c1hpc

[Paco, Anchal-remote-support, Yuta]

We added fast channels to BHD DC PDs.
C1:LSC-DCPD_(A|B)_IN1 are now available, but C1:HPC-DCPD_(A|B)_IN1 still gives us zero.

c1hpc situation -> not good
- We can see the slow signal at C1:X07-MADC1_EPICS_CH16 (DC PD A) and CH17 (DC PD B)
- C1:HPC-DCPD_(A|B)_IN1 is there, but zero.
- We have modified c1hpc model to add DCPD_(A|B) filters in front of the input matrix (see Attachment #1).
- After modifying the model, we run
ssh c1sus2 rtcds make c1hpc rtcds install c1hpc ssh fb1 sudo systemctl restart daqd_*

- After this, we got 0x2000 error. So, we ran the following. This removed 0x2000 error, but DCPD signals are still zero. They are also not available in C1HPC-MONITOR_ADC1.adl screen (see Attachment #3).
ssh c1sus2 rtcds restart c1hpc

c1lsc situation -> good
- We could see the slow signal at C1:X04-MADC1_EPICS_CH4 (DC PD A) and CH5 (DC PD B), and also C1:LSC-DCPD_(A|B)_NORM after making C1:LSC-DCPD_(A|B)_POW_NORM=1. The ADC channel and DCPD channel are exactly the same.
- After confirming the above, we modified the c1lsc model to add DCPD_(A|B) filters in front of the input matrix (see Attachment #2).
- After modifying the model, we run
ssh c1lsc rtcds make c1lsc rtcds install c1lsc ssh fb1 sudo systemctl restart daqd_*

- After this, we also got 0x2000 error. We also noticed that, for example, C1:X04-MADC0_EPICS_CH31 and C1:LSC-ASDC_INMON are different, which used to be the same (ASDC_INMON was largely attenuated).
- In the end, we run the following to remove 0x2000 error, but it crashed c1lsc, as well as c1sus, c1ioo.
ssh c1lsc
rtcds restart c1lsc

- So, we did rebootC1LSC.sh. This made c1lsc, c1ioo and c1sus as green as before, except for RFM issue in TRX/TRY, like we saw in June. We followed the steps in 40m/16887 to hard reboot c1iscex/c1iscey and ran rebootC1LSC.sh again. This made C1CDS_FE_STATUS.adl screen as green as before (see Attachment #3).

- Fast channels C1:LSC-DCPD_(A|B)_IN1 are now available. They are also available in C1LSC-MONITOR_ADC1.adl screen (see Attachment #3).

Attachment 1: Screenshot_2022-07-19_14-26-39_c1hpc.png
Attachment 2: Screenshot_2022-07-19_14-24-49_c1lsc.png
Attachment 3: Screenshot_2022-07-19_15-51-25_GreenGreen.png
17020   Tue Jul 19 18:41:42 2022 yutaUpdateBHDContrast measurements for Michelson and ITM-LO

[Paco, Yuta]

We measured contrast of Michelson fringe in both arms locked and mis-aligned. It was around 90%.
We also measured the contrast of ITM single bounce vs LO beam using BHD DC PDs. It was around 43%.
The measurement depends on the alignment and how to measure the maximum and minimum of the fringe. ITM-LO fringe was also not stable because motions of AS/LO mirrors are large. More tuning necessary.

Background
- As measured in elog 40m/17012, we see a lot of CARM in AS, which indicates large contrast defect.
- We want to check mode-matching of LO beam to AS beam.

BHD DC PD conditioning
- We added DCPD_A and DCPD_B to /opt/rtcds/caltech/c1/scripts/LSC/LSCoffsets3 script, which zeros the offsets when shutters are closed.
- We also set C1:LSC-DCPD_(A|B)_GAIN = -1 since they are inverted.

Contrast measurement
- Contrast was measured using channels ['C1:LSC-ASDC_OUT','C1:LSC-POPDC_OUT','C1:LSC-REFLDC_OUT','C1:LSC-DCPD_A_OUT','C1:LSC-DCPD_B_OUT']. For LO, only DCPD_(A|B) are used.
- We took 15%-percentile (40% for ITM-LO fringe) from the maximum and minimum of the data, and took the median to estimate the maximum value and the minimum value (see Attachment).
- Contrast = (Imax - Imin) / (Imax + Imin)
- We measured three times in each configuration to estimate the standard error.
- Jupyter notebook: https://git.ligo.org/40m/scripts/-/blob/main/CAL/BHD/measureContrast.ipynb

Results
Both arms locked, MICH fringe (15% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 89.75 +/- 0.17 %
Contrast measured by C1:LSC-POPDC_OUT is 79.41 +/- 0.86 %
Contrast measured by C1:LSC-REFLDC_OUT is 97.34 +/- 0.34 %
Contrast measured by C1:LSC-DCPD_A_OUT is 95.41 +/- 1.55 %
Contrast measured by C1:LSC-DCPD_B_OUT is 89.76 +/- 1.49 %
Contrast measured by all is 90.34 +/- 1.68 %

Both arms mis-aligned, MICH fringe (15% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 89.32 +/- 0.57 %
Contrast measured by C1:LSC-POPDC_OUT is 94.55 +/- 0.62 %
Contrast measured by C1:LSC-REFLDC_OUT is 97.95 +/- 1.37 %
Contrast measured by C1:LSC-DCPD_A_OUT is 96.40 +/- 1.04 %
Contrast measured by C1:LSC-DCPD_B_OUT is 90.98 +/- 1.07 %
Contrast measured by all is 93.84 +/- 0.94 %

ITMY-LO fringe (40% percentile)
Contrast measured by C1:LSC-DCPD_A_OUT is 45.51 +/- 0.45 %
Contrast measured by C1:LSC-DCPD_B_OUT is 38.69 +/- 0.43 %
Contrast measured by all is 42.10 +/- 1.03 %

ITMX-LO fringe (40% percentile)
Contrast measured by C1:LSC-DCPD_A_OUT is 46.65 +/- 0.65 %
Contrast measured by C1:LSC-DCPD_B_OUT is 39.82 +/- 0.51 %
Contrast measured by all is 43.24 +/- 1.45 %

Discussion
- As you can see from the attachment, REFLDC is noisy and over estimating the contrast. ASDC is reliable. We need to tune the threshold to measure the maximum value and minimum value. We should also use the mode instead of median.
- Contrast depends very much on the alignment. We didn't tweak too much today.
- ITM-LO fringe was not stable, probably due to too much motion in AS1, AS4, LO1, LO2. Their damping needs to be re-tuned.

Next:
- Model FPMI sensing matrix with measured contrast defect
- Estimate AS-LO mode-mismatch using the measured contrast
- Lock ITM-LO fringe using DCPD_(A|B) as error signal, and ITM or LO1/2 as actuator
- Lock MICH with DCPD_(A|B), and with LO beam
- Get better contrast data with better alignment and better AS1, AS4, LO1, LO2 damping

Attachment 1: ContrastMeasurements.pdf
17024   Wed Jul 20 18:07:52 2022 PacoUpdateBHDBHD MICH test

[Paco, Yuta, JC]

We did some easy tests on the BHD readout in preparation for BHD MICH. With the arm cavities and LO beam misaligned, but the MICH aligned, we measured the transfer function from C1:LSC-DCPD_A_OUT to C1:LSC-DCPD_B_OUT to get a rough estimate of the gain balance: 1.8 * DCPD_A = DCPD_B. We then locked MICH using REFL55_Q and looked at

• A=C1:LSC-DCPD_A_OUT
• B=C1:LSC-DCPD_B_OUT
• 1.8 * A - B (which we encoded using C1:LSC-PRCL_A_IN1)
• 1.8 * A + B (which we encoded using C1:LSC-PRCL_B_IN1)

namely the DCPD BHD signals. After turning the MICH_OSC on (2000 gain @ 311.1 Hz), we took some power spectra under the following three configurations:

1. LO misaligned, no MICH offset.
2. LO overlap, no MICH offset.
3. LO overlap and MICH offset.

For 1. the expectation was that since LO is misaligned and the AS port is dark, we would get no signal. In 2., however both A and B would might see some incoherent signal, but still no MICH. Finally in 3. all signals should be able to see MICH, including A-B. Attachment #1 shows the measurements 1, 2, and 3 (offset = -5.0). Then, with increasing offset values, the BHD MICH signals increased as well; discussion to follow.

Attachment 1: BHD_MICH_OSC.pdf
17025   Thu Jul 21 21:50:47 2022 TegaConfigurationBHDc1sus2 IPC update

IPC issue still unresolved.

Updated shared memory tag so that 'SUS' -> 'SU2' in c1hpc, c1bac and c1su2. Removed obsolete 'HPC/BAC-SUS' references from IPC file, C1.ipc. Restarted the FE models but the c1sus2 machine froze, so I did a manual reboot. This brought down the vertex machines---which I restarted using /opt/rtcds/caltech/c1/scripts/cds/rebootC1LSC.sh---and the end machines which I restarted manually. Everything but the BHD optics now have their previous values. So need to burtrestore these.

# IPC file:
/opt/rtcds/caltech/c1/chans/ipc/C1.ipc

# Model file locations:
/opt/rtcds/userapps/release/isc/c1/models/isc/c1hpc.mdl
/opt/rtcds/userapps/release/sus/c1/models/c1su2.mdl
/opt/rtcds/userapps/release/isc/c1/models/isc/c1bac.mdl

# Log files:
/cvs/cds/rtcds/caltech/c1/rtbuild/3.4/c1hpc.log
/cvs/cds/rtcds/caltech/c1/rtbuild/3.4/c1su2.log
/cvs/cds/rtcds/caltech/c1/rtbuild/3.4/c1bac.log

SUS overview medm screen :

• Reduced the entire screen width
• Revert to old screen style watchdog layout
17026   Fri Jul 22 15:05:26 2022 TegaConfigurationBHDc1sus2 shared memory and ADC fix

[Tega, Yuta]

We were able to fix the shared memory issue by updating the receiver model name from ''SUS' to 'SU2' and the ADC zero issue by including both ADC0 and ADC1 in the c1hpc and c1bac models as well as removing the grounding of the unused ADC channels (including chn#16 and chn#17 which are actually used in c1hpc) in c1su2. We also used shared memory to move the DCPD_A/B error signals (after signal conditioning and mixing A/B; now named A_ERR and B_ERR) from c1hpc to c1bac.
C1:HPC-DCPD_A_IN1 and C1:HPC-DCPD_B_IN1 are now available (they are essentially the same as C1:LSC-DCPD_A_IN1 and C1:LSC-DCPD_B_IN1, except for they are ADC-ed with different ADC; see elog 40m/16954 and Attachment #1).
Dolphin IPC error in seding signal from c1hpc to c1lsc still remains.

Attachment 1: Screenshot_2022-07-22_15-04-33_DCPD.png
Attachment 2: Screenshot_2022-07-22_15-12-19_models.png
Attachment 3: Screenshot_2022-07-22_15-15-11_ERR.png
Attachment 4: Screenshot_2022-07-22_15-32-19_GDS.png
17028   Fri Jul 22 17:46:10 2022 yutaConfigurationBHDc1sus2 watchdog update and DCPD ERR channels

[Tega, Yuta]

We have added C1:HPC-DCPD_A_ERR and C1:HPC-DCPD_B_ERR testpoints, which can be used as A+B, A-B etc.
Restarting c1hpc crashed c1sus2, and also made c1lsc/ioo/sus models red.
We run /opt/rtcds/caltech/c1/Git/40m/scripts/cds/restartAllModels.sh to restart all the machines. It worked perfectly without manually pressing power buttons! Wow!

We have also edited /opt/rtcds/caltech/c1/medm/c1su2/C1SU2_WATCHDOGS.adl so that it will use new /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/medm/resetFromWatchdogTrip.sh instead of old /opt/rtcds/caltech/c1/scripts/SUS/damprestore.py.

Attachment 1: Screenshot_2022-07-22_17-48-25.png
17033   Mon Jul 25 17:58:10 2022 TegaConfigurationBHDc1sus2 IPC dolphin issue update

From the 40m wiki, I was able to use the instructions here to map out what to do to get the IPC issue resolved. Here is a summary of my findings.

I updated the /etc/dis/dishost.conf file on the frame builder machine to include the c1sus2 machine which runs the sender model, c1hpc, see below. After this, the file becomes available on c1sus2 machine, see attachment 1, and the c1sus2 node shows up in the dxadmin GUI, see attachment 2. However, the c1sus2 machine was not active. I noticed that the log file for the dis_nodemgr service, see attachment 3, which is responsible for setting things up, indicated that the dis_irm service may not be up, so I checked and confirmed that this was indeed the case, see attachment 4. I tried restarting this service but was unsuccessful. I restarted the machine but this did not help either. I have reached out to Jonathan Hanks for assistance.

Attachment 1: Screen_Shot_2022-07-25_at_5.43.28_PM.png
Attachment 2: Screen_Shot_2022-07-25_at_5.21.10_PM.png
Attachment 3: Screen_Shot_2022-07-25_at_5.30.58_PM.png
Attachment 4: Screen_Shot_2022-07-25_at_5.35.19_PM.png
17034   Mon Jul 25 18:09:41 2022 TegaConfigurationBHDBHD Homodyne Phase control MEDM screen

[Paco, Tega, Yuta]

Today, we made a custom MEDM screen for the BHD Homodyne Phase Control, which is basically an overview of the c1hpc model. See Attachments 1 & 2 for details.

Attachment 1: Screen_Shot_2022-07-25_at_6.12.08_PM.png
Attachment 2: Screen_Shot_2022-07-25_at_6.18.09_PM.png
17037   Tue Jul 26 20:54:08 2022 PacoUpdateBHDBHD MICH test - LO phase control

[Yuta, Paco]

## TL;DR Successfully controlled LO phase, and did BHD-MICH readout with various MICH offsets and LO phases.

Today we implemented a DCPD based LO phase control. First, we remeasured the balancing gain at 311.1 Hz (the MICH oscillator freq) and combined C1:HPC-DCPD_A_OUT with C1:HPC-DCPD_B_OUT to produce the balanced homodyne error signal (A-B). We feed this error signal to C1:HPC-LO_PHASE_IN1 and for the main loop filters we simply recycled the LSC-MICH loop filters FM2 through FM5 (we also copied FM8, but didn't end up using it much). Then, we verified the LO phase can be controlled by actuating either on LO1 or LO2. For LO2, we added an oscillator in the HPC LOCKINS at 318.75 Hz (we kept this on at 1000 counts for the measurements below).

The LO phase control was achieved with a loop gain in the range of 10-30 (we used 20), no offset, and FM4, and FM5 engaged. FM2 can be added to boost, but we usually skipped FM3. Then, we went through a set of measurements similar to the ones described in a previous elog. A key difference with respect to the measurements from before is that we locked MICH using AS55Q (as opposed to REFL55Q). This allowed us to reach higher MICH offsets without losing lock. After turning on the MICH oscillator at 3000 counts, we looked at:

1. LO misaligned + MICH at dark fringe (offset = -21).
• Here, we don't expect to see any MICH signal and indeed we don't, except for a small residual peak from perhaps a MICH offset or slightly imbalanced PDs.
2. LO aligned, but uncontrolled + MICH at dark fringe (offset = -21).
• Here we would naively expect MICH to show up in A-B, but because of the uncontrolled LO phase, we mostly see the noise baseline (mostly from LO RIN? ...see measurement 3) under which this signal is probably buried. Indeed, the LO fringe increased noise in A, B, and A-B but not in A+B. This is nice.
3. LO aligned, but uncontrolled + MICH with dc readout (offset = +50).
• Here we expected the MICH signal to show up due to the large offset, and we can indeed see it in A, B, and A+B, but not in A-B. Nevertheless we see almost exactly the same noise level even though we allow some AS light into the BHD readout, so maybe the noise observed in the A-B channel from measurements 2 and 3 is mostly from LO RIN. This needs further investigation...
4. LO aligned, controlled at no offset + MICH with dc readout (offset = +50).
• In general here we expected to see a noise reduction in the A-B channel since the LO fringe is stable, and a MICH signal should appear. Furthermore, since LO phase is under control, we expect the LO2 Oscillator to appear which it does for this and the following measurements. Because of the relative freedom, we tried this measurement in two cases:
1. When feeding back to LO1
• We actually see MICH in the A-B channel, as expected, after the noise level dropped by ~ 5. We also observed small sidebands +- 1 Hz away from the MICH peak, probably due to local damping in either LO or AS paths.
2. When feeding back to LO2
• We also see MICH here, with a slightly better drop in noise (relative to feeding back to LO1). Sidebands persisted here, but around at +- 2 Hz.
5. LO aligned, controlled (offset = 10) + MICH with dc readout (offset = +50). *
• Here, we expected the A-B MICH content to increase dramatically, and indeed it does after a little tuning of the LO phase . The noise level decreased slightly because LO phase noise is decreased around the optimal point.
6. LO aligned, controlled (offset = 20) + MICH with dc readout (offset = +30). *
• Here, we naively expected A+B MICH content to decrease, but A-B remain constant. In order to see this we tried to keep the balance between the offsets, but this was hard. We don't really see much of this effect, so this also needs further investigation. As long as we keep controlling the LO phase using the DCPDs because the offsets tend to reduce the error signal we will have a harder time.

* For these measurements we actuated on LO2 to keep the LO phase under control.

Note that the color code above corresponds to the traces shown in Attachment #1.

## What's next?

• Alignment of LO and AS might be far from optimized, so it should be tried more seriously.
• What's the actual LO power? How does it compare with AS power at whatever MICH offsets?
• Try audio dither LO phase control.
• With MICH offset.
• Without MICH offset, double demod (after dolphin fix )
Attachment 1: 20220726_BICHD.pdf
17040   Wed Jul 27 18:30:50 2022 yutaUpdateBHDLO beam power at BHD DCPDs is significantly lower than expected

[Paco, Yehonathan, Yuta]

We measured power and counts at BHD DCPDs with LO beam only and ITM single bounce.
We found that LO beam power is ~7 times less than the expected.
We also confirmed that AS beam is clipped somewhere inside vacuum and have 20-50% less power compared with the expected.
LO/AS beams going to DCPD A and B also have power imbalance by 30-40%.

What we did:
- Run LSCoffsets.py to zero the offsets. I modified the old script so that it can handle new BHD PDs. Also, a bug was fixed (it didn't take into account the gains in filer modules, so INMON is now used instead of OUT16 for calculating offsets).
https://git.ligo.org/40m/scripts/-/blob/main/RFPD/LSCoffsets.py
- Measured powers and counts in BHD DCPDs at ITMY table with LO beam only and ITMX/ITMY single bounce.
- During the measurement, we found that power into DCPD A and DCPD B are quite different. One of the reason was a lens and an iris right after the viewport for A path. We removed both of them. Also, only A path have a pickoff which picks off ~20% of light to BHD camera (called SRMF; 40m/16880).
- We also found that LO beam shape is ugly. ITM single bounce beam from X and Y have similar clipping (see Attached photos). We tried to reduce clipping with various suspensions (LO1, LO2, AS1, AS4, SR2, SRM, BS, ITMX, PR2), but was not possible by moving only single suspension.

Result:
- Result of counts and power measurements are as follows. Power was measured right in front of DCPD, and also right after the viewport to estimate the loss in the in-air paths. Note that LSC channels have gain of 1, but HPC channels have gain of -1.9 for DCPD_A and -1 for DCPD_B.

Blocked  LO       ITMX      ITMY
C1:LSC-DCPD_A_OUT16    -0.01    -17.89    -91.62    -86.21
C1:LSC-DCPD_B_OUT16    +0.06    -17.72   -131.83   -131.98
C1:HPC-DCPD_A_OUT16    +0.07    +34.12   +174.63   +164.24
C1:HPC-DCPD_B_OUT16    +0.13    +17.60   +131.31   +131.49
Power at DCPD_A        19 uW    63 uW    278 uW    290 uW
Power at DCPD_B        19 uW    65 uW    393 uW    404 uW
Power at viewport A    -- uW    82 uW    350 uW    337 uW
Power at viewport B    -- uW    64 uW    436 uW    431 uW

DCPD calibration:
- From the measurements above, counts/W in IN1 can be calculated as follows. Offset of 19 uW is substracted from the measured power to take into account for background light.

C1:LSC-DCPD_A_IN1     -3.59e+05 counts/W
C1:LSC-DCPD_B_IN1     -3.61e+05 counts/W
C1:HPC-DCPD_A_IN1     -3.60e+05 counts/W
C1:HPC-DCPD_B_IN1     -3.57e+05 counts/W

Discussion:
- DCPD calibration shows that DCPD to ADC itself is quite balanced within 1%. A factor of 1.8-1.9 seen was from unbalanced light between A path and B path (40m/17037).
- Power expected for ITM single bounce to one of DCPDs is ~520 uW, but was 350-430 uW as measured right after the viewport. Power at A is significantly less than that for B. Note that power at AS55 was as expected (40m/16952). Also, clipping cannot be reduced by moving suspensions. These could mean that clipping is happening after AS2.

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS) * 10%(SRM) * 90%(AS2) * 50%(BHDBS) = 520 uW

- Power expected for LO beam to one of DCPDs is ~530 uW, but was 60-80 uW as measured right after the viewport. Power at A is significantly more than that for B, which is opposite for ITM single bounce. This could mean that something is happening at BHDBS? We are not sure why the power is so low. Are we seeing some ghost beam? For PR2 transmission, 22000 ppm was used for calculation, from 40m/16541.

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 2.2%(PR2) * 50%(BHDBS) = 530 uW

- As far as we remember, beam shapes were not as bad when we closed out the chambers...

Next:
- Check if measured power explains the visitivity of LO-ITM single bounce (40m/17020)
- If not, what is the mode mismatch? Is it possible to explain the mode mismatch with deviations from designed mode-matching telescope?
- Measure POP power to see if PR2 actually have T=2.2%
- Play with LO1 and LO2 to invesitate LO beam shape and power
- Check coherence between LO/AS power fluctuations with suspension motions
- What is the expected counts/W for these DCPDs?
- Balance the optical paths in ITMX table for A and B (same lenses, same mirrors)
- Install better lens in front of camera

Attachment 1: LOBeamAtBHD.JPG
Attachment 2: ITMXSingleBounceAtBHD.jpg
17041   Thu Jul 28 13:09:28 2022 yehonathanUpdateBHDMode matching considerations

The LO beam was found to have a power of 60uW, 10% of the power expected. We are pretty sure about the expectation because the AS beam has a power of 300uW, roughly the expected power. Additionally, the visibility of the MICH fringes in the BHDR is 40%.

If the mode-matching is perfect then we expect the visibility to be $\text{VIS}=\frac{I_\text{max}-I_\text{min}}{I_\text{max}+I_\text{min}}=\frac{2\sqrt{I_\text{LO}I_\text{AS}}}{I_\text{LO}+I_\text{AS}}=\frac{2\sqrt{300\cdot 60}}{300+600}$

which is roughly 74.5%.

If there is some mode-mismatch one can show that the visibility is $\text{VIS}=\frac{2\sqrt{M}\sqrt{I_\text{LO}I_\text{AS}}}{I_\text{LO}+I_\text{AS}}$, where $M=\left|\frac{\int \left(E_\text{LO}^\star E_\text{AS} \right)\mathrm{d}x \mathrm{d}y}{\sqrt{I_\text{LO}I_\text{AS}}}\right|^2$ is the mode-mismatch.

Using Finesse model I calculated \sqrt(M)=0.93 in the MICH configuration so the expected visibility is around 70%, far away from the observed 40%. To explain the observed visibility the mode mismatch would have to be ~ 30% which is very unlikely.

So it could either be a ghost beam or that the LO beam is clipped so badly that it also degrades its phase front (and therefore the mode-matching). The fact that we see fringes on the LO beam might suggest knife edge clipping on one of the auxiliary optics in the BS chamber.

17042   Thu Jul 28 14:34:40 2022 YehonathanUpdateBHDLO beam power at BHD DCPDs is significantly lower than expected

{Yuta, Yehonathan}

We went to the BS table to check the POP beam power. We first notice that the POP beam has a nice gaussan profile on the viewing card. We traced it the beam to the viewing port and measured the power there. Before measuring the power we misalign ITMY/ITMX to get rid of interferences. We measure the beam to be 205uW in both cases.

The expected power is

950 mW * 0.9 (IMC transmission?) * 5.637%(PRM) * 97.8%(PR2) * 50%(BS) * 98.6%(ITM) * 50%(BS)  * 2.2%(PR2) = 260uW

which is reasonably close to what we measure which confirms that PR2 transmission is around what we think it is.

This strengthen our suspicion that LO beam gets clipped somewhere.

We also improved the clipping on the POP camera by one of the beamsplitters along the beam path and the alignment to the POPDC PD (~100 cts before, ~ 1000 cts after).

17044   Thu Jul 28 16:51:55 2022 TegaUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

[Yuta, Tega, Yehonathan]

To investigate the BHD power imbalance and clipping issues, we did some shaking test of the mirrors in the LO path and AS paths. The results suggests the following:

• The clipping is happening after the BHD BS in DCPD_A path, as opposed to our initial guess of BHD BS transmission clipping in elog 17040.
• The LO beam we are seeing is probably a ghost beam from PR2

We performed both PIT and YAW shaking of all mirrors and looked at the output at DCPD_A and DCPD_B, see table below for details. Since we only see the dithering signal in DCPD_A, it suggests that the clipping is ocurring after the BHD BS and is also confined to the path between BHD BS and DCPD_A. We also swapped the camera location from DCPD_A to DCPD_B on ITMY table and confirmed that the beam was clipped for DCPD_A but not for DCPD_B.

This result discounts the possiblity of clipping being responsible for the power imbalance and therefore suggests that the power imbalance may actually be due to BHD BS not being 50:50. From the measurement in elog 17040, the transmission of BHD BS is 44$\pm$0.3% and the reflectivity is 56$\pm$0.3%. Note that DCPD_A is the transmission of BHD BS for AS beam, whereas DCPD_B is the reflection of BHD BS for AS beam, elog 16932.

We expect the shaking of PR2 to give no signal in either DCPD_A or DCPD_B when the LO beam is purely in trasmission, however, we see a signal in DCPD_A sugesting that the LO beam transit path through PR2 may not be as expected, i.e. the beam might be exiting the side of PR2 instead of the AR coated surface.

Finally, we measured the coherence between the dithering dof and DCPD_A/B & POP, see attachment 2, where we noticed that both DCPD_A/B have high coherence in the 1Hz-10Hz frequency band whereas ther was no coherence in POP as expected. This suggests that there may also be some small clipping in DCPD_B path.

LO Beam Shaking (LO1, LO2, PR2):

 color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue LO1 YAW 304.4 2000 Signal in DCPD_A & No signal in DCPD_B Orange LO1 PIT 304.4 2000 No signal Magenta LO2 YAW 312.2 10000 No signal Purple LO2 PIT 312.2 10000 Signal in DCPD_A & No signal in DCPD_B Green PR2 YAW 308.8 20000 Signal in DCPD_A & No signal in DCPD_B Red PR2 PIT 308.8 20000 Signal in DCPD_A & No signal in DCPD_B

AS Beam Shaking (AS1 and AS4)

 color OPTIC DOF Freq OSC Amp (cnts) comment Black 0 Reference Blue AS1 YAW 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Orange AS1 PIT 305.5 2000 Signal in DCPD_A & No signal in DCPD_B Magenta AS4 YAW 313.3 2000 Signal in DCPD_A & No signal in DCPD_B Purple AS4 PIT 313.3 2000 No signal

Attachment 1: Screenshot_2022-07-28_16-58-34_LOandASShaking.png
Attachment 2: Screenshot_2022-07-28_18-08-55_DCPDPOPSuspensionCoherence.png
17045   Thu Jul 28 20:16:26 2022 AnchalUpdateBHDShaking test for LO beam AS beam to BHD DCPDs

Some insights from the inside vacuum situation:

• The beam is an incident near normal on PR2 close to the center of the optic. It wasn't hard to align this part, I'm very confident that we aligned it to the center of PR2. So I do not think the LO beam is ghost beam from PR2.
• The place that is most susceptible to clipping is POP_SM5 mirror in front of LO1. The LO beam has little clearance from the edge of the mirror.
• Another possibility of clipping in LO beam is through the cage of LO2. LO2 is a 45-degree incidence mirror, so it is possible we are clipping off the cage or seeing a ghost beam mixed in LO beam here.
• The fact that moving PR2 is affecting LO beam is weird but doesn't necessarily mean it is a ghost from PR2.
17046   Fri Jul 29 18:24:53 2022 TegaUpdateBHDLO beam power improved by factor of 6 after LO and AS beam alignment

[Yuta, Tega]

From our previous work (elog 17044) of shaking PR2 and seeing a signal in DCPD_A and the fact that LO beam power is far smaller than the expected nominal value, we decided to use TT1 and TT2 to realign the LO beam. This resulted in LO beam power going up by a factor of 6 and an improvement in the LO beam shape. We are still unable to find LO and AS alignment which realize BHD fringe with no clipping everywhere.

Deformed LO beam issue: Following the TT1 and TT2 alignments, used PR2 and PR3 to recover the transmission of the X and Y arms to 1. We also used LO1 and LO2 offsets to further reduce the beam deformation by eliminating the HOM concentric fringes that surounded the LO beam and to maximize the DCPD outputs. BHD optics in ITMY table was tweaked a lot to keep the LO beam centered on the BHD DCPDs and camera. The improved LO beam is still astigmatic in the yaw direction but at least now looks like a TEM00 mode. We also repositioned the DCPD_A path camera lens to remove the circular diffused fringes due to lens clipping. After the alignment, power was measured to be the following. It also reduced the coherence between DCPD outputs and suspension motions (see attached).

LO         ITMX
C1:HPC-DCPD_A_OUT16    +127.50    +96.24 (ITMX single bounce consistent to 40m/17040)
C1:HPC-DCPD_B_OUT16    +120.51    +141.52
Power at viewport A    504 uW (almost as expected 40m/17040)
Power at viewport B    385 uW

AP table AS beam clipping: We also noticed clipping in the AS beam in AP table which we removed by moving SR2 and AS1 in YAW and then used AS4 to keep the BHD AS beam centered in the BHD DCPDs.

BHD fringe: After overlaping the LO and AS beams, we saw diagonal fringes indicating beam tilt of LO wrt AS, so we tried to remove the AS beam tilt using AS1 and AS4 but failed to do so because the AS4 mirror seemed to completely distort the beam, so intead we decided to use SR2 and AS1 to remove the tilt between LO and AS beams, which realized BHD fringe. But the motion of SR2 and AS1 then moved the AS beam that it is no longer seen in AP table. The alignment to realize LO and AP AS beam without clipping, and that to realize BHD fringe are attached.

Attachment 1: LO_and_oldAS_settings.png
Attachment 2: BHD_fringe_settings.png
Attachment 3: Screenshot_2022-07-29_19-37-39.png
Attachment 4: FromTheLeft-AS-POP-LO.JPG
17052   Mon Aug 1 18:42:39 2022 TegaConfigurationBHDc1sus2 IPC dolphin issue update

[Yuta, Tega]

We decided to give the dolphin debugging another go. Firstly, we noticed that c1sus2 was no longer recogonising the dolphin card, which can be checked using

lspci | grep Stargen

or looking at the status light on the dolphin card of c1sus2, which was orange for both ports A and B.

We decided to do a hard reboot of c1sus2 and turned off the DAQ chassis for a few minutes, then restared c1sus2. This solved the card recognition problem as well as the 'dis_irm' driver loading issue (I think the driver does not get loaded if the system does not recognise a valid card, as I also saw the missing dis_irm driver module on c1testand).

Next, we confirmed the status of all dolphin cards on fb1, using

controls@fb1\$ /opt/DIS/sbin/dxadmin

It looks like the dolphin card on c1sus2 has now been configured and is availabe to all other nodes. We then restated the all FE machines and models to see if we are in the clear. Unfortunately, we are not so lucky since the problem persisted.

Looking at the output of 'dmesg', we could only identity two notable difference between the operational dolphin cards on c1sus/c1ioo/c1lsc and c1sus2, namely: the card number being equal to zero and the memory addresses which are also zero, see image below.

Anyways, at least we can now eliminate driver issues and would move on to debugging the models next.

Attachment 1: c1sus2_dolphin.png
Attachment 2: fb1_dxamin_status.png
Attachment 3: dolphin_num_mem_init2.png
17054   Tue Aug 2 17:25:18 2022 TegaConfigurationBHDc1sus2 dolphin IPC issue solved

[Yuta, Tega, Chris]

We did it!

Following Chris's suggestion, we added "pciRfm=1" to the CDS parameter block in c1x07.mdl - the IOP model for c1sus2. Then restarted the FE machines and this solved the dolphin IPC problem on c1sus2. We no longer see the RT Netstat error for 'C1:HPC-LSC_DCPD_A' and 'C1:HPC-LSC_DCPD_B' on the LSC IPC status page, see attachement 1.

Attachment 2 shows the module dependencies before and after the change was made, which confirms that the IOP model was not using the dolphin driver before the change.

We encountered a burt restore problem with missing snapfiles from yesterday when we tried restoring the EPICS values after restarting the FE machines. Koji helped us debug the problem, but the summary is that restarting the FE models somehow fixed the issue.

Log files:
/opt/rtcds/caltech/c1/burt/burtcron.log
/opt/rtcds/caltech/c1/burt/autoburt/autoburtlog.log

Request File list:
/opt/rtcds/caltech/c1/burt/autoburt/requestfilelist

Snap files location:
/opt/rtcds/caltech/c1/burt/autoburt/today
/opt/rtcds/caltech/c1/burt/autoburt/snapshots

Autoburt crontab on megatron:
19 * * * * /opt/rtcds/caltech/c1/scripts/autoburt/autoburt.cron > /opt/rtcds/caltech/c1/burt/burtcron.log 2>&1
Attachment 1: c1lsc_IPC_status.png
Attachment 2: FE_lsmod_dependencies_c1sus2_b4_after_iop_unpdate.png
17056   Wed Aug 3 16:00:51 2022 yutaUpdateBHDBHD fringe aligned with reduced LO and AS beam clipping

Last week, we could find an alignment which realizes LO beam and AS beam both unclipped, but it was not consistent with an alignment which realize BHD fringe (40m/17046).
Today, we tweaked the alignment of SR2, AS1, AS4 to have BHD fringe with reduced LO and AS beam clipping.
AS beams on AP table and BHD both still look clipped, but much better now.
Ideally, SR2 and AS1 will unclip AS beam, and LO1, LO2, AS4 would make BHD fringe, but it is hard right now since LO beam seem to have little room and LO2 have little actuation range.
BHD optics on ITMY table, including camera, and AS55/ASDC were realigned after the aglinment work (Note that DCPD_A path have a pick-off for camera path, and this pick-off mirror have quite significant incident angle dependence of R/T ratio).

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 DCPD_A_OUT of ~130 and DCPD_B_OUT of ~125.
- Align PR3, PR2 to maximize TRY_OUT to ~1.05.
- 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.1.
- Tweak ITMX/ETMX if the beam spot on them are not good.
- Misalign ETMY, ETMX, ITMY to have LO-ITMX fringe in BHD DCPDs, and align AS beam with SR2 and AS4 differentially, with ratio of AS4/SR2=3.6.

DC PD values in various configurations:
Both arms locked with POX/POY, MICH free, PRM/SRM misaligned

                          Mean     Max      Min C1:IOO-MC_TRANS_SUM :     14088.57 13947.52 14167.04 C1:LSC-ASDC_OUT16 :           0.16    -0.02     0.34 C1:LSC-POPDC_OUT16 :        369.34   -74.88   854.34 C1:LSC-REFLDC_OUT16 :         0.03    -0.00     0.06 C1:LSC-TRY_OUT16 :            1.00     0.95     1.04 C1:LSC-TRX_OUT16 :            1.07     1.04     1.08

Only LO beam to BHD DCPDs
                          Mean     Max      Min C1:IOO-MC_TRANS_SUM :     14121.32 14057.71 14159.38 C1:HPC-DCPD_A_OUT16 :       129.80   128.37   130.68 (Consistent with, 40m/17046. Power as expected within 20%. Squashed shape) C1:HPC-DCPD_B_OUT16 :       123.42   121.92   124.48

ITMX single bounce (ITMY, ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min C1:IOO-MC_TRANS_SUM :     14105.13 14000.89 14171.91 C1:HPC-DCPD_A_OUT16 :        92.54    91.45    93.30 (Consistent with 40m/17040, Power as expected within 40%. Clipped to the left in camera) C1:HPC-DCPD_B_OUT16 :       137.70   136.55   138.53 (Note that DCPD_A/B ratio is different from LO, due to BHD BS R/T unbalance; 40m/17044) C1:LSC-ASDC_OUT16 :           0.10     0.09     0.10 (Power as expected 40m/16952. Clipped to the right in camera) C1:LSC-POPDC_OUT16 :        309.19   288.93   327.10 (Power as expected within 30% 40m/17042.) C1:LSC-REFLDC_OUT16 :         0.02     0.01     0.02

ITMY single bounce (ITMX, ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min C1:IOO-MC_TRANS_SUM :     14112.09 14025.37 14154.51 C1:HPC-DCPD_A_OUT16 :        92.58    92.01    93.26 C1:HPC-DCPD_B_OUT16 :       137.68   136.81   138.27 C1:LSC-ASDC_OUT16 :           0.10     0.09     0.10 C1:LSC-POPDC_OUT16 :        308.48   290.49   319.73 C1:LSC-REFLDC_OUT16 :         0.02     0.01     0.02

MICH fringe only (ETMX, ETMY, PRM, SRM, LO misalgined)
                          Mean     Max      Min C1:IOO-MC_TRANS_SUM :     14090.34 13979.15 14143.86 C1:HPC-DCPD_A_OUT16 :       325.60    91.92   714.57 C1:HPC-DCPD_B_OUT16 :       400.27    18.37   762.57 C1:LSC-ASDC_OUT16 :           0.19    -0.05     0.41 C1:LSC-POPDC_OUT16 :        595.66  -119.21  1334.11 C1:LSC-REFLDC_OUT16 :         0.03    -0.01     0.07

LO-ITMX fringe only (ITMY, ETMX, ETMY, PRM, SRM misalgined)
                          Mean     Max      Min C1:IOO-MC_TRANS_SUM :     14062.58 13968.05 14113.67 C1:HPC-DCPD_A_OUT16 :       224.31    89.57   371.66 C1:HPC-DCPD_B_OUT16 :       259.74    85.37   421.86

Next:
- Measure contrast (40m/17020) and estimate mode-matching of LO-AS again (40m/17041)
- Now that we have better LO-AS fringe, lock LO phase in MICH (40m/17037)
- Now that Dolphin issue was fixed, try double-demodulation to lock LO phase

Attachment 1: Screenshot_2022-08-03_15-46-36_BHDfringeAlmostUnclipped.png
17067   Tue Aug 9 15:33:12 2022 yutaUpdateBHDBHD fringe contrast improved from 43% to 74%

[Anchal, Yehonathan, Yuta]

We did the constrast measurement with the method same as 40m/17020.
Contrast between ITM single bounce and LO beam increased to 74% (we had 43% before unclipping LO beam in 40m/17056).
From equations in 40m/17041 and measured ITM sigle bounce power (93 or 138 counts @ BHD DCPD) and LO power (130 or 124 counts @ BHD DCPD) from 40m/17056,  expected visibility for perfectly mode-matched case is 99%.
Measured constrast of 74% indicate mode-matching of 56%.

Both arms locked, MICH fringe (20% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 80.66 +/- 0.20 %
Contrast measured by C1:LSC-POPDC_OUT is 92.27 +/- 0.66 %
Contrast measured by C1:LSC-REFLDC_OUT is 89.59 +/- 0.84 %
Contrast measured by all is 87.51 +/- 1.69 %

Both arms misaligned, MICH fringe (20% percentile)
Contrast measured by C1:LSC-ASDC_OUT is 82.50 +/- 0.61 %
Contrast measured by C1:LSC-POPDC_OUT is 94.18 +/- 0.26 %
Contrast measured by C1:LSC-REFLDC_OUT is 92.78 +/- 0.19 %
Contrast measured by all is 89.82 +/- 1.75 %

ITMX-LO fringe (40% percentile)
Contrast measured by C1:HPC-DCPD_A_OUT is 73.93 +/- 1.52 %
Contrast measured by C1:HPC-DCPD_B_OUT is 73.56 +/- 1.22 %
Contrast measured by all is 73.74 +/- 0.98 %

ITMY-LO fringe (40% percentile)
Contrast measured by C1:HPC-DCPD_A_OUT is 73.45 +/- 0.61 %
Contrast measured by C1:HPC-DCPD_B_OUT is 75.27 +/- 0.50 %
Contrast measured by all is 74.36 +/- 0.54 %

Attachment 1: HPC-DCPD_B_OUT_1344118517_ITMY-LO.png
Attachment 2: HPC-DCPD_A_OUT_1344118517_ITMY-LO.png
Attachment 3: HPC-DCPD_B_OUT_1344118318_ITMX-LO.png
Attachment 4: HPC-DCPD_A_OUT_1344118318_ITMX-LO.png
17068   Tue Aug 9 15:50:22 2022 KojiUpdateBHDBHD fringe contrast improved from 43% to 74%

For both 40m/17020 and 40m/17024, what does the contrast mean if the numbers are leaking out to ~-100cnt?
Also how much is it if you convert this contrast into the mode matching?

13   Thu Oct 25 00:01:21 2007 ranaSoftware InstallationCDSGEO DV => LIGO DV
Martin Hewitson of GEO600 fame has modified the cool GEO DV
to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week).

I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately.

I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS
client written by Ben Johnson.

The attached is a screenshot of it working on a Mac; it looks as cool on Linux.

Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then
type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client.
On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead.

Then type ligoDV to start it up. Then click away and have fun.

In the example I've selected
C1:PEM-BS_ACC_EAST_Z
and plotted its specgram.

Attachment 1: Picture_1.png
28   Mon Oct 29 23:25:42 2007 tobinSoftware InstallationCDSframes mounted
I mounted the frames directory on mafalda and linux3. It's intentionally not listed in the /etc/fstab so that an fb crash won't prevent the controls machines from booting. The command to mount the frames directory is:

mount fb40m:/frames/frames /frames
144   Fri Nov 30 11:22:22 2007 ajwSummaryCDSGEO DV => LIGO DV

 Quote: Martin Hewitson of GEO600 fame has modified the cool GEO DV to work with the LIGO NDS system with some NDS advice from Rolf (who's over in Germany this week). I've moved it onto the 40m CDS system and installed it on the AdhikariLab computer named 'django'. It worked immediately. I modified the main .m file to include the 40m's NDS server. When you run it you have to include the path to the NDS client written by Ben Johnson. The attached is a screenshot of it working on a Mac; it looks as cool on Linux. Its installed in /cvs/cds/caltech/apps/ligoDV/. In matlab you navigate to that directory and then type addpath('/cvs/cds/caltech/apps/linux/UNIX_NDS_Client_beta2/') to add the NDS client. On the Solaris machines, type type addpath('/cvs/cds/caltech/apps/solaris9/UNIX_NDS_Client_beta2/') instead. Then type ligoDV to start it up. Then click away and have fun. In the example I've selected C1:PEM-BS_ACC_EAST_Z and plotted its specgram.

Download and installation instructions, as well as a few examples for use
can be found here (typical lsc username and password):

https://www.gravity.phy.syr.edu/dokuwiki/doku.php?id=ligodv:home
170   Wed Dec 5 19:25:07 2007 ranaDAQCDSDMF
I made a database file on C1AUX called dmf.db. It has 9 DMF EPICS channels which are also trended
so that one can now write data to those channels from a DMF Monitor and the data will be records.

New channels:
[C1:DMF-SEIS_1]
[C1:DMF-SEIS_2]
[C1:DMF-SEIS_3]
[C1:DMF-LINE_1]
[C1:DMF-LINE_2]
[C1:DMF-LINE_3]
[C1:DMF-MC_1]
[C1:DMF-MC_2]
[C1:DMF-MC_3]

I added these to C1AUX because it doesn't do much and can be booted without having much effect.
(it controls Mech Shutters, Video, and Illuminators. It used to also do the EO Shutter but I
removed that from its startup.cmd and it will no longer load those records).
270   Fri Jan 25 21:36:40 2008 ranaUpdateCDSmDV / channel issues
Fri Jan 25 21:30:00 2008

As it turns out, the residual problem with the mDV stuff was not to do with our button pushing episode but instead fallout from the 'turning off of the computers' during the water leak caused by the rain and construction.

The /frames partition from fb0 (the FrameBuilder) is not mounted to the control machines via vfstab; it does not remount on bootup. I originally did this because Ben Johnson and Dave Barker had warned me that during a power outage, fb0 may not come up right away. This could make the control room machines hang up for awhile. I elected to have the mount be by hand.

So the thing to do is to put the mount command into the cold start procedures (Andrey). Its in an old elog entry of mine from Feb '07.
278   Sun Jan 27 21:44:48 2008 ranaUpdateCDSSeismic BLRMS on Matlab
I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.

Here's how it works:
• Use mDV to get data by reading directly from frames.
• Use the Matlab pwelch function to produce a power spectrum of the channels.
• Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
• Makes a tdswrite command string which writes all the values to EPICS channels.
• The EPICS channels are just a list of simple names in a database file.
• The channel names are (will be) added to the C0EDCU.ini file so that its all trended.

The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).

Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).

In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute.
Attachment 1: seisBLRMS.m
% Seismic BLRMS Monitor
%
%
%
% RA 08-01-26

% 0 for no messages, 1 for debugging
debug_flag = 1;

% ------------ Build channel list

... 82 more lines ...
356   Tue Mar 4 19:14:09 2008 ranaConfigurationCDSTDS & SVN
Matt, Rob, Rana

Today we added the TDS software to the 40m SVN repo.

First we rationalized things by deleting all the old TDS directories and taking
the tds_mevans dir and making it be the main one (apps/linux/tds).

We also deleted all of the TDS directories in the project area. It is now very
likely that several scripts will not work.
We're going to have the teething
problems of repointing everything to the nominal paths (in the apps areas).

Finally we did:
svn import tds https://40m.ligo.caltech.edu/svn/40m/tds --username rana

to stick it in. To check it out do:
svn checkout https://40m.ligo.caltech.edu/svn/40m/tds --username rana

We'll get a couple of the O'Reilly SVN books as well to supplement our verion control knowledge.
Unitl then you can use the SVN cheat sheets available at:
http://www.digilife.be/quickreferences/quickrefs.htm
383   Sun Mar 16 17:03:32 2008 robConfigurationCDSASS code change

I've updated the ass.mdl file in the directory:

to get us started in the adaptive PEM noise subtraction.

After several iterations of remote help from Alex, the code compiles and runs, receives signals from the LSC, PEM, and MC2, and communicates with the suspension controllers. I've also adapted the .par file from the code generator, but haven't got the testpoints working with the new ASS code. There are no MEDM screens yet, and Matt's adaptive filter code has not been installed (there's a matrix as a placeholder).

Putting in the adaptive code should be simple, building the MEDM screens tedious, and getting the testpoints working uncertain. I noticed that the new testpoint.par file starts at a different channel number than the previous (working) version, which is strange. I probably have a script somewhere to change all these numbers by a constant offset, but I don't know if that's the actual problem--maybe stuff just needs to be rebooted.

The code receives as input the first 24 channels from the PEM ADCU, the eight suspension control signals from the LSC, and the output of the MCL filter from MC2. It outputs to the MCL filter input of each suspension (except MC2).
394   Sat Mar 22 22:39:02 2008 mevansSummaryCDSDirect Form 2 filters are bad
Here I show a comparison between the filter algorithm currently used in LIGO (Direct Form II), and an alternative algorithm designed to reduce numerical noise. The input signal is

x = sin(2 * pi * t) + 1e-9 * sin(2 * pi * (fs / 4) * t);

where fs = 16384 is the sample rate. The filter is a 4th order notch at 1Hz (f_poles = f_zeros = 1Hz, Q_poles = 1, Q_zeros = 1e6). It is clear that the DF2 algorithm produces a noise floor that is, for this simple filter, 1e-11 / rtHz smaller than the input drive amplitude (see plots). That should probably be scary given how many second-order-sections we run our signals through. The low-noise form does a somewhat better job. The low-noise algorithm has the same memory and computational requirements as DF2, and our CDS guys have the code in hand. I suggest we start testing soon.

(The code is included below. You will need my Matlab library to run the top level test script.)
Attachment 1: low-noise_filtering.png
Attachment 2: low-noise_zoom.png
Attachment 3: FiltRT.zip
459   Tue Apr 29 21:09:12 2008 ranaDAQCDSFE Filters
These are new FE filters for downsampling and upsampling. We will be going from native hardware sampling rates of 64k down to 32k, 16k, and 2k.

The attached plot shows these filters. They are 3dB ripple, 40 dB stopband, 4th order elliptic filters in which I have moved the zeros around
into good places (e.g. to the Nyquist frequency).

I'm also attaching the .txt file containg the filter coefficients and the design strings. The filters are called x2, x4, and x32, for the
D2, D4, and D32 downsampling, respectively.
Attachment 1: fefilters.jpg
Attachment 2: fefilters.txt
# FILTERS FOR ONLINE SYSTEM
#
# Computer generated file: DO NOT EDIT
#
# MODULES ULYAW
#
################################################################################
### ULYAW                                                                    ###
################################################################################
# SAMPLING ULYAW 65536

... 28 more lines ...
1782   Thu Jul 23 07:34:45 2009 AidanUpdateCDSAdded C2 MEDM screens to 40m SVN.

1801   Tue Jul 28 18:32:21 2009 KojiUpdateCDSRCG work

Peter and Koji,

We are constructing a setup for the new 40m CDS using Realtime Code Generator (RCG).
We are trying to put simulated suspensions and test suspension controllers on a different processors of megatron
in order to create a virtual control feedback loop. Those CDS processes are communicating
each other via a shared memory, not via a reflective memory for now.

After some struggles with tremendous helps of Alex, we succeeded to have the communication between the two processes.
Also we succeeded to make the ADC/DAC cards recognized by megatoron, using the PCI express extension card replaced by Jay.
(This card runs multi PCI-X cards on the I/O chasis.)

Next steps:
- Establish a firewall between the 40m network and megatron (Remember this)
- Make DTT and other tools available at megatron
- Try virtual feedback control loops and characterize the performance
- Enable reflective memory functionalities on megatron
- Construct a hybrid system by the old/new CDSs
- Controllability tests using an interferometer

o Each cdsIPC should have a correct shared memory address spaced by 8 bytes. (i.e. 0x1000, 0x1008, 0x1010, ...)

Note on MEDM
o At the initial state, garbage (e.g. NaN) can be running all around the feedback loops. They are invisible as MEDM shows them as  "0.0000".
To escape from this state, we needed to disconnect all the feedback, say, by turning off the filters.

Note on I/O chasis
o We needed to pull all of the power plugs from megatron and the I/O chasis once so that we can activate
the PCI-e - PCI-X extension card. When it is succeeded, all (~30) LEDs turn to green.

2045   Fri Oct 2 18:04:45 2009 robUpdateCDSDTT no good for OMC channels

I took the output of the OMC DAC and plugged it directly into an OMC ADC channel to see if I could isolate the OMC DAC weirdness I'd been seeing.  It looks like it may have something to do with DTT specifically.

Attachment 1 is a DTT transfer function of a BNC cable and some connectors (plus of course the AI and AA filters in the OMC system).  It looks like this on both linux and solaris.

Attachment 2 is a transfer function using sweepTDS (in mDV), which uses TDS tools as the driver for interfacing with testpoints and DAQ channels.

Attachment 3 is a triggered time series, taken with DTT, of the same channels as used in the transfer functions, during a transfer function.  I think this shows that the problem lies not with awg or tpman, but with how DTT is computing transfer functions.

I've tried soft reboots of the c1omc, which didn't work.   Since the TDS version appears to work, I suspect the problem may actually be with DTT.

Attachment 1: omc_dac_dtt.png
Attachment 2: omc_dac_sweepTDS.png
Attachment 3: omc_dac_dtt_ts.png
2173   Tue Nov 3 12:47:01 2009 KojiConfigurationCDS1Y9 Rack configuration update

For the CDS upgrade preparation I put and moved those stuff at the rack 1Y9:

Placed 1Y9-12 ADC to DB44/37 Adapter LIGO D080397

Placed 1Y9-14 DAC to IDC Adapter LIGO D080303

Moved the ethernet switch from 1Y9-16 to 1Y9-24

Wiki has also been updated.

2181   Thu Nov 5 16:24:59 2009 KojiUpdateCDSETMY CDS test stuff

Joe, Peter, Jay, Koji, Rana

We put the new CDS stuff at Y end 1Y9 rack.

Items

• megatron
• wireless router
• IO chasis (black)
• Extention cable (between megatron & IO chasis)
• 1 ADC card
• 1 DAC card
• 1 BIO card
• The adapter box for DAC
• The adapter box for BIO
• 2x IDC-DB37 cable for the ADC box - AA chasis
• 1x IDC cable for the DAC box - Pentek
• 1x DB cable for the BIO box
• 1x +/-15V cable for the BIO box
2233   Wed Nov 11 01:33:52 2009 peteUpdateCDSRCG ETMY code update

I've added the side coil to the model controller and plant, and the oplev quad to the model controller and plant.  After the megatron wipe, the code now lives in /home/controls/cds/advLigo/src/epics/simLink.  The files are mdc.mdl (controller) and mdp.mdl (plant).  These RCG modules go at 16K with no decimation (no_oversampling=1 in the cdsParameters block) so hopefully will work with the old (16K) timing.

I've loaded many of the filters, there are some eft to do.  These filters are simply copied from the current frontend.

Next I will port to the SUS module (which talks to the IO chassis).  This means channel names will match with the current system, which will be important when we plug in the RFM.

2243   Wed Nov 11 20:46:07 2009 peteUpdateCDSRCG ETMY phase I update

The .mdl code for the mdc and mdp development modules is finished.  These modules need more filters, and testing.  Probably the most interesting piece left to do is putting in the gains and filters for the oplev model in mdp.  It might be OK to simply ignore oplevs and first test damping of the real optic without them.   However, it shouldn't be hard to get decent numbers for oplevs, add them to the mdp (plant) module, and make sure the mdc/mdp pair is stable.  In mdp, the oplev path starts with the SUSPIT and SUSYAW signals. Kakeru recently completed calibration of the oplevs from oplev cts to radians:   1403  .  From this work we should find the conversion factors from PIT and YAW to oplev counts, without making any new measurements.  (The measurements wouldn't be hard either, if we can't simply pull numbers from a document.)  These factors can be added to mdp as appropriate gains.

I've also copied mdc to a new module, which I've named "sas" to address fears of channel name collisions in the short term, and replaced the cpu-to-cpu connections with ADC and DAC connections.  sas can be the guy for the phase I ETMY test.  When we're happy with mdc/mdp, we hopefully can take the mdc filter file from chans, replace all the "MDC" strings with "SAS", and use it.

ELOG V3.1.3-