40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 235 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  11313   Tue May 19 17:53:38 2015 ranaUpdateModern ControlBrushing up on Wiener Filtering

Good to see that misofw.m is still alive and well. Todo:

  1. Apply weighting to the filter via time domain SOS prefiltering of the signals (see Jenne's code from the LLO Global FF paper)
  2. Consider using some of the MC SUSPOS signals. Its not strictly legal, but I wonder if its responsible for out noise below 1 Hz.
  3. Steve was in the midst of hooking up the Wilcoxones to get better subtraction at 5-15 Hz, but couldn't find cables. We need to hunt them down in W Bridge.
  4. Attach one of the medium or big Lings to the MC2 chamber platform and see if we can do this in hardware without driving the suspension. WE want to use a DAC channel (from where?) and pipe it to the Ling using a medium high current drive. Might start with the 50 Ohm output of the SR560 and later use a BUF634 ala Crackle coil driver.
  14603   Fri May 10 18:24:29 2019 gautamUpdateNoiseBudgetaligoNB

I pulled the aligoNB git repo to /ligo/GIT/aligoNB/aligoNB. There isn't a reqs.txt file in the repo so installing the dependencies on individual workstations to get this running is a bit of a pain. I found the easiest thing to do was to setup a virtual environment for the python3 stuff, this way we can run python2 for the cdsutils package (hopefully that gets updated soon). I'm setting up a C1 directory in there, plan is to budget some subsystems like Oplev, ALS for now, and develop the code for the eventual IFO locking. As a test, I ran the H1 noise budget (./aligonb H1), works, so looks like I got all the dependencies...

  15047   Mon Nov 25 22:10:26 2019 shrutiUpdateNoiseBudgetDiagnostics

This is to help troubleshoot the excess noise measured earlier.

The following channels were measured at GPS times 1258586880 s and 1258597457 s, corresponding to low and high Power Recycling Gain (PRG) respectively.

Excess noise was seen between 25-110 Hz in the high PRG case when compared to the low PRG case in the following channels:

 

C1:LSC-CARM-IN1_DQ (shown in Attachment 1 where the reference is low PRG)

C1:ALS-Y_ERR_MON_OUT_DQ

C1:ALS-BEAT{X,Y}_FINE_PHASE_OUT_DQ

C1:SUS-ETM{X,Y} _SENSOR_{LL,LR,UL,UR}

C1:ALS-TRX_OUT_DQ

 

Surprisingly, it was also seen to a smaller extent in (refer Attachment 3)

C1:SUS-ITMX_SENSOR_{LL,LR,UL,UR} 

 

A different type of noise spectrum, attributed to known electronic effects, was observed for

C1:SUS-ITMY_SENSOR_{LL,UL}    (refer Attachment 2)

 

These did not show any significant change in the noise spectrum:

C1:LSC-DARM-IN1_DQ (shown in Attachment 1 where the reference is low PRG)

C1:ALS-X_ERR_MON_OUT_DQ

C1:ALS-TRY_OUT_DQ

C1:SUS-ITMY_SENSOR_{LL,LR,UL,UR} 

C1:SUS-ITMY_SENSOR_{LR,UR}  (refer Attachment 2)

 

Broadband noise in:

C1:LSC-PO{X,Y}11_I_ERR_DQ

 

Attachment 1: LSC.pdf
LSC.pdf
Attachment 2: ITMY.pdf
ITMY.pdf
Attachment 3: ITMX_L.pdf
ITMX_L.pdf
  15300   Tue Apr 7 15:30:40 2020 JonSummaryNoiseBudget40m noise budget migrated to pygwinc

In the past year, pygwinc has expanded to support not just fundamental noise calculations (e.g., quantum, thermal) but also any number of user-defined noises. These custom noise definitions can do anything, from evaluating an empirical model (e.g., electronics, suspension) to loading real noise measurements (e.g., laser AM/PM noise). Here is an example of the framework applied to H1.

Starting with the BHD review-era noises, I have set up the 40m pygwinc fork with a working noise budget which we can easily expand. Specific actions:

  • Updated the 40m fork to the latest pygwinc version (while preserving the commit history).
  • Added a directory ./CIT40m containing the 40m-specific noise budget files (created by GV).
  • Added an ipython notebook CIT40m.ipynb at the root level showing how to generate a noise budget.
  • Integrated our DAC and seismic noise estimators into pygwinc.
  • Marked the old 40m NB repo as obsolete (last commit > 2 yrs ago). Many of these noise estimates are probably stale, but I will work with GV to identify which ones can be migrated.

I set up our fork in this way to keep the 40m separate from the main pygwinc code (i.e., not added to as a built-in IFO type). With the 40m code all contained within one root-level directory (with a 40m-specific name), we should now always be able to upgrade to the latest pygwinc without creating intractable merge conflicts.

  16152   Fri May 21 12:12:11 2021 PacoUpdateNoiseBudgetAUX PDH loop identification

[Anchal, Paco]

We went into 40m to identify where XARM PDH loop control elements are. We didn't touch anything, but this is to note we went in there twice at 10 AM and 11:10 AM.

  16975   Wed Jul 6 19:58:16 2022 PacoSummaryNoiseBudgetXARM noise budget

[Anchal, Paco, Rana]

We locked the XARM using POX11 and made a noise budget for the single arm displacement; see Attachment #1. The noise budget is rough in that we use simple calibrations to get it going; for example we calibrate the measured error point C1:LSC-XARM_IN1_DQ using the single cavity pole and some dc gain to match the UGF point. The control point C1:LSC-XARM_OUT_DQ is calibrated using the actuator gain measured recently by Yuta. We also overlay an estimate of the seismic motion using C1:PEM-SEIS_BS_X_OUT_DQ (calibrated using a few poles to account for stack and pendulum), and finally the laser frequency noise as proxied by the mode cleaner C1:IOO-MC_F_DQ.

A couple of points are taken with this noise budget, apart from it needing a better calibration;

  1. Overall the inferred residual displacement noise is high, even for our single arm cavity.
    1. By looking at the sim OLTF in foton, it seemed that the single arm cavity loop TF could easily become unstable due to some near-UGF-funkiness likely from FM3 (higher freq boost), so we disabled the automatic triggering on it; the arm stayed locked and we changed the error signal (light blue vs gold (REF1) trace)
  2. The arm cavity is potentially seeing too much noise from the IMC in the 1 to 30 Hz band in the form of laser frequency noise.
    1. Need IMC noise budget to properly debug.
  3. At high frequency (>UGF), there seem to be a bunch of "wiggles" which remain unidentified.
    1. We actually tried to investigate a bit into these features, thinking they might have something to do with misalignment, but we couldn't really find significant correlation.

RXA edit:

  1. we also noticed some weirdness in the calibration of MC_F v. Arm. We think MC_F should be in units of Hz, and Paco calculated the resulting motion as seen by the arm, but there was a factor of several between these two. Need to calibrate MC_F and check. In principle, MC_F will show up directly in ALS_BEATX (with the green PDH lock off), and I assume that one is accurately calibrated. Somehow we should get MC_F, XARM, and ALS_BEAT to all agree. JC is working on calibrating the Mini-Circuits frequency counter, so once that is done we will be in good shape.
  2. we may need to turn on some MC_L feedback for the IMC, so that the MC length follows the NPRO frequency below ~20 Hz.
  3. Need to estimate where the IMC WFS noise is in all of this. Does it limit the MC length stability in any frequency band? How do we determine this?
  4. Also, we want to redo this noise budget today, whilst using AS55 instead of POX. Please measure the Schnupp asymmetry by checking the optimum demod phase in AS55 for locking Xarm v Yarm.
Attachment 1: xarm_nb_2022_07.pdf
xarm_nb_2022_07.pdf
  5   Fri Oct 19 16:11:38 2007 pkpOtherOMCOMC PZT response
Sam and I locked the laser to the OMC cavity and looked at the error signal as a function of the voltage applied to the OMC PZT.
Here are two plots showing the response as a function of frequency from 1 kHz to 100 kHz and another high-res response in the region of 4.5 kHz to 10 kHz.
Attachment 1: fullspec.jpg
fullspec.jpg
Attachment 2: 4.5to10.jpg
4.5to10.jpg
Attachment 3: 4.5to10.pdf
4.5to10.pdf
Attachment 4: fullres.pdf
fullres.pdf
  6   Sat Oct 20 11:54:13 2007 waldmanOtherOMCOMC and OMC-SUS work
[Rich, Chub, Pinkesh, Chris, Sam]

Friday the 18th was a busy day in OMC land. Both DCPDs were mounted to the glass breadboard and the OMC-SUS structure was rebuilt to the point that an aluminum dummy mass is hanging, unbalanced. The OSEMs have not be put on the table cloth yet, but everything is hanging free. As for the DCPDs, if you recall one beam is 3mm off center from the DCPD tombstone. Fortunately, one DCPD is nearly 3mm offcenter from the case in the right direction, so the errors nearly cancel. The DCPD is too high, so the beam isn't quite centered, but they're close. We'll get photos of the beam positions in someday. Also, the DC gain between the two PDs is, at first glance, different by 15%. DCPD1, the one seen in transmission has 315 mV of signal while DCPD2 has 280 mV. Not sure why, could be because of beam alignment or tolerances in the Preamp or the angle incident on the diode or the QE of the diodes. The glass cans have *not* been removed.
  8   Mon Oct 22 19:27:14 2007 pkpOtherOMCPZT calibration/ transfer function.
We measured the PZT transfer function by comparing the PZT response of the circuit with the cavity in the loop, with that of the circuit without the cavity in the loop. Basically measure the transfer function of the whole loop with the laser/PZT and Op-amps in it. Then take another measurement of the transfer function of everything else besides the PZT and from both these functions, we can calculate the PZT response.

The calibration was done by using the error signal response to a triangular wave of volts applied to the PZT. A measurement of the slope of the error signal , which has three zero-crossings as the cavity sweeps through the sidebands, gives us the Volts/Hz response. In order to derive a frequency calibration of the x axis, we assume that the first zero crossing corresponds to the first side band (-29.5 MHz) and the third one corresponds with the other sideband (+29.5 MHz). And then by using the fact that we know the response of the cavity to a constant frequency shift, we can use the Volts/Hz measurement to calculate the Volts/nm calibration. The slope that was calculated was 3.2e-6 V/Hz and using the fact that the cavity is 1 m in length and the frequency is 1064 nm, we get a calibration of 0.9022 V/nm.

Attachment 1: calib.pdf
calib.pdf
Attachment 2: calibpzt2.pdf
calibpzt2.pdf
Attachment 3: all2.pdf
all2.pdf
Attachment 4: noPZT2.pdf
noPZT2.pdf
  9   Tue Oct 23 09:01:00 2007 ranaOtherOMCPZT calibration/ transfer function.
Are you sure that the error signal sweep is not saturated on the top ends? This is usually the downfall
of this calibration method.
  14   Thu Oct 25 17:52:45 2007 waldmanOtherOMCOMCs with QPDs
[Rich, Chub, Pinkesh, Sam]

Yesterday we got the QPD, OTAS, and PZT cabling harness integrated with the OMC. We found a few things out, not all of them good. The QPDs went on no problem and could be fairly well aligned by hand. We "aligned" them by looking at all four channels of the QPD on the scope and seeing that there is signal. Since the beam is omega = 0.5 mm, this is a reasonable adjustment. We then connected the OTAS connector to the OTAS and found that the heater on the OTAS was bonded on about 30 degrees rotated from its intended position. This rotated the connector into the beam and caused a visible amount of scattering. This wasn't really a disaster until I removed the connector from the heater and broke the heater off of the aluminum parts of the OTAS. Two steps backwards, one step forward. After the OMC, OMC-SUS integration test we will re-bond the heater to the aluminum using VacSeal. In the meantime, the OMC has been moved to Bridge 056 for integration with the OMC-SUS. More on that as we make progress.
  16   Thu Oct 25 23:35:36 2007 waldmanOtherOMCHang the OMC!
[Pinkesh, Sam]

We tried, convicted and hung the OMC today. The OMC was found guilty of being overweight, and unsymmetrically balanced. The unsymmetry was kind of expected and was corrected with a hefty stack of counterweights positioned over the counterweighting holes. The stacks will be measured at some future date and correctly sized objects machined. The overweightness showed up when the level hanging breadboard was about 5 mm low. This showed up in the board height above the table as well as the OSEM flag positions within their holes. The problem was remedied with a liposuction of the intermediate mass. We removed both small vertical cylinder weights that Chris added, and then we removed the heavy steel transverse weight that can be used to adjust the tip around the long axis (I forgot what its called).

The top of the breadboard ended up about 154 mm off the table. The breadboard is 39 mm thick, and the optics are centered (30 - 12.7) = 17.3 mm below the surface for a as hanging beams height of 154 -39 - 17.3 = 97.7 mm or about an 0.150 inches lower than we were aiming for. Can I get a refund?

We screwed up in multiple ways:
  • The slotted disks that capture the wires do not have the alignment bore used to center the wire in the hole
  • We didn't correctly route the far field QPD cable so it runs funny
  • We didn't have a tool which could be used to get two of the DCPD preamp box mounting screws (which are M3's chub!)
  • We don't have the cable clamps to tie off the electrical cables to the intermediate mass
  • We don't have any of the cabling from the OMC-SUS top to the rack so we can't test anything
  • We haven't uploaded pretty pictures for all to see

We left the OMC partially suspended by the OMC-SUS and partly resting on the installation lab jacks which are currently acting as EQ stops. After we fix the cabling we will more permanently hang it. PS, It looks like the REFL beam extraction will be tricky so we need to get on that....
Attachment 1: IMG_1483.jpg
IMG_1483.jpg
Attachment 2: IMG_1481.jpg
IMG_1481.jpg
  19   Fri Oct 26 17:34:43 2007 waldmanOtherOMCOMC + earthquake stops

[Chub, chris, Pinkesh, Sam]

Last night we hugn the OMC for the first time and came up with a bunch of pictures and some problems. Today we address some of the problems and, of course, make new problems. We replaced the flat slotted disks with the fitted slotted disks that are made to fit into the counterbore of the breadboard. This changed the balance slightly and required a more symmetric distribution of mass. It probably did not change the total mass very much. We did find that the amount of cable hanging down strongly affected the breadboard balance and may also have contributed to the changing balance.

We also attached earthquake stops and ran into a few problems:

  • The bottom plate of the EQ stops is too thick so that it bumps into the tombstones
  • The vertical member on the "waist" EQ stops is too close to the breadboard, possibly interfering with the REFL beam
  • The "waist" EQ stops are made from a thin plate that doesn't have enough thickness to mount helicoils in
  • Helicoil weren't loaded in the correct bottom EQ stops
  • The DCPD cable loops over the end EQ stop looking nasty but not actually making contact

However, with a little bit of jimmying, the EQ stops are arrayed at all points within a few mm of the breadboard. Meanwhile, Chub has cabled up all the satellite modules and DCPD modules and Pinkesh is working on getting data into the digital system so we can start playing games. Tonight, I intend to mount a laser in Rana's lab and fiber couple a beam into the 056 room so we can start testing the suspended OMC.
  20   Fri Oct 26 21:48:40 2007 waldmanConfigurationOMCFiber to 056
I set up a 700 mW NPRO in Rana's lab and launched it onto a 50m fiber. I got a few mW onto the fiber, enough to see with a card before disabling the laser. The fiber now runs along the hallway and terminates in rm 056. Its taped down everywhere someone might trip on it, but don't go out of your way to trip on it or pull on it because you are curious. Tomorrow I will co-run a BNC cable and attenuate the NPRO output so it can only send a few mW and so be laser safe. Then we can try to develop a procedure to align the beam to a suspended OMC and lock our suspended cavity goodness.

Notes to self: items needed from the 40m
  • ND10 and ND20 neutral density filter
  • EOM and mount set for 4 inch beam height
  • Post for fiber launch to get to 4 inch
  • Mode matching lens at 4in
  • 3x steering mirror at 4in
  • RF photodiode at 4in
  • Post for camera to 4in
  • Light sheild for camera
  • Long BNC cable
Some of these exist at 056 already
  21   Sat Oct 27 19:00:44 2007 waldmanConfigurationOMCHanging, locked OMC with REFL extracted.
I got the OMC locked to the fiber output today. It was much more difficult than I expected and I spent about 30 minutes or so flailing before stopping to think. The basic problem is that the initial alignment is a search in 4-dimensional space and there is naturally only one signal, the reflected DC level, to guide the alignment. I tried to eyeball the alignment using the IR card and "centering" the beams on mirrors, but I couldn't get close enough to get any light through. I also tried to put a camera on the high reflector transmission, but with 1.5 mW incident on the cavity, there is only 1.5 microwatts leaking through in the best case scenario, and much, much less during alignment.

I resolved the problem by placing a high reflector on a 3.5 inch tall fixed mount and picking off the OMC transmitted beam before it reaches the DC diodes. I took the pickoff beam to a camera. The alignment still sucked because even though the beam cleanly transmitted the output coupler, it wasn't anywhere close to getting through the OTAS. To resolve this problem, I visually looked through the back of M2 at M1 and used the IR card to align the beam to the centers of each mirror. That was close enough to get me fringes and align the camera. With the camera aligned, the rest was very easy.

I restored the PDH setup we know and love from the construction days and locked the laser to the OMC with no difficulty. The laser is in Rana's lab so I send the +/- 10V control signal from the SR560 down a cable to 058E where it goes into the Battery+resistor box, the Throlabs HV amplifier, and finally the FAST channel of the NPRO. BTW, a simple experiment sows that about 35 +/- 3 V are required to get an FSR out of the NPRO, hence the Thorlabs HV. The EOM, mixer, splitter, etc is on the edge of the table.

With this specific OMC alignment, ie. the particular sitting on EQ stops, it looks like all of the ghost beams have a good chance of coming clear. I can fit a 2 inch optic in a fixed mount in between the end of the breadboard and the leg of the support structure. A picture might or might not be included someday. One of the ghost beams craters directly into the EQ stop vertical member. The other ghost barely misses M2 on its way down the length of the board. In its current configuration, the many REFL beam misses the leg by about 1.5 inches.
  25   Mon Oct 29 11:07:22 2007 waldmanSoftware InstallationOMCSoftware install on OMS
[Alex, Sam]

We spent a little time this morning working on OMS and getting things restarted. A few changes were made. 1) We put openmotif on OMS so that the burtrb doesn't throw that crappy libXm any more. 2) We upgraded OMS to a 32 kHz sampling rate from 2 kHz. All the filters will have to be changed. We also added a PDH filter path to maybe feedback PDH signals cuz that will be cool. Maybe someday I will write up the very cool channel adding procedure.
  26   Mon Oct 29 12:20:15 2007 waldmanConfigurationOMCChanged OMS filters
I changed the OMS configuration so that some of the OMC-SUS LED channels go to a breakout box so that we can input the PDH error signal. After lunch, we will try to lock the cavity with a PDH error signal and digital filters. Then its on to dither locked stuff. Note that this LED business will have to be changed back some day. For now, it should be extremely visible because there are dangling cables and a hack job interface lying around.
  27   Mon Oct 29 23:10:05 2007 waldmanConfigurationOMCLost in DAQspace
[Pinkesh, Sam]

In setting up a Digital based control of the hanging OMC, we naively connect the Anti-Imaging filter output to an Anti-Aliasing input. This led to no end of hell. For one thing, we found the 10 kHz 3rd order butterworth at 10 kHz, where it should be based on the install hardware. One wonders in passing whether we want a 10 kHz butter instead of a 15 kHz something else, but I leave that for a later discussion. Much more bothersome is a linear phase shift between output and input that looks like ~180 microseconds. It screams "What the hell am I!?" and none of us could scream back at it with an answer. I believe this will require the Wilson House Ghost Busters to fully remedy on the morrow.
Attachment 1: SS.pdf
SS.pdf
Attachment 2: SS.gif
SS.gif
  37   Wed Oct 31 09:45:28 2007 waldmanOtherOMCResolution to DAQland saga
[Jay, Sam]

We did a rough accounting for the linear delay this morning and it comes out more or less correct. The 10 kHz 3rd order butterworth AA/AI filter gives ~90 degrees of phase at 6 kHz, or 42 microseconds. Taken together, the two AA and AI filters are worth 80 microseconds. The 1.5 sample digital delay is worth 1.5/32768 = 45 microseconds. The remaining 160 - 125 = 35 microseconds is most likely taken up by the 64 kHz to 32 kHz decimation routine, assuming this isn't accounted for already in the 1.5 sample digital delay.

It remains to be seen whether this phase delay is good enough to lock the laser to the OMC cavity
  42   Wed Oct 31 23:55:17 2007 waldmanOtherOMCQPD tests
The 4 QPDs for the OMC have been installed in the 056 at the test setup. All 4 QPDs work and have medm screens located under C2TPT. The breadboard mounted QPDs are not very well centered so their signal is somewhat crappy. But all 4 QPDs definitely see plenty of light. I include light and dark spectra below. QPDs 1-2 are table-mounted and QPD 2 is labeled with a bit of blue tape. QDPs 3-4 are mounted on the OMC. QPD3 is the near field detector and QPD4 is the far field. In other words, QPD3 is closest to the input coupler and QPD4 is farthest.

Included below are some spectra of the QPDs with and without light. For QPDs 1 & 2, the light source is just room lights, while 3&4 have the laser in the nominal OMC configuration with a few mWs as source. The noise at 100 Hz is about 100 microvolts / rtHz. If I recall correctly, the QPDs have 5 kOhm transimpedance (right Rich?) so this is 20 nanoamps / rtHz of current noise at the QPD.
Attachment 1: QPD_SignalSpectrum.pdf
QPD_SignalSpectrum.pdf
Attachment 2: QPD_SignalSpectrum.gif
QPD_SignalSpectrum.gif
  43   Thu Nov 1 01:28:04 2007 waldmanOtherOMCFirst digital lock of OMC
[Pinkesh, Sam]

We locked a fiber based NPRO to the suspended OMC tonight using the TPT digital control system. To control the laser frequency, we took the PZT AI output and ran it on a BNC cable down the hallway to the Thorlabs HV box. The Thorlabs is a singled ended unit so we connected the AI positive terminal only and grounded the BNC to the AI shield. We could get a -6 to 1.5 V throw in this method which fed into the 10 k resisotr + 9 V battery at the input of the HV box. The HV out ran to the NPRO PZT fast input.

We derived our error signal from a PDA255 in reflection with a 29.5 MHz PDH lock. The signal feeds into one of the unused Tip/Tilt AA channels and is passed to the PZT LSC drive through the TPT_PDH1 filter bank. In the PZT_LSC filter we put a single pole at 1 Hz which, together with the phase we mentioned the other night (180 degrees at 3 kHz) should allow a 1 kHz-ish loop. In practice, as shown below, we got a 650 Hz UGF with 45 degrees of phase margin and about 6 dB of gain margin.

The Lower figure shows the error point spectrum with 3 settings. REF0 in blue shows lots of gain peaking at 1.5 kHz-ish, just where its expected - the gain was -40. The REF1 has gain of -20 and shows no gain peaking. The current trace in red shows some gain peaking cuz the alignment is better but it also has included a 1^2:20^2 boost which totally crushes the low frequency noise. We should do a better loop sweep after getting the alignment right so we can see how much boost it will really take.

Just for fun, we are leaving it locked overnight and recording the PZT_LSC data for posterity.
Attachment 1: 071101_PZT_firstLoopSweep.pdf
071101_PZT_firstLoopSweep.pdf
Attachment 2: 071101_PZT_firstLoopSweep.gif
071101_PZT_firstLoopSweep.gif
Attachment 3: 071101_OMC_FirstLock_spectra.pdf
071101_OMC_FirstLock_spectra.pdf
Attachment 4: 071101_OMC_FirstLock_spectra.gif
071101_OMC_FirstLock_spectra.gif
  58   Fri Nov 2 12:18:47 2007 waldmanSummaryOMCLocked OMC with DCPD
[Rich, Sam]

We locked the OMC and look at the signal on the DCPD. Plots included.
Attachment 1: 071102_OMC_LockedDCPD.gif
071102_OMC_LockedDCPD.gif
Attachment 2: 071102_OMC_LockedDCPD.pdf
071102_OMC_LockedDCPD.pdf
  59   Sat Nov 3 16:20:43 2007 waldmanSummaryOMCA good day's work

I followed up yesterday's test of the PZT with a whole mess of characterizations of the PZT control and finished the day by locking the OMC with a PZT dither lock and a 600 Hz loop. I haven't analyzed any of the data yet, so its not calibrated in physical units and etc. etc. etc. Since a lot of the sweeps below are of a "drive the PZT, look at the PDH signal" nature, a proper analysis will require taking out the loop and calibrating the signals, which alas, I haven't done. Nonetheless, I include all the plots because they are pretty. The files included below are:

  • DitherLock_sweep: Sweep of the IN2/IN1 for the dither lock error point showing 600 Hz UGF
  • HiResPZTDither_sweep: Sweep of the PZT dither input compared to the PDH error signal. I restarted the front end before the sweep was finished accounting for the blip.
  • HiResPZTDither_sweep2: Finish of the PZT dither sweep


More will be posted later.
Attachment 1: 071103_DitherLock_sweep.png
071103_DitherLock_sweep.png
Attachment 2: 071103_DitherLock_sweep.pdf
071103_DitherLock_sweep.pdf
Attachment 3: 071103_HiResPZTDither_sweep.png
071103_HiResPZTDither_sweep.png
Attachment 4: 071103_HiResPZTDither_sweep.pdf
071103_HiResPZTDither_sweep.pdf
Attachment 5: 071103_HiResPZTDither_sweep2.png
071103_HiResPZTDither_sweep2.png
Attachment 6: 071103_HiResPZTDither_sweep2.pdf
071103_HiResPZTDither_sweep2.pdf
  60   Sun Nov 4 23:22:50 2007 waldmanUpdateOMCOMC PZT and driver response functions
I wrote a big long elog and then my browser hung up, so you get a less detailed entry. I used Pinkesh's calibration of the PZT (0.9 V/nm) to calibrate the PDH error signal, then took the following data on the PZT and PZT driver response functions.:

  • FIgure 1: PZT dither path. Most of the features in this plot are understood: There is a 2kHz high pass filter in the PZT drive which is otherwise flat. The resonance features above 5 kHz are believed to be the tombstones. I don't understand the extra motion from 1-2 kHz.
  • Figure 2: PZT dither path zoom in. Since I want to dither the PZT to get an error signal, it helps to know where to dither. The ADC Anti-aliasing filter is a 3rd order butterworth at 10 kHz, so I looked for nice flat places below 10 KHz and settled on 8 kHz as relatively harmless.
  • Figure 3: PZT LSC path. This path has got a 1^2:10^2 de-whitening stage in the hardware which hasn't been digitally compensated for. You can see its effect between 10 and 40 Hz. The LSC path also has a 160 Hz low path which is visible causing a 1/f between 200 and 500 Hz. I have no idea what the 1 kHz resonant feature is, though I am inclined to point to the PDH loop since that is pretty close to the UGF and there is much gain peaking at that frequency.
Attachment 1: 071103DitherShape.png
071103DitherShape.png
Attachment 2: 071103DitherZoom.png
071103DitherZoom.png
Attachment 3: 071103LSCShape.png
071103LSCShape.png
Attachment 4: 071103DitherShape.pdf
071103DitherShape.pdf
Attachment 5: 071103DitherZoom.pdf
071103DitherZoom.pdf
Attachment 6: 071103LSCShape.pdf
071103LSCShape.pdf
Attachment 7: 071103LoopShape.pdf
071103LoopShape.pdf
  63   Mon Nov 5 14:44:39 2007 waldmanUpdateOMCPZT response functions and De-whitening
The PZT has two control paths: a DC coupled path with gain of 20, range of 0 to 300 V, and a pair of 1:10 whitening filters, and an AC path capacitively coupled to the PZT via a 0.1 uF cap through a 2nd order, 2 kHz high pass filter. There are two monitors for the PZT, a DC monitor which sniffs the DC directly with a gain of 0.02 and one which sniffs the dither input with a gain of 10.

There are two plots included below. The first measures the transfer function of the AC monitor / AC drive. It shows the expected 2 kHz 2d order filter and an AC gain of 100 dB, which seems a bit high but may be because of a filter I am forgetting. The high frequency rolloff is the AA and AI filters kicking in which are 3rd order butters at 10 kHz.

The second plot is the DC path. The two traces show the transfer function of DC monitor / DC drive with and with an Anti-dewhitening filter engaged in the DC drive. I fit the antidewhite using a least squares routine in matlab constrained to match 2 poles, 2 zeros, and a delay to the measured complex filter response. The resulting filter is (1.21, 0.72) : (12.61, 8.67) and the delay was f_pi = 912 Hz. The delay is a bit lower than expected for the f_pi = 3 kHz delay of the AA, AI, decimate combination, but not totally unreasonable. Without the delay, the filter is (1.3, 0.7) : (8.2, 13.2) - basically the same - so I use the results of the fit with delay. As you can see, the response of the combined digital AntiDW, analog DW path is flat to +/- 0.3 dB and +/- 3 degrees of phase.

Note the -44 dB of DC mon / DC drive is because the DC mon is calibrated in PZT Volts so the TF is PZT Volts / DAC cts. To calculate this value: there are (20 DAC V / 65536 DAC cts)* ( 20 PZT V / 1 DAC V) = -44.2 dB. Perfect!

I measured the high frequency response of the loop DC monitor / DC drive to be flat.
Attachment 1: 07110_DithertoVmonAC_sweep2-0.png
07110_DithertoVmonAC_sweep2-0.png
Attachment 2: 071105_LSCtoVmonDC_sweep4-0.png
071105_LSCtoVmonDC_sweep4-0.png
Attachment 3: 07110_DithertoVmonAC_sweep2.pdf
07110_DithertoVmonAC_sweep2.pdf 07110_DithertoVmonAC_sweep2.pdf
Attachment 4: 071105_LSCtoVmonDC_sweep4.pdf
071105_LSCtoVmonDC_sweep4.pdf 071105_LSCtoVmonDC_sweep4.pdf
  79   Wed Nov 7 14:01:31 2007 waldmanOmnistructureOMCFrequency and Intensity noise
One of the biggest problems I had using the PZT to lock was excessive noise. I did a little noise hunting and found that the problem was the cable running from the rack to the laser fast input. As a reminder, the laser has a 4 MHz / volt fast input. We require about 300 MHz to go one FSR, so there is a Thorlabs HV box between at the NPRO fast input which takes 0-10 V -> 0-150 V. The 150 V HV range is worth about 600 MHz of NPRO frequency.

OLD SETUP: Single side of DAC differential (10 Vpp) -> 9V in series with 10 kOhm -> 10 kOhm input impedance of Thorlabs HV -> NPRO

We used the single side of the DAC differential because we didn't have a differential receiver. This turned out to be a bad idea because the cable picks up every 60 Hz harmonic known to man kind.

NEW SETUP: Digital conditioning -> DAC differential (digitally limited to 0 - 1 V) -> SR560 in A-B mode gain 10 (0 - 10 V output)-> Thorlabs HV -> NPRO.

This has almost no 60 Hz noise and works much, much better. Moral of the story, ALWAYS USE DIFFERENTIAL SIGNALS DIFFERENTIALLY !

Note that I may be saturating the SR560 with 10 V output, Its spec'd for 10 Vpp output with 1 VDC max input. I don't know whether or not it can push 10 V out....
  82   Thu Nov 8 00:55:44 2007 pkpUpdateOMCSuspension tests
[Sam , Pinkesh]

We tried to measure the transfer functions of the 6 degrees of freedom in the OMS SUS. To our chagrin, we found that it was very hard to get the OSEMs to center and get a mean value of around 6000 counts. Somehow the left and top OSEMs were coupled and we tried to see if any of the OSEMs/suspension parts were touching each other. But there is still a significant coupling between the various OSEMs. In theory, the only OSEMS that are supposed to couple are [SIDE] , [LEFT, RIGHT] , [TOP1, TOP2 , TOP3] , since the motion along these 3 sets is orthogonal to the other sets. Thus an excitation along any one OSEM in a set should only couple with another OSEM in the same same set and not with the others. The graphs below were obtained by driving all the OSEMS one by one at 7 Hz and at 500 counts ( I still have to figure out how much that is in units of length). These graphs show that there is some sort of contact somewhere. I cant locate any physical contact at this point, although TOP2 is suspicious and we moved it a bit, but it seems to be hanging free now. This can also be caused by the stiff wire with the peek on it. This wire is very stiff and it can transmit motion from one degree of freedom to another quite easily. I also have a graph showing the transfer function of the longitudnal degree of freedom. I decided to do this first because it was simple and I had to only deal with SIDE, which seems to be decoupled from the other DOFs. This graph is similar to one Norna has for the longitudnal DOF transfer function, with the addition of a peak around 1.8 Hz. This I reckon could very be due to the wire, although it is hard to claim for certain. I am going to stop the measurement at this time and start a fresh high resolution spectrum and leave it running over night.

There is an extra peak in the high res spectrum that is disturbing.
Attachment 1: shakeleft.pdf
shakeleft.pdf
Attachment 2: shakeright.pdf
shakeright.pdf
Attachment 3: shakeside.pdf
shakeside.pdf
Attachment 4: shaketop1.pdf
shaketop1.pdf
Attachment 5: shaketop2.pdf
shaketop2.pdf
Attachment 6: shaketop3.pdf
shaketop3.pdf
Attachment 7: LongTransfer.pdf
LongTransfer.pdf LongTransfer.pdf LongTransfer.pdf
Attachment 8: Shakeleft7Nov2007_2.pdf
Shakeleft7Nov2007_2.pdf
Attachment 9: Shakeleft7Nov2007_2.png
Shakeleft7Nov2007_2.png
  86   Fri Nov 9 00:01:24 2007 waldmanOmnistructureOMCOMC mechanical resonances (Tap tap tappy tap)
[Pinkesh, Aidan, Sam]

We did a tap-tap-tappy-tap test of the OMC to try to find its resonances. We looked at some combination of the PDH error signal and the DCPD signal in a couple of different noise configurations. The data included below shows tapping of the major tombstone objects as well the breadboard. I don't see any strong evidence of resonances below the very sharp resonance at 1300 Hz (which I interpret as the diving board mode of the breadboard). If I get free, I 'll post some plots of the different breadboard resonances you can excite by tapping in different places.

(The "normalized" tapping response is abs(tap - reference)./reference.)
Attachment 1: Fig1.png
Fig1.png
Attachment 2: Fig2.png
Fig2.png
Attachment 3: Fig4.png
Fig4.png
Attachment 4: Fig2.pdf
Fig2.pdf
Attachment 5: Fig1.pdf
Fig1.pdf
Attachment 6: Fig4.pdf
Fig4.pdf
Attachment 7: ResonanceData.zip
  87   Fri Nov 9 00:23:12 2007 pkpUpdateOMCX and Z resonances
I got a couple of resonance plots going for now. I am still having trouble getting the Y measurement going for some reason. I will investigate that tommorow. But for tonight and tommorow morning, here is some food for thought. I have attached the X and Z transfer functions below. I compared them to Norna's plots - so just writing out what I was thinking -

Keep in mind that these arent high res scans and have been inconviniently stopped at 0.5 Hz Frown.

Z case --

I see two small resonances and two large ones - the large ones are at 5.5 Hz and 0.55 Hz and the small ones at 9 Hz and 2 Hz respectively. In Norna's resonances, these features arent present. Secondly, the two large peaks in Norna's measurement are at 4.5 Hz and just above 1 Hz. Which was kind of expected, since we shortened the wires a bit, so one of the resonances moved up and I suppose that the other one moved down for the same reason.

X case --

Only one broad peak at about 3 Hz is seen here, whereas in Norna's measurement, there were two large peaks and one dip at 0.75 Hz and 2.5 Hz. I suspect that the lower peak has shifted lower than what I scanned to here and a high res scan going upto 0.2 Hz is taking place overnight. So we will have to wait and watch.

Pitch Roll and Yaw can wait for the morning.
Attachment 1: Xtransferfunc.pdf
Xtransferfunc.pdf Xtransferfunc.pdf Xtransferfunc.pdf
Attachment 2: Ztransferfunc.pdf
Ztransferfunc.pdf Ztransferfunc.pdf Ztransferfunc.pdf
  93   Mon Nov 12 10:53:58 2007 pkpUpdateOMCVertical Transfer functions
[Norna Sam Pinkesh]

These plots were created by injected white noise into the OSEMs and reading out the response of the shadow sensors ( taking the power spectrum). We suspect that some of the additional structure is due to the wires.
Attachment 1: VerticalTrans.pdf
VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf
  99   Wed Nov 14 07:48:38 2007 nornaOmnistructureOMCOMC Cable dressing
[Snipped from an email]

1) Last Friday Pinkesh and I set the OMC up with only the top three OSEMs and took a vertical transfer function. We had removed the other OSEMs due to difficulty of aligning all OSEMs with the weight of the bench etc bringing the top mass lower than the tablecloth can accommodate. See attached TF.Clearly there are extra peaks (we only expect two with a zero in between) and my belief is that at least some of them are coupling of other degrees of freedom caused by the electrical wiring. Pinkesh and I also noticed the difficulty of maintaining alignment if cables got touched and moved around. So.....

2) Yesterday Dennis and I took a look at how much moving a cable bundle around (with the peak shielding) changed the DC alignment. In a not too precise experiment ( using HeNe laser reflecting off the bench onto a surface ~ 1 metre away) we saw that we could reposition the beam one or two mm in yaw and pitch. This corresponds to ~ one or two mrad which is ~ the range of the OSEM DC alignment. We discussed possibility of removing the cabling from the middle mass, removing the peak and taking it from the bench directly to the structure above. I asked Chub if he could make an equivalent bundle of wires as those from the two preamps to see what happens if we repeat the "moving bundle" experiment. So...

3) Today Chub removed the cabling going to the preamps and we replaced it with a mock up of wire bundle going directly from the preamps to the structure above. See attached picture. The wires are only attached to the preamp boxes weighted down with masses but the bundle is clamped at the top. We repeated the "wiggle the bundle" test and couldnt see any apparent movement ( so maybe it is at most sub-mm). The cable bundle feels softer.

The next thing Chub did was to remove the second bundle ( from photodiodes, heater, pzt) from its attachment to the middle mass and strip off the peek. It is now also going to the top of the structure directly. The whole suspension now appears freer. We discussed with Dennis the "dressing " of the wires. There are some minor difficulties about how to take wires from the bright side to the dark side, but in general it looks like that the wires forming the second "bundle" could be brought to the "terminal block" mounted on the dark side and from there looped up to the top of the structure. We would have to try all this of course to see the wiring doesnt get in the way of other things (e.g. the L and R OSEMs). However this might be the way forward. So...

4) Tomorrow Pinkesh and I will check the alignment and then repeat the vertical transfer function measurement with the two bundles as they are going from bench to top of structure. We might even do a horizontal one if the middle mass is now within range of the tablecloth.
We can then remove preamp cables completely and lay the second bundle of cables on the optical bench and repeat the TFs.

The next thing will be to weigh the bench plus cables. This will allow us to
a) work out what counterbalance weights are needed - and then get them manufactured
b) firm up on how to handle the extra mass in terms of getting the masses at the correct height.

And in parallel Chub will work on the revised layout of cabling.

Looking a little further ahead we can also get some stiffness measurements made on the revised bundle design ( using Bob's method which Alejandro also used) and fold into Dennis's model to get some sanity check the isolation.

I think that's it for now. Comments etc are of course welcome.

Norna
Attachment 1: OMC-11-13-07_011.jpg
OMC-11-13-07_011.jpg
Attachment 2: VerticalTrans.pdf
VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf VerticalTrans.pdf
  102   Wed Nov 14 16:54:54 2007 pkpUpdateOMCMuch better looking vertical transfer functions
[Norna Pinkesh]

So after Chub did his wonderful mini-surgery and removed the peek from the cables and after Norna and I aligned the whole apparatus, the following are the peaks that we see.
It almost exactly matches Norna's simulations and some of the extra peaks are possibly due to us exciting the Roll/longitudnal/yaw and pitch motions. The roll resonance is esp prominent.

We also took another plot with one of the wires removed and will wait on Chub before we remove another wire.
Attachment 1: VerticalTransPreampwireremovedNov142007.pdf
VerticalTransPreampwireremovedNov142007.pdf VerticalTransPreampwireremovedNov142007.pdf VerticalTransPreampwireremovedNov142007.pdf VerticalTransPreampwireremovedNov142007.pdf
Attachment 2: VerticalTranswiresclampedNov142007.pdf
VerticalTranswiresclampedNov142007.pdf VerticalTranswiresclampedNov142007.pdf VerticalTranswiresclampedNov142007.pdf VerticalTranswiresclampedNov142007.pdf
  105   Thu Nov 15 17:09:37 2007 pkpUpdateOMCVertical Transfer functions with no cables attached.
[Norna Pinkesh]

The cables connecting all the electronics ( DCPDs, QPDs etc) have been removed to test for the vertical transfer function. Now the cables are sitting on the OMC bench and it was realigned.
Attachment 1: VerticaltransferfuncnocablesattachedNov152007.pdf
VerticaltransferfuncnocablesattachedNov152007.pdf VerticaltransferfuncnocablesattachedNov152007.pdf VerticaltransferfuncnocablesattachedNov152007.pdf VerticaltransferfuncnocablesattachedNov152007.pdf
  179   Fri Dec 7 11:33:24 2007 waldmanOmnistructureOMCPZT wiring
The 2 pin LEMO connector has got an unmarked pin and a pin marked by a white half-circle.
The unmarked pin is connected to the side of the PZT attached to the mirror.
The marked pin is connected to the side of the PZT attached to the tombstone.
  206   Thu Dec 20 19:05:34 2007 waldmanHowToOMCHOWTO build front ends
For instance, to build the TPT front end code.

  • Save your file /cvs/cds/advLigo/src/epics/simLink/tpt.mdl
  • go to /cvs/cds/advLIGO on the TPT machine
  • do make clean-tpt tpt install-tpt
  • do rm /cvs/cds/caltech/chans/daq/C2TPT.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing.
  • do make install-daq-tpt
  • run starttpt to restart the tpt computer.

Enjoy.
  207   Thu Dec 20 19:10:03 2007 waldmanUpdateOMCStressful reattachment of heater
Photos may follow eventually, but for now here's the rundown. I scraped the heater clean of the thermal epoxy using a clean razor blade. Then I stuffed a small piece of lint free cloth in the OTAS bore and wrapped the OMC in tin foil. With a vacuum sucking directly from the face of the OTAS, I gently scraped the glue off the OTAS aluminum. I wiped both the OTAS and the heater down with an isoproponal soaked lint-free cloth. I put a thin sheen of VacSeal on the face of the heater, wiping off the excess from the edges with a cloth. Then I clamped the heater to the OTAS using 2" c-clamps from the tombstone back to the heater front, making sure the alignment of the OTAS was correct (connector on the absolute bottom, concentric with the OTAS outer diameter). I added a second clamp, then beaded the outside of the joint with a little bit extra VacSeal, just for kicks. I'll leave it covered at least overnight, and maybe for a day or two.

sam
  1888   Tue Aug 11 23:55:04 2009 rana, richSummaryOMCQuantum Efficiency and Dark Current measurements of eLIGO Photodiodes

Rich Abbott, Rana

Summary: We found that the 3mm InGaAs photodiodes from eGTRAN which are being used for the DC Readout in eLIGO are bad. The QE is ~50%. We will have to replace them ASAP.

Valera and Nic Smith have pointed out out a factor of ~2 discrepancy between the estimated power transmission to the dark port in H1 and L1. So we decided to measure the QE of the accused diodes.

 The data of the QE and dark current are attached here.

We used a 1064 nm CrystaLaser (which does not have a very stable power output). We attenuated the light with an ND1.0 for all measurements.

The photocurrent is estimated by reading out the voltage across one leg of the differential drive of the DC PD preamp. The photocurrent goes across a 100 Ohm resistor and then through 2 gain of  1 stages to get to this testpoint, so the overall transimpedance gain is 100 Ohms for this measurement.

By far, the Ophir power meter is the biggest source of error. Its absolute calibration is only 5% and the variation across the sensor face is ~5%. There are some hot and not hot spots on the face which can make even more variation, but we tried to avoid these.

We also inserted the power meter very close to the time when we read the voltage, so that the photocurrent and power estimates are made within 10 seconds of each other. This should reduce the error from the laser's power fluctuations.

All diodes still had the glass case on. We measured the reflected power to be ~5-7% of the incident power. This reflected power is NOT accounted for in these estimates.

 

Punch line: The eGTRAN diodes that we currently use are definitely bad. The JDSU and EG&G 2mm diodes have a better QE. We should immediately purchase 3 mm versions and get them cut and measured to be ready for the Sep. 1 commissioning surge.

Attachment 1: IMG_0135.png
IMG_0135.png
  1958   Thu Aug 27 16:14:28 2009 steveSummaryOMCburned photodiode

Old -pre 6/2009  LLO DCPD 3 mm od GTRAN photodiode

Attachment 1: 20090827_173252.jpg
20090827_173252.jpg
Attachment 2: 20090827_170802.jpg
20090827_170802.jpg
  2095   Thu Oct 15 02:38:10 2009 rana, robUpdateOMCDark Port Mode Scan using the OMC

Bottom trace is proportional to the OMC PZT voltage - top trace is the transmitted light through the OMC. Interferometer is locked (DARM- RF) with arm powers = 80 / 100. The peaks marked by the cursors are the +(- ?) 166 MHz sidebands.

Attachment 1: OMC-ModeScan_091015.png
OMC-ModeScan_091015.png
  8849   Mon Jul 15 16:44:46 2013 AlexUpdateOMCOMC North Safety

 [Eric Alex]

We are planning on testing our laser module soon, so we have added aluminum foil and a safety announcement to the door of OMC North. The safety announcement is as pictured in the attachment.

Attachment 1: photo_2_(1).JPG
photo_2_(1).JPG
  14022   Tue Jun 26 20:59:36 2018 aaronUpdateOMCprep for vent in a couple weeks

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)
  14051   Wed Jul 11 15:57:00 2018 aaronUpdateOMCReviving OMC electronics
Gautam showed me the electronics racks for the OMC PZTs and DAQ. I'm in the process of chasing down what channels we need, and confirming that we'll be able to plug the old antialiasing/imaging boards into the current DAC/ADC boards. I found what I think was Rob Ward's simlink model for the omc, located at
 
/cvs/cds/caltech/cds/rward-advLigo/src/epics/simLink/omc.mdl
 
Channels in this model:
  • 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)

 
Electronics inventory:
  • 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?
  •  
  14052   Wed Jul 11 16:23:21 2018 aaronUpdateOMCCoordination of the Output Mode-cleaner Mirror Insertion Expedition (COMMIE)

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
  14060   Thu Jul 12 21:16:25 2018 aaronUpdateOMCChecking OMC Electronics

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.

  14072   Sat Jul 14 16:04:34 2018 aaronUpdateOMCChecking OMC Electronics

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.

Attachment 1: Screenshot_2018-07-14_17.53.40.png
Screenshot_2018-07-14_17.53.40.png
Attachment 2: Screenshot_2018-07-14_17.57.17.png
Screenshot_2018-07-14_17.57.17.png
  14095   Sat Jul 21 01:14:02 2018 gautamUpdateOMCPZT Jena driver board check

[Aaron, gautam]

We did a quick check of this board today. Main takeaways:

  • There are two voltages (HV pos and HV neg) that are output from this unit.
  • Presumably, these goto different piezoelectric elements, referenced to ground. Are there any spec sheets for these describing the geometry/threshold voltages?
  • The outputs are:
    • \mathrm{HV_{+}} = 10(V_{\mathrm{DAC}}+V_{\mathrm{offset}}), \mathrm{HV_{-}} = 10(-V_{\mathrm{DAC}}+V_{\mathrm{offset}})
    • So with V_{\mathrm{offset}} = 7.5 \mathrm{V}, we expect to be able to use +/- 7.5 V of DAC range.
  • The trim pot had to be adjusted to realize V_{\mathrm{offset}} = 7.5 \mathrm{V}​.
  • I assume 150V is some kind of damage threshold of the PZT, so there is no benefit to using 10V offset voltage (as this would result in 200 V at full range DAC voltages).

With the correct V_{\mathrm{offset}} = 7.5 \mathrm{V}, we expect 0V from the DAC to result in 0 actuation on the mirror, assuming that an equal 75V goes to 2 PZTs mounted diametrically opposite on the optic. Hopefully, this means we have sufficient range to scan the input pointing into the OMC and get some sort of signal in the REFL signal (while length PZT is being scanned) which indicates a resonance. 

We plan to carve out some IFO time for this work next week.

  14120   Tue Jul 31 22:50:18 2018 aaronUpdateOMCOMC Expected Refl Signal

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:

R=r-\frac{t^2}{r}\frac{g(\omega)}{1-g(\omega)}

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

g(\omega)=r_1r_2(r_3...)e^{-i\phi}e^{-\alpha_0p}

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.

Attachment 1: omcRefl.pdf
omcRefl.pdf
  14159   Mon Aug 13 20:21:10 2018 aaronUpdateOMCNew DAC for the OMC

[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:

C1:OMC-ASC_PZT1_PIT
C1:OMC-ASC_PZT1_YAW
C1:OMC-ASC_PZT2_PIT
C1:OMC-ASC_PZT2_YAW
C1:OMC-PZT
 
The model compiles and we can change the channel values, so we are all set to do this OMC scan on the software side.
Attachment 1: c1omcSCREENSHOT.png
c1omcSCREENSHOT.png
  14163   Tue Aug 14 23:14:24 2018 aaronUpdateOMCOMC scanning/aligning script

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.

  14213   Sun Sep 23 20:15:35 2018 KojiSummaryOMCMontecarlo simulation of the phase difference between P and S pols for a modeled HR mirror

Link to OMC_Lab ELOG 308

ELOG V3.1.3-