40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 213 of 344  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  10068   Thu Jun 19 00:02:48 2014 JenneUpdateLSCPRMI+2 arms recovery

Arms locked in comm and diff with ALS. PRMI locked with REFL33 I&Q while arms off resonance. Having trouble reducing CARM offset, even to get to arm powers of 1.

After Manasa installed the new Xgreen PD, Koji looked at the PSL table alignment with me.  I saw only a very weak beatnote with the X BBPD, even though I could see the beatnote on the Y PD from the leakage of the X beam to the Y PD  (Yend shutter was closed, so just PSL and X greens were on the table).  I had thought that my near-field and far-field alignments were pretty good (actually, I checked them, but didn't feel that I needed to tweak them since Manasa did the alignment this afternoon).  Anyhow, it was just a matter of tweaking up the alignment a bit, and then the X beatnote got up to about -25dBm at a few tens of MHz.  I am starting to question myself if the other BBPD is broken, or if I just not well enough aligned.  Anyhow, the spare is in, we can still have a look at the previous X BBPD, but it may be okay, and it's just me embarrassing myself by not catching an alignment problem.

Anyhow, after the X beat was found, I was able to (on my first try) lock the arms using ALS comm and diff.  (I already had a nice strong Y beatnote, so that didn't need finding, other than temp adjustment of the end laser).  I ran the carm_cm_up.sh script, and it did everything nicely.  I did a quickie check of the phase tracker loop gains, but that should be redone in the morning.

PRMI was a little reluctant to lock, so I played around with the MICH and PRCL gains, but didn't really find any combination that was any better than the usual (+0.8 for MICH, -0.04 for PRCL as I had last night, although I needed to reduce the PRCL gain back to -0.02 to eliminate loop osc). 

After an arm lockloss, I relocked just the PRMI and used awggui to put a line into C1:LSC-PRM_EXC to check the RF PD phasing.  I changed REFL33 from 133.5 to 138.5, and REFL 165 from -142.5 to -152.5.  I didn't think that REFL11 needed changing, and I didn't check REFL55.  I also checked that I could lock PRMI without arms, using both REFL33 and REFL165 - they seemed about the same to me, both stable.  REFL33 has 1's in the input matrix, and I was using 0.07's for REFL165.  The demod phase adjustment didn't really improve PRMI locking while the arms were held off resonance, even if I moved the arms even farther from resonance (usually we do 3nm, I went out to 5nm to see if that helped - it didn't).  I tried REFL165 locking, but that wasn't any good either.  I tried using REFL165 with the arms held off resonance, but that didn't seem to catch at all (at least with REFL33 I was getting short lock blips). 

Anyhow, of the 3 or 4 times that I caught REFL33 PRMI lock and tried to reduce the CARM offset, only one time did I even get to arm powers of about 1 (CARM digital offset of -0.1, with CARM held on sqrt transmission signals), and then it didn't stay for more than a few tens of seconds.  The other few times, it broke lock on the way up to arm powers of 1. 

So, carm_cm_up.sh works pretty well, although perhaps the arm powers of 1 offset reduction needs to be a little slower.  PRMI doesn't catch and hold lock very easily with REFL33, and even less so with REFL165.  It may be useful to try catching lock with REFL11 or 55, and doing a transition over to 3f.  No real progress forward, but we're pretty much recovered.

 

  10090   Tue Jun 24 01:07:56 2014 JenneUpdateLSCBootfest 2014!

Still no real luck getting the beam back aligned to the IFO.

Koji and I tried a few minutes of wiggling the input pointing tip tilts (TT1 and TT2) around, and then tried doing some thinking.

We note that the beam propagates (modulo a few pickoffs):

IMC -> Faraday -> TT1 -> MMT1 -> MMT2 -> TT2 -> PRM.

Since moving TT1 to the rails does make beam reflections in the BS chamber move (as seen by movement of the general illumination on the PRM face camera), I posit that the beam is getting through the Faraday.  It is certainly getting at least mostly through the Faraday, although since the MC locked so easily, I assume that we didn't have too much movement after the ~2pm Alaskan earthquake & aftershocks, so we're at pretty much the same alignment as usual, in terms of beam pointing coming from the IMC.

The plan is then to see the position of the beam on MMT1, and steer using TT1 to get the beam to roughly the center.  Then, see the beam propagate to MMT2 (if possible) and TT2 (if possible).    From here, we should be able to see the spot on PRM.  We should be able to use TT2 to tweak things up, and get the beam back to about the right place on POP, or REFL, or somewhere farther along.  Hopefully at this point, we'd see some flashes in the Yarm. 

Using a spare Watek camera, I was able to capture a shot of the face of MMT1.  This is when the TTs were restored to their values that were saved last Monday.  I checked, and this is also roughly the center of the actuation range of TT1, for both pitch and yaw.

MMT1_face_23June2014_2315pm.png

I am not able to see the face of MMT2, or TT2.  If I leave TT1, and move TT2, I am not able to see any movement of any beam or reflections seen in the PRM face camera.

Koji and I are checking the MC spot positions, but it may be time to leave this for the morning crew.

EDIT:  The MC spots were actually pretty bad, and the WFS were working really hard.  Koji realigned the MC suspensions, and now the MC spots are slightly better, although quite similar, to what Manasa measured last week.  The restored TT values still don't give us any flashes in the arms.

  10094   Tue Jun 24 18:35:53 2014 JenneUpdateLSCStill no beam going to IFO

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating. 

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2. 

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

  10125   Wed Jul 2 21:30:42 2014 JenneUpdateLSCLittle Bo-Peep has lost her phase
Little Bo-Peep has lost her phase,
And can't tell where to find it;
Leave it alone, and it'll come home,
Bringing its degrees behind it.
 
Seriously.  What?  I was holding CARM on sqrtTrans with arm powers of about 1, DARM was still ALS diff, PRMI on REFL33.  CARM was actuating on +ETMX+ETMX, since I kept kicking the MC out of lock, but other than that, everything was set by the carm_cm_up script, so I don't think there should be any big differences.  I took a CARM transfer function, and it seems like the phase bubble has all but disappeared compared to the reference from mid-May. 

CARM_loop_ArmPowers1_2July2014.pdf

I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.

 

Also this evening, I went to the Yend and did another tweak-up of the green beam alignment. 

  10126   Wed Jul 2 22:58:11 2014 JenneUpdateLSCLittle Bo-Peep has found her phase

Never mind.  This is just the low pass filter that Den put in to try to deal with the moving cavity pole. 

Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines.  This had no effect other than to keep me searching and measuring until I figured it out.  If I turn off the low pass, the phase pops back up to very close to the reference.  The low pass currently comes on automatically as part of the carm_cm_up script.

  10136   Mon Jul 7 13:55:26 2014 JenneUpdateLSCc1cal model restarted

I'm not sure why the c1cal model didn't come up the last time c1lsc was rebooted, but I did an "rtcds start c1cal" on the lsc machine, and it's up and running now.

  10174   Thu Jul 10 02:15:36 2014 JenneUpdateLSCQPD dark noise checkout

I have put beam dumps in front of both of the end transmission QPDs so that I could measure the dark noise.  They are still there.

I checked that the Yend QPD sliders and switches were doing things as I expected.  I couldn't do the Xend since c1auxex is still lost (elog 10165).  I'll post plots and actual information on this checkout, as well as my calculation of what this dark noise means in terms of meters for CARM when we're using 1/sqrt(trans) signals tomorrow morning. 

  10187   Fri Jul 11 20:05:34 2014 JenneUpdateLSCQPD dark noise checkout

The other day, I took spectra of the Yend transmission QPD dark noise for several different configurations of the transimpedance gain and the whitening gains. 

I also calculated with Optickle the expected sensitivity vs. CARM offset for the sqrtInv CARM sensor. 

I put these things together to get a plot of transmission QPD noise vs. CARM offset, for a chosen set of analog settings.


Measurement of Yend transmission QPD dark noise

Since EricQ had already checked out the whitening filters (see elog 9637 and elog 9642), I didn't check on them.  I just left them (the analog whitening, and the digital antiwhitening filters) on. 

First, I checked the noise vs. transimpedance gain. There are a few too many settings to put them all on one plot, so I have them sorted by the original transimpedance:  0.5 kOhms vs 5 kOhms.  It's a little tricky to see, but all of the spectra that begin with the 5k transimpedance have a little extra noise around 10 Hz, although I don't know why.  In the legend I have made note of what the settings were.  x1 x1 is my representation of the "inactive" setting.

TransQPDY_darkNoise_vs_TransimpedanceGain_9July2014.pdf

I then looked at the noise with different whitening gain slider settings.  All but one of the traces are the 20 kOhm setting.  

TransQPDY_darkNoise_vs_WhiteningGain_9July2014.pdf

These .xml files are in /users/jenne/Arms/TransQPDnoise_July2014/


Calculation of inverse sqrt transmission sensitivity

I used Optickle to give me the power transmitted through the ETMs.  I first find the transmission in the FPMI case.  I use that to normalize the full PRFPMI transmission, so that the output units are the same as our C1:LSC-TR[x,y]_OUT units. 

I take the square root of the transmitted power (sum of transmissions from each arm) at each CARM offset point, add 1e-3 as we do in the front end model to prevent divide-by-zero problems, and then take the inverse.

I find the slope by taking the difference in power between adjacent points, divided by the CARM offset difference between those points. 

In this plot, I have taken the absolute value of the sensitivity, just for kicks.  I also display an arbitrarily scaled version of the log of the transmitted power, so that we can see that the highest sensitivity is at half the maximum power.

sqrtTrans_sensitivity.png


 Calculate the QPD dark noise in terms of meters

Finally, I put it all together, and find the dark noise of the QPD in terms of meters.  Since the spectra were measured in units where the single-arm transmission is unity, the already match the units that I used to calculate the sqrtInv sensitivity. 

I take the spectra of the QPD dark noise for the 20 kOhm case, and multiply it by the sensitivity calibration number at several different CARM offsets.  As we expect, the noise is the best at half-max transmission, where the sensitivity is maximal. 

sqrtTrans_Noise_vs_CARMoffset.png

  10200   Tue Jul 15 01:41:43 2014 JenneUpdateLSCData for DARM on sqrtInv investigation

I took some data tonight for a quick look at what combinations of DC signals might be good to use for DARM, as an alternative to ALS before we're ready for RF.

I had the arms locked with ALS, PRMI with REFL33, and tried to move the CARM offset between plus and minus 1.  The PRMI wasn't holding lock closer than about -0.3 or +0.6, so that is also a problem.  Also, I realized just now that I have left the beam dumps in front of the transmission QPDs, so I had prevented any switching of the trans PD source.  This means that all of my data for C1:LSC-TR[x,y]_OUT_DQ is taken with the Thorlabs PDs, which is fine, although they saturate around arm powers of 4 ever since my analog gain increase on the whitening board.  Anyhow, the IFO didn't hold lock for much beyond then anyway, so I didn't miss out on much.  I need to remember to remove the dumps though!!

Self:  Good stuff should be between 12:50am - 1:09am.  One set of data was ./getdata -s 1089445700 -d 30 -c C1:LSC-TRX_OUT_DQ C1:LSC-TRY_OUT_DQ C1:LSC-CARM_IN1_DQ C1:LSC-PRCL_IN1_DQ

  10206   Tue Jul 15 21:43:28 2014 JenneUpdateLSCQPDs back

I removed the dumps in front of the trans QPDs.  The Yend QPD needed re-normalization, so I did that.

  10208   Wed Jul 16 01:04:09 2014 JenneUpdateLSCData for DARM on sqrtInv investigation

I realized while I was looking at last night's data that I had been doing CARM sweeps, when really I wanted to be doing DARM sweeps.  I took a few sets of data of DARM sweeps while locked on ALSdiff.  However, Rana pointed out that comparing ALSdiff to TRX-TRY isn't exactly a fair comparison while I'm locked on ALSdiff, since it's an in-loop signal, so it looks artificially quiet. 

Anyhow, I may consider transitioning DARM over to AS55 temporarily so that I can look at both as out-of-loop sensors. 

Also, so that I can try locking DARM on DC transmission, I have added 2 more columns to the LSC input matrix (now we're at 32!), for TRX and TRY.  We already had sqrt inverse versions of these signals, but the plain TRX and TRY were only available as normalization signals before.  Since Koji put in the facility to sqrt or not the normalization signals, I can now try:

Option 1:  ( TRX - TRY ) / (TRX + TRY)

Option 2:  ( TRX - TRY ) / sqrt( TRX + TRY )

DARM does not yet have the facility to normalize one signal (DC transmission) and not another (ALS diff), so I may need to include that soon.  For tonight, I'm going to try just changing matrix elements with ezcastep.

Since I changed the c1lsc.mdl model, I compiled it, restarted the model, and checked the model in.  I have also added these 2 columns to the AUX_ERR sub-screen for the LSC input matrix.  I have not changed the LSC overview screen.

  10209   Wed Jul 16 01:18:02 2014 ranaSummaryLSCPython Wavelet peak finding for dramatic ALS - Red Resonance finding speedup

New script called scripts/ALS/findRedResonance.py finds the IR resonance in less than 20 seconds.

  1. Do a ~2 FSR scan of the arm over 10 seconds using the Phase Tracker servo offset ramp. (dt = 10 s)
  2. Load the frame data for the TR_OUT and the Phase Tracker phase. (dt = 2 s)
  3. Use Python (modern) SciPy to find all peaks with moderate SNR (dt = 3 s)
  4. Take the top 3 peaks (all presumably TEM00) and choose the one closest to zero and go there.

The above is the gist of what goes on, but there were several issues to overcome to get the code to run.

  1. None of our workstations have a modern enough Python distro to run either the ipython notebooks or the new SciPy with wavelets, so I installed Anaconda Python in the controls home directory.
  2. In order to get the peak finder function to work well I gave it a range of peak widths to look for. If we change the speed of the ALS scan by more than 3x, we probably have to change the width array in the function.
  3. I've used the find_peaks_cwt function in SciPy. This uses a Ricker ('Mexican Hat') wavelet to find peaks by doing multi-res transforms and looking for ridges in the wavelet space (I think)
  4. To make the code run fast, I downsample from 16 kHz to 1 kHz right at the top. Would be better if we had downsampling in v2 of the getData function.

 

  10211   Wed Jul 16 01:35:16 2014 KojiSummaryLSCPython Wavelet peak finding for dramatic ALS - Red Resonance finding speedup

From the last plot:

- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz

- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004

==> mode matching ~93%, dominat higher order is the 2nd order (5%).

Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number?

  10224   Thu Jul 17 00:38:30 2014 JenneUpdateLSCRIN in arm transmission

[Rana, Jenne]

We had a look at the RIN of the transmission signals TRX and TRY, when the arms were individually locked on IR.  If the intensity noise is very bad, then the transmission signals aren't really a good option to use for locking.  So, if the RIN is bad, we need to work on our intensity stabilization. 

We need to understand what the situation is with the AOM, and why it isn't working as expected, so that we can reinstall it.  We also need to decide if we're going to use the SR560 setup, or if the Chas ISS is sufficiently characterized for us to use. 

The RIN is certainly bad.  Also, I don't know why the Xarm's RIN is worse between 10 Hz and a few hundred Hz than the Yarm.

TransRIN.pdf

  10241   Sat Jul 19 17:36:44 2014 JenneUpdateLSCRIN in arm transmission

I looked at what the RIN contribution of the sqrtInv sensor is by locking the arms individually on IR using POX and POY.  I then took spectra of the sqrtInv channels.  For the Xarm, I had forced the triggering so that the QPD was being used as the transmission PD, while the Yarm was using the regular Thorlabs PD.  I also had the green lasers locked to the arms, and took beatnote spectra to see what the sensing noise of the beatnotes is, all at the same time.

For the sqrtInv channels, I used the Optickle calibration from elog 10187. For today's plot, I am using the calibration at about 1nm, since that is about where we are when we transition to the sqrtInv Thorlabs signal usually.

For the ALS channel, I was using the _FINE_PHASE_OUT signal, which is in units of degrees of phase for a single green wavelength.  So, since k * x = phi, I want the phase data to be converted to radians (2*pi/360), and use k = 2*pi / lambda_green.  So, doing some algebra, this gives me x = phi_degrees * lambda / 360 for my calibration. 

What I see in the plot is that the ALS sensing noise is pretty bad compared to the sqrtInv channels, so maybe we don't have to work so hard on the ISS this next week.  Also, the Thorlabs PD is much better than the QPDs, which maybe isn't so surprising since we have them set so that they have good SNR at higher power.

Anyhow, here's the plot:

TransSqrtInvRIN_vs_ALSsensing_18July2014.png

Also, here is the Thorlabs PD only, with single arm locked on RF, with the noise calibrated to different CARM offsets:

ThorlabsRIN_16July2014.png

  10242   Sat Jul 19 20:51:51 2014 KojiUpdateLSCRIN in arm transmission

Your calibration of the ALS signal should be revised.

The phase for the ALS is not an optical phase of the green but the phase of the phase tracker servo output.

The calibration of the phase tracker depends on the cable length of the delay line in the beat box.
It seems that we are based on this calibration. Which gives up ~19kHz/deg.

Or, equivalently, use C1:.....PHASE_OUT_HZ instead.

  10248   Mon Jul 21 17:32:43 2014 ericqSummaryLSCArm losses

Quote:

From the last plot:

- Subtracting the offset of 0.0095, the modulation depth were estimated to be 0.20 for 11MHz, 0.25 for 55MHz

- Carrier TEM00 1.0, 1st order 0.01, 2nd order 0.05, 3rd order 0.002, 4th order 0.004

==> mode matching ~93%, dominat higher order is the 2nd order (5%).

Eric: now we have the number for the mode matching. How much did the cavity round-trip loss be using this number?

Using these numbers for both arms (Modulation takes away .2*.25 = 5% power, mode matching takes away 7% after that), I get the following from my data from March:

Xarm loss is 561.19 +/- 14.57 ppm

Yarm loss is 130.67 +/- 18.97 ppm

Obviously, the Xarm number looks very fishy, but its behavior was qualitatively very different when I took the data. ASDC would change from ~0.298 to ~0.306 when the Yarm was locked vs. misaligned, whereas the xarm numbers were .240 to .275. 

In any case, I'll do the measurement again tomorrow, being careful with offsets and alignment; it won't take too long. 

  10258   Wed Jul 23 02:01:15 2014 JenneUpdateLSCRIN in arm transmission - revised calibration

 

As Koji pointed out, I messed up the calibration.  However, fixing it doesn't change things that much.

From this calibration by Yuta, the Xarm ALS calibration is 54 deg / MHz, or 19.17 kHz / deg.  So, I multiply my data which is in these degree units by 19.17e3 to get Hz.  Then I use delta_f / f = delta_L / L to convert to meters.  f = c / lambda_green, and L = 37.5 meters. 

This only changes the calibration by about 10-15%.  It still looks like the ALS noise is well above the RIN level of the sqrtInv signal.

TransSqrtInvRIN_vs_ALSsensing_18July2014.png

  10262   Wed Jul 23 11:32:04 2014 KojiUpdateLSCIFO warming up

Alone with the IFO. Started from some conversation with it.

Some ALS trials: Found the Y-end green alignment was terrible. In fact the end green set up is terrible.
Unfixed optics, clipping/fringing in the faraday, unstable suprema mounts which is unnecessarily big.

Eventualy I stopped touching the end alignment. Run ALS to see the stability of the things.
This is a performance confirmation after some touching of the ALS electronics by Manasa/SURFs

The sensing noise levels of the ALSs looks the same as before.

The intensity noise of the transmission was also checked. They are not RIN but very close to RIN
as the DC was the unity for both arms.

The X arm has worse ALS noise level and RIN.
Although I forgot to turn off the HEPA flow at the south bench during the measurement. Gurrr.

  10267   Wed Jul 23 23:43:28 2014 ericqUpdateLSCLocking efforts; Wrath of the Mode Cleaner

 [Koji, ericq]

We were working on getting back into the locking groove tonight.

The POP2F and REFL3F demod angles needed some tuning to lock the PRC reliably. The green alignments were mostly fine, the X end PZT ASS works reasonably well. Suspensions, especially the ITMs, seemed to be drifting a fair deal; today was fairly hot out, I guess.

We only got to the point of attempting the SqrtInv handoff once (which failed because I forgot to check the filter bank offsets). This was because the Mode Cleaner refused to stay locked longer than ~5-10 minutes at a time. We adjusted the MC and FSS servo offsets by the usual means, but this didn't make a difference.

We discussed and decided that the time is right to roll up our sleeves and dig into the MC loop, and try to figure out why these intermittent times of unreliability keep cropping up. We will check out the servo board, and see if we can find the missing phase than Evan observed, as well as characterize the FSS/PZT crossover, and investigate what kind of conditions we may create that cause the PC to saturate.

  10285   Tue Jul 29 16:41:54 2014 KojiUpdateLSCMC servo

The MC openloop gains were measured with several conditions
- MC fast/PC crossover was measured to be ~30kHz.
- No feature found in the fast path above 10kHz.

=====

I have been making a circuit to test the crossover between the PZT and PC paths.
This was supposed to allow us to inject a test signal as well as the 5V necessary to offset the voltage for the HV amp.
So far this attempt was not successful although the circuit TF looked just fine. I was wondering what was wrong.

I now suspect that the noise of the circuit was too big. It has ~65nV/rtHz noise level. This corresponds to the external
disturbance of 1~2Hz/rtHz. This is ~10 times larger noise level than the freerun frequency noise.

In the control band the circuit noise is suppressed (cancelled) by the feedback loop.
This is OK when the loop is dominated by the PZT loop. However, if the loop is dominated by the PC path,
the PC path has to work for this compensation.

So what I should do is to remove the low pass filter in the FSS and move it to the downstream of the HV amp.
This way we may be able to reduce the PC path actuation as the noise of the HV amp is also reduced by the LPF.

=====

For the meantime, I used another approach to characterize the MC crossover. I could manage to lock the MC without the PC path.
The openloop was measured with and without the PC path in this low gain setup. In fact the loop was oscillating at 6kHz
due to the low phase margin. Nevertherless, this comparison can let us find where the crossover. The loop gain was also
measured with the nominal condition.

<<Measuerement condition>>

No PC
MC IN1 Gain: +19dB
VCO Gain: +3dB
Boosts: No boost / No super boost

FSS Common Gain: +13dB
Fast Path Gain: +21.5dB
The PC path disconnected.
(Note that the loop was almost oscillating and the apparent gain may look lower than it should have been)

WIth PC
MC IN1 Gain: +19dB
VCO Gain: +3dB
Boosts: No boost / No super boost

FSS Common Gain: +13dB
Fast Path Gain: +21.5dB
The PC path connected.

Nominal
MC IN1 Gain: +19dB
VCO Gain: +15dB
Boosts: Boost On / Super boost 2

FSS Common Gain: +13dB
Fast Path Gain: +21.5dB
The PC path connected.

 

  10286   Tue Jul 29 18:00:20 2014 AkhilUpdateLSCCalibration of ETMX and ETMY actuators

The ultimate goal of characterizing the temperature actuator turned to be fruitful in obtaining the calibration values for ETMX and ETMY (Calibration of ITMs were done previously  here but not for ETM). In this process, I measured the PZT response by  displacing one of the test masses in the frequency range of 20 Hz and 900 Hz  and measured the transfer functions in counts/counts. 

ETMX = [12.27  x 10 -9/ f2 m/count

ETMY = [14.17  x 10 -9/ f2] m/count

 

I calculated these calibration values from the measurements that we have taken( in detail : elog)  and did the following calculations: 

The measurements I made were :PZT count/ Actuator Count separately for all the test masses.

PZT count/ Actuator count = [PZT count/ arm cavity displacement(m) ]*[ displacement of a test mass(m) / Actuator Count]

For a same laser and assuming flat response of the PZT, the term [PZT count/ arm cavity displacement(m) ] remains for all the test masses.

The fitting was done on the gain plots of the PZT Response vs Test mass displacement and a function G * f ^-2 was fitted. The resulting G values were:

ETMX: 8.007* f ^-2 

ITMX: 3.067* f ^-2

ETMY :11.389* f ^-2

ITMY : 3.745* f ^-2

To calculate the calibration of ETMX:

 [PZT count/ Actuator count : ETMX ] / [ displacement of a test mass(m) / Actuator Count :ETMX] =  [PZT count/ Actuator count : ITMX ] / [ displacement of a test mass(m) / Actuator Count :ITMX]

putting the values from the above fitting and Kiwamu's elog,

the calibrated value was calculated to be [12.27 * 10^-9 /f^-2 ]m/count.

A similar calculation was done for ETMY.

The attached are the fitting plots for the measurements taken.

 Now using these and the previously measured calibrations, I will get the complete calibrated TF of the thermal actuator.

 

 

 


 

 

  10293   Wed Jul 30 00:42:27 2014 KojiUpdateLSCMC servo

I used an oscillator and an oscilloscope to measure the open loop transfer function at higher frequency than 100kHz.
(I remember that I tried to use Agilent 4375A for this and failed before ... due to low input impedance???)\

Here is the update. It seems that the gain margin is not so large. We should apply low pass to prevent too large servo bump.

  10300   Wed Jul 30 22:01:24 2014 KojiUpdateLSCMC servo

In fact there is a pomona box between the HV amp and the laser.
It is expected that the combination of the box and the laser PZT (2.36nF by Elog #3640) provides poles at 2.9Hz and 148kHz and a zero at 32Hz.
Basically, the gain of this stage is 0.1 at 10kHz. So the injected noise is reduced by factor of 10. It is just barely OK.
I need a bit more careful design of the output stage for the MC servo.

  10302   Thu Jul 31 01:08:54 2014 KojiUpdateLSCALS stability check

- ALS X/Y arm stability was checked by IR locked arms.

- Basically the stability looks same as before.

Q sez: here are some ALS ASDs (in Hz/rtHz). 

The reference plots are with the arms locked on CARM/DARM with ALS. The main traces are with the arms locked on POX/POY. Alignment affects these traces a fair amount.

postXGreenUpgradeCheckup.pdf

The X arm ALS seems no worse for the upgrade, and the PZT actuators do look pretty orthogonal when we play around with the alignment. 

  10331   Mon Aug 4 22:52:03 2014 JenneUpdateLSCALS alignment tweak-up

After aligning the arms to IR, I aligned the Y green beam to the arm.  Also, the X green beatnote was very small, so I aligned the PSL green for X.

  10335   Wed Aug 6 00:14:10 2014 JenneUpdateLSCALS is iffy tonight

The ALS system is iffy tonight.

After putting the cable back to the RF spectrum analyzer (it had been taken to test the frequency counter setup, and not put back), I had a good Yarm beatnote, but again this evening the Xarm beatnote is small.  I touched up the PSL table alignment (very, very little needed, but it did double my peak height).  I *think* that this is happening because we haven't settled into a good IFO alignment place, so the arm pointing keeps changing very slightly, which means that the PSL ALS alignment needs touching.  Anyhow, even after alignment the Xarm beatnote is only -36 dBm at 81 MHz.  It should be at least -25 dBm or so, although I haven't seen it any larger than about -35 dBm since the IFO beam was lost last Friday.

I am not able to hold ALS lock long enough to scan the arms and find the IR resonances.  The only optics that I am actuating on this evening are the 2 ETMs.  When I lose lock and look at the watchdogs, the ETMs are the only optics that have largeish numbers, which comes from the ALS lockloss.  So, I don't think I am suffering from the ITM suspension kicks tonight.  Rather, I think that it's that the ALS system isn't tuned up nicely.

I think that it is past time we tuned up and checked out the ALS PDH setup.  Q:  Can you please measure the loop TFs for both of the ALS PDH boxes tomorrow?  At the very least we want to know what we're working with. 

Evan:  What is the status with the ISS? 

I am going to try tomorrow to look at the suspensions, and see if I can track anything down.  I feel like I see the kicks more often when the arms are locked, i.e. we are sending an LSC signal to them.  The LSC POS signal is a factor of a few hundred larger than the damping SUSPOS signal is.  Are we saturating something somewhere?  Why is this a new thing?  We certainly do see kicks when the LSC is not engaged, so this may not be the right path, but it is something concrete to look at.

  10345   Thu Aug 7 12:34:56 2014 JenneUpdateLSCSuspensions not kicking?

Yesterday, Q helped me look at the DACs for some of the suspensions, since Gabriele pointed out that the DACs may have trouble with zero crossings.  

First, I looked at the oplevs of all the test masses with the oplev servos off, as well as the coil drive outputs from the suspension screen which should go straight out to the DACs.  I put some biases on the suspensions in either pitch or yaw so that one or two of the coil outputs was crossing zero regularly.  I didn't see any kicks. 

Next, we turned off the inputs of the coil driver filter banks, unplugged the cable from the coil driver board to the satellite box, and put in sinusoidal excitations to each of the coils using awggui.  We then looked with a 'scope at the monitor point of the coil driver boards, but didn't see any glitches or abnormalities.  (We then put everything back to normal)

Finally, I locked and aligned the 2 arms, and just left them sitting.  The oplev servos were engaged, but I didn't ever see any big kicks. 

I am suspicious that there was something funny going on with the computers and RFM over the weekend, when we were not getting RFM connections between the vertex and the end stations, and that somehow weird signals were also getting sent to some of the optics.  Q's nuclear reboot (all the front ends simultaneously) fixed the RFM situation, and I don't know that I've seen any kicks since then, although Eric thinks that he has, at least once.  Anyhow, I think they might be gone for now.

  10378   Wed Aug 13 19:23:09 2014 JenneUpdateLSCPSL, Aux laser mode hop check

This afternoon Q helped me put in some temporary PDs for checking for any mode hopping behavior in our 3 main lasers. 

Q helped me install PDA55s on each of the lasers (I did the ends, he did the PSL) so that we could do the mode hop temperature check.  For the Yend, I took the leakage transmission through the first Y1 steering mirror after the laser. This beam was dumped, so I replaced the dump with a PDA55. For the Xend, the equivalent mirrors are too close to the edge of the table, so I put in a spare Y1, and reflect most of the light to a beam dump.  The leakage transmission then goes to a PDA55.  Note that for both of these cases, no alignment of main laser path mirrors was touched, so we should just be able to remove them when we're through.  For the PSL, I believe that Q took the rejected light from one of the PBSes before the PMC. 

The end temporary PDs are using the TRX / TRY cables, so we will be looking at the C1:LSC-TR[x,y] channels for the power of the end lasers.  The PSL's temporary PD is connected to the PMC REFL cable.  For the end PDs, since I had filter banks available, I shuttered the end lasers and removed the dark offset.  I then changed the gains to 1, so the values are in raw counts.  The usual transmission normalization gains are noted in one of the control room notebooks.

I did a slow ezcastep and ramped the temperature of all 3 lasers over about an hour.  Since we usually use the PSL around FSS slow slider value of zero, I swept that from -10 to +10.  Since we usually use the Xend laser at around 10,000 counts, I swept that from 0 to 20,000.  For the Yend laser, it is usually around -10,000 counts, so I swept it from -20,000 to 0.  ezcastep -s 0.2 C1:ALS-X_SLOW_SERVO2_OFFSET +1,20000 C1:ALS-Y_SLOW_SERVO2_OFFSET +1,20000 C1:PSL-FSS_SLOWDC +0.001,20000

I was looking for something kind of similar to what Koji saw when he did this kind of sweep for the old MOPA (elog #2008), but didn't see any power jumps that looked suspicious.

Here is the PSL:

ModeHopCheck_PSL_13Aug2014.pdf

The Xend:

ModeHopCheck_Xend_13Aug2014.pdf

And the Yend:

ModeHopCheck_Yend_13Aug2014.pdf

  10390   Thu Aug 14 18:31:45 2014 ericqUpdateLSCLSC Modeling Update

 Based on the game plan, I have created a slew of updated pretty plots about our signals and loops. 

First: With measured arm losses, when do we start to see REFL DC dip? At what arm buildup powers? 

I updated my MIST model with the arm losses I've measured (Y:130ppm, X:530ppm), and some measured transmissions from the wiki, vs. the design parameters, as I used to have. Here is the DC sweep plot which is now hanging up in the control room. 

dcSweep.pdf

In this plot, I also calculated what MIST thinks the full arm power buildup will be as compared to our single arm locking, and I get something of order 200, rather than the 600 we've tossed around in discussions. Nothing else is very different in this plot from the old version; though the REFLDC dip is a little bit wider. 

Now, here are some radiation-pressure inclusive sensing transfer functions, for the anti-spring case (which in Rob's day was easier to lock for unknown reasons):

carm2TRX.pdfcarm2REFLDC.pdf

carm2REFL11.pdfdarm2AS55Q.pdf


Next: Include new AO path TFs into CM model Look at possibilities for engaging AO path 

With these TFs, and the recently measured+fit new AO TF, here are the open loop gains of the slow, digital, SqrtInv-sensed MCL CARM and fast, analog, REFLDC-sensed AO CARM loops for the region of offsets we've achieved and a little lower. The slow digital loop includes the 1k LP that we have used in the past, in addition to the normal CARM filters. I still need to figure out the right sequence of ( offset reduction / crossover frequency motion / overall gain adjustment ) that gets the coupled cavity resonance solidly within the loop bandwidth. 
 
MCLcarmLoop.pdfAOcarmLoop.pdf

 

  10395   Thu Aug 14 22:31:12 2014 JenneUpdateLSCTRY gets mystery offset

I don't know why, but TRY has somehow gotten a 0.3 count offset in the last hour. 

Rana and I are witnesses for each other that neither of us has gone into the IFO room in the last several hours (and we're the only ones here).  For some reason though, the TRY PD now has a 0.3 count offset.  We have been doing some ALS locks, but we have not run the offset script in the last several hours.  Closing the green shutter doesn't change things, and we still see the offset when the MC loses lock, so it's not to do with the end or the PSL laser.  We haven't been in there, so there hasn't been a change in the room lights. 

TRY_0pt3_offset.pdf

  10397   Thu Aug 14 23:19:49 2014 ranaSummaryLSCETM Violin fundamental filters moved to LSC

 We used to do violin mode and test mass body mode notches in the SUS-LSC filter modules. Now we want them balanced in the LSC and triggered by the LSC, so they're in the filter modules which go from the the LSC output matrix to the SUS.

01.png

Today, we were getting ETM violin mode ringups while doing ALS hunt and so we moved the bandstops into the LSC. I also changed the bandstop from a wide one which missed the ETMX mode to a double bandstop which gets both the ETMX and the ETMY mode. See attached image of the Bode mag.

03.png

  10399   Fri Aug 15 02:05:55 2014 JenneUpdateLSCALS in-loop spectra

 Not sure why, but Rana and I didn't see the super high Xarm noise with ALS that we reported last night (elog 10382).  

The in-loop ALS noise seems fine.  The out of loop measurement while the ALS is locked is a little tricky, since ALS hold the arms within the POX/POY linear ranges.  

Here is the in-loop noise:

ALS_XY_inloop_noise_14Aug2014_lowBeatFreq.pdf

  10401   Fri Aug 15 14:09:21 2014 JenneUpdateLSCTRY mystery offset gone

Again unknown, but about 6 hours ago (so ~8am) the offset disappeared. 

Here's a 1-day trend:

TRY_0pt3_offset_gone.pdf

  10402   Fri Aug 15 14:35:57 2014 ericqUpdateLSCTRY mystery offset gone

One question answered, but another raised. The offset came from LSC-TRY switching to the ETMY-QPD signal from ETMY-TRY (Hi gain pd). 

BUT WHY

TRYmystery.png

  10422   Fri Aug 22 03:55:45 2014 JenneUpdateLSCXarm PDH fine, Yarm PDH/ALS needs work

[Rana, Jenne, EricQ]

We did several things tonight.  First, a list (so I can remember them all), and then some details.

(1) Jiggled ETMY SUS cables, removed kicks.

(2) Locked X and Y ALS, looked at POX, POY as out of loop sensors.

(3) Measured stuff (?) at the Yend.

(4) Reconnected REFL DC to SR560.

(5) Attempted CARM offset reduction.


Item 1:

When Rana and I started locking this evening, we saw (as Q has been witnessing for a while now) the ETMY kick a lot.  However, it seemed to be kicking even more than usual.  Since Q had been down at the end station recabling things, we wondered if a SUS-related cable got bumped.  Rana went down to the end and pushed all the cables into their receptacles.  One of the last sets that he pushed was the satellite box.  We didn't have walkie-talkie communication, but the DC offset of the ETMY oplevs changed just a minute or two before he returned to the control room.  So, we guess that it was the satellite box cables that were loose.  Unfortunately, there is no clear way to strain relieve them, which is why they can so often be troublesome.  Anyhow, the ETMY hasn't kicked since.

Item 2:

We locked the arms with ALS.  We saw that the POX signal was about 20% of the full pk-pk height of the PDH signal, so it's mostly within the linear range, but not entirely.  It is what it is, however, and we took measurements assuming that it's okay.  I calibrated POX by putting an excitation onto ETMX, and matching the height of the peak in POX and BEATX_FINE_PHASE_OUT_HZ.

Q and Rana had also [remembered / put in / something] a digital readback for the end green PDH error point.  Q went down to the end and gave me a number of 2600 Hz/V for the err mon port of the PDH board, which is what is connected to the ADC.  With that and 20/2^16 V/cts, I had a calibration of 0.8 Hz/ct. 

What we see in this plot is that the green end PDH is not the limiting noise for the POX out of loop measurement of the residual arm motion.  Also, in the multi-color metrology paper, Fig 7 (which is posted in the control room), we see at about a little over 1 Hz a ratio of about 4.5 between the residual motion and the AUX PDH error signal.  In today's plot, I see a ratio of about 20.  I infer from this that the green PDH for the Xarm is fine, and that we may want to re-look at the ALS digital loop, but we should leave the X PDH alone.

Here is the Xarm plot:

Xend_ErrorPointMeasurements.pdf

Q took the data for the Yarm plot, so hopefully he can give it to us in the morning.  What we did notice was that the noise was much worse for the Yarm.  This prompted Item 3, measuring the loop.

Item 3:

Q and Rana went down to the Yend and measured some things.  They came back, and said that they hadn't changed anything in analog while they were down there.  One thing that Q did note was that we have almost 90 degrees of phase margin (since it's a 1/f loop), and about 10 dB of gain margin, above the UGF.  So, we're in good shape for being able to try triggering the boost on the PDH box.  Q will give us more notes on this work, as well as plots, in the morning.

Item 4:

At some point, I remembered that Q and Gabriele had repurposed the SR560 that we had been using for the REFLDC input to the common mode board.  So, Q went and put it back, so that REFL DC goes into the SR560, and so does a DAC channel so that we can remotely set the offset.  The A-B output goes to the REFL11I whitening channel, since real REFL11I goes into the input of the CM board.  I think that today, the SR 560 was left at a gain of 1.

Item 5:

We decided to carry on and try to reduce the CARM offset some.  An annoyance is that the Yarm still has pretty significant low-frequency noise, but the idea is that if we can get over to the sqrtInvTrans signals, it will be fine.

So, we didn't get much farther than we had in the past, but it was nice to get there at all again.  I ran the carm_cm_up script (many times).  One of the times, all I wanted to do was see how much I could reduce the CARM offset.  CARM was on sqrtInvTrans, DARM was on ALS diff, and I was able to get the arm powers up to about 2.5.  I don't know why I lost lock.  The sqrtInv signals should be good until at least arm powers of 20 or so. 

I was able to see the REFL DC dip, but only a teensy tiny bit.  It went down by maybe 1 count.  Q suggested looking at how deep it could get while leaving CARM and DARM both on ALS, and setting both offsets to 0.  We were seeing arm flashes of about 50 counts, and REFL DC went from 0 to -800.  So, I wasn't seeing much of a REFL dip, but it was definitely there when I went to arm powers of 2ish.

We tried looking at different sqrtInv options for DARM, and haven't come to any real conclusion.  In the plot below, we are looking at a swept sine between DARM_IN1 (ALSdiff) and either MC_IN1 0.3*(sqrtInvX - sqrtInvY) or SRCL_IN1 (TRX - TRY / sqrt(TRX + TRY) ):

DARM_ALSdiff_vs_sqrtInv.pdf

 


We have a few things to add to the to-do list:

* Put UGF servos for LSC loops in place.

* Implement UGF "servos" (per Koji's suggested method) for phase trackers.

* Write a lockloss script that is run by the ALS watch scripts - print a PDF of error and control signals for every lockloss, and save it somewhere.

* Fix up Ygreen modematching on the PSL table.  The X green spot is quite similar on the camera to the corresponding PSL green spot.  However the Y green spot is not at all the same as its PSL green spot. 

 

  10434   Thu Aug 28 01:41:03 2014 ericqUpdateLSCPhase Tracker UGF normalization

We want both the X and Y phase trackers to have the same UGF, so that the X and Y ALS signals are subject to the same phase characteristics and can be nicely decoupled into CARM/DARM. 

I've started implementing a simple normalization scheme that Koji suggested, namely, dividing the I output of the phase tracker by a low passed version of the Q output. (Since the I is servoed to zero, the radius of the error signal in the IQ plane is essentially equal to the Q value) I put some simulink logic into the IQLOCK library part that BEAT[XY]_FINE are instances of to switch the normalization on/off, and to protect from divide-by-zeros. I also exposed the switching and FM on the ALS screen.

UGFnorm.png

I then tried using it, to mediocre results. I put a 10mHz LP in the filter module, found a Y-Arm beat, set the phase tracker gain to give me a 2kHz UGF, and then set the gain of the UGH normalization FM to turn the current average Q to unity. 

I then moved the laser temperature around to get different beatnote locations/amplitudes, hoping that the phase tracker UGF would stay the same when the UGH normalization was on.

It did not.

It did, however, correct it in the right direction... more work will be done with this, to try and make it useful. There's also the unfortunate effect that locking/unlocking the green causes erratic phase tracker output, which messes with the input to the normalizing LP filter, so if one were to leave it switched on, wonky stuff would come out. I don't want to go overboard with triggering shenanigans before I even get it working in the first place, though.  

  10442   Tue Sep 2 22:54:27 2014 KojiSummaryLSCphase tracker UGF

FYI and FMI

Phase tracker UGF is  Q_AMP * G * 2 PI / 360 where Q_AMP is the amplitude of the Q_ERR output and G is the gain of the phase tracker.

For example: Q_AMP = 270, G = 4000\ => UGF = 1.9kHz

  10444   Wed Sep 3 04:17:21 2014 JenneUpdateLSCY green ALS (not PDH) needs investigation

Q put the X PDH box back, so that I could try locking, and remember which end is up after a week away.

I am unable to hold ALS comm/diff for any length of time. Only once today did I hold it through the FM3 boost turn-on.  So, I looked at the individual arms.

Xarm, even though it's the one that Q is seeing this saturation problem with, seems fine. 

Yarm however is having trouble holding lock for more than a few minutes at a time.  The green beam stays locked to the arm for ~infinity, so I'm not so worried about the PDH box right now.  If I look at the error and control points of the ALS digital servo, the Yarm is much more noisy above about 20 Hz.  Something that I might think of for this kind of mismatch at higher frequencies is poorly matched whitening / dewhitening, or none at all for the Yarm, however this doesn't look like that to me.  Based on the shape of the spectra, I don't think that we're running into ADC noise. For this plot, both arms are individually locked with ALS feeding back to the ETM, gain magnitude of 15 (Xarm gets a minus sign because of our temperature / beatnote moving direction convention), FMs 1,2,3,5,6 on.  Something that seems critical for getting the Yarm to have the FM3 boost without losing lock is having the SLOW temperature servos on for a little while so that the PZT output (as monitored on the temp servo screen) for the end lasers fluctuate around zero. Right now, both beatnotes are at about 62MHz, with an amplitude of about -31dBm.

Yarm_noisy_above_20Hz.pdf

I still need to do a somewhat more thorough investigation of what might be causing the Yarm locklosses.  Is the length-to-angle decoupling worse for ETMY than for ETMX?  Am I moving the arm length so far that the PZT can't follow within its actuation limits?  Does the Yend PDH box have a similar saturation to the Xend box, but somehow (a) worse, and (b) not as obvious so we didn't suspect it before? 

I need to put this plot into calibrated units, and also include the low frequency monitor that we have of the PDH error point (all of which are _DQ channels).

Things to do:

* Figure out Xend PDH box saturation issue.  Is Yend seeing same saturation in the variable gain amplifier?  We have 3 spares of these chips in the Plateau Tournant Bleu, if we need them. 

* Check Yarm ALS stability.  (NB:  The arms have been individually locked for the last 15 min or so while I've been writing, so maybe letting the slow servo settle is the key, and this is not something that needs work).

* Get CARM on DC Trans, DARM on AS55Q (after arm powers of about 1).  Can we see good REFL DC dip?  Should we try using just the transmission PD signal as the error signal for the CM board, if we aren't close enough to resonance to use REFL DC?

  10446   Wed Sep 3 18:42:43 2014 JenneUpdateLSCGreen PDH box boosts

From EricQ's simulations reported in elog 10390, we want to transition from ALS comm to DC transmission signals around 500 pm.  However, around 100 pm, the DC transmission signals have a sign flip, so we don't want to have the ALS swing that close to the CARM resonance.  So.  We want to be at about 500 pm, and not touch 100 pm.  So, we don't want our peak ALS motion to go beyond ~400 pm.  Which means that we need to have less than about 40 pm in-loop RMS, to avoid hitting 400 pm.  This is an ALS requirement, but since the analog PDH box is what forces the end laser to follow the arm cavity, and thus give us information about the arm length fluctuations, the PDH residual noise is part of our sensor noise for the full ALS.  So, we need to have the PDH in-loop RMS be less than 40 pm, integrated from a few kHz down to at least 30 mHz. Recall that above the ALS UGF (of about 200 Hz), the sensor noise will be suppressed by 1/f, so we should take that into account when we are looking at the PDH error signal, before we calculate the RMS motion.

Q also measured the in-loop error signal with the current Yend PDH box in elog 10430, and it looks like most of the RMS is coming from a few hundred Hz.  I designed a hack to the PDH board boost that has a zero at about 2kHz, and a gain of 30 at DC, so that we will win by squishing all that RMS.  Also, it shouldn't be too aggressive, so we should be able to leave it on all the time, and still acquire lock of the green laser to the arm, without having to do triggering.

The board schematic is at DCC D1400294.  The boost is also called the "integrator stage", although it will no longer be a simple integrator.

EDIT, JCD:  This cartoon is not correct for the non-boosted state, doesn't include effect of R16.

BoostCartoon.pdf

  10448   Thu Sep 4 00:56:44 2014 JenneUpdateLSCGreen PDH box boosts

Okay, went back to the drawing board with Rana and Koji on PDH box stuff.

Currently (at least for the Yend), in the boost OFF state, we have an overall gain of about 50.  This is crazy big.  Also, the zero in the "transfer function stage" is around 1kHz, however our green cavity pole is (calculated) to be around 20 kHz.  Since these are supposed to cancel but they're not, we have a wide weird flat region in our loop TF.

So.  I calculated the changes to the TF stage that I'll need so that I have an increase of about 20 in DC gain, kept the pole at the same ~20Hz, but moved the zero way out to 18kHz.  I also calculated the changes needed for the integrator stage to make it effective at much higher frequency than it was designed for.  Now the pole is at 75 Hz, and the zero will be at 1.6kHz, and the high frequency gain will stay pretty close to the same with and without the boost.

Planned new TF stage:

TFstage_newDesign_3Sept2014.png

Planned boost stage (with and without boost activated):

BoostNoBoost_newDesign_3Sept2014.png

New boost stage only, so you can see the phase:

BoostOnly_newDesign_3Sept2014.png

The schematic, modified to show my planned changes (which I will put in the DCC after I make the changes):

D0901351-v1_3Sept2014.pdf

  10449   Thu Sep 4 01:28:32 2014 ericqUpdateLSCRecycling cavity lengths

 Going off some discussion we had at lunch today, here is my current knowledge of the state of cavity lengths. 

Acknowledging that Koji changed the sideband modulation frequency recently, the ideal cavity lengths are (to the nearest mm):

  • Lprc = c / ( 4 * fmod) = 6.773 m
  • Lsrc = c / ( 5 * fmod) = 5.418 m

We when last hand measured distances, after moving PR2, we found:

  • Lprc  = 6.752 m = 2.1 cm short
  • Lsrc  = 5.474 m = 5.6 cm long. 

However, when I looked at the sideband splitting interferometrically, I found:

  • Lprc = 6.759m = 1.4 cm short

This is only 5mm from the hand measured value, so we can believe that the SRC length is between 5 and 6 cm too long. I'm building a MIST model to try and see what this may entail. 

  10450   Thu Sep 4 03:12:55 2014 ericqUpdateLSCGreen PDH box boosts

Jenne made her board modifications, and the measured TF agreed with the design. Alas, the green would not lock to the arm in this state. 

I think that the reason is that the new TF does not have nearly as much low frequency gain as the old one, for a given UGF. Thus, for example, the 1Hz noise due to the pendulum resonance, has 30dB less loop gain suppressing it. 

boostedTF.pdf

 

NEED MORE gain.jpg

 

  10451   Thu Sep 4 10:10:23 2014 KojiUpdateLSCRecycling cavity lengths

Com'on. This is just a 60ppm change of the mod frequency from the nominal. How can it change the recycling cav length by more than a cm?

https://wiki-40m.ligo.caltech.edu/IFO_Modeling/RC_lengths

This describes how the desirable recycling cavity lengths are affected by the phase of the sidebands at non-resonant reflection of the arms.

If we believe these numbers, L_PRC = 6.7538 [m] and L_SRC = 5.39915 [m].

Compare them with the measured numbers

  • Lprc = 6.752 m
  • Lsrc  = 5.474 m

You should definitely run MIST to see what is the optimal length of the RCs, and what is the effect of the given length deviations.

  10452   Thu Sep 4 16:45:10 2014 JenneUpdateLSCGreen PDH box boosts

As EricQ mentioned in last night's elog, the modifications were made to the Yend (SN 17) uPDH board.

R31 became 49.9 Ohms, R30 became 45.3kOhm, R24 became 1.02k, R16 became 1k, a new flying resistor is tombstoned up against R24 and connected by purple wire to C6 and it is 20k.  C28 is 183nF and C6 is 100nF.  These numbers were used in Q's simulation last night.

 

 

IMG_1712.JPGIMG_1714.JPG

  10453   Thu Sep 4 18:16:20 2014 ericqUpdateLSCRecycling cavity lengths

Koji correctly points out that I naïvely overlooked various factors. With a similar analysis to the wiki page, I get:

  • Ideal arm length of 37.795 m
  • Ideal PRC length of 6.753 m
  • Ideal SRC length of 5.399 m

This means that:

  • The PRC, measured at 6.759m, is 6mm long. 
  • The SRC, measured at 5.474m, is 7.5 cm long

Next step is to see how this may affect our ability to sense, and thereby control, the SRC when the arms are going. 

MIST simulations and plots are in the attached zip. 

  10458   Fri Sep 5 05:32:57 2014 JenneUpdateLSCGreen PDH box boosts

[Rana, Jenne, EricQ]

* Too much gain overall on Yend box, needed attenuator on output to get lock.  Rethought gain allocation.  Resoldered board, installed, Ygreen locks nicely.  Error point and control point spectra, box TF and open loop TF data collected, to be plotted.

* Q replaced the Xend box, with a matching TF.

* Locked both arms individually, Yend has lots of low freq fluctuation, Xend has some.  Can't do out of loop measurement since we're going well beyond the range of the PDH signals (Yarm RIN is between 1/2 and 1.) Plot TRX and TRY spectra with ALS lock vs. IR lock to get an idea of what frequencies we have a problem with.

* Tried comm/diff locking anyway.  Works.  Used cm_up script to get CARM to sqrtInvTrans.  Went to powers of about 0.5 (hard to say really, because of fluctuations), put sine at 611.1 Hz, 200 cts onto ETMs (-1*x, +1*y), looked at TF between ALS diff and AS55Q.  Put that amount into the static power normalization spot for AS55.  In steps of 0.1, reduced ALSdiff input matrix elements and increased AS55->DARM element.  2 (3?) times was able to get to AS55Q for DARM.  Lost lock once unknown reason, while reducing CARM offset.  Lost lock once trying to turn on FM4 LSC boost for DARM.

TRX/TRY spectra:

TRX_TRY_ALSvsIR_4Sept2014.pdf

  10462   Fri Sep 5 21:13:57 2014 JenneUpdateLSCGreen PDH out of loop

I locked the arms with IR, and measured the beatnote spectra to get the out of loop noise for the PDH boxes. 

Unfortunately, we don't have a reference saved (that I can find), so we're going to have to compare to an elog of Koji's from a month ago.  I have created an out of loop ALS reference .xml file in the Templates/ALS folder.

ALS_XY_outOfLoop_5Sept2014.pdf

As we can see from Koji's elog 10302, the Xarm seems to have stayed the same, but the Yarm seems to have increased by about an order of magnitude below 100 Hz.  :(

  10474   Tue Sep 9 00:34:34 2014 JenneUpdateLSCFiguring out where to do DARM->AS55

This afternoon, after Q and Manasa finished recovering from the activities of the morning, I aligned the IFO, and went to the Yend to touch up the alignment of the green to the arm.  I don't know if it was the alignment (I didn't do the PSL table), or I happened to have a good combination of laser temperatures, or what, but the Yend ALS noise was super good.  After that, the low frequency noise contribution is different lock-to-lock, and I haven't discerned a pattern yet.

One thing that we want to try is to get DARM to AS55 so that we're entirely off of ALS (assuming we've already gotten CARM to sqrtInvTrans).  However, according to Q's simulations, we have to get past arm power of a few before we are within the AS55 linewidth.  I have a DTT running showing me the phase between AS55 and ALSdiff as I reduce the CARM offset, but I haven't been able to get close enough to see the sign flip when CARM is on sqrtInvTrans.  If I just sweep through with both CARM and DARM on ALS, I see the sign flip.  I've tried a few different things, but I have not successfully gotten a transition to AS55 while the arm powers were above 1.  Empirically,  I think I want them at at least 3 or 4.

Koji suggested locking the DRMI rather than PRMI, to widen the AS55 linewidth, but I haven't tried that tonight.  Maybe tomorrow night.

I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

Q, can you please work on figuring out the phase tracker gain tracker?  It will be nice to have that functional so we don't have to fret about the phase tracker gains. 

Manasa, can you please estimate what kind of mode matching we have on the PSL table between the arm greens and the PSL green?  We *do not* want to touch any optics at this point.  Just stick in a power meter to see how much power we're getting from each beam, and then think about the peak height we see, and what that might tell us about our mode overlap.  If we determine it is total crap, we can think about measuring the beams that go either toward the camera, or the DC PDs, since neither of those paths require careful alignment, and they are already picked off from the main beatnote path.  But first, what is our current efficiency?  Yarm is first, then Xarm, since Yarm seems worse (peak height is larger for non-00 modes!)

  10478   Tue Sep 9 14:25:46 2014 jamieUpdateLSCFiguring out where to do DARM->AS55

Quote:

I have made a ruidimentary lockloss plotting script, that I have put in ..../scripts/LSC/LockLossData, but I'm not satisfied with it yet.  Somehow it's not catching the lockloss, even though it's supposed to run when the ALS watch/down scripts run.  I'll need to look into this when I'm not so sleepy.

We developed a fairly sophisticated lockloss script at the sites, which you could try using as well.  It's at:

USERAPPS/sys/common/scripts/lockloss

It requires a reasonably up-to-date install of cdsutils, and the tconvert utility.  It uses guardian at the sites to determine when locklosses happen, but you can use it without guardian by just feeding it a specific time to plot.  It also accepts a list of channels to plot, one per line.

ELOG V3.1.3-