(Jordan V., Gerardo M.)
Late entry.  Removed the old batteries for both stations, and installed new batteries with a larger capacity.
Both stations were tested after replacing the batteries, and the solar panel controllers were noted as charging the new batteries.  No issues noted with either station.

Graeme, Matt, Craig

Using our setup from yesterday (alog 76397), we injected into the common mode board and measured a CARM to DARM transfer function.
Matt will post plots, comparisons, and measurement times later.

I am posting the data now, it lives in /ligo/gitcommon/psl_measurements/data/carm_to_darm_tfs/.

Just to clarify what these measurements are, we injected a 600 mV broadband white noise injection from 51.2 kHz to 102.4 kHz frequency span into the common mode board excitation point.
We measured out at the REFL A 9 QMON at the PSL racks (which is actually REFL A 9 I used for frequency feedback) and out of the OMC DCPD whitening chassis A+ terminal, patched over to the PSL racks as described in alog 76397.

We saw a significant rise in the REFL A 9 QMON noise as we injected more (Matt's plots to come), but very little increase in the OMC DCPD noise.
We had around 5e-3 coherence between the two at best.
We took 10000 averages, so we believe that anything above 1e-4 is "well-resolved".

We did not have time to try injecting between 1 kHz and 51.2 kHz before we lost lock, or to try looking at OMC DCPD A / EXC
We were not injecting at the time of the lockloss.  
We left the SR785 out there but not plugged in to anything on the racks so we can relock peacefully.

EDIT:
We went back out, got some data betwen 1 kHz and 52 kHz, and then unplugged everything, including the SR785 and the HAM6 OMC DCPD A+ whitening chassis cable.  We didn't unplug the patch panel connection.

Jennie W, Craig C.

We paused the IFO at state 503 (CHECK_VIOLINS_BEFORE_POWERUP) and took another test where we looked at the power on POPAIR B RF18 and 90 while changing first the 9 and the 45 MHz modulation depths.

The times series of the two PDs readouts we care about and the guardian is the first image. the second image shows all the PDs in one document.

Results are:

Sideband and carrier powers at each diode

H1:IMC-PWR_IN_OUT16 9 power = 0.051 W
H1:IMC-PWR_IN_OUT16 45 power = 0.117 W
H1:IMC-PWR_IN_OUT16 carrier power = 1.834 W
H1:IMC-PWR_IN_OUT16 total DC power = 2.003 W
H1:IMC-IM4_TRANS_NSUM_OUT16 9 power = 0.047 W
H1:IMC-IM4_TRANS_NSUM_OUT16 45 power = 0.105 W
H1:IMC-IM4_TRANS_NSUM_OUT16 carrier power = 1.668 W
H1:IMC-IM4_TRANS_NSUM_OUT16 total DC power = 1.819 W
H1:LSC-REFL_A_LF_OUT16 9 power = 0.014 mW
H1:LSC-REFL_A_LF_OUT16 45 power = 0.028 mW
H1:LSC-REFL_A_LF_OUT16 carrier power = 0.210 mW
H1:LSC-REFL_A_LF_OUT16 total DC power = 0.252 mW
H1:LSC-REFL_B_LF_OUT16 9 power = 0.013 mW
H1:LSC-REFL_B_LF_OUT16 45 power = 0.026 mW
H1:LSC-REFL_B_LF_OUT16 carrier power = 0.193 mW
H1:LSC-REFL_B_LF_OUT16 total DC power = 0.231 mW
H1:LSC-POP_A_LF_OUT16 9 power = 34.865 uW
H1:LSC-POP_A_LF_OUT16 45 power = 28.588 uW
H1:LSC-POP_A_LF_OUT16 carrier power = 1027.882 uW
H1:LSC-POP_A_LF_OUT16 total DC power = 1091.334 uW
H1:ASC-POP_A_NSUM_OUT16 9 power = 8.372 cts
H1:ASC-POP_A_NSUM_OUT16 45 power = 6.709 cts
H1:ASC-POP_A_NSUM_OUT16 carrier power = 241.335 cts
H1:ASC-POP_A_NSUM_OUT16 total DC power = 256.416 cts
H1:ASC-POP_B_NSUM_OUT16 9 power = 7.685 cts
H1:ASC-POP_B_NSUM_OUT16 45 power = 6.310 cts
H1:ASC-POP_B_NSUM_OUT16 carrier power = 222.705 cts
H1:ASC-POP_B_NSUM_OUT16 total DC power = 236.701 cts
H1:ASC-AS_C_NSUM_OUT16 9 power = 0.019 W
H1:ASC-AS_C_NSUM_OUT16 45 power = 0.051 W
H1:ASC-AS_C_NSUM_OUT16 carrier power = 0.032 W
H1:ASC-AS_C_NSUM_OUT16 total DC power = 0.101 W
H1:ASC-OMC_A_NSUM_OUT16 9 power = 0.020 W
H1:ASC-OMC_A_NSUM_OUT16 45 power = 0.057 W
H1:ASC-OMC_A_NSUM_OUT16 carrier power = 0.032 W
H1:ASC-OMC_A_NSUM_OUT16 total DC power = 0.109 W
H1:ASC-OMC_B_NSUM_OUT16 9 power = 0.018 W
H1:ASC-OMC_B_NSUM_OUT16 45 power = 0.049 W
H1:ASC-OMC_B_NSUM_OUT16 carrier power = 0.031 W
H1:ASC-OMC_B_NSUM_OUT16 total DC power = 0.097 W
H1:ASC-X_TR_A_NSUM_OUT16 9 power = 45.016 W
H1:ASC-X_TR_A_NSUM_OUT16 45 power = 52.783 W
H1:ASC-X_TR_A_NSUM_OUT16 carrier power = 10961.375 W
H1:ASC-X_TR_A_NSUM_OUT16 total DC power = 11059.174 W
H1:ASC-X_TR_B_NSUM_OUT16 9 power = 57.131 W
H1:ASC-X_TR_B_NSUM_OUT16 45 power = 66.290 W
H1:ASC-X_TR_B_NSUM_OUT16 carrier power = 14355.521 W
H1:ASC-X_TR_B_NSUM_OUT16 total DC power = 14478.941 W
H1:ASC-Y_TR_A_NSUM_OUT16 9 power = -258.850 W
H1:ASC-Y_TR_A_NSUM_OUT16 45 power = 380.017 W
H1:ASC-Y_TR_A_NSUM_OUT16 carrier power = 14506.812 W
H1:ASC-Y_TR_A_NSUM_OUT16 total DC power = 14627.979 W
H1:ASC-Y_TR_B_NSUM_OUT16 9 power = -267.817 W
H1:ASC-Y_TR_B_NSUM_OUT16 45 power = 403.885 W
H1:ASC-Y_TR_B_NSUM_OUT16 carrier power = 15432.447 W
H1:ASC-Y_TR_B_NSUM_OUT16 total DC power = 15568.516 W

Power-recycling gains for sidebands and carrier

9 MHz PRG = 70.9
45 MHz PRG = 25.9
Carrier PRG = 58.4

Reflection ratios for sidebands and carrier

9 MHz reflection ratio = 0.176
45 MHz reflection ratio = 0.159
Carrier reflection ratio = 0.075
 

To run test make sure corner POP beam diverter is unshuttered (which it is in this guardian state) then run labutils/mod_depth_up_down_test/code/measure.py, then find the csv file with the correct GPS time in ../data and copy the start and stop times for the mod-depth changes into mod_depth_analysis.py and run this file.
The level on POP90 in the nominal blue region is not in a steady state which means we did not wait long enough at 2W when the measurement finished to get a good estimate of the nominal power on the diode before the IFO started powering up to 10W in the next guardian state.

Dhruva, Naoki, Sheila, Trent, Camilla

This afternoon we tried some SQZ optimization, left SQZ ASC on while squeezing.

Edit: Going back to 120/120 after the IFO has been locked for 2.5 hours we see a lot less frequency dependent rotation. The rest of the team is continuing PSAMS optimization now.

Dhruva measured is NLG is 17. sqzparams.opo_grTrans_setpoint_uW is at 80uW, giving us 21.4 SHG Launch. OPO temperature optimized during this measurement.

TITLE: 03/15 Day Shift: 15:00-23:00 UTC (08:00-16:00 PST), all times posted in UTC
STATE of H1: Commissioning
INCOMING OPERATOR: None
SHIFT SUMMARY:

IFO is in NLN and COMISSIONING

Control Room Operation Log 03/15

 ———————————————————— Shift begin to Nominal Low Noise

15:42 UTC - NLN

16:30 UTC - Erik rebooting Nuc29 due to it flipping on and off - successful

 ———————————————————— Nominal Low Noise to Lockloss/Lock Attempt 1

17:03 UTC - Lockloss ISI EX Stage 1, 2, SUS EX, SUS TMSX WD tripped due to commissioning (known reason)

17:34 - Resetting WDs reset - Counts got to 136 for LL AC on L2.

• EX bottom 2 stages have not leveled off below the new arbitrary 25 (micron) value. We have contacted Jeff to ask if we can raise the thresholds
• After 30 minutes and still no ringing, thresholds are still above 100 but oscillating lower
• We are thinking of adjusting the threshold to get to locking, due to commissioning. (screenshot below).
  • Pressed the reset button again and values went from 100s to sub unity very quickly
    • I wonder if pressing it initially tried damping and then when in a more damped state, re-pressing was much more effective? (screenshot 2)
    • I didn’t know nor think that the reset button activates damping? What’s going on here?
  • Issue passed off to Jeff and Oli, who worked on this change (data counts to micron units) recently.
  • Jeff responded saying that the damping loops do take care of the ring-up after the WD is tripped - just need to press it sooner.

17:36 -  Started locking - stopping at Damp Bounce for some commissioning tests (Jennie and Craig)

17:55 - Guardian restarted with NEW_DARM being the new (nominal) DARM.

18:02 - BS touched by Georgia in order to improve BS - but went into MICH_FRINGES before much movement

18:05 - Lockloss at CHECK_MICH_FRINGES - relocking now.

18:07 - Pointed out by TJ, and trended to confirm - the ALS X TRX is much lower than the last few lock attempts. It was hovering around 1.2 yesterday and is maxing at 0.7 today despite a high comm beat note (~6). This might warrant an initial alignment if the current lock attempt fails. 

18:25 - BS moved by Georgia to acquire PRMI - success 

18:26 - DRMI Locked

18:32 - Lockloss DRMI

 ———————————————————— Lock Attempt 1 to Init Align

18:32 - Initial Alignment Started 

18:40 - Initial Alignment Strangeness - while ALS locked for both arms, the WFs took a while to offload, keeping us in this state for longer than expected - alogged by Camilla (alog 76423)

18:47 - ALSX Transmission values are back to what they were yesterday - around 1.2. Expecting this to fix DRMI locking issues.

19:02 - Initial Alignment Complete - requested CHECK_VIOLINS_BEFORE_POWERUP for Jennie/Craig to run their tests.

 ———————————————————— Init Align to Lock Attempt 2

19:21 - Reached CHECK_VIOLINS_BEFORE_POWERUP for Jennie to take her measurements.

19:26 - Tests done, NLN requested

19:29 - HAM7 WD Tripped - potentially due to SQZ work - requested pre-squeeze state - ADS_TO_CAMERAS. Camilla letting Naoki and Nutsinee know - checking WD now.

19:34 - WD reset successfully.

19:40/1 - Requested and reached TRANSITION_FROM_ETMX for commissioning work.

19:54 - Lockloss - DRMI unlocked (reason not immediately apparent)

 ———————————————————— Lockloss to Lock Attempt 3

20:30 - Lockloss - DRMI unlocked at LOWNOISE_ASC (Alenna caused via changes made in that state)

20:47 - Gerardo informed the control room that the computing room across from the control room had a loud fan and that the back wall was vibrating - informed facilities and Tyler is investigating. Nothing was wrong according to Tyler and Eric.

21:18 - Locked and in NOMINAL_LOW_NOISE

 ———————————————————— Nominal Low Noise to Shift End

22:38 - Craig Running CARM Injection Tests

22:48 - Craig’s Tests done - preparing for future injections

LOG:

[Elenna, Louis]

We reduced the amplitudes of the L2 and L3 SUS calibration lines. Both lines were way too loud after moving to the new DARM loop offloading configuration. The settings we ended up on are below:


Line | Freq | Gain | DELTA_L/SUS_EXC uncertainty 

L2   | 16.4 Hz | 1.5 | 0.0058
L3   | 17.6 Hz | 0.061 | .0046


For each step I changed all of the following channels:
H1:SUS-ETMX_L2_CAL_LINE_CLKGAIN, H1:SUS-ETMX_L2_CAL_LINE_SINGAIN, H1:SUS-ETMX_L2_CAL_LINE_COSGAIN, H1:CAL-CS_TDEP_SUS_LINE2_COMPARISON_OSC_CLKGAIN, H1:CAL-CS_TDEP_SUS_LINE2_COMPARISON_OSC_SINGAIN, H1:CAL-CS_TDEP_SUS_LINE2_COMPARISON_OSC_COSGAIN

I'm attaching the CAL-CS SUS Line screens for both lines. Red boxes highlight the gains that we adjusted.

With this new value of the optical gain, when Kappa_c = 1, the optical gain would be 2.1% higher than before the OMC realignment.

This has been the plan for a while, to add Picket Fence to the SEI_ENV earthquake transition. I more or less copied the logic for the PEAKMON tests that we use for the earthquake transitions and appliedt that to the network peak channel for picket fence. So if the network peak channel goes above 800nm/s that will cause SEI_ENV to transition to the appropriate earthquake state. I have convinced myself that the worst case scenario is we just won't transition early because of network lag in picket fence. I haven't seen any cases so far where a signal in picket fence would cause us to unnecessarily transition. I have seen many cases where picket fence gave ~30sec of early warning. The code is pretty simple and only got added to two or three state test in SEI_ENV, so if it breaks something it will be easy to remove.

FAMIS26288

All vibrometers look to be reporting stable levels.

I've written a new check_model_changes program (used to be called check_model_daq_changes) to additionally check for any IPC addition or removal.

If an IPC sender has been removed, the code gives the list running models which currently have receivers as a reminder that they should also be changed.

The code is designed to be ran between running "rtcds build" and "rtcds install" to catch any issues before the production files are overwritten.

If the list of DAQ channels which have been added/removed is long, the code defaults to showing the first ten channels. The --all argument gives the full list.

For example, after building the h1susitmx and h1isiitmx models on h1build:

david.barker@opslogin0: check_model_changes h1susitmx
--------------------- file times ----------------------
Fri Mar 15 13:35:17 2024 = Model build time
Tue Mar 12 14:47:02 2024 = Current configuration load time
 
DAQ configuration is changed, processing...

++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_OFFSET added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_GAIN added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_LIMIT added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_TRAMP added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_SWREQ added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_SWMASK added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_INMON added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_EXCMON added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_OUT16 added to the DAQ
++: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RMSLP_F1_OUTPUT added to the DAQ
++: ... plus 210 more slow channels ...
--: slow channel H1:SUS-ITMX_DACKILL_STATE removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_RESET removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_BPSET removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_BPTIME removed from the DAQ 
--: slow channel H1:SUS-ITMX_DACKILL_PANIC removed from the DAQ 
--: slow channel H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_TX removed from the DAQ 
--: slow channel H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_SHMEM_TX removed from the DAQ 
--: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_SD_RMSMON removed from the DAQ 
--: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_RT_RMSMON removed from the DAQ 
--: slow channel H1:SUS-ITMX_R0_WD_OSEMAC_LF_RMSMON removed from the DAQ 
--: ... plus 19 more slow channels ...

Total number of DAQ changes = 249
(220 additions, 29 deletions)
 
IPC Senders have been removed
Please wait while ipc receiver database is generated...
----------------------------------------------------------------------------------------------------------------------------done 
IPC: 2 Removed Senders
     H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN NOTE: receiver in model(s) ['h1isiitmx']
     H1:FEC-29_IPC_SUS_ITMX_M0R0_WDMON_STATE_SHMEM NOTE: receiver in model(s) ['h1susitmpi']

david.barker@opslogin0: check_model_changes h1isiitmx
--------------------- file times ----------------------
Fri Mar 15 13:20:55 2024 = Model build time
Tue Mar 12 14:47:01 2024 = Current configuration load time
 
DAQ configuration is changed, processing...

--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_ER removed from the DAQ 
--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_ET removed from the DAQ 
--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_PS removed from the DAQ 
--: slow channel H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN_RX removed from the DAQ 

Total number of DAQ changes = 4
(0 additions, 4 deletions)
 
IPC: 1 Removed Receiver:
     H1:FEC-70_IPC_SUS_ITMX_M0R0_WDMON_STATE_DOLPHIN

The readback of the broadband PD in transmission of the SHG (SQZ-SHG_TRANS_DC) was electronicslly saturating. We switched the gain from 10x to 1x on the generic PD interface box and adjusted the transimpedance gain accordingly. The readback now shows ~1.2V and 7.2mW.

Closes FAMIS 26235

Laser Status:
    NPRO output power is 1.819W (nominal ~2W)
    AMP1 output power is 67.79W (nominal ~70W)
    AMP2 output power is 138.9W (nominal 135-140W)
    NPRO watchdog is GREEN
    AMP1 watchdog is GREEN
    AMP2 watchdog is GREEN

PMC:
    It has been locked 14 days, 20 hr 29 minutes
    Reflected power = 16.63W
    Transmitted power = 109.4W
    PowerSum = 126.1W

FSS:
    It has been locked for 0 days 0 hr and 25 min
    TPD[V] = 0.8046V

ISS:
    The diffracted power is around 2.5%
    Last saturation event was 0 days 0 hours and 25 minutes ago

Possible Issues: None

Around 2024/03/15 18:39 UTC Elenna noticed that H1:GRD-ALS_XARM was in INITIAL_ALIGNMENT waiting for the WFs to converge. But the WFS weren't on!

ENABLE_WFS state compleated at 18:34UTC. It stayed in INITIAL_ALIGNMENT (state -16) until unlocked at 18:39:51UTC. Plot attached showing WFS off.

[Louis, Gabriele]

The DHARD_Y to DARM coupling always showed two regimes: a steep coupling below 20-30 Hz, and a flatter coupling above 20-30 Hz. We've been able to change the flatter coupling above 20-30 Hz by changing the ITMT Y2L coefficient.

Today we confirmed a suspicion: the steep low frequency coupling is due to length to angle coupling at the AS WFS. We changed the beam position on the WFS by adding an offset to the WFS centering (H1:ASC-AS_A_DC_YAW_OFFSET) and saw a change in the DHARD_Y to DARM coupling.

A value close to -0.14 gives the minimum coupling below 20 Hz. we now have two independent knobs to minimize the DHARD_Y to DARM coupling at all frequencies.

Incidentally, the higher frequency couping is now lower than yesterday, with the same ITMY Y2L coefficient of -1.65

We did a scan of the AS_A_WFS Y centering from -0.2 to -0.1 in steps of 0.01, an analysis will follow tomorrow:

-0.200: 1394510627 - 1394510727
-0.190: 1394510777 - 1394510877
-0.180: 1394510927 - 1394511027
-0.170: 1394511077 - 1394511177
-0.160: 1394511227 - 1394511327
-0.150: 1394511377 - 1394511477
-0.140: 1394511527 - 1394511627
-0.130: 1394511677 - 1394511777
-0.120: 1394511827 - 1394511928
-0.110: 1394511978 - 1394512078
-0.100: 1394512128 - 1394512228
 0.000: 1394512278 - 1394512378

We are leaving a value of -0.14 in the WFS offset

Naoki, Dhruva, Nutsinee

Yesterday we had only 3dB squeezing at IFO so we checked squeezing at homodyne. Although the visibility is good (98.5%), the squeezing was only 4.5dB at homodyne with 6dBm CLF6. We reduced the CLF power and recovered 8dB squeezing as shown in the attached figure.

The CLF6 was reduced from 6dBm to -42dBm and the 8dB squeezing was obtained with -38dBm CLF6. The CLF6 between -38 and -20 dBm gave similar squeezing so we set it at -24dBm, which is similar to O4a value and corresponds to 8uW CLF_REFL_LF_OUTPUT. The squeezing at IFO is recovered to 4.5dB with -24dBm CLF6.

Note that the LLO also saw the better squeezing at IFO with less CLF power in LLO70072.

We had 6.5dB squeezing at homodyne in 76040 and 4.5dB squeezing at IFO in 76226 with 6dBm CLF6 before. The question is why we lost squeezing at homodyne and IFO this week with same CLF power? The commissioning list in 76369 might give us a clue.

Last week when we locked the new OMC by hand I copy-pasted some guardian code into a shell, and found that there was a gain set and wait that were totally unnecessary. This inspired me to start reading through ISC_LOCK to look for other redundant waits. Here are my notes, I only got up to the start of LOWNOISE_ASC before I went totally cross-eyed.

Here are the notes I took, the ones in bold we can for sure remove.

Preparing for lock

Line 301-305 [ISC_LOCK, DOWN] Prcl UGF servo turn off (do we still do this?) no wait times but maybe unnecessary
Line 327 [PREP_FOR_LOCKING] Thermalization guardian (are we using this?)
Line 350-354 [PREP_FOR_LOCKING] Turn off CHARD blending, no wait times
Line 423 [PREP_FOR_LOCKING] turn off PR3 DRIVEALIGN P2P offset for PR3 wire heating
Line 719 [PREP_FOR_LOCKING] toggling ETM ESD HV if the output is low, seems redundant with line 445

Initial alignment

INITIAL_ALIGNMENT for the green arms only offloads a minute or 2 after it's visually converged. Initially I thought the convergence checker thresholds should be raised, but it's a 30 second average. Might make sense to reduce the averaging time?
(2 screenshots attached for this one)

Arm Length Stabilization

ALS_DIFF [LOCK] Ramps DARM gain to 40, waits 5 seconds, ramps DARM gain to 400, waits 10 seconds. Seems long.
ALS_DIFF Line 179, waits 2* the DARM ramp time, but why?
ALS_DIFF [LOCK] Enegages boosts with a 3 second wait, engages boosts with another 10 second wait
ALS DIFF Line 191 wait timer 10 seconds seems unnecessary.

ALS_COMM [PREP_FOR_HANDOFF] line 90 5 second wait - maybe we could shorten this?
ALS_COMM [HANDOFF_PART_3] lines  170 and 179 - 2 and 5 second timers but I'm not sure I get why they are there
ALS_COMM's Find IR takes 5 seconds of dark data, has two hard coded VCO offsets in FAST_SEARCH, if it sees a flash it waits 5 seconds to make sure it's real, and then moves to FINE_TUNE_IR, taking 50 count VCO steps until the transmitted power is >0.65
Suggest updating the hard coded offsets (ALS_DIFF line 247) from [78893614, 78931180] to [78893816, 78931184] (second spot seems good, first spot needs a few steps)

ALS_DIFF's find IR has 3 locations saved in alsDiffParams.dat which it searches around. This list gets updated each time it finds a new spot, HOWEVER the search starts 150 counts away from the startin location and steps in in increments of 30. Seems like it would be more efficient to start 30 below the saved offset?

ISC_LOCK [CHECK_IR] line 1206 has a 5 second wait after everything is done which could probably be reduced?

Power- and dual- recycled michelson locking

PRMI locking - a bunch of 1 second waits idk if they are needed?
ISC_DRMI line 627/640 [PRMI_LOCKED] self.timer['wait']=1 seems maybe unnecessary?
ISC_DRMI line 746, 748 [ENGAGE_PRMI_ASC] - MICH P and Y ASC ramps on with a 20 second timer, but wait = false, but this seems long anyway?
ISC_DRMI line 762/765/768 [ENGAGE_PRMI_ASC] self.timer['wait'] = 4... totally could remove this?
ISC_DRMI [PRMI_TO_DRMI] line 835 - wait timer of 4 seconds (but I don't think it actually waited 4 seconds, see third attached screenshot, so maybe I dont know what time['wait'] really means!!!
When doing the PRMI to DRMI transition it first offloads the PRMI ASC, does the PRMI_TO_DRMI_TRANSITION state, then runs through the whole DOWN state of ISC_DRMI which takes ~25 seconds? maybe there can be a quicker way to do this

In ISC_DRMI there's a self.caution flag which is set as True if AS_C is low, and has 10 second waits after ASC engagements and a *90 second* wait before tirning on the SRC ASC. Might be worthwhile to to replace this with a convergence checker since it might not be needed that we wait for a minute and a half if we are already well algined

Line 1845 ISC_LOCK [CHECK_AS_SHUTTERS] 10 second wait for...? This happens after the MICH RSET but before the FAST SHTTER is reqested to READY
Lines 1837/8 and 1865 redundant?
Line 1870 wait timer 2 seconds after AS centering + MICH turned back on but why
Line 1887 - straight up 10 second wait after increasing MICH gain by 20dB

CARM offset

Line 2119 [CARM_TO_TR] time.sleep(3) at the end of this state not clear what we're waiting for
Line 2222 [DARM_TO_RF] self.timer['wait'] = 2 that used to be 1
Line 2235 [DARM_TO_RF] another 2 second timer?
Line 2314 [DHARD_WFS] 20 second timer to turn DHARD on, but maybe we should just go straight to convergence checking once the gains are ramped on?
Line 2360 [PARK_ALS_VCO] 5 second wait after resetting the COMM and DIFF PLLs
Line 2406 [SHUTTER_ALS] 5 second wait followed by a 1 second sleep after the X arm, Y arm, and COMM are taken to shuttered
Line 2744 [CARM_TO_ANALOG] 2 second wait when REFLBIAS boost turned off but before summing node gain (A IN2) increased?
Line 2753 [CARM_TO_ANALOG] 5 second wait after summing node gain increased
Line 2760 [CARM_TO_ANALOG] 2 second wait after enabling digital CARM antiboost?
Line 2766 [CARM_TO_ANALOG] 2 second wait after turning on analog CARM boost
Line 2772 [CARM_TO_ANALOG] 2 second wait after raming the REFL_DC_BIAS gain to 0, actually maybe this one makes sense.

Full IFO

There are a ton of waits during the ASC engagement but I think usually the convergence checkers are the limit to time spent in the state.
Line 3706 [ENGAGE_SOFT_LOOPS] 5 second wait after everything has converged?
Line 3765 [PREP_DC_READOUT_TRANSITION] 3 second wait after turning on DARM boost but shouldn't it be 1 second?
Line 3816 [DARM_TO_DC_READOUT] 10 second wait after switching DARM intrix from AS45 to DC readout, might be excessive
Line 3826/7 [DARM_TO_DC_READOUT] - DARM gain is set to 400 (but it's already 400!) and then there is a 4 second wait, these two lines can for sure be removed!
Line 3834 [DARM_TO_DC_READOUT] - 5 second wait after turning ramping some offsets to 0 BUT the offsets ramp much more quickly than that!

Power up

line 4033 [POWER_10_W] 30 second wait after turning on some differential arm ASC filters but actually, never mind I don't think it actually does this wait
Line 4299 [REDUCE_RF45_MODULATION_DEPTH] we have a 30 second ramp time to ramp the modulation depths, maybe this could be shorter?
Line 4614 [MAX_POWER] 20 second thermal wait could be decreased?
Line 4641 [MAX_POWER] 30 second thermal wait could be decreased??
Line 4645 [MAX_POWER] 30 second thermal wait for the final small step could be devreased?

Lownoise stuff

line 4463/4482 [LOWNOISE_ASC] 5 second wait after we turn off RPC gains that were already off
line 4490 [LOWNOISE_ASC] 10 second wait after CHARD_Y gain lowered, but it looks to have stabilized after 5 seconds so I think we can drop this to 5.
honestly a lot of waits in lownoise_asc so I ran out of time to check them all for necessity

The CAL-CS filters installed by Jeff (LHO:76392) do a better job of correcting CAL-DELTAL_EXTERNAL. See darm_fom.png. Here's a screenshot of the filter banks: new_darm_calcs_filters.png.

Also, Evan's 5Hz high pass filter (LHO:76365) pretty much killed the strong kick we've been seeing each time we switch into this new DARM state from ETMY.