J. Kissel This morning, I re-installed the H1SPIH23 pathfinder's photodiode and picomotor cable-table-brackets (CTBs) that had been temporarily moved to upgrade the Corner 1 H1 capacitive position sensor (see LHO:90791), and re-dressed the cabling cable clamps. As mentioned in passing in LHO:90750 the CRS team will now consume the "spare" SPI_HAM3_004 quadrupus leg, that's J2 of the S2500513 instantiation of D2400342, which manifests as CH8 on the TCSY_C02, Controller 10, PICO G picomotor controller driven by the Corner 2 ECAT chassis -- which shows up on the H1SYSCSAUX computer's SDF system. So this has been routed in the +X direction and up in +Z to the table top on the +Y corner. I'll post pictures of all the re-dressing in the comments so I can better caption them.
J. Kissel / J. Warner / A. Pele (Belated aLOG) ECR: E2100347 and E1800270 Wrapping up the in-mode-cleaner-tube work underneath the -X side of HAM3, Jim, Arnaud, and I started the work to upgrade all the HAM3 ISI capacitive position sensors (CPS) to triaxial BNC "triax" cabling for connecting the target to a known ground (per ECR:E1800270), and convering verticals sensors to "fine" resolution sensors (per ECR:E2100347). I worked on the install of V2, and Jim got through H1, V1, and H2 before we had to quit for the day. After Arnaud fixed some teething issues with the CPS readout that were causing a LOT of excess noise (LHO:90763), we were able to position the H1, V1, and V2 target in the middle of the range of the sensor probe head (i.e, near zero [ct] in the range of the +/- 32k [ct] ADC). See 2026-06-26_H1ISIHAM3_CPSCenteringWork_Timeline.png for a trend of the three sensors that we've centered. The y-axis are in ADC counts because I wasn't sure if the "Crs_Cal_V2" calibration, FM1 zpk([1.5916],[0.1447], 30.5176) was a good calibration. If so, the readout of the position is ADC [ct] Apparent Position [um = 1e-6*m] H1 6.9 0.23 V1 198.8 6.07 V2 395.9 12.10 see 2026-06-29_H1ISIHAM3_CPSCentering_CalibratedValues.png. Three things of note: (1) In order to gain access to the H2 sensor probe for the upgrade, Jim had to remove all the SPI ISIK transceiver cabling that had been bolted on the Horizontal Corner 1 hatch on 2026-06-10 (LHO:90581). While he centered the target in the middle of the ADC range and re-bolted the hatch back on, he didn't have time to restore the SPI cabling. We'll do re-dress later. (2) This is probably already known by the SEI team proper, but the in-chamber work securing things to the platform in various places -- even with the lockers engaged -- does change the position of the platform slightly. See the main timeline for time periods of chamber work vs. (apparent?) change in position. (3) When plugging in the H1 CPS triax, Jim found that the cable wouldn't seat well at the D1-1A1 feedthru. Upon inspection, the teflon insulator between conductors was quite mangled -- see 2026-06-26_ISIHAM3_CPSCenteringWork_H1_BEFORE_BADBADBAD.jpg. He then used a pair of needle-nosed pliers to straighten out the teflon, and got it good enough that it engaged with the feedthru -- see 2026-06-26_ISIHAM3_CPSCenteringWork_H1_AFTER_GOODENOUGH.jpg. We took a look at the adjacent V1 connector head and it seemed fine, and felt fine going into the socket -- see 2026-06-26_ISIHAM3_CPSCenteringWork_V1_ALREADYGOOD.jpg.
TITLE: 06/29 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: 15mph Gusts, 12mph 3min avg
Primary useism: 0.01 μm/s
Secondary useism: 0.10 μm/s
QUICK SUMMARY:
Mon/Early week activities: GV6(Y-BM) work this morning, BBSS activities with FARO continued, BSC3 rebalance for baffles, HAM3 CPS upgrades, Install CRS, HAM3 baffling, HAM3 ground loop checks.
Rain system just passed through the site on this cloudy morning. M5.5 earthquake off the southern coast Oregon coast (no WD trips). Kim is already in the lvea and also covering other buildings more than usual.
Mitchell, Disha, Robert
On Friday we finished alignment of the baffles on the +X side of HAM3. This took extra time because we didn’t expect 12 point flange bolts on the PR2 dog clamps that we were moving. Beam spot photos from the BBS showed that we had mitigated retroreflections from the dog clamps and other retro-reflectors that we were worried about, but the brackets for two of the SPI baffles formed strong 2-D corner reflectors with the table top (see figure). We need to hide them with something that is the same height but not normal to the BBS-PR3 beam, and we need to finish aligning the baffles on the –X side. We may also need to treat two of the table baffle brackets on the +X side of HAM3 if they produce retroreflections in PR3 beam spot photos.
Here's some pictures to aide the conversation about "which brackets are SPI bracket retro-reflectors?" These were taken on 2026-06-18 when TJ and I were installing these baffles for the first time (see LHO:90676). Two versions of each photo, one annotated and one not. 2026-06-18_H1SPIH23_ISIK_Baffles_BigPicture_ANNOTATED.jpg shows "looking in the +X direction" big-picture view of the beam splitter from inside the HAM23 mode cleaner tube, and highlights in red which baffles' brackets are the problem. 2026-06-18_H1SPIH23_MinusYSide_Baffles_TopDown_IsometricView_ANNOTATED.png shows a top-down / isometric, "looking in the +X / +Y / -Z direction" view of the -X / -Y corner of the optical table, again calling out the problematic baffle brackets. Saying it out loud -- it's not one baffle's brackets, its both - the -Y bracket of the middle upper panel baffle, and - the +Y bracket of the -Y upper panel baffle. of the ISIK shroud assembly D2400106 Also -- just saying it out loud. Robert shows how shiny these brackets are in the -X view of HAM3 from the beam splitter. "Why aren't these an issue for the -Y view of HAM4 from the beam splitter?" Because HAM4 doesn't have any of these HAM table baffles on its -Y side -- the HAM3 baffles exist because we had to remove the lower panel of the HAM2-HAM3 *mode cleaner tube* baffle on the HAM3 end of the tube (LHO:90138 and LHO:90162) in order to support SPI. But the equivalent panel on the HAM4 end of the HAM4-HAM4 tube baffle is still in place, so these HAM table baffles are not needed.
Eric, Ryan S, Camilla, Sheila
All week we have been working on getting a set of OMC scans and beam profile measurements for different psams. We have both sets of data now, with plots and scripts coming soon next week.
OMC scans
We started with a script that Begum gave us from HAM6 work at LLO. We set up ASC loops to go from ASA and AS B DC signals to ZM4 and ZM5 (as described in 90742). We struggled a while to lock the OMC on the seed beam in air, hampered by 90754. With that noisy OMC lock, yesterday Camilla manually aligned OM3 and the OMC suspension carefully to maximize the 00 transmission. We then added offsets to H1:OMC-ASC_QPD_{A,B}_{PIT,YAW}_OFFSET, which is not the usual location for OMC QPD offsets. We will need to get rid of these offsets before we go back to locking.
OMC A offset: PIT 0.088 YAW: 0.133 OMCB offset: PIT 0.27 YAW: -0.22
We found that we were able to move the psams, whih misaligns the OMC terribly, run the centering loops to the ZMs, then run the OMC QPD loops to bring the 1st order peaks back down to a couple % of the 00 peak repeatedly. We spent some time modifying and then debugging the script that Begum shared with us.
It takes in a list of ZM4 and ZM5 strain gauge values, moves the psams servos target to that point and waits 30 seconds with the ZM centering loops on (it doesn't check the acutal value of the strain gauge, perhaps this would be a good thing to add next time). It then turns on the OMC QPD loops for 20 seconds. It then takes a 100 second ramp of the OMC PZT, and saves the times and ZM strain gauge targets into a yaml file.
There is a template you can use to watch all this at userapps/sqz/h1/Templates/ndscope/OMC_psams_scans_monitor.yml The script that runs these sweeps is at sqzutils, or /ligo/gitcommon/squeezing/sqzutils/omc_scans_sweep_psams.py There is also a script there that loads the data, identifies the peaks and estimates mode mismatch and misalignment there, analyze_psam_omc_sweeps.py. A preliminary plot is attached (apologies for the color choices and linear y scale here).
M2 profile measurements
Eric and Ryan S took a series of M2 profiler measurements of the beam on SQZT 7 today, doing the alignment procedure at each strain gauage setting (they didn't adjust ZM alignments). Their data is in here, we will post some plots of this next week.
Note about ZM5 strain guage
While Eric and Ryan were making beam profile measurements, they ran into a situation where ZM5 would not go the strain guage setting of 2. I was able to get it to go to 2 manually, but noticed that there were times when the strain gauge voltage dropped to zero, similar to a problem seen at LLO HAM6 recently. We should follow up on this next week.
More on the ZM5 strain gauge issues -
While Eric and I were taking beam profiles and moving to the last step for the ZM5 PSAM (requesting 2V), the strain gauge readback voltage fell to -2.8V and got stuck, shown at the T-cursor in the first attached ndscope. Changing the requested voltage away from 2V did not affect the strain gauge's behavior or the voltage sent to the PZT, which looked to be railed close to 200V. Eventually Sheila was able to unstick the voltage and get the strain gauge back to 2V by stopping the servo and clearing its history.
This is reminiscent of behavior seen at LLO with one of their new HAM6 PSAMS, OMA2, where after scanning the PZT to the edge of its range, the strain gauge would show open loop for a few seconds, then return to normal (LLO:alog80740 and FRS 37456). We haven't run the repeated scans with ZM5 like LLO did with their OMA2, but we looked for other times recently when the ZM5 PSAM showed weird behavior and found a time earlier that day during one the the OMC scans; see the second ndscope. It's possible that when this happened to Eric and I on Friday, the strain gauge would have fixed itself after a few seconds like in LLO's case, but the integrators in the servo kept the voltage railed.
LLO's solution for this was to fully swap out the optic and its attached PZT/strain gauge assembly, so while we think about this, we are assessing what spares exist that could potentially be swapped in.
After getting IAS sign off from Keita, Betsy and Jason yesterday, Mitch and I went to BSC2 to start reattaching the actuators. We finished that this afternoon, according to dial indicators on the chamber we haven't moved from the locked position, but stops are still engaged. Actuators are valved in, and I have set the alignment targets for HEPI to the current value. IPS readouts should be meaningful again for trends, just remember that they have been disconnected basically since the cartridge was pulled from the chamber, so doing alignment comparisons between before that time and now are pretty pointless. On Monday, I plan to unlock, look at lock/unlock offsets, then use the loops to servo to this locked position. If locked to unlocked shift is large, it may mean we will want to do another round of spring adjustments, but I should be able to do those from above, using the IPSs.
TITLE: 06/26 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:
Main activities today were: SQZ measurements in lvea + control room, connecting actuators for BSC2 hepi, ham3 baffling...
LOG:
Jordan, Jake Z, Owen H
Per FRS Ticket 38164, two viewports were removed off of HAM2 and replaced with Class A 10" CF blanks.
On the East Door, port A2F2 was an uncoated ZV-800 (SN 66), and on the West door A1F1 was a ZV-800 Coated SN (R009). These two viewports will be inspected on the bench and put into spares inventory if all looks okay and passes inspection criteria.
These two blank flanges will be added to the list for leak checking during pumpdown.
After this week's HAM3 CPS work, had been hearing "HAM3 CPS Glitch" verbal alarms every few seconds, so volume reduced on Verbal. To allow us to hear Verbal, RyanS made an edit to the tests.py file to remove the alarm for HAM3's CPS Glitches (he commented this change in the file).
This specific alarm will need to be restored--after the CPS work is complete.
I updated the some of the medms for the blends for HAM2&HAM3 to include the SPI and CRS, added INERT_MID
Blend of four sensors: /opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_BLEND_SUPSENS_FOUR.adl
Made new block for a blend with four sensors: opt/rtcds/userapps/release/isi/common/medm/hamisi/new_FADER_4PART.adl
The blocks for 2 sensors and 3 sensors (new_FADER_PART.adl, new_FADER_3PART.adl) currently have T240 labeled instead of SPI, I didn't want to mess with those blocks, as they are used for other chambers and it's still labeled T240 in the model, but for the 4PART I did switch T240 to SPI
Made new blend fade medm screen for HAM2 & HAM3: opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_H23_BLEND.adl
Made overview screen for HAM2&HAM3:opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_H23_FADE_OVERVIEW.adl
The only thing changed was to switch which screen the ST1 BLEND FADE button takes you to the new medm.
I added and commited all these to the SVN and updated the sitemap to link the them for HAM2 and HAM3
Continued working on HAM2&3 medm screens
Updated the input filters in opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_H23_FADE_OVERVIEW to include input filters for the SPIINF, SPI_FF, and CRSINF, and link to the SPI and CRS overview screens. The buttons link to the userapps/release version of the overview screens.
I made a few new input filter screens:
/opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_CHAMBER_SPIINF_ALL.adl
/opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_CHAMBER_SPI_FF_ALL.adl
/opt/rtcds/userapps/release/isi/common/medm/hamisi/ISI_CUST_CHAMBER_CRSINF_ALL.adl
and set up the a link to an ndscope of the BLRMS channel (like the CPS), but that can be easily gotten rid of.
I've commited all of the to the svn
TITLE: 06/26 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: 17mph Gusts, 12mph 3min avg
Primary useism: 0.02 μm/s
Secondary useism: 0.08 μm/s
QUICK SUMMARY:
Arnaud, Marie, Jeff, Oli
Compared to the BSFM, the cross coupling in the BBSS from P to Y is mught higher (This plot shows ~ 2 orders of magnitude, but I don't want to confirm that yet since the data fudge for the BSFM might be incorrect).
I made a comparison of the last few BBSS P to Y measurements and compared them to an old BSFM P to Y measurement.
We found that the P to Y cross coupling looks a lot like just Y to Y (bright blue), so there is much more Y than there should be.
There is still some more work to be done to absolutely confirm this, but current in progress results can be found in /ligo/svncommon/SusSVN/sus/trunk/BBSS/Common/Results/comparetripleparams/2026-06-25_BBSSvsBSFM, r13050.
A minor grain of salt: though the "(BBSS Teststand BOSEMs * 0.35587 | P to Y)" BOSEM data set seems to report *equal* if not *worse* P to Y magnitude as Y to Y magnitude, the data quality is garbage -- likely incoherent at all-but-on-resonance frequencies.
Jeff, Arnaud, Betsy, Oli
Yesterday we checked the coil response for the BBSS QOSEMs. We did this at the BBSS M1 QOSEM satamp. Everything is looking good and as we expected.
We did this by putting the BBSS in SAFE, then unplugging the db15's that go to the coil drivers. In their place Jeff plugged in a fancy breakout board that separated out each of the 4 channel pins. The resistance of each of the reading device channels is listed below:
| Coil Voltage (Satamp to Coil Driver) | ||
| Resistance of reading device (no uncertainty to 0.1 Ohm) |
Used to measure
|
|
| Breakout (B/O) Channel 1 | 24.3 Ohm | CH1 (F1), CH5 (LF) |
| Breakout (B/O) Channel 2 | 20.9 Ohm | CH2 (F2), CH6 (RT) |
| Breakout (B/O) Channel 3 | 23.1 Ohm | CH3 (F3) |
| Breakout (B/O) Channel 4 | 23.4 Ohm | CH4 (SD) |
With this channel breakout board we then went channel by channel to measure voltage. We turned the master switch ON so counts can head out from the COILOUTF filter bank. For each channel, we noted the COILOUTF filter bank gain sign, and if there was any voltage read out when no offsets were put in. Then we put an OFFSET in the COILOUTF filter bank and noted the voltage that we were reading. We did this for multiple OFFSETs for each channel. After testing each channel, with an offset still on, we would check the other channels to see if anyone else was seeing anything more than their default reading with no offsets, which they never saw anything different from that. Here is that data:
| Cable | SUS_BS_85 | SUS_BS_87 | ||||||||||
| Channel | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 | ||||||
| OSEM | F1 | F2 | F3 | SD | LF | RT | ||||||
| COILOUTF gain | -1 | -1 | 1 | 1 | -1 | 1 | ||||||
| COILOUTF OFFSET | Voltage (V) (+/- 0.5 mV) |
COILOUTF OFFSET | Voltage (V) (+/- 0.5 mV) |
COILOUTF OFFSET | Voltage (V) (+/- 0.5 mV) |
COILOUTF OFFSET | Voltage (V) (+/- 0.5 mV) |
COILOUTF OFFSET | Voltage (V) (+/- 0.5 mV) |
COILOUTF OFFSET | Voltage (V) (+/- 0.5 mV) |
|
| 20,000 | -2.825 | 20,000 | -2.837V | 20,000 | 2.848 | 20,000 | 2.839 | 20,000 | -2.826 | 20,000 | 2.836 | |
| 10,000 | -1.413 | 10,000 | -1.419 | 10,000 | 1.424 | 10,000 | 1.419 | 10,000 | -1.413 | 10,000 | 1.418 | |
| 0 | 0 | 0 | -1.00E-03 | 0 | 0 | 0 | 0 | 0 | -1.00E-03 | 0 | 0 | |
| -10,000 | 1.412 | -10,000 | 1.416 | -10,000 | -1.424 | -10,000 | -1.42 | -10,000 | 1.412 | -10,000 | -1.418 | |
| -20,000 | 2.825 | -20,000 | 2.83 | -20,000 | -2.849 | -20,000 | -2.839 | -20,000 | 2.825 | -20,000 | -2.837 | |
| With OFFSET of -20,000 (in V): | With OFFSET of -20,000 (in V): | With OFFSET of -20,000 (in V): | With OFFSET of -20,000 (in V): | With OFFSET of -20,000 (in V): | With OFFSET of -20,000 (in V): | |||||||
| CH1 (B/O Ch1) | -- | CH1 (B/O Ch1) | 0 | CH1 (B/O Ch1) | 0 | CH1 (B/O Ch1) | 0 | CH5 (B/O Ch1) | -- | CH5 (B/O Ch1) | -1.00E-03 | |
| CH2 (B/O Ch2) | -1.00E-03 | CH2 (B/O Ch2) | -- | CH2 (B/O Ch2) | -1.00E-03 | CH2 (B/O Ch2) | -1.00E-03 | CH6 (B/O Ch2) | 0 | CH6 (B/O Ch2) | -- | |
| CH3 (B/O Ch3) | 0 | CH3 (B/O Ch3) | 0 | CH3 (B/O Ch3) | -- | CH3 (B/O Ch3) | 0 | |||||
| CH4 (B/O Ch4) | 0 | CH4 (B/O Ch4) | 0 | CH4 (B/O Ch4) | 0 | CH4 (B/O Ch4) | -- | |||||
You can see that the voltage signs are all consistant with the sign of the OFFSET * COILOUTF gain, and the values are all pretty consistant as well.
After we were done reading out the voltages for SUS_BS_85, we put offsets of -20,000 in F1, F2, and F3 and checked the voltages on all three channels. All three channels read the same voltage as they had when we had tested them individually at -20,000 counts. That table is below.
| OFFSET of -20,000 for F1, F2, F3 (in V) | |
| CH1 (F1) | 2.825 V |
| CH2 (F2) | 2.831 V |
| CH3 (F3) | -2.849 V |
Some pictures of the "DAC Voltage to Coils" setup that gathered the above data. 2026-06-24_QOSEM_CoilDriveDACVoltage_BigPicture.jpg Zoomed out photo of SUS_BS_85 cable disconnected from the Coil Driver 1-4 channel input to the QOSEM satamp chassis in SUS-R2, and connected to the dummy OSEM system (what Oli calls the "fancy breakout board"), with a DVM reading out the voltage across the resistors. In the pictured case, we're using the DVM (placed in the rack for convenience) reading out the voltage across the Channel 1 resistor of the dummy OSEM which is connects across the + and - legs of the Channel 1 output of the cable (i.e. F1). 2026-06-24_QOSEM_CoilDriveDACVoltage_Zoom_DummyCoilResistor.jpg Zoomed in photo of the clip leads hooked across the resistor. Since the sign of the voltage is critical, I made sure to find a dummy OSEM that had the + and - legs clearly called out, ensuring the positive, red, signal lead for the BNC connection was connected to the + leg of the drive signal, and black to the -, return, leg. 2026-06-24_QOSEM_CoilDriveDACVoltage_Zoom_DVM.jpg Zoom in photo of an example of the DVM read-out voltage during the given offset (in this case, it was the CH1, F1, 10,000 [ct] offset -- multipled by the -1 COILOUTF gain -- to read -1.413 [V]_DC). Note -- again because signs are under question in this investigation -- careful attention was paid to ensure the orientation of the BNC to banana adapter into the DVM; connecting in the standard "nub is negative" configuration i.e. the shield of the BNC cable, connected to the black clip lead on the other end, is connected to the black COM input of the DVM. 2026-06-24_QOSEM_CoilDriveDACVoltage_DisconnectedSatampCable.jpg Zoom in photo of where the SUS_BS_85 DAC drive cable connects into the QOSEM satamp.
Jeff, Betsy, Arnaud, Oli
Yesterday afternoon we went to the BBSS QOSEM satamp and checked the coil resistance. We did this by putting the BBSS in SAFE and then unplugging the Satamp to Duopus cables one by one. Each of these three cables have the pins for two QOSEMs, split as CH1 + CH2, CH3 + CH4, and CH5 + CH6. Each cable was unplugged and then the pins for each coil probed. Below are the results. These values are all pretty similar.
| Coil Resistance (Satamp to Duopus) | ||||||
| CH1-2 (SUS_BS_81) | CH3-4 (SUS_BS_82) | CH5-6 (SUS_BS_83) | ||||
| Channel | CH1 | CH2 | CH3 | CH4 | CH5 | CH6 |
| CH Coil Pins | 23 -> 10 | 18 -> 5 | 23 -> 10 | 18 -> 5 | 23 -> 10 | 18 -> 5 |
| OSEM Mapping | F1 | F2 | F3 | SD | LF | RT |
| Coil Resistance | 39.1 +/- 0.1 Ohm | 40.0 +/- 0.2 Ohm | 39.0 +/- 0.2 Ohm | 39.7 +/- 0.2 Ohm | 40.0 +/- 1.5 Ohm | 40.5 +/- 0.5 Ohm |
| Notes | Larger than normal variation | |||||
Picture of the setup: (in this instance) the QOSEM CH 3-4 (i.e. F3 and SD) SUS_BS_82 cable is disconnected at the QOSEM satamp in SUS-R2, and its "to chamber" end is connected to a standard D25 breakout board. Clip leads are connected across the pins as described above to gather the coil resistance. These results are as expected: the QOSEMs are up-cycle bodies and coils from BOSEMs, which are known to have resistance of ~40 [Ohm], in this case 40 +/- 2.5%. Note, this is markedly different than the 35 +/- 10% [Ohm] -- 31.5 to 38.5 [Ohm] -- assumed in LHO:90743. Maybe Tom is assuming that this is the coil resistance if measured directly at the coil flexi-circuit terminals, and the "extra" resistance is from the long cable run to the chamber which is what we typically measure. However, the 2.5% spread in coil resistance values between F1, F2, and F3, is NOT enough of an imbalance to explain the worrisome P to Y cross-coupling seen at DC (LHO:90728 and LHO:90739) and in the M1 to M1 transfer functions (LHO:90765).
Indeed, the ~35ohm nominal coil resistance I quoted in LHO:90743 is measured at the QOSEM uDB9, so not including cable or feedthrough resistance.
After assembly I measured the coil reistance of these LHO BBSS QOSEMs to be:
| QOSEM SN | LHO BBSS Channel | Coil Resistance at uDB9 |
| S2600012 | F1 / CH1 |
34.6 |
| S2600009 | F2 / CH2 |
35.6 |
| S2600013 | F3 / CH3 |
35.1 |
| S2600008 | LF / CH5 |
35.7 |
| S2600011 | RT / CH6 |
36.4 |
| S2600010 | SD / CH4 |
35.6 |
J. Kissel, for J. Freed At the last minute on 2026-06-18, Josh figured out that we had errantly been sending the SPI's double mixer two copies of a COS wave of 4096 Hz rather than a SIN and COS (LHO:90680). This was because someone had errantly put a 90 [deg] rotation in the SIN analog output path. He fixed it before he left, but didn't save it in the SDF system and it got lost during Monday's bootfest of h1seih23 (LHO:90689). I'm not sure if Josh (or anyone) tuned it to any specific value, but I've changed the SIN analog rotation phase to 0.0 and accepted it in SDF so we don't lose it. Josh may add some more details in the comments below, in the comments to his LHO:90680.
During investigation I found that that SUS-R2 rack was energiezed by about 1mV. This was found to be caused by SPI RF Splitter being attached to the rack directly. I ran out of time to correct this before my visitation ended
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.
| Strain Gauge (V) | PZT Supply Voltage (V) | RoC (m) with increasing scan | RoC (m) with decreasing scan |
| 1.3 V | 0 | 0.8211 | 0.82202 |
| 6.0x V | 196 | 0.8911 | 0.89114 |
| 3.1x V | 60 (d) or 90 (i) V | 0.8523 | 0.85025 |
| 4.4x V | 120 or 150 V | 0.87534 | 0.87242 |
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.
The beam width data kindly tabulated by Camilla, the R(V) data from Camille's dcc E2100298, and the analysis code .py are attached, in the .zip. Fair warning, the analysis code also makes a bunch of plots I find useful to look at but another user may find irritating :)
Code for the data points upstream of ZM2 attached. The measured beam widths and their corresponding position are listed in the script. The real raw data with the screenshots from the beam profiler UI is attached to the main log.
I wanted to try to get an idea of what sort of astigmatism we're seeing on the FC path. I was able to get good fits of Begum's data right after ZM1. This indicates that the astigmatism coming right off of the VIP looks quite good ( 99.9 +/- 0.1% overlap between X and Y). Plots of the fits are attached for each lens position.
I wasn't able to get particularly convincing fits of the data after ZM2. The points are several Rayliegh ranges away from the waist and I found that the fits were quite sensitive. I could get answers anywhere between 98%-100% mode overlap between X and Y depending on what parameters I used in a la mode for the seed waist. Someone might be able to do a more sophistocated fit of the data, but I think one would want to measure closer to the waist to better constrain the fit and get a more precise estimate of the astigmatism added by ZM2.
J. Kissel
Quick summary of status and things done before the weekend:
2026-05-14
- Secured new D2400143-v6 breadboard to 1"Dx6"L posts
- w/ J. Freed Helicoiled most holes
2026-05-15
- Finished helicoiling and confirmed all holes have helicoils.
- Brought out IXM100 mounts that are to replace CVM100 mounts, confirmed left vs. right-handed assignment
- Fit-checked (success!), then installed new version of 45 deg periscope adapters to M_M4 and M_M5 mounts.
- Aligned periscope adapters as best possible by eye
- Migrated over and re-cabled up all photodiodes per wiring diagram and cable routing defined in LHO:90228.
- Migrated R_F1 and M_F1 fiber collimators, confirming and adjusting alignment of slow-axis w/ vertical flat.
- Re-connected optical fiber input to each collimator.
- Re-introduced beam on to breadboard confirming that NPRO and Laser Prep Chassis still work as good as we left it.
- Measured raw power from R_F1 and M_F1 fiber collimator output using S121C power meter.
- Aligned R_F1 and M_F1 fiber collimator output using
- D2500080 alignment iris target assemblies
- D2400143-v6 holes 89 + 101 for R_F1 and 101 + 80 for M_F1 and
- S121C behind the "far" iris, maximizing power throughput.
- Migrated R_P1 and M_P1 thin-film polarizers.
- Measured P-pol (TRANS) and S-pol (REFL).
- Migrated D_R_P1 and D_M_P1 beam dumps.
Optical power going into the mock PSL input fiber is ~195 [mW] as we left it, and internal laser prep chassis reads 7.8 [V] implying that input power to the chassis is the same 173 [mW] we set it to, to match the real PSL input (see LHO:89693).
RF power on power monitors from prep chassis are as expected, in the 750 +/- 10 [mV] range.
Measuring power with our trusty S121C with ThorLabs PM100-D readout (confirmed to be measuring at 1064 [nm] wavelength): Josh and I hard at work doing helicoil science. Photo credit: Ryan Short.
A belated photo from the day that both D2400143-v4 and D2400143-v6 were side-by-side, right before the helicoiling and transfer of components began.
Zoom of Cable Table Bracket 1 (CTB-1), which collects - (1st Floor) the D25 end of the D2400343 PD concentrator cable SPI_HAM3_[031-034] (hidden from view), and - (2nd Floor) the D25 end of the D2400342 quadrupus picomotor cable SPI_HAM3_[001-004] and sends them into - (1st Floor) the ST1 end of 28 AWG D25 cable SPI_HAM3_014 - (2nd Floor) the ST1 end of 22 AWG D25 cable SPI_HAM3_012Zoom of Cable Table Bracket 2 (CTB-2), which collects - (1st floor) IFO MEAS A/B single-element PDs' duopus - (2nd floor) IFO REF A/B single-element PDs' duopus and sends them into - (1st floor) Cable D, i.e. SPI_HAM3_032 of the D2400343 PD concentrator. - (2nd floor) Cable E, i.e. SPI_HAM3_031 of the D2400343 PD concentrator.Zoom of Cable Table Bracket 3 (CTB-3), which collects - (1st floor) OL ISIK QPD B - (2nd floor) FBR PWR REF/MEAS single-element PDs' duopus and sends them to - (1st floor) Cable B, i.e. SPI_HAM3_034 of D2400343 PD concentrator - (2nd floor) Cable C, i.e. SPI_HAM3_033 of D2400343 PD concentrator