Displaying reports 76581-76600 of 85965.Go to page Start 3826 3827 3828 3829 3830 3831 3832 3833 3834 End
Reports until 16:19, Thursday 30 January 2014
H1 ISC
stefan.ballmer@LIGO.ORG - posted 16:19, Thursday 30 January 2014 (9674)
The machine was talking to us

Repeatedly in the past we had found the ISS PD's DC level jump to a state past 10Volts to somewhere arount 12V. The last time this occured last night (alog 9637). Staring at the PSL ODC screen, it told us that two things were wrong: BIT7 "ISS actuation saturation" and BIT11 "NPRO Relaxation Oscillation" were red.

Last night we fixed the ISS actuation saturation by readjusting the set point, but the PDs remaind in the odd 12V state.

Staring at the ODC screen this morning, BIT11 "NPRO Relaxation Oscillation" remained red. Taking that suggestion by ODC seriously, I went out to toggle the NPRO noise eater. Sure enough - the the ISS PD's switched back to the normal "<10V" state, and BIT11 went green.

Conclusions:

- Our long-standing ISS PD mystery is caused by noise eater oscillations.

- The PSL ODC system correctly announced this problem.

FYI, The ODC overview screen is available from the SYS tab on the site overview, and has links to all subsystem screens. The subsystem screens have a description string for each bit. Currently fully operational -including meaningful thresholds -are PSL, IMC, ISI and HPI for all currently commissioned systems, as well as SUS for MC1, MC2 and MC3. (All SUS's have a working ODC system installed, but the good settings are still a moving target due to commissioning.

I put the ODC master screen on video5. Due to the many not yet commissioned systems, there is still a lot of red there. In the attached plot, there is even more red due to the ongoing IMC length measurement. (stay tuned)

 

Related previous alogs:

alog 9637

alog 7077

Images attached to this report
H1 AOS (PEM)
corey.gray@LIGO.ORG - posted 15:25, Thursday 30 January 2014 (9673)
Dust Monitor#9 Being Moved to HAM4

Richard & company are moving this Dust Monitor to HAM4 (since it's an open chamber).  Still working on bringing it online (it's been INVALID).

H1 DAQ
corey.gray@LIGO.ORG - posted 15:23, Thursday 30 January 2014 (9672)
"Non-Invasive" Work at ITM Rack AT 3:13 - 3:21

This was Dave & Jim doing work with the hardware watchdogs and they said it shouldn't have affected anybody.

H1 ISC
kiwamu.izumi@LIGO.ORG - posted 15:09, Thursday 30 January 2014 - last comment - 00:30, Friday 15 January 2016(9630)
REFLAIR and POPAIR PD chain check

I have been silently checking the signal chain of the REFLAIR and POPAIR RFPDs using the AM laser (a.k.a. PD calibrator) to make sure that they are functional expectedly.

Summary

The RF frequency of the AM modulation was adjusted in each measurement such that the demodulated IF signal was below 50 Hz.


Calibration of the amplitude modulation depth

We recalibrated the AM laser.

The current setting of the laser was changed recently because we opened up the current driver when we thought the laser diode had been dead in the early December. Then the laser head and its current driver were sent to Rich at Caltech for his extensive testing although the laser magically fixed itself and he didn't find anything wrong. So this was the first time for us to use the AM laser which had been fixed. Because of that mysterious event, I wanted to recalibrate the laser. First of all, Yuta and I measured the power to be 2 mW with an Ophir Vega without the attenuation filter. Then we measured the modulation depth for the amplitude modulation by using a Newfocus 1611 as a reference.

The new calibration for the amplitude modulation is:

P_am =  5.13 mW x (P_dc / 1 mW) * (1 V / V_drive)

where P_dc is the laser power at DC and V_drive is the drive voltage when it is driven by a 50 Ohm source. For example, if one puts this laser to a PD which then shows a DC laser power of say 2 mW, the AM coefficient is now 5.13 mW x ( 2 mW / 1 mW) /V_drive = 10.26 mW/V_drive.


REFLAIR_A_RF9 (S1203919)

Remarks:

The signal chain is OK. The PD response is smaller by 15% for some reason.

It seems as if the transimpedance is smaller by 15% than what had been measured at Caltech (LIGO-S1203919). The cable loss from the RFPD to the rack was measured to be 0.47 dB. Be aware that the demod gain is half of the quad I/Q demodulator because this is a dual channel demod (see E1100044). The demod conversion gain is assumed to be 10.9 according to LIGO-F1100004-v4.


REFLAIR_A_RF45 (S1203919)

Remarks:

The signal chain is healthy.

Found cable loss of about 1.5 dB. The measurements excellently agree with the loss-included expectation.


POPAIR_A_RF9 (S1300521)

Remarks:

The signal chain is healthy.

The measurement suggests that there is loss of 1 dB somewhere. I didn't measure the cable loss this time.


POPAIR_A_RF45 (S1300521)

Remarks:

The signal chain is OK. Though loss sounds a bit too high.

The measurement suggests a possible loss of 2.6 dB somewhere. I didn't measure the cable loss.


REFLAIR_B_RF27 (S1200234)

Remarks:

The signal gain is bigger than the expectation by a factor of 2.3.


REFLAIR_B_RF135 (S1200234)

Remarks:

The signal gain is bigger than the expectation by a factor of 1.5


POPAIR_B_RF18 (S1200236)

Remarks:

The signal gain is bigger than the expectation by a factor of 2.3


POPAIR_B_RF90 (S1200236)

Remarks:

The signal gain matches with the expected value, but I don't believe this.

Comments related to this report
kiwamu.izumi@LIGO.ORG - 17:16, Thursday 30 January 2014 (9678)

There was a typo:

P_am =  5.13 mW x (P_dc / 1 mW) * (1 V / V_drive)

P_am = 5.13 mW x (P_dc / 1 mW) x (V_drive / 1 V)

koji.arai@LIGO.ORG - 18:38, Thursday 30 January 2014 (9686)

For 27MHz and 136.5MHz, the RF gains are +19.8dB and +50.7dB, respectively. S1400079

 

daniel.sigg@LIGO.ORG - 22:46, Thursday 30 January 2014 (9696)

The response of the BBPD isn't really flat over all frequencies. See D1002969.

koji.arai@LIGO.ORG - 12:59, Friday 31 January 2014 (9719)

The description in D1002969 is for the initial version. (The schematics seems up-to-date.)

The latest version has the rf performance as attached.

Non-image files attached to this comment
kiwamu.izumi@LIGO.ORG - 13:11, Wednesday 05 February 2014 (9845)

This is a follow up of the calibration measurements for REFLAIR_B and POPAIR_B.

I have updated the expected signal gain for these photo detector chains using more realistic gains which Koji gave (see his comments above). Now all the values make sense. Note I did not perform any new measurements.

In the following calculations, the quantity in red represent the updated parameters.

 


REFLAIR_B_RF27(S1200234)

Remarks:

The signal chain is healthy. There is loss of 0.92 dB somewhere.

  • Expected AM at 27 MHz = 5.13 mW x (1.045 mW / 1 mW) x 0.05 V_drivepp x 0.4 A/W x 2.1 kOhm = 225 mVpp
  • Expected ADC counts = 19.8dB (S1400079-v1) x 225 mVpp x 10.9 x 2^16/40 counts/V = 39294 counts pp
  • Measured ADC counts = 35431 counts pp
    • The signal is smaller by 0.92 dB than the expected.

REFLAIR_B_RF135(S1200234)

Remarks:

The signal chain is OK. There is loss of 3.9 dB somewhere.

  • Expected AM at 135 MHz = 5.13 mW x (1.045 mW / 1 mW) x 0.0014 V_drivepp x 0.4 A/W x 1 kOhm = 3 mVpp
  • Expected ADC counts = 50.7 dB (S1400079-v1) x 3 mVpp x 10.9 x 2^16/40 counts/V = 18377 counts pp
  • Measured ADC counts = 11689 counts pp
    • The signal is smaller by 3.9 dB than the expected.

POPAIR_B_RF18 (S1200236)

Remarks:

The signal chain is healthy. The signal was bigger by 9% than the expected.

  • Expected AM at 18 MHz = 5.13 mW x (0.93 mW / 1 mW) x 0.1 V_drivepp x 0.4 A/W x 2.1 kOhm = 401 mVpp
  • Expected ADC counts = 401 mVpp x 10.9 x 2^16/40 counts /V = 7157 counts pp
  • Measured ADC counts = 7803 counts pp
    • The signal is greater by 9 % than the expected.

POPAIR_B_RF90 (S1200236)

Remarks:

The signal chain is healthy. There is loss of 1.2 dB somewhere.

  • Expected AM at 90 MHz = 5.13 mW x (0.93 mW / 1 mW) x 0.1 V_drivepp x 0.4 A/W x 1.2 kOhm = 229 mVpp
  • Expected ADC counts = 229 mVpp x 10.9 x 2^16/40 counts/V = 4090 counts pp
  • Measured ADC counts = 3549 counts pp
    • This is smaller than the expected by 1.2 dB
evan.hall@LIGO.ORG - 14:08, Wednesday 06 January 2016 (24728)

From these measurements, we can use POPAIR to infer the calibration for POP.

I looked at a recent lock acquisition while the interferometer was trying to engage the outer ISS loop. The LSC is relatively stable during this time, and the POP beam diverter is still open.

After undoing whitening gain and digital gain (2 ct/ct for POPAIR9/45, and 32 ct/ct for POP9/45), we find the following TFs:

  • POP9I/POPAIR9I = 0.19 ct/ct
  • POP45Q/POPAIR45Q = 0.21 ct/ct

This implies calibrations of 1.7×106 ct/W for POP9 and 1.8×106 ct/W for POP45.

Images attached to this comment
evan.hall@LIGO.ORG - 00:30, Friday 15 January 2016 (24959)

There's a factor of 4 difference in power between POP and POPAIR (17 mW versus 68 mW with a PSL power of 23 W), so the values I gave above are off by a factor of 4. The demod gains should be 6.4×106 ct/W for POP9 and 7.2×106 ct/W for POP45.

H1 IOO
laura.nuttall@LIGO.ORG - posted 14:43, Thursday 30 January 2014 - last comment - 18:58, Thursday 30 January 2014(9671)
IMC ODC summary bit red for the last 21 hrs
I've attached a plot showing that the IMC has 'not been in a good state' (i.e. red) for the last 21 hours due to the ASC control switch not being on (summary bit 1). I can't see anything obvious in the alogs to determine why this is, anyone know? Thanks
Images attached to this report
Comments related to this report
kiwamu.izumi@LIGO.ORG - 16:59, Thursday 30 January 2014 (9677)

The IMC WFS was off for approximately 8 hrs from Jan-30 01:50 to Jan-30 10:03 in UTC and it have been up in the rest of the time in the past two days. Probably it is because of the master gain which was lowered to 0.25 for some reason yesterday.

stefan.ballmer@LIGO.ORG - 16:35, Thursday 30 January 2014 (9676)
I suspect that this was caused by the NPRO relaxation oscillation, see alog 9674. Laura, can you produce the same plot for the PSL ODC channel for the same time segment, as well as check weather this is fixed now? (You will have to exclude the afternoon, as people have actively been working on the mode cleaner.)
laura.nuttall@LIGO.ORG - 18:58, Thursday 30 January 2014 (9688)
I've had a look at the last four hours and the IMC ODC is still red for the same reason (see first attached plot), but the PSL is looking green (2nd plot). I'm currently trying to make the PSL ODC plot for the last day but it's taking some time, so as soon as I have them I'll post it. But if this is to do with the NPRO relaxation oscillation (alog 9674) which Stefan reported turned the PSL ODC green it has not affected the IMC ODC. 
Images attached to this comment
H1 ISC
keita.kawabe@LIGO.ORG - posted 14:28, Thursday 30 January 2014 - last comment - 08:13, Friday 31 January 2014(9653)
ETM and ITM pitch VS locking to 00

(Correction Jan/31: Sheila's made a similar plot for a period (https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=9691) where the cavity was locked all the time, and it seems like the plot presented here was sampling only a small edge of the 00 lock range.)


As of now, it seems like both ETM and ITM should be within 0.3 urad pk-pk from the optimal alignment to stay locked on 00 mode.

Plot 1: I took OL and green transmission data for 5 minutes when the cavity was going back and forth between 00 and 01 mostly without losing lock.

In the top panel, the transmission time series is actually the sum of the SHG and the transmission, but it's on 00 mode when it was 1400 counts, 01 when it was between 1000 and 1200 counts.

Plot 2: 2D color map of the above data.

X axis is ITM OL PIT, Y is ETM. I arbitrary set the threshold of 1300 counts for green transmission and subtracted that from the transmission data, and set the color map such that orange-red color is above 0 (i.e. locked to 00 mode), yellow-green is negative  (01 mode).

Each cell is normalized by the number of data points in that cell. Blue means there's no data point in that cell.

Sorry that X and Y axis scaling is different. To aid your eyes, I put white and pink diagonal lines showing the direction of common (soft) and differential (hard) misalignment.

Plot 3: 2D plot of where the OLs were staying.

You cannot tell from plot 2 where the OL was staying the most, so here is the number of data points in each cell divided by the total number of data points. Adding everything on this map together you'll get 1.

On average EX=-28.12, IX=-6.28.

Conclusion:

  1. Thin band on 00 mode area, elongated along the white (soft or common) line,  shows that the problem is along the pink line (differential or hard) due to cavity geometry discussed before by people.
  2. In order to stay locked on 00, both ITM and ETM should be within 0.3 urad pk-pk or somethibng, otherwise you'll drop out of the locking range along the pink line.
  3. The DC alignment was not optimal despite dither alignment. [ITMX, ETMX] could have been centered around [-6.4, -27.2 urad] (instead of [-6.28, -28.12]). Not sure what to make out of this, as the dither servo was going on and off each one second.
  4. A factor of 2 or 3 improvement will make ITM great, but ETM needs more (but note that the data was when it was bad).

Note that this is dependent on RF sideband frequency.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 08:13, Friday 31 January 2014 (9699)

Note the bogus or inconsistent sign convention of OLs.

For ETM, when the optic tilts down (increase in PIT slider), OL PIT increases, while for ITM OL PIT decreases.

That's the reason why the hard (differential) mode is parallel to the line ETMX=ITMX.

LHO General
patrick.thomas@LIGO.ORG - posted 13:46, Thursday 30 January 2014 - last comment - 14:03, Thursday 30 January 2014(9667)
Apollo flying crane over X arm in LVEA


			
			
Comments related to this report
patrick.thomas@LIGO.ORG - 14:03, Thursday 30 January 2014 (9668)
Done
H1 SEI
patrick.thomas@LIGO.ORG - posted 13:42, Thursday 30 January 2014 (9666)
Richard and Filiberto working near LVEA BSC chambers (WP 4417)


			
			
LHO General
patrick.thomas@LIGO.ORG - posted 13:39, Thursday 30 January 2014 (9665)
Fire Systems Maintenance to look at fire hydrant leak


			
			
LHO General
patrick.thomas@LIGO.ORG - posted 13:38, Thursday 30 January 2014 - last comment - 14:24, Thursday 30 January 2014(9664)
Jeff and Andres working near HAM4


			
			
Comments related to this report
patrick.thomas@LIGO.ORG - 14:24, Thursday 30 January 2014 (9670)
Done
LHO General
patrick.thomas@LIGO.ORG - posted 13:31, Thursday 30 January 2014 (9663)
Betsy getting box of parts from LVEA


			
			
H1 TCS
patrick.thomas@LIGO.ORG - posted 13:20, Thursday 30 January 2014 - last comment - 14:04, Thursday 30 January 2014(9662)
Aidan working on TCS in HAM4


			
			
Comments related to this report
patrick.thomas@LIGO.ORG - 14:04, Thursday 30 January 2014 (9669)
Starting work.
H1 SUS (SUS)
betsy.weaver@LIGO.ORG - posted 13:10, Thursday 30 January 2014 (9661)
SUS and more TMS Ground Checks on ETMy cartridge

This morning Filiberto, Travis and I made grounding checks of the SUS cables on the ISI.  We also check a few of the TMS cables that were easy to access near our bundle.  Coery checked some prior as well.  Long story short, we only found 1 cable route that has a ground issue and it is on a TMS segment that runs to BOSEMs.  It is the connection with the D100225-S1104782 cable in it.  This cable has been through testing, so likely we can find and remedy this ground.  Coery said he'll add it to the TMS hit-list.

H1 SUS
betsy.weaver@LIGO.ORG - posted 12:01, Thursday 30 January 2014 - last comment - 14:07, Friday 31 January 2014(9658)
Ring Heater in line of fire during welding

We've observed some burn marks on the shielding of the ETMy ring heater cables which occured sometime during the 3 prior weld sessions (May 2012, Dec 2013, Jan 2014).  The burns are on the lowest ring heater cable that laces around the test mass and makes a connection between the test mass and the PUM.  There is a burn on the right segment and the left segment.  I dug up a picture that shows that the burn on the "right" segment (as viewed from the back of the suspension) was there just after the May 2012 weld session, so that one is not new.  However the "left" cable burn is new from the Dec or Jan welding.  We did not see when this actually occured.

Filiberto tested the ring heater cable and found that all pins are operating as per spec, although he thinks pin 1 is shorting.  We are tracking down what this means (did we test it correctly, when was it last tested, is it possible that the burn is contributing to the short, even though it does not look like it is, etc.).

Comments related to this report
betsy.weaver@LIGO.ORG - 12:03, Thursday 30 January 2014 (9659)

This is the picture of the RH "right" cable taken in May 2012.

Images attached to this comment
betsy.weaver@LIGO.ORG - 12:11, Thursday 30 January 2014 (9660)

And here is the "left" RH segment burn which happened in the Dec or Jan weld.

Images attached to this comment
filiberto.clara@LIGO.ORG - 14:07, Friday 31 January 2014 (9723)
For the ring heater cable, the following pins were tested.

Pins 2,3,4, and 5 are tied together.
Pins 14,15,16, and 17 are tied together.
The resistance between these two sets is 47.5 ohms.

Pins 8,9,10, and 11 are tied together.
Pins 20, 21, 22, and 23 are tied together.
The resistance between these two sets is 45.9 ohms.

Pin 1 is tied to shield and shorted to ground.

Filiberto Clara 
H1 IOO
paul.fulda@LIGO.ORG - posted 10:43, Thursday 30 January 2014 - last comment - 11:24, Thursday 30 January 2014(9652)
Making REFL beam size measurements on ISCT1

I'm making a measurement of the ITMX direct reflected beam size on ISCT1. PRM is misaligned, sending the beam to the parking dump for this mesurement. Please do not align PRM as this will make the REFL beam too powerful for the beam analyzer and may fry it.

Comments related to this report
paul.fulda@LIGO.ORG - 11:24, Thursday 30 January 2014 (9657)

I'm done for now making measurements with PRM misaligned. I'll realign PRM now and measure the PRM direct reflected beam

Displaying reports 76581-76600 of 85965.Go to page Start 3826 3827 3828 3829 3830 3831 3832 3833 3834 End