TITLE: 02/09 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Lock Acquisition
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY: I had a _small struggle to align XARM_IR, but I managed to get everything aligned enough. We're relocking at DC_READOUT.
LOG: No log.

• 23:31 UTC lockloss from a 7.6 earthquake from Cayman islands
  • Held in down for ~3 hours until the ground motion has reduced enough to try to lock
  • 03:54 UTC I started an IA after "IR was not found"
  • Couldn't aquire XARM_IR, probably since HAM2 tripped so the INPUT pointing isn't good.
    • Tried setting PR2 and IM4 back their top mass osems positions from the earlier IA ( I probably should have done the rest of the IMs here as well)
    • Tried reverting alignments to the same point during the last IA (20:18 UTC 02/08) then restarted with GREEN_ARMs again
    • I couldn't lock XARM IR again so I treneded back all the IMs top mass osems and moved them back to where they were during XARM_IR in the last IA earlier today
      • I started with IM4 and when I got to IM1_P I saw us finally center on the ASC_TR_B QPD that I had been watching and getting concerned that it wasntt getting any better until I hit IM1, once I got it close the automation took over and finished the IA.
        • I had to move each the IMs dozens of microradians

TITLE: 02/09 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Earthquake
INCOMING OPERATOR: Ryan C
SHIFT SUMMARY:
A day full of Tours. 

I tried to do a calibration and Lost lock during the Simulines, alog 82699. 
Relocking went very smothly after an Initial alignment.

Every thing was going well until a very sudden 7.6 Magnitude Earthquake struck which almost Immidiately unlocked us tripped multiple ISI's.


LOG:

TITLE: 02/09 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Earthquake
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: LARGE_EQ
    Wind: 3mph Gusts, 1mph 3min avg
    Primary useism: 107.61 μm/s
    Secondary useism: 16.20 μm/s
QUICK SUMMARY:

• We lost lock to a large earthquake (7.6) off the gulf of Honduras recently
  • It'll probably be a few hours till I can start relocking (3?)

When verbals announced an earthquake I checked the SEI screen the earthquake was listed as an 8.0 Mag!

I then quickly checked USGS and they also had listed it as an 8.0 Mag but it seems like it has since been demoted to a 7.6?
https://earthquake.usgs.gov/earthquakes/eventpage/us7000pcdl/executive

When it struck all the ISI's trip before verbals could finish announcing the earthquake.
I immidiately called Jim and ask him if I should hit the very large Earthquake button, but he said if things were already tripped then it doesn't really matter.




 

Dropped from Observing at 19:32:21 UTC
running calibration at 19:33 UTC

Command Ran:
pydarm measure --run-headless bb

notification: end of measurement
notification: end of test
diag> save /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250208T193344Z.xml
/ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250208T193344Z.xml saved
diag> quit
EXIT KERNEL

2025-02-08 11:38:55,388 bb measurement complete.
2025-02-08 11:38:55,389 bb output: /ligo/groups/cal/H1/measurements/PCALY2DARM_BB/PCALY2DARM_BB_20250208T193344Z.xml
2025-02-08 11:38:55,389 all measurements complete.

Command ran:
gpstime;python /ligo/groups/cal/src/simulines/simulines/simuLines.py -i /ligo/groups/cal/H1/simulines_settings/newDARM_20231221/settings_h1_20241005_lowerPcal_higherPUM.ini;gpstime
PST: 2025-02-08 11:42:39.733837 PST
UTC: 2025-02-08 19:42:39.733837 UTC
GPS: 1423078977.733837
2025-02-08 19:42:40,790 | INFO | File written out to: /ligo/groups/cal/H1/measurements/DARMOLG_SS/DARMOLG_SS_20250208T194240Z.hdf5
2025-02-08 19:42:40,798 | INFO | File written out to: /ligo/groups/cal/H1/measurements/PCALY2DARM_SS/PCALY2DARM_SS_20250208T194240Z.hdf5
2025-02-08 19:42:40,802 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L1_SS/SUSETMX_L1_SS_20250208T194240Z.hdf5
2025-02-08 19:42:40,807 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L2_SS/SUSETMX_L2_SS_20250208T194240Z.hdf5
2025-02-08 19:42:40,811 | INFO | File written out to: /ligo/groups/cal/H1/measurements/SUSETMX_L3_SS/SUSETMX_L3_SS_20250208T194240Z.hdf5
2025-02-08 19:42:40,811 | INFO | Overall driving parameters:

Lockloss 20:04 UTC During the simulines

Output:

2025-02-08 20:04:44,126 | INFO | Scanning frequency 1200.0 in Scan : DARM_OLGTF on PID: 2461496
2025-02-08 20:04:44,127 | INFO | Drive, on DARM_OLGTF, at frequency: 1200.0, is now running for 23 seconds.
2025-02-08 20:04:47,234 | INFO | Drive, on L1_SUSETMX_iEXC2DARMTF, at frequency: 11.13, and amplitude 13.856, is finished. GPS start and end time stamps: 1423080282, 1423080300
2025-02-08 20:04:47,234 | INFO | Scanning frequency 12.33 in Scan : L1_SUSETMX_iEXC2DARMTF on PID: 2461503
2025-02-08 20:04:47,235 | INFO | Drive, on L1_SUSETMX_iEXC2DARMTF, at frequency: 12.33, is now running for 25 seconds.
2025-02-08 20:04:49,049 | ERROR | IFO not in Low Noise state, Sending Interrupts to excitations and main thread.
2025-02-08 20:04:49,049 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L1_CAL_EXC
2025-02-08 20:04:49,049 | ERROR | Ramping Down Excitation on channel H1:LSC-DARM1_EXC
2025-02-08 20:04:49,049 | ERROR | Ramping Down Excitation on channel H1:CAL-PCALY_SWEPT_SINE_EXC
2025-02-08 20:04:49,049 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L3_CAL_EXC
2025-02-08 20:04:49,049 | ERROR | Ramping Down Excitation on channel H1:SUS-ETMX_L2_CAL_EXC
2025-02-08 20:04:49,049 | ERROR | Aborting main thread and Data recording, if any. Cleaning up temporary file structure.
ICE default IO error handler doing an exit(), pid = 2461462, errno = 32
PST: 2025-02-08 12:04:53.378517 PST
UTC: 2025-02-08 20:04:53.378517 UTC
GPS: 1423080311.378517


I just finished an Initial Alignment.

Sat Feb 08 10:06:41 2025 INFO: Fill completed in 6min 37secs

TCmins [-49C, -47C] OAT (-2C, 28F) DeltaTempTime 10:06:40

On Thursday Erik extended FMCSSTAT to monitor the FCES and End Station VEA temperatures ALOG82673

I have added the new channels to the FMCS STAT overview MEDM, which is generated by the script generate_fmcs_stat_medm.py

TITLE: 02/08 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 155Mpc
OUTGOING OPERATOR: Ryan S
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 3mph Gusts, 2mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.15 μm/s
QUICK SUMMARY:

H1 has been locked for almost 5 Hours.
All systems look great, at first glance.

LHO plans to drop from Observing for caibration from 19:30- 20:00 UTC.
 

TITLE: 02/08 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
INCOMING OPERATOR: Ryan S
SHIFT SUMMARY:

H1 lockloss after 14+hr lock.  During locking, took opportunity to (1) LOAD Violin_Damping & (2)Address POP_A p/y offsets.  Within 2-3min of getting to OBSERVING, S250208ad GW Candidate rolled through.

There have been elevated PSL Dust counts throughout the shift.
LOG:

• 0040--0120 Visits to EX, MX, Mechanical Room (mike, janos)
• 0119 implemented ITMy M5 new violin damping settings (from RyanC)--need to LOAD VIOLIN_DAMPING to have guardian use these settings.
• 0210 Locklos
  • 0210 VIOLIN DAMPING LOADed & took GRD IFO to MANAGED
  • 0214 INITIAL ALIGNMENT
    • 0235 ISC LOCK restarts another alignment!!  (we were in MICH BRIGHT when this happened!)
    • Had noticed that ISC LOCK was MANAGED (by H1_Manager....but why?)
    • 0235 H1 Manager's log notes "waiting for green"  timer was DONE.....AND then it selected to do an Alignment----but I was already running one!  :-/
    • I took H1 Manager to IDLE and ISC LOCK to AUTO
  • 0235-0251 Initial Alignment (Round 2! started by H1 manager)
  • Locking to NLN was pretty straightforward. 
  • Took opportunity to add offsets to POP_A's pit & yaw with Sheila's instructions and her over the phone.  This included another LOAD of ISC_DRMI (see alog).
• 0348 OBSERVING
• 0351 GW Candidate Event S250208ad
• 0418-0423 out of observing due to PI24

After the ETMx Glitch Lockloss, had the opportunity to address the POP_A Offsets via Sheila's alog (but she also phoned in to walk me through it!)  :) 

• Held ISC_LOCK at PREP_DC_READOUT_TRANSITION
• Took lines 1030 & 1031 of ISC_DRMI.py to TRUE (from false):
  • self.usePRC1 = True  #returned to TRUE after adding new POP_A Pit OFFSET on feb7, 2025
  • self.usePRC2 = True  #returned to TRUE after adding new POP_A Pit OFFSET on feb7, 2025
  • ISC_DRMI.py LOADed
• Entered new OFFSETs for POP_A pit/yaw (which had been 0).  Now they are:
  • H1:ASC-POP_A_PIT_OFFSET = -0.465
  • H1:ASC-POP_A_YAW_OFFSET = -0.557
• ACCEPTED the new POP_A OFFSETs in the ASC safe.snap (attached)
• Continued on to Nominal Low Noise
• ACCEPTED the new POP_A OFFSETs in the ASC observe.snap (attached)
• Back to Observing at 0348utc.  Also took a screenshot of all the windows I had up for this change (attached)

H1 just had an ETMx Glitch lockloss (after 14.25hr lock).

H1 MANAGER Ended An Alignment To Start Another Initial Alignment!

Some weirdness was that I proactively ran an Initial Alignment, but while in MICH BRIGHT, ISC_LOCK took over and restarted an Initial Alignment at 0235utc!! (I had GRD IFO in MANAGED...but noticed that ISC LOCK was also still MANAGED [by H1 MANAGER]).  H1 Manager's log had a note about a timer "waiting for green" was done, so h1 manager thought we needed to run an alignment.   :-/

At any rate, let this 2nd Alignment run through, and now back to locking.

See that h1's violin is still high, and then noticed that ITMy Mode5 is currently running with:  0.0 gain + FM8 ON.  To damp this down since the big ring-up on Tuesday, Ryan C found some settings which had been working (and after a few days of seeing them help, he updated lsc_params to with these new settings, BUT we need to run a LOAD of VIOLIN_DAMPING to implement these settings next time we are out of OBSERVING (this LOAD slipped my mind after my lockloss a few minutes before the end of my shift).

In the meantime, I made the change by hand (~13.5hrs into our current lock):

• 0119utc I took the gain to -0.01 + turned FM8 OFF  (all of this done while in OBSERVING)

TITLE: 02/08 Day Shift: 1530-0030 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Observing at 51Mpc
INCOMING OPERATOR: Corey
SHIFT SUMMARY:
H1 Stayed Locked the Entire Day! There were multiple times when we fell out of Observing.  This was because the SUS_PI Guardian decided that we needed !!! XTREME_PI_DAMPING !!!, like Macho Man Randy Savage's new Mountain Dew comercial on repeat.
Sheila agreed that it was just a little too Xtreme, and changed the threshhold for XTREME from 20 to 40 so we can get some Observing time in.

Other than and Sheila's Picoing on POP QPDs  that it's been a quite but ! XTREME ! day.


LOG:                                                                                                                                                                                                                                   

TITLE: 02/08 Eve Shift: 0030-0600 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Observing at 146Mpc
OUTGOING OPERATOR: Tony
CURRENT ENVIRONMENT:
    SEI_ENV state: CALM
    Wind: 14mph Gusts, 11mph 3min avg
    Primary useism: 0.03 μm/s
    Secondary useism: 0.14 μm/s
QUICK SUMMARY:

For the handoff today, Tony mentioned the change to the threshhold for PI Mode24.  And also got a run down from Sheila alignment/offset items for DRMI due to the pico-ing onto the POP photodiodes (for next lockloss, I will probably look at DRMI alignment and if it looks rough (or if ALS has issues), I'll run an Initial Allignment.)

Microseism continues to trend down to/below the 50th percentile.  Breezes are under 15mph.

J. Kissel
ECR E2500017
IIET Ticket IIET:33143
WP 12302

As a follow-on to LHO:82509, where I installed the infrastucture that down-sampled the new-ish 524 kHz, filtered, pick-off paths of the OMC DCPDs in the same way as the primary GW path, here is the explicit list of channels that are now available. 

Be forwarned -- unlike the primary path 16 kHz channels, the configuration of the ADC input matrix and filters of the 524 kHz test banks are *not* controlled by the SDF system, and are not a part of the DARM loop, so "we" can do whatever we want with them, even during observing without any impact on or change in the detector. In other words, you aren't guaranteed that these 16 kHz test channels will have the same signal processing forever. Please either check we me -- or preferably learn how to look at the configuration of EPICs records and filter modules yourself -- so you understand what to expect in the test pick-off channels when you compare them against the their primary path counter part.
I can at least promise when *I* make a change to these channels, it will be explicitly aLOGged, as I have been doing (something like LHO aLOGs 82384 or 82313). But -- I can't encourage this enough -- all EPICs records and filters are saved at all times always and forever, so being able to lookup and reconstruct the configuration from *that* is the end-all-be-all.

For now, the test paths are set up to produce results like in LHO:82512, and I outline the differences between the paths below.

All of these channels are calibrated into [mA] on the DCPDs. We can work with you if you need these in different units, but for line hunting and comparative analyses like ASD ratios and transfer functions the units really shouldn't mean much more to you than what you should label your y-axis.

It may be useful to reminder yourself of the analog side of these DCPD channels using the diagram from LHO:67644. Namely, below I mention "4CH average of analog voltage" because of the way the voltage from each DCPD is copied in analog and digitized on 4 separate ADC channels with the special "AA" chassis, D2300115, which is a normal AA chassis stripped of all filtering to be instead a pass-through-and-copy chassis.


H1:OMC-DCPD_A_OUT_DQ     
H1:OMC-DCPD_B_OUT_DQ      
 
    - primary GW path versions of DCPD A and B, 
    - 16 kHz down-sampled version of 524 kHz channels, because there's no filtering or gains applied in these 16 kHz banks
    - 4CH average of analog voltage, 
    - Stored in the frames at single-precision, but not limited by single precision noise below the ~7 kHz.
    - has NO 1 Hz 5th-order elliptic high-pass filter, or else the DARM loop would be terribly unstable and the IFO wouldn't work.
    - as of Friday 2025-01-24 has 2x 16kHz digital AA filters, and 1x digital 65kHz AA filters
    - BLUE traces in LHO:82512
          
H1:OMC-DCPD_16K_A1_OUT_DQ     
H1:OMC-DCPD_16K_B1_OUT_DQ   
 
    - first copy test path of DCPD A and B, 
    - 16 kHz down-sampled version of 524 kHz channels, because there's no filtering or gains applied in these 16 kHz banks
    - 4CH average of analog voltage, (by setting H1:OMC-ADC_INMTRX_1_9 and _2_10 element to 1.0, with all others in the _1 and _2 row set to 0.0)
    - has 1 Hz 5th-order elliptic high-pass filter ON to minimize impact of single-precision noise (in the 524 kHz version that's NOT stored in the frames).
    - as of Friday 2025-01-24 has NO digital AA filters
    - BROWN traces in LHO:82512
    
H1:OMC-DCPD_16K_A2_OUT_DQ   
H1:OMC-DCPD_16K_B2_OUT_DQ  

    - second copy test path of DCPD A and B
    - 16 kHz down-sampled version of 524 kHz channels4CH average of analog voltage, because there's no filtering or gains applied in this 16 kHz bank 
    - 4CH average of analog voltage, (by setting H1:OMC-ADC_INMTRX_3_9 and _4_10 element to 1.0, with all others in the _3 and _4 row set to 0.0)
    - has 1 Hz 5th-order elliptic high-pass filter ON to minimize impact of single-precision noise (in the 524 kHz version that's NOT stored in the frames).
    - as of Friday 2025-01-24 has 1x 16kHz digital AA filters, and 1x digital 65kHz AA filters, and thus 
    - a replica of how the primary path was set up PRIOR to 2025-01-24 (tho, the primary path never had the 1 Hz high-pass)
    - GREEN traces in LHO:82512


H1:OMC-DCPD_SUM_OUT_DQ
H1:OMC-DCPD_16K_SUM1_OUT_DQ     
H1:OMC-DCPD_16K_SUM2_OUT_DQ 
 
    - These are the primary path and two copies of the SUM of the DCPDs, "summed" with specific balancing matrix coefficients, i.e. the channels
        H1:OMC-DCPD_MATRIX_1_1 and _1_2
        H1:OMC-DCPD_MATRIX1_1_1 and _1_2
        H1:OMC-DCPD_MATRIX2_1_1 and _1_2
 
    - At the moment, the A and B inputs to the matrix have all the configuration notes of the corresponding A and B channels mentioned above, and there is no filtering or gain applied in the TEST SUM banks just like in the primary path.

    - These channels are directly proportional to DARM_ERR [counts], which is eventually calibrated into H1:GDS-CALIB_STRAIN (and all downstream "cleaned" products). Unfortunately, that coefficient of proportionality changes at the ~1% level every lock stretch, or else I'd quote it explicitly, but it's roughly 2.47e6 [mA/ct] or 4.05e-7 [ct/mA].
 
H1:OMC-DCPD_NULL_OUT_DQ       
H1:OMC-DCPD_16K_NULL1_OUT_DQ  
H1:OMC-DCPD_16K_NULL2_OUT_DQ    

    - Similar to the SUM channels, these are the primary path and two copies of the DIFFERENCE of the DCPDs, "subtracted" with specific balancing matrix coefficients, i.e. the channels
        H1:OMC-DCPD_MATRIX_2_1 and _2_2
        H1:OMC-DCPD_MATRIX1_2_1 and _2_2
        H1:OMC-DCPD_MATRIX2_2_1 and _2_2

    - Here as well, at the moment, the A and B inputs to the matrix have all the configuration notes of the corresponding A and B channels mentioned above, and there is no filtering or gain applied in the TEST SUM banks just like in the primary path.


I have not yet looked at the test-path SUM or NULL channels to understand anything about what's in there other than the obvious -- that they're replicas of the singular SUM and NULL channels that are *extremely* useful in commissioning the IFO. So, I anticipate these will be just as useful because we can use these test paths to configure two *other* versions of how the DCPD signals are processed.

The corner RGA (located on output arm between HAM4 and HAM5) lost connection to the control room computer and stopped collecting data around 6pm yesterday (2/6/25). The software gave an error stating "Driver Error: Run could not be stopped".

I could not ping the unit from the terminal, but Erik confirmed the port is still open on the network switch, so it seems to be an issue with the RGA electronics. Other RGAs connected to this computer can still be accessed.

I restarted the software and attempted to reconnect to the RGA, but no luck. I will have to wait until next Tuesday maintenance to troubleshoot. This unit had been collecting data for the past ~6 months without issue. I will perform a hardware reset at the next opportunity to try and bring the unit back online, otherwise we have a new PrismaPro we can replace this unit with during the next vent.

Starting on Feb 5th, we've had more ring ups of MODE24.  This doesn't seem related to the move of PR3, although it has been worse today it started before the move. 

We have been taken out of observing by extreme damping 15 times in the last 3 hours.  So for right now I've increased the threshold from 20 to 40 to go to extreme damping.  We will see if this avoids the need to go out, or just delays it by a few seconds.

Matt Todd, Jennie Wright, Sheila Dwyer

Today we lost lock right before the commissioning window, and so we made another effort at moving the spot on PR2 out of lock, correcting some mistakes made previously. Here's an outline of steps to take:

• run initial alignment, take screenshot of slider positions after or note time.
• with both green arms locked, PRM and SRM misaligned,  take ISC_LOCK in PR2_SPOT_MOVE which moves other sliders based on scaling of your manual adjustment of PR3 sliders:
  •     pitPR3toPR2 = -9.2;
        yawPR3toPR2 = +9.2;
        pitPR3toIM4 = 0.51;
        yawPR3toIM4 = 0.755;
        pitPR3toPRM = 1.5;
        yawPR3toPRM = 1.89;
  • For yaw these have been tested and do a fairly good job of preventing the ASC from needing to correct PR3 moves in full lock.  For pitch we haven't fine tuned them, but adjusted the IM4 value based on the gain change last April.
• Move PR3 in yaw, and you will see the ALS_COMM beatnote dropping (you can use sheila.dwyer/ndscope/PR2_spot_move_JW.yaml) you can restore the COMM beatnote by adjusting the pico (PICO_A_MOTOR_8), today Matt did roughly 100 steps on the pico for 3 urad on PR3yaw.
• Eventually PR3 pitch becomes misaligned because of the yaw to pitch cross coupling, to correct this you must move the guardian out of PR2 spot move, say use IDLE.  You can correct using the osem for PR3. 
• Iterate between these two, watching for the AS camera to become misaligned in pitch.  This happens because PR2 and IM4 also have yaw to pitch cross couplings. 
• When this happens, we moved PR2 to see IR flashes in the Xarm, then ran inital alignment steps for X arm IR and PRX to adjust the alignment of PR2, IM4, and PRM. This is a good checkpoint to save sliders
• Continue moving PR3 yaw, pico in PR2_spot_move and PR3 pitch with ISC_LOCK idle, until you get where you want to go.

When relocking:

• We did adjust the COMM beatnote beamsplitter on ISCT1, both pitch and yaw.  The pico couldn't quite recover us to a good beatnote, it's not correcting exactly the right DOF.
• The beam will have moved on the POP QPDs, so turn turn off PRC1 and PRC2 ASC in DRMI (PRC1 uses these QPD offsets)  Do this by editing lines 1030 and 1031 in ISC_DRMI.py
  •         self.usePRC1 = False  #tuend these to false because pop QPD will need a reset since we moved PR3 Feb 6th 2025
            self.usePRC2 = False
• Once we have all the ASC on at 2W, we want to reset these offsets, which can be done at the state DARM_TO_DC_READOUT, these will need to be accepted in both safe.snap and OBSERVE.snap

Today, we did not pico on these QPDs, but we need to.  We will plan to do that Monday or Tuesday (next time we relock), and then we will need to update the offsets.

Today, I also forgot to revert the change to ISC_DRMI before we went to observing.  So, I've now edited it to turn back on the PRC1 + PRC2 loops, but someone will need to load ISC_DRMI at the next opurtunity.

[M. Todd, C. Compton, G. Vajente, S. Dwyer]

Summary

To understand the effect of the Relative Intensity Noise (RIN) of the CO2 laser (Access 5W L5L) proposed for CHETA on the DARM loop, we've done a brief study to check whether the addition of the RIN as displacement noise in deltaL will cause saturation at several key points in the DARM loop such as the ESD driver and DCPDs. The estimates we've made on the RIN at these points are calibrated with the DARM model in pydarm, which models the DARM loop during Nominal Low Noise; however, appropriate checks have been made that these estimates are accurate or at least over-estimating of the effects during lower power stages (when the CHETA laser will be on).

CHETA RIN to ESD drive

This estimate is done by propagating displacement noise in deltaL (how CHETA RIN is modeled, m/rtHz) to counts RMS of the ESD DAC. The RMS value of this should stay below 25% or so of the saturation level of the DAC, which is 2**19. To do this, we multiply the loop suppressed CHETA RIN (calibrated into DARM) by the transfer functions mapping deltaL to ESD counts (all are calculated at NLN using pydarm).

The CHETA RIN in ESD cts RMS is 0.161% of the saturation level, and in L2 coil cts RMS is 1.098%, and in L3 coil cts RMS is 0.015%. It is worth noting that the CHETA RIN RMS at these points is around 10x higher than that which we expect with just DARM during NLN.

We also checked to make sure that the ESD cts RMS during power-up states is not higher than that during NLN, meaning the calibration using NLN values gives us a worst case scenario of the CHETA RIN impact on ESD cts RMS.

List of Figures:

    1) Loop Model Diagram with labeled nodes
    2) CHETA RIN in ESD cts RMS
    3) CHETA RIN in L2coil cts RMS
    4) CHETA RIN in L1coil cts RMS
    5) DARM Open Loop Gain - pydarm
    6) DARM Sensing Function - pydarm
    7) DARM Control Function (Digitals) - pydarm
    8) Transfer Function: L3DAC / DARM_CTRL - pydarm
    9) Transfer Function: L2DAC / DARM_CTRL - pydarm
    10) Transfer Function: L1DAC / DARM_CTRL - pydarm
    11) ASD/RMS ESD cts during power-up states - diaggui H1:SUS-ETMX-L3_MASTER_OUT_UL_DQ
    12) CHETA RIN ASD (raw)

CHETA RIN to DCPD ADC

This estimate is done by propagating displacement noise in deltaL (how CHETA RIN is modeled, m/rtHz) to counts RMS of the DCPD ADC. The RMS value of this should stay below 25% or so of the saturation level of the DAC, which is 2**15. To do this, we multiply the loop suppressed CHETA RIN (calibrated into DARM) by the transfer functions mapping deltaL to DCPD ADC counts, using the filters in Foton files. This gives us the whitened ADC counts, so by multiplying by the anti-whitening filter we get the unwhitened DCPD ADC cts RMS, which is what is at risk of saturation.

The CHETA RIN in DCPD cts RMS is 3.651% of the saturation level. Again, it is worth noting that the CHETA RIN RMS at this point is around 10x higher than that which we expect with just DARM during NLN.

We also checked to make sure that the DCPD-A ADC channel is coherent with DARM_ERR. In short, it is up to 300Hz, where controls noise dominates our signal -- after 300Hz shot noise becomes the dominant noise source and reduces our coherence.

List of Figures:

    1) Loop Model Diagram with labeled nodes
    2) CHETA RIN in DCPD ADC cts RMS
    3) Transfer Function: DCPD-ADC / DELTAL_CTRL
    4) Coherence: DCPD-A / DARM_ERR

Codes used:

Calibrating CHETA RIN to ESD cts RMS

Calibrating CHETA RIN to DCPD ADC cts RMS

Previous related alogs:
    1)  alog 82456