40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 63 of 341 Not logged in
ID Date Author Type Category Subject
12175   Tue Jun 14 11:29:25 2016 JohannesSummaryASCYArm OpLev Calibration

In preparation for the armloss map I checked the calibration of the Y-Arm ITM and ETM OpLevs with the method originally described in https://nodus.ligo.caltech.edu:8081/40m/1247. I was getting a little confused about the math though, so I attached a document at the end of this post in which I work it out for myself and posteriority. Stepping through an introduced offset in the control filter for the corresponding degree of freedom, I recorded the change in transmitted power and the reading of the OpLev channel with the current calibration. One thing I noticed is that the calibration for ITM PIT is inverted with respect to the others. This can of course be compensated at any point in any readout/feedback chain, but it might be nice to establish some sort of convention where positive feedback to the mirror will increase the OpLev reading.

The calibration factors I get are within ~10% of the currently stored values. The table (still incomplete, need to relate to the current values) summarizes the results:

Mirror DoF Current Relative New
Y-Arm OpLev Calibration
ETM PIT   0.974 ± 0.029
YAW   1.077 ± 0.021
ITM PIT   -0.972 ± 0.020
YAW   0.920 ± 0.048

The individual graphs:

## ITM YAW

The math:

Attachment 1: CavityCoupling.pdf
12223   Tue Jun 28 20:43:23 2016 KojiSummaryCOCFirst Contact cleaning practice

Made a dry run of the in-situ cleaning for a 3inch optic.

Attachment 1: The Al dummy mass is clamped in the suspension cage.
Attachment 2: The front surface was painted. The nominal brush with the FC bottle was used.
Attachment 3: Zoom in of the front surface.
Attachment 4: The back surface was painted.
Attachment 5: The back surface was peeled.
Attachment 6: The front surface was peeled too.
Attachment 7: The peeled layers.

Findings:

1. To paint a thick layer (particlarly on the rim) is the key to peel it nicely.

2. It was helpful for easier peeling to have mutiple peek tabs. Two tabs were sufficient for ~1" circle.

3. The nominal brush with the bottle was OK although one has to apply the liquid many times to cover such a large area. A larger brush may cause dripping.

4. The nominal brush was sufficiently long once the OSEMs are removed. In any case it is better to remove the OSEMs.

Attachment 1: IMG_20160628_170335196.jpg
Attachment 2: IMG_20160628_171547769.jpg
Attachment 3: IMG_20160628_171607802.jpg
Attachment 4: IMG_20160628_172328190.jpg
Attachment 5: IMG_20160628_174541960.jpg
Attachment 6: IMG_20160628_174556004.jpg
Attachment 7: IMG_20160628_174617198.jpg
12239   Fri Jul 1 17:51:28 2016 PrafulSummaryElectronicsReplacing DIMM on Optimus

There has been an ongoing memory error in optimus with the following messages:

controls@optimus|~ >
Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705127] [Hardware Error]: Corrected error, no action required.

Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705174] [Hardware Error]: CPU:24 (10:4:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc04410032080a13

Message from syslogd@optimus at Jun 30 14:57:48 ...

Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705264] [Hardware Error]: MC4 Error (node 6): DRAM ECC error detected on the NB.

Message from syslogd@optimus at Jun 30 14:57:48 ...
kernel:[1292439.705323] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)

Optimus is a Sun Fire X4600 M2 Split-Plane server. Based on this message, the issue seems to be in memory controller (MC) 6, chip set row (csrow) 7, channel 0. I got this same result again after installing edac-utils and running edac-util -v, which gave me:

mc6: csrow7: mc#6csrow#7channel#0: 287 Corrected Errors

and said that all other DIMMs were working fine with 0 errors. Each MC has 4 csrows numbered 4-7. I shut off optimus and checked inside and found that it consists of 8 CPU slots lined up horizontally, each with 4 DIMMs stacked vertically and 4 empty DIMM slots beneath. I'm thinking that each of the 8 CPU slots has its own memory controller (0-7) and that the csrow corresponds to the position in the vertical stack, with csrow 7 being the topmost DIMM in the stack. This would mean that MC 6, csrow 7 would be the 7th memory controller, topmost DIMM. The channel would then correspond to which one of the DIMMs in the pair is faulty although if the DIMM was replaced, both channels 0 and 1 would be switched out. Here are some sources that I used:

http://docs.oracle.com/cd/E19121-01/sf.x4600/819-4342-18/html/z40007f01291423.html#i1287456

http://martinstumpf.com/how-to-diagnose-memory-errors-on-amd-x86_64-using-edac/

I'll find the exact part needed to replace soon.

12306   Fri Jul 15 17:44:37 2016 AakashSummaryGeneralAcromag Setup | SURF2016

Aidan has described the physical connections and initial setup here :  https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php?id=main:resources:computing:acromag#recovering_from_a_terminal_power_communication_outage  .

Since I used a Raspberry Pi(domenica.martian) for communicating to Acromag(acroey.martian) card, I had to recompile everything for linux-arm architecture.

Put all the files mentioned by Aidan and run a tmux session to grab channels.

Also, pyModbus can be used to read the channels. I'll put the physical connections schematic shortly.

12337   Tue Jul 26 14:24:38 2016 KojiSummaryVACPurge compressed air system at LHO

I've visited the purge clean air system at LHO Yarm mid-station with John Worden.

The system is described C981637. There is a schematic in C981637-06-V (Vol.6).pdf although the schematic has some differences (or uncorrected mistakes).

This system is intended to provide positive pressure when a soft cover is attached to a chamber door. When the door is open, the purging does not help to keep the chamber clean because the flow is too slow. This protection has to be done with overhead HEPA filters (22x5000cfm). It may be possible that this purge air helps the tube not to allow dusts to come in. But before using this, the chambers and the tubes have to be cleaned, according to John.

- Here at the site, the purge air system is started up a day before the vent. This system is used for the vent air, the purge air, and turbo foreline filling.

- Air intake (attachment 1): At the site, the air is intaken from the VEA. We want to incorporate somewhat clean air instead of dirty, dusty, outside air.

- Initial filter (attachment 2): a high volume filter before the compressors.

- The compressors (attachment 3, 4) are 5x 6 horse power air compressor each goes up to 160 psi. They are turned on and off depending on the demand of the air. Which is turned on is revolved by the controller to equalize the compressor usage hours.

- The compressed air goes through the air cooler (heat exchanger) to remove the heat by the compressor work.

- This air goes through prefilters and accumulated in the air receiver (100psi) (attachment 5). This receiver tank has an automated vent valve for periodical water drainage at the bottom.

- The accumulated air is discharged to twin drier towers (attachment 6, blue). The tower is operated by the controller (attachment 7) alternately with a period of 4min (or 10min by setting). When one of the towers is working, a humid air comes from the bottom and the dry air is discharged from the top. A part of the dry air goes into the other tower from the top to the bottom and dries the tower. There is a vent at the bottom to discharge water periodically.

- The dried air goes through 4 types of filters. After the last filter, all of the plumbing should be made of stainless steel to keep cleanliness.

- The air goes to the pressure reducing regulator (attachment 8, gray). The final flow speed at the chamber side is 50cfm max, according to John.

- The lower pressure air goes through the final filter (attachment 8, blue). As the pressure is low, this filter is big in order to keep the volume of the air flow.

- The purge air is supplied to the chamber side with KF50 (attachment 9). There is a vent valve (attachment 10) for safety and also to run a dry air for at least a day before the use to clean up the supply line. The purge line is disconnected when no in use.

- The entire system (attachment 11) and size comparison (attachment 12).

Attachment 1: air_intake.jpg
Attachment 2: initial_filter.jpg
Attachment 3: compressors1.jpg
Attachment 4: compressors2.jpg
Attachment 6: drier.jpg
Attachment 7: drier_controller2.jpg
Attachment 8: pressure_regulator_and_last_filter.jpg
Attachment 9: chamber_side_supply.jpg
Attachment 10: vent_valve_for_line_cleaning.jpg
Attachment 11: the_whole_system.jpg
Attachment 12: size_comparison.jpg
12338   Tue Jul 26 16:01:32 2016 SteveSummaryVACPurge compressed air system

Thanks for checking this out Koji

The builder in 1996 was Process System International, Inc ( Westborough, MA ) It does not exist any longer or I just could not find them. Flow diagramm at Atm1

Should I be keep looking for a company who could quote us for building a similar smaller unit with 10 - 15 cfm flowrate?

Note: my intension with the two mobile-overhead HEPA filter was the same as John Worden's " clean air overpressured tent " at chamber entrance.

Atm2, Our unit has 650 cfm, velocity 90 fpm at resistance 0.5"    It may be enough to give a little overpressure if we seal it well to the chamber

We use to use them to minimize dirt getting inside the chanbers.

Attachment 1: cleanAirSupl.pdf
Attachment 2: mobileHEPA.jpg
12339   Tue Jul 26 17:41:59 2016 KojiSummaryVACPurge compressed air system

We have no number for the CFM without calculation. We can't assume a random number like 10-15

12341   Wed Jul 27 11:40:48 2016 steveSummarySUSoplev laser summary updated

Quote:

Quote:

Quote:

 Quote: 2005              ALL oplev servos use Coherent DIODE LASERS # 31-0425-000, 670 nm, 1 mW     Sep. 28, 2006              optical lever noise budget with DC readout in 40m,  LIGO- T060234-00-R, Reinecke & Rana     May  22, 2007              BS, SRM & PRM  He Ne 1103P takes over from diode     May  29, 2007              low RIN He Ne JDSU 1103P selected, 5 purchased sn: T8078254, T8078256, T8078257, T8078258 & T8077178 in Sep. 2007     Nov  30, 2007               Uniphase 1103P divergence measured     Nov. 30, 2007               ETMX old Uniphase 1103P  from 2002 dies: .............., running time not known......~3-5 years?     May 19, 2008               ETMY old Uniphase 1103P from 1999 dies;.....................running time not known.....~    ?     Oct.  2, 2008                ITMX & ITMY are still diodes, meaning others are converted to 1103P earlier                        JDSU 1103P were replaced as follows:    May 11, 2011                ETMX replaced, life time 1,258 days  or 3.4 years    May 13, 2014               ETMX , LT 1,098 days or 3 y    May 22, 2012               ETMY,  LT 1,464 days or  4 y    Oct.  5, 2011                BS & PRM, LT 4 years,  laser in place at 1,037 days or 2.8 y    Sep. 13, 2011               ITMY  old 1103P &    SRM    diode laser replaced by 1125P  ..........old He life time is not known, 1125P in place 1,059 days or 2.9 y    June 26, 2013              ITMX 622 days or 1.7 y    note: we changed because of beam quality.........................laser in place 420 days or 1.2 y     Sep. 27, 2013               purchased 3 JDSU 1103P lasers, sn: P893516, P893518, P893519 ......2 spares ( also 2 spares of 1125P of 5 mW & larger body )

May  13, 2014             ETMX,  .............laser in place 90 d

May  22, 2012             ETMY,

Oct.  7,  2013             ETMY,  LT  503 d  or  1.4 y............bad beam quality ?

Aug. 8,  2014              ETMY,  .............laser in place   425 days  or  1.2 y

Sept. 5, 2014              new 1103P, sn P893516  installed at SP table for aLIGO oplev use qualification

May 23, 2016             ITMX dead laser sn P845648 replaced after 1062 days [2.9 yrs] by 1103P, sn P859884, with output output  2.6 mW, nicely round beam quality at 15 meters.

July 27, 2016             2  new 1103P from Edmonds in: P947034 & P947039, manf. date April 2016,

12352   Fri Jul 29 03:44:04 2016 AakashSummary About Acromag | SURF 2016

I tried to recompile the modbusApp binary for linux-arm acrhitecture since I suspected someting wrong with it. But still the problem persists; I can connect to acromag but cannot access the channels. I have also reconfigured new acromag bus works terminal XT 1221-000 and I want to test if I could access its channels. My target is to complete this acromag setup work before sunday morning so that I can focus towards having some useful results for my presentation.

12365   Wed Aug 3 14:52:37 2016 SteveSummaryPEMGuralps as connected

Guralps as connected with pictures

12534   Wed Oct 5 19:43:13 2016 gautamSummaryGeneralVent review

This elog is meant to review some of the important changes made during the vent this summer - please add to this if I've forgotten something important. I will be adding this to the wiki page for a more permanent record shortly.

Vent objectives:

1. Clean ITMX, ITMY, ETMX, ETMY
2. Replace ETMX suspension cage, replace Al wire standoffs with Ruby (sapphire?) standoffs.
3. Shorten Y arm length by 20mm
4. Replace 40mm aperture baffles in ETM chambers with 50mm black glass baffles

Optics, OSEM and suspension status:

ITMX & ITMY

• ITMX and ITMY did not have any magnets broken off during the vent - all five OSEM coils for both were removed and the optic EQ stopped for F.C. cleaning.
• Both HR and AR faces were F.Ced, ~20mm dia area cleaned.
• The coils were re-inserted in an orientation as close to the original (as judged from photos), and the shadow sensor outputs were made as close to half their open values as possible, although in the process of aligning the arms, this may have changed
• OSEM filter existense was checked (to be updated)
• Shadow sensor open values were recorded (to be updated)
• Checked that tables were level before closing up
• The UL OSEM on ITMY was swapped for a short OSEM while investigating glitchy shadow sensor outputs. This made no difference. However, the original OSEM wasn't replaced. Short OSEM was used as we only had spare short OSEMs. Serial number (S/N 228) and open voltage value have been recorded, wiki page will be updated. Does this have something to do with the input matrix diagonalization weirdness we have been seeing recently?
• ITMX seems to be prone to getting stuck recently, reason unknown although I did notice the LL OSEM was kind of close to the magnet while inserting (but this magnet is not the one getting stuck, as we can see this clearly on the camera - the prime suspect is UL I believe)
• OL beam centering on in vacuum steering optics checked before closing up

ETMY

• UL, UR and LR magents broke off at various points, and so have been reglued
• No standoff replacement was done
• Re-suspension was done using newly arrived SOS wire
• Original OSEMs were inserted, orientations have changed somewhat from their previous configuration as we did considerable experimentation with the B-R peak minimization for this optic
• OSEM filter status, shadow sensor open voltage values to be updated.
• New wire suspension clamp made at machine shop is used, 5 in lb of torque used to tighten the clamp
• HR face cleaned with F.C.
• Optic + suspension towers air baked (separately) at 34C for curing of EP30
• Checked that tables were level before closing up
• 40mm O.D. black glass baffle replaced with 50mm O.D. baffle.
• Suspension cage was moved towards ITMY by 19mm (measured using a metal spacer) by sliding along stop marking the position of the tower.

ETMX

• Al wire standoffs <--> Ruby wire standoffs (this has changed the pitch frequency)
• All magnets were knocked off at some point, but were successfully reglued
• New SOS tower, new SOS wire, new wire clamp used
• OSEM filter status, shadow sensor open voltage values to be updated.
• OSEM orientation is close to horizontal for all 5 OSEMs
• Table leveling was checked before closing up.
• 40mm O.D. black glass baffle replaced with 50mm O.D. baffle.\

PRM

• Some issues with the OSEMs were noticed, and were traced down to the Al foil caps covering the back of the (short) OSEMs, which are there to minimize the scattererd 1064nm light interfering with the shadow sensor, shorting one of the OSEMs
• To mitigate this, all Al foil caps now have a thin piece of Kapton between foil and electrical contacts on rear of OSEM
• No OSEMs were removed from the suspension cage during this process, we tried to be as gentle as possible and don't believe the shadow sensor values changed during this work, suggesting we didn't disturb the coils (PRM wasn't EQ stopped either)

SRM

• The optic itself wasn't directly touched during the vent - but was EQ stopped as work was being done on ITMY
• It initially was NOT EQ stopped, and the shift in table level caused by moving ITMY cage to the edge of the table for F.C. cleaning caused the optic to naturally drift onto the EQ stops, leading to some confusion as to what happened to the shadow sensor outputs
• The problem was diagnosed and restoring ITMY to its original position made the OSEM signals come back to normal.

SR3

• Was cleaned by drag wiping both front and back faces

SR2/PR2/PR3/BS/OMs

• These optics were NOT intentionally touched during this vent
• The alignment on the OMs was not checked before close-up

Other checks/changes

• OL beams were checked on in-vacuum input and output steering mirrors to make sure none were close to clipping
• Insides of viewport windows were checked for general cleanliness, given that we have found the outside of some of these to be rather dirty. Insides of viewports checked were deemed clean enough.
• Steve has installed a new vacuum guage to provide a more realiable pressure readout.
• We forgot to investigate the weird behaviour of the AS beam that Yutaro and Koji identified in November. In any case, looks like the clipping of the AS beam is worse now. We will have to try and fix this using the PZT mounted OMs, and if not, we may have to consider venting again

Summary of characterization tasks to be done:

1. Mode matching into the Y arm cavity given the arm length change
2. HOM content in transmitted IR light from Y arm given the arm length change (Finesse models suggest that the 2f second order HOM resonance may have moved closer to the 00 resonance)
3. Arm loss measurement
4. Suspension diagonalization
5. Check the Qs of the optics eigenmodes - should indicate if any of our magnets, reglued or otherwise, are a little loose
12587   Fri Oct 28 15:46:29 2016 gautamSummaryLSCX/Y green beat mode overlap measurement redone

I've been meaning to do this analysis ever since putting in the new laser at the X-end, and finally got down to getting all the required measurements. Here is a summary of my results, in the style of the preceeding elogs in this thread. I dither aligned the arms and maximized the green transmission DC levels, and also the alignment on the PSL table to maximize the beat note amplitude (both near and far field alignment was done), before taking these measurements. I measured the beat amplitude in a few ways, and have reported all of them below...

             XARM   YARM
o BBPD DC output (mV), all measured with Fluke DMM
 V_DARK:     +1.0    +3.0  V_PSL:      +8.0    +14.0  V_ARM:      +175.0  +11.0

o BBPD DC photocurrent (uA)
I_DC = V_DC / R_DC ... R_DC: DC transimpedance (2kOhm)  I_PSL:       3.5    5.5  I_ARM:      87.0    4.0

o Expected beat note amplitude I_beat_full = I1 + I2 + 2 sqrt(e I1 I2) cos(w t) ... e: mode overlap (in power) I_beat_RF = 2 sqrt(e I1 I2) V_RF = 2 R sqrt(e I1 I2) ... R: RF transimpedance (2kOhm) P_RF = V_RF^2/2/50 [Watt]      = 10 log10(V_RF^2/2/50*1000) [dBm]
     = 10 log10(e I1 I2) + 82.0412 [dBm]
     = 10 log10(e) +10 log10(I1 I2) + 82.0412 [dBm]

for e=1, the expected RF power at the PDs [dBm]  P_RF:      -13.1  -24.5

o Measured beat note power (measured with oscilloscope, 50 ohm input impedance)        P_RF:      -17.8dBm (81.4mVpp)  -29.8dBm (20.5mVpp)   (38.3MHz and 34.4MHz)       e:        34                    30  [%]                           o Measured beat note power (measured with Agilent RF spectrum analyzer)         P_RF:      -19.2  -33.5  [dBm] (33.2MHz and 40.9MHz)       e:       25     13    [%]                          

I also measured the various green powers with the Ophir power meter:

o Green light power (uW) [measured just before PD, does not consider reflection off the PD]
 P_PSL:       16.3    27.2  P_ARM:       380     19.1

Measured beat note power at the RF analyzer in the control room  P_CR:      -36    -40.5    [dBm] (at the time of measurement with oscilloscope) Expected    -17    - 9    [dBm] (TO BE UPDATED)

Expected Power: (TO BE UPDATED) Pin + External Amp Gain (25dB for X, Y from ZHL-3A-S)     - Isolation trans (1dB)     + GAV81 amp (10dB)     - Coupler (10.5dB)

The expected numbers for the control room analyzer in red have to be updated.

The main difference seems to be that the PSL power on the Y broadband PD has gone down by about 50% from what it used to be. In either measurement, it looks like the mode matching is only 25-30%, which is pretty abysmal. I will investigate the situation further - I have been wanting to fiddle around with the PSL green path in any case so as to facilitate having an IR beat even when the PSL green shutter is closed, I will try and optimize the mode matching as well... I should point out that at this point, the poor mode-matching on the PSL table isn't limiting the ALS noise performance as we are able to lock reliably...

12613   Mon Nov 14 14:21:06 2016 gautamSummaryCDSReplacing DIMM on Optimus

I replaced the suspected faulty DIMM earlier today (actually I replaced a pair of them as per the Sun Fire X4600 manual). I did things in the following sequence, which was the recommended set of steps according to the maintenance manual and also the set of graphics on the top panel of the unit:

1. Checked that Optimus was shut down
2. Removed the power cables from the back to cut the standby power. Two of the fan units near the front of the chassis were displaying fault lights, perhaps this has been the case since the most recent power outage after which I did not reboot Optimus
3. Took off the top cover, removed CPU 6 (labelled "G" in the unit). The manual recommends finding faulty DIMMs by looking for an LED that is supposed to indicate the location of the bad card, but I couldn't find any such LEDs in the unit we have, perhaps this is an addition to the newer modules?
4. Replaced the topmost (w.r.t the orientation the CPU normally sits inside the chassis) DIMM card with one of the new ones Steve ordered
5. Put everything back together, powered Optimus up again. Reboot went smoothly, fan unit fault lights which I mentioned earlier did not light up on the reboot so that doesn't look like an issue.

I then checked for memory errors using edac-utils, and over the last couple of hours, found no errors (corrected or otherwise, see Praful's earlier elog for the error messages that we were getting prior to the DIMM swap)- I guess we will need to monitor this for a while more before we can say that the issue has been resolved.

Looking at dmesg after the reboot, I noticed the following error messages (not related to the memory issue I think):

[   19.375865] k10temp 0000:00:18.3: unreliable CPU thermal sensor; monitoring disabled
[   19.375996] k10temp 0000:00:19.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376234] k10temp 0000:00:1a.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376362] k10temp 0000:00:1b.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376673] k10temp 0000:00:1c.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376816] k10temp 0000:00:1d.3: unreliable CPU thermal sensor; monitoring disabled
[   19.376960] k10temp 0000:00:1e.3: unreliable CPU thermal sensor; monitoring disabled
[   19.377152] k10temp 0000:00:1f.3: unreliable CPU thermal sensor; monitoring disabled

I wonder if this could explain why the fans on Optimus often go into overdrive and make a racket? For the moment, the fan volume seems normal, comparable to the other SunFire X4600s we have running like megatron and FB...

12615   Mon Nov 14 19:32:51 2016 ranaSummaryCDSReplacing DIMM on Optimus

I did apt-get update and then apt-get upgrade on optimus. All systems are nominal.

12679   Mon Dec 19 22:05:09 2016 KojiSummaryIOOPMC, IMC aligned. The ringdown PD/Lens removed.

PMC and IMC were aligned on Friday (16th) and Today (19th).

The PD and lens for the ringdown experiment were removed as they were blocking the WFS.

12680   Wed Dec 21 21:03:06 2016 KojiSummaryIOOIMC WFS tuning

- Updated the circuit diagrams:

IMC WFS Demodulator Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600503

IMC WFS Whitening Board, Rev. 40m https://dcc.ligo.org/LIGO-D1600504

- Measured the noise levels of the whitening board, demodboard, and nominal free running WFS signals.

- IMC WFS demod phases for 8ch adjusted

Injected an IMC PDH error point offset (@1kHz, 10mV, 10dB gain) and adjusted the phase to have no signal in the Q phase signals.

- The WFS2 PITCH/YAW matrix was fixed

It was found that the WFS heads were rotated by 45 deg (->OK) in CW and CCW for WFS1 and 2, respectively (oh!), while the input matrices were identical! This made the pitch and yaw swapped for WFS2. (See attachment)

- Measured the TFs MC1/2/3 P/Y actuation to the error signals

Attachment 1: DSC_0142.JPG
12682   Thu Dec 22 18:39:09 2016 KojiSummaryIOOIMC WFS tuning

Noise analysis of the WFS error signals.

Attachment 1: All error signals compared with the noise contribution measured with the RF inputs or the whitening inputs terminated.

Attachment 2: Same plot for all the 16 channels. The first plot (WFS1 I1) shows the comparison of the current noise contributions and the original noise level measured with the RF terminated with the gain adjusted along with the circuit modification for the fair comparison. This plot is telling us that the electronics noise was really close to the error signal.

I wonder if we have the calibration of the IMC suspensions somewhere so that I can convert these plots in to rad/sqrtHz...?

Attachment 1: WFS_error_noise.pdf
Attachment 2: WFS_error_noise_chans.pdf
12683   Fri Dec 23 20:53:44 2016 KojiSummaryIOOIMC WFS tuning

WFS1 / WFS2 demod phases and WFS signal matrix

Attachment 1: DSC_0144.JPG
Attachment 2: DSC_0145.JPG
12684   Fri Dec 23 21:05:56 2016 KojiSummaryIOOIMC WFS tuning

Signal transfer function measurements

C1:SUS-MC*_ASCPIT_EXC channels were excited for swept sine measurements.

The TFs to WFS1-I1~4, Q1~4, WFS1/2_PIT/YAW, MC2TRANS_PIT/YAW signals were recorded.

The MC1 and MC3 actuation seems to have ~30Hz elliptic LPF somewhere in the electronics chain.
This effect was compensated by subtracting the approximated time delay of 0.022sec.

The TFs were devided by freq^2 to make the response flat and averaged between 7Hz to 15Hz.
The results have been summarized in Attachment 3&4.

Attachment 4 has the signal sensing matrix. Note that this matrix was measured with the input gain of 0.1.

Input matrix for diagonalizing the actuation/sensor response

Pitch

$\begin{pmatrix} -1.58983 & -0.901533 & -5592.53 \\ 0.961632 & -0.569662 & 1715.12 \\ 0.424609 & 1.60783 & -5157.38 \end{pmatrix}$

e.g. To produce pure WFS1P reaction, => -1.59 MC1P + 0.962 MC2P + 0.425 MC3P

Yaw

$\begin{pmatrix} 1.461 & -0.895191 & -4647.9 \\ 0.0797164 & 0.0127339 & -1684.11 \\ 0.223054 & -1.31518 & -4101.14 \end{pmatrix}$

Attachment 1: IMC_WFS_segment_TF.pdf
Attachment 2: IMC_WFS_channels_TF.pdf
Attachment 3: IMC_WFS_161221_table1.pdf
Attachment 4: IMC_WFS_161221_table2.pdf
Attachment 5: IMC_WFS_161221.xlsx.zip
12685   Sun Dec 25 14:39:59 2016 KojiSummaryIOOIMC WFS tuning

Now, the output matrices in the previous entry were implemented.
The WFS servo loops have been engaged for several hours.
So far the REFL and TRANS look straight. Let's see how it goes.

12686   Mon Dec 26 12:45:31 2016 KojiSummaryIOOIMC WFS tuning

It didn't go crazy at least for the past 24hours.

Attachment 1: IMC_REFL_TRANS_26hrs.png
Attachment 2: IMC_TRANS_P_Y_26hrs.png
12688   Thu Dec 29 13:22:21 2016 ranaSummaryIOOIMC WFS tuning
• For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.
• It seems from the noise plots that the demod board is now dominating over the whitening board noise.
• If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.
• We should look at the out-of-lock light power on the WFS and re-examine what the 'safe' level is. We used to do this based on the dissipated electrical power (bias voltage x photocurrent).

At Hanford, there is this issue with laser jitter turning into an IMC error point noise injection. I wonder if we can try out taking the acoustic band WFS signal and adding it to the MC error point as a digital FF. We could then look at the single arm error signal to see if this makes any improvement. There might be too much digital delay in the WFS signals if the clock rate in the model is too low.

12689   Thu Dec 29 16:52:51 2016 KojiSummaryIOOIMC WFS tuning

Koji responding to Rana

> For the rough calibration below 10 Hz, we can use the SUS OSEM cal: the SUSPIT and SUSYAW error signals are in units of micro-radians.

I can believe the calibration for the individual OSEMs. But the input matrix looked pretty random, and I was not sure how it was normalized.
If we accept errors by a factor of 2~3, I can just naively believe the calibration factors.

> If the RF signals at the demod input are low enough, we can consider either increasing the light power on the WFS or increasing the IMC mod. depth.

The demod chip has the conversion factor of about the unity. We increased the gains of the AF stages in the demod and whitening boards. However, we only have the RMS of 1~20 counts. This means that we have really small RF signals. We should check what's happening at the RF outputs of the WFS units. Do we have any attenuators in the RF chain? Can we skip them without making the WFS units unstable?

12690   Thu Dec 29 21:35:30 2016 ranaSummaryIOOIMC WFS tuning

The WFS gains are supposedly maximized already. If we remotely try to increase the gain, the two MAX4106 chips in the RF path will oscillate with each other.

We should insert a bi-directional coupler (if we can find some LEMO to SMA converters) and find out how much actual RF is getting into the demod board.

Attachment 1: Screen_Shot_2017-01-03_at_5.55.13_PM.png
12720   Sat Jan 14 22:39:30 2017 ranaSummarySUSITMY is drifting ?

https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20170114/sus/susdrift/

ITMY is not like the others. Real or just OSEM madness?

12723   Mon Jan 16 21:03:47 2017 ranaSummaryIOOMCL / MCF / Calibration

Oot on the streets and in the chat rooms, people often ask, "What is up with the MC_F calibration?".

Not being sure of the wiring in the c1ioo model, I have formed this screencap of today's model and put it here. The MC_LENGTH and MC_FREQ are the filter banks which would calibrate these channels. In the filter banks there were various version of a 'dewhite' filter. They were all approximately z=150, p=15, g =1 @ DC, but with ~1% differences. I don't trust their provenance and so I've enforced symmetry and fixed their names to reflect what they are (150:15). I have also turned on one filter in MC_FREQ so that now the whitening of the Pentek Interface board is compensated.

Why is this TF 1/f? It should be -20 dB/decade if MC_F is in units of Hz* and MCL is a pendulum response. Perhaps its because the combination of the Koji summing box, the Thorlabs HV driver, and the Pomona box forms an additional 1/f ? IF so, this would explain the TF we see. Once we get confirmation from Koji, we can load the TF into the MC_FREQ filter bank and then MC_F will be in units of Hz (as will the summary pages).

(along the way I've also turned off the craaaazzzy servo input enable tickling that gets put in the MC AutoLocker every April Fool's leap year - resist the temptation)

Since we have a frequency counter system here and some oscillators, I wonder if we can just calibrate the MC_L and MC_F directly using a mixer lashed up to one of the counters. If so, and we can get the stabilized laser frequency noise down below 10 mHz/rHz, maybe this is a viable alternative method to the photon calibrators. Counting zero crossings is more honest than counting photons.

Attachment 1: c1ioo_zoom_MCLF.png
Attachment 2: MCL.pdf
12732   Wed Jan 18 12:34:21 2017 ericqSummaryIOOMCL / MCF / Calibration
 Quote: In the filter banks there were various version of a 'dewhite' filter. They were all approximately z=150, p=15, g =1 @ DC, but with ~1% differences. I don't trust their provenance and so I've enforced symmetry and fixed their names to reflect what they are (150:15).

The filters were made in response to a measurement of the pentek whitening boards in 2015 (ELOG 11550), but this level of accuracy probably isn't important.

12748   Tue Jan 24 01:04:16 2017 gautamSummaryIOOIMC WFS RF power levels

Summary:

I got around to doing this measurement today, using a minicircuits bi-directional coupler (ZFBDC20-61-HP-S+), along with some SMA-LEMO cables.

• With the IMC "well aligned" (MC transmission maximized, WFS control signals ~0), the RF power per quadrant into the Demod board is of the order of tens of pW up to a 100pW.
• With MC1 misaligned such that the MC transmission dropped by ~10%, the power per quadrant into the demod board is of the order of hundreds of pW.
• In both cases, the peak at 29.5MHz was well above the analyzer noise floor (>20dB for the smaller RF signals), which was all that was visible in the 1MHz span centered around 29.5 MHz (except for the side-lobes described later).
• There is anomalously large reflection from Quadrant 2 input to the Demod board for both WFS
• The LO levels are ~-12dBm, ~2dBm lower than the 10dBm that I gather is the recommended level from the AD831 datasheet
 Quote: We should insert a bi-directional coupler (if we can find some LEMO to SMA converters) and find out how much actual RF is getting into the demod board.

Details:

I first aligned the mode cleaner, and offloaded the DC offsets from the WFS servos.

The bi-directional coupler has 4 ports: Input, Output, Coupled forward RF and Coupled Reverse RF. I connected the LEMO going to the input of the Demod board to the Input, and connected the output of the coupler to the Demod board (via some SMA-LEMO adaptor cables). The two (20dB) coupled ports were connected to the Agilent spectrum analyzer, which have input impedance 50ohms and hence should be impedance matched to the coupled outputs. I set the analyzer to span 1MHz (29-30MHz), IF BW 30Hz, 0dB input attenuation. It was not necessary to turn on averaging to resolve the peaks at ~29.5MHz since the IF bandwidth was fine enough.

I took two sets of measurements, one with the IMC well aligned (I maximized the MC Trans as best as I could to ~15,000 cts), and one with a macroscopic misalignment to MC1 such that the MC Trans fell to 90% of its usual value (~13,500 cts). The peak function on the analyzer was used to read off the peak height in dBm. I then converted this to RF power, which is summarized in the table below. I did not account for the main line loss of the coupler, but according to the datasheet, the maximum value is 0.25dB so there numbers should be accurate to ~10% (so I'm really quoting more S.Fs than I should be).

WFS Quadrant Pin (pW) Preflected(pW) Pin-demod board (pW)

## IMC well aligned

1 1 50.1 12.6 37.5
2 20.0 199.5 -179.6
3 28.2 10.0 18.2
4 70.8 5.0

65.8

2 5 100 19.6 80.0
6 56.2 158.5 -102.3
7 125.9 6.3 11.5
8 17.8 6.3

119.6

WFS Quadrant Pin (pW) Preflected(pW) Pin-demod board (pW)

## MC1 Misaligned

1 1 501.2 5.0 496.2
2 630.6 208.9 422
3 871.0 5.0 866
4 407.4 16.6

190.8

2 5 407.4 28.2 379.2
6 316.2 141.3 175.0
7 199.5 15.8 183.7
8 446.7 10.0 436.7

For the well aligned measurement, there was ~0.4mW incident on WFS1, and ~0.3mW incident on WFS2 (measured with Ophir power meter, filter out).

I am not sure how to interpret the numbers for quadrants #2 and #6 in the first table, where the reverse coupled RF power was greater than the forward coupled RF power. But this measurement was repeatable, and even in the second table, the reverse coupled power from these quadrants are more than 10x the other quadrants. The peaks were also well above (>10dBm) the analyzer noise floor

I haven't gone through the full misalginment -> Power coupled to TEM10 mode algebra to see if these numbers make sense, but assuming a photodetector responsivity of 0.8A/W, the product (P1P2) of the powers of the beating modes works out to ~tens of pW (for the IMC well aligned case), which seems reasonable as something like P1~10uW, P2 ~ 5uW would lead to P1P2~50pW. This discussion was based on me wrongly looking at numbers for the aLIGO WFS heads, and Koji pointed out that we have a much older generation here. I will try and find numbers for the version we have and update this discussion.

Misc:

1. For the sake of completeness, the LO levels are ~ -12.1dBm for both WFS demod boards (reflected coupling was negligible)
2. In the input signal coupled spectrum, there were side lobes (about 10dB lower than the central peak) at 29.44875 MHz and 29.52125 MHz (central peak at 29.485MHz) for all of the quadrants. These were not seen for the LO spectra.
3. Attached is a plot of the OSEM sensor signals during the time I misaligned MC1 (in both pitch and yaw approximately by equal amounts). Assuming 2V/mm for the OSEM calibration, the approximate misalignment was by ~10urad in each direction.
4. No IMC suspension glitching the whole time I was working today

Attachment 1: MC1_misalignment.png
12753   Wed Jan 25 10:46:58 2017 steveSummarySUSoplev laser summary updated

Oct.  5, 2015              ETMY He/Ne replaced by 1103P, sr P919645,  made Dec 2014, after 2 years

Jan. 24, 2017              ETMY He/Ne replaced by 1103P,  sr P947049,  made Apr 2016,  after 477 hrs running hot

Attachment 1: oplev_sums.png
12757   Wed Jan 25 18:18:08 2017 KojiSummaryIOOMCL / MCF / Calibration

jiSome notes on the FSS configuration: ELOG 10321

12759   Fri Jan 27 00:14:02 2017 gautamSummaryIOOIMC WFS RF power levels

It was raised at the Wednesday meeting that I did not check the RF pickup levels while measuring the RF error signal levels into the Demod board. So I closed the PSL shutter, and re-did the measurement with the same measurement scheme. The detailed power levels (with no light incident on the WFS, so all RF pickup) is reported in the table below.

IMC WFS RF Pickup levels @ 29.5MHz
1 1 0.21 10.
2 1.41 148
3 0.71 7.1
4 0.16 3.6
2 1 0.16 10.5
2 1.48 166
3 0.81 5.1
4 0.56 0.33

These numbers can be subtracted from the corresponding columns in the previous elog to get a more accurate estimate of the true RF error signal levels. Note that the abnormal behaviour of Quadrant #2 on both WFS demod boards persists.

12777   Tue Jan 31 17:28:36 2017 ranaSummaryCDSMinute Trend Koan

Someone installed "Debian" on allegra. Why? Dataviewer doesn't work on there. Is there some advantage to making this thing have a different OS than the others? Any objections to going back to Ubuntu12?

12779   Tue Jan 31 20:25:26 2017 ericqSummaryCDSMinute Trend Koan
 Quote: Someone installed "Debian" on allegra. Why? Dataviewer doesn't work on there. Is there some advantage to making this thing have a different OS than the others? Any objections to going back to Ubuntu12?

My elog negligence punchcard is getting pretty full... It's pretty much for the same reason as using Debian for optimus; much of the workstation software is getting packaged for Debian, which could offload our need for setting things up in a custom 40m way. Hacking the debian-focused software.ligo.org repos into Ubuntu has caused me headaches in the past. Allegra wasn't being used often, so I figured it was a good test bed for trying things out.

The dataviewer issue was dataviewer's inability to pull the fb out of fb:8088 in the NDSSERVER env variable. I made a quick fix for it in the dataviewer launching script, but there is probably a better way to do it.

12791   Thu Feb 2 18:28:29 2017 ranaSummaryCDSMinute Trend Koan

and the song remains the same...

the version of SVN on these workstations is ahead of the one on the other workstations so now we can't do 'svn up' on any of the Ubuntu12 machines. One allegra and optimus I get this error:

controls@allegra|GWsummaries> svn up Updating '.': svn: E180001: Unable to connect to a repository at URL 'file:///cvs/cds/caltech/svn/trunk/GWsummaries' svn: E180001: Unable to open an ra_local session to URL svn: E180001: Unable to open repository 'file:///cvs/cds/caltech/svn/trunk/GWsummaries'

Quote:
 Quote: Someone installed "Debian" on allegra. Why? Dataviewer doesn't work on there. Is there some advantage to making this thing have a different OS than the others? Any objections to going back to Ubuntu12?

My elog negligence punchcard is getting pretty full... It's pretty much for the same reason as using Debian for optimus; much of the workstation software is getting packaged for Debian, which could offload our need for setting things up in a custom 40m way. Hacking the debian-focused software.ligo.org repos into Ubuntu has caused me headaches in the past. Allegra wasn't being used often, so I figured it was a good test bed for trying things out.

The dataviewer issue was dataviewer's inability to pull the fb out of fb:8088 in the NDSSERVER env variable. I made a quick fix for it in the dataviewer launching script, but there is probably a better way to do it.

I'm not sure if its possible to downgrade our chans repo back to the old one, but I highly recommend that no one do 'svn upgrade' in any of our repos until we remove all of the Debian installs in the 40m lab or hire a full-time sysadmin.

12792   Thu Feb 2 18:32:51 2017 ranaSummaryPSLPMC alignment

Re-aligned the beam going into the PMC today around 5 PM. I noticed that its all in pitch and since I moved both of the mirrors by the same amount it is essentially a vertical translation.

I wonder if the PMC is just moving up and down due to thermal expansion in the mount? How else would we get a pure vertical translation? Need to remember next time if the beam goes up or down, and by how many knob turns, and see how it correlates to the lab temperature.

12796   Fri Feb 3 11:40:34 2017 ericqSummaryCDS/cvs/cds/caltech/chans back on svn1.6

I was able to bring back svn 1.6 formatting to /cvs/cds/caltech/chans by doing the following on nodus:

cd /cvs/cds/caltech
mkdir newchans
cd newchans
svn co https://nodus.ligo.caltech.edu:30889/svn/trunk/chans ./
rm -rf ../chans/.svn
mv ./.svn ../chans/

Note that I used the http address for the repository. The svn repository doesn't live at file:///cvs/cds/caltech/svn anymore; all of our checkouts (e.g. in the scripts directory) use http to get the one true repo location, regardless of where it lives on nodus' filesystem. (I suppose we could also use https://nodus.martian:30889/svn to stick to the local network, but I don't think we're that limited by the caltech network speed)

Presumably, at some point we will want to introduce a newer operating system into the 40m, as ubuntu 12.04 hits end-of-life in April 2017. Ubuntu 16.04 includes svn 1.8, so we'll also hit this issue if we choose that OS.

Aside from the svn issues, this directory (/cvs/cds/caltech/chans) only contains pre-2010 channels. Filters and DAQ ini files currently live in /opt/rtcds/caltech/c1/chans, which is not under version control. It's also not clear to me why summary page configurations should be kept in this /cvs/cds place.

12797   Sat Feb 4 12:00:59 2017 ranaSummaryCDS/cvs/cds/caltech/chans back on svn1.6

True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

12798   Sat Feb 4 12:20:39 2017 jamieSummaryCDS/cvs/cds/caltech/chans back on svn1.6
 Quote: True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

Just to be clear, since there seems to be some confusion, the SVN issue has nothing to do with Debian vs. Ubuntu.  SVN made non-backwards compatible changes to their working copy data format that breaks newer checkouts with older clients.  You will run into the exact same problem with newer Ubuntu versions.

I recommend the 40m start moving towards the reference operating systems (Debian 8 or SL7) as that's where CDS is moving.  By moving to newer Ubuntu versions you're moving away from CDS support, not towards it.

12799   Sat Feb 4 12:29:20 2017 jamieSummaryCDS/cvs/cds/caltech/chans back on svn1.6

No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Quote:
 Quote: True - its an issue. Koji and I are updating zita into Ubuntu16 LTS. If it looks like its OK with various tools we'll swap over the others into it. Until then I figure we're best off turning allegra back into Ubuntu12 to avoid a repeat of this kind of conflict. Once the workstations in the LLO control room are running smoothly on a new OS for a year, we can transfer into that. I don't think any of us wants to be the CDS beta tester for DV or DTT.

Just to be clear, since there seems to be some confusion, the SVN issue has nothing to do with Debian vs. Ubuntu.  SVN made non-backwards compatible changes to their working copy data format that breaks newer checkouts with older clients.  You will run into the exact same problem with newer Ubuntu versions.

I recommend the 40m start moving towards the reference operating systems (Debian 8 or SL7) as that's where CDS is moving.  By moving to newer Ubuntu versions you're moving away from CDS support, not towards it.

12800   Sat Feb 4 12:50:01 2017 jamieSummaryCDS/cvs/cds/caltech/chans back on svn1.6
 Quote: No, not confused on that point. We just will not be testing OS versions at the 40m or running multiple OS's on our workstations. As I've said before, we will only move to so-called 'reference' systems once they've been in use for a long time.

Ubuntu16 is not to my knowledge used for any CDS system anywhere.  I'm not sure how you expect to have better support for that.  There are no pre-compiled packages of any kind available for Ubuntu16.  Good luck, you big smelly doofuses. Nyah, nyah, nyah.

12834   Thu Feb 16 13:29:38 2017 gautamSummaryGeneralAlternative Calibration Scheme

Summary:

Craig and I have been trying to put together a Simulink diagram of the proposed alternative calibration scheme. Each time I talk the idea over with someone, I convince myself it makes sense, but then I try and explain it to someone else and get more confused. Probably I am not even thinking about this in the right way. So I am putting what I have here for comments/suggestions.

What's the general idea?

Suppose the PSL is locked to the MC cavity, and the AUX laser is locked to the arm cavity (with sufficiently high BW). Then by driving a line in the arm cavity length, and beating the PSL and AUX lasers, we can determine how much we are modulating the arm cavity length in metres by reading out the beat frequency between the two lasers, provided the arm cavity length is precisely known.

So we need:

1. Both lasers to be stabilized to be able to sense the line we are driving
2. A high bandwidth PDH loop for locking the AUX laser to the arm cavity such that the AUX laser frequency is able to track the line we are driving
3. An accurate and precise way to read out the beat frequency (the proposal here is to use an FPGA based readout)
4. An accurate measurement of the arm length (I think we know the arm lengths to <0.1% so this shouldn't dominate any systematic error).

To be able to sense a 1kHz line being driven at 1e-16 m amplitude, I estimate we need a beat note stability of ~1mHz/rtHz at 1kHz.

Requirements and what we have currently:

• The PSL is locked to the mode-cleaner, and the arm cavity is locked to the PSL. The former PDH loop is high BW, and so we expect the stabilized PSL to have frequency noise of ~1mHz/rtHz at about 1kHz (to be measured and confirmed)
• The AUX laser is locked to the arm cavity with a medium-BW (~10kHz UGF) PDH servo. From past out-of-loop ALS beat measurements, I estimate the expected frequency noise of the AUX laser at 1kHz to be ~1Hz/rtHz with the current PDH setup
• Rana suggested we "borrow" the stability of the PSL by locking the AUX laser and PSL in a high bandwidth PLL - if we want this loop to have ~300kHz BW, then we need to use an EOM as an actuator. The attached Simulink diagram (schematic representation only, though I think I have measurements of many of those transfer functions/gains anyways) shows the topology I had in mind. Perhaps I did not understand this correctly, but if we have such a loop with high gain at 1kHz, and the error signal being the beat between PSL and AUX, won't it squish the modulation we are applying @1kHz?
• Is it feasible to instead add a parallel path to the end PDH loop with an EOM as an actuator (similar to what we do for the IMC locking)? Ideally, what we want is an end PDH loop which squishes the free-running NPRO noise to ~1mHz/rtHz at 1kHz instead of the 1Hz/rtHz we have currently. This loop would then also have negligible tracking error at 1kHz. Then, we could have a low bandwidth PLL offloading onto the temperature of the crystal to keep the beat between the two lasers hovering around the PSL frequency.

Hardware:

On the hardware side of things, we need:

• FSS box to drive the EOM (Rana mentioned there is a spare available in the Cryo lab)

Koji and I briefly looked through the fiber inventory we have yesterday. We have some couplers (one mounted) and short (5m) patch fibers. But I think the fiber infrastructure we have in place currently is adequate - we have the AUX light brought to the PSL table, and there is a spare fiber running the other way if we want to bring the PSL IR to the end as well.

I need to also think about where we can stick the EOM in given physical constraints on the EX table and the beam diameter/aperture of EOM...

Attachment 1: AltCal.pdf
12835   Thu Feb 16 21:55:47 2017 ranaSummaryGeneralAlternative Calibration Scheme

Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

12842   Tue Feb 21 13:51:35 2017 CraigSummaryGeneralAlternative Calibration Scheme

We get SNR in two ways: the amplitude of applied force and the integration time.  So we are limited in two ways: stability of the lock to applied forces and time of locklosses / calibration fluctuations.

At the sites, you probably know that we blow our spectrum out of the water with the calibration lines, with SNRs of about 100 on the scale of about 10 seconds.  For us this might be impossible, since we aren't as quiet.

If we want 1% calibration on our sweeps, we'll need  0.01 = Uncertainty = sqrt( (1 - COH^2)/(2 * Navg * COH^2) ), where COH is the coherence of the transfer function measurement and Navg is the number of measurements at a specific frequency.  This equation comes from Bendat and Piersol, and is subject to a bunch of assumptions which may not be true for us (particularly, that the plant is stationary in time).

If we let Navg = 10, then COH ~ 0.999.

Coherence = Gxy^2/(Gxx * Gyy), where x(t) and y(t) are the input signal and output signal of the transfer function measurement, Gxx and Gyy are the spectral densities of x and y, and Gxy is the cross-spectral density.

Usually SNR = P_signal / P_noise, but for us SNR = A_signal / A_noise.

Eric Q and Evan H helped me find the relationship between Coherence and SNR:

P = Pn + Pc, Pn = P * (1 - Coh), Pc = P * Coh

==> SNR = sqrt( Pc / Pn ) = sqrt( Coh / 1 - Coh )

From Coh ~ 0.999, SNR ~ 30.

 Quote: Question for Craig: What does the SNR of our lines have to be? IF we're only trying to calibrate the actuator in the audio band over long time scales, it seems we could get by with more frequency noise. Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?

12845   Wed Feb 22 10:16:54 2017 ranaSummaryGeneralAlternative Calibration Scheme

OK, but the questions still stands: "Assuming we want a 1% calibration at 50-500 Hz, what is the requirement on the frequency noise PSD curve?"

 Quote: We get SNR in two ways: the amplitude of applied force and the integration time.  So we are limited in two ways: stability of the lock to applied forces and time of locklosses / calibration fluctuations.
12857   Tue Feb 28 21:05:44 2017 ranaSummaryIOOMC Length offset changes MCWFS offsets

The input offset on the MC length servo board changes the lock point of the length loop (by how much? need to calibrate this slider into meters & Hz).

The SUM signal on the MC WFS is ~few 1000. This is several times larger than the pit/yaw signals. This is bad. it means that the TEM00 mode on the WFS (or what the WFS interperets as a TEM00) is larger than the TEM01/10 that its supposed to measure.

So if the beam moves on the WFS head it will convert this large common mode signal into a differential one.

We moved the MC Servo offset around from -3 to +3 V today and saw that it does affect the transmitted light level, but we need to think more to see how to put the offset at the real center of the resonance. This is complicated by the fact that the MCWFS loops seem to have some several minutes time constant so things are essentially always drifting.

1. Characterize and juice up the WFS loops.
2. Figure out how to set the MC length loop offset. Is this bad offset changing the zero point of the MC WFS loops?
3. If so, it may be a source of excess jitter noise in the interferometer.

I changed the McREFL SMOO to make it easier to use this noisy channel to diagnose small alignment changes:

caput C1:IOO-MC_RFPD_DCMON.SMOO 0.1

12869   Mon Mar 6 12:34:30 2017 johannesSummaryASSASS light injection scenarios

What we want from the light source for the AS port light injection:

• Frequency control for locking and maintaining known offset from arm cavity resonances -> see below
• Fast extinguishing light in the IFO -> AOM first order switching

We have four possible laser sources that we can use for the injection of 1064 nm from the back:

• There are ~65 mW of IR power coming from the PSL doubling oven, of which ~2mW are used for the fiber beat box. The remaining light is currently dumped on the PSL table and would be available. It is picked off after the PMC and does not have any of the sidebands.
• There is a ~200 mW Lightwave NPRO on the PSL table that is currently unused.
• Koji said he has a ~500mW NPRO in the OMC lab that has no PZT actuation. I contacted a couple companies about fiber-coupled variable AOM frequency shifters that we can pair with this laser.
• I don't think using the high power beam of the PSL itself is a good idea, especially if we want to map the loss on the optics, because' we'll need it for the dither locking

I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.

Different frequency control schemes are:

• Modulate sidebands on the light and stabilize directly to the arm, using POX/Y or back-reflection at AS
• Free-space resonant EOM
• Free-space broadband EOM with Rich's resonant amplifier attachment
• Fiber-coupled EOM
• Offset phaselock:
• PSL IR: Transfer mode-cleaner stability
• Can lock arms while measurement in progress, but will have PSL IR light on PDs
• Green from the end;
• Broadly tunable laser frequency and no interference from IR.

Either way we'll need a few things:

• required for PDH locking, optional if we phaselock instead
• AOM
• We have free-space available, looking into fiber-coupled ones with frequency tuning
• Fast switching electronics
• Various fiber stuff
• We have enough to set up the fiber coupling of one light source. I'm starting with the 200 mW NPRO but this is technically interchangable.

I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.

12892   Fri Mar 17 15:30:39 2017 SteveSummarySUSoplev laser summary updated

March  17,  2017         ETMX laser replaced at LT 3y with 1103P, sn T8070866

Attachment 1: oplev_sums.png
12905   Fri Mar 24 12:21:27 2017 gautamSummaryIOOMCL / MCF / Calibration

I repeated this measurement as follows:

1. Added a filter in the MC_F filterbank (FM9) to account for the Pomona box between the PZT control signal and the laser PZT (pole@2.9Hz). So the filter bank at the time of TF measurement looks like this:
2. Measured TF from driving MC2 (with C1:SUS-MC2_MCL_OUT channel) to C1:IOO-MC_F, which is the output of the above filter bank. The response is the expected 1/f^2 shape of the free optic

3. From this transfer function, the magnitude is 0.0316 ct/ct. Using the value of 6nm/ct for the MC2 actuator gain that I found in a previous elog entry, I calibrated the MC_F output into Hz using the calibration factor 3.95MHz/ct (FM10 in the above filterbank).

Here is a calibrated MC_F spectrum:

RXA: I've added this plot of the free-running noise of the Lightwave NPRO which is probably similar to our Innolight Mephisto. Seems like the laser is quieter than MC_F everywhere below 100 Hz.

Attachment 2: MCF_cal.pdf
Attachment 3: MCFTF_mag.pdf
Attachment 4: MCFTF_phase.pdf
Attachment 5: MCFTF_coh.pdf
Attachment 6: FreqNoiseReq.pdf
12907   Mon Mar 27 12:48:36 2017 ranaSummaryIOOMCL / MCF / Calibration

What readouts do we have for the PMC length? If we could have a calibrated & whitened error and control signal for the PMC up to 16 kHz, perhaps we could see at what frequencies we can use it as a faux-RefCav.

12910   Mon Mar 27 20:29:05 2017 ranaSummaryDetCharSummary pages broken again

Going to the summary pages and looking at 'Today' seems to break it and crash the browser. Other tabs are OK, but 'summary' is our default page.

I've noticed this happening for a couple of days now. Today, I moved the .ini files which define the config for the pages from the old chans/ location into the /users/public_html/detcharsummary/ConfigFiles/ dir. Somehow, we should be maintaining version control of detcharsummary, but I think right now its loose and free.

ELOG V3.1.3-