WP 13447

A L4C Interface Chassis was installed in the CER rack SEI-C2, slot U10. Output signals connected to both HAM ISI Anti-Alias Interface Chassis on slots U39 and U38. Part of HAM2 L4C upgrade.

AA Chassis Slot U39: Channels 25-28
AA Chassis Slot U38: Channels 25-28 and channels 29-32

Serial Number of Chassis: S2501278

Jennie Wright, Khanh Vu

This morning, July 22, we measured the input matrix of the wavefront sensors using step responses applied to the PZT and JM1. The collected data are attached below.

We turned on the offsets of the PZT and JM1 for both pitch and yaw, adjusted each offset, and measured the corresponding responses in the pitch and yaw channels of wavefront sensors A and B. For PZT yaw and pitch, we increased the offset by 400. We used smaller increments of 100 for JM1 yaw and 30 for JM1 pitch. The JM1 lock filters contained integrators and were not enabled in the actuator path, so we used the test filters to introduce the disturbances. After each measurement, we returned the offset to its original value so that the measurements were applied evenly.

Because the measurements were made using different offset values, we normalized the data by first dividing each response by its corresponding offset value and then dividing by the largest resulting value. The two values highlighted in red were recorded from noisy data, so they have high uncertainty. However, both values are very close to zero.

Measured Astigmatism due to ZM2

We've been investigating astigmatism in HAM 7 recently, and have found that ZM2 seems to be a prime suspect.  The actuation strength of the PSAMs depends sensitively on the beam spot size, so any astigmatism in the ZM2 optic will couple strongly to the optical beam due to its large beam size (w = 2.5 mm).

In 90815 we measured the beam profile before ZM4 and found that the astigmatism at that point does depend sensitively on the strain gauge setting for ZM4.  Below I compute the astigmatism in terms of the 1D overlap integral between the X and Y beam parameters.  This is a useful metric, since it tells us roughly what the maximum mode overlap we can achieve with another stigmatic mode (eg the SQZ-OMC mode overlap). 

Here, we notice that the overlap depends strongly on the ZM2 settings.  It can be quite bad for some strain gauge settings, but actually doesn't look too bad at the nominal operating point for O4 (3.15 V).  From the characterization data at Caltech, we know that the PSAM astigmatism can vary significantly with different settings, so this isn't surprising.  See this analysis from Lee:  Google Slides

The value for 3.15 V is roughly consistant with the recent measurement of the mode between ZM2 and ZM3.  I did a fit of the measurements in aLog 91142 and found that, at the nominal strain gauge setting, the XY overlap after ZM2 is 0.997.  Since ZM2 is double passed and actuates primarily on the beam defocus at FC1, we naively expect its contribution to the XY overlap right before ZM4 to be ~0.994.  This assumption doesn't alwasy hold, particularly if the beam is poorly mode matched to the FC and the retro beam at ZM2 has a very different spot size.

See the attached zip file for further analysis of the data from aLog 91142.  The data from this aLog also suggests that centering the beam better on ZM2 would reduce the astigmatism after ZM2 by about 50% at the nominal strain gauge setting.  This data doesnt appear to show a significant change in astigmatism for smaller offsets in the strain gauge setting, though the lack of data at the waist might be impacting the fit somewhat.

It seems that the severity of our astigmatism issue with ZM2 depends on whether our mode matching to the FC has changed significantly since replacing the VOPO in December.  If we need to change the ZM2 setting significantly to fix the mode matching to the filter cavity, astigmatism will start to limit our matching to the OMC.  

Sensitivity of the FC path

This raises an interesting question:  Why have ZM2 be a PSAM in the first place?  In principle, we are just mode matching between two static cavity modes.  We should be able to do this with a ZM2 optic with a fixed RoC.  In practice, the need for tunability is dictated by how sensitive the mode matching solution is and how well we know the various parameters. 

In order to mode match between the OPO (waist size < 100 um) to the filter cavity (waist size ~ 1cm) over a path of < 5 m in length, we require the beam to be diverging rapidly past ZM2.  See the attached Wield plots for the telescope:  Tangential and Saggital

This results in the mode matching solution being quite sensitive to the following parameters:  The ZM2 ROC,  the ZM2 - to - FC1 distance, and the RoC of the FC1 AR surface.

I made wS plots using Finesse which show how the mode at the HR surface of FC1 depends on the following parameters.  I made some assumptions about what the nominal values are for the FC AR and ZM2 RoCs which I'm sure aren't 100% accurate.  I think that's fine for now: we just want to see how offsets in the parameter values impact the mode matching to help us gain intuition:

• ZM2 RoC
• FC1 AR RoC
• ZM2 to FC1 distance.  In practice this can be varied by sliding ZM3 around to shorten/lengthen the total path

These plots show the 2D overlap for both the horizontal (plotted with X markers) and vertical (plotted with * markers) q parameters (this analysis includes only the astigmatism from the OPO and ZM2 AOI).  We see that all three DoFs are fairly degenerate, primarily impacting the beam defocus at FC1.  

The original design for the optical path was to use a variable ZM2 to compensate for the manufacturing tolerences of the ZM2 and FC1 RoC's.  

However, these plots suggest that one could also compensate for this by moving the position of ZM3 instead of changing the ZM2 RoC.  It looks like LLO has actually played around with this degeneracy in the past (59774).  One can also translate L2 to fix these issues, but this can only compensate for small mismatches.

Upshot

In summary, I hope we find that the current PSAM setting for ZM2 gives us good SQZ-FC mode matching and we don't have any urgent reason to make significant changes to the FC path to address astigmatism issues.  If this does end up being an issue, or if we decide to revisit this for A#, it looks like there might be a way to make the FC path work without a PSAM, though it would take a fair amount of effort to implement.  

Camilla, Ryan S, Rachel.

We went into HAM7 with the aim of check the power budget through the OPOS with ZM1,2,3 in the settings for a lower beam on ZM2 and also setting irises after ZM5 in preparation for the repeat ZM5 swap. However the beam alignment was bad so we didn't compete any of these tasks.

Red and green co-alignment still good, OPO REFL and green pump REFL still in nominal location so OPOS hadn't moved. However the beam was low and to +X on the ZM2 iris and the retroreflective off FC1 was ~4mm off at the ZM1 iris, no light was getting though the OPOS. This was true in both the old and new ZM2 beam height (ZM1,2,3) alignments. From the control room Ryan found that on Monday ZM2 moved a large amount. He undid this. Then Rachel and I worked to improve the retro-alignment with ZM2. We then got beam through OPOs to ZM4 but still no light on the IR PD. This was confusing so we stopped. Today we found out this was because Rahul had locked ZM5 while troubleshooting it. Once he unlocked ZM5 we had some light on SQZT7 PD. 

I think ZM2 must have been bumped when I was measuring the distances between ZM2 and the nanoscan. See bump in ndscope.  There is cable in the front of ZM2 that if I moved could change the hanging of ZM2.

Rahul confirmed that ZM2 is heathy 91186, just it appears that now the alignment sliders need to be in a different location for the same pointing. 

Oli, Rahul

Camilla had accidently bumped the PSAMS cable on ZM2 in HAM7, hence we we took a quick health check measurements on it and we can confirm that the suspension is absolutely healthy. 

On Monday I had locked the bottom stage of ZM5 (PSAMS) after discovering a broken PZT and then set it to SAFE.

Today, I set it free (all stages suspended and alignment slider ON) to enable Camilla et al confirm beam alignment on the table and then perform beam profile measurements. 

Camilla is also planning to place two iris in front of ZM5.

Next week we are planning to replace the broken PZT (or the entire PSAMS) on ZM5 (PSAMS).

Corey* the Fellow Ryan C and I went to the EndX station today and did a standard End Station measurement following T1500062-v21 this Tuesday.
The only thing that seems to be kind of peciluar is that the PCAL Laser Power supply had a strange Limit light that was lit up during the entire duration of the ES measurement.
After the measurement I keyed OFF the Laser enable and keyed it back on. The limit LED was then gone. Myabe this is from the power outage back on July 15th.

Also I had to change a line in generate_measurement_data.py to get it to run. specifically line 192: conn = nds2.connection(server,  31200)   #  8088) 
to:  conn = nds2.connection(server,8088)   # 31200)
This was because "Yesterday the trend files weren't mounted on the  NDS server"
I have since reverted the change and pushed the correct lines back up the the PCAL repo on the master branch so it should still work for LLO.

Obligitory before Beam Spot pic: Beams look centered. 

Scripts ran @cdsws32:
python generate_measurement_data.py --WS PS4 --date 2026-07-16
Reading in config file from python file in scripts
../../../Common/O4PSparams.yaml
PS4 rho, kappa, u_rel on 2026-07-16 corrected to ES temperature 299.3 K :
-4.699027391114544 -0.0002694340454223 0.000750622815531554
Copying the scripts into tD directory...
Connected to h1daqnds1
martel run
reading data at start_time:  1468690400
reading data at start_time:  1468690930
reading data at start_time:  1468691270
reading data at start_time:  1468691940
reading data at start_time:  1468692480
reading data at start_time:  1468692870
reading data at start_time:  1468693288
reading data at start_time:  1468694160
reading data at start_time:  1468694666
Ratios: -0.46162600451541763 -0.4661255070734819
writing nds2 data to files
finishing writing
Background Values:
bg1 =        9.407246; Background of TX when WS is at TX
bg2 =        4.744478; Background of WS when WS is at TX
bg3 =        9.437291; Background of TX when WS is at RX
bg4 =        4.772117; Background of WS when WS is at RX
bg5 =        9.378150; Background of TX
bg6 =        0.491299; Background of RX

The uncertainty reported below are Relative Standard Deviation in percent 

Intermediate Ratios
RatioWS_TX_it      = -0.461626;
RatioWS_TX_ot      = -0.466126;
RatioWS_TX_ir      = -0.456059;
RatioWS_TX_or      = -0.460920;
RatioWS_TX_it_unc  = 0.071844;
RatioWS_TX_ot_unc  = 0.070784;
RatioWS_TX_ir_unc  = 0.080713;
RatioWS_TX_or_unc  = 0.076349;
Optical Efficiency
OE_Inner_beam                      = 0.987790;
OE_Outer_beam                      = 0.988918;
Weighted_Optical_Efficiency        = 0.988354;

OE_Inner_beam_unc                  = 0.053989;
OE_Outer_beam_unc                  = 0.054059;
Weighted_Optical_Efficiency_unc    = 0.076402;

Martel Voltage fit:
Gradient      = 1636.768024;
Intercept     = 0.518413;

 Power Imbalance = 0.990347;

Endstation Power sensors to WS ratios::
Ratio_WS_TX                        = -1.077875;
Ratio_WS_RX                        = -1.390900;

Ratio_WS_TX_unc                    = 0.043402;
Ratio_WS_RX_unc                    = 0.050017;

=============================================================
============= Values for Force Coefficients =================
=============================================================

Key Pcal Values :
GS           =      -5.135100; Gold Standard Value in (V/W)             
WS           =      -4.699027; Working Standard Value             

costheta     =      0.988362; Angle of incidence
c            =      299792458.000000; Speed of Light
             
End Station Values : 
TXWS         =        -1.077875; Tx to WS Rel responsivity (V/V)
sigma_TXWS   =        0.000468; Uncertainity of Tx to WS Rel responsivity (V/V)
RXWS         =        -1.390900; Rx to WS Rel responsivity (V/V)
sigma_RXWS   =        0.000696; Uncertainity of Rx to WS Rel responsivity (V/V)

e            =        0.988354; Optical Efficiency
sigma_e      =        0.000755; Uncertainity in Optical Efficiency

Martel Voltage fit : 
Martel_gradient         =        1636.768024; Martel to output channel (C/V)
Martel_intercept   =        0.518413; Intercept of fit of     Martel to output (C/V)

Power Loss Apportion : 
beta          =        0.998895; Ratio between input and output (Beta)  
E_T          =        0.993611; TX Optical efficiency 
sigma_E_T          =        0.000380; Uncertainity in TX Optical efficiency 
E_R          =        0.994710; RX Optical Efficiency 
sigma_E_R          =        0.000380; Uncertainity in RX Optical efficiency 

Force Coefficients : 
FC_TxPD          =        7.902743e-13; TxPD Force Coefficient 
FC_RxPD          =        6.196373e-13; RxPD Force Coefficient 
sigma_FC_TxPD          =        3.801143e-24; TxPD Force Coefficient 
sigma_FC_RxPD          =        3.152590e-24; RxPD Force Coefficient 
data written to ../../measurements/LHO_EndX/tD20260721/

Obligitory After Beam Spot: Beam spots still look centered

Final Trends pdf: LHO_EndX_PD_ReportV6.pdf

TITLE: 07/22 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
OUTGOING OPERATOR: None
CURRENT ENVIRONMENT:
    SEI_ENV state: MAINTENANCE
    Wind: 6mph Gusts, 3mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.10 μm/s 
QUICK SUMMARY: More work today towards locking DRMI planned. The IMC was left offline overnight, but the JAC looks like it's been locked for roughly the past 13 hours. The LVEA remains Laser HAZARD and the corner/HAM1 continues pumpdown.

• Wind and other ground motion low
• Dust alarm on LVEA6 (seen several times yesterday)
• CDS overview green except for an open test point on PRM, soon to be cleared
• All other systems nominal

WP13433

I started the offload of raw minute trend files from TW1 to SATABOY archive 17:38 Tue. At this point it is 52% complete, ETA 19:30 tonight.

(Jordan V., Gerardo M.)

We moved the SS-500 up to HAM6 connected it to the turbo pump on HAM6 chamber and started it, once it got up to speed we valved in at 23:18 utc.  See attached plot for effect.

TITLE: 07/22 Eve Shift: 2330-0500 UTC (1630-2200 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Not much else happened today after the end of Ryan S's shift. Sheila and Keita went out to ISCT1 to align the POP path but were not able to make much progress, so commissioning stopped for the day.

JAC is being left LOCKED but IMC was taken OFFLINE so Jim can take some measurements.

LVEA is LASER HAZARD

LOG:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Dan Moraru, Jonathan Hanks,

Per WP 13432 Dan and I put a new link between LDAS and CDS in.  This is to support stream data via the ngdd tooling for IR1 and later.  What we ended up doing was to create a gateway box running vyos (a router OS) and using that as the gateway to the internal LDAS network that the NGDD servers live on.  I updated DNS so the servers resolve properly in the control room and have shown that I can pull data from NGDD.  The gateway box is runnong on the VM cluster, so it gains high availability and can be easily scaled up if we need to expand its capacity.

Jennie W, Sheila D, TJ S,

Summary: JAC HEATER guardian can cool/heat the JAC body but is not optimised yet.

Today TJ and I tested the guardian I wrote yesterday. We still haven't optimised the gain and setpoint to choose. Included is trends from today showing that we could cool down the JAC but we eventually run out of range on the heater (and on the PZT fast feedback) so I think we want to choose a set point where the heat load is around a couple of W constantly.

In addition, because we were increasing the temperature of the remaining water moelcules in HAM1 (which is still pumping water out of the vacuum volume) we cause the pressure to slowly rise in the chamber if we have too much heat on the JAC. This should not be a problem once we reach hard vacuum.

TJ and I are going to rewrite the cdsutils.servo function so we have more tuning over the feedback settings. The current function will send the guardian node into error when the heater power reaches 0 as it keeps trying to step the channel to negtaive values. We also have to turn the servo off and on again in order to change the gain and set point.

Elenna, Keita, Ryan Short, Oli

We were able to lock the Michelson.  We started with a beam reflected off ITMY on the AS camera, aligned SR2 to center that on AS_C.  Then we rastered ITMX at 0.06Hz and 0.07 Hz in pitch and yaw, until we saw the beam flash by on the AS camera.  Screenshot of the sliders that gave us an aligned michelson attached. 

We ran prep_for_locking, which changed the BS BIO state, but we have changed the guardian weights to not do SDF revert for now.  

We had to reduced the gain used for the michelson, it would normally acquire with a gain of 4000 and set it up to 8000 when locked.  To match the michelson UGF in our template, we had to reduce the gain to 1200, so there is a factor of 6.7 more gain somewhere.  The MICH IN1 error signal amplitude is 6 counts now, Elenna found a time in O4 when we were doing inital alignment and the amplitude was 8 counts, so the optical gain is similar.  

With the dark michelson locked, Elenna manually aliged the beam splitter, sliders attached after fine adjustment.  

WP13433 TW1 offload

The first part of the offload was done. The past 6 months of data was moved to a static directory and NDS1 was temporarily reconfigured to serve this data as a separate source. This went into effect when NDS1 was restarted as part of today's DAQ restart.

WP13442 ISI HAM2,3 model changes

Jim made wiring fixes to h1isiham[2,3]. These models were installed. No DAQ restart was needed.

WP13443 Add CRS Fast Channel

A new h1crsproc model was installed to add a SUM DQ channel at 512Hz. DAQ restart was required.

WP13436 Pre-upgrade of SUSAUX and PEMMID

All the sus-aux and pem-mid front ends were upgraded to the new RCG (5.6.5) and booting Deb13 from the new bootserver (h1boot5-6). This added slow channels to all models, ADC/DAC overflow counters to all, ADC-temp to iocs. For all but h1susauxb13 the upgrade had no problems. With h1susauxb13 the EDC had issues. Following the first upgrade both DAQ legs saw continuous CRC errors from the new EDC. The error rates were usually in the 2-6 per second (out of 16 transmits per second). Initially thought of as a timing problem, we attempted to switch the EDC timing source from the IOP model to direct read of the timing card. This produed times which looked more like unix time than GPS.

After trying some things we decided to revert h1susauxb13 to deb11/rcg5.52. We then restarted the DAQ 0-leg for the susaux and pemmid model changes and h1crsproc.

We were then in a holding pattern for the 1-leg DAQ restart. While waiting, Erik found that the EDC has a large send delay in its cps-transmit. It was 34mS here compared with 5mS at LLO.

So for a test we upgraded h1susauxb13 back to deb13/rcg-5.6.5, with cps-xmit delay reduced from 34mS to 5mS. This did not fix the CRC and the error rate was unchanged.

Next Erik changed the  EDC's send latency from +10mS to -10mS. This fixed the issue, even though code comments suggested otherwise.

Finally the cps-transmit was returned to 34mS, keeping the EDC at -10mS and the problem did not return. We decided to keep with this configuration.

DAQ Restarts.

As mentioned above, we had several DAQ restarts.

The first at 11:08 was 0-leg only, the EDC has been returned to 5.5.2

The second at 13:40 was 0-leg again (EDC once again upgraded) and 1-leg

EDC was not restarted for a new INI file, just for the OS/RGC change.

Sheila set up a single bounce beam off ITMY, and ran the AS centering loops. We could see beam on AS_C. I ran a quick test by moving the BBSS in pitch and yaw using the sliders. AS_C shows clearly for 6 urad of pitch motion, the only movement on the diode is pitch. 3 urad of yaw motion also only moves in yaw. The oplev shows pitch and yaw movement during both times, which indicates the oplev is a fairly cross coupled sensor.

Based on this test, I don't think we need to do any other work to un-couple the BBSS pit and yaw dofs.

J. Kissel,

Executive Summary
We're continuing to debug issues seen with the IMC locking. One question that came up was whether we *can* confirm that all binary IO switching of the H1SUSMC2 M3 stage coil driver -- an *unmodified* Triple Acquisition Driver (see D0901047-v4) -- using the transfer functions between DAC output and the FASTIMON coil driver monitor circuits. And the real question they *want* answered is "is the BIO on the H1SUSMC2 M3 stage functioning normally, or is that broken and that's what's causing the issues with the IMC?"

The short answer: NO, one cannot confirm the ACQUIRE switching with confidence with any of these coil driver monitor circuits. The TACQ driver is one of those drivers where the monitor pick-offs span a complex switchable output impedance network rather than a simple resistor. As such, neither VMON or the FASTIMON can measure the response of that switchable output impedance network, since you're monitoring the voltage across it. Elenna's TF posted to LHO:91155, which has the TACQ driver frequency response correctly compensated, also shows that at least the analog state matches the digital compensation state.

BUT -- I'm 95% confident that both LP and ACQ filters the H1SUSMC2 BIO switching are working normally, and switching the analog coil driver state. This is based on some weak coil driver monitor transfer function evidence, looking at the BIO monitor readbacks for the M3 Stage, and two decades of experience looking at the function of these things.

DETAILS 

Attached is the simplest cleanest demonstration of the *lack* of visibility of the Acquire Filter: 
    - Excite the transfer function from the DRIVEALIGN L2L filter bank, so you can send excitation to all four coils at once. Make sure there's no filters on, and the gain is set to 1.0.
    - Change the M3 EUL2OSEM matrix to have the L to UL, LL, UR, LR coefficients from 0.25 to 1.0.
    - Use the 'secret' state feature of the binary IO control, to switch the coil driver state to negative; i.e. State 1 = -1, State 2 = -2, State 3 = -3, and State 4 = -4.
    - This allows you to Turn OFF all coil driver frequency response compensation filters. Do so, turn them off, so that you're actually exposing the what frequency response of the coil driver you can measure.  
Templates of the excitations can be found in 
    /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/MC2/SAGM3/Data/
        2026-07-21_H1SUSMC2_M3_L_to_FASTIMON_NoCompensation_tfs.xml
        2026-07-21_H1SUSMC2_M3_L_to_VOLTMON_NoCompensation_tfs.xml

One can see in this "clean" version of the fast-imon TF 1st attachment. One only really sees the response change when the low-pass filter is turned ON vs. OFF. One might argue that there *is* a little change between STATE 1 and STATE2 (turning the Acquire filter ON, bypassing R14), but this is dirt coupling; we expect the zero:pole response to change from (9:82) Hz pair to a (1:46) Hz pair.

My justification that "it's a real change, even though it's dirty," and that the FASTIMON does show that the switch is working -- if I take the same transfer function to the voltmon circuit, 2nd Attachment (which measures the voltage across a single resistor, but *upstream* of the acquire network), one sees no change at all between STATE1 and STATE2. Said differently -- because we *do* see a change in the FASTIMON TF between STATE 1 and STATE 2, albeit not the real TF change which we know we shouldn't be able to see, but still -- a change -- is weak proof that the acquire filter is changing, and the BIO is functional.

Remember:
 - From LLO:4495, for an unmodified TACQ Driver, we expect the poles and zeros to be changing as follows:
        State         Switch State                       Freq. Resp            DC Transconductance
                       ACQ  |  LP                          (z):(p) [Hz]             [mA/V]
        STATE 1        OFF  |  OFF                         (9):(82)                   0.33 
        STATE 2        ON   |  OFF                      (1.05):(46)                    |
        STATE 3        OFF  |  ON                    (9 11 21):(1 82 210)              |
        STATE 4        ON   |  ON                 (1.05 11 21):(1 46 210)              V

 - For bode plots of the frequency response of all these TACQ driver states, and the difference between a *unmodified* vs. *modified* TACQ driver see L1200226.

 - For an info-graphical representation of the state of the digital compensation w.r.t. the analog filter state, see StateMachineDiagrams_TripAcqDriver-v7.pdf from T1100507.

 - In general, none of the SUS coil driver circuit drawings, nor the SUS coil driver monitor circuit drawings show the complete monitor circuit, so it's difficult at best to parse the total circuit system to understand the calibration. Instead, go to CoilDriverMonitorMath_CurrentMonitor.pdf posted as an other file to D070480-v2 for a complete picture of the monitor system, from which you can derive the math. I summarize it here:
   From the second page of that math, you can see that the transfer function between the Fast IMON circuit output voltage, V_IMON can be calibrated into current across the coil, I_coil by the following transfer function:
       V_IMON                 R25         2
      -------- =  2 * Z_out * ---      = --- * Z_out
       I_coil                 R24         3
where, 
     . as part of the design principle, R25 = R35, and R24 = R27 = R29 = R33, and for the D070480-v2 circuit, R25 = 10e3 [Ohm] and R24 = 30e3 [Ohm], hence, R1/R2 = 1/3, and 
     . Z_out, in the case of the TACQ driver is the entire complex switchable impedance network.

 - The list of HSTS with modified vs. unmodified TACQ drivers on their lower stages: LHO:32021

 - There *are* modified "narrow-band" coil driver monitor circuits out there, but they're only in PRM M2 and M3, and PR3 M3; LHO:72837

As a part of trying to diagnose the mode cleaner locking issues, I ran a transfer function of MC2 M3 to M3 to see if everything looked normal. Unfortunately, there is nothing in the sus svn to provide a reference, so we don't know what it is supposed to look like.

I immediately noticed strange behavior above 10 Hz that is related to the BIO state. I thought I was on to something, however, I found out that this is a long known problem that comes from coil driver coupling to the osem. Nonetheless, here is a measurement, in case anything else jumps out as strange to anyone.

I took two transfer functions in BIO state 4 - Acq On LP On, and one in BIO state 3 (nominal)- Acq Off LP On.

Jennie W, Sheila D, Ryan S,

This morning Ryan and co were trying to lock at 200mW to allow the porcupine beam dump for the PRM misalignment beam to be checked at low powers. They were having trouble locking JAC at power below 2W. I improved the alignment of the PZT mirror (H1:JAC-PZT_PIT_OFFSET and H1:JAC-PZT_YAW_OFFSET are the channels) an the JM1 suspension while we were locked at 2W so I could look at the transmitted power.

We seem to be falling out in the 'SCANNING' state during locking at 200mW and if we lock at 2W and try and turn down the power it also falls out.

Sheila checked the JAC guardian and found out that the 'JAC_locked' checker function has a threshold of 0.5 which must be passed before we stop scanning the PZT and jump to the LOCKING state.

It uses the Beckhoff channel H1:JAC-TRANS_A_DC_NORMALIZED which gets normalised by H1:JAC-TRANS_A_DC_NOMINAL to do this check. 

H1:JAC-TRANS_A_DC_NOMINAL is a scalar mA value that does not change with input power (Daniel rescaled this value on Monday manually to make the H1:JAC-TRANS_A_DC_NORMALIZED = 1 when the input power is 2W).

This was not happening so the check failed and the guardian jumped to DOWN.

Therefore Sheila has divided the H1:JAC-TRANS_A_DC_NORMALIZED by input power and set the threhold to 0.2, so this check should always come out about 0.5 for a well-aligned JAC and will therefore pass the 0.2 threshold.

I have committed the JAC guardian to the svn at userapps/isc/h1/guardian

Included pic of alignment changes for PZT mirror and JM1 plus input power monitor (H1-IMC_PWRIN_OUT16) and JAC lock check channel (H1:JAC-TRANS_A_DC_NORMALIZED).

Below is the analysis for data taken on the FC path: between ZM1 and ZM2 and between ZM2 and ZM3, with Nanoscan, see Camilla's log 90573. As a reminder, ZM1 are flat optics, ZM2 is a PSAM with variable curvature, FC1 HR side is flat, AR side is curved with RoC ~1m. 

The data suggest that the OPO mode is slightly different from O4 OPO, and also strongly suggest a new optimal ZM2 PSAM voltage can be found within the range. 

We measured the beam profile at 5 different points after ZM1 with A:L2 lens at its nominal 0 position (sled that the lens lives on is flush to its translation stage on both front and back edges). At the last point with A:L2 at 0, we realized it would be pertinent to measure beam profiles for the two extremities of the A:L2 translation stage: -13 mm, which is closer to ZM1 by 13 mm and +17 mm, which is 17 mm further from ZM1. We then proceeded to take 5 measurements (again downstream from ZM1) for each of these lens positions. The nanoscan screenshots for each measurement are attached in the .zip folder. 

The attached gif shows the beam waist position estimation extracted from the beam profile scans downstream ZM1, for all three A:L2 positions. The "target" and "O4 x/y" come from Keita's log 59515. The overlap plot attached shows the field overlap in percentage for all three A:L2 positions, with target and O4 beam parameters. With A:L2@0, the overlaps are above 99%, which bodes well for the FC mode matching prospects. There could potentially be a better mode matching solution to the "target" or "O4" for A:L2 between 0 pos and -13mm pos. However, the following measurements betwen ZM2 and ZM3 suggest fine-tuning of A:L2 position will not be necessary. 

We also measured beam profile between ZM2 and ZM3 for three different points, setting ZM2 PSAM voltage to 4 different values at each point. The "nominal" O4 strain gauge (S.G.) for ZM2 has been 3.15 V, which corresponds to ~ 60 or 90 V pzt supply voltage depending on which direction one scans from. The edges of the psam range are 0 V and 196 V, which corresponds to ~1.2-1.3 V and ~6.04 V S.G. respectively. In the interest of more uniform sampling of the available psam curvatures, we also chose to sample 4.5 V S.G. (~120 V or 150 V). 

This table shows experimental data mapped to radii of curvature of the ZM2 mirror, using Camille's E2100298. The exact PZT strain gauge/ PZT supply voltage that gives a certain RoC is affected by the hysteresis curve i.e. sweep direction.

Attached gif for propagation between FC1 and ZM2 show esimated beam parameters for all four SG cases: 1.3, 3.1x, 4.4x and 6.0x V. The exact values for the strain gauge varied from one beam profile position to the next, however it should be good enough to tell if we have enough range on ZM2 or not.

The gif switches between different SG values once every 2 second, the lefthand plot is useful in looking at the beam divergence near FC1 while the righthand plot is a zoom-in around the beam waist. Looking at the estimated beam waist position for 1.3 V and 3.1x V cases switching across the "FC x/y waist", "VOPO target waist", ''O4 x/y waist", we can guess there could be a better mode matching solution between these two SG values. "FC x/y waist" comes from the Finesse eigenmode solution for the FC path (thanks Kevin Kuns!), target and O4 values are the same from the above-mentioned Keita log, assuming ZM2 curvature to be 0.85025 m (3.15V SG), and the following distances between the optics: A:M3 --> ZM1: 158.2 mm, ZM1--> ZM2: 1498.625 mm, ZM2 --> ZM3: 1821.497 mm, ZM3--> FC1: 1000.261 mm. Camilla extracted these distance values from D1900365-v1.

Knowing the applied PZT voltage and the corresponding RoC, we can use the measurements at 3.1x V and 1.3 V to estimate the mode matching we would obtain if we swept the RoC between that of these strain gauge values. The attached FC mode matching projection plot is computed by taking beam parameter estimated from the beam size measurements for 3.1x V, propagates the beam back to ZM2, unapplies the estimated RoC (decreasing RoC value was used informed by data, indicated in bold in the above table), then reapplies the RoC between these two values, after the overlap with the FC eigenmode is calculated. This projection suggests that mode-matching points with >99% overlap for both x and y axes are accessible. Clearly, there is varying astigmatism with strain gauge setting, see beam profile plots where 3.1x and 6.0x V shows beams with smaller astig. than the other two points. Since the PSAM characterization data gives only a single RoC number rather than separate x/y effective curvatures, the projection should be interpreted as approximate. In practice, the final optimization should be done empirically.

The effect of the astigmatism is also apparent in this defocus vs beam size at FC1 plot that shows mode matching contours. The calculation is made at the FC1.p2.o plane in Finesse.