Reports until 14:09, Tuesday 16 April 2024
H1 SUS (ISC, OpsInfo)
jeffrey.kissel@LIGO.ORG - posted 14:09, Tuesday 16 April 2024 - last comment - 14:17, Tuesday 16 April 2024(77211)
H1 SUS IM Alignment Sliders now Calibrated into microradians
J. Kissel

EXECUTIVE SUMMARY

After having visited the calibration of the HAUX alignment sliders since 2016 (see LHO:30010), it's time to re-measure and recalculate what these gains should be, as we've lost confidence in their accuracy. 

I've recalibrated the IM1, IM2, IM3, IM4 alignment sliders today, such that one count offset in [pitch, yaw] produces 1 microradian in [pitch, yaw] according to the OSEMs. To correct from the previous incorrect calibration, slider values would have needed to be multiplied by factors of 20 to 30 [urad/"urad"].

METHODS AND RESULTS

In order get something in play quickly, I've used the OSEMs as my absolute angle reference, having been calibrated into microns [um] for years and cast into PITCH and YAW through trusted OSEM2EUL matrices to produce pitch and yaw in microradians [urad]. 

Recall the goal is to calibrate the output of the OPTICALIGN banks, which are nominally in Euler basis DAC counts [DAC ct] such that when you request the slider to move in your desired physical unit (in this case, [urad]) then the output of the bank requests the appropriate amount from the DAC. Thus, we need a gain, H where
    slider offset [urad] * H [DAC ct / urad] = DAC output [DAC ct]        (1)


In short, the method is:
    (i) Set the OPTICALIGN gain to 1.0 so there's no confusion during the measurement.
    (ii) Request the slider offset to be a range of values (I arbitrarily chose [-10000, -5000, -1000, 1000, 5000, 10000]; six data points such that a linear regression had plenty to grab on to)
    (iii) At each requested value, record the OSEM values.
    (iv) Fit a line to a plot of OSEM value vs. slider value, i.e. (slope * slider value + offset). The slope will be in units of [urad / DAC ct].
    (V) Invert the slope to obtain the slider calibration gain in units of [DAC ct / urad].
I used an ipython session interactively to do so for all IMs at the same time via for loops, while the IMC was unlocked and misaligned.

Here're the results in units of [DAC ct / urad] (rounded to the nearest 4th decimal place):
         PIT       YAW
IM1     9.9093    5.3457
IM2    10.1124    5.4868
IM3    12.5623    6.8758
IM4    10.9005    5.6289

Note that the results are not insignificantly different from suspension to suspension, even though every HAUX actuation chain should be the same. So, I've elected to install these suspension specific gains (like we have with other suspensions that have had recent attention), rather than a generic gain for suspension type based on a model of the actuation strength.

The first two pages of 2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_GainFitPlots.pdf shows the plots of data, and their fits. As an aside, because I drove the slider requests programmatically via ipython, it was easy to measure both the pitch and yaw OSEM values during the other DOF's slider changes. As such, I also gathered the amount of cross-coupling between pitch drive and yaw response and vice versa, yaw drive and pitch response, in units of [urad / DAC ct]. This is shown on the last two pages. The good news is that the off-diagonal cross-coupling is an order of magnitude or two less than the expected diagonal coupling (I think auto-y-axis-scaling dataviewer or ndscope sessions have scared us for years). That being said, IM3 is the worst offender.

After I installed the new calibration, I've made sure to set the *actually* [urad] value to reproduce the same [DAC ct] output that had been requested with the previous incorrect ["urad"] values (generated with the incorrect [DAC ct / "urad"] gain, G). The method for doing so is revealed through a quick algebra exercise,
    slider offset [urad] * H [DAC ct / urad] = DAC output [DAC ct]                 (1)
    bad slider offset ["urad"] * G [DAC ct / "urad"] = DAC output' [DAC ct']       (2)

    want
    DAC output [DAC ct] = DAC output' [DAC ct'],

    so
    slider offset [urad] * H [DAC ct / urad] = bad slider offser ["urad"] * G [DAC ct / "urad"]
    
    slider offset [urad] = bad slider offset ["urad"] * G [DAC ct / "urad"] / H [DAC ct / urad]     (3)
or, in words, multiply the old bad offsets by the ratio of (old gain / new gain) to get the new well-calibrated offsets.

In addition to calibrating the offsets, I also updated the visual representation of the available range on the MEDM screen. In this case, given that the HAUX are driven with 18-bit DACs, then each OSEM can drive 2^17 - counts. The EUL2OSEM matrix elements for conversion of pitch and yaw to each of the four OSEMs is +/-8.594 [um / urad], so that means that a Euler basis pitch and yaw [DAC ct] drive cannot exceed 2^17 / 8.594 = 15251 [Eul DAC ct]. After dividing by the above calibration for each, that takes the slider limits to (roughly, taking the lowest range -- IM3 -- as the limiter) +/- 1200 [urad] for pitch and +/- 2200 [urad] for yaw.

2024-04-16_H1SUSIM_AlignmentSlider_Recalibation_OPTICALIGN_Screens_after_correctunits.png shows the final product after all of these changes,
    - the new slider gain values,
    - the new slider offset values to reproduce the same DAC output, and
    - the updated range of values.

Operators be aware: the amount of nudging you need to do on IM4 during initial alignment will need to change as a result of this re-calibration. Using the same math as Eq. (3) above, [1, 10, 100, 1000] "urad" nudges now are actually, roughly [0.05, 0.5, 5. , 50] "urad" nudges.

2024-04-16_H1SUSIM_AlignmentSlider_Recalibration_Notes.txt are my very rough notes from the morning's work, including all mistakes, as well as ipython code snippets to take actions, store information, and make plots. Could be cleaner for future users, but alas.
Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 14:17, Tuesday 16 April 2024 (77214)
As a result of this work, I have accepted the new OPTICALIGN slider calibration gains, which are "monitored" in the h1susim_safe.snap.
As is tradition, the OPTICALIGN slider offsets are *NOT* monitored, so I made sure to go to the "full table" and force accept the offsets as well.

Finally, I've also committed the update to the 
    /opt/rtcds/userapps/release/sus/common/medm/haux/
        SUS_CUST_HAUX_M1_OPTICALIGN.adl
because these values (a) are not too terribly different than the previous +/- 2500 ["urad"] range that was there, and (b) I expect the L1 HAUX to have similar calibration, when they get to it.