40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 214 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  9321   Thu Oct 31 00:06:45 2013 masayukiUpdateComputer Scripts / Programscds fft,tf,offsets

I wrote the scripts for cdsutils.

1. fft

usage: fft.py [-h] [-c N_CYCL] [-a N_AVG] freq channel [channel ...]

Measures the frequency content of one or more NDS channels
at the specified frequecy.
    The measurement results are  magnitude, phase, real part imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  channel     list of measurement channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100

2. tf

usage: tf.py [-h] [-c N_CYCL] [-a N_AVG] [--dB] freq input output

Measures the transfer funtion of one NDS channels pair  at the specified frequecy.
    The measurement results are the coherence, magnitude, phase, real part, imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  input       list of measurement input channel
  output      list of measurement output channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100
  --dB        print the amplitude in dB

 

3.offsets

usage: offset.py [-h] [-t SECONDS] filterbank [filterbank ...]

Zero the offset of one or more filterbank. Take average of OUT16 channel, and put (-1 * average / gain) into offset.  After change offsets, it will turn on the offset.
    example usage) offset -d 25 C1:LSC-AS55_Q C1:LSC-AS55_I

positional arguments:
  filterbank  list of filterbank to zero offset

optional arguments:
  -h, --help  show this help message and exit
  -t SECONDS  define the averaging time. default value is 10

I put these scripts in /opt/rtcds/cdsutils/trunk/lib/cdsutils.
I couldn't put them into cds library, but I will left tomorrow to Japan...

So please help me Jamie or Joe !!

 

 

By the way,

I modified the LSCoffset script  (script)/LSC/LSCoffsets.py.

usage: LSCoffsets.py [-h] [-d SECONDS] [--PDlist]

 Zero the offsets of LSC PDs. During taking average, we will close the PSL and green shutter. After zeroing, it will turn on the offsets switch.
    example usgae) LSCoffset2.py -d 20    

optional arguments:
  -h, --help  show this help message and exit
  -d SECONDS  define the averaging time. default value is 10
  --PDlist    print PD list for LSC and exit

i made new directory 'offset_backup' for old offset script. I move all old offset script into there.

But unfortunately that cannot use right now, because cds offsets script is not available yet...

  9322   Thu Oct 31 15:34:28 2013 manasaUpdateIOOMC not happy since yesterday

Quote:

 

8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 

The MC has not been able to hold lock for over a couple of hours since yesterday. I aligned the MC yesterday (elog 9320) and it lost lock in a couple of hours. I realigned the MC again around noon today only to see it drifting and lose lock again.

I have attached the MC trend for the 2 hours when the MC drifted slowly from its happy to sad state.

 

 

Attachment 1: MC_drift.png
MC_drift.png
  9323   Thu Oct 31 20:05:48 2013 RANAUpdateIOOMode Cleaner Tune-UP

Quote:

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 I couldn't find any dumps near the WFS. Koji looked. I looked twice. Maybe they are spooky and absorbing all of the light?

The MC alignment was bad and the WFS were making it drift. Koji aligned the beam into the PMC. I then restored the MC suspensions to where they were 8 days ago (back when the transmission and reflection were good). With the WFS OFF, this gave us a MC trans ~ 16000. With WFS ON it goes to 17500 which is about as good as its been over the last 80 days.

I centered the beam on the WFS with the MC unlocked and also centered the beam on the whole WFS path (it was near clipping between WFS 1 & 2). Also for some reason that beamsplitter which steers the beam onto WFS1 is a R=33% (!? why is this not a R=50% ??).

Steve, please swap this out to a BS1-1064-50-1025-45S if we have one sitting around. If not, we want to add this to the CVI purchase list, but not buy until we get a bigger list together.

I also centered this newly aligned beam into the IMC onto the PSL QPDs. We should now use these as a pointing reference for the beam into the IMC.

While doing this I noticed that the beam was almost clipping on the Uniblitz shutter used to block the PSL beam. That shutter is mounted too short and was also not centered horizontally. I removed it for now so that Steve can find a more adjustable mount for it and put it back into play. The beam going into the IMC is BIG, so you have to very careful when centering the shutter. Might be that we cannot leave it at 45 deg and still get a big enough aperture.

Note #3 for Steve: please also replace the mount for last steering mirror into the IMC with a Polanski or a Superman, that black Ultima is no good. Also the dogs must be steel - no aluminum dogs for our sensitive places.

Attachment 1: drifty.png
drifty.png
  9325   Fri Nov 1 09:45:32 2013 SteveUpdateIOObeam dumps to be find

Quote:

Quote:

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 I couldn't find any dumps near the WFS. Koji looked. I looked twice. Maybe they are spooky and absorbing all of the light?

The MC alignment was bad and the WFS were making it drift. Koji aligned the beam into the PMC. I then restored the MC suspensions to where they were 8 days ago (back when the transmission and reflection were good). With the WFS OFF, this gave us a MC trans ~ 16000. With WFS ON it goes to 17500 which is about as good as its been over the last 80 days.

I centered the beam on the WFS with the MC unlocked and also centered the beam on the whole WFS path (it was near clipping between WFS 1 & 2). Also for some reason that beamsplitter which steers the beam onto WFS1 is a R=33% (!? why is this not a R=50% ??).

Steve, please swap this out to a BS1-1064-50-1025-45S if we have one sitting around. If not, we want to add this to the CVI purchase list, but not buy until we get a bigger list together.

I also centered this newly aligned beam into the IMC onto the PSL QPDs. We should now use these as a pointing reference for the beam into the IMC.

While doing this I noticed that the beam was almost clipping on the Uniblitz shutter used to block the PSL beam. That shutter is mounted too short and was also not centered horizontally. I removed it for now so that Steve can find a more adjustable mount for it and put it back into play. The beam going into the IMC is BIG, so you have to very careful when centering the shutter. Might be that we cannot leave it at 45 deg and still get a big enough aperture.

Note #3 for Steve: please also replace the mount for last steering mirror into the IMC with a Polanski or a Superman, that black Ultima is no good. Also the dogs must be steel - no aluminum dogs for our sensitive places.

No wonder they could not find the beam dumps. Last night was Haloween. They should of just said: Trick or treat! where are the beam dumps?

Attachment 1: razor_beam_dumps.jpg
razor_beam_dumps.jpg
  9330   Sat Nov 2 19:36:15 2013 CharlesUpdateGeneralPossible misalignment?

 I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.

I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.

  9331   Sat Nov 2 22:49:44 2013 CharlesUpdateISSCTN ISS Noise Suppression Requirement - Updated 10/27

 Previously in elog 8959, I gave a very simple method for determining the noise suppression behavior of the ISS. Recently, I recalculated this requirement in a more correct fashion and again redesigned the ISS to be used in the CTN experiment.

  • Determining the Requirement

Just as before, the data from PSL elog 1270 is necessary to infer a noise suppression requirement. The data presented there by Evan consists of two noise spectra, 1) the unstabilized RIN presently observed in the CTN experiment readout and 2) the theoretical brownian noise produced by thermal processes in the mirror coating+substrate. The statement "TF_mag = (Unstabilized RIN) / (Calculated Brownian Noise Limit)", where TF_mag refers to the required open-loop gain of the ISS, is actually a first order approximation of the 'required' noise suppression. In fact if we wanted the laser noise to be suppressed below the calculated brownian noise level, it is more correct to say 

        Closed-loop ISS gain = (Calculated Brownian Noise Limit) / (Unstabilized RIN)

As this essentially gives a noise suppression spectrum i.e. a closed-loop gain in linear control theory. Below is a very simple block diagram showing how the ISS fits into the CTN experiment. The F(f) block represents my full servo board.

    ISS_path.png

Some of the relevant quantities involved:

            plant-quant_1.png

            plant-quant_2.png

So looking at the block diagram, our full closed-loop transfer function is given by,

cl-loop.png

So then to determine the required F(f), i.e. the required transfer function for my servo, we consider the expression 

               requirement.png

The plant transfer function is simply Plant = (C(f) * a * P * A) ~ 0.014 V/V, where I have ignored the cavity pole around 97 kHz as our open-loop transfer function ends up crossing unity gain around 10 kHz. In the above, I have included what I call a 'safety factor' of 10. Essentially, I want to design my servo such that it suppresses noise well beyond what is actually required so that we can be sure noise contributions to experiment readouts are not significantly influenced by the laser intensity noise.

  • Proposed Servo Design

Using the data Evan reported for the brownian noise and free-running RIN, I came up with an F(f) to the meet the requirement as shown below.

CTN_TF_req-vs-proposed.png

 Where the blue curve includes the safety factor mentioned before. This plot just demonstrates that using my modular ISS design, I can meet the given noise suppression requirements.

To be complete, I'll say a little more about the final design.  As usual, the servo consists of three stages. The first is the usual LP filter that is always 'on' when the ISS loop is closed. The boosts I have chosen to use consist of an integrator with a single zero and a filter that looks somewhat like a de-whitening filter. The simulated open-loop transfer functions are shown below.

switching-filters.png

 

 

 

 

 

 

 

 

  9333   Mon Nov 4 09:03:21 2013 SteveUpdatePSLPMC auto locker

Quote:

 I was working on the electronics bench and what sounded like a huge truck rolled by outside. I didn't notice anything until now, but It looks like something became misaligned when the truck passed by (~6:45-6:50 pm). I can hear a lot of noise coming out of the control room speakers and pretty much all of the IOO plots on the wall have sharp discontinuities.

I haven't been moving around much for the past 2 hours so I don't think it was me, but I thought it was worth noting.

 The PMC auto locker is not set to acquire error message made me lock PMC manually.  Arms  locked instantly: TRY 0.9 V and TRX 0.65 V

Attachment 1: 3dTREND.png
3dTREND.png
  9334   Mon Nov 4 11:37:12 2013 SteveUpdateIOOPSL output shutter installed

 

 The PSL shutter is reinstalled.The base plate is delrin for isolation and the mount height is adjustable. The last steering mirror mount to be swapped in is ready. It is sitting on the top of the ITMX optical table cover with SS dogs.

There are two reflected spots on the north side of the Uniblitz shutter. They are coming from the vacuum window. They should be trapped also.

Attachment 1: Shutterisback.jpg
Shutterisback.jpg
  9336   Mon Nov 4 12:59:43 2013 JenneUpdateIOOMC alignment not so good after PSL output shutter installed

Quote:

  The PSL shutter is reinstalled.

 I'm not sure if Steve bumped something, or if it was just a fluke, but the MC didn't come back very nicely after Steve finished re-installing the shutter.

Earlier today, after Steve locked the PMC, MC trans looked good for over an hour (according to the striptool plot on the wall).  Then, the MC was unlocked for about an hour, presumably while Steve was working, he had the light blocked.  When he finished, the MC transmission was around 5,000 while usually it is around 17,000.  The reflection was around 3.4, rather than a best of below 0.5 (unlocked refl is 4.5).

Using Rana's ezcaservo trick to get the suspensions back to where they were at last good lock usually works (I used to do it by hand though).  However, today, it only got the reflection down to about 2.0.  So, I did the rest of the alignment by hand. 

After I did this, the reflection is down to 0.48.  Engaging the WFS makes the MC much more noisy, so I have them disabled currently. 

I have measured the spots, and if I compare them to the measurements that (I think it was Manasa) took last week, they look pretty bad. 

I think that we need to swap out the 2nd zigzag mirror, and then do a careful MC realignment.  It's certainly not worth doing the work, and then re-doing it after we swap out the zigzag mirror.

MCspots_4Nov2013.png

  9338   Mon Nov 4 15:46:17 2013 JenneUpdateLSCThoughts and Conclusions from last week's PRMI+2arms attempt

5:31pm - This is still a work in progress, but I'm going to submit so that I save my writing so far. I think I'm done writing now.


First, a transcription of some of the notes that I took last Tuesday night, then a few looks at the data, and finally some thoughts on things to investigate.


MICH and PRCL Transfer Functions while arms brought in to resonance (both arms locked to ALS beatnotes):

This is summarized in elog 9317, which I made as we were finishing up Tuesday night.  Here's the full story though.  Note that I didn't save the data for these, I just took notes (and screenshots for the 1st TF).

POP22I was ~140 counts, POP110I was ~100 counts.

MICH gain = -2.0, PRCL gain = 0.070. 

First TF (used as reference for 2-10), PRMI locked on REFL165, Xarm transmission = 0.03, Yarm transmission = 0.05 (both arms off resonance).  MICH UGF~40Hz, PRCL UGF~80Hz.

MICH_40Hz.pngPRCL_80Hz.png

2: X=off-res (xarm not moved), Y=0.13, no change in TF

3: X=off-res (xarm not moved), Y=0.35, no change in TF

4: X=off-res (xarm not moved), Y=0.60, MICH high freq gain went up a little, otherwise no change (no change in either UGF)

5:  X=off-res (xarm not moved), Y=0.95, same as TF#4.

6: X=0.20, Y=1.10 (yarm not moved), same as TF#4

7:  X=0.40, Y=1.30 (yarm not moved), same as TF#4

8:  X=0.70, Y=1.55 (yarm not moved), same as TF#4

9: X=1.40, Y=2.20 (yarm not moved), same as TF#4

10: X=4.0, Y=4.0 (yarm not moved), PRCL UGF is 10Hz higher than TF#4, MICH UGF is 20Hz lower than TF#4.

11: (No TF taken), Xarm and Yarm transmission both around 20!  To get this, MICH FMs that were triggered, are no longer triggered to turn on.  Also, MICH gain was lowered to -0.15 and PRCL gain was increased to 0.1

12: (No TF taken), Xarm and Yarm transmissions both around 40!  The peaks could be higher, but we don't have the QPD ready yet.

After that, we started moving away from resonance, but we didn't take any more transfer functions.


OpLev spectra for different arm resonance values:

We were concerned that the ETMs and ITMs might be moving more, when the arms are resonating high power, due to some optical spring / radiation pressure effects, so I took spectra of oplevs at various arm transmissions.

I titled the first file "no lock", and unfortunately I don't remember what wasn't locked.  I think, however, that nothing at all was locked.  No PRMI, no arm ALS, no nothing.  Anyhow, here's the spectrum:

ALS_noLock.pdf

I have a measurement when the Yarm's transmission was 1, and the Xarm's transmission was 1.75.  This was a PRMI lock, with ALS holding the arms partially on resonance:

ALS_X1pt75Y1.pdf

Next up, I have a measurement when Yarm was 0.8, Xarm was 2.  Again, PRMI with the arms held by ALS:

ALS_X2Y0pt8.pdf

And finally, a measurement when Xarm was 5, Yarm was 4:

ALS_X5Y4.pdf

Just so we have a "real" reference, I have just now taken a set of oplev spectra, with the ITMs, ETMs and PRM restored, but I shut the PSL shutter, so there was no light flashing around pushing on things.  I noticed, when taking this data, that if the PSL shutter was open, so the PRFPMI is flashing (but LSC is off), the PRM oplev looks much like the original "no Lock" spectra, but when I closed the shutter, the oplev looks like the others.  So, perhaps when we're getting to really high powers, the PRM is getting pushed around a bit?

ALS_noLock_noLaser.pdf

Conclusions from OpLev Spectra:  At least up to these resonances (which is, admittedly, not that much), I do not see any difference in the oplev spectra at the different buildup power levels.  What I need to do is make sure to take oplev spectra next time we do the PRMI+2arms test when the arms are resonating a lot. 


Time series while bringing arms into resonance:

PRMI_2arms_29Oct2013_POPrin.png

I had wondered if, since the POP 22 and 110 values looked so shakey, we were increasing the PRCL RIN while we brought the arms into resonance.  You can see in the above time series that that's not true.  The left side of the plot is PRMI locked, arms held out of resonance using ALS.  First the Yarm is brought close to resonance, then the Xarm follows.  The RIN of the arms is maybe increasing a little bit as we get closer to resonance, but not by that much.  But there seems to be no correlation between arm power and RIN of the power recycling cavity.

Alternatively, here is some time series when the arm powers got pretty high:

PRMI_2arms_29Oct2013_POPrin_highArmPowers.png


Possible Saturation of Signals:

One possibility for our locklosses of PRMI is that some signal somewhere is saturating, so here are some plots showing that that's not true for the error and control signals for the PRMI:

PRMI_2arms_29Oct2013_LSCcontrolSignals.png

Here, for the exact same time, is a set of time series for every optic except the SRM.  We can see that none of the signals are saturating, and I don't see any big differences for the ITMs or ETMs in the times that the PRMI is locked with high arm powers (center of the x-axis on the plot) and times that the PRMI is not locked, so we don't have high arm powers (edges of the plot - first half second, and last full second).  You can definitely see that the PRM moves much more when the PRMI is locked though, in both pitch and yaw. 

PRMI_2arms_29Oct2013_OpLevs_highArmPowers.png

DCPD signals at the same time:

PRMI_2arms_29Oct2013_DCPDs.png

NB:  These latest 3 plots were created with the getdata script, with arguments "-s 1067163405 -d 7".  It may be a good idea to take some spectra starting at, say 1067163406, 1 second in, and going for ~2 seconds. (It turns out that this is kind of a pain, and I can't convince DTT to give me a sensible spectrum of very short duration....we'll just need to do this live next time around).


Things to think about and investigate:

Why are we losing lock? 

On paper, is the (will the) optical spring a problem once we get high resonance in the arms? 

Spectra of oplevs when we're resonating high arm power.

What is the coupling between 110MHz and 165MHz on the REFL165 PD?  Do we need a stronger bandpass? 

Why are things so shakey when the arm power builds up?

Why do PRCL and MICH have different UGFs when the arms are controlled by ALS vs. ETMs misaligned?

Does QPD for arm transmissions switching work?  Can we then start using TRX and TRY for control?

What is the meaning of the similar features in both transmission signals, and the power recycling cavity?  Power fluctuation in the PRC due to PRM motion? 

  9339   Mon Nov 4 17:08:23 2013 JenneUpdateLSCThoughts on Transition to IR

Gabriele and I talked for a while on Wednesday afternoon about ideas for transitioning to IR control, from ALS. 

I think one of the baseline ideas was to use the sqrt(transmission) as an error signal.  Gabriele pointed out to me that to have a linear signal, really what we need is sqrt( [max transmission] - [current transmission] ), and this requires good knowledge of the maximum transmission that we expect.  However, we can't really measure this max transmission, since we aren't yet able to hold the arms that close to resonance.  If we get this number wrong, the error signal close to the resonance won't be very good.

Gabriele suggested maybe using just the raw transmission signal.  When we're near the half-resonance point, the transmission gives us an approximately linear signal, although it becomes totally non-linear as we get close to resonance.  Using this technique, however, requires lowering the finesse of PRCL by putting in a medium-large MICH offset, so that the PRC is lossy.  This lowering of the PRC finesse prevents the coupled-cavity linewidth of the arm to get too tiny.  Apparently this trick was very handy for Virgo when locking the PRFPMI, but it's not so clear that it will work for the DRFPMI, because the signal recycling cavity complicates things.

I need to look at, and meditate over, some Optickle simulations before I say much else about this stuff.

  9340   Mon Nov 4 18:24:15 2013 KojiUpdateLSCThoughts on Transition to IR

 You have the data. Why don't you just calculate 1/SQRT(TRX)?

...yeah, you can calculate it but of course you don't have no any reference for the true displacement...

  9341   Mon Nov 4 23:11:00 2013 JenneUpdateLSCSmall updates to LSC screen

I made some small edits to the LSC screen. 

* When I added columns for the new AS110 PD, I had forgotten to make the Trigger matrix and Power Normalization matrix icons on the screen bigger, so we weren't seeing the last 2 columns in the overview screen.

* I added "show if not zero" oscillator icons to the Sensing Matrix part of the LSC overview screen, so that it's easier at a glance to see that there is an oscillator on.

  9342   Tue Nov 5 00:39:43 2013 manasaUpdateIOOIFO alignment tuning

Information acknowledged from Steve:

The last steering mirror mount for IR on the PSL was swapped for a more robust one. Prior to swapping the ibeam positions on the PSL IOO QPDS in ang and pos were recorded.

What I did henceforth:

1. Once the last steering mirror was installed, I walked the beam to restore input pointing using the last 2 steering mirrors. It needed a lot of work in yaw as expected.

2. When the input pointing was recovered, MC locked right away in TEM00. I measured the MC spot positions and compared it with Jenne's measurement made prior to the swap. The spot positions were pretty close.

3. The input pointing was adjusted in pitch and yaw (on the last steering mirror) in small steps. MC alignment was recovered and spot positions were measured each time. After several iterations, the MC spot positions were pretty much centered. I recentered the WFS and reset the WFS offsets. MC is now locked with WFS enabled at ~16900 counts.

MC_spot.png

4. Since the arms were aligned this morning, I used the Y arm as reference and corrected for the input pointing using tip-tilts.

5. Arms locked right away. Note: ASS doesn't seem to be doing it's job. I had to manually align the arms for maximum on TRX and TRY.

6. MICH and PRMI lock were also recovered.

7. I started to check the status with ALS as well. But for reasons unknown, I don't see any ADC counts corresponding to the beat note. Looking at the beatbox there aren't any signs of disconnected cables.  I am saving this as a morning job to fix it.

  9343   Tue Nov 5 08:44:21 2013 SteveUpdateIOOafter last steering mirror mount swap

 The IOO Angle and IOO Position qpds  were recentered after this entry.

 Suggested corrections in elog entry #9323 are completed:

 1,  last steering mirror mount replaced by Polanski mount

 2,  PSL output shutter mount reconfigured

 IOO qpds are not centered. I failed to connect laptops to 40MARSian network.

Attachment 1: after_Shutter_SMm_installed.png
after_Shutter_SMm_installed.png
Attachment 2: afterlastSMmountswap.jpg
afterlastSMmountswap.jpg
  9344   Tue Nov 5 16:39:54 2013 GabrieleUpdateLSCThoughts on Transition to IR

Quote:

Gabriele and I talked for a while on Wednesday afternoon about ideas for transitioning to IR control, from ALS. 

I think one of the baseline ideas was to use the sqrt(transmission) as an error signal.  Gabriele pointed out to me that to have a linear signal, really what we need is sqrt( [max transmission] - [current transmission] ), and this requires good knowledge of the maximum transmission that we expect.  However, we can't really measure this max transmission, since we aren't yet able to hold the arms that close to resonance.  If we get this number wrong, the error signal close to the resonance won't be very good.

Gabriele suggested maybe using just the raw transmission signal.  When we're near the half-resonance point, the transmission gives us an approximately linear signal, although it becomes totally non-linear as we get close to resonance.  Using this technique, however, requires lowering the finesse of PRCL by putting in a medium-large MICH offset, so that the PRC is lossy.  This lowering of the PRC finesse prevents the coupled-cavity linewidth of the arm to get too tiny.  Apparently this trick was very handy for Virgo when locking the PRFPMI, but it's not so clear that it will work for the DRFPMI, because the signal recycling cavity complicates things.

I need to look at, and meditate over, some Optickle simulations before I say much else about this stuff.

 The idea of introducing a large MICH offset to reduce the PRC finesse might help us to get rid of the transmitted power signal. We might be able to increase enough the line width of the double cavity to make it larger than the ASL length fluctuations. Then we can switch from ASL to the IR demodulated signal without transitioning through the power signal.

  9345   Tue Nov 5 16:47:09 2013 JenneUpdateLSCEnd transmission QPDs

I think Steve is trying to align the end transmission QPDs, since the arms are locked nicely right now.  I noticed that the QPDX pitch and yaw signals were digital zeros.  A quick look determined that the QPDX matrix to go from 4 quadrants to 3 degrees of freedom had been filled in for the POS row, but not pitch and yaw.  So, I copied the QPDY matrix over to QPDX (so the ordering of the rows and columns is assumed to be the same). 

Hopefully this will get us close to centered, but I suppose we ought to check really which quadrant is which, by shining a laser pointer at each quad at each end.

  9347   Tue Nov 5 17:12:34 2013 SteveUpdateLSCcentered qpds

 Full list tomorrow: IP-Ang & Pos, ETMY-T, ETMY-Oplev, ETMX-T, IOO-Ang & Pos

 RA: No one in the control room this evening can understand what this ELOG means. Please use more words.

Attachment 1: recentered.png
recentered.png
  9349   Tue Nov 5 19:39:27 2013 JenneUpdateLSCOpLev time series

[Rana, Jenne]

We looked at the time series for all the oplevs except the BS, from last Tuesday night, during a time when we were building up the power in the arms.  We conclude from a 400 second stretch of data that there is not discernible difference in the amount of motion of any optic, when the cavities are at medium power, and when they're at low power.  Note however, that we don't have such a nice stretch of data for the really high powers, so the maximum arm power in these plots is around 5.  Both the TRX and TRY signals look fairly stationary up to powers of 1 or 2, but once you get to 4 or 5, the power fluctuations are much more significant.  So, since this isn't caused by any optic moving more, perhaps it's just that we're more sensitive to optic motion when we're closer to resonance in the arms.

However, from this plot, it looks like the ETMY is moving much more than any other optic.  On the other hand, ETMY has not ever been calibrated (there's an arbitrary 300 in there for the calibration numbers on the ETMY oplev screen).  So, perhaps it's not actually moving any more than other optics.  We should calibrate the ETM oplevs nicely, so we have some real numbers in there.  ETMX also only is roughly calibrated, relative to the OSEMs.  We should either do the move-the-QPD calibration, or a Kakeru-style pitch and yaw some mirrors and look at transmitted power.

Traces on this xml file have been filtered with DTT, using zpk([0],[0.03],1,"n").

OpLevs_during_PRMI_2arms.pdf

 

  9350   Tue Nov 5 19:50:07 2013 manasaUpdateElectronicsIOO rack +/-5V power supplies

The power supply to the ADC box on the IOO rack (that reads the beat I & Q signals) was pulled out because it did not run through any fuse and was connected directly to the power supply. 

There were already connections running from the +/-5 V power supply. They were powering the mode cleaner demod board rack. In order to remove the ADC power connectors from the power supply, I notified Jenne in the control room because turning off the power supply would affect the MC. I switched off the +/-5V power supplies at the same time. The ADC power connectors were removed. The +/-5V power supplies were then turned ON again at the same time. Jenne relocked the MC after this.

I have still not connected the ADC to the fuse rack power supply because this requires the +/-5V power supplies to be turned OFF again in order to pull out new connections from the fuse rack and I need to make a new ADC power connector with thicker wires.

  9351   Tue Nov 5 19:55:12 2013 ranaUpdateSUSoplev XY-plots reflect new calibration

I used the same OSEM SUSPIT/YAW method as before to calibrate the ETMY optical lever signals. They were off by a factor of ~10.

ETMY Pitch     300  /  26    (old/new)     urad/counts

ETMY Yaw       300  /  31    (old/new)     urad/counts

These should be redone with the Kakeru / Ottaway arm cavity power technique if we want to get better than ~30% accuracy.

  9352   Wed Nov 6 08:33:53 2013 SteveUpdateIOOPoiting changes of PSL

Quote:

 Full list tomorrow: IP-Ang & Pos, ETMY-T, ETMY-Oplev, ETMX-T, IOO-Ang & Pos

 RA: No one in the control room this evening can understand what this ELOG means. Please use more words.

 Yesterday the last steering mirror mount on the PSL was changed, Manasa recovered the MC alignment and Jenne locked the arms.

 I centered the following qpds:  ASC-IBQPD, LSC-TRY, SUS-ETMY_OPLEV, LSC-TRX, SUS_ETMX_OPLEV

 Touching the PSL pointing IOO-QPD_ANG & POS was a mistake. We lost the reference of the well refined MC input.

 

One and 20 days TRENDS  plot showing the PSL output drift in pitch can be power drop

However initial pointing is amazingly good. ( I wonder about the lens in front of the qpd ?)

Attachment 1: 1dayTRENDofPOITING.png
1dayTRENDofPOITING.png
Attachment 2: 20dayTRENDioo.png
20dayTRENDioo.png
  9354   Wed Nov 6 15:12:01 2013 JenneUpdateCDSFB not talking to LSC?

Something funny is going on with the framebuilder's communication with the LSC machine. 

This is a different failure mode / error than I have seen before.  It's not the type of problem that is solved by restarting the mxstreams (that is indicated by also the 2 blocks on top of one another, that are green on the lsc machine right now, being red), although I did try that, before I looked closer and realized that that wasn't the problem.

ssh-ing to c1lsc, and doing a "rtcds restart all" seems to be fixing the problem.  Both c1oaf and c1cal needed another round of restarting, because they needed their BURT buttons pressed manually.  All of the models on the lsc machine are running fine now, though.

Here's a screenshot of the CDS overview screen, with the error lights:

Screenshot-Untitled_Window-1.png

  9355   Wed Nov 6 15:57:22 2013 JenneUpdateLSCPower Supply solution

We have decided that, rather than replacing the power source for the amplifiers that are on the rack, and leaving the Thorlabs PD as POP22/110, we will remove all of the temporary elements, and put in something more permanent.

So, I have taken the broadband PDs from Zach's Gyro experiment in the ATF.  We will figure out what needs to be done to modify these to notch out unwanted frequencies, and amplify the signal nicely.  We will also create a pair of cables - one for power from the LSC rack, and one for signal back to the LSC rack.  Then we'll swap out the currently installed Thorlabs PD and replace it with a broadband PD.

  9356   Wed Nov 6 15:59:41 2013 manasaUpdateElectronicsIOO rack +/-5V power supplies

Quote:

The power supply to the ADC box on the IOO rack (that reads the beat I & Q signals) was pulled out because it did not run through any fuse and was connected directly to the power supply. 

There were already connections running from the +/-5 V power supply. They were powering the mode cleaner demod board rack. In order to remove the ADC power connectors from the power supply, I notified Jenne in the control room because turning off the power supply would affect the MC. I switched off the +/-5V power supplies at the same time. The ADC power connectors were removed. The +/-5V power supplies were then turned ON again at the same time. Jenne relocked the MC after this.

I have still not connected the ADC to the fuse rack power supply because this requires the +/-5V power supplies to be turned OFF again in order to pull out new connections from the fuse rack and I need to make a new ADC power connector with thicker wires.

I switched OFF the +/-5V power supplies on the IOO rack to hook up the ADC power connectors through 250mA fuses to +/-5V. Since these power supplies were powering the MC demod boards, MC remained unlocked during the process. I turned the power supplies back ON and MC relocked itself after this.

  9357   Wed Nov 6 17:21:58 2013 JamitUpdateCDSFB not talking to LSC?

Quote:

Something funny is going on with the framebuilder's communication with the LSC machine. 

This is a different failure mode / error than I have seen before.  It's not the type of problem that is solved by restarting the mxstreams (that is indicated by also the 2 blocks on top of one another, that are green on the lsc machine right now, being red), although I did try that, before I looked closer and realized that that wasn't the problem.

ssh-ing to c1lsc, and doing a "rtcds restart all" seems to be fixing the problem.  Both c1oaf and c1cal needed another round of restarting, because they needed their BURT buttons pressed manually.  All of the models on the lsc machine are running fine now, though.

Here's a screenshot of the CDS overview screen, with the error lights:

Screenshot-Untitled_Window-1.png

This definitely looks like a timing problem on the c1lsc front end computer.  The red lights on the left mean that the timing synchronization is lost at the user model.  I'm perplexed why it looks like the IOP is not seeing the same error, though, since it should originate at the ADC.  The red lights to the right just mean the timing synchronization is lost with the DAQ, which is too be expected given a timing loss at the front end.

We'll have to take a closer look when this happens again.

  9358   Thu Nov 7 08:57:20 2013 SteveUpdateIOOPSL pointing monitoring

 The qpd sees the power drop as position change.

The laser  monitoring screen shows little changes of the Innolight 2W output. See elog 9292 to compare

So why does the PMC downgrade if the laser output is stationary ?

The PMC-T power is down to 0.75V  The auto locker does maximize power output.

It needs a manual alignment touch up.

 

 

Attachment 1: PMC11072013.jpg
PMC11072013.jpg
Attachment 2: PMCTqpdMon.png
PMCTqpdMon.png
  9359   Thu Nov 7 11:19:04 2013 SteveUpdateVACcrane work POSTPONED to Monday

Quote:

 

The smoke alarms were turned off and surrounding areas were covered with plastic.

The folding I-beam was ground down to be in level with the main beam.

Load bearing cable moved into correct position. New folding spring installed.

Crane calibration was done at 500 lbs at the end of the fully extended jib.

Than we realized that the rotating wheel limit switch stopped working.

This means that the crane is still out of order.

 

 New limit switch will be installed tomorrow morning

Konecranes postponed installation Friday morning Nov. 8

Friday 5pm : Konacranes promising to be here 8am Monday, Nov 11

It was rescheduled on Tuesday again for Wednesday, Nov 13

  9360   Thu Nov 7 14:39:49 2013 JenneUpdateLSCLock Acquisition Game Plan

Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan. 

From those talks, here is my current understanding of the plan, in a Ward-style cartoon:

 LockAcquisition_7Nov2013.pdf(This is a 2 page document - description of steps is on 2nd page)

If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using.  To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.

Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.


There are several things at this point that we know we need to look into:

* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)

* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)

* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)

* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports?  Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier?  (Simulation)

* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)

* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases.  If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash.  (Simulation)

* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be.  If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI?  We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined).  (Simulation)

* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)

* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)

* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion?  PRM angular motion? ALS noise?) (Calculation)


Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon. 

  9361   Fri Nov 8 17:19:27 2013 JenneUpdateLSCNew Broadband PD for POP 22/110

Here is a photo of the board inside the broadband photodiode (one of them) that I took from the Gyro experiment:

IMG_1255.JPG

This PD is Serial Number S1200271.

We need to have a look at the schematic, figure out what's in here now, and then modify this to be useful (appropriate resonances / notches, as well as amplification) for POP 22/110.

  9362   Fri Nov 8 18:12:21 2013 JenneUpdateLSCPRFPMI: Not crossing any resonances

Quote:

There are several things at this point that we know we need to look into:

* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be.  If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI?  We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined).  (Simulation)

 I have done a sweep of CARM, while looking at the fields inside of one arm (I've chosen the Xarm), to see where any resonances might be, that could be causing us trouble in keeping the PRMI locked as we bring the arms into resonance. 

2f_resonances_Xarm_CARMsweep.png

Since Gabriele pointed out to me that we're using the 3x55MHz signal for locking, we should be most concerned about resonances of the higher orders of 55, and not of 11.  So, on this plot, I have up to the 6th order 55 MHz sidebands, which are 332 MHz.  Although the Matlab default color chart has wrapped around, it's clear that the carrier is the carrier, and the +4f2, which is the same blue, is not the giant central peak.  So, it's kind of clear which trace is which, even though the legend colors are degenerate.  Also, the main point that I want to show here is that there is nothing going on near the carrier, with any relevant amplitude.  The nearest things are the plus and minus 55 MHz sidebands themselves, and they're more than 50 nm away from the carrier. 

Recalling from elog 9122, the PRFPMI and DRFPMI linewidths are about 40pm.  50pm away from the resonant point is ~1/10 the power, and 100pm away from the resonant point is ~1/100 the power.  So, 50 nm is a looooong ways away. 

Just for kicks, here is a plot of all the resonances of the 1f and 2f modulation frequencies, up to 30*f1, which is the same 6*f2:

AllModFreq_resonances_Xarm_CARMsweep.png

The resonances which are "close" to the carrier are the 9th order 11 MHz sidebands, and they're 280pm from the carrier, so twice as far as we need to be, to get our arm powers to ~1/100 of the maximum, and, they're a factor of ~1e4 smaller than the carrier.

  9363   Sat Nov 9 10:25:43 2013 KojiUpdateLSCNew Broadband PD for POP 22/110

General Remarks on the BBPD

- To form the LC network: Use fixed SMD inductors from Coilcraft. SMD tunable capacitors are found in the shelf right next to Steve's desk.
  If the tuning is too coarse, combine an appropriate fixed ceramic SMC C and the tunable C (in parallel, of course)

- L1/C1a/C1b pads are specifically designed for an additional notch

- Another notch at the diode stage can be formed between the middle PD pin (just left of the marking "C3b") to the large GND pad (between C1a/C1b to C3a).
  You have to scratch off the green resin with a small flat screw driver (or anything similar)

- A notch at the amplifier stage can be formed between the output of MAR-6SM ("+" marking)  and one of the GND pads (left side of the "U1" marking)

- The original design of the PD is broadband. So additional notches on the diode stage provides notches and resonances.
  Check if the resonances do not hit the signal frequencies.

- One would think the PD can have resonant feature to reduce the coupling of the undesired signals.
  In some sense it is possible but it will be different from the usual resonant tank circuit in the following two points.

  * Just adding a parallel L between the cathode and ground does not work. As this DC current should be directed to the DC path,
    L&C combo should be added. In fact this actually give a notch-resonance pair. This C should be big enough so that you can ignore it
    at the target resonant frequency. Supply complimentary small C if necessary to keep low impedance of the Cs at the target frequency.
    (i.e. Check SRF - self-resonant frequency of the big C)

  * Since the input impedance of MAR-6SM is 50Ohm, the top of the resonant curve will be cut at 50Ohm. So the resultant shape looks
    like a bandpass rather than a resonance.

- So in total, simulation of the circuit is very important to shape the transimpedance. And, consider the circuit can not be formed as simulated
  because of many practical imperfections like stray Ls and Cs.

 

  9364   Mon Nov 11 12:19:36 2013 ranaUpdateCDSFE Web view was fixed

Quote:

FE Web view was broken for a long time. It was fixed now.

The problem was that path names were not fixed when we moved the models from the old local place to the SVN structure.

The auto updating script (/cvs/cds/rtcds/caltech/c1/scripts/AutoUpdate/update_webview.cron) is running on Mafalda.

Link to the web view: https://nodus.ligo.caltech.edu:30889/FE/

 Seems partially broken again. Not updating for most of the FE. I've commented out the cron lines for this as well as the mostly broken MEDM Snapshots job. I'm in the process of adding them to the megatron cron (since that machine is at least running 64 bit Ubuntu 12, instead of 32-bit CentOS)

  9365   Mon Nov 11 22:35:45 2013 RANAUpdateIOOPSL pointing monitoring

Since the pointing has gone bad again, I went to the PSL to investigate. Found some bad things and removed them:

1) There was a stopped down iris AGAIN in the main beam path, after the newly installed mirror mount. I opened it. Stop closing irises in the beam path.

2) The beam dump for the IOO QPD reflection was just some black aluminum. That is not a real dump. I removed it. We need two razor blade dumps for this.

3) There was an ND filter wheel (???) after one of the PMC steering mirrors. This is not good noise / optics practice. I removed it and dumped the beam in a real dump. No elog about this ?!#?

 

The attached trend shows the last 20 days. The big step ~2 weeks ago is when Steve replaced the steering mirror mount with the steel one. I don't understand the drift that comes after that.

 

Today I also spent ~1 hour repairing the Aldabella laptop. Whoever moved it from the PSL area to the SP table seems to have corrupted the disk by improper shutdown. Please stop shutting the lid and disconnecting it from the AC power unless you want to be fixing it. Its now running in some recovery mode. Lets leave it where it is next to the PSL and MC1.

I steered the MC suspensions back to where they were on the trends before the PSL mirror mount swap and then aligned the PSL beam into it by touching the last 2 steel mounts. Once the alignment was good without WFS, I centered the beams on the IOO QPDs. If it behaves good overnight, I will center the unlocked beams on the MC WFS.

 

Please stay off the PSL for a couple days if you can so that we can watch the drift. This means no opening the doors, turning on the lights, or heavy work around there.

Attachment 1: qpd.pdf
qpd.pdf
  9366   Tue Nov 12 15:04:35 2013 ranaUpdateCDSFE Web view was fixed

Quote:

 Seems partially broken again. Not updating for most of the FE. I've commented out the cron lines for this as well as the mostly broken MEDM Snapshots job. I'm in the process of adding them to the megatron cron (since that machine is at least running 64 bit Ubuntu 12, instead of 32-bit CentOS)

 https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

Seems to now be working. I made several fixes to the scripts to get it working again:

  1. changed TCSH scripts to BASH. Used /usr/bin/env to find bash.
  2. fixed stdout and stderr redirection so that we could see all error messages.
  3. made the PERL scripts executable. most of the PERL errors are not being logged yet.
  4. fixed paths for the MEDM screens to point to the right directories.
  5. the screen cap only works on screens which pop open on the left monitor, so I edited the screens so that they open up there by default.
  6. moved the CRON jobs from mafalda over to megatron. Mafalda no longer is running any crons.
  7. op540m used to run the 3 projector StripTool displays and have its screen dumped for this web page. Now zita is doing it, but I don't know how to make zita dump her screen.
  9367   Tue Nov 12 16:49:22 2013 JenneUpdateLSCXend QPD and Whitening board pulled

Quote:

* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)

 I have the X end transmission QPD, as well as the whitening board, out on the electronics bench.  Since the Thorlabs high-gain TRX PD also goes through this whitening board, we have no transmission signal for the Xarm at this time. The whitening board was in the left-most slot, of the top crate in the Xend rack.  The only cables that exist for it (like the Yend), are the ribbon from the QPD, the 4-pin lemo from the Thorlabs PD, and the ribbon going to the ADC.

I have taken photos, and want to make sure that I know what is going on on the circuits, before I put them back in. 

The QPD:

IMG_1262.JPG

IMG_1260.JPG

The whitening board:

IMG_1264.JPG

IMG_1276.JPG

  9368   Tue Nov 12 21:50:01 2013 ranaUpdate zita network configured

 

 I installed 'nfs-client' on zita (the StripTool terminal). It now has mounted all the shared disks, but still can't do StripTool since its a 32-bit machine and our StripTool is 64.

  9369   Tue Nov 12 23:05:06 2013 ranaUpdatePEMthump noise from particle counter

Quote:
The particle counter is back on the IOOC location on a piece of FOAM
It needs this isolation, so when the pump is running, it's not shaking things.
The counter was counting for 6 sec and it was on holding for 20 mins.
Now I set the counter for 20 sec so it is easy to recognise it's signal and it holds for 2min only.
This will set the alarm handler in action.

Atm1: 40 mins plot
PEM-ACC_MC2_x,y,z up to 13 mins: pcounter at MC2 table, clamped, counting for 20s and holds for 2 mins
PEM-ACC_MC2_x,y,z from 13 to 26 mins: pcounter at MC2 table, not clamped, seated on 2" foam, counting 20s and holds for 2 mins
PEM-ACC_MC1_x,y,z from 26 to 40 mins: pcounter at MC1_IOOC location, not clamped, seated on 2" foam, counting 20s and holds for 2 mins

Rana won the bet

This noise source from 2008 is back. Somehow the particle counter snuck back up to the top of the BS chamber. Bad, noisy particle counter. Let's move it away from out sensitive optics and put it on the wall next to the router or maybe on some toolbox. Not on optics tables, chambers, or near them.
  9370   Tue Nov 12 23:48:23 2013 RANAUpdateIOOPSL pointing monitoring

Since I saw that the trend was good, I aligned the MC refl path to the existing IMC alignment:

  1. removed a broken IRIS that was clipping the reflected beam (and its mount)
  2. moved the first 1" diameter steering mirror on the high power path after the 2" diameter R=10% steering mirror. It was not centered.
  3. Moved the lens just upstream of the LSC RFPD away from the PD by ~5 mm. The beam going towards the WFS was too close to this mount and I could see some glow.
  4. Centered the beam on all optics in the WFS path and then the WFS DC.
  5. Centered beam on LSC RFPD.

The reflected spots from the PD are not hitting the dump correctly. WE need to machine a shorter post to lower the dump by ~1 cm to catch the beams.

  9371   Wed Nov 13 01:35:40 2013 JenneUpdateLSCPRM motion causing trouble?

Quote:

* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion?  PRM angular motion? ALS noise?) (Calculation)

 I think that our problem of seeing significant arm power fluctuations while we bring the arms into resonance during PRMI+arms tests is coming from PRM motion. I've done 3 calculations, so I will describe below why I think the first two are not the culprit, and then why I think the PRM motion is our dominant problem.

===============================================================

ALS length fluctuations

Arm length fluctuations seem not to be a huge problem for us right now, in terms of what is causing our arm power fluctuations.

What I have done is to calculate the derivative of the power in the arm cavity, using the power buildup that optickle gives me. The interferometer configuration I'm using is PRFPMI, and I'm doing a CARM sweep. Then, I look at the power in one arm cavity. The derivative gives me Watts buildup per meter CARM motion, at various CARM offsets. Then, I multiply the derivative by 60 nm, which is my memory of the latest good rms motion of the ALS system here at the 40m. I finally divide by the carrier buildup in the arm at each offset, to give me an approximation of the RIN at any CARM offset.

I don't know exactly what the calibration is for our ALS offset counts, but since we are not seeing maximum arm cavity buildup yet, we aren't very close to zero CARM offset. 

From this plot, I conclude that we have to be quite close to zero offset for arm length fluctuations to explain the large arm power fluctuations we have been seeing.

 xarmRIN_vs_CARM.png

=======================================================================

AS port contrast defect from ETM motion

For this calculation, I considered how much AS port contrast defect we might expect to see given some ETM motion. From that, I considered what the effect would be on the power recycling buildup. 

Rather than doing the integrals out, I ended up doing a numerical analysis. I created 2 Gaussian beams, subtracted the fields, then calculated the total power left. I did this for several separations of the beams to get a plot of contrast defect vs. separation. My simulated Gaussian beams have a FWHM of 1 unit, so the x-axis of the plot below is in units of spot motion normalized by spot size. 

Unfortunately, my normalization isn't perfect, so 2 perfectly constructively interfering beams have a total power of 0.3, so my y-axis should all be divided by 0.3. 

The actual beam separation that we might expect at the AS port from some ETM motion (of order 1e-6 radians) causing some beam axis shift is of the order 1e-5 meters, while the beam spot size is of the order 1e-3 meters. So, in normalized units, that's about 1e-2. I probably should change the x-axis to log as well, but you can see that the contrast defect for that size beam separation is very small. To make a significant difference in the power recycling cavity gain, the contrast defect, which is the Michelson transmission, should be close to the transmission of the PRM. Since that's not true, I conclude that ETM angular motion leading to PRC losses is not an issue. 

I still haven't calculated the effect of ITM motion, nor have I calculated either test mass' angular effect directly on arm cavity power loss, so those are yet to be done, although I suspect that they aren't our problem either. 

ASportOverlap_moveGaussianBeams.png

========================================================================

PRM motion

 

I think that the PRM moving around, thus causing a loss in recycling gain, is our major problem. 

First, how do I conclude that, then some thoughts on why the PRM is moving at all. 

=========

theta = 12e-6 radians (ref: oplev plot from elog 9338 last week)

L = 6.781 meters

g = 0.94

a = theta * L /(1-g) = 0.0014 meters axis displacement

w0 = 3e-3 meters = spot size at ITM

a^2/w0^2 = 0.204 ==>> 20% power loss into higher order modes due to PRM motion.

That means 20% less power circulating, hitting the ITMs, so less power going into the arm cavities, so less power buildup. This isn't 50%, but it is fairly substantial, using angular fluctuation numbers that we saw during our PRMI+arms test last week. If you look at the oplev plot from that test, you will notice that when the arm power is high (as is POP), the PRM moves significantly more than when the carrier buildup in the cavities was low. The rms motion is not 12 urad, but the peak-to-peak motion can occasionally be that large. 

So, why is that? Rana and I had a look, and it is clear that there is a difference in PRM motion when the IFO is aligned and flashing, versus aligned, but PSL shutter is closed. Written the cavities flash, the PRM gets a kick. Our current theory is that some scattered light in the PRC or the BS chamber is getting into the PRM's OSEMs, causing a spike in their error signal, and this causes the damping loops to push on the optic. 

We should think a little more on why the PRM is moving so much more that any other optic while the power is building up, and if there is anything we can do about the situation without venting. If we have to, we should consider putting aluminum foil beam blocks to protect the PRM's OSEMs. 

  9372   Wed Nov 13 08:46:03 2013 SteveUpdateVACvertex crane repair completed

nullQuote:

 

The smoke alarms were turned off and surrounding areas were covered with plastic.

The folding I-beam was ground down to be in level with the main beam.

Load bearing cable moved into correct position. New folding spring installed.

Crane calibration was done at 500 lbs at the end of the fully extended jib.

Than we realized that the rotating wheel limit switch stopped working.

This means that the crane is still out of order.

 

New limit switch installed and tested. The crane is back in full operational mode. Two spare limit switches on hand.

  9373   Wed Nov 13 09:31:15 2013 GabrieleUpdateLSCPRM motion causing trouble?

Interesting results. When you compute the effect of ETM motion, you maybe should also consider that moving around the arm cavity axis changes the matching of the input beam with the cavity, and thus the coupling between PRC and arms. But I believe this effect is of the same order of the one you computed, so maybe there is only one or two factors of two to add. This do not change significantly the conclusion.

Instead, the numbers you're giving for PRM motion are interesting. Since I almost never believe computations before I see that an experiment agrees with them, I suggest that you try to prove experimentally your statement. The simplest way is to use a scatter plot as I suggested the past week: you plot the carrier arm power vs PRM optical lever signals in a scatter plot. If there is no correlation between the two motions, you should see a round fuzzy ball in the plot. Otherwise, you will se some non trivial shape. Here is an example: https://tds.ego-gw.it/itf/osl_virgo/index.php?callRep=18918

 

  9374   Wed Nov 13 11:30:07 2013 SteveUpdatePEM particle counter MOVED
Particle counter moved from the top of IOOC to the east wall
Attachment 1: Met1Moved.JPG
Met1Moved.JPG
  9375   Wed Nov 13 18:02:08 2013 JenneUpdateCDSCan't talk to AUXEY?

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

  9376   Wed Nov 13 18:32:04 2013 Nic, EvanUpdateISSSR560 ISS loop

We have implemented an SR560-based ISS loop using the AOM on the PSL table. This is a continuation of the work in 40m:9328.

We dumped the diffracted beam from the AOM onto a stack of razor blades. This beam is not terribly well separated from the main beam, so the razor blades are at a very severe angle. Any alternatives would have involved either moving the AOM or attempting to dump the diffracted beam somewhere on the PMC refl path. We trimmed the RF power potentiometer on the driver so that with 0.5 V dc applied to the AM input, about 10% of the power is diverted from the main beam.

We ran the PMC trans PD into an AC-coupled SR560. To shape the loop, we set SR560 to have a single-pole low- pass at 300 Hz and an overall gain of 5×104. We take the 600 Ω output and send it into a 50 Ω feed-through terminator; this attenuates the voltage by a factor of 10 or so and thereby ensures that the AOM driver is not overdriven.

The AOM driver's AM input accepts 0 to 1 V, so we add an offset to bias the control signal. The output of the 50 Ω feedthrough is sent into the 'A' input of a second SR560 (DC coupled, A − B setting, gain 1, no filtering). Using a DS345 function generator, a 500 mV offset is put into the 'B' input (the function generator reads −0.250 V because it expects 50 Ω input). The 50 Ω output of this SR560 is sent into the AOM driver's AM input.

A measurement of suppressed and unsuppressed RIN is attached. We have achieved a loop with a bandwidth of a few kilohertz and with an in-loop noise suppression factor of 50 from 100 Hz to 1 kHz. This measurement was done using the PMC trans PD, so this spectrum may underestimate the true RIN.

Attachment 1: psl_aom_overhead.jpg
psl_aom_overhead.jpg
Attachment 2: aom_driver.jpg
aom_driver.jpg
Attachment 3: loop_on_settings.jpg
loop_on_settings.jpg
Attachment 4: fxn_gen.jpg
fxn_gen.jpg
Attachment 5: 40m_iss.pdf
40m_iss.pdf
  9378   Wed Nov 13 19:22:58 2013 JenneUpdateLSCPRM motion correlated to intracavity power

[Gabriele, Jenne]

Nic and Evan put the ISS together (elog 9376), and we used an injection into the error point (?) to modulate the laser power before the PMC (The AOM had a bias offset, but there is no loop).  This gives us some RIN, that we can try to correlate with the PRM OSEM sensors. 

We injected several lines, around 100, 200, 500 and 800 Hz.  For 100, 200 and 800 Hz lines, we see a ratio between POPDC and the OSEM sensors of 1e-4, but at 500 Hz, the ratio was more like 1e-3. We're not sure why this ratio difference exists, but it does.  These ratios were true for the 4 face OSEMs.  The side OSEM saw a slightly smaller signal.  

For these measurements, the PRMI was sideband locked, and we were driving the AOM with an amplitude of 10,000 counts (I don't know what the calibration is between counts and actual drive, which is why we're looking at the POPDC to sensor *ratio*).  

To get a more precise number, we may want to consider locking the PRMI on carrier, so we have more power in the cavity, and so more signal in the OSEMs.  

These ratios look, by eye, similar to the ratios we see from the time back on 30 Oct when we were doing the PRMI+2arms test, and the arms were resonating about 50 units.  So, that is nice to see some consistency.

AOMmodulated_POPDC_OSEM.pdf

This time series is from 1067163395 + 27 seconds, from 30 Oct 2013 when we did the PRMI+2arms.

POPDC_sensors_30oct2013.png

 


Ideas to go forward:

We should think about chopping the OSEM LEDs, and demodulating the PD sensors. 

We should also take a look in the chamber with a camera from the viewport on the north side of the BS chamber, to see if we see any flashes in the chamber that could be going into the OSEMs, to see where we should maybe put aluminum foil shields.

  9379   Wed Nov 13 19:41:55 2013 JenneUpdateISSISS AOM

AOM driving from DAC:

I found that the DAC channels for TT3 and TT4 are connected up in the simulink model, but we aren't using them, since we don't actually have those tip tilts installed.  So, we hooked up the TT4 LR DAC output, which is channel 8 on the 2nd set of SMA outputs.  We put our AOM excitations into TT4_LR_EXC.

 

  9380   Wed Nov 13 20:02:12 2013 Nic, EvanUpdateISSSR560 ISS loop

Quote:

We have implemented an SR560-based ISS loop using the AOM on the PSL table. This is a continuation of the work in 40m:9328.

We dumped the diffracted beam from the AOM onto a stack of razor blades. This beam is not terribly well separated from the main beam, so the razor blades are at a very severe angle. Any alternatives would have involved either moving the AOM or attempting to dump the diffracted beam somewhere on the PMC refl path. We trimmed the RF power potentiometer on the driver so that with 0.5 V dc applied to the AM input, about 10% of the power is diverted from the main beam.

We ran the PMC trans PD into an AC-coupled SR560. To shape the loop, we set SR560 to have a single-pole low- pass at 300 Hz and an overall gain of 5×104. We take the 600 Ω output and send it into a 50 Ω feed-through terminator; this attenuates the voltage by a factor of 10 or so and thereby ensures that the AOM driver is not overdriven.

The AOM driver's AM input accepts 0 to 1 V, so we add an offset to bias the control signal. The output of the 50 Ω feedthrough is sent into the 'A' input of a second SR560 (DC coupled, A − B setting, gain 1, no filtering). Using a DS345 function generator, a 500 mV offset is put into the 'B' input (the function generator reads −0.250 V because it expects 50 Ω input). The 50 Ω output of this SR560 is sent into the AOM driver's AM input.

A measurement of suppressed and unsuppressed RIN is attached. We have achieved a loop with a bandwidth of a few kilohertz and with an in-loop noise suppression factor of 50 from 100 Hz to 1 kHz. This measurement was done using the PMC trans PD, so this spectrum may underestimate the true RIN.

 A small followup measurement. Here are spectra of the MC trans diode with and without the ISS on. The DC value of the diode (in counts) changed from 17264.2 (no ISS) to 17504.3 (with ISS), but I didn't account for this change in the plot.

There is a small inkling of benefit between 100Hz and 1kHz. Above about 100Hz, the RIN is suppressed to about the noise level of this measurement. Below 100Hz there is no change, which probably means that power fluctuations are introduced downstream of the AOM, which argues for an outer-loop ISS down the road.

Atm #2 is in units of RIN.

Attachment 1: ISS_560_rot.pdf
ISS_560_rot.pdf
Attachment 2: ISS_560cal.pdf
ISS_560cal.pdf
  9382   Thu Nov 14 02:50:43 2013 JenneUpdateLSCPRM oplev measured and modeled TF

In the process of figuring out what we can do to fix our PRM motion problem, I am looking at the PRM oplev. 

Eventually (as in, tomorrow), I'd like to be able to simulate some optic motion as a result of an impulse, and see what the oplev loops do to that motion.  (For starters, I'll take the impulse response of the OSEM loop as my time series that the oplev loop sees).

One thing that I have done is look at the oplev model that Rana put together, which is now in the noisebudget svn: /ligo/svncommon/NbSVN/aligonoisebudget/trunk/OpLev/C1

This script plots the open loop gain of the modeled oplev:

PRM_OL_TF_model.png

This should be compared to the pitch and yaw measured transfer functions:

 PRM_OLPIT_TF.pdf

PRM_OLYAW_TF.pdf

In the YAW plot, there are 2 transfer functions.  The first time around, the UGF was ~2.5Hz, which is too low, so I increased the gain in the C1:SUS-PRM_OLYAW filter bank from -3 to -9. 

The shapes of the measured and modeled transfer functions look reasonably similar, but I haven't done a plot overlay.  I suspect that the reason I don't see the same height peak as in the model is just that I'm not taking a huge number of points.  However, if the other parts of the TF line up, I'll assume that that's okay.

I want to make sure that the modeled transfer function matches the measured ones, so that I know I can trust the model.  Then, I'll figure out how to use the time series data with the simulated loop.  Ideally, I'd like to see that the oplev loop can fully squish the motion from the OSEM kicks.  Once I get something that looks good (by hand-tweaking the filter shape), I'll give it a try in the actual system.  We should, as soon as I get the optimal stuff working, redo this in a more optimal way.  Both now, and after I get an optimal design, I'll look at the actual step and impulse responses of the loop, to make sure there aren't any hidden instabilities.

Other thoughts for the night:

Rana suggests increasing the gain in some of the oplev QPD heads (including PRM), so that we're getting more than a few hundred counts of power on each quadrant.  Since our ADCs go to 32,000 counts, a few hundred is very small, and keeping us close to our noise limits.

Also, just an observation, but when I watch the REFL camera along with POP and AS, it's clear that the PRM is getting kicked, and I don't have the ETMs aligned right now, so this is just PRMI flashes.  There is also a lot of glow in the BS chamber during flashes (as seen on the PRM face video camera).

  9383   Thu Nov 14 02:55:26 2013 ranaUpdateSUSPRM motion correlated to intracavity power

 

Some more words about the ISS -> OSEM measurement:

The calibration of the OSEMs have been done so that these channels are each in units of microns. The SIDE channel has the lower noise floor because Valera increased the analog gain by 5x some time ago and compensated with lower digital gain.

The peak heights in the plot are:

UL   0.85

LL   0.78

UR   0.61

LR   0.45

S    0.27

So that tells us that the coupling is not uniform, but mostly coming in from the left side (which side is the the SIDE OSEM on?).

Jenne and I discussed what to do to mitigate this in the loops. Before we vent to fix the scattering (by putting some covers around the OSEMs perhaps), we want to try to tailor the OSEM damping loops to reduce their strength and increase the strength of the OL loops at the frequencies where we saw the bulk of the instability last time.

Jenne is optimizing OL loops now, and I'm working on OSEM tweaking. My aim is to lower the overall loop gains by ~3-5x and compensate that by putting in some low Q, resonant gain at the pendulum modes as we did for eLIGO. We did it here at the 40m several years ago, but had some troubles due to some resulting instability in the MC WFS loops.

 

In parallel, Steve is brainstorming some OSEM shields and I am asking around LIGO for some AC OSEM Satellite modules.

ELOG V3.1.3-