Where are we going to put the tiki bar? The ice cream machine? I am disappointed in the details that appear to have been glossed over..

 Two quadratures working in harmony.

 Hi Rana,

It looks like the channe list file has a few blank lines that the channel list reader is choking on. I removed the lines and it is working now.. I have made the error message a bit more obvious (gave the file name  and line number) and allowed it to ignore empty lines so this won't cause problems with future versions (when installed). The bottom line is nds2 is now running on mafalda.
Best regards,

John   

Acromag Wireup Update

Channels no longer in use

• From the VME analog output (VMIVME 4116) to the QPD Whitening board (no DCC number on the front), 3 channels are no longer in use
• From the anti-image filter (D000186) to the ADC (VMIVME 3113A) 5 channels are no longer in use (these are the only channels from the anti-image filter, so this filter is no longer in use at all?)
• From the universal dewhitening filter (D000183) to a binary I/O adapter (channels 1-16), 4 channels are no longer in use. These are the only channels from the dewhitening filter
• From a second universal dewhitening filter (D000183) to another the binary I/O adapter (channels 1-16), one channel is no longer in use (this was the only channel from this dewhitening filter).
• From the opti-lever (D010033) to the VME ADC (VMIVME 3113A), 7 channels are no longer in use (this was all of the channels from the opti lever)
• From the SUS PD Whitening/Interface board (D000210) to a binary I/O adapter (channels 1-16), 5 channels are no longer in use. 
• Note that none of the binary I/O adapter channels are in use.

I checked out the elog from the vent in October 2016 when the OMC was removed from the path. In the vent in a couple weeks, we'd like to get the beam going through the OMC again. I wasn't really there for this last vent and don't have a great sense for how things go at the 40m, but this is how I think the procedure for this work should approximately go. The main points are that we'll need to slightly translate and rotate OM5, rotate OM6, replace one mirror that was removed last time, and add some beam dumps. Please let me know what I've got wrong or am missing.

[side note, I want to make some markup on the optics layouts that I see as pdfs elsewhere in the log and wiki, but haven't done it and didn't much want to dig around random drawing software, if there's a canonical way this is done please let me know.]

Steps to return the OMC to the IFO output:

1. Complete non-Steve portions of the pre-vent checklist (https://wiki-40m.ligo.caltech.edu/vent/checklist)
2. Steve needs to complete his portions of the checklist (as in https://nodus.ligo.caltech.edu:8081/40m/12557)
3. Need to lock some things before making changes I think—but I’m not really sure about these, just going from what I can glean from the elogs around the last vent
   1. ​Lock the IMC at low power
   2. Align the arms to green
   3. Lock the arms
   4. Center op lev spots on QPDs
   5. Is there a separate checklist for these things? Seems this locking process happens every time there is a realignment or we start any work, which makes sense, so I expect it is standardized.
4. Turn/add optics in the reverse order that Gautam did
   1. ​Check table leveling first?
   2. Rotate OM5 to send the beam to the partially transmissive mirror that goes to the OMC; currently OM5 is sent directly to OM6. OM5 also likely needs to be translated forward slightly; Gautam tried to maintain 45 deg AOI on OM5/6.
   3. A razor beam dump was also removed, which should be replaced (see attachment 1 on https://nodus.ligo.caltech.edu:8081/40m/12568)
   4. May need to rotate OM6 to extract AS beam again, since it was rotated last time
   5. Replace the mirror just prior to the window on the AP table, mentioned here in attachment 3: https://nodus.ligo.caltech.edu:8081/40m/12566
      1. ​There is currently a rectangular weight on the table where the mirror was, for leveling
5. Since Gautam had initially made this change to avoid some backscattered beams and get a little extra power, we may need to add some beam dumps to kill ghosts
   1. This is also mentioned in 12566 linked above, the dumps are for back-reflection off the windows of the OMC
6. Center beam in new path
7. Check OMC table leveling
8. AS beam should be round on the camera, with no evidence of clipping on any optics in the path (especially check downstream of any changes)

• 27 or 29 total ADC channels are used (depending whether we keep 2 spare adc chans)
  • 4 each go to ASC_QPD1/2 (8 chans total)
  • 5 go to TRANS_PD1, TRANS_PD2, REFL_PD, TRANS_PD1_UF, TRANS_PD2_UF. These PD are used for ASC and LSC.
  • 2 go to the LSC, one each for DVMDC, DVMAC, X3DC, and X4DC
  • 12 go to the ASC_PZT
  • 2 go to the SPARE_ADC (not sure what this is)
  • I think these channels are (or were at some point) defined in memory by /cvs/cds/caltech/chans/ipc/G1.ipc
    • I found this from elog 2860; it mentions that these should eventually be migrated over to a file C1.ipc, but I don't see any OMC channels in that file or any of the 'old' C1.ipc files, so I suppose it never happened or they were removed later
  • During this vent, we won't have ASC, so
• 10 or 14 DAC channels are used (depending whether we keep 4 spare dac chans)
  • 2 from the LSC, one for CLK_OUT and one for "LSC"
  • 8 from ASC, including P1A, P1B, P2A, P2B, P1OSC, Y1OSC, P2OSC, Y2OSC
  • I think these channels are (or were at some point) saved to frames due to /cvs/cds/caltech/chans/daq/C1OMC.ini, which I found from elog 2073
  • At some point, the 33MHz mod depth was controlled by one of the spare OMC chans, C1:OMC-SPARE_DAC_CH_15. See elog 2126. I assume this is no longer the case, since c1omc is defunct.
  • Durnig this vent, we won't have ASC and don't need to CLK_OUT the LSC, so we may just need one DAC channel

As of at least Nov 2009, the .par file for the OMC was located at /cvs/cds/gds/param/tpchn_C2 (see elog 2316)

• Kepco HV supply, "OMC-L-PZT", labels indicate it goes to 250V, needs to be tested  ("TESTED OK 2014OCT12")
• Tip/Tilt Piezo Driver, LIGO D060287
• HV Piezo Driver, LIGO D060283
• QPD Whitening Board, D060214
• LIGO D050374/D050387
• LIGO D050368/D050373

Need to check:

• Can the ADC/DAC adapter boards (eg D0902006) drive whatever ~10V control signal we need across ~10m of SCSI cable?
•  

I started this document on my own with notes as I was tracing the beam path through the output optics, as well as some notes as I started digging through the elogs. Let's just put it here instead....

1. Beam from AS port into OMMT
2. Reflect off OM5-PJ
   1. TO DO: check that the PZT works
   2. 40/P/F/L, 1525-45-P
3. Pick off from OMPO
   1. TO DO: determine how much power is needed for the pick off, choose an appropriate optic (for this vent probably 50-50 is fine)
   2. The PO beam goes to OM6
4. Reflect off MMT1???
   1. TO DO: determine if this mirror has a PZT, get it working
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
   2. TO DO: determine the real name of this optic, find its recent history in the elog
   3. TO DO: determine the correct telescope parameters to optimally couple into the mode cleaner given the following:
   4. TO DO: look up how the radius of curvature (RC) of the OMC has changed, and therefore what telescope parameters are necessary
5. Focused by MMT2???
   1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
   2. TO DO: determine the real name of this optic, find its recent history in the elog
   3. TO DO: what about this optic is tunable? It looks bulky
6. Columnated by MMT3???
   1. TO DO: determine if this mirror has a PZT
      1. Has a PZT?
      2. Which PZT channel on the DAQ?
      3. Is there a cable going to from the DAC to the PZT?
      4. Is the PZT functional?
      5. How many PZTs does this mirror actually have?
7. Steered by MMT4???
   1. TO DO: determine the real name of this optic
   2. TO DO: why is this optic so small? Looks different from the rest, maybe weird space constraint
8. Steered by MMT5???
   1. TO DO: why is this optic so large compared to OMMT4?
   2. TO DO: is there a more space efficient way of steering this beam, or even some way that avoids having to steer with three distinct optics
9. Steered by MMT6???
   1. TO DO: Can this optic be removed with some clever new beam path?
10. Cleaned by the OMC
    1. TO DO: Where does the promptly reflected beam from OMC1 go after it exits the chamber?
    2. TO DO: check the PZTs
       1. Has a PZT?
       2. Which PZT channel on the DAQ?
       3. Is there a cable going to from the DAC to the PZT?
       4. Is the PZT functional?
       5. How many PZTs does the OMC actually have?
    3. TO DO: Determine if a new OMC configuration would be more ideal for the squeezing experiment
       1. This is a large task, not part of this immediate vent
    4. TO DO: What is done with the OMC reflection? What is done with the transmission?
    5. TO DO: Check the logs about how the OMC had been in use; should be mostly from rob ward
11. Reflected beam goes to the next chamber
12. Transmitted beam is split by OM7???
    1. TO DO: find the actual name of this optic
    2. TO DO: why does this have the R/T that is does?
13. Reflected beam goes to my OMPD
    1. TO DO: figure out what this PD is used for, and whether we even need it
       1. I think this might be the camera mentioned in 40m elog 21
       2. Elog 42 says the 4 QPDs for the OMC have meds screens located under C2TPT—is this a clue for channel names?
14. Transmitted beam is reflected to the next chamber by OM8???
    1. TO DO: determine the name of this optic
    2. TO DO: Where does this beam go? What is it used for?
15. Beam Dumps to add
    1. Transmission through OM5? Probably don’t need…
    2. OMMT1 transmission
    3. OMMT steering mirror transmissions
    4. OMC transmissions? Probably not?
    5. OMPD transmission?
    6. OM8 transmission
    7. Green scattering off of the window where the beam goes after GR_SM5
    8. Backscatter from the OMC prompt reflection to the window
    9. Backscatter from the OMC reflection to the window
    10. Backscatter from the MC beam off the window (this beam just travels through this chamber, interacts with no optics; there is also what looks like a small blue beam on this diagram, so maybe need to dump that backscatter too)
    11. Backscatter from the PO beam from OM6 going through the chamber window
    12. Backscatter from IM1 out the window
    13. There is a small blue beam from OMMT3 that goes through this window as well, I’m not sure exactly what is is from or for, or if it is physical (there are a few of these strange blue lines, i'm probably just misreading the diagram)
16. TESTS TO DO
    1. Characterize the PZT control
    2. Lock the OMC with a PZT dither lock
       1. Eg elog 59
    3. “Tap-tap-tappy-tap test” to find resonanes
       1. Look at combination of PDH error signal and DCPD signal???
       2. See elog 86 for results from initial OMC install—Nov 2007
    4. Check wiggling wires, etc
    5. TFs to check? Vertical TF?
    6. OMC Length check— see for eg elog 768
17. ADDITIONAL TO DO
    1. Mode matching calculation for new radius of curvature optics—see elog 1271
       1. The current MMT is not the optimal configuration even for the old Rc (see 3077 and 3088)

Notes during reading elog

• Entry 590 has a labelled picture of the optics setup with OMC
• Mention of omcepics at elog 894
• Some important changes happened in elog 1823
  • 1''->2'' mirror out of the vacuum--I should check whether this is still there, or if it has been moved
  • [many more changes.....]
• There were at one time 2 cameras monitoring OMCT and R (see 4492, 4493)
• Some OMC PZT HV supply info is at elog 4738, 4740... 
• There are some photos of the OMC table at elog 5120, and a note about moving some optics
• Not strictly about the OMC, but I really like Suresh's diagram 6756, I'll make something similar for the OMC electronics
  • although it is about adding the tip tilt electronics, which I think required a new flange for the OMC chamber
• OMC stage 1 and 2 are the steering mirrors going into the OMC, and were controlled by EPICS chans (6875, 6884)
  • these PZT HV supplies lived in OMC_SOUTH (or maybe 1Y3? see elog 6893), the driver in OMC_NORTH (LIGO-D060287)
  • Photos of these supplies in 7696
• There are pictures of the OMC and its PZTs in 7401
• The OMC HV supply was moved to power a different set of PZTs (see 7603)
• Talk of replacing the PZTs with picomotors or tip/tilts in 7684
• More pictures of the OMC table before the OMC was 'removed' are here (8114) and in 12563/12571 Gautam links to a Picassa album with pictures from just before the beam was diverted

We found a diagram describing the DC Readout wiring scheme on the wiki page for DC readout (THIS DIAGRAM LIED TO US). The wiring scheme is in D060096 on the old DCC.

Following this scheme for the OMC PZT Driver, we measured the capacitance across pins 1 and 14 on the driver end of the cable nominally going to the PZT (so we measured the capacitance of the cable and PZT) at 0.5nF. Gautam thought this seemed a bit low, and indeed a back of the envelope calculation says that the cable capacitance is enough to explain this entire capacitance.

Gautam has gone in to open up the HV driver box and check that the pinout diagram was correct. We could identify the PZT from Gautam's photos from vent 79, but couldn't tell if the wires were connected, so this may be something to check during the vent.

UPDATE:

Turns out the output was pins 13 and 25, we measured the capacitance again and got 209nF, which makes a lot more sense.

In preparation for tomorrow's vent, I'm checking some of the OMC-related electronics we plan to use.

First up is the HV Piezo Driver (D060283).

(well, technically the first up was the Kepco HV power supply... but I quickly tested that its output works up to 300V on a multimeter. The power supply for OMC-L-PZT is all good!)

According to the DCC, the nominal HV supply for this board is 200V; the board itself is printed with "+400V MAX", and the label on the HV supply says it was run at 250V. For now I'm applying 200V. I'm also supplying +-15V from a Tektronix supply.

I used two DB25 breakout boards to look at the pins for the DC and AC voltage monitors (OMC_Vmon_+/-, pins 1/6, and OMC_Vmon_AC+/-, pins 2 and 7) on a scope. I hooked up a DS345 function generator to the piezo drive inputn (pins 1,6). According to the 2013 diagram from the DCC, there is just one drive input, and an alternative "dither in" BNC that can override the DAC drive signal. I leave the alternative dither floating and am just talking to the DAC pins.

Aspects of the system seem to work. For example, I can apply a sine wave at the input, and watch on the AC monitor FFT as I shift the frequency. However, anything I do at DC seems to be filtered out. The DC output is always 150V (as long as 200V comes from the supply). I also notice that the sign of the DC mon is negative (when the Vmon_+ pin is kept high on the scope), even though when I measure the voltage directly with a multimeter the voltage has the expected (+) polarity.

A few things to try:

• The DC_Readout electronics scheme on the wiki has separate oscillator and control inputs. This diagram has lied to us in the past and is older, and the traces on top of the breadboard seem to only go to pins 1 and 6, but I'm going to first try to apply a voltage across pins 2 and 7 in case there actually is a separate control I'm ignoring.
  • Driving on these pins seems to do nothing

On further investigation this was the key clue. I had the wrong DCC document, this is an old version of this board, the actual board we are using is version A1 of D060283-x0 (one of the "other files")

Gautam and Koji returned at this point and we started going through the testpoints of the board, before quickly realizing that the DC voltage wasn't making it to the board. Turns out the cable was a "NULL" cable, so indeed the AC wasn't passing. We swapped out the cable, and tested the circuit with 30V from the HV supply to trim the voltage reference at U14. The minimum voltage we could get is 5V, due to the voltage divider to ground made by R39. We confirmed that the board, powered with 200V, can drive a sine wave and the DC and AC mons behave as expected.

[aaron, steve]

Steve gave me a venting tutorial. I'll record this in probably a bit more detail than is strictly necessary, so I can keep track of some of the minor details for future reference.

Here is Steve's checklist:

• Check that all jam nuts are tightened
• all viewports are closed
• op levs are off
• take a picture of the MEDM screens
• Check particle counts
• Check that the cranes work & wiped
• Check that HV is off

Gautam already did the pre-vent checks, and Steve took a screenshot of the IFO alignment, IMC alignment, master op lev screen, suspension condition, and shutter status to get a reference point. We later added the TT_CONTROL screen. Steve turned off all op levs.

We then went inside to do the mechanical checks

• N2 cylinders in the 40m antechamber are all full enough (have ~700psi/day of nitrogen)
• We manually record the particle count
  • this should be <10,000 on the 0.5um particles to be low enough to vent, otherwise we will contaminate the system
  • note: need to multiply the reading on the particle counter by 10 to get the true count
  • the temperature inside the PSL enclosure should be 23-24C +/- 3 degrees
  • We recorded the particle counts at ~830 and ~930, and the 0.5um count was up to ~3000
• We put a beam stop in front of the laser at the PSL table
• Checked that all HV supplies are either off or supplying something in air
  • we noticed four HV supplies on 1X1 that were on. Two were accounted for on the PSL table (FSS), and the other two were for C1IOO_ASC but ran along the upper cable rack. We got ahold of Gautam (sorry!) and he told us these go to the TT driver on OMC_SOUTH, where we verified the HV cables are disconnected. We took this to mean these HV supplies are not powering anything, and proceeded without turning these HV off.
  • There are HV supplies which were all either off or supplying something in-air at: 1Y4, 1Y2, OMC N rack, 1X9 (green steering HV)
• Checked that the crane works--both move up and down
  • vertex crane switch is on the wall at the inner corner of the IFO
  • y arm crane switch is on the N wall at the Y end
  • turn off the cranes at the control strip after verifying they work
• While walking around checking HV, we checked that the jam nuts and viewports are all closed
  • we replaced one viewport at the x arm that was open for a camera

After completing these checks, we grabbed a nitrogen cylinder and hooked it up to the VV1 filter. Steve gave me a rundown of how the vacuum system works. For my own memory, the oil pumps which provide the first level of roughing backstream below 500mtorr, so we typically turn on the turbo pumps (TP) below that level... just in case there is a calibrated leak to keep the pressure above 350mtorr at the oil pumps. TP2 has broken, so during this vent we'll install a manual valve so we can narrow the aperture that TP1 sees at V1 so we can hand off to the turbo at 500mtorr without overwhelming it. When the turbos have the pressure low enough, we open the mag lev pump. Close V1 if things screw up to protect the IFO. This 6" id manual gatevalve will allow us throttle the load on the small turbo while the maglev is taking over the pumping  The missmatch in pumping speed is 390/70 l/s [ maglev/varian D70 ]  We need to close down the conductive intake of the TP1 with manual gate valve so the 6x smaller turbo does not get overloaded...

We checked CC1, which read 7.2utorr.

Open the medm c0/ce/VacControl_BAK.adl to control the valves.

Steve tells me we are starting from vacuum normal state, but that some things are broken so it doesn't exactly match the state as described. In particular, VA6 is 'moving' because it has been disconnected and permanently closed to avoid pumping on the annulus. During this v ent, we will also keep pumping on the RGA since it is a short vent; steve logged the RGA yesterday.

We began the vent by following the vacuum normal to chamber open procedure.

1. VM1 closed
2. We didn't open VM3, because we want to keep the RGA on
3. Closed V1
4. Connect the N2 to the VV1 filter
   1. first puged the line with nitrogen
   2. We confirmed visually that V1 is closed
5. We opened VM2 to pump on the RGA with the mag lev pump.
   1. This is a nonstandard step because we are keeping the RGA pumped down.
   2. The current on TP3 is ~0.19A, which is a normal, low load on the pump
6. VV1 opened to begin the vent at ~10:30am
   1. use crescent wrench to open, torque wrench wheel to close
   2. Keep the pressure regulator below 10 psi for the vent. We started the vent with about 2psi, then increased to 8psi after confirming that the SUS sensors looked OK.
7. We checked the pressure plot and ITMX/ETMX motion to make sure we weren't venting too quickly or kicking the optics
   1. Should look at eg C1:SUS-ITMX_SENSOR_LL, as well as C1:Vac-P1_pressure
8. Once the pressure reaches 25torr, we switched over to dry air
   1. wipe off the outside dolly wheels with a wet rag, and exit through the x-arm door to get the air. Sweep off the area outside the door, and wipe off new air containers with the rag.
   2. Bring the cylinder inside, get the regulator ready/purged, and swap relatively quickly.
   3. We increased the vent speed to 10psi. 
   4. Steve says the vents typically take 4 of 300 cf cylinders from Airgas "Ultra Zero" AI  UZ300 that contains 0.1 PPM of THC

Everything looks good, so I'm monitoring the vent and swapping out cylinders.

At 12:08pm, the pressure was at 257 torr and I swapped out in a new cylinder.

Steve: Do not overpressurize the vacuum envelope! Stop around 720 Torr and let lab air do the rest. Our bellows are thin walled for seismic isolation.

Next check is the DCPD/OMMT Satellite Box

I traced a cable from the OMC electrical feedthrough flanges to find the DCPD/OMMT Satellite Box (D060105). I couldn't find the DCC number or mention of the box anywhere except this old elog.

Gautam and I supplied the box with power and tested what we think is the bias for the PD, but don't read any bias... we tracked down the problem to a suspicious cable, labelled.

We confirmed that the board supplies the +5V bias that Rich told us we should supply to the PDs.

We tested the TFs for the board from the PD input pins to output pins with a 100kHz low pass (attached, sorry no phase plots). The TFs look flat as expected. The unfiltered outputs of the board appear bandpassed; we couldn't identify why this was from the circuit diagram but didn't worry too much about it, as we can plan to use the low passed outputs.

I learned a lot about lasers this week from Siegman. Here are some plots that show the expected reflectivity off of the OMC for various mode matching cases.

The main equation to know is 11.29 in Siegman, the total reflection coefficient going into the cavity:

Where r is the mirror reflectivity (assumed all mirrors have the same reflectivity), t is the transmissivity, and g is the complex round-trip gain, eq 11.18

The second exponential is the loss; in Siegman the \alpha_0 is some absorption coecfficient and p is the total round trip length, so the product is just the total loss in a round trip, which I take to be 4*the loss on a single optic (50ppm each). \phi is the total round trip phase accumulation, which is 2\pi*detuning(Hz)/FSR. The parameters for the cavity can be found on the wiki.

I've added the ipynb to my personal git, but I can put it elsewhere if there is somewhere more appropriate. I think this is all OK, but let me know if something is not quite right.

Gautam and I tested out the DAC that he installed in the latter half of last week. We confirmed that at least one of the channels is can successfully drive a sine wave (ch10, 1-indexed). We had to measure the output directly on the SCSI connector (breakout in the FE hard drive cabinet along the Y arm), since the SCSI breakout box (D080303) seems not to be working (wiring diagram in Gautam's elog from his SURF years).

I've started putting together a list of things we'll need to buy to do BHD readout. I'm still messing around with more detailed optics layouts, but wanted to get a list started here so people can let me know if I'm missing any big, obvious categories of goods.

My current plan makes minimal changes to the signal path going to the OMC, and tries to just get the LO beam into the OMC with minimal optics. I'm not thinking of any of the optics as suspended, and it requires several reflections of the LO beam, so probably this is not an excellent configuration, but it's a start for getting the parts list:

1. My current thought is to use the MC reflection, the beam that heads from MC1 to MCR1, as the LO beam
   1. From MCR1, send the LO to a BS that directs it into an MMT, oriented along x (and lets us keep the MC refl PO)
   2. After the two MMT optics, the beam will be traveling along -x, and can be directed to a mirror that sends it towards -y to two steering mirrors that send it along -x then +x near the top of the table (perpendicular to the signal MMT.
   3. Then, send it to a PBS, which replaces the mirror directly after the signal MMT. This is where it combines 
2. Beam is then sent to the steering mirrors to bring it into the OMC
3. In parallel, the signal beam is going through the same path it has now, including the pickoff beam, with the one change that we need a HWP somewhere before the PBS, and the PBS replaces the mirror directly after the MMT (and needs to move a bit closer to have the beam properly directed)

I started making a layout of this scheme, but it's probably not going to work so I'm going to make a quick layout of this more major modification instead:

1. Both the MCR beam and the AS beam come in about parallel. Send each to a PO mirror.
2. The PO mirror directs both beams into parallel MMT aligned along x
3. From the MMT, each is directed to a pair of steering mirrors located where the OMC MMT is located now
4. From the steering mirrors go to the PBS that combines the signal and LO
5. Then to two more steering mirrors to get into the OMC, which may be moved towards +x
6. From the OMC go to the BHD PBS

What we need

Optics

• HWP for just before the LO combines with the signal
• HWP for just before the signal combines with the LO (is this necessary?)
• PBS to replace OM5 (combines the LO and the signal)
• Two MMT optics
• Two piezo-driven TT optics for steering the LO to the PBS
• One additional non-piezo optic for between the LOMMT and the LO-TTs
• One additional BS to get the LO into the MMT (and to let us still have the PO)
• -1 optic—we pick up one mirror that we replace with the PBS

Optomechanics

• 2x HWP mounts
• 1x PBS mount
• 2x mounts for piezo-driven TT
• 2x MMT optic mounts—I didn’t take a close enough look at these during the vent to know what we need here
• 2x mounts for ordinary optics
• 9x clamps for optics mounts (maybe fewer if some are on blocks)
• 9x posts for optics mounts

Electronics

• Additional TT driver
• HV supply for the new TTs
• Are the HWP actively controlled? We might need something to drive those?
• Do we have enough DAC/ADC channels?

Questions

These are mostly just miscellaneous

1. What of these optics need to be suspended? If we need suspensions on all of the LO optics, including the MMT, I’m not sure we’re going to be able to fit all of this on the table as I envision it…..
2. What if anything can we put out of vacuum (HWP for example)?
3. Do we actually need two MMT?

That seems fine, I wasn't thinking of that beam. in that case could we just have a PBS directly behind MMT2 and send both beams to the same OMMT?

Alternatively we can move OM5 and the beam path OMPO-OMMTSM towards -y, then put the LO-OMMT parallel to the existing OMMT but displaced in +x... we'd have to move the existing OMC and BHD towards +x as well. 

I've attached the diagram of what I mean.

There are a couple caveats and changes that would have to be made that are not included in this diagram, because they would be made on different tables.

1. I moved MMT2, which means the other MMT optics would have to be adjusted to accomodate this. I checked out the configuration on the BS table and this seems doable with a small rotation of MMT1 and maybe PJ2.
2. I don't know the best way to get the OMC REFL beam out... thoughts?
3. This diagram is kind of crappy after my edits, someone should tell me how to avoid collapsing all layers when I open these layout diagrams in inkscape, because I ended up editing the layout in Acrobat instead, where the lack of object grouping caused a bunch of the optics to lose one or two lines along the way.
4. I didn't include all beam paths explicitly but can if this looks like a good configuration.
5. The optic that picks off the transmission through MMT2 will need to move a bit, but there was a clamp in the way; this should be a minor change.
6. The optic just before the OMC needs to be moved up a bit.
7. The optic after the signal OMMT should be changed to a PBS and translated a bit; this is where the LO and signal beams will combine

Gautam also had some questions about the BHD/OMC timeline and plan. I feel somewhat on shaky ground with the answers, but figured I'd post them so I can be corrected once and for all.

1. Is the plan really to use the current OMC setup to make a homodyne measurement? 
   1. ​I'm not sure where on the timeline the new OMC and BHD switchover are relative to each other. I have been imagining doing the swap to BHD before having a new OMC.
2. I thought the current OMC resurrection plan was to do DC readout and not homodyne?
   1. ​I think the OMC resurrection plan is leading to DC readout, but when we switch over to BHD we'll be able to operate at the dark fringe. Is that right?
3. Is it really possible to use our single OMC to clean both the LO and dark port beams? Isn't this the whole raging debate for A+?
   1. ​My understanding is yes, with the LO and DP in orthogonal polarizations. It's not clear to me why we expect to be able to do this while there is a debate for A+, perhaps our requirements are weaker. It is something I should calculate, I'll talk to Koji.
4. A layout diagram would be really useful.
   1. ​Attached now.
5. Where in the priority list does this come in?
   1. ​I am a leaf in the wind. I think this comes well after we have the OMC resurrected, we just want to get a sense for what parts we need so we can order them before the fiscal year closes.

[aaron, gautam]

We finished up making the new c1omc model  (screenshot attached).

The new channels are only four DAC for ASC into the OMC, and one DAC for the OMC length:

I made a script to scan the OMC length at each setpoint for the two TTs steering into the OMC. It is currently located on nodus at /users/aaron/OMC/scripts/OMC_lockScan.py.

I haven't tested it and used some ez.write syntax that I hadn't used before, so I'll have to double check it.

My other qualm is that I start with all PZTs set at 0, and step around alternative +/- values on each PZT at the same magnitude (for example, at some value of PZT1_PIT, PZT1_YAW, PZT2_PIT, I'll scan PZT2_YAW=1, then PZT2_YAW=-1, then PZT2_YAW=2). If there's strong hysteresis in the PZTs, this might be a problem.

I'm continuing the arm loss measurements Yuki was making. I'm first familiarizing myself with the procedures for the measurement Johannes describes.

I'm not very familiar with the medm screens, so I'm just kind of poking around and checking with Gautam. I do the following:

1. Turned Xarm ASS dither on, then off.
2. Turned X and Y ALS on, then off shortly after
   1. Realizing I needed some guidance, I found this page on lock acquisition on the wiki
   2. Gautam showed me how to align/lock the IFO so I could take some notes, and we locked the Y arm, misaligned X.
3. I put the PD back in the AS beam path to get the ASDC signal, and approximately centered the beam. This PD is on channel 1 of the scope, which is at 192.168.113.24.
4. I centered the beam onto the MC2 PD that Yuki had installed. This PD is on channel 2 of the scope.
   1. Both scope channels are set to 1V scale (I also had tried 500mV, and it didn't seem to make a difference) and 10s time axis spacing (maximum integration time, since we're looking for a DC effect. Is this what we want?)
   2. The impedance for both channels is 1MOhm.
5. I ran the script to start the loss measurement on the Y arm.
   1. python2 armloss_dcrefl_asdcpd_scope.py 192.168.113.24 1 2 5 YARM
   2. I'm reading ~15 (au?) for the MC channel and ~5% of that out the AS, which seems to make sense to me and looked to be about what Yuki the ratios when I checked the log files. However, I'm a bit confused by the normalization, because the maximum output of the MC PD is 10V, and indeed the scope's display is reading under 10V.

I've left the script running.

After running this script Friday night, i noticed Saturday that the data hadn't saved. Scrolling up inthe terminal, I couldn't see where I'd run the script, so I thought I'd forgotten to run it as I was making last minute changes to the scope settings Friday before leaving.

Monday it turns out I hadn't forgotten to run the script, but the script itself was getting hung up as it waited for ASS to settle, due to the offset on the ETM PIT or YAW setpoints. The script was waiting until both pitch and yaw settled to below 0.7, but yaw was reading ~15; I think this is normal, and it looks like Yuki had solved this problem by waiting for the DEMOD-OFFSET to become small, rather than just the DEMOD signal to be small. Since this is a solved problem, I think I might be using an old script, but I'm pretty sure I'm running the one in Johannes' folder that Yuki is referencing for example here. The scripts in /yutaro_scripts/ have this DEMOD-OFFSET functionality commented out, and anyway those scripts seem to do the 2D loss maps rather than 1D loss measurements.

In the meantime I blocked the beams and ran the script in DARK mode. The script is saving data in /armloss/data/run_20181105/, and runs with no exceptions thrown.

However, when I try to dither align the YARM, I get an error that "this is not a degree of freedom that has an ASS". I'm alsogetting some exceptions from MEDM about unavailable channels. It must have been something about donatella not initializing, because it's working on pianosa. I turned on YARM ADS from pianosa. Monitoring from dataviewer, I see that LSC-TRY_OUT has some spikes to 0.5, but it's mostly staying near 0. I tried returning to the previous frozen outputs, and also stepping around ETMY-[PIT/YAW] from the IFO_ALIGN screen, but didn't see much change in the behavior of LSC-TRY. I missed the other controls Gautam was using to lock before, and I've also made myself unclear on whether ASS is acting only on angular dof, or also on length.

I unblocked the beams after the DARK run was done.

New all organic machine.

I'm checking out the data this morning, running armloss_AS_calc.py using the parameters Yuki used here.

I made the following changes to scripts (measurement script and calculator script)

• Included the 'hour' of the run in the armloss_dcrefl_* script. This way, we can run more than once a day without overwriting data.
• Changed the calculator script to loop over all iterations of locked/misaligned states, and calculate the loss for adjacent measurements.
  • That is, the measurement script will make a measurement with the arm locked, then with it misaligned, and repeat that N times
  • The calculator now finds the loss for the nth iteration using *_n_locked and *_n_misaligned, and finds N separate loss measurements
  • The dark signal is also computed N times, though all of the dark measurements are made before running the arm scripts, so they could be all integrated together.
  • All of these are saved in the same directory that the data was grabbed from.

I repeated the 'dark' measurements, because I need 20 files to run the script and the measurements before had the window on the scope set larger than the integration time in the script, so it was padded with bad values that were influencing the calculation.

On running the script again, I'm getting negative values for the loss. I removed the beamstops from the PDs, and re-centered the beams on the PDs to repeat the YARM measurements.

That was likely me. I had recentered the beam on the PD I'm using for the armloss measurements, and I probably moved the wrong steering mirror. The transmission from MC2 is sent to a steering mirror that directs it to the MC2 transmission QPD; the transmission from this steering mirror I direct to the armloss MC QPD (the second is what I was trying to adjust).

Note: The MC2 trans QPD goes out to a cable that is labelled MC2 op lev. This confusion should be fixed.

I realigned the MC and recentered the beam on the QPD. Indeed the beam on MC2 QPD was up and left, and the lock was lost pretty quickly, possibly because the beam wasn't centered. Lock was unstable for a while, and I rebooted C1PSL once during this process because the slow machine was unresponsive.

When tweaking the alignment near MC2, take care not to bump the table, as this also chang es the MC2 alignment.

Once the MC was stably locked, I was able to maximize MC transmission at ~15,400 counts. I then centered the spot on the MC2 trans QPD, and transmission dropped to ~14800 counts. After tweaking the alignment again, it was recovered to ~15,000 counts. Gautam then engaged the WFS servo and the beam was centered on MC2 trans QPD, transmission level dropped to ~14,900.

Gautam was doing some DRMI locking, so I replaced the photodiode at the AS port to begin loss measurements again.

I increased the resolution on the scope by selecting Average (512) mode. I was a bit confused by this, since Yuki was correct that I had only 4 digits recorded over ethernet, which made me think this was an i/o setting. However the sample acquisition setting was the only thing I could find on the tektronix scope or in its manual about improving vertical resolution. This didn't change the saved file, but I found the more extensive programming manual for the scope, which confirms that using average mode does increase the resolution... from 9 to 14 bits! I'm not even getting that many.

There's another setting for DATa:WIDth, that is the number of bytes per data point transferred from the scope.

I tried using the *.25 scope instead, no better results. Changing the vertical resolution directly doesn't change this either. I've also tried changing most of the ethernet settings. I don't think it's something on the scripts side, because I'm using the same scripts that apparently generated the most recent of Johannes' and Yuki's files; I did look through for eg tds3014b.py, and didn't see the resolution explicitly set. Indeed, I get 7 bits of resolution as that function specifies, but most of them aren't filled by the scope. This makes me think the problem is on the scope settings.

I began moving the AA and AI chassis over to 1X1/1X2 as outlined in the elog.

The chassis were mostly filled with empty cables. There was one cable attached to the output of a QPD interface board, but there was nothing attached to the input so it was clearly not in use and I disconnected it.

I also attach a picture of some of the SMA connectors I had to rotate to accommodate the chassis in their new locations.

Update:

The chassis are installed, and the anti-imaging chassis can be seen second from the top; the anti-aliasing chassis can be seen 7th from the top.

I need to breakout the SCSI on the back of the AA chassis, because ADC breakout board only has a DB36 adapter available; the other cables are occupied by the signals from the WFS dewhitening outputs.

I ran a BNC from the PD on the AS table along the cable rack to a free ADC channel on the LSC whitening board. I lay the BNC on top of the other cables in the rack, so as not to disturb anything. I also was careful not to touch the other cables on the LSC whitening board when I plugged in my BNC. The PD now reads out to... a mystery channel. The mystery channel goes then to c1lsc ADC0 channels 9-16 (since the BNC goes to input 8, it should be #16). To find the channel, I opened the c1lsc model and found that adc0 channel 15 (0-indexed in the model) goes to a terminator.

Rather than mess with the LSC model, Gautam freed up C1:ALS-BEATY_FINE_I, and I'm reading out the AS signal there.

I misaligned the x-arm then re-installed the AS PO PD, using the scope to center the beam then connecting it to the BNC to (first the mystery channel, then BEATY). I turned off all the lights.

I went to misalign the x-arms, but the some of the control channels are white boxed. The only working screen is on pianosa.

The noise on the AS signal is much larger than that on the MC trans signal, and the DC difference for misaligned vs locked states is much less than the RMS (spectrum attached); the coherence between MC trans and AS is low. However, after estimating that for ~30ppm the locked vs misaligned states should only be ~0.3-0.4% different, and double checking that we are well above ADC and dark noise (blocked the beam, took another spectrum) and not saturating the PD, these observations started to make more sense.

To make the measurement in cds, I also made the following changes to a copy opf Johannes' assess_armloss_refl.py that I placed in /opt/rtcds/caltech/c1/scripts/lossmap_scripts/armloss_cds/   :

• function now takes as argument the number of averages, averaging time, channel of the AS PD, and YARM|XARM|DARK.
• made the data save to my directory, in /users/aaron/40m/data/armloss/

I started taking a measurement, but quickly realized that the mode cleaner has been locked to a higher order mode for about an hour, so I spend some time moving the MC. It would repeatedly lock on the 00 mode, but the alignment must be bad because the transmission fluctuates between 300 and 1400, and the lock only lasts about 5 minutes.

Back to loss measurements.

I replaced the PD I've been using for the AS beam.

I misaligned the x arm.

I tried to lock the y arm, but PRC was locked so I could was unable. Gautam reminded me where the config scripts are.

The armloss measurement script needed two additional modifications:

• It was setting the initial offset of the PIT and YAW demod signals to 0, but due to the clipping on the heater we are operating at an offset. I commented out these lines.
• When the script ran UNFREEZE_DITHER, it was running it using medmrun. The scope script hadn't been using this, and it seemed that when it ran UNFREEZE_DITHER in this way the YARM_ASS servo was passing only '0'. I don't really know why this was, but when I removed the call to medmrun it worked.

I ran successfully the loss measurement script for the x and y arms. I'm getting losses of ~100ppm from the first estimates.

I made the following changes to the lossmap script:

• make the averaging time an input to the script, so we can exceed 2 second averages
• remove anything about getting data from the scope, replace it with the correct analogues to save the averages for POX/POY refl, MC trans, op lev P/Y, and ASDC signal.
• record the GPS time in the file with the cds averages (this way I can grab the full data)
• Added a step in the lossmap script to misalign the optic, so we can continue getting data for the 'misaligned' state, both for the centered and not-centered measurements (that is, for every position on the lossmap).

When the optic aligns itself not at the ideal position, I'm noticing that it often locks on a 01. When the cavity is then misaligned and restored, it can no longer obtain lock. To fix this, I've moved my 'save' commands to just before the loop begins. This means the script may take longer to run, but as long as the cavity is initially locked and well aligned, this should make it more robust against wandering off and never reacquiring lock.

I left the lossmap script running for the x-arm. Next would be to run it for the y arm, but I see that after stepping to a few positions the lock is again lost. It's still trying to run, but if you want to stop it no data already taken will be lost. To stop it, go to the remaining terminal open on rossa and ctrl+c

the analysis needs:

• Windowing
• Filter, don't average
• detrend to get rid of the linear drifts in lock that we see.
  • Is this the right thing?

I made additional measurements on the x and y arms, at 5 offset positions for each arm (along with 6 measurements at the "zeroed" position).

I finished running the cabling for the OMC, which involved running 7x 50ft DB9 cables from the OMC_NORTH rack to the 1X2 rack, laying cables over others on the tray. I tried not to move other cables to the extent I could, and I didn't run the new cables under any old cables. I attach a sketch diagram of where these cables are going, not inclusive of the entire DAC/ADC signal path.

I also had to open up the AA board (D050387, D050374), because it had an IPC connector rather than the DB37 that I needed to connect. The DAC sends signals to a breakout board that is in use (D080302) and had a DB37 output free (though note this carries only 4 DAC channels). I opened up the AA board and it had two IPC 40s connected to an adapter to the final IPC 70 output. I replaced the IPC40 connectors with DB37 breakouts, and made a new slot (I couldn't find a DB37 punch, so this is not great...) on the front panel for one of them, so I can attach it to the breakout board.

I noticed there were many unused wires, so I had to confirm that I had the wiring correct (still haven't confirmed by driving the channels, but will do). There was no DCC for D080302, but I grabbed the diagrams for the whitening boards it was connected to (D020432) and for the AA board I was opening up as well as checked out elog 8814, and I think I got it. I'll confirm this manually and make a diagram if it's not fake news.

I replaced the projector bulb. Previous bulb was shattered.

I've started testing the OMC channels I'll use.

I needed to update the model, because I was getting "Unable to setup testpoint" errors for the DAC channels that I had created earlier, and didn't have any ADC channels yet defined. I attach a screenshot of the new model. I ran

I need to hookup +/- 24 V supplies to the OMC whitening/dewhitening boxes that have been added to 1X2.

There are trailing +24V fuse slots, so I will extend that row to leave the same number of slots open.

While removing one +24V wire to add to the daisy chain, I let the wire brush an exposed conductor on the ground side, causing a spark. FSS_PCDRIVE and FSS_FAST are at different levels than before this spark. The 24V sorensens have the same currents as before according to the labels. Gautam advised me to remove the final fuse in the daisy chain before adding additional links.

gautam: we peeled off some outdated labels from the Sorensens in 1X1 such that each unit now has only 1 label visible reflecting the voltage and current. Aaron will post a photo after his work.

I did some ray tracing and determined that the aux beam will enter the OMC after losing some power in reflection on OMPO (couldn't find this spec on the wiki, I remember something like 90-10 or 50-50) and the SRM (R~0.9), and then transmission through OMPO. This gives us something like 8%-23% of the aux light going to the OMC, depending on the OMPO transmission. This elog tells me the aux power before the recombination BS is ~37mW, ~3.7mW onto SRM, which is consistent with the OMPO being 90-10, and would mean the aux power onto the OMC is ~3mW, plenty for aligning into the OMC.

Since the dewhitening board I'd intended to use isn't working (see elog) , I'm gong to scan the OMC length with a function generator while adjusting the alignment by hand, as was briefly attempted during the last vent.

I couldn't identify a PD on the AP table that was the one I had used during the last vent, I suspect I coopted the very same PD for the arm loss measurements. It is a PDA520, which has a large (100mm^2) area so I've repurposed it again to catch the OMC prompt reflection during the mode scans. I've mounted it approximately where I expect the refl beam to exit the AS chamber.

I brought over the cart that usually lives at 1X1 to help me organize materials near the OMC chamber for opening.

I replaced the banana connectors we'd been using to send HV to the HV driver with soldered wires going to the final locking connector only, so now the 150V is on a safe cable.

I powered up the DCPD sat box and again confirmed that it's working. I sent a 500Hz sine wave through the sat box and confirmed that I can see the signal in the DCPD channels I've defined in cds. I gave the TT and OMC-L PZT channels bad assignments on the ADC (right now, what reads as 'OMC_PZT_MON' is actually the unfiltered output from the sat box, while the DCPD channels are for the filtered outputs of the box), because the way the signals are grouped on the cables I can't attach all of them at once. For this vent, I'll only really need the DCPD outputs, and since I have confirmed that I can read out both of those I'll fix up the HV driver mon channels later.

I kept having trouble keeping the power LEDs on the dewhitening board 'on'. I did the following:

1. I noticed that the dewhitening board was drawing a lot of current (>500mA), so I initially thought that the indicators were just turning on until I blew the fuse. I couldn't find the electronics diagrams for this board, so I was using analagous boards' diagrams and wasn't sure how much current to expect to draw. I swapped out for 1A fuses (only for the electronics I was adding to the system).

2. Now the +24V indicator on the dewhitening board wasn't turning on, and the -24V supply was alternatively drawing ~500mA and 0mA in a ~1Hz square wave. Thinking I could be dropping voltage along the path to the board, I swapped out the cables leading to the whitening/dewhitening boards with 16AWG (was 18AWG). This didn't seem to help.

3. Since the whitening board seemed to be consistently powered on, I removed the dewhitening board to see if there was a problem with it. Indeed, I'd burned out the +24V supply electronics--two resisters were broken entirely, and the breadboard near the voltage regulator had been visibly heated.

1. I identified that the resistors were 1Ohm, and replaced them (though I couldn't find 1Ohm surface mount resistors). I also replaced the voltage regulator in case it was broken. I couldn't find the exact model, so I replaced the LM2940CT-12 with an LM7812, which I think is the newer 12V regulator.
2. Though this replacement seemed to work when the power board was disconnected from the dewhitening board, connecting to the dewhitening board again resulted in a lot of current draw.
3. I depowered the board and decided to take a different approach (see)

I noticed that the +/-15V currents are slightly higher than the labels, but didn't notice whether they were already different before I began this work.

I also noticed one pair of wires in the area of 1X1 I was working that wasn't attached to power (or anything). I didn't know what it was for, so I've attached a picture.

Taking another look at the datasheet, I don't think LM7812 is an appropriate replacement and I think the LM2940CT-12 is supposed to supply 1A, so it's possible the problem actually is on the power board, not on the dewhitening board. The board takes +/- 15V, not +/- 24...

Koji gave me some tips on testing this board that I wanted to write down, notes probably a bit intermingled with my thoughts. Thanks Koji, also for the DCC and equipment logging!

• Test the power and AI boards separately with an external supply, ramping the voltage up slowly for each.
• If it seems the AI board is actually drawing too much current, may need to check its TPs for where a problem might be
  • If it's really extensive may use an IR camera to see what elements are getting too hot
  • Testing in segments will prevent breaking more components
• Check the regulator that I've replaced
• The 1 Ohm resistors may have been acting as extra 1A fuses. i need to make sure the resistors I've used to replace them are rated for >1W, if this is the case.
• Can check the resistance between +-12V and Gnd inputs on the AI board, if there is a short drawing too much current it may show up there.
• The 7812 may be an appropriate regulator, but the input voltage may need to be somewhat higher than with the low drop regulator that was used before.
• I want to double check the diagram on the DCC

I set up a function generator to drive OMC-L, and have the two DCPD mons and the OMC REFL PD sent to an oscilloscope. I need to select a cds channel over which to read the REFL signal.

The two DCPD mon channels have very different behaviors on the PD mons at the sat box (see attachment). PD1 has an obvious periodicity, PD2 has less noise overall and looks more white. I don't yet understand this, and whether it is caused by real light, something at the PDs, or something at the sat box.

I've again gone through the operations that will happen with the OMC chamber vented. Here's how it'll go, with some of the open questions that I'm discussing with Gautam or whoever is around the 40m:

1. Function generator is driving OMC-L. Right now there is one 150V Kepco supply in use, located on the ground just to the right of the OMC rack. I only have plans to power it on while scanning OMC-L, and until the OMC is fully in use the standard practice will be to use this HV with two people in the lab and shut it off after the immediate activities.
   1. To do: Is a second drive necessary for the TT drivers? I don't think it is during this vent, because we will want to align into the OMC with the TTs in a 'neutral' state. I recall that the way the TT drivers are set up, 0V from the dac to the driver is the 'centered' position for all TTs. Unless we want to compensate for some known shift of the chambers during pumpdown, I think this is the TT position we should use while aligning the OMMT into the OMC.
   2. To do: make sure I'm driving the right pins with the function generator. Update: Seems I was driving the right channels, here's the pinout.
2. We will use the reflection of aux from the SRM to align into the OMC.
   1. Gautam pointed out that I hadn't accounted for the recombination BS for the aux beam being 90-10. This means there's actually something like 300uW of aux onto the OMC, rather than ~3mW. This should still be enough to see on a card, so it is fine.
   2. However, the aux beam is aligned to be colinear with the AS beam when the SRM is misaligned. So the question is whether the wedge on the SRM makes the SRM-reflected aux beam not colinear with the AS beam

---------

Talked with Gautam for a good while about the above plan. In trying to figure out why the DCPD sat box appears to have a different TF for the two PDs (seems to be some loose cabling problem at the mons, because wiggling the cables changed this), we determined that the AA chassis also wasn't behaving as expected--driving the expected channels (28-31) with a sine wave yields some signal at the 100Hz driving frequency, but all save ch31 were noisy. We also still saw the 100Hz when the chassis was unplugged. I will continue pursuing this, but in the meantime I'm making an IDE40 to DB37 connector so I can drive the ADC channels directly with the DAC channels I've defined (need to match pinouts for D080303 to D080302). I also will make a new SCSI to DB37 adapter that is more robust than mentioned here. I also need to replace the cable carrying HV to the OMC-L driver, so that it doesn't have a wire-to-wire solder joint.

We moved a razor blade on the AP table so it is no longer blocking the aux beam. We checked the alignment of aux into the AS port. AUX and AS are not colinear anywhere on the AP table, and despite confirming that the main AS beam is still being reflected off of the OMC input mirror, the returning AUX beam does not reach the AP table (and probably is not reaching the OMC). AUX needs to be realigned such that it is colinear with the AS beam. It would be good if in this configuration, the SRM is held close to its position when the interferometer is locked, but the TTs should provide us some (~2.5mrad) actuation. Gautam will do this alignment and I will calculate whether the TTs will be able to compensate for any misalignment of the SRM.

Here is the new plan and minimal things to do for the door opening tomorrow:

1. Function generator is driving OMC-L.
   1. The PZT mon channel is sent to the oscilloscope.
   2. To do: confirm again that the triangle wave I send in results in the expected triangle wave going to the OMC, using this mon channel.
2. The OMC REFL signal is being sent to the AP PD. See photo.
   1. Need to align into this PD, but this alignment can be done in air on the AP table.
3. Monitor the DCPD signals using the TPs from the sat box going to the oscilloscope.
   1. There may be further problems with the sat box, but for the initial alignment into the OMC only the REFL signal is necessary.
   2. Not minimally necessary, but the sat box needs a new case. It has a front, back, and bottom, but no main case, so the board is exposed.
4. I will move the OMMT-to-OMC steering mirrors while watching the scope for flashes in the REFL signal.

That is the first, minimal sequence of steps, which I plan to complete tomorrow. After aligned into the OMC, the alignment into the DCPDs shouldn't need modification. Barring work needed to align from OMC to DCPDs, I think most other work with the OMC can be done in-air.

I did the following:

• Noticed that the OMC rack's power has +-18V, but I had tested the HV driver with +-15V. Maybe fine, something to watch.
• Checked that nothing but the OMC driver board was in use on the OMC's Sorensen (the QPD whitening board in the OMC rack is not in use, and anyway is labeled +-15V), then turned down the rack voltage from 18 to 15V. Photos attached of AUX_OMC_S Sorensen bank.
• I hadn't used the alternative dither before. I started by driving the alternative dither with a 10Vpp sine wave at 1-10 Hz. I have both the DC and AC driver mons on a scope.
  • Initially, I only give it 10V at the HV. I don't see much, nor at 30V, while driving with 0-10V sine waves between 0.1-100Hz.
  • In my last log, I hadn't been using the alternative dither.
• Instead, I switch over to the main piezo drive, which is sent over DB9. Now I see the following on the AC/DC piezo mon channels:
  • Increasing the HV input (increasing in steps from 10-50V) yields 1V at the DC piezo mon for 50V at the HV input.
  • Driving under a few 100s of Hz results in no change to the AC dither mon. Driving <1Hz results in a small (~10% for a 10Vpp drive) at the HV. I didn't take a full transfer function, but it is the thing to do with cds.
  • Changing the drive amplitude changes the AC mon amplitude proportionally
  • At a few kHz, the 10Vpp drive saturates the AC mon.
  • Photos are in order:
    • 1Hz drive, visible on the DC mon channel in green
    • 1kHz drive 10Vpp, visible on the AC mon channel in violet
    • 1kHz drive 5Vpp
    • 5kHz drive 10Vpp, saturates the AC mon channel

At 11:13 am there was a ~2-3 second interruption of all power at the 40m.

I checked that nobody was in any of the lab areas at the time of the outage.

I walked along both arms of the 40m and looked for any indicator lights or unusual activity. I took photos of the power supplies that I encountered, attached. I tried to be somewhat complete, but didn't have a list of things in mind to check, so I may have missed something. 

I noticed an electrical buzzing that seemed to emanate from one of the AC adapters on the vacuum rack. I've attached a photo of which one, the buzzing changes when I touch the case of the adapter. I did not modify anything on the vacuum rack. There is also 

Most of the cds channels are still down. I am going through the wiki for procedures on what to log when the power goes off, and will follow the procedures here to get some useful channels.

I completed testing of the AI board mentioned above. In addition to the blown fuse, there were two problems:

• A was a large drop of solder splattered on some of the ch 1 ICs, which is why we couldn't maintain any voltage. I removed the solder.
• The +12V wire from the power board to the AI board was loose, so I removed and replaced that crimp connection

After this, I tested the TF of all channels. For the most part, I found the expected 3rd order ~7500Hz cheby with notches at ~16kHz and 32kHz. However, some of the channels had shallower or deeper notches. By ~32kHz, I was below the resolution on the spectrum analyzer. Perhaps I just have nonideal settings? I'll attach a few representative examples.

I reinstalled the chassis at 1X2, but haven't connected power.

I turned on AUX, and aligned the aux beam to be centered on the first optic the AS beam sees on the AP table. I then turned off the AUX laser.

I replaced the 2'' AUX-AS combining BS with a 2'' HR mirror for 1064. I aligned the AUX beam from the new HR mirror into the next iris, so AUX passes through irises both before and after the new optic. Now, AS does not go out to the AS PDs.

I mounted the old BS on the SP table in a random orientation.

I also dumped the beam transmitted through one of the AUX steering mirrors before the new HR mirror.

I replaced the 2'' AUX-AS combining BS with a freshly mounted 2'' HR mirror for 1064. The mirror is labelled 'Y1-2037-45-P', and had a comment on its case: 'V'. I aligned the AUX beam from the new HR mirror into the next iris, so AUX passes through irises both before and after the new optic. Now, AS does not go out to the AS PDs.

I mounted the old BS on the SP table in a random orientation.

I also dumped the beam transmitted through one of the AUX steering mirrors before the new HR mirror.

[gautam, aaron]

We did work in the OMC chamber today to get the OMC aligned. Aaron was in the clean suit while Gautam steered in-air optics. We modified the aux input steering optics and the final two OMC steering optics (between OMMT and OMC), but did not modify any of the AS path optics.

I had already aligned AUX approximately into the AS port from the AP table. With the OMC N door open, we aligned the aux beam first to OM6, then to OMPO, then OM5. OM5 was the last optic in the OMC chamber that we could align to.

From there, Gautam found the aux beam clipping on a few optics on its way to SR4 using the IR viewer. Once we were approximately hitting SR4, we got a return beam in the OMC chamber, which we were able to coalign with the input aux beam.

We had already done the alignment of SR5 into the OMC during the last vent, so we immediately had a refl off of the OMC, which we aligned onto a PD520 from the PSL table (larger aperture than the previous PD, which anyway needed a macroscopic adjustment to catch the refl beam).

Next, we removed the OMC cover, wrapped it in foil, and placed it in the makeshift clean room near the Y end. The screws remain in a foil bucket in the OMC chamber. With the cover off, Aaron moved the OMC input steering mirrors to align the beam in the OMC. We measured ~2.4mW in the OMC refl beam, which means about 240uW is transmitted into the OMC. Aaron thinks the beam overlaps itself after one round trip in the cavity, but that the entire plane may be too low in pitch, so more alignment may be needed here.

With the beam approximately aligned into the OMC, we energized the OMC-L piezo driver with 200V, and applied a ~0.03Hz triangle wave on the OMC diff input (pins 2-7). We monitor the REFL PD, piezo mon, function generator signal, and one of the trans PDs. We noticed that the PZT mon shows the driver saturating before the function generator reaches its full +-10V, which is something to investigate.

We saw what could have been regular dips in the REFL PD signal, but realized that with an unkown level of mode matching, it will be hard to tell whether the light becomes resonant with the DC signal. Gautam has suggested coaligning the aux and PSL beams, then observing the PDH signal from the PSL beam as the OMC sweeps through resonance, while turning aux back on anytime we try to make adjustments to the alignment of the OMC (so I can see the beam in the cavity).

I'll think through the plan in some more detail and we will try to have the OMC locked tomorrow.

gautam:

1. All references to SR4 etc actually refer to OM4 etc.
2. For this experiment, we are using the prompt reflection of the AUX beam from the HR surface of the SRM, so as to get maximum light into the cavity.
3. For 2.4 mW incident on OMC1 (actually we measured the REFL beam on the AS table), we expect ~24 uW inside the cavity, which isn't a lot but still was visible on the card.
4. After this work, I checked the IMC alignment - it was still easily able to lock to a TEM00 mode, but the transmission was ~half (i.e. ~600cts) of what I am used to it being in low power mode (~1300 cts). I didn't align the cavity to the input beam, as I think in this case, the right thing to do is to align the input beam to the IMC cavity axis.

I tested the OMC-L HV driver box again, and made the following observations:

• Drove the HV diff pins (2,7) with a 5V triangle wave
  • Observed that with a ~0.4V offset on the drive, the HV output (measured directly with a 10x probe) has a 0-(almost)200V triangle wave (for 200V HV in), saturating near 200V and near 0V somewhat before reaching the full range of the triangle
  • The HV mon gives the same answer as measuring the HV output directly, and is reduced 100x compared to the HV output.
  • At 1Hz and above, the rolloff of the low pass still attenuates the drive a bit, and we don't reach the full range.
• Drove the HV dither pins (1,6) with a 100mV to 10V triangle wave, around 15kHz
  • Even at 10V, the dithering is near the noise of the mon channel, so while I could see a slight peak changing on the FFT near the dither frequency, I couldn't directly observe this on a scope using the mon channel
  • However, measuring the HV directly I do see the dither applied on top of the HV signal. The amplitude of the dither is the same on the HV output as on the dither drive.

[gautam, aaron]

We searched for blips while nominally scanning the OMC length.

We sent a 0.1Hz, 10Vpp triangle wave to the OMC piezo drive diff channels, so the piezo length is seeing a slow triangle wave from 0-200V.

Then, we applied a ~15kHz dither to the OMC length. This dither is added directly onto the HV signal, so the amplitude of the dither at the OMC is the same as the amplitude of the dither into the HV driver.

We monitored the OMC REFL signal (where we saw no blips yesterday) and mixed this with the 15kHz dither signal to get an error signal. Gautam found a pomona box with a low pass filter, so we also low passsed to get rid of some unidentified high frequency noise we were seeing (possibly a ground loop at the function generator? it was present with the box off, but gone with the AC line unplugged). [So we made our own lock-in amplifier.] Photo attached.

We tested the transfer function of the LP, and finding it at 100kHz rather than the advertised 10kHz, we opened the box, removed a resistor to change the 3dB back to 10kHz, and confirmed this by measuring the TF.

We didn't see flashes of error signal in the mixed reflection either, so we suspect that either the PZT is not actuating on the OMC or the alignment is bad. Based on what appears to be the shimmering of far-misaligned fringes on the AS camera, Aaron's suspicion from aligning the cavity with the card, and the lack of flashes, we suspect the alignment. To avoid being stymied by a malfunctioning PZT, we can scan the laser frequency next time rather than the PZT length.

I drew out some idea of how we might use a single OMC to clean both paths of the BHD after mixing, without being susceptible to polarization-dependent effects within the OMC. Basically, can we send the two legs of the BHD into the OMC counterpropagating. I've attached a diagram.

I think one issue would be scattered light, since any backscatter directly couples into the counterpropagating mode, and thus directly to the PD. However, unless the polarization of the scattered light rotates it would not scatter back to the IFO. And, since the LO and signal mix before the OMC, this scattered light would not directly add phase noise.

Maybe more problematic would be that if the rejection at the PBS (or the polarization rotation) isn't perfect, light from the LO directly couples into the dark port. Can we get away with a Faraday isolator before the OMC? 

Diagram attached.

Continuing this investigation of the IMC, today I am getting familiar with the PMC and FSS. I'd like to measure the frequency noise of the PSL referenced to the PMC.

I checked that the PSL shutter is off, so no light reaches the IMC.

I'm not really sure what I'm looking for on the FSS boxes. I found a few documents to guide:

• On the tabletop testing of FSS for LIGO
• 40m wiki

I ran the FSS autolock script from C1PSL_FSS, nothing obvious changes when I do so. The FSS error signal (which I think is PSL-FSS_MIXERM) is flatlined, and the RC-RF_PD has no LO (PSL-FSS_LOCALC is nan).

The circuit diagram for the PMC servo card is D980352. From this diagram, I see that I can send an excitation from the network analyzer to FP2TEST (9.09 kOhm input impedance) where it is added to the PMC error signal before going to the loop filters.

I hook up the following

• Agilent 4395A output to SR560 (300 Hz HP, gain of 1)
• SR560 to FP2TEST and to Agilent's channel R
• PMC error signal IF (mixer box mounted to rack, I noticed the IF BNC->SMA were a bit loose/stressed by a hanging LP RF filter) to SR560 (also 300 Hz HP, gain of 2)
• SR560 to Agilent channel A

I 'Enable' Test 2 on the PSL screen, so FP2TEST gets added to the error signal.

PDH signal

• TDS 3034B with four channels
  • 1. PMC servo box external drive (split off from the function generator)
  • 2. PMC servo box output monitor (mirrors the drive, shows when drive is saturating)
  • 3. IF signal (split off after the mixer)
  • 4. PMC Trans (long BNC from the PSL table)
• SRS DS345 function generator (into the PMC servo box' external drive)
  • 100 Hz signal (there's a 10 Hz pole on the PZT drive, so any faster than this and I can't see both sidebands without the HV output mon clipping)
  • 3.19 Vpp amplitude (smallest amplitude at 100 Hz such that both sidebands are well resolved)
  • 1.52 V offset (center the carrier's PDH error signal at pi/2 out of phase with the drive)

I was able to see the carrier and both sidebands.

I tried to grab this data from the scope via ethernet, but was unsuccessful (timeout errors, I'm using the scripts from scripts/tektronix/tek-dump, and the GPIB box that Kruthi had been using for the GigE cam; I also tried plugging in directly scope->ethernet. Never got anything but timeout errors, so maybe I'm not specifying the port correctly. Anyway the trace is frozen on the scope for later use, or I can easily repeat this now that I know how).

Spectrum

Next, I locked the PMC (Test1 is off, tune DC output adjust until I get some transmission, turn on the loop at Test1, increase the gain to before the loop goes unstable). I'm sending the following channels to SR560 (gain = 2, no filtering, high dynamic reserve, 50 Ohm outputs), and reading spectra from the Agilent 4395A:

• R-- PMC TRANS PD
• A-- PDH IF
• B-- PMC PZT HV MON

The HV mon was always saturating the preamp, so I disconnected it; I added a 50 Hz (6db) high pass to the Trans PD signal, since it has a DC component.

I got to take a look at the traces on the spectrum analyzer front panel, but too tired to do the GPIB for now. There are peaks, things look reasonable.

Grabbed the PMC data

I went to set up the spectrum analyzer measurements through GPIB, but inadvertently deleted the contents of ~/Agilent/netgpibdata/ (made a soft link in my folder, decided I wanted it gone but rm'ed instead of unlink). I copied what I think was in that folder back (from /opt/rtcds/caltech/c1/scripts/general/labutils/netgpibdata).

Again, the spectra are:

• R-- PMC TRANS PD into SR560 with G=2 DC coupled, no filtering
• A-- PDH IF into SR560 with G=2, DC coupled, no filtering
• B-- PMC PZT HV MON into SR560 with G=2, AC coupled, no filtering

I recorded the three spectra with the following parameters:

• Three separate spans:
  • 10 Hz to 150 kHz
  • 100 to 550 kHz
  • 500 kHz to 2.5 MHz
• bwSpanRatio = 0.1 %
• averages: 10
• number of points: 801
• spec type: noise (PSD units)

I then ran AGmeasure with the above parameters in the yaml, with the rest following the defaults in AgilentTemplate.yaml. I saved the data in /users/aaron/40m/data/PMC/190617/

Looks like the header contains all of the parameters, so I shouldn't have trouble distinguishing the spectra. I didn't get the instant plotting working, but the data seem to be there.

I'm still having trouble getting the data from the oscilloscope. I'm not sure why the tektronix scrips I've used before aren't working, I'm checking it now.

update: Grabbed the data, the issue was just using the wrong IP address. 

Milind pointed out that all boxes on the medm screens were white. I didn't have diagnostics from the medm screens, so I started following the troubleshooting steps on the restart procedures page.

It seemed like maybe a frontend problem. I tried telnet-ing into several of the fe, and wasn't able to access c1psl. The section on c1psl mentions that if this machine crashes, the screens will go white and the crate needs to be turned off and on. Millind did this.

Now, most of the status lights are restored (screenshot).

Milind: I did a burtrestore following this and locked the PMC following the steps described in this elog.