40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 81 of 337 Not logged in
ID Date Author Type Category Subject
12899   Wed Mar 22 00:33:00 2017 gautamUpdateIMCIMC length offset nulling

[valera, gautam]

Motivation: see this elog

I was fiddling around for a few days trying to implement the method outlined in this paper to null this offset - I will post a separate elog about my efforts but Valera pointed out that we could try injecting an AF modulation at the IN2 input of the MC Servo Board. Last night, we hooked up an SR function generator (f = 312Hz, A = 0.01Vpp, IN2 gain = -5dB) to the unused BNC IN2 input of the MC Servo board. To avoid any additional offsets from the AO path during this measurement, I disconnected the LEMO cable (it is labelled).

We looked at the spectrum of the MC transmission around 312Hz and also 2*f = 624Hz. As a result of this modulation, we expect in the transmitted power, dP/P, a 2f term with amplitude ~(X_mod/X_0)^2 and a term at f with amplitude ~(X_offset * X_mod / X_0^2) - I may have missed out some numerical factors of order 1. So the latter should vanish if the offset at the error point is truly zero and the lock-point is the center of the resonance. Last night, we found that an offset in the range of -0.25 V to -0.19 V nulled this peak in the DTT spectrum. Today, the number was -0.05V. So the true offset seems to vary from lock to lock. Here are spectra around f=312Hz for a few different values of the offset slider (the center of the resonance seems to be -0.05V on the MEDM slider at this time).

Do these numbers make sense? Some time ago, I had pulled out the MC Servo board to find out what exactly is going on at this offset summing point. The MEDM slider goes from -10V to 10V, and by measuring the voltage at TP5 (see schematic below), I found that there is a 1/40 scaling factor between what is actually applied and the number on the MEDM slider (so for example, the numbers in the legend in the above plot have to be divided by 40). I've modified the MC Servo Board MEDM screen to reflect this. When I had pulled the board out, I noticed that in addition to the offset voltage applied via the backplane connector, there was also a potentiometer (R50 in the schematic below). I had nulled the voltage at TP5 using this potentiometer, but I guess drifts of ~5mV are possible.

Discussion on calibration of offset slider in Hz/V:

I've yet to do a rigorous calibration of this slider into Hz, but looking at the spectrum of the transmitted intensity at 2f, we estimated the coefficient (X_mod/X_0) ~ 3e-3 for an offset of 0.2V. dP/P ~1 when the applied modulation equals the linewidth of the cavity, which is 3.6kHz. So 0.2V of offset slider corresponds to ~ 10Hz frequency offset. In other words, I estimate the slider calibration to be 50Hz/V. So with the full range of +/- 10V, we should be able to scan ~1kHz of frequency offset. What does this imply about the variation of the offset slider value that removes the peak at 1f between locks? As mentioned above, this variation is ~0.2V over a day - with the calibration mentioned above, this corresponds to a change in cavity length of ~10um, which seems reasonable to me...

So how did all of this tie in with WFS SUM offsets? We did the following:

• After nulling the length offset using the procedure detailed above, we noticed non-zero offsets on both WFS1 and WFS2 "I" SUM outputs
• So we set the dark offsets and RF offsets for the WFS, with no light incident on the WFS (PSL shutter closed).
• Re-locking the IMC and closing the WFS loops, we noticed that WFS2 SUM offset was still hovering around 0, but WFS1 SUM offset was ~ -2000cts.
• Looking at some trends on dataviewer, this offset seems to drift around over a few days timescale by a few thousand counts - for example, the WFS1 offset today was +2000cts. Moreover, the WFS1 offset seems to drift around by ~factor of 3 times as much as WFS2 offset in the 24 hour period I looked up (plot to follow)...
• Misaligned MC2 and looked at the sum offset with just the single bounce beam off MC1 onto the WFS

I neglected to screenshot the StripTool from the times we were doing these trials but I have the times, I will pull up some dataviewer plots and upload them here tomorrow...

Attachment 1: offsetInvestigation.pdf
Attachment 2: offset_summing_amp.pdf
12898   Tue Mar 21 21:59:48 2017 gautamUpdateIMCIMC input beam mode matching

[valera, gautam]

We implemented the plan outlined in the previous elog. The visibility (Pmax-Pmin)/(Pmax+Pmin) calculated with the MC REFL PD levels with the MC locked/unlocked is now ~96% (up from 88%). The MC REFL DC level in lock is now ~0.12V (compared to 0.4V). Assuming a modulation depth of 0.1 @ 29.5MHz, about 25% of this (i.e. 0.03V) is from sideband light.

The procedure followed was (see sketch in previous elog for various optic labels):

1. Move L2 back (towards PMC) by ~2cm.
2. Walk the beam using M3 and M4 to minimize MCREFL, re-lock IMC, run WFS.
3. Move L3 back (towards PMC) by ~2cm.
4. Repeat steps 2 and 3, the latter with smaller steps, monitor MCREFL DC level.

We could probably tweak the fine positioning of L2 and L3 and improve the efficiency a little more, but the primary objective here was to see if there was any effect on the large common mode offset on the WFS demodulated "SUM" output. Unfortunately, we saw no effect.

Here are two photos of the relevant section of the PSL table before (left) and after (right) our work there:

12897   Tue Mar 21 21:21:58 2017 gautamUpdateIOOWFS filter banks updated

The arrangement of filters in the WFS loop filter banks have been altered, Rana will update with details of the motivation behind these changes. Here is how the screen looks now:

I have updated the C1IOO SDF table, and also the mcwfson script to reflect these changes. The latter has been svn committed.

12896   Tue Mar 21 15:13:44 2017 gautamUpdateIMCIMC input beam mode matching

[valera, gautam]

Last night, Valera and I looked into two aspects of the IMC:

1. How can we accurately set the offset at the error point of the PDH servo such that we lock to the true center of the resonance?
2. What's up with the large common mode offset on the WFS?

I will post a more detailed elog about last night's work, but Valera also thought it might be a good idea to try and improve the mode-matching into the IMC. I couldn't find anything on the wiki/elog about the mode matching situation on the PSL table, so I quickly went over yesterday to measure some lengths. From looking at the MCREFL DC levels when the mode cleaner is locked (~0.37V) and unlocked (~5.7V), the current mode matching efficiency seems to be about 88%, so there is definitely some headroom for improvement.

Here is my cartoon of the situation on the PSL table. All lengths are measured in mm, and I would say correct to +/- 5 mm, so there could be considerable error here...

(L1 : f=+200mm. L2: f=-150mm. L3:  f=+400mm)

I extracted the lengths from the edge of the PSL table to IM1 and MC1 from (what I think are) the latest CAD drawings on the DCC. I then put all this into an a la mode script [Attachment #5] - I assumed a waist of 370um at the PMC output mirror, and a waist of 1.78mm at MC1. I neglected the passage through the in-vac Faraday, EOM and BS1 (on the sketch above) and the MC1 substrate. I was able to achieve a theoretical mode-matching efficiency of 1 by just moving the positions of L2 and L3.

Given that there are probably errors of the order 0.5cm in the lengths on the PSL table, and also the in-vacuum distance to MC1, I figured it would be ideal to just move one lens and see if we can improve the efficiency. It looks like it may be more effective to move L2 than L3. The plot on the right shows that the sensitivity is approximately equal to the positioning of L2 and L3. Judging by this plot, looks like w.r.t. the coordinates in this plot, we are somewhere around (0.02,-0.02).

It looks like if we want to do this, moving L2 (f = -150mm) may be the best way to go.

Attachment 2: IMC_ModeMatch.pdf
Attachment 3: singleLensSensitivity.pdf
Attachment 4: sensitivity.pdf
Attachment 5: IMCmodeMatch.m
close all
clear all
clc

%Create a beamPath object
InpPath = beamPath;
%Add components - for a first pass, ignore Faraday and HWPs, so only
%mirrors and lenses..

... 115 more lines ...
12895   Mon Mar 20 17:12:08 2017 steveUpdatePEMparticle counter inside of PSL enclousure

The logging script is multiplying by 100 instead of 10 !

 Quote: The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am. The HEPA filter speed at the Variac was turned down to 20V from 40 This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

Attachment 1: enclousure_partical_count.png
12894   Mon Mar 20 14:39:44 2017 gautamUpdateCDSNo internet connectivity on control room machines

Koji diagnosed that the NAT router was to blame for this problem. I simply power cycled this router, and now the connectivity has been restored.

It was possible to log into nodus and then to pianosa - and it was also possible to log into the various control room machines once logged into nodus. However, the outward packets seemed to not get transmitted. Anyways, power cycling the NAT Router unit seems to have done the job.

 Quote: There is no internet connectivity on any of the control room machines.  I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.

12893   Mon Mar 20 11:18:58 2017 gautamUpdateCDSNo internet connectivity on control room machines

There is no internet connectivity on any of the control room machines.

I have been trying to debug by tracing the cabling situation in the rack in the office area, and will update if/when this problem has been resolved. I had last come into the lab on Saturday and there was no problem then. There 40m wireless network servicing the office area seems to work fine.

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
12891   Fri Mar 17 14:49:09 2017 gautamUpdateLSCMCREFL condition pictures

I did a quick measurement of the beam size on the MC REFL PD today morning. I disabled the MC autolocker while this measurement was in progress. The measurement set up was as follows:

This way I was able to get right up to the heat sink - so this is approximately 2cm away from the active area of the PD. I could also measure the beam size in both the horizontal and vertical directions.

The measured and fitted data are:

The beam size is ~0.4mm in diameter, while the active area of the photodiode is 2mm in diameter according to the datasheet. So the beam is ~5x smaller than the active area of the PD. I couldn't find anything in the datasheet about what the damage threshold is in terms of incident optical power, but there is ~100mW on th MC REFL PD when the MC is unlocked, which corresponds to a peak intensity of ~1.7 W / mm^2...

Even though no optics were intentionally touched for this measurement, I quickly verified that the spot is centered on the MC REFL PD by looking at the DC output of the PD, and then re-enabled the autolocker.

Attachment 2: MCREFL_X.pdf
Attachment 3: MCREFL_Y.pdf
12890   Fri Mar 17 10:47:16 2017 SteveUpdateOptical Levers ETMX oplev laser replaced

JDSU 1103P. sn T8070866, made March 2007, output power 2.7 mW,  on pd 17,750 counts,

GV 17 March 3pm: I found the Innolight NPRO was off when I walked down to the X end earlier, possibly was accidentally tripped during the Oplev laser replacement. I turned it back on.

Quote:

 Quote: ETMX oplev laser is dead. It will be replaced this after noon. Sus damping recovered.

This 3 years old HeNe [ JDS 1103P, sn 351889 ]  has been dying for some time or just playing possum at age 1,126 days

I did not replace the ETMX oplev laser because I was unable to bring up the the C1ASC_ETMX_OPTLEV_SERVO  medm screen on laptops.

12889   Thu Mar 16 08:22:16 2017 SteveUpdateSUSETMX damping

Finally I see what kicks the sus damping off

Quote:

Huh? So should we ask them to put the container back? Or do you have some other theory about ETMX tripping that is not garbage related?

 Quote: ETMX sus damping recovered. Note: The giant metal garbage container was moved from the south west corner of CES months ago.

Attachment 1: laser_power_glitch.png
12888   Tue Mar 14 15:05:18 2017 SteveUpdateOptical Levershistory of ETMX oplev laser

 Quote: ETMX oplev laser is dead. It will be replaced this after noon. Sus damping recovered.

This 3 years old HeNe [ JDS 1103P, sn 351889 ]  has been dying for some time or just playing possum at age 1,126 days

I did not replace the ETMX oplev laser because I was unable to bring up the the C1ASC_ETMX_OPTLEV_SERVO  medm screen on laptops.

Attachment 1: ETMX_1103P_3y.png
12887   Tue Mar 14 10:56:33 2017 gautamUpdateCOCRC folding mirrors - coating optimization

Rana suggested including some additional terms to the cost function to penalize high sensitivity to deviations in the layer thickness (L). So the list of terms contributing to the cost function now reads:

1. Thermal noise - we use the proxy function from E0900068-v3 to do this
2. Deviation from target T @1064nm, p-pol
3. Deviation from target T @532nm, p and s-pol
4. HR Surface field
5. The ratio $\frac{d\mathcal{T}/\mathcal{T}}{dL/L}$ with dL/L = 1%, evaluated at 1064nm p-pol and 532nm p and s-pol (only the latter two for the AR side)

I did not include other sensitivity terms, like sensitivity to the refractive index values for the low and high index materials (which are just taken from GWINC).

There is still some arbitrariness in how I chose to weight the relative contributions to the cost function, but after some playing around, I think I have a solution that I think will work. Here are the spectral reflectivity and layer thickness plots for the HR and AR sides respectively.

HR side: for a 1% increase in the thickness of all layers, the transmission changes by 5% @ 1064nm p-pol and 0.5% @ 532nm s and p-pol

AR sidefor a 1% change in the thickness of all layers, the transmission changes by <0.5% @ 532nm s and p-pol

(substrate to the right of layer 38)

I've also checked that we need 19 layer pairs to meet the spec requirements, running the code with fewer layer pairs leads to (in particular) large deviations from the target value of 50ppm @ 1064nm p-pol.

Do these look reasonable?

Attachment 1: PR3_R_170313_1701.pdf
Attachment 2: PR3AR_123_Layers_170313_1701.pdf
Attachment 3: PR3AR_R_170313_1752.pdf
Attachment 4: PR3AR_123_Layers_170313_1752.pdf
12886   Tue Mar 14 10:40:30 2017 SteveUpdateSUSOSEM filters are in

We have 50 pieces in the clean cabinet.

Attachment 1: filters.jpg
12885   Tue Mar 14 09:08:11 2017 SteveUpdateOptical LeversETMX HeNe is dead

ETMX oplev laser is dead. It will be replaced this after noon. Sus damping recovered.

Attachment 1: this_morning.png
12884   Mon Mar 13 16:47:41 2017 SteveUpdatePEMY-arm air conditon belts replaced

The east end AC unit is arching over and running rough at CES. Called for mechanic.......

Both belts were replaced and the unit is running happily.

12883   Sat Mar 11 20:11:58 2017 johannesUpdateComputer Scripts / Programsloss script

Yarm script running on Pianosa. Still working on visualization of the ETMX lossmap.

 Quote: Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

12882   Fri Mar 10 19:48:56 2017 johannesUpdateComputer Scripts / Programsloss script

Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

12881   Fri Mar 10 18:00:22 2017 SteveUpdateGeneralattempted ETMY picture taking

Attachment 1: P3100044.JPG
Attachment 2: P3090024.JPG
12880   Fri Mar 10 11:37:25 2017 gautamUpdateComputer Scripts / Programsloss script

This was still running at ~9.30am today morning, at which point I manually terminated it after confirming with Johannes that it was okay to do so. Judging by the StripTool traces in the control room, the mode cleaner remained locked for most of the night, there should be plenty of usable data...

Note that I re-aligned the Y-arm (to experiment further with photo-taking) at about 9.30am, so the data after this time should be disregarded...

 Quote: loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.

12879   Thu Mar 9 22:28:11 2017 johannesUpdateComputer Scripts / Programsloss script

loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.

 Quote: I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

12878   Thu Mar 9 20:38:19 2017 ranaConfigurationIOOMC lock acquisition settings changed; no more HOM locks

The MC was sort of misaligned. It was locking on some vertical HOMs. So I locked it and aligned the suspensions to the input beam (not great; we should really align the input beam to the centered spots on the MC mirrors).

With the HOMs reduced I looked at the MC servo board gains which Guatam has been fiddling with. It seems that since the Mod Depth change we're getting a lot more HOM locks. You can recognize this by seeing the longish stretches on the strip tool where FSS-FAST is going rail-to-rail at 0.03 Hz for many minutes. This is where the MC is locked on a HOM, but the autolocker still thinks its unlocked and so is driving the MC2 position at 0.03 Hz to find the TEM00 mode.

I lowered the input gain and the VCO gain in the mcdown script and now it very rarely locks on a HOM. The UGF in this state is ~3-4 kHz (I estimate), so its just enough to lock, but no more. I tested it by intentionally unlocking ~15 times. It seems robust. It still ramps up to a UGF of ~150 kHz as always. 'mcdown' commited to SVN.

12877   Thu Mar 9 20:11:04 2017 KojiUpdateGeneralattempted ETMY picture taking

The attached is the ETMY image with the single arm locked. This was the best I could do. Here is the recipe

• Turn on SP570UZ
• Switch to "M" mode (Manual aperture and exposure)
• Set the aperture to be the widest (smallest F number) and the exposure to be maximum (15 second).
• Switch to AF mode by the lens side switch
• Use the lens dial to adjust the zoom until the OSEMs fill the central 1/3 box (i.e. 1/9 area of the field of view). If you zoom more, you can't focus the spot later.
• Use menu button to switch to ISO1600 (You are now capable to see the beam spot)
• Switch to MF mode by the lens side switch
• Use the lens dial to adjust the focus to have the sharpest image of the spot. This can be achieved at the focal distance of ~1m
• Use menu button to switch back to ISO64
• Push the shutter (I didn't use it, but you should be able to use 2sec timer)
Attachment 1: P3090032.JPG
12876   Thu Mar 9 17:26:43 2017 SteveUpdateGeneralattempted ETMY picture taking

I removed the video monitoring can and replaced it with Olympus SP-570UZ camera. It has no IR blocker. The OSEM light are dominant because I can not zoom in more.

I left the camera in place so you can try it. Leave the LEXAN plate on the glass window so no accident can happen. The illuminator is on and you can turn it off-on with the manual switch, close to the camera. Camera manual is on my desk.

12875   Thu Mar 9 15:25:12 2017 KojiUpdateGeneralIMC/XYarms aligned/locked

As per Steve's request, I've checked the alignment of the IMC and the arms. These three cavities are locked and aligned.

12874   Wed Mar 8 18:18:51 2017 johannesUpdateComputer Scripts / Programsloss script

I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

12873   Wed Mar 8 15:28:37 2017 SteveUpdateOptical Leversoplev laser RIN

Gautam and Steve,

 Quote: Corrected oplev laser RIN plot at day 3 RXA: to measure RIN, the lever arm should be really short, not long. the beam should be 3x smaller than the active area of the diode the specular beam should be dumped on a razor dump. we need to make a summary page for HeNe laser testing so that we can see 24 hour specgrams of these things for ~3-4 lasers at the same time. We should add specgram stuff for the existing HeNe SUM channels on the active OLs. GV: The channel the PD Steve is using is hooked up to C1:ALS-FC_X_F_IN. As I found out today, there can be considerable RF pickup between the C1:ALS-FC_X_F_IN and C1:ALS-FC_Y_F_IN channels, which share a common 4-pin LEMO cable - this is because the rise time of the square wave output of the Wenzel dividers is <1us, so suitability of this particular channel for the RIN measurement set up has to be reconsidered. Perhaps we can use one of the six spare PEM channels over at 1X6.

We did the following:

1, switched data channel  from  C1:ALS-FC_X_F_IN to C1:PEM-MIC_1_OUT_DQ   Actual connection at 1X7 rack, input C17

Tested channel with 1Hz, 100 mV sine wave through DV

2, placed BS into the beam path so the reflected value on the PDA100A 0.1mW,  beam od ~1mm, beam path lenght 11 cm, gain 20dB 3.7Vdc

The full output of this 1103P 2.8 mW was saturating the PDA100A

Summery :finding it to be too good to be this good

Attachment 1: RIN.jpg
Attachment 2: RIN_1103P_rotated.pdf
12872   Tue Mar 7 15:17:19 2017 SteveBureaucracyGeneralproperty tag

Property tag found.

Attachment 1: property_tag.jpg
12871   Mon Mar 6 16:32:36 2017 SteveUpdateGeneralold NPRO

16 years old Lightwave NPRO M126-1064-700, sn 415 power output is tripping continously to zero.

The Lightwave Controller 125/126-OPN-POS sn516 was used in this test. Settings were lowered to close to nominal values without any success.

One can not determine what is broken: head or controller. This NPRO head was under Manasa's desk.

12870   Mon Mar 6 14:47:49 2017 gautamUpdateSummary PagesCode status check script modified

For a few days now, the "code status" page has been telling us that the summary pages are DEAD, even though the pages themselves seemed to be generating plots. I logged into the 40m shared account on the cluster and checked the status of the condor job (with condor_q), and did not find anything odd there. I decided to consult Max, who pointed out that the script that checks the code status (/home/40m/DetectorChar/bin/checkstatus) was looking for a particular string in the log files ("gw_daily_summary"), while the recent change in the default output of condor_q meant that the string actually being written to the log files was "gw_daily_summa". This script has now been modified to look for instances of "gw_daily" instead, and so the code status indicator seems to be working again...

The execution of the summary page scripts has also been moved back to pcdev1 (from pcdev2, where it was moved to temporarily because of some technical problems with pcdev1).

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.

12868   Mon Mar 6 09:12:59 2017 SteveUpdatesafety crane inspection 2017

All 3 cranes inspected by professional Fred Goodbar of Konecranes and load tested with 450 lbs at max reach on Friday, March 3, 2017

Attachment 1: inspection_2017.jpg
12867   Sun Mar 5 12:41:23 2017 gautamUpdateIMCWFS servo-steppin

I've been sitting on some data for a while now which I finally got around to plotting. Here is a quick summary:

Attachment #1: I applied a step input to the offset of each of the six WFS loops and observed the step response. The 1/e time constant for all 4 WFS loops is <10s suggesting a bandwidth a little above 0.1Hz. However, the MC2 P and Y loops have a much longer time contant of ~150s. Moreover, it looks like the DC centering of the spot on the QPD isn't great - the upper two quadrants (as per the MEDM screen) have ~3x the cts of the lower pair.
I did not (yet) try increasing the gain of this loop to see if this could be mitigated. I accidentally saved this as a png, I will put up the pdf plot

Attachment #2: This is a comparison of the WFS error signals with the loops engaged (solid lines) vs disabled (dashed lines). Though these measurements were taken at slightly different times, they are consistent with the WFS loop bandwidths being ~0.1Hz.

Attachment #3: Comparison of the spectra of the testpoint channels and their DQ counterparts at the same time which are sampled at 512Hz. It does not look like there is any dramatic aliasing going on, although it is hard to tell what exactly is the order of the digital AA filter implemented by the RCG. Further investigation remains to be done... For reference, here are some notes: T1600059, T1400719

GV 7 March 2017 6pm: It looks like we use RCG v2.9.6, so it should be the latter document that is applicable. I've been going through some directories to try and find the actual C-code where the filter coeffs are defined, but have been unsuccessful so far...

 Quote: I will update with the in-loop error signal spectra, which should give us some idea of the loop bandwidth. I will look into lowering the sampling rate, and how much out-of-band power is aliasing into the 0-256 Hz band and update with my findings.

Attachment 1: WFS_stepping.png
Attachment 2: WFS_comparisons.pdf
Attachment 3: WFSdigitalAA.pdf
12866   Fri Mar 3 17:24:21 2017 SteveUpdateOptical Leversoplev laser RIN

Corrected oplev laser RIN plot at day 3

RXA:

1. to measure RIN, the lever arm should be really short, not long.
2. the beam should be 3x smaller than the active area of the diode
3. the specular beam should be dumped on a razor dump.
4. we need to make a summary page for HeNe laser testing so that we can see 24 hour specgrams of these things for ~3-4 lasers at the same time.
5. We should add specgram stuff for the existing HeNe SUM channels on the active OLs.

GV: The channel the PD Steve is using is hooked up to C1:ALS-FC_X_F_IN. As I found out today, there can be considerable RF pickup between the C1:ALS-FC_X_F_IN and C1:ALS-FC_Y_F_IN channels, which share a common 4-pin LEMO cable - this is because the rise time of the square wave output of the Wenzel dividers is <1us, so suitability of this particular channel for the RIN measurement set up has to be reconsidered. Perhaps we can use one of the six spare PEM channels over at 1X6.

Attachment 1: 3march17.pdf
12865   Thu Mar 2 20:32:18 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box

[gautam, lydia]

I pulled out the box and found the problem: the +24 V input to the amplifier was soldered messily and shorted to ground. So I resoldered it and tested the box on the bench (drove with Marconi and checked that the gain was correct on scope). This also blew the fuse where the +24 power is distributed, so I replaced it. The box is reinstalled and the mode cleaner is locking again with the WFS turned on.

Since I tried to keep the cable lengths the same, the demod phases shouldn't have changed significantly since the amplifier was first installed. Gautam and I checked this on a scope and made sure the PDH signals were all in the I quadrature. In the I vs. Q plot, we did also see large loops presumably corresponding to higher order mode flashes.

 Quote: Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.

12864   Thu Mar 2 17:58:45 2017 ranaUpdateOptical Leversoplev laser RIN

This measurement looks bogus - the difference between dark and not dark is not significant enough to believe. Need to figure out how to match better into the ADC range.

12863   Thu Mar 2 13:59:04 2017 SteveUpdateOptical Leversoplev laser RIN

The laser got much better at low frequency as it warmed up. This laser is almost as good as the electronics?

Dark noise cal was the same today as it was 2 days ago.

Attachment 1: 1103P@2d.png
12862   Wed Mar 1 23:56:09 2017 gautamUpdateIMCFront panel for 29.5 MHz amplifier box

The alignment wasn't disturbed for the photo-taking - I just re-checked that the spot is indeed incident on the MC REFL PD. MC REFL appeared dark because I had placed a physical beam block in the path to avoid accidental PSL shutter opening to send a high power beam during the photo-taking. I removed this beam block, but MC wouldn't lock. I double checked the alignment onto the MC REFL PD, and verified that it was ok.

Walking over to the 1X1, I noticed that the +24V Sorensen that should be pushing 2.9A of current when our new 29.5MHz amplifier is running, was displaying 2.4A. This suggests the amplifier is not being powered. I toggled the power switch at the back and noticed no difference in either the MC locking behaviour or the current draw from the Sorensen.

To avoid driving a possibly un-powered RF amplifier, I turned off the Marconi and the 29.5MHz source. I can't debug this anymore tonight so I'm leaving things in this state so that Lydia can check that her box works fine...

 Quote: I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again.

12861   Wed Mar 1 21:15:40 2017 LydiaUpdateIMCFront panel for 29.5 MHz amplifier box

I installed the front panel today. While I had the box out I also replaced the fast decoupling capacitor witha 0.1 uF ceramic one. I made SMA cables to connect to the feedthroughs and amplifier, trying to keep the total lengths as close as possible to the cables that were there before to avoid destroying the demod phases Gautam had found. I didn't put in indicator lights in the interest of getting the mode cleaner operational again ASAP.

I turned the RF sources back on and opened the PSL shutter. MC REFL was dark on the camera; people were taking pictures of the PD face today so I assume it just needs to be realigned before the mode cleaner can be locked again.

I've attached a schematic for what's in the box, and labeled the box with a reference to this elog.

Attachment 1: RF_amp_(1).pdf
12860   Wed Mar 1 17:25:28 2017 SteveUpdateLSCMCREFL condition pictures

Gautam and Steve,

Our MCREFL rfpd C30642GH 2x2mm beeing investigated for burned spots.

Atm1,           unused -  brand new pd

Atm2,3,4       MCREFL in place was not moved

More pictures will be posted on 40m Picassa site later.

Attachment 1: IMG_3646.JPG
Attachment 2: mcRefl_1.jpg
Attachment 3: mcRefl_3.jpg
Attachment 4: mcRefl_5.jpg
12859   Wed Mar 1 16:00:41 2017 gautamUpdateComputer Scripts / ProgramsMatlab R2016b installed

Since it would be nice to have the latest version of Matlab, with all its swanky new features (?), available on the control room computers and Optimus, I downloaded Matlab R2016b and activated it with the Caltech Campus license. I installed it into /cvs/cds/caltech/apps/linux64/matlab16b. Specifically, I would like to run the coating optimization code on Optimus, where I can try giving it more stringent convergence criterion to see if it converges to a better spot.

I trust that this way, we don't interfere with any of the rtcds stuff.

If I've done something illegal license-wise or if this is likely to cause havoc, please point me to what is the correct way to do this.

GV 18 Mar 2017: Though I installed this using the campus network license key, this seems to only work on Rossa. If I run it on the other control room machines/Optimus, it throws up a licensing error. I will check with Larry W. as to how to resolve this...

12858   Wed Mar 1 08:28:04 2017 SteveUpdateOptical Leversoplev laser RIN

Gautam and Steve,

New JDSU 1103P HeNe oplev laser RIN was measured on the SP table with cover on.

This is the beginning of an effort to improve oplev laser noise.

Attachment 1: RIN_1103P.png
Attachment 2: RIN_HeNe.png
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

12856   Tue Feb 28 18:25:22 2017 ranaUpdatePEMETMX damping recovered

Huh? So should we ask them to put the container back? Or do you have some other theory about ETMX tripping that is not garbage related?

 Quote: ETMX sus damping recovered. Note: The giant metal garbage container was moved from the south west corner of CES months ago.

12855   Tue Feb 28 08:04:48 2017 steveUpdatePEMETMX damping recovered

ETMX sus damping recovered.

Note: The giant metal garbage container was moved from the south west corner of CES months ago.

 Quote: ETMX sus damping recovered.  PSL enclousure is dusty at 20V rotation speed. Rainy days as outside condition.

Attachment 1: ETMX.png
12854   Tue Feb 28 01:28:52 2017 johannesUpdateComputersc1psl un-bootable

It turned out the 'ringing' was caused by the respective other ETM still being aligned. For these reflection measurements both test masses of the other arm need to be misaligned. For the ETM it's sufficient to use the Misalign button in the medm screens, while the ITM has to be manually misaligned to move the reflected beam off the PD.

I did another round of armloss measurements today. I encountered some problems along the way

• Some time today (around 6pm) most of the front end models had crashed and needed to be restarted GV: actually it was only the models on c1lsc that had crashed. I noticed this on Friday too.
• ETMX keeps getting kicked up seemingly randomly. However, it settles fast into it's original position.

General Stuff:

• Oscilloscope should sample both MC power (from MC2 transmitted beam) and AS signal
• Channel data can only be loaded from the scope one channel at a time, so 'stop' scope acquisition and then grab the relevant channels individually
• Averaging needs to be restarted everytime the mirrors are moved triggering stop and run remotely via the http interface scripts does this.

Procedure:

1.     Run LSC Offsets
2.     With the PSL shutter closed measure scope channel dark offsets, then open shutter
3.     Align all four test masses with dithering to make sure the IFO alignment is in a known state
4.     Pick an arm to measure
5.     Turn the other arm's dither alignment off
6.     'Misalign' that arm's ETM using medm screen button
7.     Misalign that arm's ITM manually after disabling its OpLev servos looking at the AS port camera and make sure it doesn't hit the PD anymore.
8.     Disable dithering for primary arm
9.     Record MC and AS time series from (paused) scope
10.     Misalign primary ETM
11.     Repeat scope data recording

Each pair of readings gives the reflected power at the AS port normalized to the IMC stored power:

$\widehat{P}=\frac{P_{AS}-\overline{P}_{AS}^\mathrm{dark}}{P_{MC}-\overline{P}_{MC}^\mathrm{dark}}$

which is then averaged. The loss is calculated from the ratio of reflected power in the locked (L) vs misaligned (M) state from

$\mathcal{L}=\frac{T_1}{4\gamma}\left[1-\frac{\overline{\widehat{P}_L}}{\overline{\widehat{P}_M}} +T_1\right ]-T_2$

Acquiring data this way yielded P_L/P_M=1.00507 +/- 0.00087 for the X arm and P_L/P_M=1.00753 +/- 0.00095 for the Y arm. With $\gamma_x=0.832$ and $\gamma_x=0.875$ (from m1=0.179, m2=0.226 and 91.2% and 86.7% mode matching in X and Y arm, respectively) this yields round trip losses of:

$\mathcal{L}_X=21\pm4\,\mathrm{ppm}$  and  $\mathcal{L}_Y=13\pm4\,\mathrm{ppm}$, which is assuming a generalized 1% error in test mass transmissivities and modulation indices. As we discussed, this seems a little too good to be true, but at least the numbers are not negative.

12853   Mon Feb 27 15:33:10 2017 SteveUpdateVACRGA scan at day 130

Valve configuration: vacuum normal

Vacuum envelope: 23.5 C

Attachment 1: rgascan@130d.png
12852   Fri Feb 24 20:38:01 2017 johannesUpdateComputersc1psl boot-stall culprit identified

[Gautam, Johannes]

c1psl finally booted up again, PMC and IMC are locked.

Trying to identify the hickup from the source code was fruitless. However, since the PMCTRANSPD channel acqusition failure occured long before the actual slow machine crashed, and since the hickup in the boot seemed to indicate a problem with daughter module identification, we started removing the DIO and DAQ modules:

1. Started with the ones whose fail LED stayed lit during the boot process: the DIN (XVME-212) and the three DACs (VMIVME4113). No change.
2. Also removed the DOUT (XVME-220) and the two ADCs (VMIVME 3113A and VMIVME3123). It boots just fine and can be telnetted into!
3. Pushed the DIN and the DACs back in. Still boots.
4. Pushed only VMIVME3123 back in. Boot stalls again.
5. Removed VMIVME3123, pushed VMIVME 3113A back in. Boots successfully.
6. Left VMIVME3123 loose in the crate without electrical contact for now.
7. Proceeded to lock PMC and IMC

The particle counter channel should be working again.

• VMIVME3123 is a 16-Bit High-Throughput Analog Input Board, 16 Channels with Simultaneous Sample-and-Hold Inputs
• VMIVME3113A is a Scanning 12-Bit Analog-to-Digital Converter Module with 64 channels

/cvs/cds/caltech/target/c1psl/psl.db lists the following channels for VMIVME3123:

Channels currently in use (and therefore not available in the medm screens):

• C1:PSL-FSS_SLOW_MON
• C1:PSL-PMC_PMCERR
• C1:PSL-FSS_SLOWM
• C1:PSL-FSS_MIXERM
• C1:PSL-FSS_RMTEMP
• C1:PSL-PMC_PMCTRANSPD

Channels not currently in use (?):

• C1:PSL-FSS_MINCOMEAS
• C1:PSL-FSS_RCTRANSPD
• C1:PSL-126MOPA_126MON
• C1:PSL-126MOPA_AMPMON
• C1:PSL-FSS_TIDALINPUT
• C1:PSL-FSS_TIDALSET
• C1:PSL-FSS_RCTEMP
• C1:PSL-PPKTP_TEMP

There are plenty of channels available on the asynchronous ADC, so we could wire the relevant ones there if we done care about the 16 bit synchronous sampling (required for proper functionality?)

Alternatively, we could prioritize the Acromag upgrade on c1psl (DAQ would still be asynchronous, though). The PCBs are coming in next Monday and the front panels on Tuesday.

The (nameless?) Windows 7 laptop that lives near MC2 and is used for the USB microscope was used for interfacing with c1psl. No special drivers were necessary to use the USB to RS232 adapter, and the RJ45 end of the grey homemade DB9 to RJ45 cable was plugged into the top port which is labeled "console 1". I downloaded the program "CoolTerm" from http://freeware.the-meiers.org/#CoolTerm, which is a serial protocol emulator, and it worked out of the box with the adapter. The standard settings fine worked for communicating with c1psl, only a small modification was necessary: in Options>Terminal make sure that "Enter Key Emulation" is set from "CR+LF" to "CR", otherwise each time 'Enter' is pressed it is actually sent twice.

12851   Thu Feb 23 19:44:48 2017 johannesUpdateComputersc1psl un-bootable

Yes, that was one of the things that I wanted to look into. One thing Gautam and I did that I didn't mention was to reconnect the SRM satellite box and move the optic around a bit, which didn't change anything. Once the c1psl problem is fixed we'll resume with that.

 Quote: The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

Speaking of which:

Using one of the grey RJ45 to D-Sub cables with an RS232 to USB adapter I was able to capture the startup log of c1psl (using the usb camera windows laptop). I also logged the startup of the "healthy" c1aux, both are attached. c1psl stalls at a point were c1aux starts testing for present vme modules and doesn't continue, however is not strictly hung up, as it still registers to the logger when external login attempts via telnet occur. The telnet client simply reports that the "shell is locked" and exits. It is possible that one of the daughter cards causes this. This seems to happen after iocInit is called by the startup script at /cvs/cds/caltech/target/c1psl/startup.cmd, as it never gets to the next item "coreRelease()". Gautam and I were trying to find out what happends inside iocInit, but it's not clear to us at this point from where it is even called. iocInit.c and compiled binaries exist in several places on the shared drive. However, all belong to R3.14.x epics releases, while the logfile states that the R3.12.2 epics core is used when iocInit is called.

Next we'll interrupt the autoboot procedure and try to work with the machine directly.

Attachment 1: slow_startup_logs.tar.gz
12850   Thu Feb 23 18:52:53 2017 ranaUpdateComputersc1psl un-bootable

The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

ELOG V3.1.3-