40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 73 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  10612   Wed Oct 15 19:56:38 2014 JenneUpdateLSCWhich side of optical spring are we on? Meas vs Model

 I have plotted measured data from last night (elog 10607) with a version of the result from Rana's simulink CARM loop model (elog 10593).

The measured data that was taken last night (open circles in plots) is with an injection into MC2 position, and I'm reading out TRX.  This is for the negative side of the digital CARM offset, which is the one that we can only get to arm powers of 5ish.

The modeled data (solid lines in plots) is derived from what Rana has been plotting the last few days, but it's not quite identical.  I added another excitation point to the simulink model at the same place as the "CARM OUT" measurement point.  This is to match the fact that the measured transfer functions were taken by driving MC2.  I then asked matlab to give me the transfer function between this new excitation point (CARM CTRL point) and the IN1 point of the loop, which should be equivalent to our TRX_OUT.  So, I believe that what I'm plotting is equivalent to TRX/MC2.  The difference between the 2 plots is just that one uses the modeled spring-side optical response, and the other uses the modeled antispring-side response.



I have zoomed the X-axis of these plots to be between 30 Hz - 3 kHz, which is the range that we had coherence of better than 0.8ish last night in the measurements.  The modeled data is all given the same scale factor (even between plots), and is set so that the lowest arm power traces (pink) line up around 150 Hz. 

I conclude from these plots that we still don't know what side of the CARM resonance we are on. 

 I have not plotted the measurements from the positive side of the digital CARM offset, because those transfer functions were to sqrtInvTRX, not plain TRX, whereas the model only is for plain TRX. There should only be an overall gain difference between them though, no phase difference.  If you look at last night's data, you'll see that the positive side of the CARM offset measured phase has similar characteristics to the negative offset, i.e. the phase is not flat, but it is roughly flat in both modeled cases, so even with that data, I still say that we don't know what side of the CARM resonance we are on.



  10614   Wed Oct 15 22:39:17 2014 JenneUpdateLSCThe Plan

 [Rana, Jenne]

We're summarizing the discussions of the last few days as to the game plan for locking.  

  1. PRMI on REFL165.  The factor of 5 in frequency will give us more MICH signal.    We want this.
    1. Drive CARM, measure coupling to PRCL, MICH while locked on REFL33.
    2. Switch to REFL165, re-measure CARM coupling.
    3. Hopefully this will reduce the AS port fluctuations, and reduce the POP22 power decrease as CARM offset decreases. 
  2. DARM transition from ALSdiff to an intermediate signal.  Simulate, and try empirically.
    1. Maybe try ASDC normalized by sum of transmissions?
    2. Maybe try difference of transmissions divided by sum of transmissions?  
  3. Look at data on disk.
    1. Do we have anything specific causing our locklosses (lately there haven't been obvious loop instabilities causing the locklosses)?
    2. How much do we think our lengths are actually changing right now (particularly DARM on ALSdiff)?
    3. Are there better ways of combining error signals that could be useful?
    4. Do we need to work on angular loops?
      1. Oplevs
      2. POP ASC for sidebands
      3. POP QPD or Trans QPDs for arms
  4.  Think about what could be causing ETMX to be annoying.  The connection that is most suspect has been ziptied, but we're still seeing ETMX move either at locklosses or sometimes just spontaneously.
  5.  RAM.  What kind of RAM levels do we have right now, and how do they affect our locking offsets?  Do we have big offsets, or negligible offsets?
  10615   Thu Oct 16 03:13:23 2014 JenneUpdateLSCPRMI on REFL165, and more

 The first thing I looked at tonight was locking the PRMI on REFL 165.

I locked the PRMI (no arms), and checked the REFL 165 demod phase. I also found the input matrix configuration that allowed me to acquire PRMI lock directly on REFL165.  After locking the arms on ALS, I tried to lock the PRMI with REFL 165 and failed.  So, I rechecked the demod phase and the relative transfer functions between REFL 165 and REFL 33.  The end of the story is that, even with the re-tuned demod phase for CARM offset of a few nanometers, I cannot acquire PRMI lock on REFL 165, nor can I transition from REFL 33 to REFL 165.  We need to revisit this tomorrow.

IFO configuration CARM offset [cts] REFL 165 demod phase [deg]
Found as-is N/A +145
PRMI, no arms N/A -135
PRFPMI +3 +110
PRFPMI +2 +110
PRFPMI +1 +110
PRFPMI +0.5 +120


IFO configuration REFL 33 I / REFL 165 I (PRCL) REFL 33 Q / REFL 165 Q (MICH)
PRMI, no arms +0.1 +0.22, although easier to acquire lock with +0.1
PRFPMI, CARM offset = +3 -0.09  (TF measured, no lock) +0.033  (TF measured, no lock)

For the PRMI-only case, I ended up using 0.1's in the input matrix, and I added an FM 1 to the MICH filter bank that is a flat gain of 2.2, and then I had it trigger along with FM2.

I turned this FM1 off (and no triggering) while trying to transition from REFL33 to REFL165 in the PRFPMI case, but that didn't help.  I think that maybe I need to remeasure my transfer functions or something, because I could put values into the REFL165 columns of the input matrix while REFL33 was still 1's, but I couldn't remove (even if done slowly) the REFL33 matrix elements without losing lock of the PRMI.  So, we need to get the input matrix elements correct.

I also recorded some time series for a quick RAM investigation that I will work on tomorrow.  

I left the PRM aligned, but significantly misaligned both ITMs to get data at the REFL port of the RAM that we see.  I also aligned the PRMI (no arms) and let it flash so that I can see the pk-pk size of our PDH signals.  I need to remember to calibrate these from counts to meters.  

Raw data is in /users/jenne/RAM/ .

I have not tried any new DARM signals, since PRMI wasn't working with 3f2.  

We should get to that as soon as we fix the PRMI-3f2 situation.

  10616   Thu Oct 16 03:18:48 2014 JenneUpdateCDSDaqd segfaulting again

 The daqd process on the frame builder looks like it is segfaulting again.  It restarts itself every few minutes.  

The symptoms remind me of elog 9530, but /frames is only 93% full, so the cause must be different.  

Did anyone do anything to the fb today?  If you did, please post an elog to help point us in a direction for diagnostics.

Q!!!!  Can you please help?  I looked at the log files, but they are kind of mysterious to me - I can't really tell the difference between a current (bad) log file and an old (presumably fine) log file.  (I looked at 3 or 4 random, old log files, and they're all different in some ways, so I don't know which errors and warnings are real, and which are to be ignored).

  10622   Fri Oct 17 13:19:48 2014 JenneUpdateLSCPOP22 ?!?!

We've seen this before, but we need to figure out why POP22 decreases with decreased CARM offset.  If it's just a demod phase issue, we can perhaps track this by changing the demod phase as we go, but if we are actually losing control of the PRMI, that is something that we need to look into.

In other news, nice work Q!




  10625   Fri Oct 17 17:52:55 2014 JenneUpdateLSCRAM offsets

Last night I measured our RAM offsets and looked at how those affect the PRMI situation.  It seems like the RAM is not creating significant offsets that we need to worry about.

Words here about data gathering, calibration and calculations.

Step 1:  Lock PRMI on sideband, drive PRM at 675.13Hz with 100 counts (675Hz notches on in both MICH and PRCL).  Find peak heights for I-phases in DTT to get calibration number.

Step 2:  Same lock, drive ITMs differentially at 675.13Hz with 2,000 counts.  find peak heights for Q-phases in DTT to get calibration number.

Step 3:  Look up actuator calibrations.  PRM = 19.6e-9/f^2 meters/count and ITMs = 4.68e-9/f^2 meters/count.  So, I was driving PRM about 4pm, and the ITMs about 20pm.

Step 4:  Unlock PRMI, allow flashes, collect time series data of REFL RF siganls.

Step 5: Significantly misalign ITMs, collect RAM offset time series data.

Step 6: Close PSL shutter, collect dark offset time series data.

Step 7: Apply calibration to each PD time series.  For each I-phase of PDs, calibration is (PRM actuator / peak height from step 1).  For each Q-phase of PDs, calibration is (ITM actuator / peak height from step 2).

Step 8:  Look at DC difference between RAM offset and dark offset of each PD.  This is the first 4 rows of data in the summary table below.

Step 9:  Look at what peak-to-peak values of signals mean.  For PRCL, I used the largest pk-pk values in the plots below.  For MICH I used a calculation of what a half of a fringe is - bright to dark.  (Whole fringe distance) = (lambda/2), so I estimate that a half fringe is (lambda/4), which is 266nm for IR.  This is the next 4 rows of data in the table.

Step 10: Divide.  This ratio (RAM offset / pk-pk value) is my estimate of how important the RAM offset is to each length degree of freedom. 

Summary table:

  PRCL (I-phase) MICH (Q-phase)
RAM offsets    
11 4e-11 m 2.1e-9 m
33 1.5e-11 m ~2e-9 m
55 2.2e-11 m ~1e-9 m
165 ~1e-11 m ~1e-9 m
Pk-pk (PDH or fringes) PDH pk-pk from flashes MICH fringes from calculation
11 5.5e-9 m 266e-9 m
33 6.9e-9 m 266e-9 m
55 2.5e-9 m 266e-9 m
165 5.8e-9 m 266e-9 m
Ratio: (RAM offset) / (pk-pk)    
11 7e-3 8e-4
33 2e-3 7e-3
55 9e-3 4e-3
165 2e-3 4e-3


Plots (Left side is several PRMI flashes, right side is a zoom to see the RAM offset more clearly):









  10626   Mon Oct 20 17:50:30 2014 JenneUpdateLSCCARM W/N TFs (Others were all wrong!)

I realized today that I had been plotting the wrong thing for all of my transfer functions for the last few weeks! 

The "CARM offsets" were correct, in that I was moving both ETMs, so all of the calculations were correct (which is good, since those took forever). But, in the plots I was just plotting the transfer function between driving ETMX and the given photodiode.  But, since just driving a single ETM is an admixture of CARM and DARM, the plots don't make any sense.  Ooops.

In these revised plots (and the .mat file attached to this elog), for each PD I extract from sigAC the transfer function between driving ETMX and the photodiode.  I also extract the TF between driving ETMY and the PD.  I then  sum those two transfer functions and divide by 2.  I multiply by the simple pendulum, which is my actuator transfer function to get to W/N, and plot.

The antispring plots don't change in shape, but the spring side plots do.  I think that this means that Rana's plots from last week are still true, so we can use the antispring side of TRX to get down to about 100 pm.

Here are the revised plots:




  10630   Wed Oct 22 02:35:45 2014 JenneUpdateLSCEfforts at hopping PRMI to REFL165

[EricQ, Jenne]

The first half of our evening was spent working on CARM and DARM in PRFPMI, and then we moved on to the PRMI part.

I moved the DARM ALSdiff -> TransDiff transition to be after the CARM ALScomm -> SqrtInvTrans transition in the carm_cm_up script.  After I did that, I succeeded every time (at least  10?  We did it many times) to get both CARM and DARM off of the ALS signals. 

We tried for a little while looking at transitioning to REFL11 normalized by the sum of the transmissions, but we kept losing lock.  We also several times lost lock at arm powers of a few, when we thought we weren't touching the IFO for any transitions.  Looking at the lockloss time series did not show any obvious oscillations in any of the _IN1 or _OUT channels for the length degrees of freedom, so we don't know why we lost lock, but it doesn't seem to be loop oscillations caused by changing optical gain.  Also, one time, I tried engaging Rana's "Lead 350" filter in FM7 of the CARM filter bank when we were on sqrtInvTrans for CARM, and the arm powers were around a few, but that caused the transmission signals to start to oscillate, and after one or two seconds we lost lock.  We haven't tried the phase lead filter again, nor have we tried the Boost2 that is in FM8. 

We increased the REFL11 analog gain from 0dB to 12dB, and then reset the dark offsets, but still weren't able to move CARM to normalized REFL11. Also, I changed the POP22 demod phase from 159 degrees to 139 degrees. This seems to be where the signal is maximized in the I-phase, while the arms are held off resonance, and also partway up the resonance peak. 

We then decided that we should go back to the PRMI situation before trying to reduce the CARM offset further.  We can robustly and quickly lock the PRMI on REFL33 while the arms are held off resonance with ALS.  So, we have been trying to acquire on  REFL33 I&Q, and then look at switching to REFL 165 I&Q.  It seems pretty easy to get PRCL over to REFL165 I (while leaving MICH on REFL33 I).  For REFL33, both matrix elements are +1.  For PRCL on REFL165, the matrix element is -0.08.  We have not successfully gotten MICH over to REFL 165 ever this evening. 

We went back and set the REFL165 I&Q offsets so that the outputs after the demod phase were both fluctuating around 0.  I don't know if they were around +/-100 because our dark offsets were bad or what, but we thought this would help.  We were still able to get PRCL transitioned no problem, but even after remeasuring the MICH REFL33 vs. REFL165 relative gains, we still can't transition MICH.  It seems like it's failing when the REFL33Q matrix element finally gets zeroed out, so we're not really getting enough signal in REFL165Q, or something like that, and throughout the rest of the transition we were depending entirely on REFL33Q. 

So. Plan:

  • Get PRMI on REFL165 while arms are held off resonance. 
    • May require PRCL-MICH FF decoupling, by combining error signals?
    • May require looking back at simulations to see what we expect the relative gains and signs to be.
  • Look at CARM loop stability in simulation for REFLDC, REFL11, and normalized REFL11.  Is there a stable loop path from about 100pm down to 0pm on normalized REFL11?
  10633   Thu Oct 23 01:39:34 2014 JenneUpdateCDSDaqd "fixed"?

Merging of threads. 

ChrisW figured out that it looks like the problem with the frame builder is that it's having to wait for disk access.  He has tweaked some things, and life has been soooo much better for Q and I this evening!  See Chris' elog at elog 10632.

In the last few hours we've had 2 or maybe 3 times that I've had to reconnect Dataviewer to the framebuilder, which is a significant improvement over having to do it every few minutes.

Also, Rossa is having trouble with DTT today, starting sometime around dinnertime.  Ottavia and Pianosa can do DTT things, but Rossa keeps getting "test timed out". 

  10634   Thu Oct 23 02:08:40 2014 JenneUpdateLSCIncreased DARM gain

I changed the carm_cm_up.sh script so that it requires fewer human interventions.  Rather than stopping and asking for things like "Press enter to confirm PRMI is locked", it checks for itself.  The sequence that we have in the up script works very reliably, so we don't need to babysit the first several steps anymore. 

Another innovation tonight that Q helped put in was servoing the CARM offset to get a certain arm power.  A failing of the script had been that depending on what the arm power was during transition over to sqrtInvTrans, the arm power was always different even if the digital offset value was the same.  So, now the script will servo (slowly!!) the offset such that the arm power goes to a preset value.

The biggest real IFO progress tonight was that I was able to actually measure the CARM and DARM loops (thanks ChrisW!), and so I discovered that even though we are using (TRX-TRY)/(TRX+TRY) for our IR DARM error signal, we needed to increase the digital gain for DARM as the CARM offset was reduced.  For ALS lock and DC trans diff up to arm powers of 3, we use the same ol' gain of 6.  However, between 3 - 6, we need a gain of 7.  Then, when we go to arm powers above 6 we need a gain of 7.5.  I was also measuring the CARM loop at each of these arm powers (4, 6, 7, 8, 9), but the gain of 4 that we use for sqrtInvTrans was still fine. 

So, the carm_cm_up script will do everything that it used to without any help (unless it fails to find IR resonance for ALS, or can't lock the PRMI, in which case it will ask for help), and then once it gets to these servo lines to slowly increase the arm power and increase the DARM gain, it will ask you to confirm before each step is taken.  The script should get you all the way to arm powers of 9, which is pretty much exactly 100pm according to Q's Mist plot that is posted.

The CARM and DARM loops (around the UGFs) don't seem to be appreciably changing shape as I increase the arm powers up to 9 (as long as I increase the DARM loop gain appropriately).  So, we may be able to go a little bit farther, but since we're at about 100pm, it might be time to look at whether we think REFL11 or REFLDC is going to be more promising in terms of loop stability for the rest of the way to resonance.

Here are some plots from this evening. 

First, the time I was able to get to and hold at arm powers of 9.  I have a striptool to show the long time trends, and then zooms of the lockloss.  I do not see any particular oscillations or anything that strikes me as the cause for the lockloss.  If anyone sees something, that would be helpful.




This next lockloss was interesting because the DARM started oscillating as soon as the normalization matrix elements were turned on for DARM on DC transmissions.  The script should be measuring values and putting in matrix elements that don't change the gain when they are turned on, but perhaps something didn't work as expected.  Anyhow, the arm powers were only 1ish at the time of lockloss.  There was some kind of glitch in the DARM_OUT (see 2nd plot below, and zoom in 3rd plot), but it doesn't seem to have caused the lockloss.




  10636   Thu Oct 23 17:45:54 2014 JenneUpdateGeneralPianosa frozen

Not sure why, but Pianosa was frozen.  Also couldn't ssh or ping.  So, I hard power cycled it.

  10637   Fri Oct 24 02:14:05 2014 JenneUpdateLSCIncreased DARM gain even more

[Jenne, Diego]

We spent the afternoon working on the new scan for IR resonance script.  It is getting much closer, although we need to work on a plan for the fine scanning at the end - so far, the result from the wavelet thing mis-estimates the true peak phase, and so if we jump to where it recommends, we are only at about half of the arm resonance.  So, in progress, but moving forward.

Tonight we repeated the process of reducing the CARM offset and measuring the DARM loop gain as we went.  I'm not sure if I just had the wrong numbers yesterday, or if the gains are changing day-by-day.  The gains that it wanted at given arm buildups were constant throughout this evening, but they are about a factor of 2 higher than yesterday.  If they really do change, we may need to implement a UGF servo for DARM.  New gains are in the carm_cm_up script.

We also actually saved our DARM loop measurements as a function of CARM offset (as indicated by arm buildups).  The loop stays the same through arm powers of 4.  However, once we get to arm powers of 6, the magnitude around 100 Hz starts to flatten out, and we get some weird features in the phase.  It's almost like the phase bubble has a peak growing out of it.  I saw these yesterday, and they just keep getting more pronounced as we go up to arm powers of 7, 8 and 9 (where we lost lock during the measurement).  The very last point in the power=9 trace was just before/during the lockloss, so I don't know if we trust it, or if it is real and telling us something important.  But, I think that it's time to see about getting both CARM and DARM onto a different set of error signals now that we're at about 100pm.


  10642   Mon Oct 27 22:19:17 2014 JenneUpdateCDSc1iscex restarted

I'm not sure why, but c1iscex did not want to do an mxstream restart.  It would complain at me that  "* ERROR:  mx_stream is already stopping."
Koji suggested that I reboot the machine, so I did.  I turned off the ETMX watchdog, and then did a remote reboot.  Everything came back nicely, and the mx_stream process seems to be running.

  10643   Tue Oct 28 01:12:57 2014 JenneUpdateSUSETMX bad :(

ETMX is misbehaving again.  I went to go squish his cable at the rack and at the satellite box, but it still happened at least once.

Anecdotally and without science, it seems to happen when ETMX is being asked to move a "big" amount.  If I move the sliders too quickly (steps of 1e-3, but holding down the arrow key for about 1 second) or if I offload the ASS outputs when they're too large (above 10ish?), ETMX jumps so that it's about 50 urad off in yaw according to the oplev (sometimes right, more often left), and either 0 or 50urad off in pitch (up if right in yaw, down if left in yaw). 

So far, by-hand slowly offloading the ASS outputs using the sliders seems to keep it happy.

I would ask if this is some DAC bit flipping or something, but it's happening for outputs through both the fast front ends (ASS offloading) and the slow computers (sliders moved too fast).  So.  I don't know what it could be, except the usual cable jiggling out issue.

Anyhow, annoying, but not a show stopper.

  10644   Tue Oct 28 02:44:08 2014 JenneUpdateSUSETMX bad :(

Okay, now ETMX's badness is a show-stopper.  I'm not sure why, but after this last lockloss, ETMX won't stay put.  Right now (as opposed to earlier tonight) it seems to only be happening when I enable LSC pushing on the SUS.  ETMX is happy to sit and stay locked on TEM00 green while I write this entry, but if I go and try to turn on the LSC it'll be wacky again.  Daytime work.

Anyhow, this is too bad, since I was feelin' pretty good about transitioning DARM over to AS55. 

I had a line on (50 counts at 503.1 Hz pushing differentially on the ETMs), and could clearly see the sign flip happen in normalized AS55Q between arm powers of 4 and 6.  The line also told me that I needed a matrix element of negative a few x10^-4 in the AS55Q -> DARM spot.  Unfortunately, I was missing a zero (so I was making my matrix element too big by a factor of 10) in my ezcastep line, so both times I tried to transition I lost lock. 

So.  I think that we should put values of 0.5 into the power normalization for our test case (I was using SRCL_IN1 as my tester) since that's the approximate value that the DCtrans uses, and see what size AS55Q matrix element DARM wants tomorrow (tonight was 1.6-3 x 10^-4, but with 1's in the normalization matrix).  I feel positive about us getting over to AS55. 

Also, Q is (I assume) going to work some more tomorrow on PRMI->REFL165, and Diego is going to re-test his new IR resonance finding script.  Manasa, if you're not swamped with other stuff, can you please see if you can have a look at ETMX?  Maybe don't change any settings, but see what things being turned on makes ETMX crazy (if it's still happening in the morning). 

  10652   Thu Oct 30 01:21:37 2014 JenneUpdateLSCNo MICH in REFL165

[Koji, Jenne, Diego]

Summary:  We really don't have any MICH signal in REFL 165.  Why is still a mystery.

We made several transfer function measurements while PRMI was locked on REFL33 with the arms held off resonance, and compared those to the case where the ETMs are misaligned.  We fine-tuned the REFL165 demod phase looking at the transfer function between 10-300 Hz (using bandpassed white noise injected in the MICH FF filter bank and looking at REFL165Q), rather than just a single line.  We did that at CARM offset of 3 counts (ALS locked), and then saw that as we reduced the CARM offset, the coherence between MICH injection and REFL165Q just goes down.  Any signal that is there seems to be dominated by PRCL. 

So, we're not sure why having the arms eats the MICH 165 signal, but it does.  Everyone should dream tonight about how this could happen. 

Koji suggested that if the signal is just lost in the noise, perhaps we could increase our modulation depth for 55MHz (currently at 0.26, a pretty beefy number already).  Alternatively, if instead the problem is that the MICH signal has rotated to be in line with the PRCL signal, there may be no hope (also, why would this happen?).

Anyhow, we'd like to understand why we don't have any MICH signal in REFL165 when the arm cavities are involved, but until we come up with a solution we'll stick with REFL33 and see how far that gets us. 

The only really worthwhile plot that I've got saved is the difference in these transfer functions when PRMI-only locked and PRMI+arms locked.  Green is PRMI-only, with the demod phase optimized by actuating on PRM and minimizing the peak in the Q signal.  Blue is PRMI with the arms held off resonance using the ALS signals, with the demod phase set again, in the same way.  We were expecting (at least, hoping) that the blue transfer function would have the same shape as the green, but clearly it doesn't.  The dip that is around 45 Hz can be moved by rotating the demod phase, which changes how much PRCL couples into the Q phase.  Weird.  At ~3nm we had somewhat reasonable coherence to RELF165Q, and were able to pick -102deg as the demod phase where the dip just disappears.  However, as the CARM offset is reduced, we lost coherence in the transfer functions.


  10686   Fri Nov 7 16:15:53 2014 JenneUpdateLSC3F RFPD RF spectra

I have found an SHP-150, but no SHP-175's (also, several 200's, and a couple of 500's).

Why do you say the SHP-150 isn't enough?  The blue peak at 10*fmod in your plot looks like it's at -12 dBm.  -13 dB on top of that will leave that peak at -25 dBm.  That should be enough to keep us from saturation, right?  It's not a lot of headroom, but we can give it a twirl until a 175-er comes in.  

Koji also suggests putting in a 110 MHz notch, combined with either an SHP-150 or SHP-175, although we'll have to measure the combined TF to make sure the notch doesn't spoil the high pass's response too much.



Minicircuits' SHP-150 only has 13dB suppression at 110MHz, which would not be enough either. SHP-175 has 31dB suppression at 110MHz and 0.82dB at 160MHz, maybe this is what we want.


  10696   Tue Nov 11 03:48:46 2014 JenneUpdateLSC3f DRMI

I was able to lock the DRMI on 3f signals this evening, although the loops are not stable, and I can hear oscillations in the speakers.  I think the big key to making this work was the placement of the SHP-150 high pass filter at the REFL165 PD, and also the installation of Koji's 110 MHz notch filter just before the amplifier, which is before the demod board for REFL165.  These were done to prevent RF signal distortion.

DRMI 3f:   With DRMI locked on 1f (MICH gain = 1, PRCL gain = -0.05, SRCL gain = 2, MICH = 1*REFL55Q, PRCL = 0.1*REFL11I, SRCL = 1*REFL165I), I excited lines, and found the signs and values for 3f matrix elements.  I was using the same gains, but MICH = 0.5*REFL165Q, PRCL = 0.8*REFL33I and SRCL = -0.2*REFL165I.  Part of the problem is likely that I need to include off-diagonal elements in the input matrix to remove PRCL from the SRCL error signal. 

With the DRMI locked on 1f, I took a sensing matrix measurement.  I don't think we believe the W/ct of the photodiode calibration (we need to redo this), but otherwise the sensing matrix measurement should be accurate.  Since the calibration of the PDs isn't for sure, the relative magnitude for signals between PDs shouldn't be taken as gospel, but within a single PD they should be fine for comparison. 

As a side note, we weren't sure about the MICH -> ITMs balancing, so we checked during a MICH-only, and with the locking apparatus we are unable to measure a difference between 1's for both ITMs in the output matrix, and 1 for ITMX and 0.99 for ITMY.  So, we can't measure 1% misbalances in the actuator, but we think we're at least pretty close to driving pure MICH. 

We kind of expect that SRCL should only be present in the 55 and 165 PDs, although we see it strongly in all of the REFL PDs.  Also, PRCL and SRCL are not both lined up in the I-phase.  So, I invite other people to check what they think the sensing matrix looks like. 

  • The excitation lines (and matching notches) were on from 12:14am (
  • Nov 11 2014 08:14:00 UTC / GPS 1099728856) to 12:20am (
  • Nov 11 2014 08:20:00 UTC / GPS 
  • 1099729216) for 360sec. 
  • MICH was driven with 800 counts at 675.13 Hz, with +1*ITMY, -1*ITMX. 
  • PRCL was driven with 1000 counts at 621.13 Hz with the PRM. 
  • SRCL was driven with 800 counts at 585.13 Hz using the SRM. 

All 3 degrees of freedom have notches at all 3 of those frequencies in the FM10 of the filter banks (and they were all turned on).  During this time, DRMI was locked with 1f signals. 

DRMI sensing matrix:


Earlier in the evening, I also took a PRMI sensing matrix, with the PRMI locked on REFL33 I&Q.  Watch out for the different placement of the plots - I couldn't measure AS55 in the DRMI case, since cdsutils.avg freaked out if I asked for more than 14 numbers (#PDs * #dofs) at a time.


Rana, Koji and I were staring at the DRMI sensing matrix for a little while, and we aren't sure why PRCL and SRCL aren't co-aligned, and why they aren't orthogonal to MICH.  Do we think it's possible to do something to digitally realign them?  Will the solution that we choose be valid for many CARM offsets, or do we have to change things every few steps (which we don't want to do)? 

Things to work on:

* Reanalyze DRMI sensing matrix data from 12:14-12:20am. 

* Make a simulated scan of higher order mode resonances in the arm cavities.  Is it possible that on one or both sides of the CARM resonance we are getting HOM resonances of the sidebands? 

* Figure out how to make DRMI 3f loops stable.

* Try CARM offset reduction with DRMI, and / or PRMI on REFL 165.

  10701   Wed Nov 12 03:22:23 2014 JenneUpdateLSC3f DRMI sensing mat

Koji pointed out something to me that I think he had told me ages ago, and Rana alluded to last night:  Since I'm not tuning my "demod phase" for the sensing matrix lockins, unless I happened to get very lucky, I was throwing away most of the signal.  Lame.  

So, now the magnitude is sqrt(real^2 + imag^2), where real and imag here are the I and Q outputs of the lockin demodulator, after the 0.1Hz lowpass.  (I put in the low pass into all of the Q filter banks).  To keep the signs consistent, I did do a rough tuning of those angles, so that I can use the sign of the real part as the sign of my signal.  When I was PRMI locked, I set the phase for all things acutated by MICH to be 79deg, all things actuated by PRCL to be 20 deg, and when DRMI locked set all things SRCL to be 50deg. 

After doing this, the phases of my sensing matrix output matches Koji's careful analyses.  I don't know where the W/ct numbers I was using came from (I don't think I made them up out of the blue, but I didn't document where they're from, so I need to remeasure them).  Anyhow, for now I have 1's in the calibration screen for the W/ct calibration for all PDs, so my sensing matrices are coming out in cts/m, which is the same unit that Koji's analysis is in. (Plot for comparing to Koji is at end of entry).

While reducing the CARM offset, I left the sensing matrix lines on, and watched how they evolved.  The phases don't seem to change all that much, but the magnitudes start to decrease as I increase the arm power.

For this screenshot, the left plot is the phases of the sensing matrix elements (all the REFL signals, MICH and PRCL), and the right plot is the magnitudes of those same elements.  Also plotted is the TRX power, as a proxy for CARM offset.  The y-scale for the TRX trace is 0-15.  The y-scale for all the phases is -360 to +360.  The y-scale of the magnitude traces are each one decade, on a log scale.


Bonus plot, same situation, but the next lock held for 20 minutes at arm powers of 8.  We don't know why we lost lock (none of the loops were oscillating, that I could see in the lockloss plot).


Here are some individual sensing matrix plots, for a single lock stretch, at various times.  One thing that you can see in the striptool screenshots that I don't know yet how to deal with for the radar plots is the error bars when the phase flips around by 360 degrees.  Anyhow, the errors in the phases certainly aren't as big as the error boxes make them look.

PRMI just locked, CARM offset about 3nm, CARM and DARM on ALS comm and diff, arm powers below 1:


PRMI still on REFL33 I&Q, CARM and DARM both on DC transmissions, arm powers about 4:


CARM offset reduced further, arm powers about 6:


CARM offset reduced even more, arm powers about 7:


For this plot for comparing with Koji's analysis, I had not yet put 1's in the calibration screen, so this is still in "W"/m, where "W" is meant to indicate that I don't really know the calibration at all.  What is good to see though is that the angles agree very well with Koji's analysis, even though he was analyzing data from yesterday, and this data was taken today.  This sensing matrix is DRMI-only (no arms), 1f locking.


Bonus plot, PRMI-only sensing matrix, with PRMI held using REFL 33 I&Q:



  10703   Wed Nov 12 18:08:35 2014 JenneUpdateLSCRIN in transmission a problem?

In my previous meditations about RIN, particularly elog 10258, I was only thinking about the RIN contribution at the offset that I was currently sitting at.  Also, In elog 10258 I was comparing to the ALS signals and just said that the trans signals are better which is true, although isn't super helpful when thinking of reduced CARM offsets. 

My summary today is that I think we want to reduce the RIN in arm transmissions by a factor of 3.

Rather than dig around, I just remeasured the RIN, for both the single arm transmissions and the MC transmission.  (Data attached as .xml file)

The RMS RIN for the Xarm is 1.3e-2.  The RMS RIN for the Yarm is 8.9e-3.  The RMS RIN for MCtrans is 4.0e-3.  For the simulations below, I will use 1e-2 as an average RIN for the arms.


As an estimate of the RIN's contribution to cavity fluctuations, I divide the RIN by the slope of the CARM transmission peak.  The slope (from optickle) gives me [ delta-W / delta-m ], and the inverse of that gives me [ delta-m / delta-W ].  I multiply this by RIN, which is [ delta-W / W ] to get [delta-m / W]. 

Then, since I'm using the DC transmission signals as my error signals, I use just TRX (normalized to be 1 for single arm resonance) as my Watts.

So, in total, the traces plotted are { TRX * RIN / slope }. 

The 2 plots are the same data, one with linear-x and the other with log-x.  They both include my estimate of the cavity length fluctuations due to RIN at the arm transmission, as well as an estimate of the cavity length fluctuations if the arm RIN was as good as the MC RIN.  I also show the DRFPMI CARM linewidth (23 pm for HWHM), and 1% of that linewidth.  The last trace is 1% of the half-width of the transmission peak, at the current CARM offset.  For example, 1000 pm away from full resonance the half-width is 1000 pm and 1% of that is 10 pm. 


What we want to see here is that the solid blue line is below one of the dotted lines.  I think that using the overall linewidth (purple dotted line) isn't really the right thing to look at.  Our goal is to prevent excursions that will get too close to the resonance peak, and cause a lockloss.  A one picometer excursion is a much bigger problem (relatively) below say 100 pm, as opposed to above 100 pm.  So, I think that we should be looking at the half-width of the resonance peak at whatever the current CARM offset is (orange dotted line).  Above 25 pm, the blue line is below the orange line for all offsets plotted.  If we made the arm RIN as good as the MC RIN, that would be true down to 12-ish pm. 

We should be able to safely transition to non-normalized RF signals at 10pm or below.  This implies that (since any RF signals normalized by this RIN-y trans signal will have the RIN), we want to improve the RIN of the transmission PDs by about a factor of 3. (This will lower the blue line such that it crosses the orange dotted line at 10 pm).


  10709   Thu Nov 13 04:28:28 2014 JenneUpdateLSCRIN in transmission a problem?

[Jenne, Rana, Koji]

We did some thinking on what could be causing the excess RIN that we see in the arm transmissions but not in the MC transmission.  Unfortunately, I don't think we have anything conclusive yet. 

We thought about:

  • Test mass oplevs
  • Input tip tilt jitter
  • MC motion


As Rana reported in elog 10708, we tuned the oplev servos for ITMX, ETMX, ITMY and ETMY.  They all now look like the new SRM oplevs that Rana described in elog 10694.  However, when we re-looked at the RIN after the oplev tuning, we did not see a noticeable change.  So, fixing up the oplevs didn't fix up the RIN.

Side notes:

  • Several optics had low gains for suspos, which were increased to give Qs of ~5ish.
  • When we gave ITMX a 500 count step in pitch (the same size used for all other optics in both pit and yaw), it didn't come back afterward.  This is a little disconcerting.  Rana had to move the alignment slider to get it back so that we had MICH fringing at the AS port again.

Input Tip Tilts

Koji did some work, reported in elog 10706, on how much the jitter of the input pointing tip tilts should affect us.  We don't think that they are moving enough to be the cause of the excess RIN that we see.

Mode Cleaner Motion

We see some coherence between MC2 suspit and TRX/TRY, so we suspect that the MC's motion could be causing problems. 

I looked at the WFS vs. TRX & TRY, and saw significant coherence at the 3 Hz stack resonance.  I think it's clear that the WFS can help suppress this motion more.  The WFS noise level was too bad to see any other coherence at other frequencies. (Side note:  We should consider increasing the analog WFS signal.  As Rana mentioned back in 2008 in elog 454, the signal is super small.  Increasing the analog gain could allow us to suppress motion at more frequencies, although it would be a bit of a pain.)

To try and get some more signal, I routed the IPPOS beam over to the PRM oplev temporarily.  The idea was to be able to look at the IPPOS port, but with a fast channel.  I turned off the BS/PRM HeNe, and removed the last steering mirror before the QPD.  I put in 2 Y1 steering mirrors to get the IPPOS beam across the table and pointing at IPPOS.  I took my measurements 3 times, with different beam sizes on the QPD, to try to image different gouy phases.  I used absorptive ND filters (0.6 + 0.1) to get the light level on the PD such that I had about 10,000 counts per quadrant, where 16,000 counts seemed to be the saturation point. I also reset the dark offsets of the QPD quadrants, although they were so small that I don't think it did much.  I also took out the optical lever calibration from counts to microradians, since that number isn't meaningful for what I was doing.  So, the IPPOS signals (using the PRM oplev channels) are in raw ADC counts.  The first measurement had no lens, and the beam was probably at least half the size of the QPD.  The second measurement had a lens, and the beam on the QPD was about half the original size.  The third measurement had the lens closer to the QPD, so that the beam was about 1mm on the diode.  In none of these cases do I see any significant coherence with the TRX/TRY RIN signals, except at 3 Hz. After my measurements I put the oplev back including all of the digital settings, although for now I just left the IPPOS beam dumped on a razor dump, since it wasn't being used anyway.  I need to realign IPPOS when it's not the middle of the night.

Some thoughts that we have:

  • Maybe it's time to resurrect seismic feedforward on MC length, to suppress some of this 3 Hz motion?
  • Maybe we should be using the MC_L path to offload some of the frequency feedback, so that we're not pushing on MC2 so hard (because if we have bad F2P coupling, this creates beam motion)

I have plots for each of my IPPOS vs. TRX/TRY measurements.  The data is attached.  For each, I looked at the transfer function between IPPOS (using the SUS-PRM_OPLEV channels) and TRX/TRY to get the 'calibration' between input beam motion and transmission RIN.  In all cases, at 3 Hz the coefficient was about 1, so in the power spectra on the right side, there is no calibration applied to the IPPOS signals. 

IPPOS vs. Transmission RIN, no lens, big beam on QPD:


(Just kidding about the other 2 plots - the elog can't handle it.  They're in the zippyzip file though, and I don't think they look qualitatively different from the no-lens case).


  10712   Thu Nov 13 23:42:01 2014 JenneUpdateLSCRIN vs. Seismic

After Kate, Diego and I moved the seismometers to the corner for a huddle test (see elog 10711), I wanted to check the coherence between the seismometers and the arm transmissions.  

First of all, it looks like either the Guralp or the T-240 have their X and Y backwards. Diego is going to check this tomorrow. 

Between 0.9Hz - 3.5Hz, we have pretty strong coherence with the horizontal seismic channels.  Interestingly, between 8-10Hz, the Yarm has pretty strong coherence with the Z-axes of the seismometers (the coherence is only about 0.6, but it's consistent over a 2-ish Hz wide band). 

The MC transmission doesn't have as much coherence with the seismic, which surprised me.  So, we can try some FF to the MC, but we may also have to do some to the arms.


  10717   Fri Nov 14 15:45:34 2014 JenneUpdateCDSComputers back up after reboot

[Jenne, Q]

Everything seems to be back up and running.

The computers weren't such a big problem (or at least didn't seem to be).  I turned off the watchdogs, and remotely rebooted all of the computers (except for c1lsc, which Manasa already had gotten working).  After this, I also ssh-ed to c1lsc and restarted all of the models, since half of them froze or something while the other computers were being power cycled. 

However, this power cycling somehow completely screwed up the vertex suspensions.  The MC suspensions were fine, and SRM was fine, but the ITMs, BS and PRM were not damping.  To get them to kind of damp rather than ring up, we had to flip the signs on the pos and pit gains.  Also, we were a little suspicious of potential channel-hopping, since touching one optic was occasionally time-coincident with another optic ringing up.  So, no hard evidence on the channel hopping, but suspicions.

Anyhow, at some point I was concerned about the suspension slow computer, since the watchdogs weren't tripping even though the osem sensor rmses were well over the thresholds, so I keyed that crate.  After this, the watchdogs tripped as expected when we enabled damping but the RMS was higher than the threshold.

I eventually remotely rebooted c1sus again.  This totally fixed everything.  We put all of the local damping gains back to the values that we found them (in particular, undoing our sign flips), and everything seems good again.  I don't know what happened, but we're back online now. 

Q notes that the bounce mode for at least ITMX (haven't checked the others) is rung up.  We should check if it is starting to go down in a few hours.

Also, the FSS slow servo was not running, we restarted it on op340m.

  10718   Fri Nov 14 17:08:17 2014 JenneUpdateLSCRIN vs. Seismic

T-240 has a different convention than we use.  It assumes that North is aligned with the Y-axis.  Since this is the new guy, and we've been using the Guralps with North = X for many years, Diego and I rotated the T-240, and put a label on it that N/S is Y, and E/W is X.  Obviously Vert is still Z.

  10719   Fri Nov 14 19:28:33 2014 JenneUpdateSUSASS gain reduced for Yarm

[Koji, Jenne]

We noticed last night that the yarm couldn't handle the old nominal gain for the ASS servos.  We were able to run the ASS using about 0.3 in the overall gain.  So, I have reduced the gain in each of the individual servos by a factor of 3, so that the scripts work, and can set the overall gain to 1.

  10724   Mon Nov 17 23:04:51 2014 JenneUpdatePSLAligned PMC

I aligned the beam into the PMC, mostly in yaw.  Don't know why it drifted, but it was annoying me, so I fixed it.

  10725   Tue Nov 18 15:20:58 2014 JenneUpdateLSCSome lockloss plots from PRFPMI

Elog from ~5am last night:

Tonight was just several trials of PRFPMI locking, while trying to pay more attention to the lockloss plots each time.

General notes: 

I tried once to acquire DRMI on 1f while the arms were held off resonance.  I wasn't catching lock, so I went back to PRMI+arms.  I aligned the PMC, which I noted in a separate elog.  

I was able to hold the PRMI on REFL33I&Q, and have ALS CARM and DARM at zero CARM offset.  The arm would "buzz" through the resonance regularly.  I use the word buzz because that's kind of what it sounded like.  This is the noise of the ALS system.

I think we want to add the transmission QPD angular signals to the frames.  Right now, we just keep the sums.  It would have been handy to glance at them, and see if they were wiggling in the same way that some other signal was waggling. 

All the data files are in /opt/rtcds/caltech/c1/scripts/LSC/LocklossData.  Each folder is one lockloss.  It includes text files for each trace, as well as any plots that I've made, and any notes taken.  The text files are several MB each, so I'm not going to bog the elog down with them.  There are a few folders that end in "_notInteresting".  These ones are, as one might guess, not interesting.  2 were MC locklosses (I'm not actuating on MC2, so I declared these independent from my work) and one was when I knew that my ALS was bad - the beatnotes weren't in good places, and so the ALS noise was high.

 Folder:  1100342268_POP22goesLow

Working notes:  Lost lock because POP22 went too low.  PRCL and MICH triggered off.  After this, changed PRCL and MICH "down" thresholds to 0.5, from 10.



Conclusion:  Easy fix.  Changed the down thresholds for MICH and PRCL to be lower, although still low enough that they will trigger off for a true lockloss.  Why though do we lose so much sideband power when the arm transmission goes high?  POP22 dipped below 10 when TRX went above 29.  Does this happen on both sides of the CARM offset?  Quick simulation needed.


Folder:  1100330534_maybePRCLangular

Working notes:  PRFPMI, reducing CARM offset to arm powers of 7.  CARM on sqrtInv, DARM on DCtrans. PRMI on REFL33 I&Q. Don't know why I lost lock.  Maybe angular stuff in PRC? I think POP spot was moving in yaw as it started to go bad.
Note, later:  regathered data to also get POP angular stuff. Don't think it's POP angular.  Not sure what it is.



Conclusion:  I'm not sure what this lockloss was caused by, although it is not something that I can see in the POP QPD (which was my initial suspicion).  It is, like many of the rest of the cases, one where I see significant bounce and roll mode oscillations (error and control signals oscillating at 16 and 24 Hz).  I don't think those are causing the locklosses though.


Folder:  1100334680_unknown_highArmPowers

Working notes:  PRFPMI, carm_up script finished, sitting at arm powers of 8.  CARM, DARM on DC trans.  PRMI on REFL33.   Don't know why lost lock.


[Don't have any? - I'll make some]

Conclusion:  Again, I see 16 and 24 Hz oscillations, but I don't think those are causing the lockloss.


Folder: 1100331950_unknown

Working notes: PRFPMI, arms about 8.  CARM, DARM on DC trans.  PRMI on REFL33.  Don't know why I lost lock.



Conclusion: Don't have an answer.


Folder: 1100345981_unknown

Working notes: Lockloss while going to arm powers of 7ish from 6ish.  Not POP angular, POP22 didn't go low.



Conclusions:  This one wasn't from POP22 going too low, but again, I don't see anything other than 16 and 24Hz stuff.


  10726   Tue Nov 18 17:11:30 2014 JenneUpdateLSCSome lockloss plots from PRFPMI

I am still staring at / trying to figure out the latter 4 locklosses posted earlier.  But, I have just included the transmission QPD angular output signals to the frames, so we should be able to look at that with locklosses tonight. 

To get the lockloss plots:  in ..../scripts/LSC/LocklossData/ , first run ./FindLockloss.sh <gps time> .  This just pulls the TRX and TRY data, and doesn't save it, so it is pretty quick.  Adjust the gps time until you capture the lockloss in your plot window.  Then run ./LockLossAutoPlot.sh <gps time> to download and save the data.  Since it has become so many channels, it first makes a plot with all of the error and control signals, and then it makes a plot with the power levels and angular signals.  The data folder is just called <gps time>.  I have started also including a text file called notes inside of the folder, with things that I notice in the moment, when I lose lock.  Don't use .txt for the suffix of the notes file, since the ./PlotLockloss.py <folder name> script that will plot data after the fact tries to plot all .txt files.  I have also been appending the folder name with keywords, particularly _notInteresting or _unknown for either obvious lockloss causes or mysterious lockloss cases.


  10727   Tue Nov 18 22:34:28 2014 JenneUpdateLSCSome other plots from PRFPMI


I was able to hold the PRMI on REFL33I&Q, and have ALS CARM and DARM at zero CARM offset.  The arm would "buzz" through the resonance regularly.  I use the word buzz because that's kind of what it sounded like.  This is the noise of the ALS system.

Here is a plot of when the arm powers went pretty high from last night.  CARM and DARM were on ALS comm and diff, PRMI was on REFL33 I&Q.  I set the CARM offset so that I was getting some full arm resonances, and it goes back and forth over the resonance.

The Y axes aren't perfect when I zoom, but the maximum TRX value was 98 in this plot, while the max TRY value was 107. 

MICH_OUT was hitting its digital rails sometimes, and also it looks like PRCL and MICH occasionally lost lock for very brief periods of time. 

Glitch-like events in PRCL_OUT are at the edges of these mini-locklosses. I don't know why POPDC has glitch-y things, but we should see if that's real.


Okay, I've zoomed in a bit, and have found that, interestingly, I see that both POP22 and POP110 decrease, then increase, then decrease again as we pass through full resonance.  This happens in enough places that I'm pretty sure we're not just going back and forth on one side of the resonance, but that we're actually passing through it.  Q pointed out that maybe our demod phase angle is rotating, so I've made some zoom-in plots to see that that's not a significant effect.  I plot the I and Q phases individually, as well as the total=sqrt(I**2 + Q**2), along with TRY (since the increases and decreases are common to both arms, as seen in the plot above).

For POP 22:


For POP 110:


I also plot the MICH and PRCL error signals along with TRY and POP22 total.  You can see that both MICH and PRCL were triggered off about 0.1msec after POP22 total this it's first super low point.  Then, as soon as POP22 becomes large enough, they're triggered back on, which happens about 1.5msec later. (The triggering was actually on POP22I, not POP22tot, but the shapes are the same, and I didn't want to overcrowd my plots).


I am not sure if we consistently lose sideband signal in the PRC more on one side of the CARM resonance than the other, but at least POP22 and POP110 are both lower on the farther side of this particular peak.  I want to think about this more in relation to the simulations that we've done.  One of the more recent things that I see from Q is from September:  elog 10502, although this is looking specifically at the REFL signals at 3f, not the 2f circulating PRCL power as a function of CARM offset.

  10734   Tue Nov 25 02:04:19 2014 JenneUpdateLSCPRFPMI tonight - need some PRCL and MICH tuning at high arm powers

Take-away for the night:  We need to do some more fine-tuning of the PRCL and MICH loops when we have arm resonance.

Koji sat with me for the first part of the night, and we looked back at the data from last week (elog 10727), as well as some fresh data from tonight.  Looking at the spectra, we noticed that last week, and early in the evening today, I had a fairly broad peak centered around ~51Hz.  We are not at all sure where this is coming from.  The PRMI was locked on REFL 33 I&Q, and CARM and DARM were both on ALS comm and diff.  This peak would repeat-ably come and go when I changed the CARM offset.  At high arm powers (above a few tens? I don't know where exactly), the peak would show up.  Move off resonance, and the peak goes away.  However, later in the night, after an IFO realignment, I wasn't able to reproduce this effect.  So.  We aren't sure where it comes from, but it is visible only in the CARM spectra, so there's some definite feedback funny business going on. 

Anyhow, after that, since I couldn't reproduce it, I went on to trying to hold the PRMI at high arm powers, but wasn't so successful.  I would reduce the CARM offset, and instead of a 50Hz peak, I would get broadband noise in the PRMI error signals, that would eventually also couple in to the CARM (but not DARM) error signal, and I would lose PRMI lock. I measured the PRCL and MICH transfer functions while the arms were at some few units of power, and found that while MICH was fine, PRCL was losing too much phase at 100Hz, so I took away the FM3 boost.  This helped, but not enough. I had 1's in the triggering matrix for TRX and TRY to both PRCL and MICH, so that even if POP22 went low, if the arms were still locked then the PRMI wouldn't lose lock unnecessarily, but I was still having trouble.  In an effort to get around this, I transitioned PRMI over to REFL 165 I&Q. 

While the arms were held around powers of 2ish, I readjusted the REFL 165 demod phase.  I found it set to 150 deg, but 75 deg is better for PRMI locking with the arms.  For either acquiring or transitioning from REFL33, I would use REFL165I * -1.5 for PRCL, and REFL 165Q * 0.75 for MICH.  (Actually, I was using -2 for REFL165I->PRCL, and +0.9 for REFL165Q->MICH, but I had to lower the servo gains, so doing some a posteriori math gives me -1.5 and +0.75 for what my matrix elements should have been, if I wanted to leave my servo gains at 2.4 for MICH and -0.02 for PRCL.) I don't always acquire on REFL165, and if it's taking a while I'll go back to putting 1's in the REFL33 I&Q matrix elements and then make the transition. 

With PRMI on REFL 165 I&Q, I no longer had any trouble keeping the PRMI locked at arbitrarily high arm powers.  I was still using 1*POP22I + 1*TRX + 1*TRY for triggering PRCL and MICH.  My thresholds were 50 up, 0.1 down.  The idea is that even if POP goes low (which we've seen about halfway up the CARM resonance), if we're getting some power recycling and the arms are above 1ish, then that means that the PRMI is still locked and we shouldn't un-trigger anything.  I didn't try switching over to POP110 for triggering, because POP22 was working fine.

Earlier in the night, Koji and I had seen brief linear regions in POX and POY, as well as some of the REFL signals when we passed quickly through the CARM resonance.  I don't have plots of these, but they should be easy to reproduce tomorrow night.  Koji tried a few times to blend in some POY to the CARM error signal, but we were not ever successful with that.  But, since we can see the PDH-y looking regions, there may be some hope, especially if Q tells us about his super secret new CESAR plan. 

Okay, I'm clearly too tired to be writing, but here are some plots.  The message from these is that the PRMI loops are causing us to fluctuate wildly in arm transmission power.  We should fix this, since it won't go away by getting off of ALS.  The plots are from a time when I had the PRMI locked on REFL165, and CARM and DARM were still on ALS comm and diff.  All 3 of these colored plots have the same x-axis.   They should really be one giant stacked plot.




Also, bonus plot of a time when the arm powers went almost to 200:


  10736   Wed Nov 26 05:15:48 2014 JenneUpdateLSCPRFPMI tonight PRMI 100Hz osc?

[Jenne, EricQ]

Just to get our day started right, we tweaked up the alignment of the Ygreen to the Yarm (after IR alignment), and also touched up the X beatnote alignment on the PSL table.  Ran the LSC offsets script, and then started locking. 

All of the locking tonight has been based on CARM and DARM held on ALS comm/diff, and PRMI held on REFL165.  Today, CARM was actuated using MC2.  No special reason for the switch from ETMs. The AS port is noticeably darker when using REFL165 instead of REFL33. 

Around 12:33am(ish), we were able to hold the arms at powers of about 100, for almost a minute.  The fluctuations were at least 50% of that value, but the average was pretty high.  Exciting.

Q and I tried a few times to engage the AO path while the arms were held at these high powers.  Q hopefully remembers what the gain and sign values were where we lost lock.  We didn't pursue this very far, since I was seeing the 50Hz oscillation that Koji and I saw the other day.  I increased the CARM gain from 6 to 10, and that seemed to help significantly.  Also, messing with the PRMI loops a bit helped.  Q increased the pole frequency in FM 5 for both MICH and PRCL from 2k to 3k.  While he had Foton open, he made sure that all of the LSC DoF filters use the z:p notation. 

I then did a few trials of trying to transition CARM over to normalized REFL11I.  Now that I'm typing, it occurs to me that I should have checked REFL11's demod phase.  Ooops.  Anyhow, using the phase that was in there, I turned on a cal line pushing on ETMs CARM, and found that using -0.002*REFL11I / (TRX + TRY) was the right set of elements.  I also put an offset of 0.05 into the CARM CESAR RF place, and started moving.  I tried several times, but never got past about 30% normalized REFL11 and 70% ALS comm. 

During these trials, Q and I worked also on tweaking up the PRMI lock.  As mentioned last night, PRCL FM3 eats too much phase (~30deg at 100Hz!), so I don't turn that on ever.  But, I do turn on FM1 (which is new tonight), FM2, 6, 8 and 9.  FM8 is a flat gain of 0.6 that I use so I can have higher gain to make acquisition faster, but immediately turn the gain down to keep the loop in the center of the phase bubble.  MICH needed a lowpass, so in addition to FM2, I am now also triggering FM 8, which is a 400Hz lowpass that was already in there. 

Now, my MICH gain is 2.4, with +0.75*REFL165Q, and PRCL gain is -0.02 with -3*REFL165I.  Triggering for both MICH and PRCL is 1*POP22I + 5*TRX with 50 up, 0.1 down. 

In my latest set of locks, I have been losing lock semi-regularly due to a 100Hz oscillation in either the PRCL or MICH loops.  If I watch the spectra, most times I take a step in CARM offset reduction, I get a broad peak in both the MICH and PRCL error signals.  Most of the time, I stay locked, and the oscillation dies away.  Sometimes though it is large enough to put me out of lock.  I'm not sure yet where this is coming from, but I think it's the next thing that needs fixing.

Here is a shot of the spectra just as one of these 100Hz oscillations shows up.  The dashed traces are the nominal error signals when I'm sitting at some CARM offset, and the solid traces are just after a step has been made. The glitch is only happening in the PRMI, not CARM and DARM. 


  10737   Wed Nov 26 22:24:28 2014 JenneUpdateLSCDARM loop improved, other work

[Jenne, Koji]

We have done several things this evening, which have incrementally helped the lock stability.  We are still locking CARM and DARM on ALS, and PRMI on REFL165.

  • Saw peaks in CARM error signal at 24Hz and 29 Hz, so put in moderate-Q resonant gains. 
  • DARM at low frequency was much noisier than CARM.  We discovered that we had put in a nice boost at some point for CARM in FM1, but hadn't transferred that over to DARM.  Copying FM1 from CARM to DARM (so replacing an integrator with a boost below ~10Hz) dropped the DARM noise down to match the CARM noise at low frequencies.
  • Koji noticed that we were really only illuminating one quadrant of the Xend QPD, so we aligned both trans QPDs.  Also, I reset the transmission normalization so that all 4 diodes (Thorlabs and QPDs at each end) all read 1 with good alignment.
  • We've got some concerns about the ASS.  It needs some attention and tuning.
    • The X ASS needs an overall gain of about 0.3.  This may be because I forgot to put the new lower gains into the burt restore after Rana's oplev work, or this may be something new.
    • When Koji did a very careful arm alignment, we turned on the Y ASS and saw it methodically reduce the transmitted power.  Mostly it was moving ETMY in yaw.  Why is the DC response of the ASS not good?  The oplev work shouldn't have affected DC.
    • We don't like the way the ASS offloads the alignment.  Maybe there's a better way to do it overall, but one thought is to have an option to offload (for long-term alignment fixing, so maybe once a day) and another option to just freeze the current output (for the continual tweak-ups that we do throughout the evening).  We'd want the ASS to start up again with these frozen values, and not clear them.
  • ETMY was being fussy, in the same way that ETMX had been for the last few months.  I went down to squish the cables, and found that it was totally not strain-relieved, and that the cable was pulling on the connector.  I have zip tied the cable to the rack so that it's not pulling anymore.
  • At high arm powers, it is hard to see what is going on at the AS port because there is so much light.  Koji has added an ND filter to the AS camera so that we can more easily tweak alignment to improve the contrast.

Something that has been bothering me the last few days is that early in the evening, I would be able to get to very high arm powers, but later on I couldn't.  I think this has to do with setting the contrast at the AS port separately for the sideband versus the carrier.  I had been minimizing the AS port power with the arms held off resonance, PRMI locked.  But, this is mostly sideband.  If instead I optimize the Michelson fringes when the arms are held with ALS at arm powers of 1, and PRM is still misaligned, I end up with much higher arm powers later.  Some notes about this though:  most of this alignment was done with the arm cavity mirrors, specifically the ETMs, to get the nice Michelson fringes.  When the PRM is restored and the PRMI locked, the AS port contrast doesn't look very good.  However, when I leave the alignment alone at this point, I get up to arm powers above 100, whereas if I touch the BS, I have trouble getting above 50.

Around GPS time 1101094920, I moved the DARM offset after optimizing the CARM offset.  We were able to see a pretty nice zero crossing in AS55, although that wasn't at the same place as the ALS diff zero offset (close though).  At this time, the arm powers got above 250, and TRY claimed almost 200.  These are the plots below, first as a wide-view, then zoomed in.  During this time, PRCL still has a broadband increase in noise when the arm powers are high, and CARM is seeing a resonance at a few tens of Hz.  But, we can nicely see the zerocrossing in AS55, so I think there's hope of being able to transition DARM over. 





Now, the same data, but zoomed in more.





During the 40m meeting, we had a few ideas of directions to pursue for locking:

  • Look into using POX or POY as a proxy for POP and instead of REFL, for CARM control.  Maybe we have some nice juicy SNR.
  • Check the linearity of our REFL signals by holding the arms on (or close to) resonance, then do a swept sine exciting CARM ctrl and taking a transfer function to the RF signals.
  • Q is going to look into the TRX QPD, since he thought it looked funny last week, although this may no longer be necessary after we put the beam at the center of the QPD.
  • Koji had a thought for making it easier to blend the CARM error signals.  What if we put a pole into the ALS CARM signals at the place where the final coupled cavity pole will be, and then compensate for this in the CARM loop.  Since any IR signals will naturally have this pole, we want the CARM loop to be stable when it's present.
  • Diego tells us that the Xarm IR beatnote is basically ready to go.  We need to see how big the peak is so we can put it into the frequency counter and read it out via EPICS.  The freq counter wants at least -15dBm, so we may need an amplifier.
  10740   Mon Dec 1 16:34:20 2014 JenneUpdateGeneralIFO wake-up


 After its' several days of rest, it is time to wake up the IFO. 

  • FSS temp was railed at +10, which was making the MC not want to lock.  Set it to zero, locked the MC, and ran the MC WFS relief scripts.
  • PMC trans is down to 0.686, so I'll probably want to tweak that up before I get too carried away for tonight. 
  • c1iscex computer was frozen, which I suspect is why Steve found ETMX tripped this morning.  Soft reboot, and we're back to normal.

With that, it's time for a new week of locking, and trying to catch up with the big kids at the sites.

  10742   Mon Dec 1 17:19:22 2014 JenneUpdateGeneralPMC align

[Diego, Jenne]

Tweaked up the input alignment to the PMC.  Now we're at 0.785.

  10743   Mon Dec 1 17:43:22 2014 JenneUpdateLSCReset Yarm trans normalization

After Koji and I reset the transmission normalizations last Friday, he did some alignment work that increased the Yarm power.  So, I had set the transmission normalization when we weren't really at full Yarm power.  Today I reset the normalization so that instead of ~1.2, the Y transmission PDs read ~1.0.

  10746   Tue Dec 2 02:44:45 2014 JenneUpdateLSCTried cav pole compensation trick - fail

[Jenne, Diego]

First, random notes:

  • saw a violin peak in CARM / DARM at 638.0Hz.  Assumed it was one of the ETMs, even though it doesn't match any of the frequencies in our handy-dandy chart: wiki resonances
    • Put an extra notch in the ETM violin filters.
    • Just now realized that I was actuating MC2 at the time for CARM (although 638 is also not what we have in the chart for MC2).  The MC2/ETM violin filters should be shared between eachother.
  • Measured CARM and DARM loops on ALS comm and diff, gains should be 8, not 6.  Fixed in Lock_ALS_CARM_and_DARM script. 
  • MC has been fussy tonight.  I started actuating CARM on ETMs, and that helped, but we've still had several unexplained MC locklosses. 
    • PC and FSS Slow are okay right now, but they have been mad earlier tonight.  Do we need to check the PID tuning for FSS slow?
  • When I first started locking this evening, I was able to hold nice high arm powers (with the usual factor of 2+ RIN), so the IFO seemed okay except for the fussy MC.

Koji suggested last week that we put a cavity pole filter into the ALS error signals, and then compensate for that in the CARM and DARM servos.  The idea is that any RF signals we want to transfer to will have some kind of frequency dependence, and at the final zero CARM offset that will be a simple cavity pole. 

I put a pole at 200 Hz, with a zero at 6 kHz into the LSC-ALS[X,Y] filter banks in FM1, and then also put a zero at 200 Hz with a pole at 6 kHz into both the CARM and DARM servos at FM7.  Ideally I wouldn't have the 6kHz in there, but the compensation filter in the CARM/DARM servos needs a pole somewhere, so I put in the zero in the ALS signals so that they match.  Foton thinks that multiplying the two filters should give a flat response, to within 1e-6dB and 1e-6 deg. 

We can lock CARM and DARM on ALS with the new filters, but it seems to be not very stable.  We've measured transfer functions in both configurations, and between 50-500Hz, there is no difference (i.e., our matching filters are matching, and cancelling each other out).  We sometimes spontaneously lose lock when we're just sitting somewhere with the new configuration, and we cannot run any find IR resonance scripts and stay locked.  We've tried the regular old script, as well as Diego's new gentler script.  We always fail with the regular script during the coarse scan.  With Diego's script, we made it through the coarse scan, but spontaneously lost lock while the script was calculating the location of the peak.  So, we determine that there is something unstable about the new configuration that we don't understand.  Turning off all the new filters and going back to the old configuration is just as robust as always.  Confusing. 


  10751   Wed Dec 3 21:41:12 2014 JenneUpdateComputer Scripts / ProgramsMatlab license updated

It seems that the old Matlab servers went down a week or so early, so I have updated the Matlab license information in 


per the instructions on https://www.imss.caltech.edu/content/updating-matlab-license-file

EDIT: Q did this also for the control room iMac

  10752   Thu Dec 4 00:26:07 2014 JenneUpdateASCPOP yaw razor blade installed

We would like the option of feeding back the POP beam position fluctuations to the PRM to help stabilize the PRC since we don't have oplevs for PR2 and PR3.  However, we cannot just use the DC QPD because that beam spot will be dominated by carrier light as we start to get power recycling. 

The solution that we are trying as of today is to look at yaw information of just the RF sidebands.  (Yaw is worse than pitch, although it would be nice to also control pitch).  I have placed a razor blade occluding about half of the POP beam in front of the POP PD (which serves POPDC, POP22 and POP110).  I also changed the ASS model so that I could use this signal to feed back to the PRM.  Loop has been measured, and in-loop spectra shows some improvement versus uncontrolled.

Optical table work:

The POP beam comes out of the vacuum system and is steered around a little bit, then about 50% goes to the DC QPD.  Of the remaining, some goes to the Thorlabs PD (10CF I think) and the rest goes to the POP camera.  For the bit that goes to the Thorlabs PD, there is a lens to get the beam to fit on the tiny diode.

There was very little space between the steering mirror that picks off the light for this PD, and the lens - not enough to put the razor blade in.  The beam after the lens is so small that it's much easier to occlude only half of the beam in the area before the lens.  (Since we don't know what gouy phase we're at, so we don't know where the ideal spot for the razor is, I claim that this is a reasonable place to start.)

I swapped out the old 50mm lens and put in a 35mm lens a little closer to the PD, which gave me just enough room to squeeze in the razor blade.  This change meant that I had to realign the beam onto the PD, and also that the demod phase angles for POP22 and POP110 needed to be checked.  To align the beam, before placing the razor blade, I got the beam close enough that I was seeing flashes in POPDC large enough to use for a PRMI carrier trigger.  The PRMI carrier was a little annoying to lock.  After some effort, I could only get it to hold for several seconds at a time.  Rather than going down a deep hole, I just used that to roughly set the POP22 demod phase (I -phase maximally negative when locked on carrier, Q-phase close to zero).  Then I was able to lock the PRMI sideband by drastically reducing the trigger threshold levels.  With the nice stable sideband-locked PRMI I was able to center the beam on the PD. 

After that, I introduced the razor blade until both POPDC and POP22 power levels decreased by about half. 

Now, the POP22 threshold levels are set to up=10, down=1 for both MICH and PRCL, DoF triggers and FM triggers.

ASS model work:

POP22 I and POP110 I were already going to the ASS model (where ASC lives) for the PRCL ASS dither readbacks.  So, I just had to include them in the ASC block, and increased the size of the ASC input matrix.  Now you can select either POP QPD pit, POP QPD yaw, POP221 or POP110I to go to either PRCL yaw, PRCL pit, CARM yaw or CARM pit. 

Compiled, installed and restarted the ASS model.

Engaging the servo:

I took reference spectra of POP QPD yaw and POP 22, before any control was applied.  The shapes looked quite similar, but the overall level of POP22 was smaller by a factor of ~200.  I also took a reference spectra of the POP QPD in-loop signal using the old ASC loop situation.

Q looked at Foton for me, and said that with the boost on, the UGF needed to be around 9 or 10 Hz, which ended up meaning a servo gain of +2.5 (the old POP QPD yaw gain was -0.063).  We determined that we didn't know why there was a high-Q 50Hz notch in the servo, and why there is not a high frequency rolloff, so right now the servo only uses FM1 (0:2000), FM6 (boost at 1Hz and 3Hz) and FM7 (BLP40). 

The in-loop residual isn't quite as good with POP22 as for the QPD, but it's not bad. 

Here's the loop:


And here's the error spectra.  Pink solid and light blue solid are the reference traces without control.  Pink dashed is the QPD in-loop.  Red and blue solid are the QPD and POP22 when POP22 is used as the error signal.  You can definitely see that the boosts in FM6 have a region of low gain around 1.5Hz.  I'm not so sure why that wasn't a problem with the QPD, but we should consider making it a total 1-3Hz bandpass rather than a series of low-Q bumps.  Also, even though the POP22 UGF was set to 9 Hz, we're not seeing any suppression above about 4Hz, and in fact we're injecting a bit of noise between 4-20Hz, which needs to be fixed still. 


  10753   Thu Dec 4 01:24:47 2014 JenneUpdateSUSPRM volin 3rd harmonic

Earlier this afternoon, while locking PRMI, I saw a big peak at 1883.48 Hz.  This comes closest to the PRM's 627.75 Hz *3, so I infer that it is the 3rd order harmonic of the PRM violin mode. 

While putting this in, I noticed that my addition of ETM filters the other day (elog 10746) had gotten deleted.  Koji pointed out that Foton can do this - it allows you to create and save filters that are higher than 20th order, but secretly it deletes them.  I went into the filter archive and recovered the old ETM filters, and split things up.  I have now totally reorganized the filters, and I have made every single optic (ETMs, ITMs, PRM, SRM, BS, MC2) all the same. 

FM1 is BS 1st and 2nd harmonics, and FM6 directly below that is a generic 3rd order notch that is wide enough that it encompases 3*BS. 

FM2 is the PRM 1st and 2nd order, and FM7 below it is the PRM 3rd order. 

FM3 is the SRM 1st order, FM4 is the ETMs' 1st order, and FM5 is the MC2 1st and 2nd order filters. 

All of these filters are triggered on if any degree of freedom is triggered.  They all have a ramp time of 3 sec. We may want to consider having separate trigger options for each optic, so that we're not including the PRM notch on the ETMs, for example, and vice versa. 

When all of these filters are on, according to Foton we lose 5.6 degrees of phase at 100 Hz.

  10755   Thu Dec 4 03:09:06 2014 JenneUpdateLSCBump in Darm Plant: Lockloss after measurement

We were sitting around arm powers of 6, and that loop measurement had finished.  I was about to go down to arm powers of 5ish, but we lost lock.  I'm not sure why.  There's some slow stuff going on in some of the servos, but nothing jumps out at me as a loop oscillation.  It does however kind of look like the PRMI lost lock just before the arm powers went down?  Perhaps this somehow triggered a lockloss?

The time is 1101721675.

Wide view plots:










We're stopping for tonight because ETMX is back to its lame-o jumping around.  I went in and squished the cables, but it's still happening.

Also, the FSS PC drive has been high the last few minutes (only starting after we quit for the night).  When the MC re-locks, it sounds like an ocean wave dying out as the noise goes down a little bit.  But, after a few minutes, it'll get mad again and unlock the MC.

Also, also, I noticed this on Monday with Diego, but the LSC-ALS[x,y] filter module gains sometimes mysteriously get set to zero.  WTF?  Eric and I have both independently checked, and we cannot find a single script in the scripts directory with the string "LSC-ALS", so we aren't deliberately changing those.  Does anyone know what might be going on here?

  10756   Thu Dec 4 23:45:30 2014 JenneUpdateCDSFrozen?

[Jenne, Q, Diego]

I don't know why, but everything in EPICS-land froze for a few minutes just now.  It happened yesterday that I saw, but I was bad and didn't elog it.

Anyhow, the arms stayed locked (on IR) for the whole time it was frozen, so the fast things must have still been working.  We didn't see anything funny going on on the frame builder, although that shouldn't have much to do with the EPICS service.  The seismic rainbow on the wall went to zeros during the freeze, although the MC and PSL strip charts are still fine. 

After a few minutes, while we were still trying to think of things to check, things went back to normal.  We're going to just keep locking for now....

  10757   Fri Dec 5 00:52:51 2014 JenneUpdateSUSETMX 2nd order violin

We looked at the spectra of POX and POY during IR lock, and Q saw a peak at 1285 in POX only.  We're actuating on the ETMs, so it must be an ETMX violin mode, although it doesn't match the others that are in the table.

Anyhow, I added it to FM9.  While I was doing that, I realized that yesterday I had forgotten to put back the 3rd order ETM violin notch, so that is also in FM9.

  10758   Fri Dec 5 02:44:43 2014 JenneUpdateGeneralIFO alignment shenanigans

[Jenne, Q, Diego]

OMG, today sucked alignment-wise.  Like, wow. 

I think that the problem with the ASS is with the input pointing part of the system.  I found that if I disable the TTs for the Yarm (iin practice, the outputs are held at zero), I could run the Yarm ASS at full gain of 1, and it would do an awesome job.  The first time I did this, I by-hand optimized the TTs by running the test mass loops to make them follow the input pointing.  After that, I haven't touched the TT pointing at all, and we've just been running the test mass loops for the Yarm ASS.  The Xarm seems to not have this problem (or at least not as drastically), so I left it as it was, touching BS as well as ITMX and ITMY, although the gain still needs to be about 0.3.

I feel pretty good about the IFO alignment now, although it is slightly different than it has been.  The transmitted arm powers are higher than they were before I changed the ASS procedure, and there seems to be a little less power fluctuation with alignment.  Q points out that I don't have concrete evidence that this is a good alignment, but it feels right. 

It was a significant enough change that I had to go down to the Yend to realign the green to the new arm axis.  Xgreen we did with the remote PZTs.  I also realigned both of the beatnotes on the PSL table. 

While I was on the PSL table, I quickly touched up the PMC alignment.

The biggest problem, the one that sucked up more hours and energy than I'd like to admit, is ETMX's jumping.  So frustrating.  Sometimes it is time-coincident with engaging the LSC, sometimes not.  I thought that it might be because there are too many violin filters, but even if I turn off all violin filters to ETMX, it jumped a few times while the cavity was locked.  Sometimes it moves when the cavity is just locked and seems happy, sometimes it moves when nothing is resonating except for the green.  It takes a few minutes to recover the alignment enough to lock, and then it'll jump again a few minutes later.  I haven't gone down to squish the cables today, although I did it yesterday and that didn't seem to do anything. 

We had a few hours of time when it wasn't jumping, so we tried a few times to lock the IFO.  The last several times we have lost lock because the PRC loop rang up.  We measured the loop at low-ish arm powers, but it kept losing lock at higher powers before we could measure.  At least 3 times, the PRC lockloss took out CARM and DARM too.

Anyhow, it has been a long day of not accomplishing anything interesting, but hopefully the IFO will feel better tomorrow.

  10759   Fri Dec 5 15:41:45 2014 JenneUpdateComputer Scripts / ProgramsNodus on fast GC network

Apparently, some time ago Larry Wallace installed a new, fast ethernet switch in the old nodus rack. Q and I have just now moved nodus' GC ethernet cable over to the new switch.  Dan Kozak is going to use this faster connection to make the data flow over to the cluster not so lag-y.

  10768   Tue Dec 9 03:34:52 2014 JenneUpdateASCPOP yaw razor tuning

With the re-do of the IFO alignment last week, I think that the beam was no longer about halfway on the POP22 razor blade.  To fix this, I locked the PRMI on sideband, removed the razor blade, and then put it back in such that it occluded about half of the light.  

I'm not entirely sure why, but when I put the razor in, POP22 went from 104(ish) to 45(ish) but POPDC  went from 5200(ish) to 1600(ish).  [The 'ish'es are because the PRC wasn't angularly stabilized, so there was some motion changing the power levels that leaked out to the POP port].  The ETMs were misaligned, so this should not be a carrier vs. sideband effect, since they'll both share the cavity axis defined by the ITMs and the PRM.  It is possible, although I didn't check, that there is some oplev light scattered into the POP photodiode that is now blocked by the razor blade.  This light would only be at DC and not the 2f frequencies.  Since the signal levels for POP22 vs. POPDC didn't change with and without the table top on (and with and without room lights on), I don't think that it is an effect of ambient light getting into the diode.  To check if it is oplev light I should (a) just look, and (b) try to lock the PRMI without the ITMX oplev laser being on to see if there is a difference in the POPDC signal.

Anyhow, under the assumption that the POP22 signal level is correct, I tuned up the PRCL ASC a little bit.  These changes are now in the carm_cm_up script, and the carm_cm_down script resets things.  Before the PRC is locked, I have FM1 and FM7 (the basic servo shape and a 40Hz lowpass) on, the gain set to zero, and the input off.  After lock is acquired, the input is turned on, and the gain ramps from 0 -> 10 in 3 seconds.  Then FM2 and FM6 (boosts at 1 and 3Hz) are engaged.

In the plot below, the dark blue and red curves were taken when there was no angular control on the PRC.  Pink was taken last week with the old QPD yaw ASC on.  Light blue is today's version of the in-loop performance of the POP22 yaw ASC loop.  I didn't save the trace unfortunately, but the DC QPD saw out-of-loop improvement between about 0.8Hz - 4 Hz. 

Also, has anything happened with the LSC rack in the last few weeks that might be causing lots of 60Hz noise? I saw these large lines last week, but I don't think I remember them from the past.


After I got the PRCL ASC working, I tried several iterations of locking.  ETMX is still being annoying, although the last hour or so have been okay.  CARM keeps getting rung up right around the transition to the sqrtInv error signal.  Since CARM and DARM are kind of entangled, it took me a few iterations to figure out that it was CARM that is ringing up, and not DARM.  I'm a little worried about the phase loss from the 1kHz lowpass that we turn on just before the transition to sqrtInv.  I want to keep the lowpass off until after we have transitioned DARM also over to DC transmission.  I tried once, but I lost lock before starting the CARM transition.  Anyhow, the ETM alignment issue is annoying.

Also, Jamie, Q, Diego and I were discussing last Friday, but none of us elogged, that we think there might be something wrong with one of the Martian network switches.  I'll start a separate thread about that right now, but it slows things down when you can't trust EPICS channels to be current, and I (without evidence) am a little worried that this might also affect the fast signals.

  10769   Tue Dec 9 03:41:06 2014 JenneUpdateCDSEPICS running slow - network issue?

[Jamie, EricQ, Jenne, Diego]

This is something that we discussed late Friday afternoon, but none of us remembered to elog. 

We have been noticing that EPICS seems to run pretty slowly, and in fact twice last week froze for ~2 minutes or so (elog 10756). 

On Friday, we plotted several traces on StripTool, such as C1:SUS-ETMY_QPD_SUM_OUTPUT and C1:SUS-ETMY_TRY_OUTPUT and C1:LSC-TRY_OUTPUT to see if channels with (supposedly) the same signal were seeing the same sample-holding.  They were.  The issue seems to be pretty wide spread, over all of the fast front ends.  However, if we look at EPICS channels provided by the old analog computers, they do not seem to have this issue. 

So, Jamie posits that perhaps we have a network switch somewhere that is connected to all of the fast front end computers, but not the old slow machines, and that this switch is starting to fail. 

My understanding is that the boys are on top of this, and are going to figure it out and fix it.

  10774   Wed Dec 10 15:05:32 2014 JenneUpdateElectronicsXend QPD whitening board modified already

In April, Koji logged that he had made some changes to the Yend QPD whitening board (elog 9854).  Today, I pulled the Xend board to see if it had the same modifications.  The filter shapes all seem to be the same (as in, the capacitors at the output filters were removed, etc.), and the final gain is the same.  I just realized that I didn't explicitly check if the whitening switches were pulled to ground to permanently turn on the whitenening, but hopefully I'll be able to see that in the photo. 

I have not made any changes today (yet) to the board, so the overall gain is still accessible via EPICS.  I wanted to do a quick check that we won't be saturating things at full power with the maximum gain, before I make a change.


EDIT:  After comparing the photos here and in elog 9854, the X end board has the filter shape modifications that were done some time ago, but the whitening is not permanently enabled.  For the Yend board, Koji added a jumper wire connecting (for example) R97 and R106 to the grounded side of C69.  This jumper wire is not in place on the X qpd board.

Before I re-pull the board and modify it, I want to make sure I know what I'm going to do for the gain slider override.

  10782   Thu Dec 11 16:42:12 2014 JenneUpdateElectronicsXend QPD whitening board plan

Here is a little PDF of what I plan to do to both of the transmission QPD whitening boards later today.  The idea is to take away the remote gain slider inputs, and force the gains to always be at +30dB.

The red and blue notes are from Koji's elog 9854, and the green are my plans for today. 

I will cut the traces from the gain slider inputs, and pull the negative input of the AD620 to ground.  The positive input will be connected to the +5 voltage line, with a divider so that the positive input to the AD620 is about 666mV. 

The AD602 will be maxed out at +30dB with anything over 625mV. 


Unless there are objections, I will start these modifications in an hour or so.  I will also make the Xarm whitening always-on, just like Koji has already done for the Yend.

EDIT, JCD, 12Dec2014:  These are not the modifications that were made.  Please see ____ for actual modifications.

  10788   Fri Dec 12 02:30:25 2014 JenneSummaryGeneralPSL table optical layout



 I missed to elog this earlier. I have temporarily removed the DC photodiode for GTRY to install the fiber holder on the PSL table. So GTRY will not be seeing anything right now.


 After some confusion, I discovered this a few hours ago.

  10789   Fri Dec 12 04:33:49 2014 JenneUpdateASCASS retuned

[Rana, Jenne]

We decided that tonight was the night for ASS tuning. 

We started from choosing new frequencies, by looking at the transmission and the servo control signals spectra to find areas that weren't too full of peaks.  We chose to be above the OpLev UGF by at least a factor of ~2, so our lowest frequency is about 18Hz.  This way, even if the oplevs are retuned, or the gains are increased, the ASS should still function. 

We set the peak heights for the lowest frequency of each arm to have good SNR, and then calculated what the amplitude of the higher frequencies ought to be, such that the mirrors are moving about the same amount in all directions. 

We re-did the low pass filters, and eliminated the band pass filters in the demodulation part of the servo.  The band passes aren't strictly necessary, as long as you have adequate lowpassing, so we have turned them off, which gives us the freedom to change excitation frequencies at will.  We modified the lowpass filter so that we had more attenuation at 2Hz, since we spaced our excitation frequencies at least ~2.5 Hz apart.

The same lowpass filter is in every single demodulator filter bank (I's and Q's, for both length and transmission demodulation).  We are getting the gain hierarchy just by setting the servo gains appropriately. 

We ran ezcaservos to set the demodulation phase of each lockin, to minimize the Q-phase signal. 

We then tuned up the gains of the servos.  Rana did the Y arm, but for the X arm I tried to find the gains where the servos went unstable, and then reduced the gain by a factor of 2.  The Xarm is having trouble getting good alignment if you start with something less than about 0.7, so there is room for improvement.

Rana wrote a little shell script that will save the burt snapshot, if the gains need adjusting and they should be re-saved. 

The scripts have been modified (just with the new oscillator amplitudes - everything else is in the burt snapshots), so you should be able to run the start from nothing and the start from frozen scripts for both arms.  However, please watch them just in case, to make sure they don't run away.

ELOG V3.1.3-