J. Kissel (with help/advice from J. Driggers, S. Dwyer, J. Oberling)
WP 11493
Why am I doing this PRIMER
We're yak-shaving again; this time in support of better understanding what the eventual frequency / phase noise will be incoming from a PSL pick-off (at the point of RefCav reflection much like SQZ or ALS fiber pickoffs, see D1300348) for the current design of SPI L (see G2301177; the longitudinal, or "L" DOF of future seismic platform interferemeters "SPI"), corroborating current estimates shown in SWG:12112.
The idea is to establish a "[Hz / V]" linear calibration for the PMC length control PZT, such that once established, we can measure the PSL "frequency noise" in various configurations of the detector (e.g. "only RefCav locked," "only IMC + RefCav," "full IFO CARM + IMC + RefCav"). Critically, for the planned frequency-band in which we plan to use SPI L for ISI platform control -- we care about "frequency noise" delivered on the fiber in the 0.01 to 5 Hz region; this *not* a frequency region typically plotted -- from 10 to 10000 Hz, since that's where the main interferometer (IFO), or frequency-dependent squeezer (FDS or SQZ), or arm length stabilization (ALS), systems care about frequency noise (see e.g. chapter of 3 of P1800022 or chapter 6 of P2200287) -- so it's been a struggle to find plot of this noise in the frequency band we need.
Notice that I put "frequency noise" in quotes. This is because, for a single fabry perot cavity (be it linear, triangular, or bowtie) on resonance,
1 lambda0 1. lambda0
---- df = ------- df = ---- dL = ------- dphi
f0 c L0 2*pi*L0
where
df = actual frequency noise of the laser, whose frequency is f0
lambda0 = wavelength of the laser
c = speed of light = lambda0 * f0
dL = actual cavity length / acoustic noise
L0 = the roundtrip length of the cavity
dphi = phase noise of the laser
which means that (a) all of these noises can be re-cast as version of each other if you know the laser wavelength and cavity length, and (b) that *sources* of these noise can all get confused together when you're just measuring one thing, e.g. the typical error signal -- the reflected light from the cavity. This fact, (b), is why I but "frequency noise" in quotes, or call it *effective* frequency noise.
Now -- the PMC itself is a cavity that is in-air, relatively short, and relatively low finesse. As such, the PSL PMC will never measure the *actual* full IFO CARM + IMC + RefCav *actual* frequency noise, since that frequency (or length, or phase) noise is established with the full 4 km arm cavities, suspended on a BSC+ISI+QUAD system in vacuum. What we'll end up measuring with the PMC are the *other* noises which are "artifacts" of the measurement -- cavity length noise (sometimes called "acoustic" noise), shot noise of the PMC REFL sensor, etc. BUT -- this "frequency noise" is still relevant because it serves as an upper limit on the *effective* frequency noise on the PSL table. Further, one of the open questions for the SPI L is how we'll use it operationally; only when the full IFO is locked or "at 'all' times, or at least when the PMC + ISS + FSS is locked"? So, we also want to see if the PMC "frequency noise" measures anything different in the three configurations of the IFO -- and again, we want this information between 0.01 to 5 Hz.
Eventually, we'll *also* use the FDS system -- which similarly receives fiber-delivered PSL light -- to *then* establish how much *additional* effective frequency noise is added by the fiber as it traverses across the LVEA via the standard LIGO fiber delivery system.
OK. That sets the scene, now on to the actual attempt at creating the linear "[Hz/V]" calibration for the PSL PMC PZT.
Measurement PRIMER
The principle of the measurement is relatively standard:
(0) Understand the *modeled* cavity parameters, including length of the cavity, and frequency "light houses" and a function of cavity length --
:: the HG00 modes (the mode at which the cavity is designed to resonate, and thus cause the highest signal on the transmission PD)
:: the distance between the HG00 models -- the free-spectral-range
:: and the frequencies of other, non-HG00 modes in relation to the HG00 mode, or
:: if there are Pound-Drever-Hall control-side bands on the HG00 carrier light.
(1) With the cavity unlocked, drive the length of the cavity using the length actuator in a smooth linear ramp and watch some photodiode in transmission as the cavity flashes through its various resonant modes. Ensure that ramp pushes the cavity length through at least one full free-spectral range. This ramp through the length of the cavity is often called a cavity "sweep," and sometimes also called a "mode scan." Typically, the drive signal is a triangular or saw-tooth wave-form, such that one gets a repeated linear ramp.
(2) While doing so, record the time series of both the driver value -- in this case a PZT voltage, [V] -- and the transmitted light. The units of the transmitted light actually don't matter, but it's always nice to have a timeseries plotted in physical units, so if you can calibrate the PD into Watts of transmitted power [W]. With the repeated ramp, you can even gather statistics as the cavity sweeps through the same FSR multiple times. We expect to see the HG00 "carrier" peak to have the highest transmission; and thus these are the standard candle "goal posts" that are the most obvious feature.
(3) Then, map the frequencies of "peaks" in the transmitted light time series to a frequency vector, by assigning the modeled frequency of each feature (the two HG00, any clearly identified control side bands, any clearly identified non-HG00 modes, etc. from step 0 ).
(4) Now, map the frequency vector on to the PZT voltage vector to obtain a frequency as a function of voltage.
Here's the kicker: a PZT is a non-linear actuator. So, in order to obtain a *linear* calibration, in [Hz/V], one needs to fit the function from (4) to a polynomial (depending on the number of modeled and identified features in the "cavity sweep," and the personal preference of the data analyst, this can be quadratic, cubic, quartic, etc.) and then take the linear coefficient of that fit as the "[Hz/V]" for a known, typical value for the operating voltage of the PZT.
Another point -- because the PZT is non-linear:
(a) The answer may depend on the maximum and minimum amplitude of the ramp / sweep,
(b) The answer may depend on the rate (or frequency) at which the ramp repeats (i.e. the sweep frequency).
(c) One may get a different answer from a ramp with a positive slope vs. a ramp with a negative slope.
(d) It has hysteresis; even though one might request the same position by requesting the same voltage, the physical position where the PZT lands may be slightly different each time your request the same voltage, or said differently, there's no guarantee that a requested triangle wave with fixed amplitude will push the cavity to the same starting length on each cycle
Also, because there's no a priori clear map of HG00 mode to voltage ahead of time, there's no guarantee that the cavity's free-spectral range is lined up with 0V, i.e. no guarantee that a ramp from +7V to -7V drive will *get* you two HG00 modes and one FSR.
It's these additional points, the kicker, and step (3) that I hadn't remembered, and/or didn't re-appreciate before I got started. Ah well.
Hopefully these things can be done offline.
Measurement Technique
2023-10-31_MeasurePMCSweep_Notes.txt are more detailed notes of the "procedure," but the summary of the specifics:
- With the IFO unlocked, the IMC unlocked, the FSS and ISS OFF, and the PMC unlocked,
- I used the user-controlled excitation "PSL-PMC_ALIGNRAMP" that feeds into the H1:PSL-PMC_TF_IN filterbank in order to drive a triangle wave (i.e. successive linear ramps, one positive sloped and one negative sloped) into the PMC's PZT
- In order
:: to combat the suspicions of non-linearity, and
:: because we didn't know what triangle wave frequency would be best as a compromise between "much less than the PMC cavity pole," and "faster than we expect the free-running PSL alignment, intensity, and frequency to drift"
I recorded 6 different measurements with two amplitudes and three ramp rates (triangle wave frequency; time spacing between voltage maximums):
H1:PSL-PMC_ALIGNRAMP _FREQ [Hz] _MIN [V] _MAX [V]
Trial 1 0.5 -5.0 +5.0
Trial 2 1.0 -5.0 +5.0
Trial 3 10. -5.0 +5.0
Trial 4 0.1 -7.0 +7.0
Trial 5 0.5 -7.0 +7.0
Trial 6 10. -7.0 +7.0
I also show a screenshot of the three FSS, ISS, and PMC MEDM screens, with highlights of what to click to get started in the above configuration after the operator holds the IFO ISC_LOCK guardian state in DOWN, and the IMC_LOCK guardian in OFFLINE.
Further, I show a trend of the relevant channels during the the whol series of measurements.
Since none of the relevant fast channels are stored in the frames (namely, H1:PSL-PMC_TF_IN_IN1 [the ramp] H1:PSL-PWR_PMC_TRANS_IN1 [the PMC trans PD]), I captured the time series of the ramps using the "triggered time response" feature of DTT. These templates live in
/ligo/home/jeffrey.kissel/2023-10-31
2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_0p5Hzramp.xml
2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_10Hzramp.xml
2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm5Volts_1Hzramp.xml
2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_0p1Hzramp.xml
2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_0p5Hzramp.xml
2023-10-31_1521UTC_H1PSL_PMC_TRANS_pm7Volts_10Hzramp.xml
where the file name indicates which amplitude and ramp rate. I then exported these timeseries and plotted the results in matlab, see first attachment,
2023-10-31_1521UTC_H1PSL_PMC_rawData.pdf. The top panel is the PZT voltage triangle wave with the wave maxima highlighted in red, and minima highlighted in green; each traverse from red to green is a "negative slope" ramp, and the traverse from green to red is a "positive slope" ramp. The bottom panel shows the PMC TRANS PD during the triangle wave, where times of maxima and minima of the ramp's triangle wave are highlighted. Don't squint too hard -- I make better plots shown in the "Results" section below.
First Results
After a ton of timeseries parsing, and array index juggling, I took the above raw data and stacked the 6 trials into groups --
every time a negative slope ramp was traversed :: 2023-10-31_1521UTC_H1PSL_PMC_negSlope.pdf, and
every time a positive slope ramp was traversed :: 2023-10-31_1521UTC_H1PSL_PMC_posSlope.pdf.
For each page, which is each trial,
Top panel :: I show every PZT voltage ramp stacked on top of each other. These all look like a very boring single line, but this indicates that I've done my timeseries stacking and index juggling correctly.
Bottom panel :: I show the PMC TRANS PD for each of these ramps. These are only synchronized in time by the MAX and MIN requested ramp voltage, and show some spread. *This* is indicative that the PZT is an imperfect actuator that has hysteresis, as discussed above under (d).
First Impressions from these Results
(I) Positive slope ramps show clear non-linearity around the HG00 mode, especially for the 0.1 Hz and 0.5 Hz data at both excitation amplitudes. So, with this in mind, only the negative slope data is really useful.
(II) From the negative slope ramps are much cleaner, and indeed it looks like the from +7 to -7 [V] ramps were enough voltage to traverse 2 HG00 modes.
(III) Given the alignment of the HG00 modes, we can get the most use out of the +7 to -7 [V] 0.5 [Hz] ramp rate data, but maybe also the +5 to -5 [V] 10 [Hz] ramp rate data.
(IV) What's ODD is that we don't seem to see evidence for the 35.5 MHz sidebands that are imposed on the PSL light incident on the PMC. We would expect, visually, that the sidebands would be symmertric about the HG00. We see no symmetric features. Maybe the modulation index is really low? Dunno.
(V) We guess that everything seen in this "mode scan" is higher order modes.
Next Steps
From T0900616:
PMC Parameter Modeled Value Measured Value
L (roundtrip) 2.02 m 2.02 m +/- 0.008 m)
Finesse 124.708 (124.536 +/- 5.091) 120.44 +/- 0.6
FWHM 1.19 MHz (1.195 MHz +/- 0.0488 MHz) 1.19 MHz +/- 0.06 MHz
Free Spectral Range 148.532 MHz +/- 0.585 MHz 148.32 MHz +/- 0.742 MHz
So we at least know two points on the voltage to frequency map (ie step 3 from above). But, because we know the PZT in nonlinear in so many different ways, we need to make sure we identify some of the other non-HG00 resonances.
We did *not* record camera images during this sweep, so doing so will have to rely on guesses from modeling the cavity (or maybe there's some other characterization documentation DCC that we can find).
Then we can do step 3 and 4.
I note that when we eventually get to the "linearization" step, we need to know the typical operating voltage. The 2023-10-31_H1PSL_PMC_PZT_Voltage_TypicalOperatingVoltage.png attachment shows the typical operating voltage is ~0.77 [V] -- in the same voltage units as the user-defined ramp.
Note -- this voltage is *not* the final voltage applied to the PZT. We have to do some further research, but I think this voltage and the ramp voltage units are DAC voltage (which I presume has the standard LIGO general standards DAC range of +/- 10 [V_peak] or 20 [V_pp]). The MEDM screen indicates that there's a -24 dB gain drop, and then I suspect that the voltage is amplified in analog by somehting like a D060283 board. We'll see.
04:00 LOCKLOSS_SHUTTER_CHECK went to SHUTTER_FAIL
04:12:23 ALS_XARM reports "[INCREASE_FLASHES.run] USERMSG 2: Arm in Fault state! Waiting..."
04:35 Lockloss from FIND_IR right after IR was not found
- Errors with DC0, GDS0, FW1, FW0 again
- Connections reestablished
04:37 I put the detector in DOWN while waiting for Dave to verify that the computers were good - Guardian was slow to react to me INIT'ing DOWN and I had to reselect a few times
04:39 BRSX/Y_STAT nodes in Errors
BRSX/Y Log output:
2023-11-03_04:39:42.266215Z BRSX_STAT [DAMPER_ON.run] timer['run check'] done
2023-11-03_04:39:42.634847Z BRSX_STAT W: Traceback (most recent call last):
2023-11-03_04:39:42.634847Z File "/usr/lib/python3/dist-packages/guardian/worker.py", line 494, in run
2023-11-03_04:39:42.634847Z retval = statefunc()
2023-11-03_04:39:42.634847Z File "/usr/lib/python3/dist-packages/guardian/state.py", line 246, in __call__
2023-11-03_04:39:42.634847Z main_return = self.func.__call__(state_obj, *args, **kwargs)
2023-11-03_04:39:42.634847Z File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/sensor_correction/brs_stat_main.py", line 193, in run
2023-11-03_04:39:42.634847Z where_BRS_should_be = Check_BRS()
2023-11-03_04:39:42.634847Z File "/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/sensor_correction/brs_stat_main.py", line 105, in Check_BRS
2023-11-03_04:39:42.634847Z drift_dat = dat[1].data
2023-11-03_04:39:42.634847Z AttributeError: 'NoneType' object has no attribute 'data'
2023-11-03_04:39:42.635830Z BRSX_STAT [DAMPER_ON.run] USERMSG 0: USER CODE ERROR (see log)
2023-11-03_04:39:42.646044Z BRSX_STAT ERROR in state DAMPER_ON: see log for more info (LOAD to reset)