40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 70 of 341  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  9662   Mon Feb 24 13:40:13 2014 JenneUpdateCDSComputer weirdness with c1lsc machine

I noticed that the fb lights on all of the models on the c1lsc machine are red, and that even though the MC was locked, there was no light flashing in the IFO. Also, all of the EPICS values on the LSC screen were frozen.


I tried restarting the ntp server on the frame builder, as in elog 9567, but that didn't fix things.  (I realized later that the symptom there was a red light on every machine, while I'm just seeing problems with c1lsc. 

I did an mxstream restart, as a harmless thing that had some small hope of helping (it didn't). 

I logged on to c1lsc, and restarted all of the models (rtcds restart all), which stops all of the models (IOP last), and then restarts them (IOP first).  This did not change the status of the lights on the status screen, but it did change the positioning of some optics (I suspect the tip tilts) significantly, and I was again seeing flashes in the arms.  The LSC master enable switch was off, so I don't think that it was trying to send any signals out to the suspensions.  The ASS model, which sends signals out to the input pointing tip tilts runs on c1lsc, and it was about when the ass model was restarted that the beam came back.  Also, there are no jumps in any of the SOS OSEM sensors in the last few hours, except me misaligning and restoring the optics.  I we don't have sensors on the tip tilts, so I can't show a jump in their positioning, but I suspect them.

I called Jamie, and he suggested restarting the machine, which I did.  (Once again, the beam went somewhere, and I saw it scattering big-time off of something in the BS chamber, as viewed on the PRM-face camera).  This made the oaf and cal models run (I think they were running before I did the restart all, but they didn't come back after that.  Now, they're running again).  Anyhow, that did not fix the problem.  For kicks, I re-ran mxstream restart, and diag reset, to no avail.  I also tried running the sudo /etc/init.d/ntp-client restart command on just the lsc machine, but it doesn't know the command 'ntp-client'. 

Jamie suggested looking at the timing card in the chassis, to ensure all of the link lights are on, etc.  I will do this next.

  9663   Mon Feb 24 15:25:29 2014 JenneUpdateCDSComputer weirdness with c1lsc machine

The LSC machine isn't any better, and now c1sus is showing the same symptoms.  Lame.

The link lights on the c1lsc I/O chassis and on the fiber timing system are the same as all other systems.  On the timing card in the chassis, the light above the fibers was solid-on, and the light below blinks at 1pps. 

Koji and I power-cycled both the lsc I/O chassis, and the computer, including removing the power cables (after softly shutting down) so there was seriously no power.  Upon plugging back in and turning everything on, no change to the timing status.  It was after this reboot that the c1sus machine also started exhibiting symptoms. 

  9664   Mon Feb 24 16:26:14 2014 JenneUpdateCDSNTP fell out of sync on front end machines - fixed

[Koji, Jenne]

Koji noticed that the time on the front-end detail screens was not correct, and that the GPS time was not matching up between different models.  Koji ran the following on all front-end machines, and on nodus:

sudo ntpdate -b -s -u pool.ntp.org

Now, everything is fine, and every status light on the cds overview screen is green.

  9673   Tue Feb 25 17:27:41 2014 JenneUpdateLSCREFL signals calibrated

I have recalibrated the REFL signals.

I first adjusted the demod phases until the I-signals lined up with the I-phase in the sensing matrix plot:


I then balanced the ITM drives by pushing on -1*ITMX and +1.015*ITMY, and seeing a minimum of MICH actuation in the I-phase of REFL55 (the PD I was locking with).

I then took a nice long measurement with DTT, and measured the peak heights in I and Q for each REFL diode.  I was driving PRM with 100 cts at 675.1Hz, and ITMX with 1000 cts at 452.1 Hz (and matching ITMY drive, to make pure MICH).  Knowing these numbers, and the actuator calibrations (PRM elog 8255, ITMs elog 8242), I know that I was driving PRCL by ~4.3 pm, and MICH by ~23 pm. 

For the I-phase calibrations, I find the peak height at the PRCL drive frequency, and divide 4.3 pm by that height.  For the Q-phase calibrations, I find the peak height at the MICH drive frequency, and divide 23 pm by that height.

This gives me the following calibrations:

  Calibration [picometers / count]
REFL 11 I    0.15
REFL 11 Q   21.6
REFL 33 I    1.06
REFL 33 Q  209
REFL 55 I    0.9
REFL 55 Q   27       
REFL 165 I    0.1
REFL 165 Q   11.6

 My calibrated REFL spectra then looks like:


  9674   Tue Feb 25 18:16:22 2014 JenneSummaryLSCEven more violin filters

A new violin mode at 1303 Hz was ringing up this afternoon.  Rana and I added a notch for this.

RXA: while the mode at 1303.6 Hz was ringing down, I used the narrowband DTT technique to measure the Q (after turning on the notch in SUS-PRM_LSC). So its another frequency in the PRM (not the BS).

The time that it takes for 2 -foldings is 652 s, which implies that Q = pi*f*tau = 1.3e6. This seems too high by a factor of ~10, so my guess is that there is still some feedback path happening. The previous bandstop filter was centered around 1285 Hz and seems also weird that the PRM would have 2 violin modes with such different frequencies. Is the mirror rotated around the optic axis such that the standoffs are not at the same height?

Attachment 1: PRMvio2.png
  9676   Wed Feb 26 01:49:08 2014 JenneUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

I have measured the sensing matrix at a variety of PRCL offset values.


During this each measurement, I also took a 20 second average of the POP 2f signals and the ASDC signal:


All of this data was taken during a single lock stretch. 

If / when I do this again, I want to go out to larger offsets.  I won't take as many points, but I do want to see how far I can go before I lose lock, and what the phase separation looks like at larger offset values (this time, I stopped at +700 counts which is about 0.7nm, to start checking the negative values. MC has been unhappy, so I wasn't able to take very many negative offset values.) 

I conclude that these sensing matrix measurements do see changes in the phase separation with PRCL length offset (what we saw / said yesterday), but that they do not line up with Q's simulation from this afternoon in elog 9671.

The simulation says that we shouldn't be seeing large phase changes until we get out to several nanometers, however the measurement is showing that we get large phase chnages with picometer scale offsets.  Yesterday, Rana and I said that the offsets due to RAM were small (of order picometer), and that they were therefore likely not important (elog 9668).  However, now it seems that the RAM is causing significant length offsets which then cause poor MICH/PRCL phase separation.

To Do List:

* Confirm MIST simulation with Optickle.

* Look at sensing matrix data pre-lockins (in the raw sensors).

* Check that there is no clipping anywhere in the REFL path (at least out of vacuum), and that the beam is sufficiently small on all 4 REFL diodes.

* Calculate the new PRC g-factor with the new length.

  9677   Wed Feb 26 02:20:35 2014 JenneUpdateIOOMC unhappy

I've asked Manasa and Q to have a look at the MC in the morning.  Rana and I have found it to be slightly uncooperative in relocking after a lockloss.

The concern is that we may be (by actuating on things during lock, or during a lockloss) ringing up some mode, maybe a violin mode in one of the suspensions, maybe a PZT mode of some sort.  If we are, and then we have to push with the PZT on the laser to lock things, that may be why the laser's PZT RMS (on the FSS screen) is so often above 1Vrms.  When we close the PSL shutter, the rms is low, like 0.6 or something, and it stays flat.  As we've all see many a' time, the red trace on the top projector plot is pretty erratic throughout the day when the MC is locked or trying to lock.

We have found that just letting the autolocker go doesn't seem to work very well, and sometimes the MC just doesn't want to re-lock.  Closing the PSL shutter or disabling the autolocker for a few minutes (5ish) doesn't do anything, but leaving it closed for a long time (30 ish minutes) helps a lot.  The MC  will relock immediately after a nice long break. 


  9679   Wed Feb 26 23:14:07 2014 JenneUpdateCDSfb timing was off

....fb timing issue happened again.

I thought that it was the thing that Koji and I saw the other day, where it was individual front end computers that had lost ntp sync, since it wasn't every core on every computer that was red, but reconnecting to the ntp server on c1lsc didn't do anything.  I then tried reconnecting to the ntp server on fb, and that fixed things right up.  Annoying.

  9680   Thu Feb 27 01:02:57 2014 JenneUpdateSUSOplev Tuning Party - round 1

[Jenne, Vivien]

We had an oplev tuning party this afternoon.  What we have learned is that we don't have a lot of intuition yet on tuning loops.  But, that was part of the point - to build some intuition. 

I took responsibility for the PRM, and Vivien took ITMX.  I think, in the end, all changes were reverted on ITMX, however Vivien took some data to try and make a computer-generated controller.  Before we got started, I locked and aligned the PRMI, and we centered the PRMI-relevant oplevs.

I moved my "boost bump" around a bit, to do more at higher frequencies, but had to sacrifice some of the "oomph", since it was starting to eat up too much phase at my UGF of ~8Hz.  I also made the stack resonant gain higher Q and lower height so that it didn't eat so much phase.  In the end, I have 25 degrees of phase margin, which isn't really great, but I do win a factor of 2 around 2 and 3 Hz.  Also, now I'm able to engage the 3.2 resgain at all, whereas with the previous filter shape I was not able to turn it on.


Maybe it's because I really want it to have helped, but I feel like the POP spot isn't moving as much when I'm locked on PRMI sidebands as it was earlier (we were seeing a lot of low frequency (few Hz) motion).  So, I think I did something good.

  9683   Mon Mar 3 10:42:53 2014 JenneUpdateCDSfb timing was off

...yet again.

lsc and sus needed mxstream restarts after I restarted the ntp on fb.

  9686   Mon Mar 3 21:50:35 2014 JenneUpdateComputer Scripts / ProgramsDropbox installed on Workstations

I have installed Dropbox on the 40m workstations, using the foteee account. 

I put it in /users/Dropbox.

As a side note, I did the install while sitting on Pianosa, but since I put the folder on the mounted hard drive, I think we should be able to use it from any workstation, although I have not yet confirmed this.

  9690   Wed Mar 5 09:52:31 2014 JenneUpdateSUSOplev Tuning - Cartoon cost function

Not a whiteboard, but here's a cartoon of my oplev cost function cartoon.  For the "maximize this area" and "minimize this area", I plan to use ratios between the curves, and then give those ratios to a sigmoid function.




  9694   Wed Mar 5 19:15:39 2014 JenneSummaryLSCALS offset moving script modified


- Step 3: Transition from ALS Common to 1/SQRT(TRX)+1/SQRT(TRY). Make sure that the calibration of TRX and TRY are matched.
  The current understanding is that the offset for 1/SQRT(TRX)+1/SQRT(TRY) can't be provided at the servo filter. Figure out
  what is the correct way to give the offsets to the TR signals.

 I have modified the script ALSchangeOffsets.py (in ..../scripts/ALS/) to also handle a "CARM" situation.  There is a new button for this on the ALS in LSC screen.  This script takes the desired offset, and puts half in the ALSX offset, and half in the ALSY offset.  Whatever offset you ask for is given the sign of the input matrix element in the ALS->CARM row of the input matrix.  For example, if you ask for a CARM offset of 1, and the matrix elements are ALSX->CARM=+1 and ALSY->CARM=-1 (because your beatnotes are on opposite sides of the PSL), you will get an offset of +0.5 in ALSX and -0.5 in ALSY, which should be a pure CARM offset. The offsets get set as expected, but I haven't had a chance to test it live while the arms are locked. 

I also want to write a script that will average the IN1 of the 1/sqrt(TR) signals, and put that number into the 1/sqrt(TR) offsets.  If this is run when we are at about half fringe, this will set the zero point of the 1/sqrt(TR) signals to the half fringe (or where ever we are).  Then, we need a script similar to the ALS CARM one, to put offsets into the CARM combination of 1/sqrt(TR)s. 

I think that putting the offsets in before the servo filters will mean that the signals coming out of the input matrices will already be at their zero points, so we won't have as much trouble shifting from ALS to IR.

  9706   Mon Mar 10 11:42:36 2014 JenneUpdateCDSfb timing was off

fb timing was off again.

  9707   Mon Mar 10 12:49:27 2014 JenneUpdateIOOPMC input pointing misaligned

I don't know why, but as you can see in Steve's plot from earlier this morning, the PMC transmission has been going down significantly all weekend.  The PMC refl camera was very bright.  I tweaked up the alignment (mostly pitch), and now we're back to normal. 

The IMC was having trouble staying locked all morning, and I'm hoping that this PMC adjustment will help - the MC already looks better, although it's only been a few minutes.

  9716   Tue Mar 11 15:19:45 2014 JenneUpdateElectronicsHigh gain Trans PD electronics change

As part of our CESAR testing last night, we had a look at the noise of the 1/sqrt(TR) signal. 

Looking at the time series data, while we were slowly sweeping through IR resonance (using the ALS), Rana noted that the linear range of the 1/sqrt(TR) signal was not as wide as it should be, and that this is likely because our SNR is really poor. 

When a single arm is at a normalized transmission power of 1, we are getting about 300 ADC counts.  We want this to be more like 3000 ADC counts, to be taking advantage of the full range of the ADC.

This means that we want to increase our analog gain by a factor of 10 for the low gain Thorlabs PDs. 

Looking at the photos from November when I pulled out the Xend transmission whitening board (elog 9367), we want to change "Rgain" of the AD620 on the daughter board.  While we're at it, we should also change the noisy black thick film resistors to the green thin film resistors in the signal path. 

The daughter board is D04060, S/N 101.  The main whitening board for the low gain trans QPD is D990399, RevB, S/N 104.

We should also check whether we're saturating somewhere in the whitening board by putting in a function generator signal via BNC cable into the input of the Thorlabs whitening path, and seeing where (in Dataviewer) we start to see saturation.  Is it the full 32,000 counts, or somewhere lower, like 28,000? 

Actually the gain was changed. From gain of 2 (Rgain = 49.4kOhm) to 20 (Rgain = 2.10kOhm), Corresponding calibration in CDS was also changed by locking the Xarm, running ASS, then setting the average arm power to be 1. Confirmed Xarm is locking. And now the signal is used for CESAR.  We see emperically that the noise has improved by a factor of approximately 10ish.

Attachment 1: IMG_1309.JPG
  9719   Tue Mar 11 18:34:11 2014 JenneUpdateLSCComposite Error Signal for ARms (7)

[Nic, Jenne, EricQ, and Koji]

We have used CESAR successfully to bring the Xarm into resonance.  We start with the ALS signal, then as we approach resonance, the error signal is automatically transitioned to 1/sqrt(TRX), and ramped from there to POX, which we use as the PDH signal.

In the first plot, we have several spectra of the CESAR output signal (which is the error signal for the Xarm), at different arm resonance conditions.  Dark blue is the signal when we are locked with the ALS beatnote, far from IR resonance.  Gold is when we are starting to see IR resonance (arm buildup of about 0.03 or more), and we are using the 1/sqrt(TRX) signal for locking.  Cyan is after we have achieved resonance, and are using only the POX PDH signal.  Purple is the same condition as cyan, except that we have also engaged the low frequency boosts (FM 2, 3, 4) in the locking servo.  FM4 is only usable once you are at IR resonance, and locked using the PDH signal.  We see in the plot that our high frequency noise (and total RMS) decreases with each stage of CESAR (ALS, 1/sqrt(TR) and PDH). 

To actually achieve the gold noise level of 1/sqrt(TR), we first had to increase the analog gain by swapping out a resistor on the whitening board. 



The other plots attached are time series data.  For the python plots (last 2), the error signals are calibrated to nanometers, but the dark blue, which is the transmitted power of the cavity, is left in normalized power units (where 1 is full IR resonance). 

In the scan from off resonance to on resonance, around the 58 second mark, we see a glitch when we engage FM4, the strong low frequency boosts.  Around the 75 second mark we turned off any contribution from 1/sqrt(TR), so the noise decreases once we are on pure PDH signal. 

In the scan through the resonance, we see a little more clearly the glitch that happens when we switch from ALS to IR signals, around the 7 and 12 second marks. 

We want to make some changes, so that the transition from ALS to IR signals is more smooth, and not a discrete switch.


Attachment 2: Screenshot-1.png
Attachment 3: ScanFromOffToOnResonance.pdf
Attachment 4: ScanThroughResonance.pdf
  9724   Thu Mar 13 01:18:00 2014 JenneUpdateLSCComposite Error Signal for ARms (8)

[Jenne, EricQ]

As Koji suggested in his email this afternoon, we looked at how much actuator range is required for various forms of arm locking:  (1) "regular" PDH lock aquisition, (2) ALS lock acquisition, (3) CESAR cooling.

To start, I looked at the spectra and time series data of the control signal (XARM_OUT) for several locking situations.  Happily, when the arm is at the half fringe, where we expect the 1/sqrt(TRX) signal to be the most sensitive (versus the same signal at other arm powers), we see that it is in fact more quiet than even the PDH signal.  Of course, we can't ever use this signal once the arm is at resonance, so we haven't discovered anything new here.


EricQ then made some violin plots with the time series data from these situations, and we determined that a limit of ~400 counts encompasses most of the steady-state peak-to-peak output from locking on the PDH signal.


[ericq: What's being plotted here are "kernel density estimates" of the time series data of XARM_OUT when locked on these signals. The extent of the line goes to the furthest outlier, while the dashed and dotted lines indicate the median and quartiles, respectively]

I tried acquiring ALS and transitioning to final PDH signals with different limiters set in the Xarm servo.  I discovered that it's not too hard to do with a limit of 400 counts, but that below ~350 counts, I can't keep the ALS locked for long enough to find the IR resonance.  Here's a plot of acquiring ALS lock, scanning for the resonance, and then using CESAR to transition to PDH, with the limit of 400 counts in place, and then a lockloss at the end.  Even though I'm hitting the rails pretty consistently, until I transition to the more quiet signals, I don't ever lose lock (until, at the end, I started pushing other buttons...).


After that, I tried acquiring lock using our "regular" PDH method, and found that it wasn't too hard to capture lock with a limit of 400, but with limits below that I can't hold the lock through the boosts turning on.


Finally, I took spectra of the XARM_OUT control signal while locked using ALS only, but with different limiter values. Interestingly, I see much higher noise between 30-300 Hz with the limiter engaged, but the high frequency noise goes down.  Since the high frequency is dominating the RMS, we see that the RMS value is actually decreasing a bit (although not much).


We have not made any changes to the LSC model, so there is still no smoothing between the ALS and IR signals.  That is still on the to-do list.  I started modifying things to be compatible with CARM rather than a single arm, but that's more of a daytime-y task, so that version of the c1lsc model is saved under a different name, and the model that is currently compiled and running is reverted as the "c1lsc.mdl" file.

  9736   Tue Mar 18 00:51:02 2014 JenneUpdateSUS4.4M local earthquake


 I am really, really happy to hear that it was just a sticking situation.  Really happy. 

  9771   Tue Apr 1 20:56:27 2014 JenneUpdatePEMNo noticeable effect from Chile's M8.2 earthquake

Koji locked the MC, arms, and PRMI, with no troubles, after the M8.2 earthquake off the coast of Chile, that happened about 4 hours ago.

  9772   Tue Apr 1 21:45:01 2014 JenneSummaryLSCPRM violin notch not at correct freq?

Koji and I have the PRMI locked right now, and we hear a very strong violin mode ringing up, at 628Hz.  This is, according to Koji's elog 9634, what we expect the PRM's violin mode to be.  However, the current PRM violin mode notch is really more of a bandstop filter, between 622-670Hz.  At 628Hz, it has a suppression of about -20dB.  If I try to increase the width of this notch by making it 612-670Hz, the PRMI won't hold lock.

We're leaving this as a daytime task for tomorrow, since we're in the middle of taking data to show that Koji's new ASC filter design (slightly tuned from his elog 9769) works well.

Edit:  I have moved the PRM violin notch frequency over to 612-660 Hz, and after letting it sit for a while (while locked on PRMI), the violin mode has settled down.  Interestingly, if I compare the spectrum with and without the 1st order violin mode notch, it looks like the 2nd order mode changes from 1256Hz to 1303Hz.  I don't know what is going on here, but we already have notches for both of those frequencies.

  9774   Wed Apr 2 01:18:30 2014 JenneUpdateLSCAttempt at PRMI+2 arms

I was trying to lock PRMI+2 arms, but I'm losing patience with the MC losing lock.  It's mostly well-behaved, but every now and again it'll lose lock, and it always seems to be just when I've gotten to a delicate part.  Anyhow.  I don't think anything needs fixing.

I am not able today to acquire PRMI lock with REFL 165 I&Q, nor am I able to follow Koji's prescription to transition to 165 from 55.  However, I am able to transition to, or just straight-up aquire on, REFL 33 I&Q.  The new ASC is awesome.

Before trying to lock with REFL165, I redid it's demod phase, by actuating on the PRM while locked on REFL 55, and minimizing the PRCL signal in the Q-phase.  Old 165 phase was -83.5 degrees, new is -79.5 degrees.

I then tried the procedure of misaligning the PRM, acquiring ALS lock of both arms, finding the arm IR resonances, and moving the arms off resonance.  Then I restored the PRM, and locked the PRMI on sidebands using REFL33 I&Q. 

Something was a little weird and unexpected:  If the arms were not far, far off resonance, there was a large MICH offset, so that AS was bright, and POP was pretty dark.  If I moved the arms farther from resonance, POP would come back to the "normal" brightness, which was ~460 counts on POP110I.  When POP was dark-ish, POP110I was about 150, although this number could be changed by moving the arms around.  This number was not dependent on PRM alignment.  Also, PRCL was not yet starting to resonate the carrier, because POPDC stayed at its low sideband-lock level of about 90 counts (vs. 2,000+ for a PRMI-only carrier lock), and POP was visually dark on the camera. 


While playing with PRMI + 2 ALS arms is entertaining for the evening, I don't yet have a plan for dealing with the changing CARM optical plant for IR signals situation.  That's in progress in the daytime.

  9778   Wed Apr 2 20:13:04 2014 JenneUpdatePEMMore Chile EQs

2 more earthquakes in Chile:  a M6.4 and a M7.8. 

We got them about 15 minutes ago (according to the BLRMS on the wall), but when I go tin, the MC was already locked, and engaging the LSC immediately got me PRMI lock (since that's the alignment state that the IFO was left in).

  9780   Thu Apr 3 00:30:52 2014 JenneUpdateLSCAttempt at PRMI+2 arms

[EricQ, Jenne]

We started out this evening by locking the PRMI, on different REFL PDs, just to make sure that we could.  We were able to acquire lock (without having to transition) on either REFL55, REFL33 or REFL165 (I&Q phases for each).  By looking at the transfer function between REFL 55 I and REFL 165 I, I determined that the phase of REFL165 needed to be -135.5, not +44.5, so that the gains were the same sign in all REFL PDs (this is in reference to Koji's elog 9777).  The time to acquisition is much shorter with REFL55 than with the other 2 photodiodes.  I'm not sure right now why this is, but it's pretty consistent, and even more so when the arms are held off resonance.  It is also easy to acquire lock with REFL 55 and then transition to either of the 3f diodes.

PRMI settings:

MICH gain = 2.0.  FMs 4, 5 always on.  FMs 2, 3, 6, 7, 9 triggered with 35 up, 2 down.  Trigger servo on POP110I with 100 up, 10 down.

PRCL gain = -0.020.  FMs 4, 5 always on.  FMs 2, 3, 6, 9 triggered with 35 up, 2 down.  Trigger servo on POP110I with 100 up, 10 down.

PRCL ASC triggered with 50 up, 10 down.  Both pitch and yaw servos had FMs 1, 9 always on, and the FM 6 boost turned on by hand after lock acquired.  Pitch gain = -0.023, yaw gain = -0.027.

If using REFL55, PRCL = I = 1 in the input matrix, and MICH = Q = 1 in the input matrix.

If using REFL33, PRCL = I = 3 in the input matrix, and MICH = Q = 3 in the input matrix.

If using REFL165, PRCL = I = 0.15 in the input matrix, and MICH = Q = 0.1 in the input matrix.

We then moved on to trying to do PRMI + 2 arms, but have been plagued a little bit by locklosses, which may be due to the high seismic from the few large and many small Chilean aftershocks. 

Settings:  With the PRM misaligned, we acquired ALS lock in a CARM/DARM fashion.  The Xarm servo was our "darm" proxy, with +1*ALSX and +1*ALSY.  The Yarm servo was our "carm" proxy, with -1*ALSX and +1*ALSY.  The opposite signs from what you might expect is from our having placed the 2 aux laser frequencies on opposite sides of the PSL.  Our DARM (xarm) was actuating +1 on ETMX and -1 on ETMY.  Our CARM (yarm) was actuating +1 on MC2.  Then we put in a CARM offset of ~60 counts.

We then realigned the PRM, and locked the PRMI (settings as above).  It is much easier to acquire lock with REFL55 than it is with REFL33 or REFL165.  Also, when we are locking the PRMI with REFL55, the AS port is dark, and we see bright sideband resonance at the POP port, as we normally expect.  However, as with last night, when we lock the PRMI with either of the 3f PDs, we see a very bright AS port, and a dark POP port.  Tonight, putting in a MICH offset did not seem to make a significant difference.  As with last night, moving the arms farther away from resonance removed this MICH offset.  I am sure that this is not an artifact of the photodiode dark offsets not being set properly, since I rechecked those carefully. 

We have not come to any interesting conclusions about PRMI+2 arms tonight, since we have started losing the MC every few minutes (maybe seismic-related?). 

  9781   Thu Apr 3 03:06:34 2014 JenneUpdateLSCAttempt at PRMI+2 arms

[EricQ, Jenne]

Much more success later! 

We've had the arms locked on ALS and held off resonance for more than 2 hours now.  That's good.  We've done several trials of locking the PRMI and trying to reduce the ALS CARM offset.  Once we were able to get quite close, but we never achieved zero CARM offset. 

One big finding is that when the TRX and TRY are about 0.1 in the coupled-cavity case, we start to see real length information in the 1/sqrt(trans) signals.  Q will edit this elog, or reply to it, with the data that he has collected.

  9787   Tue Apr 8 01:58:53 2014 JenneUpdateLSCPlaying with PRMI + 2 arms

I played around with the PRMI + 2 arms situation again this evening.  (I'm not ready to call it "PRFPMI" until we're at least partially using IR signals for CARM and DARM control).

I'm still a little bothered by the fact that we lose almost all light in the PRC when we're reducing the CARM offset.  I'm not sure where the light is going, but it's not circulating in the PRC, since I see the POP camera get very dark.  I can bring back light by changing either the PRCL offset, the MICH offset, or to a lesser extent (or maybe I'm not going far enough in offset) the DARM offset.

Tonight, I was using ALS to push on the ETMs in DARM/CARM mode (I didn't push on MC2 today, since it was being finicky and I had a hard time locking CARM with the MC as the actuator today). 

For the PRMI, I was using REFL 33 I&Q.  PRCL gain was -0.04, MICH gain was +0.8.  REFL 33I varied between +2 and +1.2 (smaller gain necessary as CARM offset was reduced, but it's easier to acquire at large CARM offset with larger gain), and REFL 33Q was +1.0.   PRCL has the usual FM 2,3,6,9 triggered, but MICH only had FM 2 triggered.  The others (particularly FM6) make MICH lose lock.  PRCL ASC was engaged, with the PRM oplev off.

Most of what I was trying tonight was to reduce the CARM offset, and then adjust some other offset (MICH, PRCL or DARM) to maximize POP DC.  It's possible that the POP 110 and 22 diodes are changing their optimal demod phases as the optical plant changes, but POPDC is just DC. 

I wasn't able to get the CARM offset below about 40 counts.  At some point I had both CARM and DARM offsets at 50 counts, and had IR resonance in the Xarm, but no resonance in the Yarm.  I guess this is just part of having a simultaneous CARM and DARM offset.

EDIT:  If I leave the CARM offset at 0, and use a large DARM offset (100 counts), I can acquire PRMI lock, but I run into the same problems as I reduce the DARM offset - the POP power decreases, and I lose lock around 45 counts.

Side note: Earlier today I redid the POP 110 and 22 phases.  POP110 was -61 deg, and is not -101 deg.  POP22 was +164 deg, and is now -105 deg.  I'm not sure why they needed such radical changes.  When sideband locked on REFL33, POP110 had an average DC level of 580 cts, while POP22 had a value of 290 cts.

  9791   Wed Apr 9 02:34:20 2014 JenneUpdateLSCJumping over the CARM resonance point

Koji was right, and I was using much too large of a CARM offset.  Tonight, I set either my CARM or DARM offset to 3 counts, and was able to easily acquire PRMI lock using REFL33. 

For either CARM or DARM offset reduction (the other one was kept at zero offset), I was able to get to about 0.5 counts, but I lose lock when I try to go to 0.4 or 0.3 counts.  One time, I tried "jumping over" the resonance, by going from minus 1 to plus 1 in CARM offset.  Plots of this below.

Locking notes

ALS locked with "Xarm" servo as proxy for DARM, and "Yarm" servo as proxy for DARM.  Pushing only on ETMs today, not the MC. 


Input matrix:  1's in REFL 33 I&Q, if not using power normalization.  200's in REFL 33 I&Q if power normalization used (either POPDC or POP22).  200 used because that's about the average value of POPDC or POP22 when PRMI sideband-only resonant.

Trigger:  POP22, up 100, down 10.

Power normalization:  1's for both MICH and PRCL in POP22I for one trial.  1's for both MICH and PRCL in POPDC for another trial.  Both seemed to work equally well, although that may change when I'm actually getting IR resonance in the cavity.

FM triggers:  MICH = FM2.  PRCL = FMs 2, 3, 6, 9.  Trigger up = 35, down 10.  PRCL delayed by 0.5 sec, MICH delayed by 5 seconds.

Servo gains:  MICH = 0.4, PRCL = -0.01


When I approach the situation of both arms resonating, it pretty consistently looks like the PRM is getting pushed in pitch (and not in yaw).  I don't know why this could be, but it seems like this is the big symptom before lockloss - if the POP spot starts moving (and the PRM suspit signal starts moving), PRMI lock is going to be lost.

I don't know if it's imperfect alignment, imperfect mode matching, or something else, but I see lots of high-order higher order modes on both the POP and AS cameras when the CARM or DARM offset is less than 1 count.  I tried to take a video, but the brightness and contrast aren't set as high as on monitors 3 and 5, so it's hard to see the dim stuff.  Youtube.  At the midpoint of the video, you see a lockloss.

Even though I have overridden the transmission triggers so that I only use the QPDs for the transmission signals, I'm only seeing arm transmission values up to about 50 from each arm.  If we had ideal PRC gain, we expect something like 650 or 700. 

A few plots

All of the raw data for these plots, and several other channels, is in /users/jenne/PRFPMI/PRMI_2arms_8Apr2014/m1_to_p1_carmOffset_1081065069.  As mentioned above, "XARM" is CARM, and "YARM" is DARM.  So, the XARM_IN1 tells us about the CARM offset that I was applying.  The start time is 1081065069, and the plots are all 8 seconds long.

First, the transmitted power and the CARM offset.


The REFL_I error signals and the CARM offset.


The RF signals that we will eventually chose from for CARM and DARM control. Note that I'm not sure about the AS55 phase, so I plot both I and Q.


The PRM suspit and sus yaw angular signals and the CARM offset.  I don't see a huge change in the suspit signal, but it does seem to change character once we approach arm resonances.


  9792   Wed Apr 9 16:08:33 2014 JenneUpdateLSCCARM loop gains vs. CARM offset

I have taken EricQ's simulation results for the CARM plant change vs. CARM offset, and put that together with the CM and CARM digital control loops, to see what we have. 

The overall gains here aren't meaningful yet (I haven't set a UGF), but we can certainly look at the phases, and how the magnitude of the signals change with CARM offset.

First, the analog CM servo.  I use the servo shape from Den's elog from December, but only what he calls "BOOST", the regular servo shape, not any of the super boosts, "BOOST 1-3".   No normalization.


Next, the digital LSC CARM servo (same filters as XARM and YARM).  I have used FM4 and FM5, which are the 2 filters that we use to acquire regular LSC arm lock.  For the actuator, I just use a 1Hz pendulum as if I'm pushing only on the ETMs.


I also used the exact same setups as above, but normalized the transfer functions by a DC photodiode output.  The analog CM loops change the least (around a few kHz) if I use POPDC.  The digital CARM loops change the least (around 100Hz) if I use TRX (or, equivalently, TRX + TRY).

Here are the normalized plots:



Either way, with or without normalization, the digital CARM loop will go unstable between 0-10pm, for both the REFL RF photodiodes.  We need to figure out how to get a realistic transfer function out for the 1/sqrt(TRANS) signals, and see what happens with those.  If those also look unstable, then maybe we should consider a DC signal for the analog CM servo to start, since that could have a wider linear range.

  9793   Thu Apr 10 01:56:05 2014 JenneUpdateLSCCARM transitioned to IR error signals!

[Jenne, EricQ]

This evening we took things a little bit farther than last night (elog 9791) and transitioned CARM to fully IR signals, no ALS at all for CARM error signals!  We were unsuccessful at doing the same for DARM. 

As we discussed at 40m Meeting this afternoon, the big key was to remove the PRCL ASC from the situation.  I don't know specifically yet if it's QPD saturation, or what, that was causing PRM to be pushed in pitch last night, but removing the ASC loops and reengaging the PRM optical lever worked like a dream. 

Since we can now, using ALS-only, get arbitrarily close to the PRMI+2 arm full resonance point, we decided to transition CARM over to the 1/sqrt(transmission) signals.  We have now done this transition 5 or 10 times.  It feels very procedural and robust now, which is awesome!

To make this transition easier, we made a proto-CESAR for the CARM signals in the LSC.  There's nothing automatic about it, it's just (for now) a different matrix. 

ALS lock conventions:

We have (finally listening to the suggestion that Koji has been making for years now....) set a convention for which side of the PSL the X and Y beatnotes should be, so that we don't have to guess-and-check the gain signs anymore.

For the X beatnote, when you increase the value on the slow slider, the beatnote should increase in frequency.  For the Y beatnote, when you increase the value on the slow slider, the beatnote should decrease in frequency. 

The input matrix (the aux input part) should then have +1 from ALSX->carm, and +1 from ALSY->carm.  It should also have -1 from ALSX->darm and +1 from ALSY->darm. 

The output matrix should be carm -> +1's for both ETMs.  darm should be -1 to ETMX and +1 to ETMY.

With these conventions, both carm and darm should have negative signs for their gains. 

Since we don't have (although should whip up) Watch scripts for the CARM and DARM servo filters, we were using the Xarm filterbank for carm, and the Yarm filterbank for darm again.

Transitioning CARM to 1/sqrt(trans) signals:

As with last night, we were able to easily acquire PRMI lock with a CARM offset of 3 counts.  We then moved down to 2 counts, and saw transmission values of 0.1-0.2.  We set the offsets in the TR_SQRTINV filter banks so that the difference between the outputs was zero, and the mean of the outputs was 2 (the same as the CARM offset we had). 

We looked at the relative gain and sign between the ALS and 1/sqrt() signals, and found that we needed a minus sign, and half the gain.  So, we stepped the 1/sqrt() matrix elements from 0 to -0.5 in steps of 0.1, and at the same time were stepping the ALS matrix elements to CARM from +1 to 0, in steps of 0.2.  This was, excitingly, very easy!

The first time we did this successfully, was a few seconds before 1081143556 gps.

Here is a set of spectra from the first time we locked on the 1/sqrt(trans) signals. 




Failure to transition CARM to RF signals, or reduce CARM offset to zero:

While locked on the 1/sqrt(trans) signals, we looked at several RF signals as options for CARM.  The most promising seems to be REFL55, normalized by (TRX+TRY).  The next most promising looks like REFL11 normalized by POPDC.  Note that these are entirely empirical, and we aren't yet at the resonant point, so these may not be truly the best.  Anyhow, we need to reconfigure the LSC input of the normalized error signals, so that they can go into the CESAR matrices.  This was more than we were prepared to do during the nighttime.  However, it seems like we should be about ready to do the transition, once we have the software in place.  Right now, we either normalize both ALS and the RF signal, or we normalize neither.  We want to be able to apply normalization to only the RF signal. 

Just sitting on the tail of the CARM resonance, there were some random times when we seem to have swung through total resonance, and spoiled our 1/sqrt(trans) signals, which aren't valid at resonance, and so we lost lock.  This implies that auto-transitioning, as CESAR should do, will be helpful. 

Attempt at transitioning DARM to AS55:

Next up, we tried to transition DARM to AS55, after we had CARM on the 1/sqrt signals.  This was unsuccessful.  Part of the reason is that it's unclear what the relative gain should be between the ALS darm signals and AS55, since the transfer function is not flat.  Also, we didn't have much coherence between the ALS signals and AS55Q at low frequencies, below about 100 Hz, which is concerning.  Anyhow, more to investigate and think on here. 

Transitioning CARM to 1/sqrt signals, with a DARM offset:

As a last test, Q put in a DARM offset in the ALS control, rather than a CARM offset, and then was still able to transition CARM control to the 1/sqrt signals.  As we expect, when we're sitting on opposite sides of the arm resonances, the 1/sqrt signals have opposite signs, to make a CARM signal. 

Conclusions / path(s) forward:

We need to redo the LSC RF signal normalization, so that the normalized signals can be inputs to CESAR. 

We need to make sure we set the AS55 phase in a sane way.

We need to think about the non-flat transfer function (the shape was 1/f^n, where n was some number other than 0) between the ALS darm signal and AS55.  The shape was the same for AS55 I&Q, and didn't change when we changed the AS55 phase, so it's not just a phasing problem. 

What DC signals can we use for auto-transitioning between error signals for the big CARM CESAR?

  9796   Fri Apr 11 01:02:07 2014 JenneUpdateLSCCARM and DARM both on IR signals!!!!!!!!!

[EricQ, Jenne]

We're still working, but I'm really excited, so here's our news:  We are currently holding the IFO on all IR signalsNo green, no ALS is being used at all!!!!  

PRCL and MICH in REFL33, CARM on 1/sqrt(trans), DARM on AS55 Q.

CARM actuating on MC2, DARM actuating +ETMY, -ETMX. 

CARM offset is 1.9 counts, TRX averages about .1 counts. At this offset, we are able to transition CARM from ALS to DC Transmission signals and DARM from ALS to AS55Q. 


  9797   Fri Apr 11 02:09:31 2014 JenneUpdateLSCCARM and DARM both on IR signals!!!!!!!!!

[EricQ, Jenne]

A few more details on our work for the evening, of switching the PRFPMI completely to IR signals (although still with a pretty big CARM offset).

We did the same transition for CARM to 1/sqrt(trans) signals, as last night (elog 9793).  The only difference is that for CARM actuation, we were using a -1*MC in the output matrix, rather than +1's for both ETMs. 

We then had a look at the relative sign and gain between the ALS DARM signals, and AS55Q, using a calibration line in DARM.  Before doing so, we used the DARM line (521.3 Hz, 50 counts) to rotate the AS 55 phase from -60.7 degrees to -97.7 degrees, which gave us about 20dB separation between the I and Q signals.  This informed us that we needed a factor of about 400 less gain for AS55Q than for the ALS darm signal, as well as a minus sign, so I put -400 in the DC normalization place in the LSC for AS55, so that my input matrix would go from ALSY-ALSX (1's) to +1 in AS55Q. 

This transition to AS55 was very easy, and once we did it, we held lock for 5 or 10 minutes, until a large earthquake from Papa New Guinea hit us.  Note however, that we still had a large CARM offset, and our TRX and TRY signals were about 0.1 counts, when we expect several hundred at perfect resonance. 

After that, we relocked, made both CARM and DARM transitions again, and tried to look at a CARM calibration line to see if we see CARM information in any of the REFL RF signals.  We lost lock after a few minutes (so, not related to our calibration line), so we didn't finish, but it looks like REFL55I, normalized by TRX+TRY is the most promising.  Also, REFL55's phase was already very good, while REFL11's phase was not. 

There were some moderate changes to the LSC model that happened, and matching screen changes.  I put in a switch just before the input triggering place of the CARM servo.  This allows us to switch from the "regular" input matrix, and a CESAR signal.  The inputs to the CESAR block are sqrtinv(TRX), sqrtinv(TRY), ALSX, ALSY and the output of the CARM row of the input matrix (so that we can have dynamic normalization of the RF signals).  I have exposed all of these changes in the input matrix screens.

I also modified slightly the ALS watch scripts, to include CARM and DARM servo filter watching, so now we can use the actual CARM and DARM servos.  We should make restore configure scripts for these!

The 2 gps times for when we made the transition from ALS DARM to AS55 DARM were 1081238160 and 1081240217.  We want to go back tomorrow, and extract some nice time series.

Here's a spectrum though, of the difference in noise between DARM on ALS, and DARM on AS55.  The CARM was always on 1/sqrt(Trans) signals during these spectra.  We have an enormous gain in high frequency noise performance once we switch to the RF signal, which is great.


  9799   Fri Apr 11 11:58:24 2014 JenneUpdateLSCCARM and DARM both on IR signals!!!!!!!!!

 A few time series from last night's data. 

300 seconds, starting from 1081240100, showing that as we move from ALSY-ALSX to AS55Q, the DARM error signal gets smaller.


The same 300 seconds, showing that the CARM error signal, and the arm transmissions, are not perturbed during this transition.


DARM in and out, for 300 seconds, showing that the control output also gets smaller.


A slightly longer time series, ending at about the same time, but starting a few minutes earlier, showing us (1) adding a 3 count CARM offset, (2) locking the PRMI (3) transitioning CARM to sqrtinv signals, and then (4) transitioning DARM to AS55Q.


CARM and DARM in and outs, for the 500 second time chunk showing all the transitions.  Unfortunately, it looks like CARM_OUT is more noisy when it's on the sqrtinv signals, than it was on the ALS signals.  Part of this may be that we have not yet swapped the resistor in the TRY QPD, to improve the SNR in the same way that we have already done for the TRX QPD.  [EDIT, JCD:  Also, we had hard-triggered the Trans switching, so we were only looking at the QPD sum for the TRX and TRY, and the QPDs only have a few ADC counts at low transmissions, so we had poor SNR for that reason too.]


  9806   Mon Apr 14 11:19:55 2014 JenneUpdateLSCMC WFS found off

I'm not sure why, but the WFS were turned off when I came in this morning.  The MC was not staying locked, and even during brief locks, the FSS FAST out was railed at 10. 

Aligning the MC mirrors to maximize the transmission, and then engaging the WFS seems to have made things better.

  9807   Mon Apr 14 13:20:45 2014 JenneUpdateLSCIFO Configure screen updated, CARM / DARM scripts added

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

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

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

  9808   Mon Apr 14 17:59:05 2014 JenneConfigurationPEMNew T-240 cable

As payment for borrowing 2 of our seismometers, Zach has made us a new Trillium cable, to go from the granite station to the readout box, which we can put into 1X7, where the PEM ADC is.  To put the T-240 in side the can, and seal it, we need a little jumper cable from the seismometer to the granite, but for now, we can just pass this cable underneath the can.

  9809   Mon Apr 14 19:02:09 2014 JenneUpdateLSCMICH gets noisy as CARM or DARM offset reduced

This afternoon, I was toying around with reducing either the CARM or DARM offsets (so, put in a CARM offset, leave DARM zero, lock the PRMI, then reduce CARM offset to zero.  Or, put in a DARM offset, leaving CARM offset zero, lock the PRMI, then reduce the DARM offset to zero).

When looking at the data, I see that the MICH error signal gets fuzzier when the arms get close to resonance. (Note here that because I forgot to zero the carm offset before finding the resonances, -3 is my zero point for this plot and the next.)


Here is a zoom of the last piece of this time series, but with both TRX and TRY plotted (along with POPDC, CARM_ERR and DARM_ERR), where you can see that I had a momentary power buildup of > 100 transmission counts, which is about 20% of our final expected power.


Here is a different time series, showing a reduction of the DARM offset, and you can see that as the offset approaches zero, the MICH error signal gets noticeably more fuzzy.  Somewhere near the 240 second mark, I lose PRMI lock.


  9810   Tue Apr 15 02:19:54 2014 JenneUpdateLSCAnalog phasing of REFL11 and REFL55

[Jenne, EricQ]

I told Koji that I wanted to play with the common mode servo this evening, and he pointed out that we only get the signals after the digital demod phase angle in the digital system (obviously).  So, if I want to use either REFL11 or REFL55 for my CARM signal, I want to do something in analog-land so that my digital demod phase is close to 0 or 90. 

While we had the PRFPMI locked (with CARM offset of 2 or 3 nm), we set the demod phases of REFL11 and REFL55 to minimize a CARM line in the Q-phase.  This gave us -34 degrees for REFL11, and -75 degrees for REFL55. 

We calculated that about 1 degree of phase shift is about 1/(2 * pi * freq), or about 1.4e-8 seconds of delay for 11MHz.  We took the speed of light in the cables to be about 2/3*c, so 1.4e-8 * 2e8 = 2.9 meters per degree for 11MHz.  Since REFL11 was 34 degrees from 0, we estimate that we need to add about 98 meters of cable to the REFL11 signal path.  The same calculation for 55 MHz, but with a 15 degree shift required, gives 8.8 meters of cable to be added to the REFL55 signal path. 

I connected up some long BNC cables, and inserted them between the heliax breakout board on the LSC rack, and the respective PD inputs of the REFL11 and REFL55 demod boards.  I used (45 meters + 45 meters + a little bit) for REFL11, and used about 9 meters for REFL55. 

When we relocked the PRFPMI, and redid the phasing, we were very close to zero for both REFL11 and REFL55!  REFL11's digital demod phase is now +1 degree, and REFL55's digital demod phase is -5 degrees.

We changed the input of the CM servo board from POY (which Den and Koji had been using in December - see elog 9500) to REFL11 I MON. 

Q locked the FPMI (separate reply elog), and then we tried engaging the CM analog servo.  We were not successful. 


These settings were mostly copied from elog 9500, so they are almost surely not correct. 

CM servo screen:  In1 gain = 31dB, switch on, offset = -2.7V, boost off, super boosts off, option=disable, 79:1.6k switch disabled, polarity minus, option disable, AO gain=8dB, limiter enable.

For the slow path, CM_SLOW -> MC LSC servo had a +1 in the input matrix. 

CM filters in the AUX_ERR screen:  FM1 (unwhite) on, all others off, gain = 2.6. 

MC servo filters:  FM7, FM10 on, all others off (no triggered filter modules).  Gain = 0 initially.

MC servo board AO path disabled initially, G=-32dB initially.


Once Q had the FPMI locked, I tried increasing just the CM analog gain (by enabling the AO path on the MC board, and increasing the gain).  Doing this, I lost lock at -3 dB. 

I then tried again, this time alternating increasing the analog gain, and increasing the MC LSC servo gain.  I got up to 3e-3 for the MC digital gain, and -7 dB for the analog gain before we lost lock again.


We have determined that we should probably try just locking one of the arms with POX or POY, as Den and Koji did, to get a feel for how the system works.



  9816   Wed Apr 16 01:51:16 2014 JenneUpdateLSCScripts written for ALS acquisition, CARM and DARM transitions

[Jenne, EricQ]

This evening, as part of locking activities, we threw together some handy scripts.

The first one, "Lock_ALS_CARM_and_DARM.py" (no judging of my naming style!!), lives in .../scripts/ALS/ . 

It acquires ALS lock in CARM and DARM mode, so we don't have to do it by hand anymore.

The first thing that it does is ask you to acknowledge that your beatnotes are in place, and they follow our new (newer than the last elog about conventions) beatnote convention.  You are reminded in the terminal window what that convention is:  When the temperature sliders for either arm is INCREASED, the beatnote frequency should INCREASE. 

After you acknowledge that the beatnotes are good, it sets the CARM and DARM servo gains to zero, enables the outputs, sets the input matrix elements, clears the phase tracker histories, and starts ramping up the gains (with +1,+1 for DARM, the darm servo gain is +positive.  with -1*ALSX,+1*ALSY for CARM, the carm servo gain is -negative).  At a gain of 3, it engages the integrators and the resonant gains.  At the final gain of 6, it engages the boosts.

We have used this script ~10 times tonight, and it's been great every time.

The next two scripts are for making the transition from ALS to IR signals.  They both live in ..../scripts/PRFPMI/

"Transition_CARM_ALS_to_TransSqrtInv.py" (again - no judging!) slowly blends the input matrix elements to swap CARM control from the ALS signals to the 1/sqrt(trans) signals.  It takes a few steps, and asks for a keyboard input between steps.  This is because if our 1/sqrt(trans) offsets aren't perfect, we can start to lose transmission power.  To mitigate this, we decrease the offset in the CARM servo filter bank to get more power back.  This script requires an input, which is what you want the final sqrtinv matrix elements to be.  It will fail without this.  For a CARM offset, both of the final sqrtinv matrix elements will have the same sign.

"Transition_DARM_ALS_to_AS55.py" (I can telepathically hear you judging me right now.)  does the same blending, except to swap DARM control from ALS signals to AS55Q.  For the same reason of imperfect offset-setting, it takes several steps, to allow you to adjust the CARM offset if needed. Although, after typing this, I realized that perhaps we should have been tweaking the DARM offset.  Either way, this transition required much less tweaking of offsets than the CARM transition did.  Again, the script requires an input, which is your final desired AS55Q->DARM matrix element value.

Both of these scripts should be run at a digital CARM offset of about 2 counts, although with the offset tweaking during the CARM transition, I usually end at about 1.5 counts. 

*  To determine the final gain value for the CARM sqrtinv matrix elements, we have been using a spare filter bank (ex. XARM), and having the input to that be the sum of the sqrtinv channels.  We then put in a CARM line, and look at the transfer function between the temporary filter bank's input, and the CARM_IN1. 

*  To determine the final gain value for the DARM AS55 matrix element, we have been doing a similar thing, looking at the transfer function between DARM_IN1 and AS55Q with a DARM line on.  We have been putting this DC gain into the static PD normalization (4th block from the left on the big LSC screen), although with the new script, it will be easier to just put that value into the matrix element.

  9817   Wed Apr 16 02:11:40 2014 JenneUpdateLSCCARM and DARM on IR signals, boosts engaged

[Jenne, EricQ]

Tonight, we transitioned CARM and DARM to IR signals, took loop transfer functions, and determined that we could engage the LSC boosts (FM4 in the CARM and DARM servos, which are the same as the XARM and YARM servos). 

Q is preparing spectra to post, and I will dig out time series.  Look for these tomorrow, if they aren't posted tonight.

For the time series data fetching, I have taken notes on what we were doing when, so that I can actually find the data.

11:09pm:  CARM's LSC boost on for the first time

11:14pm:  DARM transferred to AS55Q

11:21pm:  DARM's LSC boost on for the first time


11:53pm:  CARM transition

12:02am:  DARM transition done, both LSC boosts on

12:04am:  lockloss after reducing CARM digital offset to 0.4

12:45am: PRMI + 2 arms flashing, with no CARM or DARM offsets (arms still on ALS) because we forgot to put in the CARM offset before restoring PRM alignment.  PRMI may have been actually locked, or we may just have been flashing....need to look through the data to see what our recycling looked like.


1:05am:  pretty smooth transition completed (both CARM and DARM), but we lost lock while reducing the CARM offset.

1:19am: lockloss - why?? We were just sitting at a CARM offset of about 1.3nm (1.3 counts), holding on IR signals.  We were not touching any IFO things while looking at some plots, and just lost lock.  Want to see if we can understand why.

1:27am:  another nice smooth transition for both CARM and DARM to IR signals, but almost immediate lockloss when reducing the CARM offset.

Using the new ALS lock acquisition scripts (elog 9816) and our transition scripts, getting back to PRFPMI lock is pretty smooth and procedural.

* Align arms using ASS (ifo configure screen, restore xarm and yarm, run both arms' ass scripts).

* Align PRMI, no arms (ifo configure screen, restore prmi sideband)

* Find ALS beatnotes, with arm lasers on opposite sides of the PSL.  For both, when increasing the value of the temperature slider, the beatnote should increase in frequency.  (ifo configure screen, restore CARM and DARM als)

* Run ...../scripts/ALS/Lock_ALS_CARM_and_DARM.py

* Run "Find resonance" scripts from ALS screen for each arm.

* Put in a 3 count offset to CARM loop.

* Restore PRM alignment.  (PRMI should acquire lock immediately, although PRM may need some small alignment tweaking).  Enable PRCL and MICH outputs, PRM and BS actuation outputs.

* Reduce CARM offset to 2 counts. 

* Set offsets of 1/sqrt(TRX) and 1/sqrt(TRY) filter banks in the AUXERR section of the LSC screen.  The outputs of both should equal 2 counts (to match the 2 count offset in the CARM loop). 

* Run .../scripts/PRFPMI/Transition_CARM_ALS_to_TransSqrtInv.py , making sure to reduce the CARM digital offset if needed, to keep the arm transmissions at about 0.1 counts.

* Engage FM4 of the CARM filter bank, which is the LSC boost.

* Run .../scripts/PRFPMI/Transition_DARM_ALS_to_AS55.py , making sure to reduce the CARM (or should be DARM?) digital offset if needed, to keep the arm transmissions at about 0.1 counts.

* Engage FM4 of the DARM filter bank, which is the LSC boost.

Notes for going forward:

When we have small-ish digital CARM offsets, such that both of our arm transmitted powers are about 0.1 or higher, we see clear coherence between our CARM_IN1 (the 1/sqrt(trans) signals) and a normalized REFL11_I (again using a spare filter bank like XARM to get REFL11 normalized by (TRX+TRY) ).  We have not yet tried transitioning the CARM digital error signal to this normalized REFL11.

Even though we see that the IFO is much less noisy (as measured by significantly reduced RIN in TRX and TRY as visible by eye on Dataveiwer), we are still losing lock when we reduce the CARM offset.  I have noted above several times, for when we had locklosses, so that I can see if I see anything elucidating in the time series data.

  9819   Thu Apr 17 00:49:06 2014 JenneUpdateLSCCARM and DARM on IR signals, boosts engaged

I looked at 2 of the locklosses from last night, (1:19am and 1:27am), and saw that for both, the DARM loop started to oscillate just before we lost lock.  In the trials tonight, we were more watchful of gain peaking.

Here is the 1:19am lockloss


And here is the 1:27am lockloss


 So you can see what we were doing, and what the effect was, here is a few minutes of data just before the 1:27am lockloss. The times I note below are rough, but should give you an idea of what happened at which time.

0 sec:  Arms are held on resonance with ALS.

10 sec:  CARM offset of 3nm added.

20 sec:  PRM restored, one flash, then PRMI acquires lock.

30 sec:  CARM offset reduced to 2nm, transmitted powers are about 0.1

50 sec:  Transition CARM to 1/sqrt(trans) signals.  Note that we are using the high gain Thorlabs PD here, so the noise is better than last Thursday.

60-110 sec:  CARM offset reduction to about 1nm.

110 sec:  CARM's LSC low frequency boost engaged.

120 sec:  DARM transitioned to AS55Q.

170 sec:  DARM's LSC low frequency boost engaged.


  9820   Thu Apr 17 01:01:02 2014 JenneUpdateLSCLSC model modifications

Last night, EricQ and I were concerned that we might need some CARM UGF servoing, so I added a UGF servo block, copied from the aLIGO LSC model, to our LSC model.  The block is inline with the CARM servo, after the output triggering, just before the output matrix.  Q put together some screens, which are accessible from the main LSC screen. 

The model is compiled and running.  We didn't get very far in testing it though before Koji pointed out that it is a slow solution, and not a fast one like we were searching for.  We were hoping to deal with the momentary power buildup, and thus optical gain change, as the arms flash close to resonance.  The UGF servo will not work nearly that fast though.  We may want it for slow UGF servo-ing, but it's not the solution to what Q and I were thinking about yesterday.  Regular ol' dynamic normalization is closer to the right answer for this.

In tonight's activities, Koji and I found that we probably want a CESAR block for DARM as well as CARM, so that we can independently normalize AS55Q. 

To solve the DARM oscillation issue from last night (that I discovered this evening when I finally looked at the time series data), we may want to implement a DARM UGF servo.  For tonight, as we reduced the CARM offset and started seeing gain peaking in the DARM spectra, I hand-reduced the DARM gain.


  9821   Thu Apr 17 01:18:34 2014 JenneUpdateLSCAttempt at handing CARM to REFL11

[Jenne, Koji]

This evening, Koji and I followed the procedure from last night (elog 9817), with the exceptions that as we saw gain peaking in the DARM spectrum, we lowered the DARM servo gain.  We also left the DARM FM4 boost off, and added (TRX+TRY) power normalization to AS55 (although we still had to hand-reduce the gain).    These changes enabled us to reduce the CARM offset much further.  We were able to get the transmitted powers to hold steady at about 1 count while on the IR signals, which is a new record for us.  (We had in the past held the arms with ALS at several counts, but the power fluctuations were huge, and now they are nice and small).

After that, we started looking at whether we could transition CARM over to REFL11I.  We tried a few times, but never made it all the way.

Here are some times for data-foraging tomorrow:

8:27pm, nice transition, CARM offset reduction to 0.6 before lockloss.

9:19pm, turned on power normalization for AS55Q, then reduced CARM offset to 0.5

9:40pm, Lockloss after reducing CARM offset to -0.24, arm transmitted powers around 0.9.

gps 1081748419: First trial trying to transition CARM to REFL11I normalized by (TRX+TRY).

gps 1081749965:  Tried to transition CARM to (REFL11 + REFL33)/(TRX+TRY).  Got about 1/3 of the way through the transition (in terms of matrix element value steps) before lockloss.

11:56pm, Tried to add in REFL11I to CARM error signal (without reducing 1/sqrt(trans) matrix elements).  We increased the REFL11 matrix element until we saw gain peaking, and then tried reducing the 1/sqrt(trans) contribution, and lost lock.  We were only at an offset of 0.3, so we probably weren't close enough to the resonance yet.  We were able to add in REFL11 information, but this was probably not too hard, since there wasn't much actual information in it.


* It's a little weird that once we are on IR signals, the 0 CARM offset point that we find with ALS is not the true CARM offset point.  Although, this may be because we're just going to an averaged no CARM offset place with ALS, but since ALS is noisy, we won't ever really be holding on the zero offset point.  Anyhow, when we were using the 1/sqrt(trans) signals for CARM, and the CARM digital offset was -0.24, the ALSX and ALSY outputs were both about 0.5 in magnitude.

* We're getting there! 

  9823   Thu Apr 17 16:04:40 2014 JenneUpdateElectronicsHigh gain Trans PD electronics change


 I have made the same modification to the Yarm trans PD whitening board as was done for the xend, to increase our SNR.  I put in a 2.1kOhm thin film resistor in the Rgain place.

When I was pulling the board, the ribbon cable that goes to the ADC had its connector break.  I redid the ribbon connector before putting the board back. 

I see signals coming into the digital system for both the high gain and low gain Y transmission PDs, so I think we're back.  I will re-do the normalization after Jamie is finished working on the computers for the day.

  9826   Thu Apr 17 17:22:32 2014 JenneUpdateCDSmx_stream not starting on c1ioo, locking okay

Jamie tells me that the 2 big consequences of this are (a) we are not archiving any data that is collected on the ioo machine, and (b) that we will not have access to test points on the IOO or ALS models.

To make sure that this is not a show-stopper for locking, I have locked the arms using ALS.  The signals seem to still be getting from the ALS model to the LSC model, and I'm able to acquire ALS lock, so we should be able to work tonight.  All of the data that I have been looking at lately has been coming off of the LSC machine, so we should even be okay in terms of look-back for lockloss studies, etc.


  9829   Fri Apr 18 12:53:54 2014 JenneUpdateLSCAttempt at handing CARM to REFL11: Time series

Some time series data from Wednesday night. 

Here is the first time we've gotten the arm transmissions to about 1 count, while holding CARM and DARM on IR signals, so the transmission, as well as POPDC, were relatively quiet.


As we were attempting to transition CARM to REFL11I, at least 2 of the times, we were hitting a CARM oscillation:



  9832   Fri Apr 18 20:17:17 2014 JenneUpdateLSCALS noisy

Last night, as well as tonight, the ALS seems not quite as robust as it was earlier in the week.

I have just taken noise spectra, and ALS is definitely more noisy than usual. 

These plots are with the arms held in CARM and DARM mode, with servo gains of 8. I was seeing the beginnings of gain peaking at a gain of 10, so I turned it back to 8.  Our ALS in-loop RMS is usually something like a few hundred Hz, but I'm seeing over 1kHz, so I have a factor of 4 or 5 too much noise.  Why?!?!?



  9838   Tue Apr 22 01:11:42 2014 JenneUpdateLSCTRY 60Hz noise



P.S. I realigned the Y green to the arm and brought GTRY to 0.93

This evening, I was not able to successfully transition CARM from ALS to 1/sqrt(trans) signals.  The TRY time series looked odd, so I took a spectra, and we have huge 60Hz noise in TRY. 

I found a lock stretch from around 6:30pm that did not show the 60Hz noise, and then there was a lock stretch around 8pm that did have the noise.  So, something happened at the Yend between 6:30 and 8pm tonight.

Asking around, this was the time frame in which Manasa was down at the Yend to realign the green beam, and to check cabling for the PZT_OUT and ERR_MON signals to the ADC.

Looking at the spectra, Rana noted that we have even as well as odd harmonics of the 60Hz line, which is unusual.


To try to diagnose the problem, Rana and I tried to make sure no cables' connectors were touching, and that no equipment was plugged in that shouldn't be.  We noticed that none of: the shutter, the Thorlabs TRY PD, or the QPD TRY are isolated from the table.  To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable.  The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it.  Removing the shutter from the system did not change anything. 

We don't see the 60Hz noise in the Xarm, so it's not on the laser light itself.  Also, we don't see the 60Hz lines in the Yarm feedback signal, so we're not putting the lines onto the mirror, and thus onto the Yarm's light. 

Manasa, can you please take a look, and see if you can figure out what is going on?  We need TRY so that we can transition to 1/sqrt(trans) signals for CARM.  Thanks!!

  9839   Tue Apr 22 01:39:57 2014 JenneUpdateCDSFB unhappy again

[Jenne, Q]

The frame builder (or something) is unhappy again.  I know that we've seen this before, but I can't find the elog entry that relates to this particular problem.

Every few minutes, the fb status lights on the CDS_STATUS screen go white, and then come back green.  It's annoying when it happens every hour or so (which is unfortunately typical), but it's pretty debilitating when it stops dataviewer and dtt every few minutes.  Just from the way the lights change, it looks like perhaps the daqd process is restarting itself periodically? 

  9845   Thu Apr 24 00:11:35 2014 JenneUpdateLSCYend shutter back.


To see if perhaps the shutter was the problem, I turned off the power to the Yend green shutter, and unplugged the cable.  The cable is laying on the table, with the connector sitting on a piece of plastic to isolate it.  Removing the shutter from the system did not change anything.

 I re-plugged in the Yend shutter, and turned it on.

  9846   Thu Apr 24 02:12:05 2014 JenneUpdateLSCLocking without TRY

I tried some locking anyway tonight, even though we don't have TRY. 

The biggest conclusion is that I miss the auto-resonance-finding.  I've been roughly scanning the Y-ALS offset to find the POY zero crossing when I see the resonance on the test mass face cameras. 

The next-biggest conclusion, is that I can hold the PRFPMI close to resonance, using ALS for CARM and DARM.  I was trying to transition DARM to AS55, but I couldn't get the last bit of the way.  That is, I couldn't turn off the ALS control.  So, I think that AS55 wasn't actually holding DARM, until maybe the last moment or so.

Anyhow, here are some time series.  My average TRX value is around 40 counts, and POPDC is maybe 250 counts (just PRMI, POPDC is about 75 counts).  Obviously this is noisy as hell, but I'm not using any IR signals for the arms.  Near the end of this first time series, I am trying to switch to AS55 for DARM.


Zooming in, my real lockloss is due to PRCL oscillating at ~350 Hz:


However, I also saw ~25Hz peaks in CARM and DARM on the spectra starting to show up, and I see a ~25 Hz oscillation in DARM a few moments after the PRCL lockloss.  (Plot #2 is a zoom of the ~1.1 second mark on Plot #3.)


The locking parameters:


Input:  Using the new CESAR matrix, -1*ALSX, +1*ALSY.  Beatnotes both move up in freq if temp sliders move up.

Servo: gain = 6, FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts. 

Output = -1*MC2


Input:  +1*ALSX, +1*ALSY

Servo:  gain = 4.  FMs 1, 2, 3, 5, 6, 7, 9 on.  Offset = 0 counts.

Output = -1*ETMX, +1*ETMY


Input:  +1*REFL33_I, Norm = +0.01*POPDC, sqrt engaged.

Servo:  acquisition easier with -0.04 or -0.06, less gain peaking at -0.02   FMs 4, 5 on; 2, 3, 6, 9 triggered with 0.5 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +1*PRM

PRCL ASC off, PRM oplev on.


Input:  +1*REFL33_Q, Norm = +0.01*POPDC, sqrt engaged.

Servo:  gain = 2, FMs 4, 5 on; 2, 3 triggered with 0.2 sec delay.  Servo trigger = POPDC, up 100, down 10.  FM trigger = POPDC, up 300, down 20.

Output = +0.5*BS, -0.2625*PRM


REFL33 analog gain set to 30 dB for both I&Q.

AS55 set to 0 dB for both I&Q.  AS55 had DC normalization of 80 counts (which was the measured number for PRFPMI when TRX was about 0.1 count this evening)


ELOG V3.1.3-