Ed, Evan
The OIB and OOM were set to Undisturbed/Observing ,66Mpc, at 9:37UTC. Evan cleared SDF of everything that he knew of. Some remaining SDF diffs are as follows: SUSPRM(known issues), OMC, SUSETMY.
This is just a quick report about one of today's calibration activities.
I made a measurement to help understanding the OMC DCPD response by having intensity modulated light on OMC in a simple configuration. At the beginning I was going to use ISS PD arrays to calibration the intensity noise, but it turned out that they were not accurate enough to get 1 % accuracy due to mismatched dewhitening filters in the digital system. Seeking for alternatives, I finally ended up with ASC AS_C. Data and analysis to come later.
J. Kissel, P. Thomas, E. Hall, K. Izumi, E. Merilh We had ceased calibration activities around 10p this evening, and have been trying to recover the interometer since. A few things that have bitten us that none of our current systems could have caught: (1) Kiwamu had turned ON the frequency servo for the ALS DIFF PLL while tuning ALS DIFF actuation function measurements. This was left ON when he was finished, so it took Patrick and Kiwamu a bit off tail chasing witht the VCO frequency slider when the ALS DIFF guardian couldn't find IR. (2) Once we got past ALS DIFF onto to DRMI locking, we immediately saw the normalized ASAIR B RF 90 purple trace on the PRMIsb.stp was high. Kiwamu found that this was a result of new large dark offsets on the electornics. We suspect this has to do with the "transparent" work done in the HAM6 Racks today (see LHo aLOG 20838). (3) An initial alignment was needed (no surprise). (4) Something went wrong with what Evan suspects to be offloading just before the CARM offset reduction. This reduced the recycling gains by a third, and made the signals very noisey. Somehow the lock acquisition sequence and CARM reduction managed to survive, and eventually the SRC and SRC cavity signals came back to normal. Huh... we'll see it if repeats. (5) Power normalization didn't work during power up. Guardian skipped to COIL_DRIVERS without completing INCREASE_POWER. (6) repeat of (4) ... ifo makes it again though. Kiwamu later identifies it as a problem with SRM alignment (7) Fail at the ETMY transition. Found it due to ETMY being still in its high-voltage setting, left over from the later work that Kiwamu was doing with ALS DIFF. (8) Fail at PRM low-noise noise transition (3 coils is less stable to coil driver switching than 4 coils). Hopefully this'll be fixed tomorrow. (9) This SRM alignment business is getting better, without us doing anything... (10) repeat of (5), Evan now suspects an ISC_LOCK guardian change he made yesterday... I'm running out of steam for this. I'll leave it to others to document the rest of the recovery, 'cause this is gunna be just as hard if not harder tomorrow... #premaintenanceday
J. Kissel, K. Izumi, C. Cahillane Evan and Kiwmau wished to get a better answer than my supremely bold claim of being able to ALS DIFF VCO's pole and zero to 1% and 1 [deg] (LHO aLOG 20542). As such, they remeasured the ALS DIFF PLL OLGTF with no boosts, as had been done before, but this time with the PLL Common gain reduced to -32 dB([V/V]) instead of the nominal 26 dB([V/V]). In this way, they reduce the overall loop suppression, in hopes to alleaviate the non-linear distortion we had been plagued by before. The message -- they were right. The new OLGTF, with all other parameters the same, shows that the "nominal" z:p = 40:1.6 [Hz] pair fits the data better than my previously claimed z:p = 40:1.05 [Hz]. However, naturally, there is still confusion. The new *magntiude* residual shows what looks to be a descrepant pole-zero pair around 100 to 500 Hz, but there's no such affect in the phase. Recall that the frequency dependence in the model is simple -- a pole a DC for the phase-frequency descriminator, the z:p pair for the VCO, a time delay, and a single 450 kHz pole. Nothing around 100 - 500 Hz. What do we suspect? More non-linearity. Great. More to think on. We'll measure the PLL controller in the -32dB gain setting tomorrow to make sure it's what we hope -- non-linearity at the negative-edge of the gain setting for this box, that we can just measure and divide out.
Since we propagate the uncertainty in the estimation of the poles and zeros to the entire diff calibration, we needed to do a quantitative fitting. So we did it using LISO. Here is the resultant plot:
The below are the raw output from LISO. We will propagate these errors throughout the ALS Diff calibration.
########## fitting results ###############
It seems that parameter 'delay' has only a little influence on the fit.
Suggestion: disable the 'param delay' instruction.
Correlation matrix (using fast derivatives)
pole1:f zero0:f factor delay
pole1:f 1
zero0:f 0.435 1
factor -0.909 -0.104 1
delay -0.00739 -0.022 1.01e-11 1
Best parameter estimates:
pole1:f = 1.5812454061 +- 8.509m (0.538%)
zero0:f = 40.8398688169 +- 114.7m (0.281%)
factor = 1.8947798127M +- 8.898k (0.47%)
delay = 1.2910415204u +- 84.71n (6.56%)
Final chi^2=1.87823
The fitting code can be found in SVN at
aligocalibration/trunk/Runs/ER8/H1/Scripts/ALSDiff/fit_diff_pll_olgtf_20150824.fil
Calibration work until 05:15 UTC. UTC (Pacific) 23:00 (16:00) Start of shift. Calibration is ongoing. 00:04 (17:04) Kiwamu and Craig C. to LVEA ISC rack to measure ALS DIFF PLL open loop gain 00:11 (17:11) Corner station main entry proximity reader door forced 00:18 (17:18) end X dust monitor invalid alarm 00:37 (17:37) Daniel to CER to check RF distribution 00:43 (17:43) Daniel back 00:45 (17:45) Sheila and Daniel to LVEA to look at racks, changed ASC-AS_B_RF45 sensor cabling (alog 20838) 01:05 (18:05) Sheila and Daniel back 01:30 (18:30) Kiwamu and Craig C. back 02:50 (19:50) Momentary HEPI EX Pressure alarm The ETMX L1 UIM coil driver tripped off 3 times. Kiwamu reset it each time. 05:15 (22:15) Kiwamu done calibration work, I started attempting to lock. Spent about 20 minutes trying to find IR diff by hand. It turned out the frequency servo for the ALS DIFF VCO had been left on and was driving the frequency to H1:ALS-C_DIFF_VCO_FREQUENCY. Kiwamu turned it off. 06:13 (23:13) Evan to CER to check for possible left over issues from the changes Daniel and Sheila made. 06:19 (23:19) Evan back, no issues found Kiwamu has the IFO and is attempting to bring it back.
J. Kissel, P. Thomas Given that we've had so many examples of rocker switch death this evening (see LHO aLOG 20839), I was able to identify that my new(ish) warning message about this failure mode on the MEDM overview screen (see LHO aLOG 20281) had a bug. The MEDM logic was watching L2 for all three stages, L2, L1, and M0. I've committed the bug-fix to the SVN such that LLO can receive its benefits.
What is the MEDM Overview Screen? Is this the overall QUAD Overview? If so, where is the new(ish) warning message? Are you talking about the Guardian message window (upper right corner) on the QUAD overview?
On the top-level screen for each quad, you should see a red rectangle appear around the top, UIM, or PUM coil output filters that says "rocker switch death", as in this screenshot from Jeff's alog.
Stefan, Evan
This is an analysis that Daniel suggested a while ago.
When we increase the interferometer power from 3 W to 24 W, we increase the common-mode radiation force on the test masses. Since the suspensions are compliant, this produces an extra displacement in the test masses along the beamline relative to their suspension points. The CARM loop senses this common-mode displacement and compensates by applying a slow control voltage to the IMC VCO. This control voltage is offloaded to the UIMs of the end station suspensions, and then subsequently to the endstation HEPIs, thereby moving the suspension points of the ETMs forward so as to cancel the radiation-induced displacement. Therefore, an appropriately calibrated HEPI tidal signal can be used to estimate the amount of power circulating in the arms.
We looked at a data stretch from 2015-08-07, when we had been sitting at 3 W for a while and then powered up cleanly to 24 W, and found the following:
On the other hand, when we make a similar estimate from the end-station QPDs, we have something like 24 W × 0.88 × 1/2 × 40 W/W × 283 W/W = 120 kW. [The factor of 0.88 is the modecleaner transmission.]
The calibration of the HEPI tidal signals into nanometers is sort of loose [to within 10%?], according to Hugh. Similarly, there is some spread in the power inferred from the endstation QPDs, which gives an uncertainty that is also on the order of 10%. With a more precise HEPI calibration, perhaps we could use this method to better constrain the optical calibration.
Hugh, Richard, and I had a discussion about the precision of the HEPI calibration, and in the end Richard suggested to just measure the calibration in some locked interferometer configuration (whereby we could read out some calibrated control signal).
I had a go at this by locking ALS DIFF (with IMC F offloading off) and driving HEPI at 200 mHz, with the goal of calibrating HEPI against the PLL. I got an OK measurement by driving 100 nm pk for 8 minutes or so, but then Jim and Hugh pointed out that the ISI was already suppressing some of the HEPI drive, so the measurement probably had significant systematic error. Additionally, Daniel was skeptical that one could cleanly separate length and angle changes on the test mass (both of which can contribute to the sensed CARM displacement).
Jim, Dan, and I thought a bit about this, and (to make a long story short) we forwent HEPI calibration entirely. Instead, we decided to lock the interferometer at 2.2 W, turn off the offloading of the UIMs to the HEPIs, and then power up. The dc portion of the CARM control signal should then accumulate on the UIMs. Since the calibration group already produces estimates of the dc UIM calibration for EY (the ER7 estimate was 5.1×10−11 m/ct), we therefore already have a calibrated readout of the displacement induced by the circulating power (again neglecting angle effects). I don't think the calibration group produces similar estimates for the EX UIM.
This power-up happened around 2015-09-03 09:56:30, from 2.2 W to 22.4 W. I did a linear fit of the UIM drive before and after the power up (see attached). The initial/final slopes are 5.32 nm/s and 5.06 nm/s, so there is some error here in determining the amount of radiation-induced drive (about 10 %). Using the ER7 EY UIM calibration, the amount of radiation-induced UIM displacement is 2.95(30) µm. Using the formulas described above, this translates to a circulating power in the Y arm of 95(10) kW.
J. Kissel For efforts of limiting systematics in the calibration, I've measured all ISC controlled stages of ETMY drivers, UIM, PUM, and TST. For now, I just attach screen shots of the measurements and report where they live, such that LLO might repeat exactly the same measurements tomorrow (instead of their current plan to take the measurements in analog, lugging around an SR785). In the fullness of time, I'll fit these to get precise poles and zeros for use in the DARM model. I can already tell that they will be different from what has been quoted as cannon -- LLO aLOG 4495 -- which is upon what all ETM current *coil* driver compensation filters are based. For example, for some reason, the z:p = 50:300 [Hz] filter on the output impedance network of the UIM drivers, seems to have disappeared. It was supposed to have moved up in frequency when we increased the drive strength (see T1400223 and E1400164) but not disappear. It shouldn't matter for the calibrating, but this is just rediculousness that should be investigated lest we're being misinformed about the frequency region we do care about by a bogus measurement. Anyways, I'll do a similar study to what was done in LLO aLOG 4495 with this data, and we will compensate the calibration accordingingly. Details: ------------------ In order to (1) speed up measurements (2) focus drive amplitude and number of cycles in the frequency regions which were needed, and (3) yield the ability to do multiple slow measurments simultaneously I split the measurements for each driver into several templates with differing frequency bands. Ideally, if I weren't inventing, completing, and hoping to analyse it all to give me a very precise result in one day, I would have used the SEI group's Schroeder-phased TF tool, which has such flexibility, but alas. The templates live and have been committed to here: /ligo/svncommon/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/Electronics/ For ESD Driver in low-noise configuration: 2015-08-24_H1SUSETMY_ESDLVLNDriver_WhiteNoise_0p5Hzto1kHz_$(QUADRANT)_TF.xml 2015-08-24_H1SUSETMY_ESDLVLNDriver_SweptSine_50Hzto1kHz_$(QUADRANT)_TF.xml 2015-08-24_H1SUSETMY_ESDLVLNDriver_SweptSine_500Hzto7kHz_$(QUADRANT)_TF.xml For ESD Driver in high-range configuration: 2015-08-24_H1SUSETMY_ESDHVDriver_WhiteNoise_0p5Hzto1kHz_$(QUADRANT)_TF.xml 2015-08-24_H1SUSETMY_ESDHVDriver_SweptSine_50Hzto1kHz_$(QUADRANT)_TF.xml 2015-08-24_H1SUSETMY_ESDHVDriver_SweptSine_500Hzto7kHz_$(QUADRANT)_TF.xml For PUM Driver (each template covers all quadrants) 2015-08-24_H1SUSETMY_PUMDriver_SweptSine_0p1to30Hz_$(FILTERSTATE)_TF.xml 2015-08-24_H1SUSETMY_PUMDriver_WhiteNoise_1to7000Hz_$(FILTERSTATE)_TF.xml For UIM Driver (each template covers all quadrants) 2015-08-24_H1SUSETMY_UIMDriver_WhiteNoise_0p1to900Hz_$(FILTERSTATE)_TF.xml 2015-08-24_H1SUSETMY_UIMDriver_WhiteNoise_0p1to7000Hz_$(FILTERSTATE)_TF.xml Regarding the system set-up, I took advantage of the secret coil driver switching ability (revealed in, for example, on page 8 of G1401184), to turn off the digital compensation filters, and drove through the either the ESDOUTF bank for L3/ESD or the TEST bank for L1 and L2. Note, though I turned off the frequency dependent compensation, I did not turn off any of the OUTF gain and sign compensation (which is why some of the PUM and UIM driver's signs are flipped with respect to each other). I'll take this into account during post-processing. Also, I've used the 65 [kHz] IOP test point SUS AUX monitor channels as my response channels. I discovered all too quickly that we've been running all of our AUX monitor models at 2048 [Hz]. Sadly, because we ('ve been told we) must develop a very precise inverse actuation filter for the hardware injection team, we need to get information about the high (but not super-nyquist) frequency poles which we compensate for in the DARM ESD path (namely, the ~3250 [Hz] zero -- see LHO aLOG 18769 and LHO aLOG 18579). Not only does a sampling rate of 2048 prevent measuring such zeros, there's also severe distortion from the 65 [kHz] to 2 [kHz] very aggressive IOP down sampling filter. Yes, we know the shape, but it's just much less confusing to not include it in the measurement. However, comparing the IOP test points against the user model versions of the channels did provide good sanity checks. It for example allowed me to identify that -- even though we fixed the user-model channel ordering of the monitors for the low-noise driver, we haven't yet fixed them for the high-voltage monitors, so the Lefts are still reversed from the Rights.
More on this screwy UIM driver result:
I've quickly processed the measurement, just to better show the world that this UIM driver is totally confusing.
Again, the measurement is from the TEST L bank (otherwise empty, gain of 1.0) of the UIM to the IOP Channel of the FAST I MON. During the measurement, all digital compensation of poles and zeros are OFF. This means the signal chain of the measurement is
Drive [ct] >
Euler2OSEM Matrix Element (E2O) >
Coil Balancing Gain (CBG) >
IOP 16k-65k AI(f) >
DAC [V/ct] (G_{DAC}) >
Analog AI(f) [V/V] >
Coil Driver [A/V] >
FAST I Monitor Board [V/A] >
Analog AA(f) [V/V] >
ADC [ct/V] (G_{DAC})>
IOP Response [ct]
That means, to calibrate this measurement of (IOP Response [ct] / Drive [ct]) into the [A/V] of the coil driver, I must divide out the frequency response one 16k-65k IOP upsampling or "AI" filter, the two identical analog AA and AI filters, and multiply by the following gains,
R24_{MON} 1 1 1 1 [ A/V ]
DC calibration = --------- x ---------- x G_{ADC} x --- x --- x ------- = 0.024954 -------
R25_{MON} 2 R5_{UIM} E2O CBG G_{DAC} [ct/ct]
where the response is calibrated with R24_{MON} (= R27 = R29 = R33) = 30k [Ohm] and R25_{MON} (= R35) = 10k [Ohm] which are the gain resistors on the differential-to-single-ended amplifier on the fast current monitor on the monitor board (D070480), coupled with the output impedance of the UIM driver R5_{UIM} (= R23) = 2000 (D070481, with the more up-to-date T1400223), a factor of two from the current monitor math, and G_{ADC} = 40[V] / 2^16 [ct]. For the drive, the Euler-to-OSEM matrix element E20 = 0.25, the coil balancing gain for UL = 0.957, and the gain of the DAC, G_{DAC} = 20 [V] / 2^18 [ct].
With the above calibration, I get the attached plot. I show the UIM's UL coil (the magnitude shows the same response for all four coils).
Where we expect the C12, R104, R4, and R5 output impedance network in the UIM driver D070481 to yield a zero:pole pair of (now) 85:300 [Hz] that is a default frequency response in all states, we see none. State 1, where all low pass filters are OFF, makes this dreadfully obvious.
Even worse, with the DC gain calibration as described above, I do not reach the nominal 0.62 [mA/V] that T1400223 claims either, I get 0.28 [mA/V].
Gross!
If the H1-SUS Rack DCC file card for ETMY is up-to-date (S1301920), the serial number of this chassis is S0900304. This is consistent with the modification aLOG LHO aLOG 11514. Unfortunately, though the traveler was updated, the test plan is just a copy-and-paste of the acceptance testing prior to modification.
When the oppurtunity strikes, I'm going to take measurements of the other UIM drivers to confirm that I'm not insane.
Jeff K. reports that the ETMX UIM driver has tripped. Cheryl reported this happening last Sunday: alog 20808 From plotting the L1 OSEM monitor signals it appears that it tripped on Aug 25 2015 03:08:25 UTC. (plot attached)
Tripped again, investigating.
Time of second trip: Aug 25 2015 03:55:50 UTC Attached is a plot of the L1 OSEM monitors along with the L1 master out drive channels at the time of the second trip. It appears from this that the trip is not caused by the drive to the L1 coils. The power switch for this coil driver was replaced on August 4: alog 20222
Tripped again at Aug 25 2015 04:31:16 UTC.
Daniel, Dan, Stefan I used the 45MHz modulation depth reduction in alog 20777 to fit the amount of 45MHz sideband on the ASC-AS_C_SUM diode: reduction ASC-AS_C_SUM cts 0dB 38430 -1dB 32630 -2dB 27460 -3dB 23680 This suggests that we have the equivalent of 8796cts of power that doesn’t respond to the 45MHz modulation index reduction, plus 29735cts of 45MHz sideband power (at 0dB reduction). Thus 29735/38430 = 77% of the total light is 45MHz sideband, and 23% is something else (mostly carrier). For the ASC_AS-C_SUM calibration I get: 4e-4 fraction of HAM6 light on AS_C (alog 17738, super-seeds 15431) x 800V/W PD gain (alog 15431 -> 200V/W, but in the digital system we do not divide by 4) x 10^(36/20) whitening gain x 1638.4cts/V ADC gain = 33080 cts/Watt_HAM6 I get under nominal conditions (23W, Gamma=0.3, 0dB reduction): 899 mW of 45MHz light (compare that to an expected 23W(INPUT)*(.3)^2/2(MOD)*0.88(IMC)*0.89(NOM IFO TRANSMISSION) = 811mW) and 266 mW of other light (carrier junk?). 20mA of light on the OMC_DCPD transmission, corresponding to about 25mW of "good" carrier light - 10 times less than the junk. Also, if I use the calibration of the ASC-AS_C-SUM diode, normalizing it by the 29735cts of 45MHz SB, I should get a calibrated (power) RIN sensor. I can look at the driven oscillator amplitude noise transfer function to x-check this: I would expect the power RIN / amplitude RIN TF to be equal to sqrt(2). (Note: Daniel's RIN sensor calibrated in Vrms/rtHz / Vrms - a sqrt(2) of my previous alogs, which all quote RIN as Vrms/rtHz / V_pk, being equivalent to a rad_rms/rtHz number. ) I indeed get 1.4. (plot 1). Plot 2 shows the same transfer function but using only the seg1, with the IOP channel (H1:IOP-ASC0_MADC6_TP_CH11). Again, 1.4. Now things hang together...
I can now use ASC-AS_C to check whether the amplitude noise on the 45MHz SB has changed before vs after the EOM driver change. Plot 1 shows ASC-AS_C_SUM in cts (the data is from seg1 only, but a factor of 4 is included to mimic ASC-AS_C_SUM counts). - Red vs blue (-3dB vs 0dB reduction in Gamma) shows a factor of 2 reduction in the noise level, consistent with a Gamma^2 scaling of the noise. - Green shows the noise level before we installed the EOM driver. From the ASC_AS-C counts I estimated that the modulation index was slightly lower, and the noise is consistent with that. Plot 2 shows all 3 traces calibrated in (power) RIN, using the calibration from the main entry, but either way, it looks like the (power) RIN has not changed during the EOM driver installation - very puzzling.... Finally, plot 3 shows the noise calibrated in Watt into HAM6.
J. Kissel, S. Dwyer, E. Hall As I was about to characterizing the ETMY coil drivers (i.e. the UIM and PUM), I noticed that they were in their highest noise state. After conversations with Sheila and Evan, we (re)agreed that the PUMs should be run in their lowest noise state, which is with LP ON and ACQ OFF, or State 3 from T1100507. As such, we've switched all QUADs to this state, and confirmed that ISC_LOCK guardian will ensure this to be true in the future (again). That guardian has been reloaded. The reason they had been put back into high range (and taken out of the guardian) was that the range was needed to better damp the QUAD roll modes after they had been severely rung up in the Christmas Episode in early August. From a calibration stand point, this will affect the DARM calibration by a small amount, but I had not started characterizing the ETMY PUM drivers before I got started, and I'm now full aware of it, so it's affect will be fully understood and expected. As such, we're OK with this configuration change. Further, we'll all be happy with the little bit extra range we get from it (Evan will post an aLOG making a noise statement later)!
We can hear saturations on the quads during CARM offset reduction and when powering up, but I suppose that's the price we pay for the improved noise performance. [See attachment—blue is from yesterday (coils in high-range), red is from today (coils low range). I can't really claim that the improvements at 70+ Hz are from the coil switching, though.]
We would like to acquire with high range and then switch to low noise at some point during the lock, but the transients unlock the interferometer most of the time. Jeff suggests that we commission the digital switching delays. Perhaps that can be done parasitically with calibration activities.
Calibration Measurements:
- Kiwamu, IFO down for calibrations, 9:05 - expected to be all day, continuing now
*** FYI, I move the IFO to Commissioning when this happened and should have been Calibrations - my bad.
Note; We are now in Calibration, so IFO has two states:
'"IFO is up'" OR "IFO is having calibration measurements run."
Today's parasitic IFO/site activities:
- JeffB to EY, dust monitor investigation, 9:07 - done
- Hugh to EX and EY, HEPI, 9:07 - done
- JeffK, ETMY, measuring coil drivers, 9:15
- Sudarshan, PEM channel check in LVEA, 9:20 - done
- TJ EX BRS reset - 9:54 - done
- Kyle, near EY (Y28) to gather stuff - done
- Dave, EX, drawing updates - 12:10 - done
- Kyle, near EY (Y28) to gather stuff, 12:54 - done
- more visits to end stations while there was the opportunity, but no changes, just monitoring or restoring equipment.
Currently no outstanding IFO issues.
Calibration measurements continue.
Calibration Measurements:
- Kiwamu, IFO down for calibrations, 16:05UTC - expected to be all day, continuing now
*** FYI, I move the IFO to Commissioning when this happened and should have been Calibrations - my bad.
Note; We are now in Calibration, so IFO has two states:
'"IFO is up'" OR "IFO is having calibration measurements run."
Today's parasitic IFO/site activities:
- JeffB to EY, dust monitor investigation, 16:07UTC - done
- Hugh to EX and EY, HEPI, 16:07UTC- done
- JeffK, ETMY, measuring coil drivers, 16:15UTC
- Sudarshan, PEM channel check in LVEA, 16:20UTC- done
- TJ EX BRS reset - 16:54UTC- done
- Kyle, near EY (Y28) to gather stuff - done
- Dave, EX, drawing updates - 19:10UTC- done
- Kyle, near EY (Y28) to gather stuff, 19:54UTC- done
- more visits to end stations while there was the opportunity, but no changes, just monitoring or restoring equipment.
Currently no outstanding IFO issues.
Calibration measurements continue.
Stefan, Elli
On Saturday Stefan measured the AS36 signals with dither lines from the BS and SRM (alog 20777):
Lines:
H1:SUS-SRM_M3_ISCINF_P_EXC 7.0Hz, 300cts
H1:SUS-SRM_M3_ISCINF_Y_EXC 7.5Hz, 900cts
H1:SUS-BS_M3_ISCINF_P_EXC 8.0Hz, 100cts
H1:SUS-BS_M3_ISCINF_Y_EXC 8.5Hz, 30cts
Here are some plots of the AS36 signals demodulated against these line frequencies. These signals show how the sensitivy of the AS_36 WFS to the BS and SRM, which changes during the heat-up stage of the whole interferometer, and during 45MHz modulation depth reduction. Attached are plots of the original and demodulated signals vs time. Two vertical red lines are plotted; the first corresponds with when the IFO reaches full power, the second is when the 45MHz modulation depth reduction begins. At the end of the time series the traces go crazy- this is where Stefan reports lock was lost due to SRC1 yaw run away.
The following WFS channels are fed back to the optics at this point:
AS_B_RF36_I_PIT >> SRC1 PIT (seen in demodulation of 7.0Hz line. Right two plots, red trace)
AS_B_RF36_I_YAW >> SRC1 YAW (7.5 Hz line. Right two plots, blue trace)
AS_A_RF36_I_PIT >> MICH PIT (8 Hz line. Left two plots, red trace)
AS_B_RF36_Q_YAW >> MICH YAW (8.5Hz line. Right two plots, brown trace)
The SRC1 PIT signal doesn't change much, which is good. SRC1 YAW has a 180deg ohase change during the heat-up stage. Lines 1813 and 1815 of the guardian indicate a sign change in the ASC input matrix, maybe this corresponds to this phase change (?). MICH PIT signal looks pretty good, getting close to 180deg phase at the end of the modulation depth reduction. MICH YAW drifts downwards in phase, it looks like it hit -180deg just at the point we lost lock.
Small correction: SRC1Y uses the following input matrix (alog 20699): AS_A_RF36_I_YAW to SRC1_Y : -3 AS_B_RF36_I_YAW to SRC1_Y : 1
Jim, Evan
We have grown tired of the glitching in the PRM M3 LL OSEM, so here is a script that ramps it off in full lock. It gets rid of the glitching and allows us to recover 60ish Mpc range.
Also included is a screenshot of the usual Euler/OSEM matrix for PRM.
From detchar, here are some glitchgrams to show just how well this works. The PRM M3 LL OSEM was ramped off at 3:43 UTC, and again at 7:13 UTC in a different lock (times gotten by check EUL2OSEM matrix elements). Two glitchgrams are attached which shows that the excess glitchiness goes away as soon as the LL quadrant is disabled. This is fantastic because these are one of our top most worrisome glitch classes from ER7.
Hey @DetChar, can you make a glitch-gram of the H1:SUS-PRM_M3_NOISEMON_LL_DQ? Evan's gunna make a spectragram to see if it contains the same frequency content as the glitch grams (of DARM and the one you'll make). This "on/off" test of PRM M3 LL, at least shows that the frequency content of the glitching is below 50 [Hz]; if the content is similar in spectragram, we can use that -- a spectragram is much easier to make on the floor and/or at least here on site while the channel is being investigated. At this point, the entire drive chain is suspect, and we're not really sure where to start. I worry that starting without a more pointed target, it means we'll be looking for hours, slamming a sledge hammer blindly everywhere, and only come up with more questions. For example, as you know, these NoiseMons can be tricky. This particular PRM M3 LL NoiseMon has passed what tests that have been done on it (see LHO aLOG 17890), but the test is only a "which one of these doesn't look like the other" kind of test, not anything concrete.
Jeff and I looked at a time series trend of the LL noisemon when the interferometer was not locked, in order to give a baseline for diagnostics.
During a quiet time, it seems the peak-peak of the noisemon is about 30 counts, which [accounting for the ADC gain (216 ct / 40 V)] is something like 20 mV pp.
During a noisy time, the peak-peak can go as high as 100 counts, which is something like 60 mV pp.
@Jeff - A glitchgram would not be terribly enlightening. Normalized spectrograms actually show these glitches very clearly, and even standard spectrograms are fine. These glitches only show up in DARM to about 70 Hz, but they're in PRCL up to 150 Hz (first plot). They're getting fed back to PRM, among other things, so all four quadrants' drive signals look like PRCL. The second plot is the normalized spectrogram of LL MASTER, and it's the same as PRCL. There's also something near Nyquist in the plot, but I think it's just spectral leakage in the spectrogram. The characteristic of the LL noisemon (third plot), in contrast to the other noisemon, is that the glitches go up to 1 kHz. They happen at the same time as the glitches in MASTER, so below 150 Hz this doesn't tell us anything. But the higher-frequency content indicates that something before the noisemon is creating excess noise. And since the excess noise goes away as soon as the LL drive is zeroed, it's not just a problem in the noisemon. The noisemon stops showing any glitches once the drive is zeroed, which may be a useful clue. Is it possible to drive a single line in MASTER and see what the noisemon shows? The first three plots were all normalized spectrograms. The last two are standard spectrograms to show that these glitches do show up there. I used 0.25 sec FFTs with overlap of 0.9.
The frequency response of OMC DCPDs (A and B) are checked using ASC-AS_C as a intensity noise monitor in the single bounce configuration. Even though the response of ASC-AS_C is not well known, the result shows an almost flat response as expected with a deviation of 6% at most which is encouraging.
In order to improve the accuracy of the measurement, we should prepare a well-calibrated photo detector, probably placed at ISCT6, and make the same comparison measurement with the OMC DCPDs.
Method:
The interferomter was in a single-bounce configuration where the beam bounces off of ITMX and goes to the AS port without any recycling. Also ETMs are misaligned as well in order to avoid flash from the arm cavities. The PSL power was intentionally set to the maximum in order to get the maximum signal to noise ratio everywhere. The OMC is locked to the carrier 00 mode with a OMC-LSC_GAIN of 20. I forgot the UGF of the OMC length loop, but it was on the order of 100 Hz, I believe. The OMC alignment was done by the QPD loops with a overall gain of 0.1. For some reason, I needed to engage DC centering loops for the AS WFS A and B, otherwise it would saturate the OMC suspension. The photo current on each OMC DCPD was about 17 mA, which is a bit too high compared with the nominal full lock photo current of 10 mA.
I injected swept sine signal to the ISS inner loop from 7 kHz to 10 Hz. Then I measured a relative response between ASC-AS_C segment 3 and two OMC DCPDs. One trick in doing this is that I had to use an IOP signal to measure the response of ASC-AS_C because the ASC front end runs at only 2 kHz. Also, since I used the IOP signal, I was not able to grab summed QPD signals, and that's why I ended up with one of the QPD segments. Segment 3 happened to receive the highest power and therefore I chose this for the final analysis.
The dtt file and its ascii formated data are checked into the SVN at
/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-24_omc_dcpd_and_asc_pd.xml/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-24_asc_to_omc_dcpds_tfs.txt/CalSVN/aligocalibration/trunk/Runs/ER8/H1/Measurements/OMCDCPDs/2015-08-24_asc_to_omc_dcpds_coh.txtAlso the analysis code can be found in SVN at
CalSVN/aligocalibration/trunk/Runs/ER8/H1/Scripts/OMCDCPDs/analyze_asc_to_omc_dcpds.mResults:
The result is shown in the attached pdf. It is relative gain (or transfer function) between OMC DCPDs and ASC-AS_C. The red dots are for DCPD A and blue for DCPD B. The following frequency responses are taken into account:
Note that since AS_C is acquired at 64 kHz without any downsampling, I did not apply any digital low pass for it. Aside from these known parameters, I had to make some assumptions as follows.
Obviously, the key points to success this method is to reduce the number of the assumptions, but this time I simply attempted with ASC-AS_C, which I had to make multiple assumptions, to get some idea of how the measurement would go.
As shown in the upper panel, the absolute magnitude is almost flat with a trend in which the DCPD response higher at high frequencies. The error bars are placed by using the usual coherence technique (see alog 10506). The low frequency part below 20 Hz is clearly limited by low coherence, but it seems to consistently show lower response at low frequencies. If we take a peak to peak of the variation, it is going to be roughly 1.04 / 0.94 ~ 10 %. Looking at the phase, shown in the lower panel, the phase seems to diverge as it goes to high frequencies such as AS_C response. I don't think it can be explained by mismatch in the analog anti-aliasing filters because they are usually well matched. At this point, we can not really say if the high frequency deviation is from the real DCPD response of some artifact from unidentified uncompensated AS_C response.