Displaying reports 67741-67760 of 77136.Go to page Start 3384 3385 3386 3387 3388 3389 3390 3391 3392 End
Reports until 18:47, Thursday 30 January 2014
H1 TCS (TCS)
aidan.brooks@LIGO.ORG - posted 18:47, Thursday 30 January 2014 - last comment - 10:22, Friday 31 January 2014(9687)
TCS HWS HAM4 optics and optic-mechanical placement completed

Aidan, Thomas, Eric G.

We installed the TCS HWS HAM4 optics this afternoon per D1201098. We've finished using that area and the chamber is covered again.

Full details tomorrow.

Comments related to this report
aidan.brooks@LIGO.ORG - 10:22, Friday 31 January 2014 (9703)TCS

Here are the full details ...

We had to place ten optics/opto-mechanics assemblies. The D1201098 installation kit (cookie cuters) parts were placed to facilitate placement and alignment of optic assemblies. The assemblies were then bolted into position, summarized below:

X-Arm Optics (see D1101083)

  • HWSX STEER M1 - 4" optic assembly installed without issue. This optic may need to be temporarily removed for the SR2 install - the dog clamps that are in-situ can be used to mark the position.
  • HWSX STEER M2 - 4" optic assembly installed without issue
  • HWSX STEER M3 - 2" optic assembly installed without issue
  • HWSX DCBS1 - we were missing 8/32 bolts for attaching the 2" lens mount to the top of this pedestal (D1101840). We opted to installed the pedestal anyway and leave the 2" lens mount off the table (perhaps 100g - 150g with lens) as the the mount can be attached in-situ.
  • HWSX VACLENS - we were missing 8/32 bolts for attaching the 2" lens mount to the top of this pedestal (D1101840). See HWSX DCBS1

Y-Arm Optics (see D1101084)

 

  • HWSY STEER M1 - 4" optic assembly installed without issue.
  • HWSY STEER M2 - 2" optic assembly installed. We held this cookie cutter into position with dog-clamps rather than through the slots.
  • HWSY DCBS1 - we were missing 8/32 bolts for attaching the 2" lens mount to the top of this pedestal (D1101840). See HWSX DCBS1
  • HWSY STEER M3 - 2" optic installed without issue
  • HWSY VACLENS - we were missing 8/32 bolts for attaching the 2" lens mount to the top of this pedestal (D1101840). See HWSX DCBS1

Photos are attached below. Complete set is on ResourceSpace

We plan on installing the 4x 2" lens mounts and optics during the alignment of these optics or earlier.

Images attached to this comment
H1 CDS
david.barker@LIGO.ORG - posted 18:16, Thursday 30 January 2014 - last comment - 23:51, Thursday 30 January 2014(9684)
ALS top named part added to ASC model, channels not named correctly by RCG
Daniel noticed that following his inclusion of an ALS top_named part in the h1asc model this morning, the channels were being incorrectly named at H1:ASC-ALS_ instead of the expected H1:ALS-. Jim, Cyrus and myself spent some time diagnosing the problem and found that the problem is raised if the second part comes before the main part (ASC) in alphabetical order. In other words ALS was not correctly identified as a top_named part but ATT was. It appears the problem may be in the post_built python script where the "top_names" block property is parsed. We did some diagnostics with the h1asc model, so there may be some strange MEDM screens lying around. We never did a "make install" so the INI file was not changed since this morning.
The investigation continues.
Comments related to this report
sheila.dwyer@LIGO.ORG - 23:51, Thursday 30 January 2014 (9697)

I did two make installs this morning, apologies if this caused probems. 

H1 CDS (SUS)
david.barker@LIGO.ORG - posted 18:11, Thursday 30 January 2014 (9683)
HWWD testing with +-24V
following Rolf's suggestion we test the HWWD units with +-24V instead of +-18V, we first reproduced the start up error on unit2 in the DTS with 18V. In five power up cycles the unit did not auto startup, the LED is red and the reset button needed to be pressed to continue the startup. We then powered with 24V and found the same results, five start, none auto started.
We then moved out 24V power supply to the CER and powered the unit attached to ITMY with 24V. Again we power cycled five times, once (20%) the system auto ran, four times (80%) it stuck at the red LED and needed a reset to continue.
Results indicate error is not fixed with increasing the power from 18V to 24V. The DTS unit is left off, the CER unit was returned to 18V.
H1 SEI
hugh.radkins@LIGO.ORG - posted 17:43, Thursday 30 January 2014 (9680)
WHAM4 HEPI Locked Down, ISI Optical Table Depopulated

After adjusting F-Clamps with one requiring replacement due to a galling set screw, we locked up the HEPI.  Following that all the Optical dummy masses were removed and bagged, now ready for HAM5.  We finished about 1150pst.  Thanks to the Apollo crew Mark & Scott.

H1 ISC
alexan.staley@LIGO.ORG - posted 17:38, Thursday 30 January 2014 (9679)
MC Cavity Length Measurement

I measured the MC cavity lock by adjusting the ifr frequency and measuring the transfer functions using an SR785. The source was injected into Exc A of MC common mode board and teed to ch1, meanwhile ch2 was connected to either IMON of REFL9 (1*FSR) and REFL45 (5*FSR). Data.txt is the data collected from REFL9 and Data_2.txt is that collected from REFL45. ArmCavityLength.m is the script that determines the length given the zero crossing of the projection. The attached plots show the results with a linear regression included.

 

The cavity length is determined to  be

Non-image files attached to this report
H1 SEI
filiberto.clara@LIGO.ORG - posted 16:28, Thursday 30 January 2014 - last comment - 18:29, Thursday 30 January 2014(9675)
SEI CPS Timing Distribution System - BSC1, BSC2, and BSC3
Implemented the new timing distribution system for the CPS's units (BSC's only) in the LVEA. Changes include using BSC2 CPS_1 unit as master. The timing signal is feed to a STS-2 Distribution chassis and distributed to all other CPS units. The STS-2 Distribution Chassis was placed in SUS-R6 floor rack.
Comments related to this report
arnaud.pele@LIGO.ORG - 18:29, Thursday 30 January 2014 (9685)

Attached is a spectra of ITMX ST2 GS13 took after the timing system was changed (in blue), and compared with the reference from Seb's alog 9537 from last week (in yellow). Clearly, the combs do not appear any more.

Non-image files attached to this comment
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
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
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.
Displaying reports 67741-67760 of 77136.Go to page Start 3384 3385 3386 3387 3388 3389 3390 3391 3392 End