40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 145 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  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. 

 

sqrtInvLock.pdf

 


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?

  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.

REFL11_analog.pngREFL55_analog.png

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.

REFL11_digital.pngREFL55_digital.png

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:

REFL11_analog_normalizedPOPDC.pngREFL55_analog_normalizedPOPDC.png

REFL11_digital_normalizedTRX.pngREFL55_digital_normalizedTRX.png

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.

  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. 

MICH / PRCL:

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


Observations:

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.

TRX_TRY_QPDonly.png

The REFL_I error signals and the CARM offset.

LSC_error_signals.png

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.

REFL1f_AS55.png

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.

PRM_SUSangles.png

  9790   Tue Apr 8 23:04:14 2014 manasaUpdateLSCarm length measurements

Quote:

 Since we don't have an arm length precision measurement (i.e. better than centimeters), why not just do as Koji suggests and use the ALS to get the frequency spacing between a few red FSR and then we have the measurement solid ?

Arm lengths measured using ALS. Both the arms were estimated to have the same length (to the order of a centimeter) 37.51 m

How
I used ALS error signal to lock the arms and scanned the arm to find 4 consecutive IR resonances. From the beat note frequencies measured using the spectrum analyser during IR resonance, the FSR, and hence the length of the arms were calculated.

The estimated lengths are not very precise down to a mm given the resolution of the spectrum analyser. We have brought out the rubidium clock to use as reference for the spectrum analyser to challenge the measurements.

  9789   Tue Apr 8 19:10:39 2014 ranaUpdateLSCarm length measurements

 Since we don't have an arm length precision measurement (i.e. better than centimeters), why not just do as Koji suggests and use the ALS to get the frequency spacing between a few red FSR and then we have the measurement solid ?

  9788   Tue Apr 8 10:44:53 2014 KojiUpdateLSCPlaying with PRMI + 2 arms

I vaguely remember that the ALS count (Phase Tracker output) is converted to Hz@532nm by a factor  ~20kHz/cnt.
This means the calibration for the IR frequency is 10kHz/cnt.

If this is true 100cnt is 2MHz. Isn't it too big?

Assuming 38.5m for the arm length, FSR is 3.89MHz. (~389cnt)

Our sideband is at integer multiples of 11.03MHz. So...

1xf1 is 0.62MHz (62cnt) away from the carrier
2xf1 is 1.24MHz (124cnt)
3xf1 is 1.86MHz (186cnt)
5xf1=1xf2 is 0.79MHz (79cnt)
10xf1 = 2xf2 is 1.58MHz (158cnt)
15xf1 = 3xf2 is 1.52MHz (152cnt)

So we have to be well with in 62cnt to avoid resonating modulation sidebands.

There maybe some mistake in the factors.
e.g. Phase Tracker calibration is not correct, or CARM ALS OFFSET has factor 2 different calibration from the arm ALS offset.

  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.

  9786   Mon Apr 7 15:26:32 2014 jamie, ericqUpdateCDSaborted attempt to update c1sus machine with second CPU

This morning we attempted to replace the c1sus front end machine with a spare that had been given a second CPU, and therefore 6 additional cores (for a total of 12).  The idea was to give c1sus more cores so that we could split up c1rfm into two separate models that would not be running on the hairy edge of their cycle time allocation.  Well, after struggling to get it working we eventually aborted and put the old machine back in.

The problem was that the c1sus model was running erratically, frequently jumping up to 100 usec of a 60 usec clock allocation.  We eventually tracked the problem down to the fact that the CPUs in the new machine are of an inferior and slower model, than what's in the old c1sus machine.  The CPU were running about 30% slower, which was enough to bump c1sus, which nominally runs at ~51 usec, over it's limit.

This is of course stupid, and I take the blame.  I skimped on the CPUs when I bought the spare machines in an attempt to keep the cost down, and didn't forgot that I had done that when we started discussing using one of the spares as a c1sus replacement.

I think we can salvage things, though, by just purchasing a better CPU, one that matches what's currently in c1sus.  I'll get Steve on it:

c1sus CPU: Intel(R) Xeon(R) CPU X5680 3.33GHz

In any event, the old c1sus is back in place, and everything is back as it was.

  9785   Fri Apr 4 18:51:29 2014 ericqSummaryLSCMORE CARM related modeling

In today's ISC call, Kiwamu was comparing two ways to approach resonance: 

  • "C-Type": The scheme we currently think about; zero DARM offset and slowly reduce the CARM offset
  • "D-Type": Start with no CARM offset, but a DARM offset and reduce that. 

D-type might be interesting to check out, since things change a little less dramatically when you reduce the DARM offset. Maybe this makes signal hopping easier? Signal recycling may complicate things, though. 

So, I've simulated CARM and DARM offset effects on CARM and DARM signals. (As with the previous plots, this is for the PRFPMI configuration.) From moving both offsets around, it looks like the resonance peak is about 5x wider in DARM than in CARM, so I simulated a 50pm offset range for CARM and a 250pm offset range for DARM. 

Here are some CARM signal transfer functions subject to CARM offsets in the top plot, and DARM offsets in the bottom plot. 

 carm2REFL11.pdfcarm2REFL55.pdf

carm2REFLDC.pdfcarm2TRX.pdf

 

It's looks like the DARM offset changes cause much less dramatic changes in the CARM plant features. It's conceivable that this would make CARM locking easier. 

Here are some DARM plant transfer functions. 

 darm2AS11.pdfdarm2AS55.pdf

darm2ASDC.pdfdarm2TRX.pdf

In these plots, I did something kind of artificial: when we move the CARM offset, it changes the proper demodulation phase to get DARM in the Q of the AS 1F RFPDS. So, at each CARM offset, I re-phased the AS 1F demodulators, to show the total DARM information available at the AS RFPDs at each offset, rather than what one would actually see in them with a static demod phase. 

ASDemodAngles.pdf 

  9784   Thu Apr 3 18:55:10 2014 ericqSummaryLSCSome CARM related modeling

 The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal. 

Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:

This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:

asIsPRCRes.pdf idealPRCRes.pdf

(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)

This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.) 

 3fPrclAnglesCarm.pdf

My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me... 

 

  9783   Thu Apr 3 18:09:54 2014 ericqUpdateLSCAttempt at PRMI+2 arms

So, here's the basic: "We reduced the CARM offset and saw more TRY" plot. 

offsetTRY.pdf

 

As Jenne mentioned, we suspected that we were seeing real displacement information in the sqrtInv signals. (We had incidentally hard switched to the transmon QPDs for all of this)

Here's a 2d-histogram of the ALS CARM error signal vs. the sqrtInv CARM signal (i.e. 1/sqrt(TRX) + 1/sqrt(TRY))

 

2dhist.pdf

This is exactly the shape we expect, which is cool. You can see where we stepped the offsets, too. It looks like the signal gets into it's good linear range when ALS CARM was about -20, which is when TRY was a little under 0.1, which seems pretty early and potentially useful. 

Also, here are snapshots of what REFL11_I and sqrtInv CARM were doing in the last five seconds of time in the above plot, which was shortly before we made the offset push that broke the PRMI lock. If you look really closely, maybe you can convince yourself that there is some common information in them...? It's hard to say. In any case, there is definitely CARM pdh action happening.

pdh_trans.pdf

  9782   Thu Apr 3 17:05:52 2014 SteveUpdateVACMaglev controller swapped

Quote:

Quote:

Quote:

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

 The Osaka TG390MCAB maglev turbo pump's controller TC010M has passed the 40,000 hrs of operation. This triggered the " alarm" LED  warning light to come on. 

It is normal maintenance.  Maglev TP-1 is running perfectly.  Osaka will send us a loaner-controller that we can use while they do the std maintenance.

I'm thinking of ~ February to do this.

 We just received the loaner controller that will be swapped in it tomorrow morning.

The vacuum pressure will rise somewhat during this action.

 The loaner controller is swapped in. It has  520 Hz rotation speed.  This speed use to be 680 Hz with our old one.

  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.

  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?). 

  9779   Wed Apr 2 23:08:51 2014 KojiSummaryASCNew PRM ASC is running

The new PRM ASC design


Pitch
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1Hz, q: 3
pole: f: 2Hz q: 3  / f: 2.7Hz, q: 2  / f: 1Hz, q: 15

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/Sqrt(2) (2nd order butterworth)

Servo gain: -0.023

Yaw
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM5: (boost)
zero: f: 0.5Hz q: 1  /  4Hz, q: 2 / f: 1.5Hz, q: 10
pole: f: 1.02Hz q: 10  / f: 3Hz, q: 5  / f: 2Hz, q: 6

FM9: (HF Roll-off)
pole: f: 40Hz q: 1/sqrt(2)
 
Servo gain: -0.027


The loop gains were adjusted to have the UGFs of 10Hz. The measured openloop transfer functions were compared with the model.
The transfer functions for yaw are well matched. However, the pitch ones don't. It seems that the pitch loop has extra low pass
which I can't locate. The possibility is the analog electronics of the pitch loop.


The effect of the control between 0.3Hz to 3Hz are well represented by the model. The attachment 2 shows the free running
angle fluctuation, the ones with the control engaged, and the estimated spectra. Indeed, the estimated spectra well represent
the measured angular spectra.

  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).

  9777   Wed Apr 2 19:50:12 2014 KojiSummaryASCNew PRM ASC is running

As the designed ASC filters in this entry had too little phase margins (~10deg), I had to compromise the servo design.

The design was modified and tested again. This will be reported by a following entry.

Incidentally, I have adjusted the demodulation phases of REFL33/55/165 for PRMIsb so that the PRCL is eliminated from the Q signals.

REFL33    125.5 deg -> +136.5 deg
REFL55      45.0 deg -> +  25.0 deg
REFL165   -79.5 deg -> +  44.5 deg

This change of the demod phase for REFL165 was a bit surprising.
I did not check the sign, so it could be -135.5 deg. But still this is a bit change.

  9776   Wed Apr 2 16:34:15 2014 SteveUpdateVACMaglev controller needs service

Quote:

Quote:

 The date is correct on this monitor.

Last stored RGA scan data Dec 20, 2013

IFO pressure at CC1 5.8e-6 Torr

Valve configuration: Vacuum Normal, confirmable only by manual checking of position indicators and pressure gauge controllers  readouts

 

 The Osaka TG390MCAB maglev turbo pump's controller TC010M has passed the 40,000 hrs of operation. This triggered the " alarm" LED  warning light to come on. 

It is normal maintenance.  Maglev TP-1 is running perfectly.  Osaka will send us a loaner-controller that we can use while they do the std maintenance.

I'm thinking of ~ February to do this.

 We just received the loaner controller that will be swapped in it tomorrow morning.

The vacuum pressure will rise somewhat during this action.

  9775   Wed Apr 2 09:31:22 2014 SteveUpdatePEMlocal 3.0M earthquake

Quote:

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.

 Atm2, Chilean 8.2M eq arrived to the 40m 16:57 in 10 minutes. Our OSEMs did not see them.  Hanford got it 2 minutes later.

  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.

  9773   Tue Apr 1 22:03:44 2014 KojiSummaryASCNew PRM ASC is running

[Koji Jenne]

New PRM ASC was implemented. [to be cnt'd]

  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.

  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.

  9770   Tue Apr 1 17:37:57 2014 EvanUpdateComputer Scripts / ProgramsComsol 4.4 upgrade

Comsol 4.4 is now installed under /cvs/cds/caltech/apps/linux64/COMSOL44. I've left the other installations alone. I've changed the symlink on megatron so that comsol now starts Comsol 4.4.

The first time I ran comsol server, it asked me to choose a username/password combo, so I made it the same as the combo used to log on to megatron.

We should consider uninstalling some of the older Comsol versions; right now we have 4.0, 4.2, 4.3b, and 4.4 installed.

  9769   Mon Mar 31 23:57:22 2014 KojiSummaryASCPRM ASC characterization / design

A series of measurements / calculations for the PRM ASC characterization and servo design

1) Actuator characterization

The actuator responses of the PRM in pitch and yaw were measured (attachment figure 1). I believed the calibration of the oplev QPD to be
1 count/urad. The oplev servo loops were turned off at the FM inputs, and the filter banks were turned off so that the response has the open
loop transfer function except for the servo filter.

The measured transfer functions were fitted with LISO. The LISO results (c.f. the source codes) were shown in the figure. The responses also
include the 60Hz comb filter present in the input filters. The responses are well approximated by the single pendulum with f0 of 0.6-0.8 and q of 3.5 and 6.3.

From this measurement, the actuator responses of the PRM at DC are estimated to be 2.2 urad/cnt and 1.8 urad/cnt in pitch and yaw, respectively.

2) Sensor response of the POP QPD

As we already know how the actuators respond, the QPD optical gain can be characterized by measuring the actuator response of the QPD
(attachment figure 2). The QPD signals are such noisy that the response above 1Hz can't be measured with sufficient coherence. Below 1Hz,
the response is well represented by the actuator response measured with the oplev. From this measurement, the optical gains of the QPD
with respect to the PRM motion are 650 cnt/urad and 350 cnt/urad.

3) Open loop transfer function of the current ASC servo

By combining the above information with the servo setting of the servo filters, the open loop transfer functions of the PRM QPD ASC loops
were estimated (attachment figure 3). Actually the expected suppression of the fluctuation is poor. The yaw loop seems to have
too low gain, but in fact increasing gain is not so beneficial as there is no reasonable phase margin at higher frequency.

With the estimated openloop transfer functions and the measured free-running angular fluctuation, the suppressed angular spectra can be
estimated (attachment figure 4). This tells us that the suppression of the angular noise at around 3Hz is not sufficient in both pitch and yaw.
As there is no mechanical resonance in the actuator response at the frequency, intentional placement of poles and zeros in the servo filter is necessary.

4) Newly designed ASC filter

Here is the new design of the QPD ASC servo (attachment figure 5). The target upper UGF is 10Hz with the phase margin of 50 to 60deg.
The servo is AC coupled so that we still can tweak the alignment of the mirror.

As this servo is conditionally stable, at first we should close the loops with stable filter and then some boosts should be turned on.
Estimated suppressed fluctuation is shown in the attachment figure 6. We can see that the fluctuation was made well white between 0.5Hz to 10Hz.

The filter design is shown as follows:


Pitch
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM3: (boost)
zero: f: 0.5Hz q: 1  /  4.5Hz, q: 1 / f: 1Hz, q: 3
pole: f: 2Hz q: 3  / f: 2.7Hz, q: 2  / f: 1Hz, q: 15

FM9: (HF Roll-off)
pole: f: 40Hz q: 1.7
 
Servo gain: -0.028

Yaw
FM1: zero at 0Hz, pole at 2000Hz, gain at 2000Hz = 2000

FM3: (boost)
zero: f: 0.7Hz q: 2  /  3Hz, q: 7 / f: 2Hz, q: 6
pole: f: 1.02Hz q: 10  / f: 4.5Hz, q: 0.8  / f: 1.5Hz, q: 10

FM9: (HF Roll-off)
pole: f: 40Hz q: 1.7
 
Servo gain: -0.0132


 

  9768   Mon Mar 31 21:23:30 2014 GabrieleSummaryLSCMICH sensing oddities in REFL 3F

I'm not sure what may cause this. To back up this measurement/interpretation, I tried to take measurements of these transfer functions across different excitation frequencies via swept sine DTT, but seismic activity kept me from staying locked long enough...

I guess that you get an ellipse when the transfer functions to I and Q have a different phase. One mechanism could be that when driving MICH we make some residual PRCL and this couples with a different transfer function to both I and Q. However, I would expect no phase lag in the PRMI configuration, since there is no enough optical delay in the system to give significant dephasing at few hundreds Hz. This effect might come from mechanical resonances.

It is worth measuring the optical transfer functions from both PRCL and MICH to REFL signals at all frequencies, to see if we have strange features in the TFs.

  9767   Mon Mar 31 17:47:57 2014 ericqSummaryLSCMICH sensing oddities in REFL 3F

Last week, while I had the PRMI locked on REFL33, I did some poking around with mirror excitation to RFPD quadrature transfer functions. I got some indication of weird things with sensing MICH with the 3F REFL signals, but it should be explored more before taken as a real thing. I just figured I would show what I saw. 

With that disclaimer out of the way, here's what I did:

  • Locked PRMI on PRCL:REFL33_I and MICH:REFL33_Q, as detailed in my earlier ELOG
  • Created PRCL and MICH excitations at two different frequencies, notched said frequencies out of the control filters
  • Took transfer functions from mirror LSC output signals to 33 I, 33 Q, 165 I, 165 Q in DTT
  • For each DOF, look at the measured transfer functions only at the excitation frequency. (Assuming good coherence, which was there)

The basic idea was, some PRCL motion (for instance), has a transfer function to both the I and Q quadratures at a given PD. As the PRCL excitation sine wave goes through one cycle, the REFL signals at the excitation frequency go through some coherent cycle. Thus, the excitation traces out some trajectory in the I vs. Q plane. I believe this is analogous to the typical "radar plot" that we make for sensing matrix elements. 

However, the straight line that we normally plot in the radar plots assumes a certain phase relationship between the DOF-> I and DOF->Q transfer functions that results in a straight line. Here are the trajectories I actually measured, normalized by the excitation amplitudes.

REFL_33_traj.pdfREFL_165_traj.pdf

The plotted traces are (x,y) = (H_prcl->I * prcl, H_prcl->Q * prcl) and  (x,y) = (H_mich->I * mich, H_mich->Q * mich) where H_prcl->I is the measured complex transfer function from prcl to REFL I, for instance, and prcl and mich are the excitation signals, normalized to unit amplitude.

PRCL looks like a nice straight line in both of these, and pretty well phased, but not only is MICH not very orthogonal to PRCL, there is quite a bit of ellipticity present, which means we can't fully decouple the two DOFs, even if they were nominally orthogonal. 

I'm not sure what may cause this. To back up this measurement/interpretation, I tried to take measurements of these transfer functions across different excitation frequencies via swept sine DTT, but seismic activity kept me from staying locked long enough...

  9766   Mon Mar 31 13:26:23 2014 manasaUpdateLSCLSC model modified

I have included Yarm CESAR to the LSC model. It was just a copy paste of the Xarm CESAR. Since we are now meditating about implementing CCESAR and DCESAR, I did not run or install the model as yet.

  9765   Mon Mar 31 13:15:55 2014 manasaSummaryLSCAlignment update

Quote:

While I'm looking at the PRM ASC servo model, I tried to use the current servo filters for the ASC
as Manasa aligned the POP PDs and QPD yesterday. (BTW, I don't find any elog about it)

 Guilty!!

POP path

The POP PD was showing only ~200 counts which was very low compared to what we recollect from earlier PRMI locks (~400 counts). Also, the POP ASC QPD was also not well-aligned.
While holding PRMI lock on REFL55, I aligned POP path  to its PD (maximize POP DC counts) and QPD (centered in pitch and yaw).

X and Y green

The X green totally lost its pointing because of the misaligned PZTs from last week's power failure. This was recovered.
Y arm green alignment was also recovered.

  9764   Mon Mar 31 11:34:00 2014 manasaSummaryIOOMC2 moved

Quote:

I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.

 MC2_TRANS path in WFS servo turned OFF.

  9763   Mon Mar 31 08:11:00 2014 SteveUpdateSUSrecovery from earthquakes

Quote:

* EQ Southeast of LA around 45 minutes ago. Callum and I felt it.

* Koji and I came in to recover. MC suspensions had been mis-aligned. ETMs both tripped their watchdogs.

* As before, the ETMX was stuck in its cage and the UR & LR OSEMs were reading zero V.

* We moved the MC sus back to their OSEM values from 2 hours ago. Koji aligned everything else by just using his chee.

* To shake the ETMX loose, I tried a different tactic than the "Great Balls of Fire". I started giving it 20k steps through the ASCYAW filterbank (with ramping OFF). I used the green light in the X arm video to look at the swinging. Using this as a readback I pumped the OFFSET button on ASCYAW to resonantly swing up the yaw motion. I had to turn the watchdog thresh up to 2000 temporarily. After a couple minutes the ETMX was free.

* We then used the bias sliders to steer it back onto the OL center (which Q nicely lined up for us recently) and then X arm locked in green right away.

Fri Mar 28 22:38:04 2014:  We've just ridden through the 5th aftershock. None of the aftershocks have tripped the watchdogs  but they break the IMC lock.

Local earthquake activity is up. Our suspensions are holding well.    ETMX and ETMY sus damping restored.

  9762   Sat Mar 29 00:11:39 2014 KojiConfigurationGeneralNTP setting on nodus

FB: /etc/ntp.conf was updated as below such that it refers nodus and also caltech server when nodus is not available

server 192.168.113.200
server 131.215.239.14

ntpd was restarted and

diskless RT machines: they are booted from /diskless/root on fb.
Therefore /diskless/root/etc/ntp.conf was updated in the same way as above.
When the machines are rebooted, this setting will be active.

control machines:

now they are referring nodus and other external servers too.

  9761   Fri Mar 28 23:28:13 2014 KojiConfigurationGeneralNTP setting on nodus

[Koji Rana]

We are looking at NTP settings. I looked at nodus.

- xntpd is running

- We decided to start over the configuration file /etc/inet/ntp.conf

    - The old configuration was moved to ntp.conf.bak

    - The server configuration file was copied from ntp.server to ntp.conf

    - Caltech NTP servers 131.215.239.14 and 131.215.220.22 were selected as the servers we are reffering

    - Commented out the lines for "fudge" and "broadcast"

- xntpd was restarted

    - sudo /etc/init.d/xntpd stop
    - sudo /etc/init.d/xntpd start

- check how the daemon is running
      tail -50 /var/adm/messages

   Mar 28 23:00:49 nodus xntpd[27800]: [ID 702911 daemon.notice] xntpd 3-5.93e Mon Sep 20 15:47:11 PDT 1999 (1)
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 301315 daemon.notice] tickadj = 5, tick = 10000, tvu_maxslew = 495, est. hz = 100
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 798731 daemon.notice] using kernel phase-lock loop 0041
   Mar 28 23:00:49 nodus last message repeated 1 time
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 132455 daemon.error] trusted key 0 unlikely
   Mar 28 23:00:49 nodus xntpd[27800]: [ID 581490 daemon.error] 0 makes a poor request keyid

- check the syncing staus by ntpq -p

        remote           refid      st t when poll reach   delay   offset    disp
   ==============================================================================
   *ntp-02.caltech. .CDMA.           1 u   37   64  377     0.56    3.010    0.08
   +ntp-03.caltech. ntp1.symmetrico  2 u   36   64  377     0.52    2.727    0.12

      this * means nodus is synced to ntp-02. "+" means it is stand by as a valid secondary server.  "when" increases every second.
      When "when" reaches "poll" the clock is synced to the server. These marks are not set at the beginning.
      It was necessary to wait for sometime to get synced to the server.

- Once nodus became a synced server, the realtime systems starts syncing to nodus automatically.

   controls@c1sus ~ 0$ cat /var/log/ntpd
   25 Mar 01:41:00 ntpd[4443]: logging to file /var/log/ntpd
   (...)
   28 Mar 23:13:46 ntpd[4983]: synchronized to 192.168.113.200, stratum 2
   28 Mar 23:14:25 ntpd[4983]: time reset +39.298455 s
   28 Mar 23:14:25 ntpd[4983]: kernel time sync status change 2001
   28 Mar 23:25:19 ntpd[4983]: synchronized to 192.168.113.200, stratum 2
   controls@c1sus ~ 0$ ntpq -p
        remote           refid      st t when poll reach   delay   offset  jitter
   ==============================================================================
   *nodus.martian   131.215.239.14   2 u   42   64  377    0.140   42.222  11.373

  9760   Fri Mar 28 22:10:00 2014 rana, kojiUpdateSUSrecovery from

* EQ Southeast of LA around 45 minutes ago. Callum and I felt it.

* Koji and I came in to recover. MC suspensions had been mis-aligned. ETMs both tripped their watchdogs.

* As before, the ETMX was stuck in its cage and the UR & LR OSEMs were reading zero V.

* We moved the MC sus back to their OSEM values from 2 hours ago. Koji aligned everything else by just using his chee.

* To shake the ETMX loose, I tried a different tactic than the "Great Balls of Fire". I started giving it 20k steps through the ASCYAW filterbank (with ramping OFF). I used the green light in the X arm video to look at the swinging. Using this as a readback I pumped the OFFSET button on ASCYAW to resonantly swing up the yaw motion. I had to turn the watchdog thresh up to 2000 temporarily. After a couple minutes the ETMX was free.

* We then used the bias sliders to steer it back onto the OL center (which Q nicely lined up for us recently) and then X arm locked in green right away.

Fri Mar 28 22:38:04 2014:  We've just ridden through the 5th aftershock. None of the aftershocks have tripped the watchdogs  but they break the IMC lock.

  9759   Fri Mar 28 20:23:02 2014 ranaSummaryIOOMC2 moved

I aligned MC2 suspension by 0.01 in pit and yaw to align the MC better to the PSL beam. Then I turned the WFS back on. The beams are not centered on the WFS heads.

Nic and Gabriele ought to send their SURF some example code (in April) for how to start redesigning the WFS telescopes so that we can order some optics in early June.

I've also turned on the MC2 TRANS path to gather some data over the weekend on how well or bad it works. Please turn it off on Monday.

  9758   Fri Mar 28 17:22:55 2014 KojiSummaryLSCPRMIsb locked with REFL165I&Q again

While I'm looking at the PRM ASC servo model, I tried to use the current servo filters for the ASC
as Manasa aligned the POP PDs and QPD yesterday. (BTW, I don't find any elog about it)

I found no issue for locking PRMIsb with the REFL165I&Q signals if the PRM ASC is employed.
See this entry for the IFO settings.

It is just stable. The IFO is ready for the arm scanning.

=== ASC setting ===

PRCL_PITCH: FM1/3/9 x-0.004
PRCL_YAW: FM1/3/9 x-0.001

The PRM OPLEV has to be off when the PRM ASC is engaged. Actually, it turned out that we don't need OPLEV for locking.

  9757   Fri Mar 28 16:26:20 2014 steveUpdateVACRGA scan after power failure

Quote:

 Out gassing plus leak rate   0.15  mTorr / hour

 The pressure rose to 2.5 mTorr in 17 hours

 V1 was opened at 1:56pm

 VM2 opened at 2:10 so the RGA region is back to 1e-5 torr

 

 

  9756   Thu Mar 27 10:34:39 2014 ericqUpdateGeneralRecovery

Quote:

1. Check: ASS for X arm seems not quite doing its job. ETMX has to be moved using sliders to obtain maximum TRX and the arm alignment was seen to be drifting.

ETMX ASC output was turned off for whatever reason. Switched it on, ASS is fine.

  9755   Wed Mar 26 22:22:43 2014 ManasaUpdateGeneralRecovery

The following that went unnoticed from yesterday were recovered today:

1. ETMX and ETMY 'misalign' scripts weren't running. Troubleshooting showed slow machines c1auxex and c1auxey weren't responding. The machines were reset.

2. PRM oplev gains were zero. Gain values were set looking back at the burt files.

3. X end PZT power supplies were turned ON and set to 100V.

4. X end doubler temperature was reset to the last optimal value on elog (36.35 deg).

 

Some hitches that should be looked into:

1. Check: ASS for X arm seems not quite doing its job. ETMX has to be moved using sliders to obtain maximum TRX and the arm alignment was seen to be drifting.

2. Check: Status of other slow machines and burt restore whichever needs one.

  9754   Wed Mar 26 21:51:42 2014 ericqSummaryLSCPRMIsb locked with REFL165I&Q again

Incidentally, while messing around with transfer functions and sensing matrix elements this evening, I was able to sideband lock straight onto REFL33 I&Q.  The settings were all identical to Koji's ELOG, with the following differences:

Input ports:
REFL33   WHTN: 30dB demod phase +125.5deg (tweaked from 135.5 to minimize MICH in I)

Input matrix:

REFL33I x +1.0 -> PRCL
REFL33Q x +3.0 -> MICH

Servo:
MICH OFS 0 / Gain 1/ Limitter ON (Oscillations occurred at 1.3)
PRCL OFS 0 / Gain -0.04 / Limitter ON

Output matrix:

MICH ITMX -1.0 / ITMY 1.0
PRCL PRM 1.0

 

  9753   Wed Mar 26 14:54:32 2014 KojiSummaryLSCPRMIsb locked with REFL165I&Q again

[Manasa, Eric, Koji]

PRMIsb was locked with REFL165I&Q.


- Aligned the arms with ASS. The misaligned ETMX and ETMY

- Configured PRMIsb with IFO_Configure screen

- Immediately PRMIsb was locked with REFL55I&Q

- Checked the REFL165 phase in terms of the REFL165Q vs PRCL. It was already well adjusted at -82.5deg. We tuned the phase a bit more and got -83.5deg.

- With DTT, relative gain between REFL55I and REFL165I was measured. REFL165I is about x10 higher than REFL55I and has the same sign.

- The transition of PRCL with the input matrix was just easy.

- With DTT, relative gain between REFL55Q and REFL165Q was measured. REFL165Q is about x3 higher than REFL55Q and has the same sign.

- The transition of MICH was flakey, but after careful adjustment of the PRM alignment, ~10s lock was achieved. It seemed that the PRM alignment fluctuation
  was bug enough to unlock the interferometer.

- Eric went into the lab and aligned all of the oplevs except for the SRM's one.

- Now the lock with REFL55 and also with REFL165 became more robust. Less MICH offset and darker AS port.


Input ports:
REFL55   WHTN: 45dB demod phase +45.0deg
REFL165 WHTN: 45dB demod phase -83.5deg

Input matrix: for acquisition:
REFL55I x 1.0 -> PRCL
REFL55Q x 1.0 -> MICH

Input matrix: PRCL Transition:
REFL55I x 1.0 + REFL165I x 0.0 -> x0.5 + x0.0 -> x0.5 + x0.05 -> x0.3 + x0.05 -> x0.2 + x0.05 -> x0.1 + x0.05 -> x0.0 + x0.05

Input matrix: MICH Transition:
REFL55Q x 1.0 + REFL165Q x 0.0 -> x0.5 + x0.0 -> x0.5 + x0.3 -> x0.3 + x0.3 -> x0.2 + x0.3 -> x0.1 + x0.3 -> x0.0 + x0.3

Triggers:
MICH POP110I 100up/10down / FM Trig FM2/3/9 35up 2down 5sec delay
PRCL POP110I 100up/10down / FM Trig FM2/3/6/9 35up 2down 0.5sec delay

Servo:
MICH OFS 0 / Gain 1.3 / Limitter ON
PRCL OFS 0 / Gain -0.04 / Limitter ON

Output matrix:
MICH PRM -0.2625 / BS 0.5
PRCL PRM 1.0

  9752   Wed Mar 26 11:30:07 2014 KojiUpdateGeneralPower Failure

Recovery work: now arms are locking as usual

- FB is failing very frequently. Everytime I see red signals in the CDS summary, I have to run "sudo ntpdate -b -s -u pool.ntp.org"

- PMC was aligned

- The main Marconi returned to initial state. Changed the frequency and amplitude to the nominal value labeled on the unit

- The SHG oven temp controllers were disabled. I visited all three units and pushed "enable" buttons.

- Y arm was immediately locked. It was aligned using ASS.

- X arm did not show any flash. I found that the scx model was not successfully burtrestored yesterday.
  The setting was restored using Mar 22 snapshot.

- After a little tweak of the ETMX alignment, a decent flash was achieved. But still it could not be locked.

- Run s/LSC/LSCoffset.py. This immediately made the X arm locked.

- Checked the green alignment. The X arm green is beating with the PSL at  ~100MHz but is misaligned beyond the PZT range.
  The Y arm green is locked on TEM00 and is beating with the PSL at ~100MHz.

  9751   Wed Mar 26 11:16:59 2014 ericqSummaryLSCComposite Error Signal for ARms (3)

Extending the previous model, I've closed a rudimentary CESAR loop in simulink. Error signals with varying noise levels are combined to bring a "cavity" to lock.  

simlink.pdf

There are many things that are flat out arbitrary at this point, but it qualitatively works. The main components of this model are:

  • The "Plant": A pendulum with f0 = 2Hz, Q = 10
  • Some white force noise, low passed at 1Hz before input to the plant.
  • The Controller: A very rough servo design that is stable...
  • ALS signal: Infinite range Linear signal, with a bunch of noise
  • Transmission and PDH signals are computed with some compiled C code containing analytic functions (which can be a total pain to get working), have less noise than ALS
  • Some logic for computing linearized PDH and SqrtInv signals
  • A C code block for doing the CESAR mixing, and feeding to the servo

And it can lock! 

simulatedCESARLock.pdf

 

Right now, all of the functions and noise levels are similar to the previous simulation, and therefore don't tell us anything about anything real...

However, at this point, I can tune the parameters and noise levels to make it more like our interferometer, and thus maybe actually useful. 

  9750   Tue Mar 25 16:11:24 2014 KojiUpdateGeneralPower Failure

As far as I know the system is running as usual. I had the IMC locked and one of the arm flashing.
But the other arm had no flash and none of the arms were locked before kunch time.



This morning Steve and I went around the lab to turn on the realtime machines.

Also we took the advantage of this opportunity to shutdown linux1 and nodus
to replace the extension cables for their AC power.

I also installed a 3TB hard disk on linux1. This was to provide a local daily copy of our
working are. But I could not make the disk recognized by the OS.
It seems that there is a "2TB" barrier that the disk bigger than 2.2TB can't be recognized
by the older machines. I'll wait for the upgrade of the machine.

Rebooting the realtime machines did not help FB to talk with them. I fixed them.
Basically what I did was:

- Stop all of the realtime codes by running rtcds kill all on c1lsc, c1ioo, c1sus, c1iscex, c1iscey

- run sudo ntpdate -b -s -u pool.ntp.org on c1lsc, c1ioo, c1sus, c1iscex, c1iscey, and fb

- restart realtime codes one by one. I checked which code makes FB unhappy. But in reality
  FB was happy with all of them running.

Then slow machines except for c1vac1 and c1vac2 were burtrestored.

-------

Zach reported that svn was down. I went to the 40m wiki and searched "apache".
There is an instruction how to restart apache.

  9749   Tue Mar 25 14:52:57 2014 steveUpdateVACvacuum is recovered

 Out gassing plus leak rate   0.15  mTorr / hour

 The pressure rose to 2.5 mTorr in 17 hours

 V1 was opened at 1:56pm

 VM2 opened at 2:10 so the RGA region is back to 1e-5 torr

 

  9748   Mon Mar 24 22:13:37 2014 steveUpdateGeneralPower Failure

Quote:

I'm checking the status from home.

P1 is 8e-4 torr

nodus did not feel the power outage (is it APS supported?)

linux1 booted automatically

c1ioo booted automatically.

c1sus, c1lsc, c1iscex, c1iscey need manual power button push.

 9:11pm closed PSL shutter, turned Innolight 2W laser on,

         turned 3 IFO air cond on,

        CC1 5.1e-5 torr, V1 is closed, Maglev has failed, valve configuration is " Vacuum Normal "  with V1 & VM1 closed, RGA not running,   c1vac1 and c1vac2   were saved by UPS,

        (Maglev is not connected to the UPS because it is running on 220V)

        reset & started Maglev.........I can not open V1 without the 40mars running...........

        Rossa is the only computer running in the control room,

        Nodus and Linux1 was saved by UPS,

        turned on IR lasers at the ends, green shutters are closed

It is safe to leave the lab as is.

     

  9747   Mon Mar 24 21:36:28 2014 KojiUpdateGeneralPower Failure

I'm checking the status from home.

P1 is 8e-4 torr

nodus did not feel the power outage (is it APS supported?)

linux1 booted automatically

c1ioo booted automatically.

c1sus, c1lsc, c1iscex, c1iscey need manual power button push.

  9746   Mon Mar 24 19:42:12 2014 CharlesFrogsVACPower Failure

 The 40m experienced a building-wide power failure for ~30 seconds at ~7:38 pm today.

Thought that might be important...

  9745   Mon Mar 24 10:41:46 2014 SteveUpdateVACRGA scan at day 50

 

 

  9744   Sun Mar 23 14:20:07 2014 ranaHowToLSCBLRMS screens

 We should make screens like this for the LSC signals, errors, ALS, etc.

ELOG V3.1.3-