40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 97 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13606   Mon Feb 5 14:11:01 2018 gautamUpdateALSHuge harmonics in ALS channels

I've been trying to setup for the THD measuremetn at the LSC rack for a couple of days now, but am plagued by a problem summarized in Attachment #1: there are huge harmonics present in the channel when I hook up the input to the whitening board D990694 to the output of a spare DAC channel at the LSC rack. Attachment #2 summarizes my setup. I've done the following checks in trying to debug this problem, but am no closer to solving it:

  • The problem is reminiscent of the one I experienced with the SR785 not too long ago - there the culprit was a switching power supply used for the Prologix GPIB-ethernet box.
  • Then I remembered sometime ago rana and i had identified the power supply for the Fibox at the LSC rack as a potential pollutant. But today, I confirmed that this power supply is not to blame, as I unplugged it from its powerstrip and the spectrum didn't change.
  • There are a couple of Sorensens in this LSC rack, from what it looks like, they supply power to a BIO interface box in the LSC rack. I thought we would want to keep this rack free of switching power supplies? Wasn't that the motivation behind keeping the (linear) power supplies for all the LSC rack electronics in a little separate rack along the east arm?
  • I confirmed that when the D990694 input is terminated, these harmonics are no longer present. 
  • I plugged the output of the SOS dewhite board to an oscilloscope - there is a ~20mVpp signal there even when the DAC output is set to 0, but this level seems too small to explain the ~1000 ct-pp signal that I was seeing. The whitening gains for these channels are set to 0dB.
  • I also looked at the signal in the time domain using DTT - indeed the peak-to-peak signal is a few thousand counts.
  • This isn't a problem with the particular input channel either - the behaviour can be reproduced with any of the 4 ALS input channels.

Am I missing something obvious here? I think it is impossible to do a THD measurement with the spectrum in this condition...

Attachment 1: ALSpowerlineHarmonics.pdf
ALSpowerlineHarmonics.pdf
Attachment 2: 2A1B3AC4-4059-416A-AD88-8AB0431D7A55.jpeg
2A1B3AC4-4059-416A-AD88-8AB0431D7A55.jpeg
  13608   Mon Feb 5 22:57:28 2018 gautamUpdateALSHuge harmonics in ALS channels

Did some quick additional checks to figure out what's going on here.

  1. The SOS/dewhite board for which I didn't have a DCC number is D000316. It has a single ended output.
  2. I confirmed that the origin of this noise has to do with the ground of the aforementioned D000316 - as mentioned in my previous elog, having one end of a BNC cable plugged into the whitening board D990694 and the other end terminated in 50ohms yields a clean spectrum. But making the ground of this terminator touch the ground of the SMA connector on the D000316 makes the harmonics show up.
  3. Confirmed that the problem exists when using either the SMA or the LEMO monitor output of these D000316 boards.

So either something is busted on this board (power regulating capacitor perhaps?), or we have some kind of ground loop between electronics in the same chassis (despite the D990694 being differential input receiving). Seems like further investigation is needed. Note that the D000316 just two boards over in the same Eurocrate chassis is responsible for driving our input steering mirror Tip-Tilt suspensions. I wonder if that board too is suffering from a similarly noisy ground?

Quote:
 

Am I missing something obvious here? I think it is impossible to do a THD measurement with the spectrum in this condition...

 

  7989   Sun Feb 3 13:20:02 2013 KojiSummaryGeneralHypothesis

Rana mentioned the possibility that the PR2 curvature makes the impact on the mode stability. Entry 7988
Here is the extended discussion.


Hypothesis:

The small but non-negligible curvatures of the TT mirrors made the recycling cavity unstable or nearly unstable.


Conclusion:

If the RoC of the TT mirrors are -600 m (convex), the cavity would be barely stable.
If the RoC of the TT mirrors are less than -550m, the horizontal modes start to be unstable.
Assumption that all of the TT mirrors are concave should be confirmed.


Fact (I): Cavity stability

- The folded PRMI showed the mode stability issue. (L=6.78m from Jenne's entry 7973)
- The folded PRM-PR2-PR3-flat mirror cavity also showed the similar mode issue. (L=4.34m)
- The unfolded PRM-PR2 cavity demonstrated stable cavity modes. (L=1.91m)

Fact (II): Incident angle

- PRM 0deg
- PR2 1.5deg
- PR3 41deg

Fact (III): Mirror curvature

- RoC of PRM (PRMU02): +122.1m (measured, concave), or +115.6m (measured by the vendor)
- RoC of G&H mirrors: -600m ~ -700m (measured, I suppose the negative number means convex) (Jenne's entry 7851)
  [Note that there is no measurement of the phase map for the PR2 mirror itself.]
- RoC of LaserOptik mirrors: -625m ~ -750m (measured, I suppose that the measurement shows the mirrors are convex.) (Jan's entry 7627 and 7638)

Let's assume that the TT mirrors are always convex and have a single number for the curvature radius, say RTT


Cavity mode calculation with Zach's arbcav

1) The unfolded PRM-PR2 cavity:

The cavity becomes unstable when 0 > RTT > -122m  (This is obvious from the g-factor calculation)
==> The measured RoC of the TT mirrors predicts the cavity is stable. (g=0.98, Transverse Mode Spacing 3.54MHz)

2) The folded PRM-PR2-PR3-flat mirror cavity:

The cavity becomes unstable when RTT < -550 m
==> The measured RoC of the TT mirrors (RTT ~ -600m) predicts the cavity is barely stable (g=0.997, TMS ~600kHz).

- The instability occurs much faster than the unfolded case.
- The horizontal mode hits unstable condition faster than the vertical mode.
- The astigmatism mainly comes from PR3.

3) The folded PRMI:

The cavity becomes unstable when RTT < -550 m
==> The measured RoC of the TT mirrors (RTT ~ -600m) predicts the cavity is barely stable. (g=0.995, TMS ~500kHz)

- The instability occurs with almost same condition as the case 2)

The calculation result for the PRMI with RTT of -600 m. The code was also attached.


Q&A:

Q. What is the difference between unfolded and folded?
A. For the unfolded case, the PR2 reflect the beam only once in a round-trip.
For the folded case, each TT mirror reflects the beam twice. Therefore the lens power by the mirror is doubled.

Q. Why the astigmatism mainly comes from PR3?
A. As the angle of incidence is much bigger than the others (41deg).

Q. Why the horizontal mode is more unstable than the vertical mode?
A. Off-axis reflection of a spherical mirror induces astigmatism. The effective curvature of the mirror in
the horizontal direction
is R / Cos(theta) (i.e. longer), while it is R Cos(theta) (i.e. shorter). Indeed, the vertical and horizontal ROCs are factor of 2 different
for the 45deg incidence.

Q. Why the stability criteria for the case 2) and 3) similar?
A. Probably, once the effective curvature of the PRM-PR2-PR3 becomes
negative when RTT < -550 m.

Q. You said the case 2 and 3 are barely stable. If the TMS is enough distant form the carrier, do we expect no problem?
A. Not really. As the cavity get close to the instability, the mode starts to be inflated and get highly astigmatic.
For the case 2), the waist radii are 5.0mm and 3.7mm for the horzontal and vertical, respectively.
For the case 3), they are 5.6mm and 4.1mm for the horzontal and vertical, respectively.
(Note: Nominally the waist radius is 3.1mm)

Q. What do you predict for the stability of the PRM-PR2-Flat_Mirror cavity?
A. It will be stable. The cavity is stable until
RTT becomes smaller than -240 m.

Q. If the TT mirrors are concave, will the cavity stable?
A. Yes. Particularly if PR3 is concave.

Q. Rana mentioned the possibility that the mirrors are deformed by too tight mounting of the mirror in a ring.
Does it impact the stability of the cavity?

A. Possible. If the curvature is marginal and the mounting emphasizes the curvature, it may meet the unstable condition.

Q. How can we avoid this instability issue?
A.
1. Use flatter mirrors or at least concave mirrors.

2. Smaller incident angle to avoid emphasis of the RoC in the horizontal direction
3. Use weaker squishing force for mounting of the mirrors
4. Flip the PR3 mirror in the mounting ring by accepting the compromise that the AR surface is in the cavity.

Attachment 1: mode_density_PRC.pdf
mode_density_PRC.pdf mode_density_PRC.pdf
Attachment 2: mode_density_PRC.zip
  7992   Mon Feb 4 15:06:56 2013 KojiSummaryGeneralHypothesis

Quote:

Q. How can we avoid this instability issue?
A.
1. Use flatter mirrors or at least concave mirrors.

2. Smaller incident angle to avoid emphasis of the RoC in the horizontal direction
3. Use weaker squishing force for mounting of the mirrors
4. Flip the PR3 mirror in the mounting ring by accepting the compromise that the AR surface is in the cavity.

 Another possibility is to use a ring heater to correct the curvature. I talked a bit with Aidan about this.

  6479   Tue Apr 3 12:42:19 2012 Mike J.UpdateComputersHysteresis Model

Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency2) as a solution to y''+frequency2*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code.

Attachment 1: hysteresis1.mdl
Model {
  Name			  "hysteresis1"
  Version		  7.6
  MdlSubVersion		  0
  GraphicalInterface {
    NumRootInports	    0
    NumRootOutports	    0
    ParameterArgumentNames  ""
    ComputedModelVersion    "1.9"
    NumModelReferences	    0
... 734 more lines ...
  6487   Thu Apr 5 01:07:08 2012 Mike J.UpdateComputersHysteresis Plots

Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)2*y-Hysteresis.  The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

SHO_hyst_plot.png

  1314   Mon Feb 16 22:58:51 2009 rana, yoichiConfigurationSUSHysteresis in SUS from Misalignments
WE wondered if there was some hysteresis in the SUS alignments. When we leave the optics misaligned for a
long time it seems to take awhile for the optic to settle down. Possibly, this is the slow deformation of
the wires or the clamps.

The attached PNG shows the plot of the bias sliders for a few days. You can see that we misalign some of the
optics much more than the others. This must be stopped.

Kakeru is going to use his nearly complete optical lever calibrations to quatify this by stepping the optics
around and measuring the effect in the optical lever. Of course, the misalignment steps will be too large to
catch on the OL, but he can calibrate the align-sliders into radians to handle this.
Attachment 1: a.png
a.png
  6142   Wed Dec 21 14:23:08 2011 ranaConfigurationSUSHysteresis in suspensions?

While discussing the suspension hysteresis measurements, Koji, Kiwamu, and I realized that the suspension wire standoff is aluminum, whereas the standoff for the LIGO LOS are using quartz.

Using a soft aluminum standoff is bad. The movement of the suspension will slowly wear the groove and produce opportunities for mechanical upconversion and hysteresis.

In fact, the wire standoff as well as the clamping block on the top should be made of sapphire or ruby to prevent any such wearing issues. Steve is hot on the case.

 

  6128   Sat Dec 17 01:56:16 2011 KojiSummarySUSHysteresis test

[Koji Kiwamu]

We wonder if the flakiness of MC2 comes from the suspension or not.

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The script is here:
/users/koji/111216/SUS_hysteresis.sh

For this test, we closed the mechanical shutter before the MC.

Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.

 

 -- EDIT by KI:
I found the ITMY watchdogs tripped around 2:40 AM and then re-engaged it.
  72   Tue Nov 6 18:18:15 2007 tobinConfigurationComputersI broke (and fixed) conlogger
It turns out that not only restart_conlogger, but also conlogger itself checks to see that it is running on the right machine. I had changed the restart_conlogger script to run on op340, but it would actually silently fail (because we cleverly redirect conlogger's output to /dev/null). Anyway, it's fixed now: I edited the conlogger source code where the hostname is hardcoded (blech!) and recompiled.

On another note, Andrey fixed the "su" command on op440m. It turns out that the GNU version, in /usr/local/bin, doesn't work, and was masking the (working) sun version in /bin. Andrey renamed the offending version as "su.backup".
  4525   Thu Apr 14 17:45:59 2011 BryanConfigurationGreen LockingI leave you with these messages...

OK… the Y-arm may be locked with green light, which was the goal, and this is all good but it's not yet awesome. Awesome would be locked and aligned properly and quiet and optimised. So...  in order to assist in increasing the awesome-osity, here are a few stream-of-consciousness thoughts and stuff I've noticed and haven't had time to fix/investigate or have otherwise had pointed out to me that may help...

 

Firstly, the beam is not aligned down the centre of the cavity. It's pretty good horizontally, but vertically it's too low by about 3/4->1cm on ETMY. The mirrors steering the beam into the cavity have no more vertical range left, so in order to get the beam higher the final two mirrors will have to be adjusted on the bench. Adding another mirror to create a square will give more range AND there will be less light lost due to off 45degree incident angles. When I tried this before I couldn't get the beam to return through the Faraday, but now the cavity is properly aligned this should not be a problem.

 

A side note on alignment - while setting cameras and viewports and things up, Steve noticed that one of the cables to one of the coils (UL) passes behind the ETMY. One of the biggest problems in getting the beam into the system to begin with was missing this cable. It doesn't fall directly into the beam path if the beam is well aligned to the cavity, but for initial alignment it obscures the beam - this may be a problem later for IR alignment.

 

Next, the final lambda/2 waveplate is not yet in the beam. This will only become a problem when it comes to beating the beams together at the vertex, but it WILL be a problem. Remember to put it in before trying to extract signals for full LSC cavity locking.

 

Speaking of components and suchlike things, the equipment for the green work was originally stored in 3 plastic boxes which were stored near the end of the X-arm. These boxes, minus the components now used to set up the Y-end, are now similarly stored near the end of the Y-arm.

 

Mechanical shutter - one needs to be installed on the Y-end just like the X-end. Wasn't necessary for initial locking, but necessary for remote control of the green light on/off.

 

Other control… the Universal PDH box isn't hooked up to the computers. Connections and such should be identical to the X-arm set-up, but someone who knows what they're doing should hook things up appropriately.

 

More control - haven't had a chance to optimise the locking and stability so the locking loop, while it appears to be fairly robust, isn't as quiet as we would like. There appears to be more AM coupling than we initially thought based on the Lightwave AM/PM measurements from before. It took a bit of fiddling with the modulation frequency to find a quiet point where the apparent AM effects don't prevent locking. 279kHz is the best point I've found so far. There is still a DC offset component in the feedback that prevents the gain being turned up - unity gain appears limited to about 1kHz maximum. Not sure whether this is due to an offset in the demod signal or from something in the electronics and haven't had time left to check it out properly yet. Again, be aware this may come back to bite you later.

 

Follow the bouncing spot - the Y-arm suspensions haven't been optimised for damping. I did a little bit of fiddling, but it definitely needs more work. I've roughly aligned the ETMY oplev since that seems to be the mass that's bouncing about most but a bit of work might not go amiss before trusting it to damp anything.

 

Think that's about all that springs to mind for now…

 

Thanks to everyone at the 40m lab for helping at various times and answering daft questions, like "Where do you keep your screwdrivers?" or "If I were a spectrum analyser, where would I be?" - it's been most enjoyable!

 
  4532   Fri Apr 15 13:43:23 2011 BryanConfigurationGreen LockingI leave you with these messages...

Y-end PDH electronics.

The transfer function of the Y-end universal PDH box:

Y_End_Electronics_TF.png

 

  1707   Sat Jun 27 02:48:09 2009 ClaraUpdatePEMI moved accelerometers and made some pretty pictures

I have been working on finding the best spots to put the accelerometer sets in order to best subtract out noise (seismometers next!). Here is a plot of what I've done so far:

80min_accel_0123.png

All of these were 80-minute samples. The dashed line is unfiltered, solid line filtered. So, Setup #1 looks the best so far, but I didn't leave it there very long, so perhaps it was just a really awesome 80 minutes. I've put the accelerometers back in the Setup #1 position to make sure that it is really better.

And, in case you can't intuitively figure out what configuration the accelerometers are in by such descriptive names, here are some helpful pictures. I didn't know about the digital cameras at first, so these are actually sketches from my notebook, which I helpfully labeled with the setup numbers, color-coded to match the graph above! Also, there are some real-life photographs of the current arrangement (Setup #1' if you forgot).

MC1_accel_sketch_side.png

MC1_accel_sketch_top.png

MC2_accel_sketch.png

Doesn't this one look kind of Quentin Blake-esque? (He illustrated for Roald Dahl.)

MC1acc_S01.JPG

This is the MC1 set.

MC2acc_S123.JPG

Guess which one this is!

  4998   Wed Jul 20 11:13:59 2011 Larisa ThorneUpdateelogI restarted the ELOG as it seemed to have crashed

 

  4872   Thu Jun 23 22:59:45 2011 kiwamuUpdateABSLI-P curve of LWE

 The I-P curve was measured again, but this time in a lower current range of 1.0-1.9 [A].

The plot below is the latest I-P curve.

IP_curve_small.png

(Decision)

Based on the measurement and some thoughts, I decided to run this laser at about 1.8 [A] which gives us a middle power of ~ 360 [mW].

In the 40m history, the laser had been driven at 2.4 [A] in years of approximately 2006-2009, so it's possible to run it at such a high power,

but on the other hand Steve suggested to run it with a smaller power such that the laser power doesn't degrade so fast.


(notes)

  The laser controller handed from PK (#4855) was used in this measurement.

The nominal current was tuned to be 1.8 [A] by tuning a potentiometer on the laser head (see page.18 on the manual of LWE).

There was a huge bump around 1.4 [A] and sudden power drop at 1.48 [A] although I don't know the reason.

Quote from #4842

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

  4877   Fri Jun 24 07:49:23 2011 steveUpdateABSLI-P curve of LWE with serial numbers

Quote:

 The I-P curve was measured again, but this time in a lower current range of 1.0-1.9 [A].

Quote from #4842

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

 Lightwave Laser Head M126-1064-700   sn238,  mounted on full size Al base and side heat sink on

Controller 125/126 Smart Supply   sn 201M

  4840   Mon Jun 20 11:38:49 2011 kiwamuUpdateABSLI-P curve of LightWave M126-1064-700

The I-P curve of the LightWave NPRO (M126-1064-700), which was taken out from the MOPA box, was measured. It looks healthy.

The output power can go up to about 1 W, but I guess we don't want it to run at a high power to avoid any further degradation since the laser is old.

 

IP_curve.png

 X-axis is the current read from the display of the controller. Y-axis is the output power, directly measured by Coherent PM10.

The measurement was done by changing the current from the controller.

Quote from #4832

 [Things to be done]

   - measure the beam profiles and power

   - get a laser controller, which will be dedicated for this laser, from Peter King

  4841   Mon Jun 20 13:48:25 2011 KojiUpdateABSLI-P curve of LightWave M126-1064-700

Hmm. Was the current within the operating range? (i.e. Is it a 700mW laser or a 1W one?)

You can obtain the nominal operating current from the old EPICS values (or some elog entries).

Note that NPROs are designed to be healthy only at around the nominal pumping power
(i.e. thermal gradient, and thermal lensing of the crystal, etc.)

ALSO:

Be aware that this laser should be used under the old SOP. So the appropriate interlocking is mandatory.

And probably we need to modify the SOP such that it reflects the latest situation.

Quote:

The I-P curve of the LightWave NPRO, which was taken out from the MOPA box, was measured. It looks healthy.

The output power can go up to about 1 W, but I guess we don't want it to run at a high power to avoid any further degradation since the laser is old.

  4842   Mon Jun 20 16:44:02 2011 steveUpdateABSLI-P curve of LightWave M126-1064-700

 

 Put the serial numbers into the elog. So we can identify the laser and controller in the future.

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

  1685   Thu Jun 18 23:20:40 2009 robSummaryLSCI-Q ratio with RF detected DARM

This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state.  It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases.   So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature.  This measure is imperfect because it doesn't account for the effect of the DARM loop.

Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband.  The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.

Attachment 1: IQratio.jpg
IQratio.jpg
  6809   Tue Jun 12 23:18:18 2012 yutaUpdateGreen LockingI-Q signals for the beat

[Mengyao, Yuta]

Yes!! We have I-Q signals for the beat!!

What we did:
  1. Aligned Y arm to the Y end green incident beam. The transmission to the PSL was about 195 uW.

  2. Aligned IR beam to the Y arm by adjusting PZTs and got the transmission, C1:LSC-TRY_OUT ~ 0.86.

  3. Aligned green optics on the PSL table to get the beat signal. The beat was found when;

  PSL laser temperature on display: 31.41 deg C
  C1:PSL-FSS_SLOWDC = 1.43
  Y end laser "T+": 34.049 deg C
  Y end laser "ADJ": 0
  Y end laser measured temperature: 34.14 deg C
  C1:GCY-SLOW_SERVO2_OFFSET = 29950
  Y end slow servo: off (was on)

  4. Connected the beat PD output to the beatbox.

  5. Kicked ETMY position to change the cavity length and while the ringdown, we run pynds to get data. We plotted C1:ALS-BEATY_FINE_I_ERR vs C1:ALS-BEATY_FINE_Q_ERR, and C1:ALS-BEATY_COARSE_I_ERR vs C1:ALS-BEATY_COARSE_Q_ERR (below). We got nice circle as expected.

FINEIQplot20120612.pngCOARSEIQplot20120612.png

Current setup:
  Only AA filers are put between the output of the beatbox and the ADC.

beatysetup20120612.png

  16012   Sat Apr 10 08:51:32 2021 JonUpdateCDSI/O Chassis Assembly

I installed three of the 16-bit ADC adapter boards assembled by Koji. Now, the only missing hardware is the 18-bit DACs (quantities below). As I mentioned this week, there are 2-3 16-bit DACs available in the FE cabinet. They could be used if more 16-bit adapter boards could be procured.

C1BHD    
Component Qty Required Qty Installed
16-bit ADC 1 1
16-bit ADC adapter 1 1
18-bit DAC 1 0
18-bit DAC adapter 1 1
16-ch DIO 1 1
C1SUS2    
Component Qty required Qty Installed
16-bit ADC 2 2
16-bit ADC adapter 2 2
16-bit DAC 1 1
16-bit DAC adapter 1 1
18-bit DAC 5 0
18-bit DAC adapter 5 5
32-ch DO 6 6
16-ch DIO 1 1
  16093   Thu Apr 29 10:51:35 2021 JonUpdateCDSI/O Chassis Assembly

Summary

Yesterday I unpacked and installed the three 18-bit DAC cards received from Hanford. I then repeated the low-level PCIe testing outlined in T1900700, which is expanded upon below. I did not make it to DAC-ADC loopback testing because these tests in fact revealed a problem with the new hardware. After a combinatorial investigation that involved swapping cards around between known-to-be-working PCIe slots, I determined that one of the three 18-bit DAC cards is bad. Although its "voltage present" LED illuminates, the card is not detected by the host in either I/O chassis.

I installed one of the two working DACs in the c1bhd chassis. This now 100% completes this system. I installed the other DAC in the c1sus2 chassis, which still requires four more 18-bit DACs. Lastly, I reran the PCIe tests for the final configurations of both chassis.

PCIe Card Detection Tests

For future reference, below is the set of command line tests to verify proper detection and initialization of ADC/DAC/BIO cards in I/O chassis. This summarizes the procedure described in T1900700 and also adds the tests for 18-bit DAC and 32-channel BO cards, which are not included in the original document.

Each command should be executed on the host machine with the I/O chassis powered on:

$ sudo lspci -v | grep -B 1 xxxx

where xxxx is a four-digit device code given in the following table.

Device Device Code
General Standards 16-bit ADC 3101
General Standards 16-bit DAC 3120
General Standards 18-bit DAC 3357
Contec 16-channel BIO 8632
Contec 32-channel BO 86e2
Dolphin IPC host adapter 0101

The command will return a two-line entry for each PCIe device of the specified type that is detected. For example, on a system with a single ADC this command should return:

10:04.0 Bridge: PLX Technology, Inc. PCI9056 32-bit 66MHz PCI IOBus Bridge (rev ac)
             Subsystem: PLX Technology, Inc. Device 3101
  16116   Tue May 4 07:38:36 2021 JonUpdateCDSI/O Chassis Assembly

IOP models created

With all the PCIe issues now resolved, yesterday I proceeded to build an IOP model for each of new FEs. I assigned them names and DCUIDs consist with the 40m convention, listed below. These models currently exist on only the cloned copy of /opt/rtcds running on the test stand. They will be copied to the main network disk later, once the new systems are fully tested.

Model Host CPU DCUID
c1x06 c1bhd 1 23
c1x07 c1sus2 1 24

The models compile and install successfully. The RCG runtime diagnostics indicate that all is working except for the timing synchronization and DAQD data transmission. This is as expected because neither of these have been set up yet.

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Attachment 1: Screen_Shot_2021-05-03_at_4.16.06_PM.png
Screen_Shot_2021-05-03_at_4.16.06_PM.png
  16130   Tue May 11 16:29:55 2021 JonUpdateCDSI/O Chassis Assembly
Quote:

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Today I brought and installed the new optical transceivers (Finisar FTLF1217P2BTL) for the two timing slaves. The timing slaves appear to phase-lock to the clocking signal from the master fanout. A few seconds after each timing slave is powered on, its status LED begins steadily blinking at 1 Hz, just as in the existing 40m systems.

However, some other timing issue remains unresolved. When the IOP model is started (on either FE), the DACKILL watchdog appears to start in a tripped state. Then after a few minutes of running, the TIM and ADC indicators go down as well. This makes me suspect the sample clocks are not really phase-locked. However, the models do start up with no error messages. Will continue to debug...

Attachment 1: Screen_Shot_2021-05-11_at_3.03.42_PM.png
Screen_Shot_2021-05-11_at_3.03.42_PM.png
  16131   Tue May 11 17:43:09 2021 KojiUpdateCDSI/O Chassis Assembly

Did you match the local PC time with the GPS time?

  6814   Wed Jun 13 11:19:05 2012 steveUpdateSUSIDC receptacles clamped

The MC_ IDC 64 pin cables from sat. amplifiers to junction-interface-board towards  whitening - dewhitening at the back of rack 1 X 5 are finally  clamped with

All other sus cables of the same kind have the correct short latch arm to lock them in for reliable contact.

Attachment 1: IMG_1341.JPG
IMG_1341.JPG
  10113   Mon Jun 30 16:55:24 2014 ericqUpdateGeneralIFO (mostly) aligned

IR Alignment of the IFO is recovered! Green alignment could use some attention. 

Arms and PRC hold well, powers are within normal ranges. (TR[X,Y] >.9, POP110I > 400)

Details:

  • Starting from where Koji had brought things (i.e. beams on REFL, AS), I gradually stepped the PRM back to where I had a PRC lock right before the bootfest, using SUSPIT_IN and SUSYAW IN, while stepping the TT pointing (arbitrarily shifting TT1 and TT2) to keep the REFL camera spot centered. 
  • Green was locked fairly well to the Yarm (GTRY = 0.8), so I knew it supported a mode. I misaligned ITMX to keep the Xarm out of the way. 
  • Adjusting TT1 and TT2, I was able to get some light on the POP camera, while keeping REFL spot visible with small adjustments to PRM
  • I set up the PRM to set up some PRM-ITMY retroreflection, and saw tiny flashes in TRY. 
  • From here, I wandered around with the tip-tilts to try and get better arm pointing, while tweaking PRM for the REFL spot and retroflection, and BS for the AS spot. I got this to TRY flashes of ~0.3

Then, Jenne took over, worked some alignment magic, and did the hard part of getting the Yarm locked and ASS'd. 

  • I then took back over and got the Xarm locked and ASS'd.
  • I saved relevant mirror positions, and set up the PRMI, got it locked, saved PRM position. 
  • Jiggled the BS/PRM oplev HeNe power connector, it turns on now, oplevs are working. 
  • Similar to TT1, TT2 gains for PIT and YAW are now 300. Strictly speaking, they don't have to be, but PIT would be very nearly railed, and I changed YAW so that all four gains would be consistent.

Caveats:

Green no longer locks to 00 on the Y-arm, and the X-arm green transmission isn't the best despite PZT fiddling (~.6). Also, when green is locked to the Xarm, I see a distinct circular spot on the GTRY camera, with Y green and PSL green shutters closed. 

While Jenne used Yarm ASS successfully, when I run it now, it slowly pushes things out of alignment, and two of the traces (YARM_ETM_YAW_L_DEMOD_I_OUTPUT, and the same for ITM) have a reasonable constant offset that doesn't move away. 

 

  10114   Mon Jun 30 22:06:55 2014 JenneUpdateASCIFO (mostly) aligned - ASS working

[Koji, Jenne]

The Yarm ASS is now working (as is the Xarm ASS).  Both of the TT's pitch servos had a sign flip.  We don't know why.

To start, we lowered the matrix elements that push on the TTs by a factor of 3, to compensate for the new factor of 3 in the slider gains:  ezcastep C1:ASS-YARM_OUT_MTRX_5_5 /3 C1:ASS-YARM_OUT_MTRX_5_7 /3 C1:ASS-YARM_OUT_MTRX_6_6 /3 C1:ASS-YARM_OUT_MTRX_6_8 /3 C1:ASS-YARM_OUT_MTRX_7_5 /3 C1:ASS-YARM_OUT_MTRX_7_7 /3 C1:ASS-YARM_OUT_MTRX_8_6 /3 C1:ASS-YARM_OUT_MTRX_8_8 /3

We turned off all 4 tip tilt ASS servos (in the Yarm ASS servo screen), and turned them on one at a time.  By doing this, we discovered that the pitch servos for both TT1 and TT2 needed to have the opposite sign from what they used to have.  However, the yaw servos kept the original signs.  It really doesn't make sense to me why this should be, but this is the way the ASS servo works.  We left both Xarm and Yarm ASSs on for several minutes, and saw that they didn't push any mirrors out of alignment.

The ASS_DOTHER_ON burt snapshot has been resaved with the new values.

 

Also, earlier this evening, I aligned the Yarm green beam to the cavity, although the cavity was not optimally aligned, so this needs to be re-done.

 

On our to-do list should be to add the tip tilt slider values to the DAQ channels list.

  1830   Tue Aug 4 23:03:56 2009 albertoUpdateLockingIFO Alignment

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

  1833   Wed Aug 5 09:48:05 2009 albertoUpdateLockingIFO Alignment

Quote:

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

I also noticed that the FSS transmitted power has been constantly decaying for the last 6 months. Only in the last month tt dropped by 15%. The laser power hasn't decayed as much, so it's probably not the cause.
Maybe this is one reason why lately of less power going to the IFO.
 
We call it FSS Transmission, but I guess we mean power transmitted TO the IFO, that is it measures the power reflected from reference cavity, right?
 
Still on the front of the FSS, the reflected power has dropped from -0.5 to -1.2. Here I also wonder about the reason of negative values for that.
 

See attachments

Attachment 1: 2009-08-09_FSStransPD.png
2009-08-09_FSStransPD.png
Attachment 2: 2009-08-09_FSreflPD.png
2009-08-09_FSreflPD.png
  2205   Sun Nov 8 22:50:29 2009 AlbertoUpdateASCIFO Alignment

Tonight I aligned the IFO by running the scripts one by one.

SRC was far off and I had to align SRM by hand before the script could work. SPOB is still low when DRM is aligned.

I'm restoring the full IFO now that I'm taking off.

  8921   Thu Jul 25 02:53:00 2013 KojiUpdateGeneralIFO Alignment after TT flipping - no progress

There was no progress tonight after Jenne left.
I could not find any reasonable fringes of the IFO after 3 hours of optics jiggling.

* I jiggled TT1 and TT2. The slider has not been restored.
We should probably look at the value in the day time and revert them.
(Still this does not ensure the recovery of the previous pointing because of the hysteresis)

* The arms are still aligned for the green.
It's not TEM00 any more because of the vent/drift but the fringe is visible (i.e. eigenaxis is on the mirror)

* As we touched PR3, the input pointing is totally misaligned.

To Do / Plan

* We need to find the resonance of the yarm by the input TTs. Once the resonance is found, we will align the PRM.

* Move the BS to find the xarm resonance.

* Finally align SRM

* It was not possible to find the resonance of the yarm without going into the chamber. Definitely we can find the spot on the ITMY by a card, but we are not sure the beam can hit the ETMY. And the baffles makes the work difficult.

* One possibility is to align the input beam so that the ITMY beam is retroreflected to the PRM. I tried it but the beam was not visible form the camera.

  551   Sun Jun 22 21:38:49 2008 robHowToGeneralIFO CONFIGURE

Now that we're getting back into locking, it's nice to have a stable alignment of the interferometer.
Thus, after you're done with your experiment using subsets of the interferometer (such as a single arm),

please use the IFO_CONFIGURE screen, and click "Restore last Auto-Alignment" in the yellow "Full IFO" section.

If you don't know what this means/how to do this, you shouldn't be using the interferometer on your own.
  9807   Mon Apr 14 13:20:45 2014 JenneUpdateLSCIFO Configure screen updated, CARM / DARM scripts added

I have compressed the IFO Configure screen.  All PRMI things (sideband lock and carrier lock) are in the PRMI button, all arm things (both RF and ALS) are in the respective arm buttons.

I have also made a new set of scripts for CARM and DARM lock acquisition with ALS. 

I hope that each button's purpose is clear, but take a second to look at them before you next use the IFO Configure screen.

  1693   Wed Jun 24 09:21:19 2009 steveConfigurationVACIFO RGA scan with Maglev & Cryo

Quote:

Quote:

The Maglev is running for 10 days with V1 closed.  The pressure at the RGA-region is  at 2e-9 torr on CC4 cold cathode gauge.

Valve VM2 to Rga-only was opened 6 days ago. The foreline pressure is still 2.2e-6 torr with small Varian turbo ~10 l/s on cc2

Daily scans show small improvement in large amu 32 Oxygen and large amu 16, 17 and 18 H20 water peaks.

Argon calibration valve is leaking on our Ar cylinder and it is constant.

 

The good news is that there are no fragmented hydrocarbons in the spectrum.

The Maglev is soaked with water. It was seating in the 40m for 4 years with viton o-ring seals

However I can not explan the large oxygen peak, either Rai Weiss can not.

 

The Maglev scans are indicating cleanliness and water. I'm ready to open V1 to the IFO

 V1 valve is open to IFO now. V1 interlock will be tested tomorrow.

Valve configuration: VAC NORMAL with CRYO and Maglev are both pumping on the IFO

The IFO RGA scan is normal.

The Cryo needs to be regenerated next. It has been pumping for 36 days since last regenerated.

This has to be done periodically, so the Cryo's  14 K cold head is not insulated by by ice of all things pumped away from the IFO

Attachment 1: nmagd1ifo.jpg
nmagd1ifo.jpg
Attachment 2: nmagCryopres.jpg
nmagCryopres.jpg
  14115   Mon Jul 30 11:05:44 2018 gautamUpdateSUSIFO SUS wonky

When I came in this morning:

  • PMC was unlocked.
  • Seis BLRMS were off scale.
  • ITMX OSEM LEDs were dark on the CRT monitor even though Sat Box was plugged in.

Checking status of slow machines, it looked like c1sus, c1aux, and c1iscaux needed reboots, which I did. Still PMC would not lock. So I did a burtrestore, and then PMC was locked. But there seemed to be waaaaay to much motion of MCREFL, so I checked the suspension. The shadow sensor EPICS channels are reporting ~10,000 cts, while they used to be ~1000cts. No unusual red flags on the CDS side. Everything looked nominal when I briefly came in at 6:30pm PT yesterday, not sure if anything was done with the IFO last night.

Pending further investigation, I'm leaving all watchdogs shutdown and the PSL shutter closed.

A quick look at the Sorensens in 1X6 revealed that the +/- 20V DC power supplies were current overloaded (see Attachment #1). So I set those two units to zero until we figure out what's going on. Possibly something is shorted inside the ITMX satellite box and a fuse is blown somewhere. I'll look into it more once Steve is back.

Attachment 1: IMG_7102.JPG
IMG_7102.JPG
  16028   Wed Apr 14 14:52:42 2021 gautamUpdateGeneralIFO State

The C1:IFO-STATE variable is actually a bunch (16 to be precise) of bits, and the byte they form (2 bytes) converted to decimal is what is written to the EPICS channel. It was reported on the call today that the nominal value of the variable when the IMC is locked was "8", while it has become "10" today. In fact, this has nothing to do with the IMC. You can see that the "PMC locked" bit is set in Attachment #1. This is done in the AutoLock.sh PMC autolocker script, which was run a few days ago. Nominally, I just lock the PMC by moving some sliders, and I neglect to set/unset this bit.

Basically, there is no anomalous behavior. This is not to say that the situation cannot be improved. Indeed, we should get rid of the obsolete states (e.g. FSS Locked, MZ locked), and add some other states like "PRMI locked". While there is nothing wrong with setting these bits at the end of execution of some script, a better way would be to configure the EPICS record to automatically set / unset itself based on some diagnostic channels. For example, the "PMC locked" bit should be set if (i) the PMC REFL is < 0.1 AND (ii) PMC TRANS is >0.65 (the exact thresholds are up for debate). Then we are truly recording the state of the IFO and not relying on some script to write to the bit (I haven't thoguht through if there are some edge cases where we need an unreasonable number of diagnostic channels to determine if we are in a certain state or not).

Attachment 1: IFOSTATE.png
IFOSTATE.png
  16030   Wed Apr 14 16:46:24 2021 AnchalUpdateGeneralIFO State

That makes sense. I assumed that IFO-STATE is configured as you have proposed it to be configured. This could be implemented in later.

Quote:
 

a better way would be to configure the EPICS record to automatically set / unset itself based on some diagnostic channels. For example, the "PMC locked" bit should be set if (i) the PMC REFL is < 0.1 AND (ii) PMC TRANS is >0.65 (the exact thresholds are up for debate). Then we are truly recording the state of the IFO and not relying on some script to write to the bit (I haven't thoguht through if there are some edge cases where we need an unreasonable number of diagnostic channels to determine if we are in a certain state or not).

 

  8085   Fri Feb 15 01:41:02 2013 Manasa, YutaSummaryAlignmentIFO aligned and ready for PRMI locking

[Yuta, Manasa, Jenne, Jamie, Steve]

IFO aligned and ready for PRMI locking

Alignment procedure

0. Measured MC centering (off by 5mrad) before getting the doors off.

1. Got the TTs to 0.0 in pitch and yaw.

2. Using the MMTs, the beam was centered on the TTs.

3. TT1 was adjusted such that the incident beam was centered at PRM (with target).

4. TT2 was adjusted such that the beam passed through the center of BS (with target).

5. Centered the beam on PR2 by sliding it on the table.

6. Moved PR2 and tweaked TT2 to center the beam on ITMY and BS respectively.

7. Using TTs, we got the beam centered on ETMY while still checking the centering on ITMY.

8. ITMY was adjusted such that it retro-reflected at the BS.

9. ETMY was aligned to get a few bounces in the arm cavity.

10. Centered on ITMX by adjusting BS and then tweaked ITMX such that we retro-reflected at BS.

11. At this point we were able to see the MI fringes at the AS port.

12. Tweaked ITMX to obtain reflected MI fringes in front of MMT2.

13. By fine adjustments of the ITMs, we were able to get the reflected MI to go through the faraday  while still checking that we were retro-reflecting at the BS.

14. Tweaked the PRM, such that the PRM reflected beam which was already visible on the 'front face back face of faraday' camera went through the faraday and made fine adjustments to see it fringing with the reflected MI that was already aligned.

15. At this point we saw the REFL (flashing PRMI) coming out of vacuum unclipped and on the camera.

16. Started with alignment to get the AS beam out of vacuum. We tweaked OM1 and OM2 (steering mirrors in the ITMY chamber) to center the beams on OM4 and OM3 (steering mirrors in the BSC) respectively.

17. We then adjusted steering mirrors OM5 and OM6 (in the OMC chamber) such that the beam went unclipped out of vacuum.

18. Note that we took out the last steering mirror (on the AS table) in front of the AS camera, so that we can find the AS beam easily. This can be fixed after we pump down.

 

 

Tomorrow

  0. REFL still looks like an egg, but leave it .

  1. Align PRMI (no more in-vac!) .

  2. Align POP/REFL/AS cameras and PDs.

  3. Setup PRM/BS/ITMX/ITMY oplevs.

  4. Balance the coils on these mirrors.

  5. Lock PRMI.

  8086   Fri Feb 15 01:51:43 2013 JenneSummaryAlignmentIFO aligned and ready for PRMI locking

 

Yuta and Manasa, you guys are awesome!

Small, inconsequential point:  The camera image in the upper right of your video is the *back* of the Faraday in our usual nomenclature.  The camera is listed in the videoswitch script as "FI_BACK".  The camera looking at the "front" of the Faraday is just called "FI". 

  10124   Wed Jul 2 16:18:32 2014 JenneUpdateASCIFO aligned, PRMI + 2 arms achieved

After the meeting, I aligned the IFO to the IR, and then I aligned the Ygreen to the Yarm.  I then found the beatnotes and used ALS to hold the arms with CARM/DARM, locked the PRMI, and reduced the CARM offset until I had arm powers of about 3.  Given that this was at 3pm, and people were tromping all over inside the IFO room, I feel positive about tonight.  

So, IFO seems ready, carm_cm_up script was successful, and got me to arm powers of 1, and then I further reduced the offset by a bit to go a little higher. 

  613   Tue Jul 1 12:51:34 2008 JohnSummaryGeneralIFO alignment
Rana, Rob, Yoichi, John

The recent computer problems and MZ work had disturbed the alignment of the interferometer.

We adjusted the MC alignment back to nominal positions using old OSEM values. We then walked
the input beam to match the MC. Coupling into the interferometer has increased noticeably.
The rest of the IFO was then aligned to the new input beam.

Proceeding to full IFO locking we were able to engage the AO path and hand off CARM to SPOBDC.
Arm powers got up to 4.

If the new alignment proves successful we will centre all QPDs etc so we can easily return to
this state.
Attachment 1: align080701.png
align080701.png
  5267   Fri Aug 19 01:46:06 2011 SureshUpdateGeneralIFO alignment

[Keiko, Jamie, Kiwamu, Anamaria,

We followed the procedure that we laid-out in our elog of yesterday.  We completed the first six steps and we now have the y-arm well aligned to the green beam which passes through the center of of both ETMY and ITMY. 

The IR beam was steered with the PZTs to coincide with the green beam.  The BS was adjusted to see IR beam scatter on a target placed near the center of the ETMX.  And then the AS IR beam was steered to the AS camera by adjusting several components along OM path ( we touched OM1, OM2, OM3, OM4, OM5, OMPO and OM6).  We then looked for IR fringes in the AS port from the Y-arm. But no luck there.  We need to realign the IR beam into the Y-arm cavity axis using the pzts.

We aligned ITMX and PRM to get power recycled Michelson fringes at the AS.

 

  8070   Tue Feb 12 20:42:36 2013 JamieUpdateAlignmentIFO alignment in prep for in-air PRMI

Yuta, Manasa, Jamie, Jenne, Steve, Rana

Starting this morning, we removed the temporary half PRC mirror in front of BS and started to align the IFO in prep for an in-air lock of the PRMI.

This morning, using the new awesome steerable active input TTs, Jenne and I centred the beam on PRM, PR2/3, BS, ITMY and ETMY.

After lunch, Yuta and Manasa aligned the Y ARM, by looking at the multi-pass beam.  The X-end door was still on, so they roughly aligned to the X ARM by centring on ITMX with BS.  They then got fringes at the BS, and tweaked the ITMs and PRM to get full fringes at BS.

We're currently stuck because the REFL beam appears to be clipped coming out of the faraday, even though the retro-reflected beam from PRM is cleanly going through the faraday output aperture.  The best guess at the moment is that the beam is leaving MC at an angle, so the retro-reflected beam is coming out of the faraday at an angle.  We did not center spots on MC mirrors before we started the alignment procedure today.  That was dumb.

We may be ok to do our PRMI characterization with the clipped REFL, though, then we can fix everything right before we close up.  We're going to need to go back to touch up alignment before we close up anyway (we need to get PR2 centered).

Yuta and Manasa are finishing up now by making sure the AS and REFL beams are cleanly existing onto the AS table.

Tomorrow we will set up the PRM oplev, and start to look at the in-air PRMI.  Hopefully we can be ready to close up by the end of the week.

  8071   Tue Feb 12 20:57:47 2013 JenneUpdateAlignmentIFO alignment in prep for in-air PRMI

We should check MC spot positions to see what they are. 

Also, I'm not thrilled about the idea of a clipped REFL beam.  Haven't we played that game before, and decided it's a crappy game?  Can we recenter the MC, and recover quickly with TT1? 

 

  8073   Tue Feb 12 23:24:17 2013 yutaUpdateAlignmentIFO alignment in prep for in-air PRMI

[Manasa, Yuta]

Lot's of alignment work, still no AS beam. REFL is clipped by Faraday output aperture......
Our guess is that this is because
we skipped MC centering.

Alignment procedure we took:
 1. AM work: Aligned input beam using TT1/TT2
   such that the beam hits ETMY and ITMY at the center.

 2. Coarsely aligned ITMY
   such that the ITMY retro-reflected beam hits BS at the center.

 3. Aligned ETMY (we didn't actually move ITMY)
   such that Y arm flashes.
   This tells you that ITMY is aligned well to the incident beam.

 4. Aligned BS
   such that the beam hits ITMX at the center.

 5. Aligned ITMX
   such that the ITMX retro-reflected beam hits BS at the center.
   At this point, we saw MI fringes at AS port.

 6. Fine alignment of ITMX:
   MI reflected beam was not overlapping in front of BS after it was reflected by PRM.
   We used this longer REFL path to tune alignment of ITMX to ITMY reflected beam.
   We saw MI fringe at REFL port coming out of the chamber, but it was clipped.

 7. Aligned PRM
   by looking at REFL beam from PRM on the back face of Faraday (video FI_BACK).
   We fine tuned the alignment such that PRM retro-relfected beam hits BS at the center and REFL beam from PRM overlaps with the MI fringes at the back face of Faraday.

 8. Clipping of REFL at the Faraday output aperture:
   We confirmed that the shape of the REFL beam from PRM was OK at the back face of Faraday. But some how, it was clipped at the output aperture. So, REFL beam coming out of the chamber is clipped now.

 9. Tried to get AS beam out of the chamber:
   We tweaked steering mirrors after SRM to get AS beam out of the chamber. But, we lost the AS beam between the very last folding mirrors (OMPO and OM6) in the OMC chamber......


Discussion:
 1. Why clipping at the Faraday output aperture?
   In principle, if PRM reflects the incident beam at normal incidence, it should pass the Faraday unclipped. But it's not!
   Our guess is that the incident beam does not go well centered through the apertures of the Faraday. I think we have to do MC centering to get good pointing to the Faraday.
   We also see that MI fringe at the back face of the Faraday is at the edge of its aperture, after all of these alignment work (we even used Y arm!). This tells you that some thing is wrong.

 2. Why did you guys lose the AS beam?
   AS beam is too weak after reflecting off of OMPO. The beam was neither visible on IR cards nor IR viewers. The beam is weaker than usual because PMC transmission is ~0.7 and MC REFL is getting high (~ 0.7). We didn't want to realign MC after all of this work today.


Tomorrow (my suggestion):
  1. Align PMC (for higher power).
  2. MC centering.
  3. Input beam steering using TTs and redo the same alignment procedure (it shouldn't take longer than today).
      ==> Center beam on PR2  (Added by Manasa)
  4. Maybe we should better check PRM reflection at REFL port after the Faraday, before doing the full alignment work.
  5. Align AS, REFL, POP PDs/cameras.
  6. Setup PRM/BS/ITMX/ITMY oplevs.
  7. Balance the coils on these mirrors.
  8. Lock PRMI.


What needs to be done before pumping down:
  1. PRMI characterization: PR gain and g-factor
   How can we do the g-factor measurement? Use additional laser? Kakeru method (elog #1434; we need to calibrate mirror tilt to do this)?
  2. Glitch study in PRMI locking. If still glitchy, we have to do something. How is beam spot motion? (elog #6953)
  3. Fine alignment of the flipped PR2.
  4. Fine alignment of IFO using both arms.

  4673   Tue May 10 00:31:28 2011 kiwamuUpdateASCIFO alignment plan

The alignment of the interferometer goes basically step by step.

Tuesday will be an alignment day.

  0. MC beam centering (it's done)

  1. F2P to balance the coils on every optics including BS, PRM, SRM, ITMs and ETMs (Kiwamu).

  2. A2L and then change the DC bias of ITMY and ETMY to get a perfect eigen axis (VF/Jamie).

  3. align input PZT mirrors (PZT1 and 2) to maximize the Y arm transmission (VF/Jamie).

  4. do the same things for X arm but using BS instead of the PZTs.

  5. Alignment of the central part.

  6. Make a script to automatically get those things done. 

  10047   Mon Jun 16 23:15:44 2014 JenneUpdateLSCIFO alignment recovery

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.

 

Also, this afternoon, I touched up the MC alignment a bit, although it still needs work (I've asked Manasa to look at it tomorrow).  Rana centered the WFS to my MC alignment (this will need to be redone after the MC is truely aligned), and we turned the WFS on.  I also locked both arms individually, and locked MICH and PRMI sideband.  The PRMI wasn't especially stable unless I turned on the POP ASC.  I assume (hope) that this is just because I was doing it during the day, and not because there is something actually different about the PRMI since the computer meltdown.

 

Rana and I also took some notes on things that need to be done, starting tomorrow (the first line and the yellow line are scribbles):

Note_061614_230723_0.jpg

  10051   Tue Jun 17 17:14:14 2014 ManasaUpdateLSCIFO alignment recovery

 1. Recovered MC alignment and locked it manually after the ottavia cron failed to help.

2. Measured the MC spots and could not get the MC spots better looking than this.

spot positions in mm (MC1,2,3 pit MC1,2,3 yaw):
[1.6609930611758554, -1.4655939584833202, 1.3133188677545831, -1.9483764375494121, -1.6539541350121174, -0.8862744551298497]

3. Realigned the beams to the MC WFS and enabled WFS servo.

MC Trans SUM is ~17000 counts and MC REFL is ~0.5 counts.

To-do list

MC spots

MC WFS

IOO QPDS center

BBPD char

Recover REFL 33

MC REFL

MC autolocker cron

ELOG V3.1.3-