Displaying reports 64321-64340 of 83266.Go to page Start 3213 3214 3215 3216 3217 3218 3219 3220 3221 End
Reports until 09:56, Monday 06 July 2015
H1 SUS
betsy.weaver@LIGO.ORG - posted 09:56, Monday 06 July 2015 - last comment - 15:22, Monday 06 July 2015(19447)
TMSX investigation

Picking up where Arnaud left off nearly 2 weeks ago, alog 19208 post vent, I am looking at the health of the TMSX suspension.  Basically, we reinvented what he stated - the TMSX LF and RT BOSEMs are less sensitive than they were "before".  The TFs show a DC offset from the Model and the TFs taken a year ago.  We're not sure why this is - Kiwamu suggests that a change in the stiffness of the suspension made during the June cable strain relieving likely would have caused the resonance peaks to shift as well as the DC offset...  We don't think this DC shift is too serious - the loop gain in V and P need to be retuned.

 

I can drive the TMSX with PIT alignment bias and see the Left and Right (suspect) BOSEMs respond, so they are not "out of range" and are actuating.

I reran the TMSX TFS for PIT and VERT - Both look healthy to me, so whatever bad measurement was posted in the middle of the 19208 alog is still gone.

Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 10:17, Monday 06 July 2015 (19450)
I agree with Betsy -- a change in stiffness would only affect the magnitude of the transfer function at low-frequencies. An overall scale factor discrepancy like what is shown here is typically a problem with an electronics gain being different (say, if a satellite pre-amp's circuits have much less gain than before), or an incorrect digital gain (say, if the EUL2OSEM / OSEM2EUL matrices were systematically incorrect). 

It might be that the diodes have a new, worse, open light current, and what is being used for digital compensation / normalization is now in correct. It would be difficult to believe / quite the coincidence that would a problem from *both* LF and RT at the same time. 

Recall that this is FRS Ticket #3246.

------
For reference, I also quote Keita who had replied on this over a small-email-list:
""
Seems like TMSX RT and LF are bigger than before by maybe 5000 counts or so, which I didn't catch when we came out of chamber. We added small masses (strain relief parts) to TMS, so this makes sense qualitatively.

These numbers were already big-ish before vent in a retrospect, and RT is now about 4000 counts away from the open value which is supposed to be -2*H1:SUS-TMSX_M1_OSEMINF_RT_OFFSET~26000 cts. 

No idea if 4000 counts is too small a margine there, nor if the BOSEM height is the cause of the poor measurement results.

Anyway, my questions are, 

1. Were the suspension bias sliders on or off during the measurement?
If not, measure with nominal offset even though we don't know the right alignment for now.

2. Is the S/N of the PIT sensing considerably smaller than before?
If it is, TMS should be noisier than before due to noisier PIT damping, which in principle compromise ASC performance for ITMs (DSOFT, CSOFT).

Regardless of the answers, my gut feeling is that it's possible to run H1 without fixing the BOSEM height for O1 (unless TMSX is shaking too much due to this and the IFO wouldn't lock).
""
betsy.weaver@LIGO.ORG - 15:22, Monday 06 July 2015 (19453)

The PIT and VERT TFs that I ran this morning were with the bias sliders enabled.

H1 General
edmond.merilh@LIGO.ORG - posted 09:17, Monday 06 July 2015 (19448)
Morning Meeting Summary

VAC : pumping going fine. Y-arm to be opened tomorrow. X-Arm on Wednesday. Sloww process to valve-in new getter type pumps.

SUS: FE model changes to be done tomorrow. Betsy picking pu TMS investigations from two weeks ago.

SEI: Evals of FF. HAM6 HEPI Still locked. FE models update for Tues / sensor correction.

CDS: P-Cal cabling at both end stations. Richard/Fil will have a look at the TMS PDs. GPS cabling scheduled for rooftop on Tues.

COMM: Continued working on MICH FREEZE (silmultaneous DRMI locking)

FAC: X-Arm cleaning complete, Y-Arm cleaning ton commense tomorrow. Extra person, Rodney, added to cre to expedite.

LHO VE
kyle.ryan@LIGO.ORG - posted 15:13, Saturday 04 July 2015 (19444)
Kyle on site checking pumps

1440 hrs. local -> In and out of X-end VEA, 

1450 hrs. local -> In and out of LVEA and 

1500 hrs. local -> In and out of Y-end VEA.  


1515 hrs. local -> Kyle leaving site now.
H1 ISC
evan.hall@LIGO.ORG - posted 17:52, Friday 03 July 2015 (19443)
REFL9 rephased

Previously we have seen that moving to in-vac REFL9I for control of CARM has led to worse DARM noise at high frequencies. So as a first step in diagnosing the issue, I wanted to check the phasing of REFL9.

With DRMI locked, I drove a line in PRCL at 212 Hz and then adjusted the in-vac REFL9 LO phase shifter in order to minimize the appearance of the line in REFL9Q. (Since we don't have CARM at the moment, PRCL is the next best thing. Of course, the phasing should be rechecked for CARM once we are back to full locking.)

Originally the phase shifter had 16+4+1/4+1/8+1/16 = 20.44 ns delay, with REFL9Q/REFL9I = 0.15/0.85 = 0.18 at 212 Hz. Now the phase shifter has 26+4+2+1+1/4+1/8 = 23.38 ns delay, with REFL9Q/REFL9I = 0.005/1.08 = 0.008.

Images attached to this report
H1 ISC
jenne.driggers@LIGO.ORG - posted 16:52, Friday 03 July 2015 (19442)
MICH freeze attempt - inconclusive
Nic, Evan, Jenne

We tried looking at the efficacy of MICH freeze with DRMI today.   

First, we looked at the MICH fringe velocity in Michelson-only: With the MICH freeze engaged, the fringe velocity seems to slow down by a factor of about 2 versus without the freeze.  

Then we aligned the DRMI and tried to get some locking statistics (length of time waiting for lock) with the freeze on vs. off, but we aren't really getting any locks at all.  We waited more than 15 minutes without a lock with the freeze off, so we went to trying with the freeze engaged.  With MICH freeze engaged, we had 2 wait times of 2 or 3 minutes, but all other times have been more than 15 minutes.  (We tried changing trigger threshold settings a few times, which is what defined the ends of these 15 minute wait stretches).

So far, it's not clear to us whether the MICH freeze is having a significant effect at all.  We think we'll try again later.
H1 ISC
evan.hall@LIGO.ORG - posted 16:27, Friday 03 July 2015 (19441)
DRMI locking partially recovered

Nic, Jenne, Evan

In spite of the bad POPAIR situation, we were able to get DRMI to lock by increasing the whitening gain of POP18 (from 12 dB to 45 dB), and by lowering the trigger thresholds for MICH by a factor of 10, and SRCL by a factor of 5.

After DRMI locked, we were able to optimize the buildups of POP18 and AS90, mostly by moving PR3 positive in pitch, and then compensating by moving PR2 negative in yaw. In this way we increased the buildup of POP18 by a factor of 45. (We then undid the extra analog whitening gain.) So this seems to support the idea that our issues are caused (at least partially) by misalignment of the power recycling cavity.

We went onto the table and again tried to resteer onto POPAIR_B, but we got only 10 % more power on the PD. POP18 is now at about 6 ct (normalized), whereas we expect about 300 ct for DRMI without arms. So there is still a missing factor of 50 somewhere.

We measured the OLTFs of PRCL, MICH, and SRCL, and they seem fine. So the DRMI LSC seems healthy as far as we can tell; there's just some problem with the POP path.

H1 COC (ISC)
nicolas.smith@LIGO.ORG - posted 14:36, Friday 03 July 2015 - last comment - 15:28, Monday 27 July 2015(19440)
BS Butterfly Ringdown measurement

(evan jenne nic)

Evan said that the Q of the BS butterfly hadn’t yet been measured.

We let the system alone for 10 minutes in DRMI and analyzed the ringdown. The biggest SNR was in the PRCL error signal.

The resonance frequency is 2449Hz, the Q factor is (5.6 pm 0.2) 	imes 10^{6}. This means a time constant of 12 minutes.

Ringdown with fit is atached.

Non-image files attached to this report
Comments related to this report
nicolas.smith@LIGO.ORG - 15:28, Monday 27 July 2015 (19969)

(script attached)

Non-image files attached to this comment
H1 DAQ (DAQ)
stefan.countryman@LIGO.ORG - posted 12:32, Friday 03 July 2015 (19439)
Timing System Installation Diagram v. 1 on DCC
I've been working on a diagram of the timing system with specific locations and uses of every timing system component. I've put it up on DCC as https://dcc.ligo.org/LIGO-D1500201. I'd appreciate feedback regarding what else would be useful (while bearing in mind that I'd like this to stay clear and simple). I'm also happy to make extra pages if someone needs a detailed view of some particular element of the system that wouldn't fit into the overview shown.

Happy 4th!
Non-image files attached to this report
H1 ISC
evan.hall@LIGO.ORG - posted 23:57, Thursday 02 July 2015 (19436)
Initial alignment recovery progress

Jenne, Evan

Tonight we ran through initial alignment of the corner in order to get back to DRMI locking (without arms). This is a bit different than usual, since we cannot use the X arm as a reference for PR3 (via the COMM beat note) or for IM4 and PR2 (via the IR input pointing).

Initially we just restored the suspension slider values for PRM, PR2, PR3, SR2, SR3, SRM, and IM4 to their pre-vent values. Then we tried locking PRX, but found that we could not get decent fringing, even by moving the PRM a milliradian or so in pitch and yaw. So we instead restored the pitch and yaw values of PR3 as seen by the oplev, and then optimized the fringing using PR2 and PRM. This allowed us to lock PRX with a decent amount of light at the AS port (>1000 ct on ASAIR_LF with 10 W PSL power), and we then engaged the PRX WFS loops as usual.

We were able to lock the dark Michelson and optimize the BS angle without issue.

We were able to lock SRY using a similar philosophy as PRX: we restored the SR3 alignment to its pre-vent values as seen by the oplev. After that, we saw fringing and were able to optimize it by moving SRM. Then we were able to lock SRY and engage the SRC alignment loops without issue.

Then we tried moving on to DRMI locking. The flashes at the AS port look more or less normal, but there seems to be very little going on in POP18. We saw some flashing with peaks < 1 ct, but for normal DRMI acquisition we expect hundreds of counts. We went onto ISCT1, and found that the beams were low (by about 1 mm) on both the POPAIR diodes. We adjusted the spot on POPAIR_B so that it is more centered, but this only brough the flashing up to at most 15 ct (at 20 W PSL power).

Since it seemed that the POP path was somehow not aligned, we then relocked PRX (with WFS loops feeding back to PRM) and moved IM4 while watching the spots on the POP QPDs. We centered the spots as best we could, then ran through the other initial alignment steps again, and then tried locking DRMI. However, this did not improve the flashing in POP18. For the time being, we reverted our change to the POPAIR_B pointing on ISCT1.

JCD:  Since we were able to lock the individual pieces of the vertex, it seems like the vertex optics are all aligned to one another, however I am less confident in the overall alignment (e.g., the input pointing doesn't match what the Xarm will want, so we're not hitting all of our PDs simultaneously).  I am not quite sure how to resolve this, with the sensors that we have at our disposal right now.

H1 PSL (ISC, PSL)
sudarshan.karki@LIGO.ORG - posted 20:40, Thursday 02 July 2015 - last comment - 11:50, Monday 25 January 2016(19434)
ISS Loop Transfer Function Measurement

Inner Loop

ISS Inner Loop has  UGF of 22 KHz with a phase margin of about 50 degress. This was measured with variable gain set at 6 dB for the best phase margin. This is the normal operation settings for Inner Loop.

Outer Loop

Outer Loop has a UGF of 1 KHz ( designed for 4 KHz) with a phase margin of  about 30 degrees. The variable gain was set at 40 dB (max available) and an additional gain stage(?) was switched on as well.

Also tried moving the the Inner loop gain to see if it shows any improvement on the outer loop but no luck.

TF Plots are attached.

Images attached to this report
Comments related to this report
sudarshan.karki@LIGO.ORG - 18:18, Monday 06 July 2015 (19460)

These transfer function measurements were taken at ~10 W of PSL power.

sudarshan.karki@LIGO.ORG - 11:50, Monday 25 January 2016 (25141)

The data used for the plot above is attached.

Non-image files attached to this comment
H1 CAL (CAL, DetChar, INJ)
peter.shawhan@LIGO.ORG - posted 19:53, Thursday 02 July 2015 - last comment - 10:12, Friday 03 July 2015(19435)
Sign flip seen in ER7 hardware injections
I selected a loud sine-gaussian injection done during ER7 at each site and compared h(t) data from the HOFT frames against the intended strain waveform; this is documented at https://wiki.ligo.org/Main/HWInjER7#Injection_sign_check .  It looks like the injection came through with the wrong sign at LHO, but with the right sign at LLO.  This should be investigated.
Comments related to this report
peter.shawhan@LIGO.ORG - 10:12, Friday 03 July 2015 (19438)CAL, INJ
I double-checked the PCAL-based strain sign checks at both LHO and LLO and they seem sound.  So the sign flip seen for the ER7 hardware injections would have to be something related to the actuation path used for the hardware injections, e.g. the inverse actuation filter bank or perhaps the location of a minus sign in the main feedback loop (in the output matrix or elsewhere?).
H1 ISC
nicolas.smith@LIGO.ORG - posted 16:38, Thursday 02 July 2015 - last comment - 20:22, Friday 10 July 2015(19432)
Couldn't make fringe wrapping with bright michelson

(evan jenne nic)

We wanted to investigate the OMC alignment/backscatter problem. Driving the OMC SUS in Yaw has been known to cause backscatter noise due to the modulation of the optical path length when the OMC moves in Yaw.

Our procedure was to lock the vertex optics in a bright michelson configuration (a state has been added to the IFO_ALIGN guardian to make this easy). Then we wanted to drive the OMC in yaw and choose the yaw->longitudinal matrix element such that the center of rotation would be about the input beam, rather than the omc center of mass. This would be determined by minimizing the scatter as measured by either OMC trans, or the MICH error point.

I was surprised that we were not able to induce any significant backscatter fringe wrapping noise in this configuration. We drove the OMC SUS in longitude up to the point that the beam was misaligning enough to noticibly affect the OMC DC trans.

We also drove the ISI table directly by putting a 1Hz 1mm injection into the Y isolation loop error point. 

Driving the path length, we both listened and had a live spectrum running. We saw no evidence of scatter in either OMC trans or MICH_IN1.

We will need to think if there is another configuration (available to use without arms) that will be more sensitive to backscatter.

Comments related to this report
nicolas.smith@LIGO.ORG - 16:52, Thursday 02 July 2015 (19433)

I forgot to mention that we turned on the AS fast shutter and OMC pzt high voltage supplies for HAM6.

nicolas.smith@LIGO.ORG - 20:22, Friday 10 July 2015 (19563)

This measurement didn't work because I was wrong about the calibration. The isolation loop error points are in nanometers, not micrometers. So we were moving the table 1000 times less than I thought.

H1 General
nutsinee.kijbunchoo@LIGO.ORG - posted 16:21, Thursday 02 July 2015 (19431)
Ops Summary

8:52 Sudarshan work on ISS

         Fil to EX (run cables)

9:16 Jordan to HAM6 checking on PEM sensors

9:44 Kyle to HAM6

10:01 Kyle grab He bottle at EY

10:15 Leo - EX ESD measurement

10:20 Kyle out of EY

11:25 Dave and Stefan to EY - Hook up GPS receiver

11:32 Fil & Andrea back from EY

11:50 Jordan to LVEA testing PEM accelerometer

12:04 Leo done with EX ESD measurement. Starting EY ESD measurement.

12:47 Jordan back

13:00 Kyle to EX

12:42 ISI HAM5 tripped

           -No correlation with PEM acc. sensors. Not sure what happened. Coincides with sharp peak on 1-3 Hz ground motion plot. Suspect electronics issue.

13:42 Fil and Stefan to EX by the rack

13:53 Jordan to EX

14:12 Leo finished EY ESD measurement

14:24 Rick and Sudarshan to LVEA - ISS work by PSL enc.

          Kyle back

14:37 Jordan to EY

15:00 Fil & Stefan back

15:10 Rick & Sudarshan back

15:19 Sudarshan & Jordan to IOT2R table

15:27 Kyle to HAM6

15:41 Kyle back. Shutdown HAM5, HAM6 annulus pump.

 

Other notes:

- Jordan discovered magnetometer at EY rack output straight line since June 22nd.

- Laser Hazard notifications added to Ops Overview.

 

HAPPY HOLIDAY!!!!

LHO VE
kyle.ryan@LIGO.ORG - posted 16:17, Thursday 02 July 2015 (19430)
~1530 hrs. local -> Isolated HAM5 and HAM6 annulus pump carts and shut them down


			
			
H1 SUS (SYS)
leonid.prokhorov@LIGO.ORG - posted 15:39, Thursday 02 July 2015 (19429)
OPLEV Charge measurements
More charge measurements. Plots are attached.
Images attached to this report
H1 DAQ (DAQ)
stefan.countryman@LIGO.ORG - posted 15:05, Thursday 02 July 2015 (19425)
Calibrated Cesium Standard CsIII Atomic Clock in MSR to Minimize Long-Term Linear Drift
Jim, Daniel

I calibrated the frequency of the CsIII Cesium Standard Atomic Clock in MSR by setting the Output Frequency on to 1 + (1010 * 10^-15). I did this at 12:26 PDT on July 2, 2015. I used the serial port on the back of the clock and the Monitor2 software installed on the IBM Thinkpad in MSR.

The previous setting was +1078 (parts per 10^15); I calculated the proper value to be 1010 (details below). I used the time difference between the atomic clock's 1PPS signals and our timing system's 1PPS signals. I took a linear regression to determine the rate of linear drift of the CsIII, since an improperly calibrated Cesium clock shows very little short-term jitter but does show long-term linear drift. Our timing system is long-term accurate since it's GPS backed.

I interpreted the meaning of the time difference according to an explanation from Daniel: a negative time difference means that the external (i.e. Cesium) 1PPS signal is ahead, while a positive time difference means it's behind. I calculated the drift rate to be approximately -6.8e-14 corresponding to -175 ns per 30-days.; the CsIII 1PPS is getting earlier and earlier relative to the timing system 1PPS, suggesting that the period is a bit short. I calculated the proper setting for the CsIII, as explained below, and talked to Microsemi's customer support to confirm that the CsIII's output frequency setting is what one would expect (the instructions were vague). He agreed with my interpretation but didn't have deep knowledge of the system. So we'll have to keep an eye out and check the drift rate in a few weeks to see if it is indeed close to zero (I expect it
will be fine).

The offset to be entered was calculated as follows. The current 1PPS period is given by tau_{measured} - 1 = m_{drift} where m_{drift} is the drift rate. If the clock's "natural" frequency is f_{natural}, then the current offset (Delta{f})_{measured} (which I found to be 1078 * 10^{-15} according to the Monitor2 interface) relates to the current measured period as (1 + (Delta{f})_{measured})f_{natural} = f_{measured} = frac{1}{tau_{measured}}. We want f_{calibrated} = 1, so we need to set (1 + (Delta{f})_{calibrated})f_{natural} = 1 = (1 + (Delta{f})_{measured})f_{natural}tau_{measured}, which simplifies to 1 + (Delta{f})_{calibrated} = (1 + (Delta{f})_{measured})tau_{measured}, giving (Delta{f})_{calibrated} = (1 + (Delta{f})_{measured})tau_{measured} - 1 = (tau_{measured} - 1) + (Delta{f})_{measured}tau_{measured}, or, in terms of the drift rate, (Delta{f})_{calibrated} = m_{drift} + (Delta{f})_{measured}(1 + m_{drift}), which we then divide by 10^{-15} in order to get the value to be entered into the Monitor2 software. See the attached code (written in Julia) for the precise method used. The output (besides the graphs, also attached) includes the above calculations:

Drift rate in Time Code Generator in MSR: -6.786047272268983e-14
Drift rate in Time Code Translator in EX: -6.788794482601771e-14
Drift rate in Time Code Translator in EY: -6.780539996010063e-14
mean_drift_rate = mean($(Expr(:comprehension, :(channel.drift_rate), :(channel = channels)))) => -6.785127250293606e-14
delta_f_measured = 1.078e-12 => 1.078e-12
delta_f_calibrated = mean_drift_rate + delta_f_measured * (1 + mean_drift_rate) => 1.0101487274969909e-12
what_to_enter_into_monitor2 = delta_f_calibrated / 1.0e-15 => 1010.1487274969908

Note that the drift rates calculated for each channel are in very close agreement. I used this to pick the new setting of 1010 for the Cesium clock. The channels I looked at were:

H1:SYS-TIMING_C_MA_A_PORT_2_SLAVE_CFC_TIMEDIFF_1 (Time Code Generator in MSR)
H1:SYS-TIMING_X_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Time Code Translator in EX)
H1:SYS-TIMING_Y_FO_A_PORT_9_SLAVE_CFC_TIMEDIFF_1 (Time Code Translator in EY)

The timeseries (with linear regressions) and histograms are included. The period analyzed is from the beginning of ER7 until last week. I had to remove a chunk of spurious data from the EY channel since Dave and I were using the BNC cable for a different test and polluted the EY channel during that time.

The linear regression shows a very clear and steady trend, as expected. Standard deviation of the atomic clock offset is reduced by a factor of five once linear drift is accounted for, and the histogram more closely follows a Gaussian distribution:

std(z) => 1.1845358220722136e-8    # Jitter about linear trend
std(y) => 5.853090568967089e-8      # Absolute time difference
Images attached to this report
Non-image files attached to this report
H1 DAQ (DAQ)
stefan.countryman@LIGO.ORG - posted 15:00, Thursday 02 July 2015 (19426)
Tested and Installed New CNS II GPS Clocks in EX and EY
Filiberto, Jim, Dave

Installed one new CNS Clock II in each end station in receiving, directly above the Timing IRIG-B Module in each rack. We tested each unit to make sure it successfully locks to a GPS signal.

Filiberto ran an extension cable for the GPS antenna from VEA into receiving in both end stations in order to provide signal for the new CNS II as well as a BNC cable from receiving to CER to deliver the CNS II 1PPS signal to the third time difference port of the Timing Comparator located there. The cable lengths for the 1PPS signals are the same to within an inch.
H1 CAL (AOS, CAL)
sudarshan.karki@LIGO.ORG - posted 10:01, Wednesday 17 June 2015 - last comment - 14:41, Sunday 12 July 2015(19186)
Gravitational Wave Strain h(t) sign convention determination using Pcal

Calibration Team

Sign of h(t):

The gravitational wave strain h(t) is given by  h(t) = Delta L/L where Delta L  is is computed using

                         Delta L = ± (Lx - Ly)

The sign of Delta L can be determined using Pcal actuation on the test mass. Pcal only introduces a push force  so pcal readout signal (truly pcal excitation) is minimum when the testmass is away from the corner station (closer to pcal laser). From the first plot the phase between DARM/PCAL is ~ -180 degrees (DARM lags PCAL) which suggests that DARM signal from ETMX will be maximum when pcal is minimum (ETMX further away from corner station). Similarly, from second plot, since DARM and PCAL have a phase difference of ~-360 degrees (essentially 0 degrees), the  DARM signal from ETMY is minimum when the pcal is minimum. This shows that the sign convention for the Delta L is '+'

Time Delay between Pcal and DARM:

Also the slope of the curve gives the time delay between Pcal and DARM signal chain. The time delay is about 125±20 us. This time delay can be accounted for, within the uncertainity, from the difference in signal readout chain outlined in Figure 3 attached.

Refer to LLO alog #18406 for the detailed explanation behind this  conclusion.

Images attached to this report
Comments related to this report
peter.shawhan@LIGO.ORG - 10:04, Friday 03 July 2015 (19437)CAL
I believe this sign check and the sign check at LLO are correct.  For the record, below is how I reached that conclusion:

The photon calibrator laser can only push, but there is a nonzero baseline intensity and you modulate the intensity around that.  The question is, if you apply a positive voltage to the PCAL system input, do you get more force or less force on the test mass?  Figure 21 of the PCAL final design document seems to show that the undiffracted beam through the AOM is what is sent to the test mass, so increasing the amplitude of the 80 MHz drive to the AOM REDUCES the force on the test mass.  However, the AOM driver electronics could introduce a sign flip when it conditions the input voltage.  To check that, I pulled up PCAL excitation and receiver photodiode data (e.g. H1:CAL-PCALX_EXC_SUM_DQ and H1:CAL-PCALX_RX_PD_OUT_DQ) and plotted a short time interval at GPS 1117933216.  I saw that the PCAL photodiode signal variations are basically in phase with the PCAL input excitation, with just a ~30-40 degree phase lag at ~500 Hz, presumably from filter delay.  So, applying a positive voltage to the PCAL system input causes more force on the test mass, and anyway the PCAL receiver photodiode measures intensity directly.  I confirmed this for all four PCALs (H1 and L1, X and Y) and also confirmed that the transmitter and receiver photodiodes vary together.

The PCAL pushes on the front of the ETM, i.e. on the face that the primary interferometer beam reflects off of.  This being a pendulum, the ETM is closest to the laser (i.e., the arm is shortest) when the force is at its MAXIMUM.  LLO alog 18406 has a comment consistent with that: "Theory of pendulums suggests that Pcal signal will be minimum when ETM swings further away from corner station".  LHO alog 19186, above, has a statement, "pcal readout signal (truly pcal excitation) is minimum when the testmass is away from the corner station (closer to pcal laser)", which is more ambiguous because the ETM being away from the corner station would put it FARTHER from the PCAL laser.  But both draw the correct conclusion from the data: with the intended sign convention, DARM should be at its positive maximum when the X arm is longest (ETMX is farthest from the corner station; PCALX intensity is at its minimum) or when the Y arm is shortest (ETMY is closest to the corner station; PCALY intensity is at its maximum), and that is what was reported at both sites.
darkhan.tuyenbayev@LIGO.ORG - 10:33, Tuesday 07 July 2015 (19466)

Peter,

I disagree with one assumption in your argument, but it does not disprove (or support) the rest of your conclusions.

"The question is, if you apply a positive voltage to the PCAL system input, do you get more force or less force on the test mass? Figure 21 of the PCAL final design document seems to show that the undiffracted beam through the AOM is what is sent to the test mass, so increasing the amplitude of the 80 MHz drive to the AOM REDUCES the force on the test mass. However, the AOM driver electronics could introduce a sign flip when it conditions the input voltage."

As far as I know there's no sign flip in AOM electronics. Undiffracted beam gets dumped in BD2, while diffracted beam is sent to the ETM.

Unfortunately I couldn't find an explicit noting of it in our recent DCC documents.

peter.shawhan@LIGO.ORG - 14:41, Sunday 12 July 2015 (19580)CAL, INJ
Oh, the diffracted beam gets sent to the test mass?  Then I agree, there isn't a sign flip in the electronics.  (In figure 21 in the document, it looks like the undiffracted beam went to the test mass.)

BTW, I've posted a multi-frequency look at the hardware injection actuation sign (and amplitudes and time delays) at https://wiki.ligo.org/Main/HWInjER7CheckSGs.
Displaying reports 64321-64340 of 83266.Go to page Start 3213 3214 3215 3216 3217 3218 3219 3220 3221 End