jeffrey.kissel@LIGO.ORG - posted 15:07, Tuesday 04 January 2022 - last comment - 18:01, Wednesday 05 January 2022(61214)
Benchtop Data and Results for ETMX PUM Driver after ECR E2100204 Upgrades to Increase z:p frequencies of Lowest Noise State
J. Kissel, F. Clara ECR: E2100204 IIET Ticket: 18986 Installed: Dec 09 2021 LHO aLOG 60972 Chassis SN: S1000346 Getting started on the action items listed in LHO aLOG 60990 and IIET Ticket 21642, I pulled the data that Fil posted to the H1 SUS ETMX L2/PUM driver's serial number DCC page (S1000346), plotted it, and fit it to see if the data will be good enough for the calibration group -- who sets *very* high standards, hoping that the compensation of this driver's response is better than 1% over as wide a frequency range as possible, with particular focus on frequencies between 5 and 200 Hz (see orange trace in the most recent plot of the relative contribution of each actuator stage to the DARM response in LHO aLOG 58727). Sadly, the data appears to be a bit too noisy -- exactly in this 5 to 200 Hz region -- to provide a trust-worthy fit. Attached is a 5 page .pdf that shows our now traditional "quad bode plot" (showing the magnitude and phase of the measurement and model in the left column, and then the magnitude and phase of ratio aka residual of the two in the right column) for each coil in pages 1 through 4, and then finally all four coils one one plot on page 5. Where the data fails due to "poor" quality is most obvious in the residual plots -- there are unphysical jumps between frequency points when one divides the (continuous) z:p:k fit into the data and those unphysical jumps result in residual that is larger than 1% within the most important frequency region. What's striking is that the frequency content of noise on the measurements is consistent across coils; I'm not sure I have a good explanation for it, but regardless, the data is too noisy to convince me that the fitting algorithm has done a sufficient job in sifting through that noise to arrive at poles and zeros that would perfectly compensate noise-free data. The message -- we're going to need to drive this board again, with either more cycles or higher excitation amplitude, in the region whether the filter is doing the most work to filter *out* that excitation -- between 5 and 200 Hz. While we're at it, we can help out the fitting program by driving to lower and higher frequency as well. Unfortunately the board is already installed, so we'll have to make trips to the end station. C'est la vie! Details on the measurement, where I relocated the data, where to find the script used, and where the results live will come in the comments.
Non-image files attached to this report
Comments related to this report
Benchtop Measurement Setup: Fil employed the new(ish) SR785 Accessory Box (D1900068) -- affectionately referred by it's designer's name -- The Dean Box. Setting up the measurement system like what's shown on Page 6 of the Dean Box Brochure, Fil did a quick fiddle of the SR785 settings to tune the frequency range, drive level, and channel configuration by hand. The DUT, in this case is the the PUM driver. Note, the brochure assumes DB9 cables and pinouts on both sides of the driver, but the PUM driver has a DB15 connection to the UK SatAmp going toward the chamber, so there must have been *some* sort of breakout board / clip leads / BNC situation. Also, as confirmed by Fil's measurement notes within the zip file, he hooked up a 20 Ohm resistor across +/- legs of the output ("to sat-amp") port to create a dummy OSEM load. Thus the raw data is V_diff_out / V_diff_in, which mains the actually transfer function we want (or at least typically plot as the fundamental transconductance units of the driver), I_out / V_diff_in, is (V_diff_out / V_diff_in) / R_load. I've done this division before plotting and fitting, so all analysis is done in units of [Amps / Volt_diff_in]. Nice and trivial measurement system set up -- I can't wait to use it!
J. Kissel
I'm trying to be good and write my scripts in python (instead of matlab) and commit to a git repo (instead of svn), so the data analysis script to produce the fit lives here:
/ligo/gitcommon/suspensions/ligo/electronics/fits/fit_ETMX_PUM_driver_20211209.py
The fitting algorithm's core uses IIRRational -- "version 2.5.0" whatever that means -- more precisely, I updated my local checkout to git hash 4c43d042, i.e. the to the version Lee last committed to 6 months ago on Jun 21 2021.
However, as we're still (inactively, as far as I know) trying to figure out what to do with (potentially, but not in this case) large collections of binary blobs, I committed renamed and re-organized versions of Fil's data to
^/trunk/Common/Electronics/H1/Data/SUSElectronics/ETMX/PUM/2021-12-09/
and the .pdf plots of the results live in
^/trunk/Common/Electronics/H1/Results/SUSElectronics/ETMX/PUM/2021-12-09/
For the record (so we can compare the answers from future fits of less noisy data against fits of data with *this* level of noise to see if this level of data produces "good enough" fits), here's a summary of the zeros and poles from this fit:
STATE 3 (ACQ OFF, LP ON) SUMMARY
UL -- [z]:[p] = [ 11.9695 28.8833 137.1716]:[ 2.5227 145.1761 1206.0845]
LL -- [z]:[p] = [ 11.7926 28.6319 123.9059]:[ 2.4875 132.7571 1178.9901]
UR -- [z]:[p] = [ 12.1761 28.9206 125.9417]:[ 2.5256 137.2523 1192.0923]
LR -- [z]:[p] = [ 12.0471 28.9893 129.2467]:[ 2.5252 139.1522 1194.4004]
Recall, in the PUM driver's State 3 (see StateMachineDiagrams_PUMDriver-v7.pdf from T1100507) we expect to have two collections of zeros and poles: one from the switchable low pass filter -- which is ON in State 3 -- and one from the switchable output impedance network (the "acquire" filter) -- which is OFF in State 3.
We do not expect the acquire network to have its response changed after ECR E2100204, so these should still be, roughly, [z:p] = [12:110] (in Hz).
The currently installed compensation is
# DESIGN ETMX_L2_COILOUTF_UL 5 zpk([117.3675],[11.3742],1,"n")
# DESIGN ETMX_L2_COILOUTF_LL 5 zpk([115.3799],[11.9118],1,"n")
# DESIGN ETMX_L2_COILOUTF_UR 5 zpk([119.1647],[11.6034],1,"n")
# DESIGN ETMX_L2_COILOUTF_LR 5 zpk([119.1031],[11.5558],1,"n")
where, remember the *compensation* must flip the poles and zeros, i.e. the compensation's zeros match the drivers poles, and poles match the zeros.
Thus, I expect the above fit z:p values of
UL -- [z]:[p] = [ 11.9695 ] : [ 145.1761 ]
LL -- [z]:[p] = [ 11.7926 ] : [ 132.7571 ]
UR -- [z]:[p] = [ 12.1761 ] : [ 137.2523 ]
LR -- [z]:[p] = [ 12.0471 ] : [ 139.1522 ]
are the response from the output impedance network, with the acquire switch "OFF." The fact that the fit's poles are higher in frequency than expected and previously measured gives me further corroborating evidence that this data set is not good enough.
The poles and zeros for the low pass filter are *expected* to be:
Before Implementing ECR E2100204 [6, 20] : [0.5, 250]
After Implementing ECR E2100204 (something higher, to by written down in a future -v2 of E2100205)
The currently installed compensation is
# DESIGN ETMX_L2_COILOUTF_UL 7 zpk([0.4979;245.6072],[5.5323;22.4187],1,"n")
# DESIGN ETMX_L2_COILOUTF_LL 7 zpk([0.4915;240.0583],[5.4697;21.8761],1,"n")
# DESIGN ETMX_L2_COILOUTF_UR 7 zpk([0.4988;243.0059],[5.5514;22.1419],1,"n")
# DESIGN ETMX_L2_COILOUTF_LR 7 zpk([0.4989;243.4424],[5.5456;22.2043],1,"n")
which agrees with expectation, even if the second 250 Hz pole frequency is ~3% lower in real life (~243 Hz).
Pulling out the acquire zero:pole pair from the fit leaves what I suspect are the new zero:pole frequencies of the lowpass filter,
UL -- [z]:[p] = [ 28.8833 137.1716 ]:[ 2.5227 1206.0845 ]
LL -- [z]:[p] = [ 28.6319 123.9059 ]:[ 2.4875 1178.9901 ]
UR -- [z]:[p] = [ 28.9206 125.9417 ]:[ 2.5256 1192.0923 ]
LR -- [z]:[p] = [ 28.9893 129.2467 ]:[ 2.5252 1194.4004 ]
i.e. somewhere around [z]:[p] = [29, 130]:[2.5 1200] Hz. We'll see if these numbers hold up to scrutiny of lower noise data!
We will also benefit from taking *ratios* of transfer function states, so the fitting program can better isolate the zeros and poles of the lowpass vs. the output impedance network. Saying it "out loud," mostly to refresh my own memory:
- Fitting State 1 alone yields the Acquire OFF zero:pole pair
- Fitting State 2 alone yields the Acquire ON zero:pole pair
- The ratio of State 3 to State 1 will have only the lowpass filter zeros:poles
We will do as Fil has done, and measure the transfer function of the driver while the output is loaded a known resistance rather than the AOSEMs (I'll ask Fil if I can borrow his 20 [Ohm] resistor). (If I'm greedy, I'll then *remeasure* the TFs with the AOSEM connected, such that I can fit for the AOSEM response too...)