Displaying reports 61941-61960 of 77271.Go to page Start 3094 3095 3096 3097 3098 3099 3100 3101 3102 End
Reports until 16:29, Friday 19 December 2014
H1 SEI (ISC, SYS)
jeffrey.kissel@LIGO.ORG - posted 16:29, Friday 19 December 2014 - last comment - 18:17, Sunday 11 January 2015(15756)
Bad GS13 Gain Guardian Switching vs Watchdog Loop
J. Kissel, K. Venkateswara, K. Izumi, J. Warner

While Kiwamu was trying to lock the Michelson, several things went wrong, but it uncovered a flaw in the new gain switching of the GS13s that has been implemented in the Guardian (see LHO aLOG 15537. Here's what happened.
(1) Kiwamu incorrectly brought up the BSC ISI in "fully isolated," which turns on stage 2 isolation loops, and switches the GS13s to high-gain mode.
(2) As expected, while trying to acquire MICH lock, impulses sent to the SUS BS kick the cage as well, which is attached to the BS ISI ST2, and trips the ST2 on the GS13s watchdog.
(3) We then reset the watchdog, and switched to "isolated damped," and this triggered the new guardian feature to *start* switching the GS13s back to low gain, but with MICH still trying to lock, impulses would still trip the watchdog before guardian had the chance to switch *all* of the GS13s gains. 
(4) This, trigger-happy watchdog resetting, and guardian half transitioning, caused a nasty loop of guardian sloshing the GS13 gains back and forth between high and low, which, with MICH impulses, continued to trip the watchdog.

I attach a plot of one of the WD trip, which clearly shows that the V3 GS13 had failed to have its gain switched to low. 

We should 
(a) look the new code to make sure there isn't a bad loophole regarding the GS13 gain switching when transitioning from "fully isolated" to "isolated damped"
(b) look for ways to increase the switching speed, or add a pause / check that the switch has occured on all GS13s before proceeding with the transition
(c) remember that these are physical, several thousand pound systems -- if you have to reset watchdogs repeatedly something is wrong and you don't know why, don't just blindly continue to mash the reset button, figure out what's wrong, or do what Kiwamu did and ask an expert!

#justwait
Images attached to this report
Comments related to this report
hugo.paris@LIGO.ORG - 09:40, Friday 09 January 2015 (15961)

The GAIN and DWT filters' switching mode is set to zero-crossing, with a time-out of 2s (see attachement). Even though Guardian engages the filters properly, they don’t actually switch until a certain time, causing MICH to start acquiring lock before the ISI is ready for it.

This could be solved by selecting the immediately switch mode for the GS13 GAIN and DWT filters. But, after discussing it with Jeff yesterday it turned out that he recalled switching gains with the ISO on, which would be way less stable without zero-crossing.

I modified the SEI guardian to add a 3s wait at the end of the gain switch sequence to give the filters the time they need to switch with the current zero-crossing configuration, before allowing MICH to start acquiring lock.

This fix should be tried next time we start acquiring lock on MICH.

Non-image files attached to this comment
hugo.paris@LIGO.ORG - 18:17, Sunday 11 January 2015 (16007)

Jeff, Hugo,

The SEI guardian patch I made was tested today. Jeff locked MICH while SEI_BS was in the ISOLATED_DAMPED state (GS13 in low-gain). Once MICH was locked, we switched SEI_BS to FULLY_ISOLATED (GS13s in High Gian, and ST2 Iolation loops turned on). The ISI did not trip, and MICH remained locked.

In order to make sure that this was ra reliable fix, we went ahead and switched the state of the SEI_BS node back and forth between ISOLATED_DAMPED and FULLY_ISOLATED a couple times. Once again, the ISI did not trip, and MICH remained locked.

Time series of the state of the SEI_BS Guardian node, versus the MICH error signal, are attached

 

The updated  code was commited under the SVN:
/opt/rtcds/userapps/release/isi/common/guardian/isiguardianlib/isolation/util.py     -r9543

 

Note: Jamie gave me good feedback on how to improve this new code. The goal here was to make sure it works. I will optimize it once I am back at Stanford.

Images attached to this comment
H1 AOS (ISC)
eleanor.king@LIGO.ORG - posted 16:19, Friday 19 December 2014 - last comment - 14:58, Thursday 14 May 2015(15758)
PRM high bandwidth filters

Thomas, Stefan, Jeff, Kiwamu, Elli

Continuing along the same line as yesterday's work on PR3 (alog 15727), we have designed high-bandwidth (<10Hz) actuation filters for the PRM.  These filters are applied to H1ASC-PRC1P and H1ASC-PRC1Y in the central part of the ASC WFS servo.

The filters added to ASC WFS central are called 'PRM^-1' and are:
H1:ASC-PRC1_P:   zpk([0.2+i+0.9;0.2-i*0.9;0.05+i*3.41;0.05-i*3.41],
                [0;0.2+i*2.75;0.2-i*2.75;0.125+i*9.99922;0.125-i*9.99922],1,"n")
H1:ASC-PRC1_Y:     zpk([0.04+i*1.08;0.04-i*1.08;0.1+i*2.08;0.1-i*2.08;0.05+i*3.43;0.05-i*3.43],
                [0;0.15+i*1.8;0.15-i*1.8;0.05+i*3.3;0.05-i*3.3],1,"n")
Some old unused filters were also removed.


Low-pass filters called 'RLP17' were added to the PRM M3 locking filters in pitch and yaw:
H1:SUS-PRM_M3_LOCK_P:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")
H1:SUS-PRM_M3_LOCK_y:  zpk([4+i*119.933;4-i*119.933],[6.78887+i*13.9134;6.788887-i*13.9134],1,"n")

Comments related to this report
thomas.vo@LIGO.ORG - 18:27, Friday 19 December 2014 (15760)
After getting the hang of creating some of these filters and we werestrongly encouraged to write a detailed proceudre:
 
1. Create a white noise, M3 to M3 transfer function using the templates located in /ligo/svncommon/SusSVN/sus/trunk/HSTS/H1/PRM/SAGM3/Data, you can actually use any bottom stage sensor that is available, OSEMs or OptLevs but on PRM, we're only let with the OSEM option.
 
2. The idea is to use the transfer function and then add zeros and poles using the calibration feature in DTT to roughly get a filter than will give you the damped motion you're looking for with the correct phase without waiting for measurements to run everytime you're changing the Q or freq of the pole/zero:
We start by finding the frequency of the lowest resonance and then this will give us an idea of the complex portion and then we eyeball a Q depending on the original transfer function's Q.  By shifting the complex portion of the zero, we attempt to get the correct phase and dither by hand until we roughly supress the resonance with 30-35 degrees phase margin.  We move on with the same procedure for the higher frequency measurements, creating poles and zeros when necessary.  Attached is a before and after look at the transfer function.
 
3. Now that we have the right idea for the ZPK values, we can create a filter module in the ASC WFS Servo Control.  For PRM the correct filter is h1ASC-PRC1 and so we just copied the new filter values into foton and then test by first locking PRMI and then ramping the gain slowly and watching if the DAC saturates or the PRMI breaks lock.  If it doesn't break lock we can tell that our loops are unconditionally stable and then retake OL transfer functions with the new filters in place to see if we're adding any new noise.  Then you're pretty much done.​
Non-image files attached to this comment
stefan.ballmer@LIGO.ORG - 00:44, Saturday 20 December 2014 (15764)
I had to sighly correct the filters to make them stable. Attached is what we now have running.

The filters are:
PITCH: zpk(  [0.1+i*1.02;0.1-i*1.02;0.12+i*3.35;0.12-i*3.35],  [0.12+i*2.75;0.12-i*2.75;11.1111+i*38.4258;11.1111-i*38.4258]  ,1,"n")
YAW:   zpk(  [0.015+i*1.09;0.015-i*1.09;0.03+i*2.05;0.03-i*2.05;0.02+i*3.43;0.02-i*3.43],  [0.05+i*1.75;0.05-i*1.75;0.02+i*3.25;0.02-i*3.25;11.1111+i*38.4258;11.1111-i*38.4258],1,"n")

Images attached to this comment
betsy.weaver@LIGO.ORG - 14:58, Thursday 14 May 2015 (18430)

Note, commissioners (Kiwamu/Evan) report that they turned these filters off ~April 21st, 2015 since they were no longer needed.  Filters now off are PRM M3 LOCK P and Y FM9 (RLP17).  SDF has been updated.

H1 CDS
david.barker@LIGO.ORG - posted 16:06, Friday 19 December 2014 (15755)
restart of h1isiham3 and h1hpiham3

Fabrice, Hugh, Dave:

we restarted the models h1isiham3 and h1hpiham3 as part of the seismic investigation of this chamber. No new filters, code or daq configuration were applied, this was a simple restart.

LHO VE
kyle.ryan@LIGO.ORG - posted 16:00, Friday 19 December 2014 (15754)
Halted pumping of Y-end -> Will resume Monday


			
			
H1 General
jeffrey.bartlett@LIGO.ORG - posted 15:59, Friday 19 December 2014 (15753)
Ops Shift Summary
LVEA: Laser Hazard
Observation Bit: Commissioning  

08:00 Cris – Delivering garb to End-X
08:40 Doug – OpLev work at HAM4
08:51 Kyle & Gerardo – Roughing BSC10
09:00 Betsy, Travis, & Rick – At End-X
09:10 Fabrice – BS & HAM3 Testing
09:13 Filiberto & Aaron – PEM cabling work in the Beer Garden
09:30 Karen – Going to End-Y
09:55 Kyle & Gerardo – Back from End-Y
10:18 Jim – Going to End-X to unlock HEPI & ISI
10:30 Shutdown dust monitor at HAM1
10:36 Karen – Back from End-Y
10:40 Dale – High School tour in control room
11:19 Dave – Going to End-Y to adjust cameras
11:21 Jim – Back from End-X
11:45 Betsy, Travis, & Rick – Back from End-X
12:50 Jim – Going to End-X to unlock HEPI
12:52 Filiberto – PEM and cabling work in Beer Garden and along spool arms
13:50 Dave – At End-X to adjust cameras
14:02 Kyle, Gerardo, & Bubba – End-X Install West door, connect pump cart and pump annulus
14:05 Dave – Back from End-X
14:44 Filiberto – Out of the LVEA
14:47 Dave – Restarting HAM3 models
15:28 Rick – Taking Mike R. and friend on tour of LVEA
15:40 Kyle, Gerardo, & Bubba – Finished with BSC9 door install, started pumping annulus 
H1 SEI (SEI)
fabrice.matichard@LIGO.ORG - posted 15:52, Friday 19 December 2014 - last comment - 15:42, Monday 05 January 2015(15751)
More HAM3 Investigation

Jim, Hugh, Krishna, Jeff, Fabrice:

 

We keep investigating the sensor corrction issue on HAM3. What we found yesterday is that it depends on which blends are engaged. We can't explain why yet. We did additional tests today:

- we turned off all CPSs of all HAM-ISI and BSC-ISI in the corner station. No change.

- we checked the jumpers of all HAM3 CPS boards. All good.

- we tried to apply large offset in case it would reduce some kind of cable touching/rubbing (+/-400 um in HEPI Z, and +/-400 um in ISI X,Y, Z). No change.

 

Finally, we tried to do the Z sensor correction to HEPI. In the plot attached:

- Red curves is HAM3 ISI isolated, no sensor correction

- Green Curve, we turn ON the sensor correction in X and Y to the HAM-ISI

- Blue Curve, we also turn on Z sensor correction to ISI. The 0.6 HZ peak shows up. For some reason it also reduces X at the microseism.

- Brown, we do the Z sensor correction to HEPI instada of ISI. The peak is still there in the CPS, but not in the GS13. It's unclear why.

 

The last configuration looks good from the GS13s,  but it's unclear yet how good it is for the cavity. More info on that is coming.

Images attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 17:21, Friday 19 December 2014 (15759)DetChar
One more thing that Fabrice forgot to mention in this recap:
   - they restarted the front-end processes for H1ISI and HPI HAM3 (see 15755) -- and also saw no change.

Perhaps during a future maintenance day, we can hard-reboot the entire chassis.

Some further speculation / questions: 
- That we *don't* see the feature in the GS13s when we're in low-frequency blend when we feed Z sensor correction to HPI (but we still see the feature in the CPS) rules out the GS13s as the source of the problem.
- The 0.6 [Hz] feature is modifiable by changing the RX / RY blend filters -- higher blend frequency means less 0.6 [Hz] feature. RX/RY implies it's a differential vertical noise, in that one of two of the three CPS are causing the problem. 
- Higher blend means more CPS is being used. Wouldn't you think that if the problem is in the CPS, then using more of them would make the problem worse?
- Could it be some subtle, small electronics cross-talk between the STS and the CPS that goes into oscillation? 
- We're grasping at straws. This stinks.

@DetChar -- I know it's impossible to figure out the state of the ISIs offline, but can you track this chamber over time and see at least how long we've seen a 0.6 [Hz] feature? 
It might take Keith Riles type *days* worth of averaging to find it...
It would be also good take Keith Riles type high-resolution ASDs to find out how sharp the feature is, and to quantify how the heck 1.12 [Hz] is related to 0.6 [Hz]...
jim.warner@LIGO.ORG - 15:42, Monday 05 January 2015 (15875)

In case detchar people are curious about the configuration of this chamber over break, when I came in this morning I found the ISI in what we thought was the good state in December. That is, X&Y sensor correction on the ISI, Z on HEPI and normal blends, isolation loops. I doubt anyone changed the configuration since the 19th of December.

H1 PEM (PEM)
dale.ingram@LIGO.ORG - posted 15:51, Friday 19 December 2014 (15752)
Holiday seismic forecast
The information we received from Hanford ops indicated that hauling would not occur on day shift or swing shift today, 12/19.  The 1-3Hz seismic trace during the day today looks pretty noisy, however, as if hauling is occurring.  I'll pursue this next week -- perhaps there's other activity underway nearby.  No hauling is scheduled for the weekend.  Next week the drivers are scheduled to work day and swing on Monday and Tuesday and then go out for the remainder of the week and the weekend.  I suspect that they'll use a similar schedule during the week of Jan 1.   
LHO VE
kyle.ryan@LIGO.ORG - posted 15:28, Friday 19 December 2014 (15750)
~1400 - 1500 hrs. local -> Installed BSC9 West door -> Began pumping BSC9 annulus
Kyle, Gerardo, Bubba -> Door 

Kyle -> Annulus 

Will begin "rough" pumping X-end first thing Monday morning

H1 AOS
krishna.venkateswara@LIGO.ORG - posted 13:38, Friday 19 December 2014 - last comment - 15:44, Friday 19 December 2014(15746)
Z sensor correction to HEPI is working on BS, ITMX and ITMY

F. Matichard, H. Radkins, J. Warner, K. Venkateswara

Due to the problems described in 15690, Z sensor correction to the corner station BSC HEPIs was causing excess tilts at low frequencies. Based on directions from Fabrice, Hugh and I ran tilt decoupling measurements described in 15726 and fixed this to some extent. The pdf attachment (BS_HEPI_Tilt_Decoupling.pdf) shows the effect of the tilt decoupling at the Beamsplitter. The measurements show the X, Y  CPS signals with no sensor correction, with sensor correction and finally with sensor correciton and tilt decoupling. There is still room for improvement and a more careful and longer measurement might reduce this further.

For the moment this seems to be good enough to keep MICH locked with perhaps some improvement in the MICH_OUT as seen in the image attached (MICH_OUT.png). The benefit of the Z sensor correction can be seen in the second image (BS_Zsensor_Correction.png). The improvement is not as significant as some of the other chambers. We should investigate more to see what limits the subtraction.

Edit: I made a mistake in the labeling of the lines. The blue and green labels are switched and so are the blue/cyan and pink labels. In summary, the sensor correction increased x and y motion by a factor of ~10 and ~40 respectively and tilt decoupling reduced it by a factor of ~3 and ~8. A more careful/longer approach may reduce it to the original levels.

 

Images attached to this report
Non-image files attached to this report
Comments related to this report
jeffrey.kissel@LIGO.ORG - 15:44, Friday 19 December 2014 (15749)ISC, SYS
I attach a screen shot of
(1) The tilt-decoupling, IPS Align elements that have been installed for the three BSC chambers
(2) The current, raw IPS position position values for these chambers
(3) The current alignment offsets stored on HEPI

Remember that we're concerned that if the IPS raw position values, (2), reach the edge of their linear range (around +/-25000 = +/-2.5e4 [ct]), then the tilt decoupling numbers could change. However, with the current set points / alignment offsets stored on HEPI, (3), the raw IPS values, (2), are at worst less than +/-14000 (most less than +/-6000), well within the linear range, so we expect the tilt decoupling values (1) to be static and valid.

And just for ease of parsing later, if they get lost in a reboot or something, the alignment decoupling values are
           ITMX      BS        ITMY

RX to Z   (none)   -0.0172   -0.0049

RY to Z   0.0015    0.0038    (none)
Images attached to this comment
H1 SEI
jim.warner@LIGO.ORG - posted 13:19, Friday 19 December 2014 (15747)
ETMX ISI and HEPI UN-Locked
H1 COC (COC)
richard.savage@LIGO.ORG - posted 12:39, Friday 19 December 2014 - last comment - 13:57, Friday 19 December 2014(15744)
ETMX cleaning
Betsy, Travis, Jason, Rick

First Contact was peeled from the ETM surface this morning.  No First Contact remnants were observed on the surface.  

Particulate counts, using the "Green Lantern," were in the 2-5 particles per square inch range, down from the 5-10 particles per square inch seen before applying the first contact.

The composite image attached below contains six images.  The upper row of three were taken before applying the First Contact and the lower row of three were taken after the First Contact was removed.

For all images, the surface of the ETM was illuminated with a green LED flashlight.  For the four images on the left the flashlight was held by hand.  For the two in the right, the flashlight was set in the Arm Cavity Baffle in an effort to make the illumination the same for both images.

Images attached to this report
Comments related to this report
betsy.weaver@LIGO.ORG - 13:57, Friday 19 December 2014 (15748)

Adding to Rick's alog above, we are not sure we see much change in the particulate as observed via the pcal camera with flashlight illumination.  We did see some improvement of the particle counts when we counted using the green lantern (lights up across the surface).  We blew the optic HR surface for ~10 minutes and did not see much particulate move off.

 

Particle counts:

We appeared to see more particulate in this chamber than in BSC10 - we noted about 2 times the amount of particles floating through the flashlight beam than in with the ETMy.  However, the particle counter counted 0 counts in all sizes when I sampled before we entered the chamber, so it must all be from moving around.  We counted the following just after applying FC to the ETMx and while wiping our way out of the chamber

1090  0.3um

560  0.5um

400  0.7um

260 1.0um

 

Chamber closeout order:

Pulled FC

Blew optic with dei N2 Top Gun for 10 mins

Restored ACB to normal position*

Unclamped optic

Unlocked ISI

Laid witness plates and 1" witness optic (2 on floor, 2 on QUAD sus)

Removed all tools/guns/lights, etc.

Took TFs of ISI and QUAD for health checks

 

*  When we looked at the ACB earthquake stops after replacing it and noticed that one was very high in the hole.  After bantering and worrying about it for an hour, we discovered this alog which says that this is actually how it was tuned to begin with.  Jim checked and doesn't see unhealthy vertical TFs, so we're leaving it again.

H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 10:13, Friday 19 December 2014 (15739)
CDS model and DAQ restart report, Thursday 18th December 2014

model restarts logged for Thu 18/Dec/2014
2014_12_18 11:30 h1fw1

unexpected restart. Conlog frequently changing channels report attached.

Non-image files attached to this report
LHO VE
kyle.ryan@LIGO.ORG - posted 10:00, Friday 19 December 2014 (15738)
~0930 hrs. local -> Kyle, Gerardo began "rough" pumping Y-end
Blow down dewpoint -26C
H1 SEI
hugh.radkins@LIGO.ORG - posted 18:29, Thursday 18 December 2014 - last comment - 13:10, Friday 19 December 2014(15726)
Tilt Decoupling HEPI Z to RX & RY on ITMX ITMY & BS

Fabrice Krishna Hugh.

Krishna was suspecting that RX tilting on ITMY and the BS was impacting the HEPI Z Sensor correction results.  Sure enough, when checked it was most coupled on the BS Z to RX and next on ITMY HEPI Z to RX.  The other couplings, that is, HEPI Z to RY, and for ITMY both HEPI Z to RX & RY, where less by about a factor of 10.

The Measurement

HEPI Z is driven with a 0.001 to .1 band pass excitation (see attachment 1) looking for coherence with ISI Stage1 T240 X & Y.

The HEPI is in normal configuration, Lvl1 position loops but with sensor correction off.

The ISI Stage1 all dofs are put into high blend (T750) and its sensor correction is also off.

Once a baseline of the existing HEPI Z to ISI Stage1 T240 to RX & RY coupling is established as seen by the T240 Y & X, the HEPI is then Tilted in RX & RY with a smaller magnitude but similar bandpass to see the actual tilt of the ISI Stage1 when HEPI is tilted.  The Decoupling factor is computed by the ratio of the former to the latter: RXz/RXrx.  This correction goes into the IPS Align matrix.

Results

See attachment 2 for ITMY.  The left three plots are the TF data for inline tilt on ITMY, this is the Y direction caused by RX; the three right plots are for the crossline tilt RY showing on X. The first step is shown in blue: the area below 0.1 to 0.01hz with good coherence is our tilt coupling.  Notice on the right side, there is poor coherence and the TF magnitude is 10x smaller than the tilt in the Ydirection seen on the left side.

The green traces are the direct tilt measurement HEPI RX(RY) to ISI RX(RY).  Picking a few magnitude points from the blue & green traces in the area of interest and averaging the ratios gives the decoupling factor blue/green= 0.23/46(e.g.) == -0.0049 with the sign coming from the phase which are ~180 out of phase.

The brown trace (only on the left side) shows the reduction with the decoupling factor in the matrix (see last attachment) when the first measurement is repeated. (I failed to save the coherence for this but it was reduced just above 0.8 from the near 1 at the start (blue.)  This indicates there may be more improvement to be made but it will be time consuming and may not be worth it.  The improvement though is clear, about a factor of 10.

Time constraints (commissioners) prevented a brown results curve measurement for the Z to RY tilting but I have the data to calculate the ratio.  We expect the improvement to be minimal as the coupling is already low.

Images attached to this report
Comments related to this report
krishna.venkateswara@LIGO.ORG - 13:10, Friday 19 December 2014 (15745)

I've attached similar data for the Beamsplitter HEPI. The RX and RY correction values were based on the following measurement:

                                        the transfer function between Z drive to X/Y

Correction value =  ------------------------------------------------------------------------

                                        the transfer function between RX/RY drive to X/Y

 

For the beamsplitter, we measured

RX correction = - 0.0172

RY correction = + 0.0038

The plot shows the transfer function between Z drive to X/Y before and after the tilt decoupling.

Images attached to this comment
H1 SUS
betsy.weaver@LIGO.ORG - posted 14:32, Thursday 18 December 2014 - last comment - 12:26, Friday 19 December 2014(15717)
ETMx Test Mass cleaning status

Secretary notes from BSC9 today:

We will pull the FC sheet ~9:30 am tomorrow and hopefully get the door back on by lunch.

Comments related to this report
betsy.weaver@LIGO.ORG - 14:41, Thursday 18 December 2014 (15719)

Note, there were apparently no witness plate or witness optics placed on the floor of BSC9 when it was closed last time, so we did not pick them up today.

betsy.weaver@LIGO.ORG - 12:26, Friday 19 December 2014 (15743)

Also, I forgot to mention that when we inspected the ETMx-HR, we saw some mottling and haze across the surface but we did NOT see the "ring" feature that the FC left on the ETMy-HR.

H1 General
edmond.merilh@LIGO.ORG - posted 12:12, Thursday 18 December 2014 - last comment - 10:17, Friday 19 December 2014(15715)
Ops Overview MEDM screen edited for Suspensions

The Ops Overview screen that shows the graphic representation of the IFO (OPS_OVERVIEW_CUSTOM.adl) had been previously unable to report individual suspension stage watchdog trips. According to the models, the discreet watchdog stages are "ANDED" into an EPICS channel called $(IFO):SUS-$(LOC)_DACKILL_TRIG_STATE which was the only conditional channel included for the Visibility Calculation in MEDM. This channel will never show it's alarm state unless all upstream watchdogs have been tripped therefore making said "trips" invisible in this overview, which has become a popular one with operators and others as well (imo). Discreet watchdog channels have been added and tested for BS and all Quad suspensions. This overview screen can now be relied on  for accurate reporting on the status of any suspension watchdog trips.

Comments related to this report
edmond.merilh@LIGO.ORG - 14:07, Thursday 18 December 2014 (15716)

TMSs and everything down the output arm has been added to his list, also.

edmond.merilh@LIGO.ORG - 10:17, Friday 19 December 2014 (15740)

All suspensions have been covered at this point. Please let me know if anyone experiences false reporting of status of suspensions in this view.

H1 ISC
daniel.hoak@LIGO.ORG - posted 00:51, Thursday 18 December 2014 - last comment - 10:50, Friday 19 December 2014(15706)
output gain stage on ASC-AS_C changed to accommodate shutter threshold

Dan, Fil, Thomas

We made a quick modification to the ASC-AS_C transimpedance board today, so that the HAM6 fast shutter threshold can be set for 1W of light into the chamber.  The modification was a swap of R23, from 1.24k ohm to 422 ohm.  This changes the gain on the SUM_OUT channel on the back of the chassis, that's used for the fast shutter logic.

ASC-AS_C gets 2.5% of the light into HAM6, so we'd like to set the threshold at 25mW.  The input to the shutter controller rails at 2V.  The QPD transimpedance is 1000 ohms, the quantum efficiency is probably about 80%, and the new resistor changes the final gain stage to 422/4.99k = 0.0845.  So, the correct shutter threshold is 0.025*1000*0.8*0.0845 = 1.7 volts.

This modification only affects the signal path to the shutter controller; it doesn't change the signal path that is acquired by the ASC front end.  So the ASC-AS_C sum that you see on the MEDM screen hasn't changed.  (The input to the HAM6 shutter controller is recorded by the channel H1:SYS-MOTION_C_SHUTTER_G_TRIGGER_VOLTS.)

Comments related to this report
rich.abbott@LIGO.ORG - 10:50, Friday 19 December 2014 (15742)
Something seems odd here.  The QPD amp single ended sum output (D1001974) is designed to accommodate the full design dynamic range of the QPD (10mA per quadrant)by use of the R3 = 1.24k and to produce 10V at the sum output during this full scale optical input.  The shutter controller (D1102312) photodiode input is a unity gain receiver, although for some bizarre reason, this design only operates on +5V for all the opamps.  The correct way to fix this dynamic range problem should have been by lowering R13 from 10k to 2k thus preserving best SNR on the QPD sum output.  Also, I see no mention of serial numbers here.  Hopefully the eTraveler's are being updated as this is the only way to track such changes at the board and chassis level.
H1 ISC
alexan.staley@LIGO.ORG - posted 20:27, Wednesday 10 December 2014 - last comment - 10:18, Friday 19 December 2014(15548)
Ringdown

Evan, Alexa

Following the preparation described in alog 15524, we made a ringdown measurement of both the x- and y-arm. For each arm, we locked the IR beam and ran the wfs to ensure maximum build up. We then turned the wfs off, and switched the input polarity of the MC common mode board to unlock the MC quickly (based on LLO's alog 11727 the MC has about a 15usec ringdown time). We used the relfected signal at the AS port to capture the ringdown. We repeated this measurement 10 times to have ample data for our uncertainities. We also measured the "off-resonance" ringdown, by unlocking the arm and misaligning the respective ETM. All the data can be found in /ligo/home/alexan.staley/Public/Ringdown/EX(Y)data (these folders are then split into locked and unlocked times).  From this data we calculated the total loss:

X arm: 14310(100) ppm

Y arm: 15000(100) ppm

Based on the galaxy ITMY transmissivity (1.42%) this amounts to 800ppm of loss in the y-arm. Meanwhile, for the x-arm, the ITMX transmissivity is 1.39 % corresponding to a 410ppm loss in the arm. We are in the process of calculating the transmissivity of the ITMs based on our ringdown fit. Our code can be found in /ligo/home/alexan.staley/Public/Ringdown/proccess.py. The y-arm losses seems consitent with our scan measurements; however the x arm does not. These numbers are very sensitive to the transmissivity we use; so before we make an conclusion with this we should inprove our confidence in the transmissivity values.

Comments related to this report
evan.hall@LIGO.ORG - 11:14, Thursday 11 December 2014 (15551)

I’ve attached the code, the data, and the plots in a zip file.

Also attached are a few representative plots with the arms locked and unlocked.

Also, Dave wants me to note that the inferred loss of 410 ppm in the X arm is probably wrong; we’ve just pulled the ITMX transmissivity from the galaxy website instead of extracting it from our data. This is in progress.

The time constant of the ringdown is half of the cavity storage time, and the cavity storage time is related to the arm reflectivities by an equation in Isogai (sec 4.3):

	au_{
m{s}} = frac{-1}{f_{
m{fsr}} ln(r_{
m{I}} r_{
m{E}})}

We've assumed that we know RE = 1 − 5×10−6.

Non-image files attached to this comment
evan.hall@LIGO.ORG - 11:06, Thursday 18 December 2014 (15683)

Here are the values for the ITM transmissivities, as inferred from the ringdown data.

In summary, to within experimental error there is no anomalous loss in the X arm. In the Y arm, the anomalous loss is 1330(370) ppm.

An updated version of the code is attached, along with a document giving the expression for TITM in terms of the measured quantities.

Here I've assumed RETM = 1, as was done in the paper by Isogai et al.

[Edit: Alexa has pointed out that we need to use m1 = RITM(P0+P1), rather than the original Isogai formula m1 = P0+P1, since we are using a PD in reflection. I've updated the table and the attachments accordingly. The ITM transmissivities change slightly and the extra losses go up a bit, but the conclusions remain the same.]

  X arm Y arm
m1 201(5) mV 153(5) mV
m2 70(13) mV 467(30) mV
m3 203(16) mV 114(12) mV
m4 1.863(13) ms 1.778(12) ms
ITM transmission, TITM 1.419(35) % 1.366(36) %
Total loss, L 14 310(100) ppm 14 990(100) ppm
L − TITM 120(360) ppm 1330(370) ppm
ITM transmission, TITM 1.425(35) % 1.37(4) %
Total loss, L 14 310(100) ppm 14 990(100) ppm
L − TITM 60(360) ppm 1290(410) ppm

For posterity, the old, incorrect values for the ITM transmissions were 1.425(35) % for X and 1.37(4) % for Y. The incorrect values for the extra losses were 60(360) ppm for X and 1290(410) ppm for Y.

Non-image files attached to this comment
garilynn.billingsley@LIGO.ORG - 10:18, Friday 19 December 2014 (15741)
Check the assumption on ETM transmission?  Our measurement is 3.6 ppm with a tolerance of 0.2 ppm for both LHO ETMs.  https://dcc.ligo.org/LIGO-E1300313
Displaying reports 61941-61960 of 77271.Go to page Start 3094 3095 3096 3097 3098 3099 3100 3101 3102 End