When we first put together everything for PM1, we just copied all the filters over from RM1(84457). It turns out that the coil drivers for RM1 and RM2 both have had ECRs completed (ECR:E2200307, IIET:24501) that changed the frequency response for the coil drivers, a change which the PM1 coil drivers do not have.

After some troubleshooting (84454), we figured this all out, and so I just went in and updated the COILOUTF filters for PM1 to be what they are supposed to be, which is identical to the filters used in the other HAMA driver top masses that haven't had the ECRs done to them, like the ZMs. Filters have been loaded in.

J. Kissel, R. Kumar, O. Patane, F. Clara

We're debugging why high-frequency asymptote/slope/frequency response of PM1's transfer functions do not match RM1's -- see RED (PM1) and BLACK (RM1) from the attachments of LHO:84397.
I immediately suspected coil driver compensation filters in COILOUTF banks did not match the analog HAM-A driver's low pass filter *state.* 
In the modern era all HAM-A driver's low pass filters are to be jumpered ON since we don't have binary input/ouput remote control of them. And when instantiating a new HTTS suspension, because there's no MEDM interface to set it, and you have to "caput" the channel (H1:SUS-RM1_BIO_M1_STATEREQ) to 2.0 via the command line. 
When we forget to do this, we errantly see the analog response of the driver in the health check transfer functions rather than the expected "falls as 1/f^2 above the resonances."

We confirmed (via trend) that I *did* set this correctly when I original brought the infrastructure online see LHO:84457 comment to LHO:83293 on Mar 20 2025. 
We also confirmed that it's still the case today -- see attached screenshot, with magneta box around the CD state.

We also confirmed that the LED status lights of the LP filter are green / ON, which report that, internally, indeed the HAM-A driver's LP filter switch is in the "Run" state, which is LP ON, see attached photo of SUS-C4, U-heights 3 (for PM1),4 (for RM2), 5 (for RM1) (per page 14 of D0902810-v11).

HOWEVER 
(1) In taking that picture, I noticed that all the HAM-A drivers in that rack had a sticker mentioning ECR E2100430 *except* for PM1's driver in U3. 
In that ECR -- which is for modifying the OMs -- is better described in T2100410, the low pass filter response was changed from a z:p = [10,20]:[1,200] to z:p = [0.5,3174]:[52.32, 50.77].
There are later ECRs E2200307 and E2400048 that demand the *rest* of the HAM-A drivers should be modified with these same changes.
Tickets IIET:20650 (for OMs) IIET:24501 (for IMs, RMs, and OFI), confirm that these modifications have been done at LHO for those suspensions.

(2) IIET:30349 (for the A+ SUS), suggests that no such modifications have been done at LHO (and partially implemented at LLO).
Rahul confirms with a pictures from SUS-M1 that the ZM1 ZM2 ZM3 and the OPO, and SUS-C8 for ZM4 ZM5 ZM6 that there are no stickers referencing any ECR E2100430, E2200307, and what it *should* reference, E2400048.
From this we conclude that E2400048 has NOT been implemented here at LHO.
 
(3) Finally - even though ECRs demand that essentially ALL HAM-A drivers should now have this LP filter change -- there exists NO version of D1100117 that has the the change in components or callout of new frequency response. This is likely why this change got overlooked when setting up PM1's HAMA driver.

So, from the lack of sticker, lack of updated circuit drawing, and odd health check transfer function response --  we conclude frequency response PM1's HAM-A driver has frequency response is still the z:p = [10,20]:[1,200] response.

When I set up PM1, I copied RM1's COILOUTF frequency response. 
RM1's COILOUTF is *correctly* was compensating the z:p = [0.5,3174]:[52.32, 50.77] analog response. 
However, that will NOT correctly compensate the unmondified PM1 driver's z:p = [10,20]:[1,200] response.

*sigh* For now, we'll update the COILOUTF filters, and then discuss later when / if we want to modify the driver.

Original (and more detailed) post: SWG:12283

I have added two scripts and a folder to the Common/MatlabTools of the Sus SVN. The folder is called ExportedModels and it contains exported [A,B,C,D] matrices for making state-space models for 13 suspension types (HLTS_model, QUAD_model, HAUX_model, etc.). It also contains a SUS_projections struct that contains a summary of the OSEM to euler bais changes for most suspensions, also organized by suspension type.

Instructions to navigate the structs can be found in export_SUS_production_models.m, and export_SUS_projection_matrices.m; both inside Common/MatlabTools/

The idea is that these two can be imported into other programming languages (I'm thinking python right now) for analysis, scripting or any other things that people might want.

___

The use I have in mind right now is for OSEM calibration using ISI drives, following the work we're doing with Oli [see LHO:84296]. But could be handy for something else.

Mon May 19 10:06:14 2025 INFO: Fill completed in 6min 11secs

FAMIS 31086

The PMC was left unlocked over the weekend, and when Oli relocked it this morning, it came back with higher transmitted power but about the same reflected, and the ISS diffracted power is lower too. As things are still settling, PMC TRANS is coming down and the ISS diffraction is coming up. However, this has also made the (already poorly calibrated) rotation stage downstream unhappy as the higher power out of the PMC is causing the stage to not exactly provide the power requested (e.g 2.2W vs 2.0W) and the LASER_PWR Guardian is reporting "Power not the same as requested." As the HAM1 team is currently using the beam for alignment checks and doesn't particularly care about the extra 200mW, I'll leave things alone for now.

Dry air skid checks, water pump, kobelco, drying towers all nominal.

Dew point measurement at HAM1 -43.9 °C.

TITLE: 05/19 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: LIGHT_MAINTENANCE_WINDY
    Wind: 17mph Gusts, 10mph 3min avg
    Primary useism: 0.02 μm/s
    Secondary useism: 0.11 μm/s
QUICK SUMMARY:

HAM1 doors should be going on today!

LVEA is currently LASER SAFE (84443)

Sun May 18 10:06:37 2025 INFO: Fill completed in 6min 33secs

Sat May 17 10:06:18 2025 INFO: Fill completed in 6min 14secs

I left 10W out of the rotation stage, with the stage de-engergized this evening and the light pipe closed.  I've just now unlocked the PMC (LOCK off, RAMP off) so that we won't have 10W on the light pipe shutter all weekend. 

Sheila and I went into HAM1 today to do a few last things:

• we used a power meter to do quick power budgeting on both the POP and REFL paths. Results will be posted Monday. Fast summary: results are sensible
• We did a quick check to determine that all beams are going where they are supposed to be, nothing is blocked
• we checked light is still present on diodes, they are good to go
• we did not end up taking distance measurements, due to feasbility limitations since we were using portable stairs and could not touch the ISI. However, we believe that we can get the data we need from pictures and drawings.

From ISC perspective, we are good to go for doors and pumpdown.

Sheila, has Transitioned the LVEA back to LASER SAFE.

TITLE: 05/16 Day Shift: 1430-2330 UTC (0730-1630 PST), all times posted in UTC
STATE of H1: Planned Engineering
INCOMING OPERATOR: None
SHIFT SUMMARY:

Work is ongoing in HAM1 to finish up all the checks we need done before doors go on next week.

The RM/PM damping issues that we've been seeing (84427) are most likely due to the higher purge air in HAM1 since they had been working fine two days ago when the purge air had been turned way down, and yesterday and today when the purge air had been turned up, were not working. We'll be able to better confirm this on Monday during a time when we can have the purge air very low and there isn't any activity happening in HAM1. RM1, RM2, and PM1 have been put into SAFE for the weekend.

The LVEA is currently LASER HAZARD.

Sensor correction is on in the LVEA (SEI_ENV: LIGHT_MAINTENANCE_WINDY and SEI_CONF: NOBRSXY_WINDY).
LOG:

Famis 27815 TCS Weekly Chiller Water Level Top-Off

DCC T2200289

Jennie W, Sheila, Elenna

In order to get data for mode-matching and for Elenna to get data to calibrate sideband heights we ran some mode scans after the SR3 heater was turned on last night.

16:55:24 UTC Carried out single bounce OMC scan at 10W PSL input with sensor correction on HAM6 on, high voltage on for PZT driver in HAM6, sidebands off , SRM mis-aligned, ITMY mis-aligned, DC 3 and 4 on, OMC ASC on.

Excitation freq changed to 0.005 Hz as the top peak of the TM00 mode looked squint so could have been saturating. Lowering this frequency prevented this.

Ref 15-17 corresponds to dcpd data, pzt exc signal, pzt2 dc monitor.

Then mis-aligned ITMX and aligned ITMY (Sheila had to re-align SR2 to centre on ASC-AS_C).

Measurement starts at 17:08:18 UTC.

Ref 18-20 corresponds to dcpd data, pzt exc signal, pzt2 dc monitor.

Traces saved in 20250516_OMC_scan.xml. The top left plot is the first scan bouncing beam off ITMX, the second scan is the bottom right bouncing off ITMY.

The top right is the two plots of the PZT2 DC voltage monitor. That is, the current voltage applied to the PZT. The bottom left is the plot of the voltage ramp applied to the PZT2 on the OMC for this measurement.

The ndscope attached shows the power in mA transmitted through the OMC on the top, then the PZT used for the scan DC voltage underneath, then the input PZT voltage underneath that, then the reflected power from the OMC in mW, then at the bottom the SR3 heater element temperature in degrees.

Elenna did two more scans in single bounce with sidebands back on and different modulations depths in each.

J. Kissel

Today Dave installed all the simulink front-end code infrastructure that Oli and I built for PM1 (see LHO:83214), Oli created a generic MEDM macro for PM1 and attached a call to that file with the generic HTTS MEDM screen to the sitemap yesteday. 

That meant I had everything in place for me to completely fill out the PM1 infrastructure:
- Populated OSEM2EUL, SENSALIGN, and EUL2OSEM matrices with generic HTTS values
- Populated OSEMINF filter banks with standard OSEM calibration filters and turned them ON with a gain of 1.0 for now
- Populated the DAMP filter with standard (recently improved) HTTS damping filters
- Populated the COILOUTF filter bank with HAM-A coil driver frequency response compensation, and turned the filters on with magnet polarity compensating gains of UL LL UR LR = +1, -1, -1, +1'
- Populated and turned on the RMS filtering to support the watchdog trigger signals, and set the threshold to 150 [urad_RMS] as is the case for other HTTS
- Turned on the on-diagonal elements of the DRIVEALIGN matrix
- Set the calibration gain of the OPTICALIGN alignment offsets to 1.0, which is not the right number, but standard for HTTS. Turn the offset ON.

Then monitored and accepted all the settings in the h1sushtts_safe.snap, expect the OPTICALIGN offsets.
The committed the safe.snap and filter file to the userapps repo.

All we need now is PM1 itself!