40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 3 of 348  Not logged in ELOG logo
IDdown Date Author Type Category Subject
  17420   Wed Jan 25 12:49:14 2023 RadhikaUpdateALSXARM green laser lock debugging

I returned the half-wave plates on the XEND table back to their original angles, and restored the loop configuration with the PDH servo box. I returned the PD gain to 40 dB (original setting), and set the servo gain knob to 6. This was the region of highest loop stability, with the lock holding for a few seconds (as before). The control signal on the scope did not look intuitive - the peaks of the control signal corresponded with zero crossings of the error signal. 

Paco encouraged me to retake transfer function measurements of the PDH servo box. The main takeaway is the PDH servo (boost on) has the expected frequency response at a gain setting of 3 or under, up to 100 mVpp of input. Attachment 1 shows the frequency response at a servo gain of 2, for varying input amplitudes. 

The rest of the bode plots correspond to servo gain of 4, 6, 8, and 10 (boost on). The saturation LED would turn on above a gain value of ~3.25, so these results can't be analyzed or interpreted. But it does seem like a steep, low-frequency jump is a signature of the saturated servo. This jump doesn't appear with 10 mVpp input, at least at or above 1 Hz. 

Attachment 1: XEND_PDHservo_boost_on_gain2.pdf
Attachment 2: XEND_PDHservo_boost_on_gain4.pdf
Attachment 3: XEND_PDHservo_boost_on_gain6.pdf
Attachment 4: XEND_PDHservo_boost_on_gain8.pdf
Attachment 5: XEND_PDHservo_boost_on_gain10.pdf
  17419   Wed Jan 25 11:35:20 2023 yutaSummaryBHDREFL55 visually inspected, BH44 Kapton taped

Following was done to investigate 60 Hz noise issue, but no significant change in the FPMI noise observed.

REFL55 inspection:
  - Even before BH44 installation, we have been experiencing flaky REFL55 RF output. When some work was done at AP table or something, sometimes the amplitude of REFL55_I and REFL55_Q goes very low, and/or offset changes. This was usually fixed by touching the RF output of REFL55.
  - So, we took out REFL55 and opened the back lid to inspect. RF output seemed rigid and the SMA connector was properly grounded to the box; didn't find any issue (Attachment #1).
  - REFL55 was put back to its original position, and the cables were also put back.

BH44 Kapton tape:
  - I realized that other RFPDs have Kapton tape in between the RFPD golden box and the black mount, but not for BH44 we recently installed.
  - I have checked that the golden box of BH44 and the optical table is not grounded when RF output and the DB15 cable was disconnected, but is gounded when they are connected, just like BH55.
  - Anyway I removed BH44 and put a Kapton tape (Attachment #2), just in case, and BH44 was put back to its original position, and the cables were also put back.

FPMI noise spectra after the work:
  - Attachment #3,4,5 are noise spectra of FPMI BHD sensors when FPMI is RF locked with AS55_Q, REFL55_I, and REFL55_Q, and LO_PHASE is locked with BH55 with the following configurations.
  - Attachment #3: whitening/unwhitening filters for AS55, REFL55, POX11, POY11, BH55, BH44 turned on (nominal configuration after lock acquisition)
  - Attachment #4: whitening/unwhitening filters for AS55, REFL55, POX11, POY11, BH55, BH44 turned off. No significant change except for expected whitening filter transfer function.
  - Attachment #5: whitening/unwhitening filters for AS55, REFL55, POX11, POY11, BH55, BH44 turned on, 30 dB resonant gain at 60 Hz, Q=10 in CARM loop. Significant 60 Hz reduction everywhere. This was not observed when resonant gain at 60 Hz was put in DARM loop (only 60 Hz at AS55_Q was reduced). 60 Hz noise mainly coming from something in CARM loop?

Don't forget to:
  - Put a beam dump for BH44

Attachment 1: REFL55.JPG
Attachment 2: BH44Kapton.JPG
Attachment 3: 20230125_FPMIBHDPDs_Spectra_FPMILockedBH55Locked.pdf
20230125_FPMIBHDPDs_Spectra_FPMILockedBH55Locked.pdf 20230125_FPMIBHDPDs_Spectra_FPMILockedBH55Locked.pdf
Attachment 4: 20230125_FPMIBHDPDs_Spectra_FPMILockedBH55LockedNoWhitening.pdf
20230125_FPMIBHDPDs_Spectra_FPMILockedBH55LockedNoWhitening.pdf 20230125_FPMIBHDPDs_Spectra_FPMILockedBH55LockedNoWhitening.pdf
Attachment 5: 20230125_FPMIBHDPDs_Spectra_FPMILockedBH55LockedResG60InCARM.pdf
20230125_FPMIBHDPDs_Spectra_FPMILockedBH55LockedResG60InCARM.pdf 20230125_FPMIBHDPDs_Spectra_FPMILockedBH55LockedResG60InCARM.pdf
  17418   Wed Jan 25 10:02:47 2023 yehonathanUpdate Earthquake, MC3 watchdog tripped

We came this morning and noticed the FSS_FAST channel was moving very rapidly. Short inspection showed that MC3 watchdog got tripped. After reenabling the watchdog the issue was fixed and the MC is stable again.

There is a spike in the seismometers 8 hours ago and it was probably due to the 4.2 magnitude earthquake that happened in Malibu beach around that time.

  17417   Tue Jan 24 21:29:31 2023 yutaSummaryBHDElectronics diagram around BH44 and BH55

1) Turning the whitening filter before the ADC on/off didn't changed the relative height of 60 Hz peak compared with the noise floor. When the whitening filter was turned on, increase of the dark noise measured at C1:LSC-****_(I|Q)_IN1 was roughly consistent by eye with the whitening filter transfer function (gain of 1 at DC, ~15 Hz zero x2, ~150 Hz pole x2), which suggests the 60 Hz pickup is before the whitening filter.

2) Attached is the electronics diagram around BH44 and BH55.

Attachment 1: BH44BH55Diagram.pdf
  17416   Tue Jan 24 21:04:59 2023 AnchalUpdateASCAS WFS path beam profiled

I completed the mode matching calculation today and found good solution with 360.6 mm ROC PLCX lens at -1.2 m from z=0 point. I placed the lens there today and aligned all mirrors to get centered beam on both WFS PDs when the flipper mirrors are flipper up. This alignment would probably require tweaking everying we flip the mirrors as the flipper mirrors do not come back to same position usually.

I mounted the modified WFS boards 111B and 112B next to the whitening filter boards of existing WFS. Now to switch over, onewould need to transfer the 8 RF lemo cables and the 2 IDE ribbon cables.

I'm working on rtcds model to read AS WFS data and handle it separately. I'll keep a WPICS binaruy switch to switch between IMC WFS or AS WFS. I need to figure out some build issues on this work still.


Attachment 1: ASBeamFocusingLens.png
  17415   Tue Jan 24 16:12:07 2023 ranaSummaryBHDFPMI displacement noise with 60 Hz harmonics side lobes

1) do a comparison with the whtiening before the ADC on/off. This will tell us if it is pickup before the whtiening filter or not.

2) If there are ground loops made by 44 MHz setup, we want to draw a simple diagram which includes which sides are grounded and which have transformers. How about make a drawing to bring to the group meeting tomorrow? IN the lab we have these coaxial BALUNs for making a 1:1 transformer coupling.

3) Another source of 60 Hz is the unintentional demodulation of spikes made by the Sorensen switching supplies: they produce spikes all the way up to 100 MHz, so if they land near 44 MHz, you may get some 60 Hz on the demodulation. You should be able to see this with a dipole antenna or a hoop antenna.

  17414   Tue Jan 24 11:21:59 2023 yutaSummaryBHDFPMI displacement noise with 60 Hz harmonics side lobes

Just to show how bad 60 Hz noise is, I compared FPMI displacement noise with pre-BH44 era (measured on Jan 13, 40m/17400).
Blue curve in Attachment #1 is the sensitivity with FPMI locked with RF in pre-BH44 era, and pink curves are that measured today (C1:CAL channels are currently unavailable due to 0x2000 appeared after running restatAllModels.sh).
60 Hz + harmonics pedestals are apparent today, but was not there on Jan 13. Today, DARM could be handed over to AS55_Q from POX11-POY11, but CARM could not be handed over to REFL55_I from POX11+POY11 (this was possible last night).
Attachment #2 shows FPMI error signals when electronic FPMI is locked. Too much 60 Hz, especially in REFL55_I_ERR and AS55_I_ERR crying (note that REFL55_Q is used for MICH lock, but AS55_Q is not in-loop yet when this screenshot was taken.)

  - Fix c1cal 0x2000 issue
  - Fix REFL55 loose RF output
  - Disconnect cables in BH44 to open possible ground loops made during BH44 installation (especially 44 MHz generation part??).

Attachment 1: FPMI_calibrated_noise_20230124_60Hz.pdf
Attachment 2: Screenshot_2023-01-24_11-27-22_FPMIndscope.png
  17413   Mon Jan 23 22:51:17 2023 yutaSummaryBHD60 Hz harmonics side lobe investigations

[Paco, Yehonathan, Yuta]

Since we have installed BH44, we are seeing side lobes of 60 Hz + harmonics in AS55, REFL55, BH55, BH44, preventing us from locking FPMI BHD (40m/17405).

BH55 RF amp removed:
  - We have noticed that the side lobes are there in BH55 (but not in BH44) when LO-ITMX single bounce is fringing (ETMs and ITMY mis-aligned).
  - Changing whitening gains and turning on/off whitening/unwhitening filters didn't help.
  - When LO-ITMX single bounce is locked with BH55, the side lobe in BH55 reduces.
  - Dithering LO1 at 11 Hz created 180 +/- 11 Hz signal, which confirms that this side lobes are from the up conversion of optic motion.
  - We thought it could be from RF saturation, so we have put a 55-67 MHz bandbass filter (SBP-60+) in between BH55 RFPD and RF amp (ZFL-1000LN+; 40m/17195). Didn't help.
  - We then removed the RF amp. This largely reduced the side lobes (but still some at 180 Hz). We could lock LO-ITMX single bounce without the RF amp, so we decided to remove it for now.

Side lobes only when one of the arms is locked:
  - When ETMs are mis-aligned, MICH fringing and BHD fringing, there are 60 Hz + harmonics, but the side lobes are not there.
  - But with Xarm is locked (ETMY, ITMY mis-aligned) or Yarm is locked (ETMX, ITMX mis-aligned), the side lobes appear in AS55, REFL55, BH55, BH44.
  - Changing whitening gains and turning on/off whitening/unwhitening filters didn't help.
  - As the error signals are normalized by TRX and TRY, we turned on/off the power normalization, but didn't help.
  - Switching 60 Hz comb in BS, ITMX, ITMY, ETMX, ETMY suspension damping didn't help.

POY11 Investigations:
  - When ETMs are mis-alined, POX11 had relatively large 60 Hz + harmonics, but almost none in POY11 (unlike other RFPDs; see Attchment #1).
  - However, when ETMY is aligned and Yarm is loked with POY11, the side lobe grows in POY11.
  - Changing the feedback point from ETMY to ITMY or MC2 didn't help.
  - We have unplugged the IQ demod board for BH44 from the eurorack (without removing the cables) and removed the fuse for the power supply of the RF amp for 44 MHz generation (40m/17401), but these also didn't help.
  - We have also tried locking Yarm with REFL55(= ~2 x POY11), BH55(= ~10 x POY11), ALSY(= ~2000 x POY11)wink, but the side lobes were always there.
  - Disconnect cables in BH44 to open possible ground loops made during BH44 installation (especially 44 MHz generation part??).
  - Check if the noise was there before BH44 installation using past data.

Attachment 1: Screenshot_2023-01-24_11-43-40_POXPOYDark.png
  17412   Mon Jan 23 20:50:58 2023 AnchalUpdateASCAS WFS path beam profiled

I measured the expected beam profile by WFS photodiodes by measuring the beam when mode cleaner was unlocked from the point where beam is picked for WFS. See attachment 1 for beam details. z=0 is the point in the path where AS beam will merge.

For measuring the beam profile of AS beam, I had to focus it using a lens. I picked up a 360.6 mm ROC lens and placed it at z=-67 inch point. Then I profiled the beam at some comfortable section of the path and fitted it. with reverse z-axis. Using this method, I can place the lens back and obtain the original beam back. Attachment 2 shows this fitting process and identification of the original beam profiles. I plotted the AS beam profiles again in attachment 3 and saved them for seeding mode matching effort later. Note that we don't want to be super accurate here, so I did not do any error analysis, just wanted to finish this fast. Also pardon me for the bad quality plots, I did not want to learn Matlab plotting to make it beautiful.

Note: There is significant astigmatism in both IMC reflection beam and AS beam. This could be due to beam going through far off-center on lens. Something to keep in mind, again this measurement is not ideal in terms of precision but this large an astigmatism could not be due to measurement error.


  • Identify correct len(s) and their positions
  • Align the AS beam to WFS heads
  • Test the full signal chain.
Attachment 1: WFSPathBeamProfile.pdf
WFSPathBeamProfile.pdf WFSPathBeamProfile.pdf WFSPathBeamProfile.pdf
Attachment 2: ASFocPathBeamProfile.pdf
ASFocPathBeamProfile.pdf ASFocPathBeamProfile.pdf ASFocPathBeamProfile.pdf
Attachment 3: ASPathBeamProfile.pdf
ASPathBeamProfile.pdf ASPathBeamProfile.pdf ASPathBeamProfile.pdf
  17411   Mon Jan 23 16:31:23 2023 ranaUpdateALSDFD and Phase tracker AM coupling

Both the TF measurement and the noise measurements are useful, but the nosie measurement is much more meaningful. Since we expect the main coupling to be incoherent, what we really want is a noise budget style measurement:

  1. Measure the FM noise spectrum with only a single sine wave into the Moku.
  2. Same as #1, but with the AM noise added as you already did.
  3. Estimate the noise budget contribution by doing PSD subtraction, and then scale that by the excitation magntiude. This will be the contribution of beat amplitude noise to the measured calibration.

I took transfer function measurement of DFD AM coupling using noise excitation.

  17410   Mon Jan 23 11:20:44 2023 JCSummaryBHDBH44 RFPD optical path and LO/AS camera

Here's the beam path of BH44.

Attachment 1: BH44.jpg
  17409   Sat Jan 21 18:01:06 2023 AnchalUpdateALSDFD and Phase tracker AM coupling

I took transfer function measurement of DFD AM coupling using noise excitation.

Noise excitation setup

Noise is injected using C1:BAC-SPARE_CH14_EXC using awggui which is filtered by a foton filter to simulate the real beatnote RF amplitude noise measured by taking quadrature sum of C1:ALS-BEATY_FINE_I_OUT and C1:ALS-BEATY_FINE_Q_OUT. See attachment 1.

The DAC output is connected to MP1 at CH1. MP1 is set to run in waveform generation mode with following settings:


  • Carrier frequency: 45 MHz
  • Carrier Level: 500 mVpp
  • No offset or phase offset
  • Amplitude modulation ON
    • Modulation slope: 100%/V
    • Source Input: Ch1

The AWGUI is set to excite C1:BAC-SPARE_CH14_EXC using settings mentioned in attachment 2.

With this setup, the RF amplitude noise is simulated with MP1 and DAC excitation.

Transfer function measurement

With AWGGUI running as mentioned above, I simply used diaggui in spectrum mode for channels C1:BAC-SPARE_CH14_EXC and C1:ALS-BEATY_FINE_PHASE_OUT_HZ. The second channel is already calibrated into Hz, and the first channel is in counts. To convert it into voltage of amplitude fluctuation, I first converted DAC excitation to voltage by assuming 16 bit DAC with +/- 10 V range, this gives conversion constant of 10/2**15 V/cts. Then since MP1 is doing 100%/V AM modulation, for 500 mVpp RF level, this means 0.25 V/V AM modulation. Multiplying these two together gives, 7.6294e-5 V/cts. I put this number in teh diaggui calibration for C1:ALS-BEATY_FINE_PHASE_OUT_HZ.

This created the transfer function measurement attached in attachment 3.

The measurement resulted in roughly 2kHz/V AM to frequency coupling in DFD + phase tracker setup. The previous measurement with coherent sinusoidal excitation was exactly a factor of 1000 less than this, so I believe I might have made some error in calibrating or there could be an error in the previous elog. Please check my calculations. But a solid thing to note is the coherence measured below 1Hz. I'll do more sophisticated analysis on weekdays.

I also think that coherence was low because of low excitation. We should redo this test with more noise power to get good coherence in all frequency band to have good idea of what would happen to ebatnote RF amplitude noise at all frequencies.

Mon Jan 23 11:47:23 2023 Adding Attachment 4:

I realised that with the noise excitation setup set to mimic real beatnote amplitude noise with very low frequency noise as it is seeded with Moku:Pro, the measured frequency noise by the DFD+Phase Tracker setup at C1:ALS-BEATY_FINE_PHASE_OUT_HZ is an indicator of how much RF amplitude noise of beatnote contribute to the frequency noise measured by DFD+Phase tracker. Attachment 4 is the spectrum measured during this measurement.

Attachment 1: BeatYRFAmplitudeNoiseASDwithSimulation.pdf
Attachment 2: AWGguiSettingsForSimulatedRFAMNoise.png
Attachment 3: DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf
DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf DFD_AM_to_Hz_Coupling_upto_0p1Hz.pdf
Attachment 4: DFD_Phase_Tracker_Noise_Due_To_Amplitude_Noise.pdf
  17408   Sat Jan 21 15:32:40 2023 AnchalUpdateASCAS WFS path nominally set

I've completed the beam redirection path for AS beam to WFS heads in a nominal way. By that I mean that all mirrors (M1, M2, M3, and M4) are now in their final positions and we will need to install one or two lenses to collimate the beam to match the mode that the WFS path is expecting as it has it's on the focusing lens before the photodiodes. For this last part, I think the fasted way would be to profile the beam and calculate the correct lens and position rather than trial and error as the beam intensity is very low for estimating the beam size by eye.

IMC WFS state: Flip M1 and M2 down.

AS WFS state: Flip M1 and M2 up.

Attachment 1: PXL_20230121_231740878.NIGHT.jpg
  17407   Fri Jan 20 20:13:20 2023 AnchalUpdateASCInstalled 2 flipper mirrors for handingl MC reflection beam to camera

After discussions with Yuta, I figured that a better optical layout is possible which does not interfere with the existing IMC WFS path at all. So I reset the IMC WFS path today (and zeroed RF offsets again) and changed the MC reflection camera and MC reflection beam dump (black hole) position to create space for a flipper mirror that will pop up in the IMC WFS path and steer in the AS beam. New proposed path is shown in the photo in cyan. Red is MC reflection beam, yellow is IFO reflection beam and orange is teh AS beam that we will pick up using flipper mirror M1. Note that I found an intense 6.4 mW ghost beam coming out of the interferometer in between IFO refl and MC refl beams. This beam is shown in pink which I have dumped now. This beam was earlier not dumped. We will need to investigate more on the source of this beam and correct it in the next vent.

Attachment 1: PXL_20230121_035908170.NIGHT.jpg
  17406   Thu Jan 19 20:35:54 2023 AnchalUpdateASCInstalled 2 flipper mirrors for handingl MC reflection beam to camera

Today I installed two flipper mirrors M3 and M4 (see attached photo) to create alternate route for MC reflection camera beam. Both these mirrors are Y1-1037-45S. In nominal operation where IMC is using the WFS, we will keep M3 upright and M4 flipped down. When using WFS for AS, M3 will be flipper down and M4 will be upright to save the camera from the high intensity MC reflection beam.

Note that everytime M3 is flipper and put back upright, the alignment into WFS would need to be tuned as the flipper apparatus does not come back to same alignment everytime. I centered the beams on the WFS heads today and zeroed RF offsets usingC1IOO_WFS_MASTER>!Actions>Correct WFS RF Offsets script. After this, the IMC WFS loops are working as expected atleast for last 15 minutes that I have monitored them. Hopefully, this will remain consistent.

Upcoming work:

  • Change the steering mirror that steers the beam to black hole to be a flipper mirror too as AS beam strength (measured when MICH was locked to bright port) is 0.3 mW and IMC WFS heads combined power is 0.5 mW in nominal operation, so we can not afford to dump any AS beam light.
  • Put flipper mirror M1 and fixed mirror M2 mentioned in 40m/17320 for steering AS beam to IMC WFS heads.
Attachment 1: PXL_20230120_041313615.jpg
  17405   Thu Jan 19 18:15:48 2023 yutaSummaryBHDBH44 RFPD optical path and LO/AS camera

[JC, Paco, Anchal, Yuta]

- We installed the new BH44 beam path and RFPD.

- JC installed the new beam path for the LO/AS camera.

- We succeeded in locking LO Phase with BH44_Q_ERR, but didn't attempt FPMI BH44 because we noted large 60 Hz harmonics in most of our RF error signals.

BH44 RPFD/Camera installation:

- We picked off LO/AS beam path previously going to the camera, and installed a Y1 (45 deg, s-pol) mirror, a f=150mm lens and the RFPD (Attachment #1). We initially tested it using the incandescent light from a flashlight and then aligned the beam, we also made sure it's not saturating.

- Using the spurious transmission from the mirror mentioned above, we steered a new beam path for the camera and realigned it using another short focal length lens (f ~ 100 mm).

LO Phase control:

- We increased the whitening gain from 0 dB to 42 dB for both C1:LSC-BH44_I and C1:LSC-BH44_Q, and zeroed the offsets. Even before this step we could see a fringe from BH44, which is quite promising!

- After alignment was recovered on the LO/AS path, we succeeded in locking the single bounce (ITMX) LO phase using BH44_Q. Here the configuration was FM4, FM5 and a gain of ~ 5 * 0.5 = 2.5 (to match the typical BH55_Q error point).

- While BH44_Q was used to control the LO phase, we saw the BH55_Q was not zero but actually almost at max fringe value (see Attachment #2). This implies the BH44_Q is indeed orthogonal to BH55_Q with respect to the LO Phase!

FPMI lock:

- We locked electronic FPMI but noted a  large 60 Hz + harmonics component in the RF error signals including AS55, BH55, REFL55, and BH44 (see Attachment #3). We could hand off to FPMI and even locked the LO phase with BH44_Q, but we were not sure the BHD_DIFF error signal was fit for handoff to FPMI BHD. Therefore we stopped here.

60 Hz + harmonics:

- We did a quick investigation around the areas we have been working in the lab to see if we had introduced this noise in any obvious way. First we checked the new amplifier for the 44 MHz LO, we briefly removed its power but the 60 Hz noise remained. Then we checked the AP table, but nothing had really changed there. We also disconnected and removed the rolling cart with the marconi and other instruments from the LSC rack. Finally, we turned all the lights down. None of these quick fixes changed the amount of noise.

- We also tried looking at these error signals under different IFO alignment and feedback configurations. We always see the noise in the AS55 and REFL55 quadratures, but not in BH44, BH55 or BHD_DIFF unless MICH is locked.

Next steps:

- Investigate more into 60 Hz noise, why? where?

- Measure sensing matrix with LO Phase locked with BH44 and BH55 to make comparison.


Attachment 1: PXL_20230120_000603659.jpg
Attachment 2: Screenshot_2023-01-19_18-42-03_LO-ITMX_BH44Lock.png
Attachment 3: Screenshot_2023-01-19_18-29-24_60Hzandfriends_FPMIBHD.png
  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.

Attachment 1: BH44_IQDemodMeasuredDiff_1358192471.pdf
  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).

  - 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.

Attachment 1: PDInterface.JPG
Attachment 2: 44MHzGen.JPG
Attachment 3: IQdemod.JPG
Attachment 4: BH44_IQDemodMeasuredDiff_1358051213.png
Attachment 5: BH44_IQDemodMeasuredDiff_1358051325.png
Attachment 6: Screenshot_2023-01-17_20-57-18.png
  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]    

 - 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).

 - 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.

Attachment 1: Screenshot_2023-01-13_18-41-48_SensMat_FPMIBHD.png
Attachment 2: BHD_DARM_Sensors_20230113.pdf
Attachment 3: FPMI_calibrated_noise_20230113_LO1vsAS4.pdf
  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.

Attachment 1: Screenshot_2023-01-13_14-55-34.png
Attachment 2: FPMI_calibrated_noise_20230113.pdf
  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

Attachment 1: BH44_Transimpedance_From_Test_Port.pdf
  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


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.


  • 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.
Attachment 1: DFD_AM_coupling.pdf
  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.


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.

Attachment 1: IMG_4166.jpg
  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

Attachment 1: FPMI_calibrated_noise_20230112.pdf
Attachment 2: FPMI_calibrated_noise_20230112_HF.pdf
  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.

Attachment 1: xbeat_dfd.png
  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.

Attachment 1: WFS_Board_112B_Test.pdf
  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

 - 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

 - 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

 - 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

 - 2.617 * AS55_Q

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

4. Lock 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)
 - Acuation on 1 * LO1
 - UGF ~110 Hz (Attachment #3)

5. Hand over to BHD_DIFF

 - -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:


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    
(-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.

 - 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).

 - 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.

Attachment 1: Screenshot_2023-01-11_16-17-16_MICH.png
Attachment 2: Screenshot_2023-01-11_16-12-40_CARM.png
Attachment 3: Screenshot_2023-01-11_16-21-40_LOPHASE.png
Attachment 4: Screenshot_2023-01-11_16-10-54_DARM.png
Attachment 5: FPMI_calibrated_noise_20230111.pdf
Attachment 6: FPMI_calibrated_noise_20230111_HF.pdf
  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.

Attachment 1: WFS_Board_111B_Test.pdf
  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.

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

Attachment 1: Screenshot_2023-01-10_14-26-46.png
Attachment 2: IMG_1994.JPG
  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. 

Attachment 1: IMG_6465.JPG
  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.


Attachment 1: SUS_Model_Changes.png
Attachment 2: MC1_INMATRIX.png
  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;

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?

Attachment 1: PXL_20230104_233926284.MP.jpg
  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 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.
Attachment 1: PXL_20230104_233907953.jpg
  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
Attachment 1: als_rf_power_screenshot.png
  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.

Attachment 1: DACBE2CD-35EB-4314-92FD-71C5270A6961.jpeg
Attachment 2: 45D7AF8F-5955-4036-B8AE-D761C2838408.jpeg
  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
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
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.

Attachment 1: Screen_Shot_2023-01-03_at_3.37.07_PM.png
  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

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;
/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 );
/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]
/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).

Attachment 1: ETMY_cal.pdf
  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


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 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.



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.


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


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 %.


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


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%.


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.


  • 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
ELOG V3.1.3-