40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 252 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  14861   Fri Sep 6 11:56:44 2019 aaronHowToCDSWFS discussion, restarting CDS

Rebooting

I reset c1lsc, c1sus, and c1ioo.

I noticed that the script gives the command 'ssh c1XXX', but we have been getting no route to host using this command. Instead, the machines are currently only reachable as c1XXX.martian. I'm not sure why this is, so I just appended .martian in rebootC1LSC.sh

This time, the script does run. I did get 'no route to host' on c1ioo, so I think I need to reset that machine again. After reset, the script failed to login to c1ioo and c1lsc.

Fri Sep 6 13:09:05 2019

After lunch, I reset the computers again, and try the script again. There is again no route to host for c1ioo. I'm going inside to shutoff the power to c1ioo, since the reset buttom seems to not be working. I still can't login from nodus, so I'm bringing a keyboard and monitor over to plug in directly.

On reset, c1ioo repeatedly reaches the screen in attachment 1, before going black. Holding down shift or ctrl+alt+f1 doesn't get me a command prompt. After waiting/searching the elog for >>3 min, we decided to follow these instructions to cycle the power of c1ioo. The same problem recurred following power up. I found online some instructions that the SunSystems 4600 can hang during reboot if it has become too hot ("reboot during a thermal shutdown"); I did notice that the temperature light was on earlier in this procedure, so perhaps that is the problem. I followed the wiki instructions to shut down the computer again (pressed power button, unplugged 4 power supplies from back of machine), and left it unplugged for 10-30 min (Fri Sep 6 14:46:18 2019 ).

Fri Sep 6 15:03:31 2019

Rana plugged in the power supplies and reset the machine again.

Fri Sep 6 16:30:37 2019

c1ioo is still unreachable! I pressed reset once, and the reset button flashes white. The yellow warning light is still on.

Fri Sep 6 16:54:21 2019

The reset light has stopped flashing, but I still can't access c1ioo. I reset once more, this time watching c1ioo on a monitor directly. I'm still seeing the same boot screen repeatedly. I do see that CPU0 is not clocking, which seems weird.

Troubleshooting CPU module

Following gautam's elog here, I found the Sun Fire X4600 manual for locating faulty CPUs. After the white reset light stopped flashing, I held down the power button to turn off the system. Before shutdown, all of the CPU displayed amber lights; after shutdown, only the leftmost CPU (as viewed from the back, presumably CPU0) displays an amber light. The manual says this is evidence that the CPU or DIMM is faulty. Following the manual, I remove the standby power, then checked out these Instructions for replacing the CPU to remove the CPU; Gautam also has done this before.

Fri Sep 6 20:09:01 2019 Fri Sep 6 20:09:02 2019

I pulled the leftmost CPU module out, following the instructions above. The CPU module matches the physical layout and part number of the Sun Fire X4600 M2 8-DIMM CPU module; pressing the fault reminder light gives amber indicators at the DIMM ejectors, indicating faulty DIMMs (see). The other indicator LEDs did not illuminate.

I located several spare DIMMs in the digital cabinet along Y arm (and a couple with misc computer components in the control room), but didn't find the correct one for this CPU module. The DIMM is Sun PN 371-1764-01; I found it online and ordered eight. Please let me know if this is incorrect.

To protect the CPU module, I've put it in an ESD safe bag with some bubble wrap and a note. It's on the E shop bench.

Conclusion: Need new DIMM, didn't find the correct part but ordered it.

  14862   Fri Sep 6 15:12:49 2019 KojiHowToCDSWFS discussion, restarting CDS

Assuming you are at pianosa, /etc/resolv.conf is like

# Generated by NetworkManager
nameserver 192.168.113.104
nameserver 8.8.8.8

But this should be like

nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 8.8.8.8

search martian

as indicated in https://nodus.ligo.caltech.edu:8081/40m/14767

I did this change for now. But this might get overridden by Network Manager.

  6992   Thu Jul 19 02:32:45 2012 JenneUpdateIOOWFS don't come on automatically??

The MC unlocked ~20 min ago, correlated with 2 consecutive earthquakes in Mexico.  The MC came back fine after a few minutes, but the WFS never engaged.  I turned them on by hand.  I think that Yuta mentioned once that he also had to turn the WFS on by hand.  There may be a problem in the unlock/relock catching that needs to be looked at, to make sure the WFS come back on automatically.

Also, someone (Masha and I) should look at the seismic BLRMS.  I have suspected for a few days that they're not telling us everything that we want to know.  Usually, if there's an earthquake close enough / big enough that it pops the MC out of lock, it is clear from the BLRMS that that's what happened, but right now it doesn't look like much of anything....just kind of flat for hours.

  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.

  15741   Sat Dec 19 20:24:25 2020 gautamUpdateElectronicsWFS hardware install

I installed 4 chassis in the rack 1X2 (characterization on the E-bench was deemed satisfactory, I will upload the analysis later). I ran out of hardware to make power cables so only 2 of them are powered right now (1 32ch AA chassis and 1 WFS head interface). The current limit on the +24V Sorensens was raised to allow for similar margin to the limit with the increased current draw.

Remaining work:

  1. Make 2 more power cables for ISC whitening chassis and quad demod chassis.
  2. Make a 2x 4pin LEMO-->DB9 cable to digitize the FSS and PMC diagnostic channels with the new AA chassis. If RnD cables has a very short turnaround time, might be worth it to give this to them as well.
  3. Connect ADC1 on c1ioo machine to new AA chassis (transfer SCSI cable from existing AA unit to the new one). This will necessarily involve some model changes as well.
  4. Make a short cable to connect 55 MHz output from RFsource box to the LO input on the quad demod chassis.
  5. Install the WFS head on the AS table at a suitable location. Probably will need a focusing lens as well. 
  6. Connect WFS head to the signal processing electronics (the cables were already laid out by Jordan and I).
  7. Make the necessary CDS model changes (WFS filters, matrices, servos etc). I personally don't see the need for a new model but if anyone feels strongly about separating the IMC WFS and AS WFS we can set up another model.
  8. Commission the system.

While I definitely bumped various cables, I don't seem to have done any lasting damage to the CDS system (the RFM errors remain of course).

  14945   Mon Oct 7 14:51:20 2019 aaronUpdateElectronicsWFS head RF measurements

Mon Oct 7 14:51:53 2019. I closed the PSL shutter to measure the WFS head responsivity.

I made a thru calibration as in this elog, treating laser, reference PD, and WFS RF output as a three-port device. The DC current supplied to the laser is 20.0 mA in all cases. The Agilent spectrum analyzer supplies a -10 dBm excitation to Jenne laser's AM port, and A/B is measured with 20dB attenuation on each input port. Results are in /users/aaron/WFS/data/191007/. The calibration had 100 averages, all other measurements 32 averages; other parameters found in the yml file, same folder as the data.

Measurement Reference PD DC (V) WFS Segment DC (V) WFS Segment DC, beam blocked (V) File Notes
WFS 1 Segment 1 1.86 0.79 -0.23
TFAG4395A_07-10-2019_154446.txt
 
WFS 1 Segment 2 1.86 0.72 -0.30 TFAG4395A_07-10-2019_155017.txt  
WFS 1 Segment 3 1.86 0.79 -0.21
TFAG4395A_07-10-2019_155645.txt
 
WFS 1 Segment 4 1.86 0.70 -0.30
TFAG4395A_07-10-2019_160334.txt
TFAG4395A_07-10-2019_160847.txt
I noticed the BS-PRM illuminator was on, and turned it off for the second measurement
WFS 2 Segment 1 1.86 0.56 -0.38 TFAG4395A_07-10-2019_162533.txt  
WFS 2 Segment 2 1.86 0.71 -0.21
TFAG4395A_07-10-2019_163402.txt
 
WFS 2 Segment 3 1.86 0.68 -0.28 TFAG4395A_07-10-2019_164152.txt  
WFS 2 Segment 4 1.86 0.57 -0.42 TFAG4395A_07-10-2019_164745.txt  

 

I normalized the result by the difference between the dark and bright DC levels of each segment.

Mon Oct 7 17:29:58 2019 opened PSL shutter.

  14951   Tue Oct 8 16:00:06 2019 aaronUpdateElectronicsWFS head RF measurements

I simulated this circuit with zero, but haven't gotten the results to match the measurements above.

Removing the DC readout chain from the circuit does not affect the AC response.
Perhaps something to do with the (currently unmodeled) capacitance of the diode? I think this forms a necessary part of the resonant circuit. The gain is also suspiciously low.
Edit: Indeed, simply adding the 'typical' shunt capacitance (9pF) and a small series resistor (10 Ohm) gives the right qualitative response
The python notebook is in /users/aaron/WFS/electronics.
The DC response flattens off at ~20dB by ~mHz, which also seems longer than the timescales I saw while measuring; I'm not sure I have some of the AD827 parameters correct (eg 'delay')
 
I came across this nice note on photodiodes.
 
 
  14959   Wed Oct 9 12:15:05 2019 ranaUpdateElectronicsWFS head RF measurements

It would be good if you and Shruti can look at how to change the parameters in Zero so as to do a fit to the measured data. Usually, in scipy.optimize we give it a function with some changeable params, so maybe there's a way to pass params to a zero object in that way. I think Ian and Anchal are doing something similar to their FSS Pockel's cell simulator.

  15731   Thu Dec 10 22:46:57 2020 gautamUpdateASCWFS head assembled

The assembly of the head is nearly complete, I thought I'd do some characterization before packaging everything up too nicely. I noticed that the tapped holes in the base are odd-sized. According to the official aLIGO drawing, these are supposed to be 4-40 tapped, but I find that something in between 2-56 and 4-40 is required - so it's a metric hole? Maybe we used some other DCC document to manufacture these parts - does anyone know the exact drawings used? In the meantime, the circuit is placed inside the enclosure with the back panel left open to allow some tuning of the trim caps. The front panel piece for mounting the SMA feedthroughs hasn't been delivered yet so hardware-wise, that's the last missing piece (apart from the aforementioned screws).

Attachment #1 - the circuit as stuffed for the RF frequencies of relevance to the 40m.

Attachment #2 - measured TF from the "Test Input" to Quadrant #1 "RF Hi" output.

  • There is reasonable agreement, but not sure what to make of the gain mismatch at most frequencies.
  • The photodiode itself hasn't been installed yet, so there will be some additional tuning required to account for the interaction with the photodiode's junction capacitance.
  • I noticed that the Qs of the resonances in between the notches is pretty high in this config, but the SPICE model also predicts this, so I'm hopeful that they will be tamed once the photodiode is installed.
  • One thing that is worrying is the feature at ~170 MHz. Could be some oscillation of the LM opamp. All the aLIGO WFS test procedure documentation shows measurements only out to 100 MHz. Should we consider increasing the gain of the preamp from x10 to x20 by swapping the feedback resistor from 453 ohms to 1 kohm? Is this a known issue at the sites
  • Any other comments?

Update 11 Dec: For whatever reason, whoever made this box decided to tap 4-40 holes from the bottom (i.e. on the side of the base plate), and didn't thread the holes all the way through, which is why I was unable to get a 4-40 screw in there. To be fair the drawing doesn't specify the depth of the 4-40 holes to be tapped. All the taps we have in the lab have a maximum thread length of 9/16" whereas we need something with at least 0.8" thread length. I'll ask Joe Benson at the physics workshop if he has something I can use, and if not, I'll just drill a counterbore on the bottom side and use the taps we have to go all the way through and hopefully that does the job.

The front panel I designed for the SMA feedthroughs arrived today. Unfortunately, it is impossible for the D-sub shaped holes in this box to accommodate 8 insulated SMA feedthroughs (2 per quadrant for RF low and RF high) - while the actual SMA connector doesn't occupy so much space, the plastic mold around the connector and the nut to hold it are much too bulky. For the AS WFS application, we will only need 4 so that will work, but if someone wants all 8 outputs (plus an optional 9th for the "Test Input"), a custom molded feedthrough will have to be designed. 

As for the 170 MHz feature - my open loop modeling in Spice doesn't suggest a lack of phase margin at that frequency so I'm not sure what the cause is there. If this is true, just increasing the gain won't solve the issue (since there is no instability at least by the phase margin metric). Could be a problem with the "Test Input" path I guess. I confirmed it is present in all 4 quadrants.

  15736   Thu Dec 17 15:23:56 2020 gautamUpdateASCWFS head characterization

Summary:

I think the WFS head performs satisfactorily.

  • The (input-referred) dark noise level at the operating frequency of 55 MHz is ~40pA/rtHz (modelled) and ~60 pA/rtHz (measured, converted to input-referred). See Attachment #1. Attachment #5 has the input referred current noise spectral densities, and a few representative shot noise levels.
  • The RF transimpedance gain at the operating frequency is ~500 ohms when driving a 50 ohm load (in good agreement with LTspice model). See Attachment #2 and Attachment #3.
  • The resonant gain to notch ratios are all > 30 dB, which is in line with numbers I can find for the WFS installed at the sites (and in good agreement with the LTspice model as well).
  • There are a few lines visible in the noise measurement. But these are small enough not to be a show-stopper I think.

Details and remarks:

  1. Attachment #4 shows a photo of the setup. 
    • The QPD used was S/N #84.
    • The heat sinks have a bunch of washers because the screw holes were not tappe at time of manufacture.
    • There isn't space to have 8 SMA feedthroughs in the D-shaped cutouts, so we can only have the 4 "RF HI" outputs without some major metalwork.
    • C9 has been remvoed in all channels (to isolate the "TEST INPUT").
  2. I found that some quadrants displayed a ~35 MHz sine-wave of a few mV pk-pk when I had the back of the enclosure off (for tuning the notches). The hypothesis is that this was due to some kind of stray capacitance effect. Anyways, once I closed everything up, for the noise measurement, this peak was no longer visible. With an HP8447A preamp, I measured an RMS voltage of ~2mV rms on an oscilloscope. After undoing the 20 dB gain of the amplifier, each quadrant has an output voltage noise of ~200 uVrms (as returned by the "measure" utility on the scope, I don't know the specifics of how it computes this). Point is, there wasn't any clear sine-wave oscillations like I saw on two channels when the lid was off. 
  3. Some of the lines are present during some measurement times but not others (e.g. Q4 blue vs red curve in Attachment #1). I was doing this work in the elec-bench area of the lab, right next to the network switches etc so not exactly the quietest environment. But anyway, I don't see anything in these measurements that suggest something is seriously wrong.
  4. In the transfer function measurements, above 150 MHz, there are all sorts of features. But I think this is a measurement artefact (stray cable capacitance etc) and not anything real in the RF signal path. Koji saw similar effects I believe, and I didn't delve further into it.
  5. The dark noise of the circuit is such that to be shot noise limited, each quadrant needs 10 mA of DC photocurrent. The light bulb we have has a max current rating of 0.25A, with which I could only get 3 mA DC per quadrant. So the 55 MHz sideband power needed to be shot noise limited is ~50 mW - we will never have such high power. But I think to have better performance will need a major re-work of the circuit design (finite Qs of inductors, capacitors etc).
  6. Regarding the transimpedance gains - in my earlier plots, I omitted the 50ohm input impedance of the AG4395A network analyzer. The numbers I report here are ~half of those earlier in this thread for this reason. In any case, I think this number is what is important, since the ADT-1-1 on the demod board RF input has an input impedance of 50ohm. 
  7. Regarding grounding - the RF ground on the head is actually isolated from the case pretty well. Two locations of concern are (i) the heat sinks for the voltage regulator ICs and (ii) the DB15 connector shield. I've placed electrically insulating (but thermally conducting) pads from TO220 mounting kits between both sets of objects and the case. However, for the Dsub connector, the shape of the pad doesn't quite fit all the way round the connector. So if I over-tighten the 4-40 mounting bolts, at some point, the case gets shorted to the RF ground, presumably because the connector deforms slightly and touches the case in a spot where I don't have the isolating pad installed. I think I've realized a tightness that is mechanically satisfying but electrically isolating.
  8. I will do the fitting at my leisure but the eye-fit is already suggesting that things are okay I think.

If the RF experts see some red flags / think there are more tests that need to be performed, please let me know. Big thanks to Chub for patiently supporting this build effort, I'm pleasantly surprised it worked.

  17048   Fri Jul 29 22:37:54 2022 KojiUpdateIOOWFS investigation

I wanted to check what's wrong with the WFS.

I played with MC2 misalignment to check the error signals.
MC2 pitch and yaw misalignment optically produce a vertical translation and horizontal rotation of the cavity axis at the waist, respectively. So it is thought to be a more separated excitation of the cavity axis.
Then I noticed that WFS2 error signals in general has high (~100%) pitch-yaw coupling. So it was suspicious.

I went to the rack and found that WFS2 SEG4 RF input (labeled "8") was not completely inserted. (Attachment 1)
It seemed that the LEMO connector or the receptacle didn't latch properly anymore and could be easily pulled.
I gave some elbow grease to fix this but in vain. I ended up to use LEMO-BNC adapters which somehow offered a robust connection.

Desipite the insightful discovery, this was not the intrinsic solution to the issue. I checked the past signal history, but I don't think this loose connection caused the missing signal.


Next, I needed to go a bit deeper. The WFS sensors are supposed to be adjusted to I phase where the PDH signal maximally shows up. And all the segments are supposed to have the same sign in terms of the PDH signal.

I've unlocked the IMC and turned on MC2 tickling. This swept the cavity over the resonances.
WFS1 SEG1I~3I showed about the same waveform, but SEG4 Q shows the PDH signal rather than SEG 4 I.
Then tried the same test for WFS2. The SEG4 I signal has the sign-flipped PDH signal compared to WFS2 SEG1I-SEG3I.

I quickly adjusted the demod phase of WFS1 SEG4 and WFS2 SEG4 to correct them,

WFS1 SEG4 103.9-> -20
WFS1 SEG4 -58  -> 120

This in fact made the pitch and yaw separated but flipped (Pitch signal shows up in WFS1Y and yaw signal shows up in WFS1P. Same for WFS2)

These modifications were reverted upon my leaving.


Now things are much more subtle now. And I need to do a more careful quantitative analysis of the demodulation phases / input matrix / output matrix.

Note: It seems that I had worked on IMCWFS on Dec 21, 2016

  17053   Tue Aug 2 01:10:26 2022 KojiUpdateIOOWFS investigation

Continued to work on the WFS repair

Demod phase adjustment:

- Use the PDH signal to adjust the demodulation phase to have uniform signals between the segments.

- Excited laser frequency at 1234Hz by injecting 10mVpp into IMC Servo Board IN2. The input was enabled on the MC Servo screen and given the input gain of 0dB.

- Looked at the ~real time spectrum in WFS1/2 SEG1/2/3/4 I&Q after the phase rotators. Changed the demod phases 1) to have ~0deg transfer function between C1:IOO-MC_F to C1:IOO-WFSi_Ij 2) to minimize the freq signal in Q phases.
(See Attachment 1)

- Resulting change of the demod phases:

WFS1 SEG1  52.0 -> 38.0deg
WFS1 SEG2  54.0 -> 53.0deg
WFS1 SEG3  16.6 -> 33.2deg
WFS1 SEG4 103.9 ->-37.1deg

WFS2 SEG1  17.0 -> 57.8deg
WFS2 SEG2  26.6 -> 51.5deg
WFS2 SEG3  24.5 -> 44.0deg
WFS2 SEG4 -58.0 ->103.7deg

SEG4 of both WFSs had significant phase rotation. A quick check of the power spectrum indicates that the Q signals have significantly (<x1/10) lower signals (Attachment 2/3/4). So that's good.

Transfer function measurement

Now the ASCPIT/ASCYAW of the MC1/2/3 suspension were excited and the transfer functions to WFS1/2 SEG1/2/3/4 and MC Trans P/Y were measured. The analysis will come later.

Again here the Q signals have significantly lower sensitivity to the mirror motion. So it is consistent with the above observation of the spectra.

However, the quick check of the transfer functions indicated that the conventional input matrices result in the flipped dependence of the combined error signals in pitch and yaw.
This might indicate that some of the cables were not inserted into the demod board properly although the cables at the demod boards show no indication of anomaly. (See the photos in ELOG 17048)

It might be the case that the cable had been inserted with a special unusual arrangement.

In any case, this can be fixed at the input matrix. Native change of the input matrix made WFS1PIT/WFS1YAW/WFS2PIT/WFS2YAW/MC2Trans YAW servos running (after some adjustment of the servo signs).
The MC2TRANS PIT servo didn't seem to settle and run away no matter which sign is used.

It's probably better to look at the sensing matrix and figure out the proper input/output matrix carefully. So at this moment, no WFSs are working.

Note that I left the new demod phases in the system


During the transfer function measurement some filters were turned off to make the shaking smoother:

IMC ASC filters were turned off to make the FResp flat:
- MC1 ASCP/Y FM1/FM5 OFF
- MC2 ASCP/Y FM1/FM5/FM6 OFF
- MC3 ASCP/Y FM1/FM5 OFF

60Hz comb OSEM Input filters were also turned off to make the transfer functions simpler:
- MC1 INPUT FM2 OFF (60Hz comb)
- MC2 INPUT FM2 OFF (60Hz comb)
- MC3 INPUT FM2 OFF (60Hz comb)


cf. Past IMCWFS commissioning http://nodus.ligo.caltech.edu:8080/40m/12684

  17059   Thu Aug 4 21:58:18 2022 KojiUpdateIOOWFS investigation

OK... It seems that all the 6 dof of the IMC WFS servo loops were closed with some condition...

- Measured the transfer functions from ASCPIT/YAW_EXC of each suspensions to WFS segs.
- FInd the proper input matrix for PIT and YAW for WFS1 and WFS2
- Closed loops one by one => This was not so successful because the loop shape was quite conditional.
- Closed WFS1/WFS2 loops one by one only with FM4 (0.8Hz Zero / (100Hz pole)^2). Adjust the gains to have the UGF at a few Hz.

- Found that the separation between WFS1P and WFS2P was not good. This caused instability of these loops when the gains were matched. I ended up lowering the gain of WFS1P by a factor of 10. This made the loop OK to work. FM3 (Integrator below 0.8Hz) worked fine.

- FM9 Rolloff filters (RLP12) makes the loops unstable.

- The MC2 spot loops (MC2_TRANS_PIT/YAW) are supposed to be slow loops. From the time series behavior it looks they are working.


MEDM Snapshots (Attchaments 1~4)

  17060   Thu Aug 4 22:14:20 2022 KojiUpdateIOOWFS investigation

Sensing matrix measurement

MCx_ASCyyy_EXC was shaken with the amplitude of 3000 cnt. Measure the transfer functions to each segment of the WFS I&Q demod outputs.

- Pitch excitations consistently indicated WFS1 SEG2&3 / SEG1&4, and WFS2 SEG 1&2 / SEG 3&4 are the pairs.
- Yaw excitations consistently indicated WFS1 SEG1&2 / SEG3&4, and WFS2 SEG 1&4 / SEG 2&3 are the pairs.

---> WFS1P matrix {1,-1,-1,1}, WFS1Y matrix {1,1,-1,-1}, WFS2P matrix {1,1,-1,-1}, WFS2Y matrix {-1,1,1,-1}

Now look at the servo input. The following lists show the important numbers for the actuation to sensor matrices. The numbers were the measured transfer function between 7~10Hz and the unit is 1/f^2 [cnt/cnt].

CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, -77.4602 +/- 18.4495
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -22.6042 +/- 5.289
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.0007949 +/- 0.00019046
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -60.5557 +/- 14.1008
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -206.3526 +/- 47.1332
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.00027094 +/- 6.6131e-05

CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 57.8636 +/- 35.3874
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -185.079 +/- 104.679
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, 0.00089367 +/- 0.00052603
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -349.7898 +/- 202.967
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -193.7146 +/- 111.2871
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.003911 +/- 0.0023028

CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 65.5405 +/- 14.305
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, 78.8535 +/- 17.1719
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.00087661 +/- 0.00020837
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -130.7286 +/- 29.6898
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, 129.0654 +/- 28.6328
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, -0.00024944 +/- 5.9112e-05

Put these numbers in the matrix calculation and take the inverse for pitch and yaw separately.

We obtained

WFS1P    WFS2P    MCTP    
-4.017   -4.783   -7.306e5   MC1P
 3.611   -5.252   -2.025e5   MC2P
 7.323   -1.017   -6.847e5   MC3P

WFS1Y    WFS2Y    MCTY    
-3.457   -4.532   -5.336e5   MC1Y
-0.1249   0.3826   2.635e5   MC2Y
-5.714    1.076   -4.578e5   MC3Y

Basically we can put these numbers into the output matrix. The last column corresponds to the spot position servo and we want to make this slow.
So used x1e-5 values (i.e. removed e5) instead of these huge numbers.

 

  17061   Thu Aug 4 22:14:38 2022 KojiUpdateIOOWFS investigation

WFS/MCTRANS_QPD Power Spectra

Attachment 1: HEPA ON

WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is largely contaminated by the other WFS loops.
MC2 TRANS YAW is slightly contaminated but not much compared to the one for pitch.

Attachment 2: HEPA OFF

Again, WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is still contaminated but better.
MC2 TRANS YAW is not contaminated.


Observation

WFS1/2 signals are largely disturbed when PSL HEPA is ON. Probably the amount of HEPA air flow was not optimized.
Above 1Hz, invacuum suspension are quieter than the beam incident on the IMC.

The dirty WFS signals are fedback to the mirrors. Due the large motion of the beam and also the imperfection of the actuator matrix cause the MC2 spot rather moves than stabilized.

This means that the WFS loops should leave the mirrors untouched above 1Hz i.e. The loop bandwidths should be low (~<0.1Hz). (Yes I know)
However, the simple gain reduction (x10) does make the servos unstable. So more adjustment is necessary. (<-Not for today)

  16943   Fri Jun 24 12:13:16 2022 JCUpdateIOOWFS issues

[Yuta, JC]

It seems that early this morning MC got very misaligned. Yuta was able to align the Mode Cleaner again by individually adjusting the MC1 MC2, and MC3. Once transmission reach ~12000, we went ahead and turned on WFS. Oddly enough, the transmission began plummeting and MC fell out of lock. After this, Yuta reset the WFS offsets and realigned the WFS QPDs. We then locked MC and turned on WFS once again, but the same issue happened. After fiddeling around with this, we found the if we set C1:IOO-MC2_TRANS_PIT_OUTPUT and C1:IOO-WFS1_YAW_OUTPUT equal to 0, WFS does not cause this issue. Is there a proper to reset WFS, aside from only zeroing the offsets?

  16946   Sat Jun 25 14:29:48 2022 AnchalUpdateIOOWFS issues

This issue is very weird and still unresolved. Without WFS loops, we'll have to realign IMC often and we might loose IMC alignment completely during weekends or long weekends.

I tried following things today but nothign worked:

  • Blocked WFS PDs and reset DC offsets (sitemap>C1IOO>C1IOO_WFS_MASTER>! Actions>Correct WFS DC Offsets).
  • Switched off MC chamber lights.
    I felt that they might be on, but later I feel that wasn't the case. Anyways, this didn't help.
  • Algined IMC manually using cavAlign tool with MC2-MC3 and then tweaking MC1 and MC3 a little bit. Reach 13.6k in C1:IOO-MC_TRANS_SUM. Then I unlocked IMC with autolocker off, centered beam on WFSs (they were pretty off even though we have been centering them this week), and then reset RF offsets (sitemap>C1IOO>C1IOO_WFS_MASTER>! Actions>Correct WFS DC Offsets). This did not help either.
  • The fact that IMC started misbehaving since Thursday onwards was bugging me that maybe the FE models did not come online properly, that maybe some RTS link is broken in IOO model which is causing the feedback loop to not work. So I went ahead and restarted all models, that didn't help either.
    • Now we have a restartAllModels.sh script which restarts all cds system and restores state to just before restarting. It also makes sure that watchdogs are engaged safely particularly for new suspesnions where alignment offsets are ramped.

We need to investigate this as first priority. Maybe some cable is loose, some PD power supply not working etc. Until we fix this, people should align IMC to > 12000 transmission counts whenever they have a spare 5 min. We need to work in place of WFS for sometime.

  16947   Sat Jun 25 20:23:59 2022 KojiUpdateIOOWFS issues

I could run the WFS servo (6dofs) for more than 15min by flipping the sign for the MC2 Pit and WFS1 Yaw. (See attachments)

This may mean that the sign of the loops / the input matrix / the output matrix, as well as the sensors and actuators, have the problem.
Isn't it the time to measure the sensing/actuation matrices? Maybe Tomislav already has the data?

I have reverted the changes as you may need more careful investigation.

  16949   Mon Jun 27 12:32:45 2022 yutaUpdateIOOWFS issues fixed

[Anchal, Yuta]

We found that MC1 local damping loop signs were revereted to the state before our standardization on June 7th (40m/16898), but the WFS output matrix was not reverted.
This caused the sign flip in the feedback to MC1, which caused the IMC WFS issue.
This probably happened when we were restarting the models after RTS modeling (40m/16935). We might have used wrong snap files for burt-restoring.

We went back to the snapshot taken at 09:19 June 21, 2022 and now the IMC WFS is working,

  16835   Fri May 6 13:48:34 2022 AnchalUpdateBHDWFS loop instability fixed

[Yuta, Anchal]

We investigated why WFS loop wasn't working. It seemed like WFS1 PIT error signal has a huge offset which would push the loop to misalign all optics' PIT. So we did the following steps:

  • Cover the WFS with Aluminium foils. Run Sitemap>IOO>C1_IOO_WFS_MASTER>!Actions>Correct WFS DC offsets.
  • Then center the WFS beams on the QPDS while looking at C1:IOO-WFS1/2_PIT/YAW_DC channels.
  • Then Switch off WFS loop, Switch off Autolocker, toggler the PSL Shutter so that IMC unlocks and does not catch lock back, and tehn run Sitemap>IOO>C1_IOO_WFS_MASTER>!Actions>Correct WFS RF offsets.
  • The above script found significant changes required in WFS1 RF offsets. After this, we opened the shutter and WFS loops were working fine.
  14876   Fri Sep 13 10:53:40 2019 aaronUpdateIOOWFS loop measurements

I'm scripting the WFS sensing matrix measurements. I haven't really scripted DTT before, so I'm trying to find documentation or existing scripts. I came across this elog where Gautam measured a sensing matrix during DRMI lock, and he pointed me to some .xml files used for these measurments.

 

  14878   Mon Sep 16 05:08:04 2019 ranaUpdateIOOWFS loop measurements

not need to use DTT. I'm attaching some half-finished notebooks that give the gist.

  1. Download the data with NDS2
  2. Downsample the data for ease of use.
  3. save the data as hdf5 for easy loading later.
  4. demodulate the data at the specified frequencies.

That's it! Now you have the complex, single frequency TFs. Next you invert the matrix.

  14880   Mon Sep 16 11:55:58 2019 rikaUpdateIOOWFS loop measurements

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

  14886   Tue Sep 17 09:41:48 2019 gautamUpdateIOOWFS loop measurements

Let's not worry about C1LSC until the c1iscaux upgrade is done.

 

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

  14887   Tue Sep 17 10:34:48 2019 aaronUpdateIOOWFS loop measurements

I'm using the notebooks from rana as a starting point, and making a script to measure and fill the WFS sensing matrix. It lives at /users/aaron/WFS/scripts/WFSsensingMatrix.ipynb for now. Here's what it does; what's been tested is in green, untested is goldenrod, uncoded is fire brick.

  1. Sets up an nds connection, listening to the WFS channels and the MC#_PIT/YAW IN1 channels.
  2. Loops over the excitation channels. For now, I'm assuming the user is injecting excitations one at a time in awggui; in principle, we could excite the various MC angular dof at several frequencies and take a single measurement, or use the natural frequencies of the suspensions.
    1. For each excitation, grab the data
    2. Filter the data. I'm using a 30 Hz to 40 Hz cheby filter
    3. Take an FFT, hold on to that for future reference
    4. Generate an LO at the excitation frequency, and demodulate the signals. Strong low pass.
    5. The single-frequency transfer function is now [WFS channel] / [excited MC channel]. Each iteration of this loop generates a column of the sensing matrix.
  3. Invert the sensing matrix
  4. Populate in the appropriate channels of the WFS_OUTMATRIX

Grabbing data with nds

To run these on pianosa, I ran (inside the jupyter notebook)

import sys
!{sys.executable} -m pip install astropy --user

I'm getting an error when starting the nds2 connection

conn = nds2.connection('192.168.113.201', 31200)
Failed to establish a connection[INFO: Request SASL authentication protocol]+

 I didn't find anything on the elog about this error, but I'm looking at the nds user manual. The problem was, I didn't have a valid Kerberos ticket; I opened one on Pianosa with my albert.einstein (note all caps ligo.org).

kinit aaron.markowitz@LIGO.ORG

 I'm now able to run the scripts Rana mentions, but I haven't been able to grab the channels I want (eg C1:SUS-MC1_ASCPIT_IN1_OUT); it says the channel isn't found. When I check how many of the Caltech channels are available (conn.count_channels('C1*')), there are none. I was connecting to nds.ligo.caltech.edu, but this must be the wrong server (it has all the channels for the sites). fb and fb1 (and the IP they point to, 192.168.113.201) cannot be connected to, giving the error 'Error occurred trying to write to socket.'

I recall that in the cryo lab, we need to use port 8088 to get data from cymac1, and indeed substituting 31200 -> 8088 lets me access the C1 channels (I can count the channels), but no matter what time I request, nds tells me there is no data available (gap). Gautam came by and diagnosed that the gaps I'm seeing in the frames' data are real, fb is down (see elog).


WFS Sensing Matrix Script

Saving extra channels

Continuing, I'm going to modify the script to grab live data. I'm using the iterate and next methods. I noticed that the MC2_TRANS pit/yaw channels are not saved to frames, even though WFS1/2 pit/yaw are. Since I expect I'll want to lookback at these channels, I followed the instructions for adding a daq channel, uncommenting the following line in /opt/rtcds/caltech/c1/chans/daq/C1IOO.ini:

[C1:IOO-MC2_TRANS_PIT_OUT_DQ]
acquire=1
datarate=512
chnnum=10186
datatype=4
[C1:IOO-MC2_TRANS_YAW_OUT_DQ]
acquire=1
chnnum=10189
datarate=512
datatype=4

I made a backup of the old version of this .ini file, which can be found in /users/aaron/backups/190917_C1IOO.ini. I did not remake the model, as I couldn't find the c1ioo model in /opt/rtcds/caltech/c1/userapps/trunk or from the matlab command prompt. I restarted the fb via telnet, but didn't restart the model or check the svn (got an error?). The _DQ channels are now reachable on dataviewer, so things seem to be working.

awgpy

I also tried importing cdsutils, so I can control awg in the same script that we read out the sensing matrix, but I'm getting the python3 error when I import cdsutils:

No module name '__version'

I tried pip upgrading cdsutils, but it's already up-to-date. I get the above error even if I switch to a python 2 kernel; cdsutils is installed in the python2.7 directory, so I don't know why pip is finding it when I'm running a python 3 kernel. I can move on from this for now, but it would be useful to be able to script the excitation along with the measurement.


Changes to the user environment

jupyter on donatella

Tangentially related, Rika wanted to be running some jupyter notebooks while working on donatella. I ran, on donatella:

conda install jupyter

 hm, that didn't work. Also jupyter is installed when you install conda, so I'm not sure how there is a version of conda but not of jupyter. I also see that pip and pip3 are not recognized commands on donatella.

scipy on pianosa

I noticed that some of the functions in the scipy signal processing toolbox were out of date on pianosa. The cheby and welch filters now accept additional kwargs (for eg, before you needed to give IIR filter methods a cutoff frequency normalized to the Nyquist rate, but now you can give it the frequencies and sampling rate separately).

I want to update this package, but I hesitate to break everyone's existing scripts.

  14888   Tue Sep 17 10:47:44 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 

----- 

Diagnotics test tools

range: 7 Hz to 50 Hz

 avarage=61

Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 

-----

I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.

 

We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.

Quote:

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

 

  14896   Wed Sep 18 14:45:52 2019 rikaUpdateIOOWFS loop measurements

[aaron, rika]

Gettng TFs

In the data we got yesterday, we can see some filter's effect. 

But it is not good coherence above 10Hz, so we mesured again. And this time we save the data as xml file.

And also we chaned the frequency regions broader to watch corner frequency of suspension.

-----

 Diagnotics test tools

 range: 0.1 Hz to 100 Hz

 points: 120 

 Amplitude: 1000

----

but at low frequency, the mode maching cavity was unloked cause of too much shaking.

So, we saw single frequency TF, and searched the good amplitude.

 

First, I tried to get TF @0.1~1 Hz .

-----

0.1 to 1 Hz

points: 61 (I think it's too much becous it takes about an hour)

amplitude: 5

-----

The TFs and coherence of MC1/PIT to each QPD is below. [above window: coherence, below: TF]

During the mesurement, something happened @0.2-0.3Hz so I stopped it.

We found the coherence of WFS1P and WFS2Y is not good, but others are good.

we guess that it could come from alignment which made Q chainging to small.

 

Finaly, I also got the  .xml data of MC1P 1 Hz to 10 Hz. In this time,

-----

1 to 10 Hz

points: 41 

amplitude: 90

-----

 

Making matrics

Now we took single frequency 6 TFs (MC1/2/3 PIT/YAW) @7Hz (Because this frequency has good coherence in all channel).

Aaron wrote the script using dtt to making matrics. 

 

 

Quote:

[aaron, rika]

Once stop the auto-locker and realigned to make beam to get into QPD again.

After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW. 

----- 

Diagnotics test tools

range: 7 Hz to 50 Hz

 avarage=61

Column 0: WFS2_PIT   1: WFS2_YAW   2:WFS1_PIT   3: WFS1_YAW   4: TRANCE_PIT   5:TRANCE_YAW 

-----

I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.

 

We got all data for TFs already.  Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs. 

TF of MC2 is attachiment 1. So tomorrow, I make other TF.

Quote:

[rika, aaron]

We aligned optics of WFS as it was. Now auto-locker is working to lock MC.

But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.

 

Now we reset the hardware!

 

17:11

After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.

We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.

With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.

 

 

  14957   Tue Oct 8 20:39:42 2019 aaronUpdateIOOWFS loop measurements

I installed nds2 on donatello with yum, but still can't import nds2.

  14958   Wed Oct 9 09:37:28 2019 aaronUpdateIOOWFS loop measurements

I installed nds2 again, this time successfully with

conda install -c conda-forge python-nds2-client

 

  14868   Tue Sep 10 15:41:37 2019 aaronUpdateIOOWFS measurements

[rika, aaron, rana]

We are getting the MC locked in anticipation of making some WFS transfer function measurements.

The PSL screen was all white boxes, so I keyed the PSL crate and burt restored the settings from 11:19am Sep 5 (somewhat earlier than we started rebooting computers). Following this, I ran Milind's unstick.py and then the PSL autolocker script; both worked on the first go, great work Milind!

The modecleaner autolocking script is having substantially more trouble. Rana found that pitch and yaw sliders for all MC optics have been swapped--we think it's because the camera at MC2 has been rotated. Note that for now, sliding pitch gives a change in yaw, and sliding yaw changes pitch.

Improving MC alignment

We noticed that with the WFS servo on, the modecleaner would be well aligned for a while (MC trans ~ 14000), only to lose lock after several minutes. We held the MC2_TRANS_PIT/YAW outputs at 0, so the MC2 QPD does not affect the WFS loop; the beam is well centered on WFS1/2, but not on the MC2 QPD, and with this signal out of the loop MC TRANS recovers to ~15000 counts (consistent with the quiet times over the last 90 days, see attachment 2). Attachment 1 shows the MC lock degrading, followed by some noise where we lost lock, and finally a visible increase in MC trans when we remove the MC2 QPD from the WFS loop.

mode cleaner alignment setting

MC1 Pich 4.4762     Yow 4.4669

MC2 Pich 3.7652     Yow -1.5482

MC3 Pich -0.4159    Yow 1.1477

 

After automatic locking MC, we stopped automatical locking and took alignment to the center of QPD.

And then again did the automatic locking MC. Finaly Rana move to best alignment.

 

Mode cleaner Alignment Setting

MC1 Pich 4.4942   Yow 4.6956

MC2 Pich 3.7652   Yow -1.5600

MC3 Pich -0.3789   Yow 1.1477

 

Measured sine response

We used diaggui to measure the response of WFS1/WFS2/MC2 pitch (yaw) to excitations in MC1/MC2/MC3 pitch (yaw). Seeing fluctuations of amplitude ~1 on the MCX_PIT/YAW_OUT channels, we used an amplitude 0.01 excitation at 20 Hz. We will work on scripting some of this tomorrow.

 

 

  14871   Wed Sep 11 10:26:56 2019 aaronUpdateIOOWFS measurements

Gameplan

We should also have a plan for the next couple weeks so we are organized; heavily adapted from. Here's what I'm thinking this morning:

  1. Construct the input/output matrix for the WFS. (basically, what we did yesterday)
    1. Measure a transfer function of MC[1, 2, 3]_[PIT, YAW] to [WFS1, WFS2, MC2_TRANS]_[PIT, YAW]. The transfer function above the loop bandwidth (few seconds BW, so we will excite >~ 10 Hz) characterizes the response of the sensor to the excitation.
    2. Invert the resulting 3x3 matrix and populate the inverted matrix at WFS_OUTMATRIX. This will map the WFS basis to the MC optics' pit/yaw basis.
    3. Script this process. If we make changes (for example, moving the telescoping lenses) to make this matrix more diagonal, we'll want to do these steps many times.
  2. Characterizing the loop
    1. Optimize the demodulation phase -- we want to minimize the signal in Q. This should also be automated. I found documentation in the white Wave Front Sensing binder
      1. Misalign a mirror in pitch or yaw, and rotate the phase to minimize the magnitude of Q (maximize I); this angle is 'R' on the WFSx_SETTINGS screen.
    2. We should measure a step response applied to each angular dof of the MC optics.
    3. Guoy Phase Calibration
  3. Characterizing / Calibrating the WFS heads
    1. The DCC has LIGO test procedures for their WFS RFPD, as does the white binder; the following checks are relevant for our WFS, and this is how I think we should carry them out (not identical to the procedure as written in the document). For many of these, we'll want to set up the JenneAM laser with a network analyzer for RF modulation.
      1. DC path transimpedance
        1. Measure the DC power of JenneAM with a power meter, and direct the beam to each of the QPD quadrants. Make sure the beam fits on a single quadrant.
        2. This will give us the product of the PD efficiency and DC transimpedance gain
        3. Last time this was measured (white WFS binder)
      2. notch tuning -- we are going to measure the TF, but I won't tune it without someone as ancient as the electronics
        1. Using the network analyzer, measure a transfer function from the laser AM to the QPD head's RF output
          1. Is there a pickoff available? The LIGO testing procedures recommend a FET probe
          2. We should do this while measuring the DC transimpedance for each quadrant
      3. notch rejection ratios
        1. While taking the RF transfer function, use the delta marker to record the difference between the notch and the RF operating frequency.
      4. RF transimpedance
        1. Illuminate the PD with white light from an incandescent bulb (a shot-noise limited source)
          1. 6-10 mA of photocurrent should be generated
        2. Use an RF spectrum analyzer and low noise RF pre-amplifier (gain ~20dB) to measure the shot noise limited spectrum
        3. A piece of scotch tape can be used to make the light uniformly illuminate the QPD
        4. Convert this RF PSD to an rms amplitude (voltage) spectral density, and also note the DC photocurrent. This can be used to calculate the RF transimpedance with
          1. Z_\mathrm{RF} = \sqrt{\frac{V_\mathrm{rms}^2I_\mathrm{DC}}{3.2\times 10^{-19}}}
      5. Shot noise limited input sensitivity
        1. Measure the RF PSD with the beam blocked and light off; this is the dark photocurrent, and can be used to calculate the shot noise limited sensitivity.

References:

  • Binders of documents about the 40m WFS
  • LIGO ISC WFS RFPD test procedure (T1200347 is dual frequency, T1200380 is single frequency)
    • The associated datasheet template is in T1200381
  • Wavefront Sensor (T960111). This document even has a calibration protocol with forms to fill in during testing, so I've printed an extra copy of that appendix.

Automation

It would be good to script some of what we did yesterday. I'm checking out some scripts I'd used for Qryo and armloss measurements to remember the best way to do this.

  • Existing WFS scripts (I didn't try these)
    • WFS_DC_offsets -- sets the WFS QPD dark offsets
      • block beam, then run script
    • MC2_TRANS_offsets -- sets the MC2 transmission offset (why isn't this in the same script as WFS_DC_offsets?)
      • MC should be aligned, beams centered on WFS, WFS servo off
    • mcWFSallowOn(Off) -- turns on (off) the ASC filter module outputs
    • mcwfshold -- turns off the input to WFS servos, but holds the current values of MC optic biases
    • mcwfsoff -- turns off the mc wfs loop
      • First, turns off the WFS outputs (eg WFS1_PIT OUTPUT)
      • Turns off the MC WFS input gains
      • Holds the WFS loop outputs

Miscellany

I noticed yesterday that the PSL_shutterqst box is white, and I've seen timeout requests when eg the reboot script tries to open/close the PSL shutter. It seems like a shutter that should open, so I should find the aux machine to restart it.

  14872   Wed Sep 11 14:37:43 2019 aaronUpdateIOOWFS measurements

[aaron, rika]

We identified the Jenne laser and found a long optical fiber that might be able to transport our beam to the AP table.

Now we're searching for documentation on using this laser. Kevin and John measured a TF last year. Koji advised that we needn't worry too much, the current limit is already set correctly and we need only power on the laser.

We moved the breadboard (including a couple PDs, collimating lenses, laser, steering mirrors, etc) over to the AP table, and set it on top of the panel next to the WFS. We mounted the laser on the AP table, and added one lens with f~68 mm after the laser to fit the beam on a single quadrant; the beam was about 1mm diameter (measured by eye) when it entered the QPD. We turned the laser driver on at ~19.4 mA, and directed it to WFS2 via the last two steering mirrors before WFS2.

We monitored the QPD segments' DC level with ndscope on a laptop, and were able to send the beam to each of the four quadrants in turn. We set up the Agilent network analyzer to drive the laser's amplitude modulation and sent the RF signal from the LEMO output on the QPD head directly to the network analyzer. We will take the measurements tomorrow morning.

  14874   Thu Sep 12 12:42:31 2019 aaronUpdateIOOWFS measurements

[rika, aaron]

At Seiji and Gautam's suggestion, we added an additional RF photodiode (NewFocus 1611) to the system so we can calibrate our transfer functions. The configuration is now laser -> BS --> lenses -> QPD and BS --> lenses -> RFPD. We added lenses to get the beams focused on the RFPD and QPD heads, and are again set up for TF measurement.

We took the following data. These parameters were consistent across all measurements:

  • 1kHz IF BW
  • log sweep with 801 points
  • 32 averages
  • auto attenuation
  • -10 dBm excitation amplitude
  • 19.2 mA DC current to the laser
  • The DC level of the reference PD is -, and with the beam blocked (dark current) it is
Measurement file parameters
WFS2_SEG1 / RFPD
TFAG4395A_12-09-2019_155901.txt
100 MHz - 500 MHz
WFS2_SEG1 / RFPD TFAG4395A_12-09-2019_160811.txt 10 MHz - 100 MHz
WFS2_SEG1 / RFPD
TFAG4395A_12-09-2019_170234.txt
100 kHz - 10 MHz
WFS2_SEG2 / RFPD AG4395A_12-09-2019_183125.txt 100 MHz - 500 MHz
WFS2_SEG2 / RFPD TFAG4395A_12-09-2019_183614.txt 10 MHz - 100 MHz
WFS2_SEG2 / RFPD TFAG4395A_12-09-2019_183930.txt 100 kHz - 10 MHz
WFS2_SEG3 / RFPD TFAG4395A_12-09-2019_225243.txt 100 MHz - 500 MHz
WFS2_SEG3 / RFPD TFAG4395A_12-09-2019_225601.txt 10 MHz - 100 MHz
WFS2_SEG3 / RFPD TFAG4395A_12-09-2019_225922.txt 100 kHz - 10 MHz
WFS2_SEG4 / RFPD
TFAG4395A_12-09-2019_230758.txt
100 MHz - 500 MHz
WFS2_SEG4 / RFPD TFAG4395A_12-09-2019_232058.txt 10 MHz - 100 MHz
WFS2_SEG4 / RFPD TFAG4395A_12-09-2019_234447.txt 100 kHz - 10 MHz

After taking the data for segment 1, I moved the beam to segment 2. The beam didn't fit on segment 2 without partially illuminating segment 1 (tested by maximizing the signal on segment 2, then blocking the beam. If the beam is entirely on one segment, only that segment should be effected; in this case, we found that segment 1's DC signal also changed when the beam was blocked). We readjusted the telescoping lenses to get the beam a bit smaller, and now the beam fits on segment 2. We know it is entirely on segment 2 because small beam movements do not change the signal on segment 2.

We are trying to take the remaining data, but AGmeasure keeps hanging while sending the data (after taking the measurement, over 10 min). We tried restarting the network analyzer to no avail. I was able to grab the data by cancelling the measurement and running

AGmeasure --getdata -i vanna

I've uploaded the spectrum for segment 1 in the meantime. Zero model is on the way.

When I finished up the measurements on WFS2, I removed the cables from the AP table and closed the cover.

EDIT: I forgot to switch the LEMO connector to measure the other segments, so we measured the RF signal from segment 1 even when the beam was on segments 2-4. We'll have to try again tomorrow.

  14875   Fri Sep 13 10:36:03 2019 aaronUpdateIOOWFS measurements

[rika, aaron]

We are at it again. Rika is setting up the TF measurement, I'm looking into scripting the WFS sensing matrix measurement we made earlier in the week so we can return to it next week.

 

Measurement file parameters
WFS2_SEG1 / RFPD

 

 
100 MHz - 500 MHz
WFS2_SEG1 / RFPD   10 MHz - 100 MHz
WFS2_SEG1 / RFPD
 
100 kHz - 10 MHz
WFS2_SEG2 / RFPD TFAG4395A_13-09-2019_181415.txt 100 MHz - 500 MHz
WFS2_SEG2 / RFPD TFAG4395A_13-09-2019_180955.txt 10 MHz - 100 MHz
WFS2_SEG2 / RFPD TFAG4395A_13-09-2019_182918.txt 100 kHz - 10 MHz
WFS2_SEG3 / RFPD TFAG4395A_13-09-2019_121533.txt 100 MHz - 500 MHz
WFS2_SEG3 / RFPD TFAG4395A_13-09-2019_123820.txt 10 MHz - 100 MHz
WFS2_SEG3 / RFPD TFAG4395A_13-09-2019_123243.txt 100 kHz - 10 MHz
WFS2_SEG4 / RFPD
TFAG4395A_13-09-2019_161834.txt
100 MHz - 500 MHz
WFS2_SEG4 / RFPD TFAG4395A_13-09-2019_170007.txt 10 MHz - 100 MHz
WFS2_SEG4 / RFPD TFAG4395A_13-09-2019_172001.txt 100 kHz - 10 MHz

 

When we mesuring TF of SEG4, the beam leaking to SEG1 about 1%.

We finished mesurement SEG2-4 and get the figure by running PDH_calibrate.ipynb .

edit: We observed during segment 2 measurements that blocking the beam reduced the DC level of segment 1 by less than 1%, but still clearly observable. As you can see in the plots, something is suspicious about the normalization of these TFs. We took segment 1 data a few days before the other segments, so perhaps we weren't getting the full beam on the reference PD during the later measurements? When I make this measurement for WFS1, I will try to fix some of these problems by choosing different telescoping optics, and I will consider whether removing the QPD heads from their table will improve the measurement.

  14882   Mon Sep 16 12:38:59 2019 aaronUpdateIOOWFS measurements

I wanted to make a zero model of this circuit to get a handle on the results. I couldn't import zero on pianosa, and I tried pip installing zero, but was denied due to not finding version 3.0.3 of matplotlib. I finally got it to install using

pip3 install zero --user

 Oddly, even though I can now import zero when I open a python3 session from the command line, when I open a jupyter notebook and switch to a python3 kernel, the zero module is still unavailable. I think I recall that conda manages the jupyter environment -- is pip managing an entirely separate environment (annoying)?

edit: Yeah, it was something like that. I reminded myself how this works with this article.

  14929   Thu Oct 3 11:38:35 2019 aaronUpdateIOOWFS measurements

I set up the spectrum analyzer to make the WFS head RF transfer function measurement (V/W) on WFS1. I placed the Jenne laser on the AP table, along with the reference PD power supply, laptop, and laser power supply. The Agilent output AM modulates the laser; the reference PD is again NewFocus 1611, with its AC output sent to Agilent's R channel and DC output sent to an oscilloscope;

At Koji's suggestion, I've started setting up a small breadboard to hold the fiber collimator, BS, and reference PD. I haven't really used fiber optics before, I'd appreciate another set of eyes before I get too deep.
Gautam showed me the collimator and fiber BS.

I closed the PSL shutter while checking for a location to place the breadboard, and opened it while writing this. Headed back to Cryo to pick up the large incandescent bulb we'd borrowed over the summer.

  9526   Tue Jan 7 16:41:08 2014 manasaUpdateIOOWFS moving MC suspensions

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

The MC trend for the last 2 days shows that the MC suspensions were kicked again earlier today.  Looking back at the suspension channel INMONs along with the MC trans sum shows that the suspensions get kicked everytime MC locks and unlocks. (Attch:1)

So I checked the effect of WFS on the suspensions by disabling and enabling the WFS feedback servo (Attch:2).

Since the IMC is not at it best pointing, whenever the  MC autolocker runs and enables the WFS, the suspensions look like they are getting kicked.  But really, it's just the WFS doing their job. 

Edit, JCD:  What this really means is that our DC MC pointing is bad, and we need to move the MC suspensions to offload the WFS.  (All of the WFS output numbers for MC1 and 3 were around 100, which is pretty big for those numbers).  We should resurrect the WFS offloading scripts so that we can do this more regularly, and not have to do it by hand.

  6612   Mon May 7 12:57:34 2012 DenUpdateIOOWFS noise in MC

I've measured coherence between seismometer signals and OSEMS of MC 1,2,3

gur_suspos_coh.png

GUR1 was rotated on the angle pi / 4 relative to x arm to match suspos axis of MC1 and MC3. Coherence between MC2 and GUR2_X is high, between MC3 and GUR1_X is ~0.2 but is compensated by GUR1_Y, between MC1 and GUR1_Y below 1Hz is ~0.5 and is not compensated by GUR1_X.

Then I measured coherence between GUR1_Y and MC3 OSEMS in 3 regimes :

  • FEEDBACK OFF, WFS OFF
  • FEEDBACK ON, WFS OFF
  • FEEDBACK ON, WFS ON

mc1_gur.png

Once WFS are ON, signal becomes noisy, FEEDBACK is OK. Then I measured coherence between MC_F and GUR2_X with WFS ON and OFF

mcl_wfs.png

Coherence between MC_F and GUR2_X is less when WFS are ON in the range 0.2 - 1 Hz and 4 - 10 Hz. Moreover PSD of MC_F seems to be higher at 10 - 100 Hz. But this may be caused by other reasons.

Then I measured the coherence between IN and OUT signals in WFS_SERVO

wfs_servo.png

One filter bank adds noise to WFS signals and because of that we loose coherence between MC_F and seismic motion.

  6613   Mon May 7 17:28:29 2012 DenUpdateIOOWFS noise in MC

Quote:

One filter bank adds noise to WFS signals and because of that we loose coherence between MC_F and seismic motion.

 This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

wfs_limit.png

The other thing is that WFS actuate on the angular motion, but this couples to the position motion. We need to diagonalize the actuator.

  6614   Mon May 7 19:39:52 2012 KojiUpdateIOOWFS noise in MC

OK. Then we should make this number bigger such that the coherence is still completely maintained.
Is this set in the auto locker? Or manually set?

Quote:

  This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

 

  6615   Mon May 7 20:15:37 2012 DenUpdateIOOWFS noise in MC

Quote:

OK. Then we should make this number bigger such that the coherence is still completely maintained.
Is this set in the auto locker? Or manually set?

Quote:

  This effect is due to C1:IOO-WFS1_PIT_LIMIT=2000. When I turned if off, coherence between C1:IOO-WFS_PIT input and output signals restored

 

 

LIMIT is set manually, auto locker does not change it. I've put C1:IOO-WFS1_PIT_LIMIT=4000, it seems to be fine for now.

  10681   Thu Nov 6 12:58:28 2014 KojiUpdateIOOWFS offset was reset

IMC WFS operating point seemed to get degraded.

- IMC WFS feedback was relieved.

- WFS servo was turned off.

- IMC alignment was tuned carefully

- /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets was run

- WFS servo was turned on again 

  7710   Wed Nov 14 00:56:19 2012 JenneUpdateIOOWFS on, PZT2 ~set, AS camera back

WFS are back on, and working nicely.  Den and I had seen a problem (which I had seen before) that when you turn on the integrators in the WFS loops, the MC Refl value gets worse (goes up).  Koji reminded me that he had a nice elog (7452) on how to get the MC awesome.  Ayaka and I last night stopped after Step 7.  Step 8, zeroing the WFS offsets, is the secret important thing that I keep forgetting.  I ran the script /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets, then turned on the WFS loop, and the WFS are working just fine now.   

I'm back to wishing that I had control over PZT1.  I went back and forth for a while between 1Y4 and the ETMY table to get the IPANG beam centered on the QPD.  Initially, the beam was coming out of the vacuum a little high.  The digital HV power supply is pitch, and the analog HV power supply is yaw.  When I get the beam reasonably well centered on IPANG, with a beautiful, non-clipped, beam, the beam is much too high on IPPOS.  The beam barely hits the top of the first out of vac steering mirror, and then is too high on the QPD.  It looks like (based on the sum value) that the beam is on the diode, just entirely in the upper 2 quadrants.  But if I try to fix this, since IPANG has a longer lever arm, the IPANG beam doesn't come out of the vacuum.  I have compromised by getting the beam on IPANG, centered in pitch and ignoring IPPOS pitch.  For yaw, since moving PZT2 only makes one of POS or ANG good at a time, I split the difference, so the beam is not really centered in yaw on either, but it's close on both.

AS beam is back on the camera.  I forgot that, especially since the beam at REFL is pretty bright, I had moved the AS and REFL cameras out of the beam so we didn't crispy-fry the CCDs.  Therefore, the camera spots are no longer a reference of spot position. We can still eyeball the position on, say, the 2" lens, but that's not any kind of accurate.  I put the AS camera back to it's normal place, so the AS beam is going toward AS55 and AS110, and a little bit is going to the camera.  I have not yet aligned the beams actually on to the PDs.

REFL beam is dumped by a razor dump after the 2" lens.  Manasa did some work (elog 7666) to the REFL path, and I'm not 100% sure how it was before, so I leave it to her to please work on during the day tomorrow.  I think we need to put back the Y1 that used to be there, but I don't know where the optic is.  I put a yaw dither on the PRM with awggui, and saw the REFL beam moving at my 2Hz dither frequency, so this time we actually have a useful beam coming out.

  6982   Wed Jul 18 00:36:22 2012 JenneUpdateIOOWFS oscillating

I was trying to lock and look at the ASS for the Yarm, but the transmitted power was oscillating very near 1Hz.  Eventually I looked at the mode cleaner, and it was also moving around at a similar frequency.  I took spectra of the ETMY SUS damping feedback signals, and they (POS, PIT, YAW) saw this 1Hz motion too (see attached plots...same data, one is a zoom around 1Hz).

As a first place to start, I turned off the WFS, which immediately stopped the MC oscillation.  Turning the WFS back on, the oscillation didn't come back.  I'm not sure what happened to make the WFS bad, but I perhaps had the ASS dither lines on (I've had them on and off, so I'm not sure), although turning off the dither lines didn't make the WFS any better.

As an aside, the MC refl with the WFS off was ~1.5, rather than the ~0.5 with the WFS on, which means that the PSL beam and the MC axis are not well matched.

  5819   Sat Nov 5 01:10:29 2011 SureshUpdateIOOWFS output matrix measured (open loop)

 

The scripts and screens needed to make the MC WFS ouput matrix are once again functional

I corrected the WFS lockins' phases to ensure that the Q outputs are minimised.  Since all the lockins have the same relative phase with respect to the oscillator I found that the same phase works for all of them.  About 90 deg in this case.

The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

1) setupWFSlockins:   This script makes sure that all the ASC, WFS_ LKIN and WFS_servo filter banks used in this measurement are set up properly.  It also sets the WFS_lockin oscillator to 10 Hz.  There are filter modules in the SIG filter bank of the WFS demodulators. 

2) senseWFSoutMATRX:  This script cycles through the various MC actuators ( MC 1 2 3 : PIT and YAW ) and measures the response of the various ASC sensors (WFS and MC2_TRANS QPD).

3) The data collected by the sensWFSoutMATRX can be analysed with a matlab file called " wfsmatrix3.m " located in a subdirectory under WFS called 'matlab'.   I have added some comments in this file to make it easier to follow.   The output of this file, at the moment, gives only the " Actuation Vectors " for WFS1P, WFS2P, WFS1Y and WFS2Y.  It ignores the MC2TransQPD for now. 

4)  The lockin outputs are given below ( the 'reduceddata' )

             wfs1p      wfs2p      mc2tp      wfs1y      wfs2y     mc2ty

mc1p    0.2926   -0.4086    0.2926    0.0340    0.0064    0.0001
mc2p   -0.2830   -1.3060   -0.2833    0.0628    0.1171   -0.0003
mc3p   -0.3283   -0.3455   -0.3288   -0.0456    0.0275    0.0000
mc1y    0.0440    0.0261    0.0429    0.7204    0.9351   -0.0008
mc2y   -0.1006    0.0850   -0.1036   -1.5509   -0.3882    0.0165
mc3y     0.0150   -0.0832    0.0144    0.1114   -1.0573    0.0006

5) The actuation vectors are given below

Pitch WFS1P WFS2P
MC1 1.00 -0.86
MC2 -0.12 -1
MC3 -0.72 0.09

 

Yaw WFS1Y WFS2Y
MC1 0.16 0.59
MC2 -1.00 0.20
MC3 0.51 -1

6) This measurement was performed with the WFS servo loops open. I will try to close the loops with this matrix and run the script again to measure the output matrix in closed loop.

7) This a.vectors obtained above are significantly different from that obtained a while ago (elog 5668) before the lockin demod phases (relative to each other) were fixed.  This could also be because both are open loop measurements and we might have wandered into the nonlinear regime of the WFS sensors.

 

 

 

  5834   Mon Nov 7 15:49:26 2011 jamieUpdateIOOWFS output matrix measured (open loop)

Quote:

 The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

 I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS.

As I've tried to reitterate many times: we do not use /cvs/cds anymore.  Please put all new scripts into the proper location under /opt/rtcds.

  5899   Tue Nov 15 19:59:41 2011 SureshUpdateIOOWFS output matrix measured (open loop)

Quote:

Quote:

 The scripts used to make the WFS outmatrix measurement live in /cvs/cds/rtcds/caltech/c1/scripts/MC/WFS

 I assume you mean /opt/rtcds/caltech/c1/scripts/MC/WFS.

As I've tried to reitterate many times: we do not use /cvs/cds anymore.  Please put all new scripts into the proper location under /opt/rtcds.

 Yes the files are in /opt/rtcds/caltech/c1/scripts/MC/WFS.

I just went to wherever the 'scripts' alias takes me, found the 'pwd' and did a cp+paste of the path.   I checked to be sure that 'scripts' takes me to /opt/rtcds/caltech/c1/scripts/.

So why does the pwd show /cvs/cds.... instead of /opt/rtcds  ?

 

  5321   Mon Aug 29 19:14:31 2011 SureshUpdateIOOWFS phase adjustments

[Valera, Suresh]

1) To see if there are significant dark-offsets on the WFS sensors we closed the PSL shutter and found that the offsets are in the 1% range.  We decided to ignore them for now.

2) To center the MC_REFL beam on the WFS we opened the PSL shutter, unlocked the MC and then centered the DC_PIT and DC_YAW signals in the C1IOO_WFS_QPD screen.

3) We then looked at the power spectrum of the I and Q signals from WFS1 to see if the spectrum looked okay and found that some of the quadrants looked very different from others.  The reason was traced to incorrect Comb60 filters.   After correcting these filters we adjusted the R phase angle in the WFS1_SETTINGS screen to suppress the 1Hz natural oscillation signal in the Q channels of all the four quadrants.  We repeated this process for WFS2

4) To see if the relative phase of all four quadrants was correct we first drove the MC_length and tried to check the phase of the response on each quadrant.  However the response was very weak as the signal was suppressed by the MC servo.  Increasing the drive made the PMC lock unstable.  So we introduced a 6Hz, 50mVpp signal from an SR785 into the MC_servo (Input2) and with this we were able to excite a significant response in the WFS without affecting the PMC servo.    By looking at the time series of the signals from the quadrants we set the R phase angle in WFS_Settings such that all the quadrants showed the same phase response to the MC_length modulation. 

     Using the larger response were were able to further tweak the R angle to supress the Q channels to about 1% of the I phase signals.

5)  I then edited the c1ioo.mdl so that we can use the six lockins just as they are used in MC_ASS.  However we can now set elements of the SEN_DMD_MATRX (sensor demod matrix) to select any of the MCL, WFS PIT and YAW channels (or a linear combination of them) for demodulation.  The change is shown below.  While compiling and model on C1IOO FE machine there were problems which eventually led to the FB crash.

Screenshot-1.png

 

  

  4289   Mon Feb 14 15:59:49 2011 JenneUpdateIOOWFS quantum efficiency as a function of angle

[Larisa and Jenne]

A few weeks ago (on the 28th of January) I had tried to measure the quantum efficiency of one quadrant of the WFS as a function of angle.  However, Rana pointed out that I was a spaz, and had forgotten to put a lens in front of the laser.  Why I forgot when doing the measurement as a function of angle, but I had remembered while doing it at normal incidence for all of the quadrants, who knows?

Anyhow, Larisa measured the quantum efficiency today.  She used WFS2, quadrant 1 (totally oil-free), since that was easier than WFS1.  She also used the Jenne Laser (with a lens), since it's more stable and less crappy than the CrystaLasers.  We put a 50 Ohm terminator on the RF input of the Jenne Laser, since we weren't doing a swept sine measurement.  Again, the Ophir power meter was used to measure the power incident on the diode, and the reflected power, and the difference between them was used as the power absorbed by the diode for the quantum efficiency measurement.  A voltmeter was used to measure the output of the diode, and then converted to current as in the quote below. 

Still on the to-do list:  Replace the WFS2 diode.  See if we have one around, otherwise order one.  Align beams onto WFS so we can turn on the servo.

QE = (h*c)/(lambda*e) * (I/P)

Where I = (Volts from Pin1 to GND)/2 /500ohms
P = Power from laser - power reflected from diode.
h, c, e are the natural constants, and lambda is 1064nm.
Also, I/P = Responsivity


Larissa is going to put her data and plots into the elog shortly....

Quote:

Quantum Efficiency Measurement:

I refer to Jamie's LHO elog for the equation governing quantum efficiency of photodiodes: LHO 2 Sept 2009

The information I gathered for each quadrant of each WFS was: [1] Power of light incident on PD (measured with the Ophir power meter), [2] Power of light reflected off the PD (since this light doesn't get absorbed, it's not part of the QE), and [3] the photo current output by the PD (To get this, I measured the voltage out of the DC path that is meant to go to EPICS, and backed out what the current is, based on the schematic, attached). 

I found a nifty 25 pin Dsub breakout board, that you can put in like a cable extension, and you can use clip doodles to look at any of the pins on the cable.  Since this was a PD activity, and I didn't want to die from the 100V bias, I covered all of the pins I wasn't going to use with electrical tape.  After turning down the 100V Kepco that supplies the WFS bias, I stuck the breakout board in the WFS.  Since I was able to measure the voltage at the output of the DC path, if you look at the schematic, I needed to divide this by 2 (to undo the 2nd op amp's gain of 2), and then convert to current using the 499 Ohm resistor, R66 in the 1st DC path.  

I did all 4 quadrants of WFS1 using a 532nm laser pointer, just to make sure that I had my measurement procedure under control, since silicon PDs are nice and sensitive to green.  I got an average QE of ~65% for green, which is not too far off the spec of 70% that Suresh found.

I then did all 8 WFS quadrants using the 1064nm CrystaLaser #2, and got an average QE of ~62% for 1064 (58% if I exclude 2 of the quadrants....see below).  Statistics, and whatever else is needed can wait for tomorrow.

Problem with 2 quadrants of WFS2?

While doing all of this, I noticed that quadrants 3 and 4 of WFS2 seem to be different than all the rest.  You can see this on the MEDM screens in that all 6 other quadrants, when there is no light, read about -0.2, whereas the 2 funny quadrants read positive values.  This might be okay, because they both respond to light, in some kind of proportion to the amount of light on them.  I ended up getting QE of ~72% for both of these quadrants, which doesn't make a whole lot of sense since the spec for green is 70%, and silicon is supposed to be less good for infrared than green.  Anyhow, we'll have to meditate on this.  We should also see if we have a trend, to check how long they have been funny.

 

  4307   Wed Feb 16 10:35:40 2011 Larisa ThorneUpdateIOOWFS quantum efficiency as a function of angle

 Here is the followup on Jenne's February 14th, 2011 update on the quantum efficiency measurements of WFS2.

http://nodus.ligo.caltech.edu:8080/40m/4289

 

Attached is a PDF of my calculations, based on measurements ranging between 0-25 degrees in 5 degree increments.

The graph at the bottom plots these angles versus the calculated quantum efficiency at each point and the responsivity. Since quantum efficiency and responsivity only differ by a factor of some natural constants (lamda, e, h, c), I used a graph with two vertical axes, because the points would be plotted at essentially the same location if quantum efficiency (%)  and responsivity (Amps/Watts) were graphed on two separate plots.

The calculated values for quantum efficiency based on my measurements (labelled "ExpAverage") were pretty close to what Jenne had calculated in earlier attempts, which was around 60%. Just to test, I compared my quantum efficiency result against the calculation of quantum efficiency using the responsivity value for silicon, 0.5 Amps/Watt, which is labelled as "Spec". Comparison of "ExpAverage" and "Spec" shows that they differ by only about 2%, so I conclude that the theoretical quantum efficiency calculated using a given responsivity agrees with my measurement-based experimental result.

ELOG V3.1.3-