40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 96 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  3610   Mon Sep 27 00:33:50 2010 ranaUpdatePSLHigh Voltage Driver added to TTFSS -> NPRO

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

  3640   Fri Oct 1 21:34:14 2010 rana, taraUpdatePSLHigh Voltage Driver added to TTFSS -> NPRO

Quote:

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

 

 We measured the Thorlabs HV Driver's TF today. It is quite flat from 1k to 10k before going up to 25 dB at 100k,

and the response does not change with the DC offset input.

 

The driver is used for driving the NPRO's PZT which requires higher voltage than that of the previous setup.

We need to understand how the driver might effect the FSS loop TF, and we want to make sure that the driver

will have the same response with DC input offset.

 

Setup

 

We used SR785 to measure the TF. Source ch was split by a T, one connected to Driver's input, another one connected to the reference (ch A). See fig2.

The driver output was split by another T. One output was connected to NPRO,

another was connected to a 1nF capacitor in a Pomona box, as a high pass filer (for high voltage), then to the response (ch B)

 The source input is  DC offset by 2V which corresponds to 38 V DC offset on the driver's output.

The capacitance of the PZT on the NPRO is 2.36 nF, as measured by LC meter.

 

 The result shows that the driver's TF is flat from 1k to 10k, and goes up at higher frequency, see fig1.

 

The next step is trying to roll of the gain at high frequency for PZT. A capacitor connected to ground might be used to roll off the frequency of the driver's output.

We will inspect the TF at higher frequency (above 100 kHz) as well.

            

Attachment 1: NPROTF.png
NPROTF.png
Attachment 2: 2010_10_01.png
2010_10_01.png
  3641   Mon Oct 4 06:47:46 2010 rana, taraUpdatePSLHigh Voltage Driver added to TTFSS -> NPRO

Inside the FSS box, the FAST path has a ~10 Hz pole made up from the 15k resistor and the 1 uF cap before the output connector.

This should be moved over to the output of the driver to make the driver happy - without yet measuring the high frequency response,

it looks like to me that its becoming unhappy with the purely capacitive load of the NPRO's PZT. This will require a little surgery inside

the FSS box, but its probably justified now that we know the Thorlabs box isn't completely horrible.

 

  15906   Thu Mar 11 20:18:00 2021 gautamUpdateLSCHigh bandwidth POY

I repeated the high bandwidth POY locking experiment.

  1. The "Q" demod output (SMA) was routed to the common mode board (it appears in the past I used the LEMO "MON" output instead but that shouldn't be a meaningful change).
  2. As usual, slow actuation --> ETMY, fast actuation --> IMC error point.
  3. Loop UGF measurement suggests that bandwidth ~25kHz, with ~25 degrees phase margin. Anyway the lock was pretty stable.

One thing I am not sure is - when looking at the in-loop error point spectra, the Y-arm error point did not get suppressed to the CM board's sensing noise floor - I would have thought that with the huge amount of gain at ~16 Hz, the usual structure we see in the spectra between 10-30Hz would be completely squished. Need to think about if this is signalling something wrong, because the loop TF measurements seemed as expected to me.

1020pm: plots uploaded. As I made the plot of the spectrum, I realized that I don't have the calibration for the Y-arm error point into displacement noise units, so it's in unphysical units for now. But I think the comment about the hump around 16 Hz not being crushed to some sort of flat electronics noise floor. For the TF plots, when the loop gain is high, this IN1/IN2 technique isn't the best (due to saturation issues) but I don't think there's anything controversial about getting the UGF this way, and the fact that the phase evolves as expected when the various gains are cranked up / boosts enabled makes me think that the CM board is itself just fine.


10am 12 March: i realized that the "Y-arm error point" plotted below is not the true error point - that would be the input to the CM board (before boosts etc), which we don't monitor digitally. The spectra are plotted for the CM_SLOW input which already has some transfer function applied to it. In the past, I routed the LEMO "MON" connector on the demod board to the CM board input, and hence, had the usual SMA outputs from the demod board going to the digital system. I hypothesize that plotting the spectra for that signal would have showed this expected suppression to the electronics noise floor.

In summary, on the basis of this test, I don't see any red flags with the CM board.

Attachment 1: OLGevolution.pdf
OLGevolution.pdf
Attachment 2: inLoopSpec.pdf
inLoopSpec.pdf
  7829   Fri Dec 14 03:32:51 2012 AyakaUpdateLSCHigh frequency noise in AS signal

I calibrated the AS error signal into the displacement of the YARM cavity in the same way as I did before (elog).

The open loop transfer function is:

XARM_OL.pdf


The transfer function from ITMX excitation to AS error signal is:

AS_ITMXexc.pdf

Then I have got the calibration value : 5.08e+11 [counts/m]

The calibrated spectrum in unit of m/rtHz is

ASspe_noise.pdf

REF0: arm displacement
REF1: dark noise + demodulation circuit noise + WT filter noise + ADC noise (PSL shutter on)
REF2: demodulation circuit noise + WT filter noise + ADC noise (PD input of the circuit (at 1Y2) is connected to the 50 Ohm terminator)
(The circuit and WT filter seem to be connected at back side of the rack. Actually there is a connector labelled 'I MON' but it is not related to C1:LSC-ASS55_I_ERR)

Also we changed the AS gain so that ADC noise does not affect:

ASgain.png

However, this did not make big change in sensitivity. I guess this means that circuit noise limits the sensitivity at higher frequencies than 400 Hz.
I tried to adjust the AS gain carefully but I could not do that because of the earthquake. Further investigation is needed.

 

Attachment 5: ASspe.tar.gz
  7832   Fri Dec 14 09:31:59 2012 ranaUpdateLSCHigh frequency noise in AS signal

This is NOT calibrated. Its sort of calibrated in the 500-1000 Hz area, but does not correctly use the loop TF or the cavity pole.

As for the noise, remember that the whole point of changing the AS whitening gain was to turn on the whitening filter AFTER locking. With the WF OFF, there's no way that you can surpass the ADC noise limit.

Quote:

I calibrated the AS error signal into the displacement of the YARM cavity in the same way as I did before (elog).

  7833   Fri Dec 14 10:09:30 2012 AyakaUpdateLSCHigh frequency noise in AS signal

Quote:

This is NOT calibrated. Its sort of calibrated in the 500-1000 Hz area, but does not correctly use the loop TF or the cavity pole.

As for the noise, remember that the whole point of changing the AS whitening gain was to turn on the whitening filter AFTER locking. With the WF OFF, there's no way that you can surpass the ADC noise limit.

Quote:

I calibrated the AS error signal into the displacement of the YARM cavity in the same way as I did before (elog).

No, I did not apply open loop TF to it (actually I could not measure the open loop TF because of the earthquake last night). So I should not have said it was the displacement.

Also I changed the AS gain with whitening filter on and xarm locked. Still it does not make any change.

  7835   Fri Dec 14 16:35:38 2012 AyakaUpdateLSCHigh frequency sensitivity improved

Since I found that the the AS sensitivity seems to be limited by circuit noise, I inserted a RF amplifier just after the AS RF output.
Now, the sensitivity is improved and limited by the dark noise of the PD.

ASspe_noise_amp.pdf

(Note: I did not apply the open loop TF on this xml file.)
REF3: dark noise + circuit noise + WT filter noise + ADC noise
REF4: circuit noise + WT filter noise + ADC

With this situation, I injected the acoustic noise:

ASspe_acoustic_amp.pdf

REF5, 6, 7: with acoustic excitation
no reference: without acoustic excitation

We could see the coherence only at the same frequencies, around 200 Hz as we saw before (elog).

Attachment 3: ASnoise.tar.gz
  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
IMG_1309.JPG
  9720   Tue Mar 11 19:07:24 2014 ericqUpdateElectronicsHigh gain Trans PD electronics change

Speaking of the whitening board, I had neglected to post details showing the the whitening was at least having a positive effect on the transmon QPD noise. So, here is a spectrum showing the effects that the whitening stages have on a QPD dark noise measurement like I did in ELOG 9660, at a simulated transmission level of 40 counts. 

The first whitening stages gives us a full 20dB of noise reduction, while the second stage brings us down to either the dark noise of the QPD or the noise of the whitening board. We should figure out which it is, and fix up the board if necessary. 

SQRTINVwhitening.pdf

The DTT xml file is attached in a zip, if anyone wants it.

Attachment 2: sqrtinvWhitening.zip
  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.

  9585   Wed Jan 29 16:36:37 2014 KojiSummaryGeneralHigh power beam blasting of the aLIGO RFPD

[Rich, Jay, Koji]

We blasted the aLIGO RF PD with a 1W IR beam. We did not find any obvious damage.
Rich and Jay brought the PD back to Downs to find any deterioration of the performance with careful tests.

The power modulation setup is at the rejection side of the PBS in front of the laser source.
I checked the beams are nicely damped.
As they may come back here tomorrow, a power supply and a scope is still at the MC side of the PSL enclosure.

  16023   Tue Apr 13 19:24:45 2021 gautamUpdatePSLHigh power operations

We (rana, yehonathan and i) briefly talked about having high power going into the IFO. I worked on some calcs a couple of years ago, that are summarized here. There is some discussion in the linked page about how much power we even need. In summary, if we can have

  • T_PMC ~85% which is what I measured it to be back in 2019
  • T_IMC * T_inputFaraday ~60% which is what I estimate it to be now
  • 98% mode matching into the IMC
  • power recycling gain of 40-45 once we improve the folding mirror situation in the recycling cavities
  • and a gain of 270-280 in the arm cavities (20-30ppm round trip loss)

then we can have an overall gain of ~2400 from laser to each arm cavity (since the BS divides the power equally between the two arms). The easiest place to get some improvement is to improve T_IMC * T_inputFaraday. If we can get that up to ~90%, then we can have an overall gain of ~4000, which is I think the limit of what is possible with what we have.

We also talked about the EOM. At the same time, I had also looked into the damage threshold as well as clipping losses associated with the finite aperture of our EOM, which is a NewFocus 4064 (KTP is the Pockel medium). The results are summarized in Attachments #1 and #2 respectively. Rana thinks the EOM can handle factor of ~3 greater power than the rated damage threshold of 20W/mm^2.

Attachment 1: intensityDist.pdf
intensityDist.pdf
Attachment 2: clippingLoss.pdf
clippingLoss.pdf
  3300   Tue Jul 27 16:33:50 2010 KojiSummaryGeneralHigh school students tour

Jenne made the 40m tour for the annual visit of 30-40 students.

c.f.

Tour 2009 http://nodus.ligo.caltech.edu:8080/40m/1717

Tour 2008 http://nodus.ligo.caltech.edu:8080/40m/737

 

Attachment 1: IMG_2657.jpg
IMG_2657.jpg
  1097   Tue Oct 28 11:10:18 2008 AlbertoUpdateLSCHigher Order Mode resonances in the X arms

Quote:
Recently we had been having some trouble locking the full IFO in the spring configuration (SRC on +166).
It was thought that an accidental higher order mode resonance in the arms may have been causing problems.

I previously calculated the locations of the resonances using rough arm cavity parameters(Elog #690). Thanks to Koji
and Alberto I have been able to update this work with measured arm length and g factors for the y arm (Elog #801,#802).
I have also included the splitting of the modes caused by the astigmatic ETM. Code is attached.

I don't see any evidence of +166MHz resonances in the y arm.


In the attached plot different colours denote different frequencies +33, -33, +166, -166 & CR.
The numbers above each line are the mn of TEMmn.
Solid black line is the carrier resonance.


I plugged the measures of the length of the X arm and radius of curvature of ETMX I made in to John's code to estimate the position of the resonances of the HOM for the sidebands in the X arm. Here's the resulting plot.
Attachment 1: HOM_resonances_Xarm.png
HOM_resonances_Xarm.png
  10494   Thu Sep 11 02:08:32 2014 JenneUpdateLSCHigher transmission powers

No breakthroughs tonight. 

DRMI didn't want to lock with either the recipe that we used a year ago (elog 9116) or that was used in May (elog 9968).  Being lazy and sleepy, I chickened out and went back to PRFPMI locking. 

Many attempts, I'll highlight 2 here.

(1) I had done the CARM -> sqrtInvTrans transition, and reduced the CARM offset to arm powers of about 7, and lost lock.  I don't remember now if I was trying to transition DARM to AS55, or if I was just prepping (measuring error signal ratio and relative sign).

Zoom_TRXTRYat7_CARMsqrtInvTrans_DARMalsdiff.png

(2) I stopped the carm_cm_up script just before it wanted to do the CARM -> sqrtInvTrans transition, and stayed with CARM and DARM both on ALS.  I got to reasonably high powers, and was measuring the error signal ratios I needed for CARM -> REFL DC and DARM -> AS55.  Things were too noisy to get good coherence for the DARM coefficient, but I thought I was in good shape to transition CARM to REFL DC (which looks like REFL11I, since REFLDC goes to the CM board, and the OUT2 of that board is used to monitor the input to the board. )  Anyhow, I set the offset such that it matched my current CARM offset value, and started the transition, but lost lock about halfway through.  CARM started ringing up here, and I think that's what caused this lockloss.  Could have been the CARM peak, which I wasn't considering / remembering at the time.

ALSonly_TryingTransitionStraightToREFLDC.png

Daytime activity for Thurs:  Lock DRMI, maybe first on 1f signals, but then also on 3f signals.

  768   Wed Jul 30 13:14:03 2008 KojiSummaryIOOHistory of the MC abs length
I was notified by Rob and Rana that there were many measurements of the MC abs length (i.e. modulation 
frequencies for the IFO.) between 2002 and now.

So, I dig the new and old e-logs and collected the measured values of the MC length, as shown below. 

I checked the presence of the vent for two big steps in the MC length. Each actually has a vent. 
The elog said that the tilt of the table was changed at the OMC installation in 2006 Oct.
It is told that the MC mirrors were moved a lot during the vent in 2007 Nov.

Note:
o The current modulation freq setting is the highest ever.
o Rob commented that the Marconi may drift in a long time.
o Apparently we need another measurement as we had the big earthquake.

My curiosity is now satified so far.

Local Time	3xFSR[MHz]	5xFSR[MHz]	MC round trip[m]	Measured by
----------------------------------------------------------------------------
2002/09/12	33.195400 	165.977000 	27.09343		Osamu
2002/10/16	33.194871 	165.974355 	27.09387		Osamu
2003/10/10	33.194929 	165.974645 	27.09382		Osamu
2004/12/14	33.194609 	165.973045 	27.09408		Osamu
2005/02/11	33.195123 	165.975615 	27.09366		Osamu
2005/02/14	33.195152 	165.975760 	27.09364		Osamu
2006/08/08	33.194700 	165.973500 	27.09401		Sam
2006/09/07	33.194490 	165.972450 	27.09418		Sam/Rana
2006/09/08	33.194550 	165.972750 	27.09413		Sam/Rana
----2006/10 VENT OMC installation	
2006/10/26	33.192985 	165.964925 	27.09541		Kirk/Sam
2006/10/27	33.192955 	165.964775 	27.09543		Kirk/Sam
2007/01/17	33.192833 	165.964165 	27.09553		Tobin/Kirk
2007/08/29	33.192120 	165.960600 	27.09611		Keita/Andrey/Rana
----2007/11 VENT Cleaning of the MC mirrors
2007/11/06	33.195439 	165.977195 	27.09340		Rob/Tobin
2008/07/29	33.196629 	165.983145 	27.09243		Rob/Yoichi
Attachment 1: MC_length.png
MC_length.png
  770   Wed Jul 30 15:12:08 2008 ranaSummaryIOOHistory of the MC abs length
> I was notified by Rob and Rana that there were many measurements of the MC abs length (i.e. modulation
> frequencies for the IFO.) between 2002 and now.

I will just add that I think that the Marconi/IFR has always been off by ~150-200 Hz
in that the frequency measured by the GPS locked frequency counter is different from
what's reported by the Marconi's front panel. We should, in the future, clearly indicate
which display is being used.
  10491   Wed Sep 10 21:05:43 2014 JenneUpdateLSCHoly sensitivity, Batman!

Koji and Manasa did some work on the PSL green situation today (Koji is still writing that log post up), but I just measured the Yarm out of loop sensitivity, and WOAH. 

The beat is -11.5dBm at 42.8 MHz.  Koji said the sweet spot is around 30 MHz.  The out of loop sensitivity is 400 Hz RMS!  Something to note is that the Y beatnote still has a 20dB amplifier before going to the beatbox, but the X does not.  We had been worried about saturation issues with the X, so we took out the amplifier.  However, I might put it back if we win big like this.

Recall from elog 10462 that I had saved a reference of the out of loop noise for both X and Y, but Y was much noisier than X.  The references below are from that elog, and the new Y is in dark blue. (Edit, 9:18pm, updated plot measuring down to 0.01Hz.  This is the new reference on the ALS_outOfLoop_Ref.xml template).

 ALS_Y_outOfLoop_10Sept2014.pdf

EDIT:  (Don't worry, I'm going to measure X too, but right now the beam overlap on the camera is not good, as if something drifted after Koji and Manasa closed up the PSL table)

Touched up the alignment for X on the PSL table.  Current beatnotes are:  [Y, -13.5 dBm, 74.1 MHz], [X, -22 dBm, 13.9 MHz].  Red is the current X out of loop, and I've saved it as the new X reference on the template.

ALS_XY_outOfLoop_10Sept2014.pdf

  10497   Fri Sep 12 00:28:04 2014 ericqUpdateLSCHoly sensitivity, Batman!

I took a quick measurement of the ALS stability, using POX and POY as out of loop sensors, using a CARM calibration line to line POX and POY up to the calibrated PHASE_OUT channels at 503Hz. 

  • X arm RMS ~1kHz
    • Could use more low frequency suppression
  • Y arm RMS ~200Hz

ALSoutOfLoop.pdf

  14573   Thu Apr 25 10:25:19 2019 gautamUpdateFrequency noise measurementHomodyne v Heterodyne

If I understand correctly, the Mach-Zehnder readout port power is only a function of the differential phase accumulated between the two interfering light beams. In the homodyne setup, this phase difference can come about because of either fiber length change OR laser frequency change. We cannot directly separate the two effects. Can you help me understand what advantage, if any, the heterodyne setup offers in this regard? Or is the point of going to heterodyne mainly for the feedback control, as there is presumably some easy way to combine the I and Q outputs of the heterodyne measurement to always produce an error signal that is a linear function of the differential phase, as opposed to the sin^2 in the free-running homodyne setup? What is the scheme for doing this operation in a high bandwidth way (i.e. what is supposed to happen to the demodulated outputs in Attachment #3 of your elog)? What is the advantage of the heterodyne scheme over applying temperature feedback to the NPRO with 0.5 Hz tracking bandwidth so that we always stay in the linear regime of the homodyne readout?

Also, what is the functional form of the curve labelled "Theory" in Attachment #2? How did you convert from voltage units in Attachment #1 to frequency units in Attachment #2? Does it make sense that you're apparently measuring laser frequency noise above 10 Hz? i.e. where do the "Dark Current Noise" and "Shot Noise" traces for the experiment lie relative to the blue curve in Attachment #2? Can you point to where the data is stored, and also add a photo of the setup?

  14576   Thu Apr 25 15:47:54 2019 AnjaliUpdateFrequency noise measurementHomodyne v Heterodyne

My understanding is that the main advantage in going to the heterodyne scheme is that we can extract the frequecy noise information without worrying about locking to the linear region of MZI. Arctan of the ratio of the inphase and quadrature component will give us phase as a function of time, with a frequency offset. We need to to correct for this frequency offset. Then the frequency noise can be deduced. But still the frequency noise value extracted would have the contribution from both the frequency noise of the laser as well as from fiber length fluctuation. I have not understood the method of giving temperature feedback to the NPRO.I would like to discuss the same.

The functional form used for the curve labeled as theory is 5x104/f. The power spectral density (V2/Hz) of the the data in attachment #1 is found using the pwelch function in Matlab and square root of the same gives y axis in V/rtHz. From the experimental data, we get the value of Vmax and Vmin. To ride from Vmax to Vmin , the corrsponding phase change is pi. From this information, V/rad can be calculated. This value is then multiplied with 2*pi*time dealy to get the quantity in V/Hz. Dividing V/rtHz value with V/Hz value gives  y axis in Hz/rtHz. The calculated value of shot noise and dark current noise are way below (of the order of 10-4 Hz/rtHz) in this frequency range. 

I forgor to take the picture of the setup at that time. Now Andrew has taken the fiber beam splitter back for his experiment. Attachment #1 shows the current view of the setup. The data from the previous trial is saved in /users/anjali/MZ/MZdata_20190417.hdf5

 

Quote:

If I understand correctly, the Mach-Zehnder readout port power is only a function of the differential phase accumulated between the two interfering light beams. In the homodyne setup, this phase difference can come about because of either fiber length change OR laser frequency change. We cannot directly separate the two effects. Can you help me understand what advantage, if any, the heterodyne setup offers in this regard? Or is the point of going to heterodyne mainly for the feedback control, as there is presumably some easy way to combine the I and Q outputs of the heterodyne measurement to always produce an error signal that is a linear function of the differential phase, as opposed to the sin^2 in the free-running homodyne setup? What is the scheme for doing this operation in a high bandwidth way (i.e. what is supposed to happen to the demodulated outputs in Attachment #3 of your elog)? What is the advantage of the heterodyne scheme over applying temperature feedback to the NPRO with 0.5 Hz tracking bandwidth so that we always stay in the linear regime of the homodyne readout?

Also, what is the functional form of the curve labelled "Theory" in Attachment #2? How did you convert from voltage units in Attachment #1 to frequency units in Attachment #2? Does it make sense that you're apparently measuring laser frequency noise above 10 Hz? i.e. where do the "Dark Current Noise" and "Shot Noise" traces for the experiment lie relative to the blue curve in Attachment #2? Can you point to where the data is stored, and also add a photo of the setup?

 

Attachment 1: Experimental_setup.JPG
Experimental_setup.JPG
  2952   Wed May 19 16:00:18 2010 JenneUpdateIOOHooray! We locked the MC! (and some other stuff)

[Jenne, Kevin]

We opened up the MC chambers again, and successfully got the MC locked today!  Hooray!  This meant that we could start doing other stuff....

First, we clamped the Faraday.  I used the dog clamps that Zach left wrapped in foil on the clean cart.  I checked with a card, and we were still getting the 00 mode through, and I couldn't see any clipping.  2 thumbs up to that.

Then we removed the weight that was on the OMC table, in the way of where MMT2 needs to go.  We checked the alignment of the MC, and it still locks on TEM00, but the spot looks pretty high on MC2 (looking at the TV view). We're going to have to relevel the table when we've got the MMT2 optic in the correct place.

We were going to start moving the PZT steering mirror from the BS table to the IOO table, place MMT2 on the OMC table, and put in a flat mirror on the BS table to get the beam out to the BS oplev table, but Steve kicked us out of the chambers because the particle count got crazy high.  It was ~25,000 which is way too high to be working in the chambers (according to Steve).  So we closed up for the day, and we'll carry on tomorrow. 

 

Photos of the weight before we removed it from the OMC table, and a few pictures of the PZT connectors are on Picasa

  2954   Wed May 19 22:28:05 2010 KojiUpdateIOOHooray! We locked the MC! (and some other stuff)

Good! What was the key?

The MC2 spot looks very high, but don't believe the TV image. Believe the result of script/A2L/A2L_MC2. What you are looking at is the comparison of the spot at the front surface and the OSEMs behind the mirror.

Quote:

[Jenne, Kevin]

We opened up the MC chambers again, and successfully got the MC locked today!  Hooray!  This meant that we could start doing other stuff....

First, we clamped the Faraday.  I used the dog clamps that Zach left wrapped in foil on the clean cart.  I checked with a card, and we were still getting the 00 mode through, and I couldn't see any clipping.  2 thumbs up to that.

Then we removed the weight that was on the OMC table, in the way of where MMT2 needs to go.  We checked the alignment of the MC, and it still locks on TEM00, but the spot looks pretty high on MC2 (looking at the TV view). We're going to have to relevel the table when we've got the MMT2 optic in the correct place.

We were going to start moving the PZT steering mirror from the BS table to the IOO table, place MMT2 on the OMC table, and put in a flat mirror on the BS table to get the beam out to the BS oplev table, but Steve kicked us out of the chambers because the particle count got crazy high.  It was ~25,000 which is way too high to be working in the chambers (according to Steve).  So we closed up for the day, and we'll carry on tomorrow.  

Photos of the weight before we removed it from the OMC table, and a few pictures of the PZT connectors are on Picasa

 

  11938   Wed Jan 20 02:53:18 2016 ericqUpdateLSCHopeful signs

[ericq, Gautam]

We gave DRFPMI locking a shot, with the ALS out-of-loop noises as attached. I figured the ALSX noise might be tolerable. 

After the usual alignment pains, we got to DRMI holding while buzzing around resonance. Recall that we have not locked since Koji's repair of the LO levels in the IMC loop, so the proper AO gains are a little up in the air right now. There were hopeful indications of arm powers stabilizing, but we were not able to make it stick yet. This is perhaps consistent with the ALSX noise making things harder, but not neccesarily impossible; we assuredly still want to fix the current situation but perhaps we can still lock.

On a brighter note, I've only noticed one brief EPICS freeze all night. In addition, the wall StripTools seem totally contiuous since ~4pm, whereas I'm used to seeing some blocky shapes particularly in the seismic rainbow. Could this possibly mean that the old WiFi router was somehow involved in all this? 

Attachment 1: 2016-01-20_ALSOOL.pdf
2016-01-20_ALSOOL.pdf
  11941   Thu Jan 21 00:02:11 2016 KojiUpdateLSCHopeful signs

That's a good news. Only quantitative analysis will tell us if it is true or not.

Also we still want to analyze the traffic with the new switch.

Quote:

On a brighter note, I've only noticed one brief EPICS freeze all night. In addition, the wall StripTools seem totally contiuous since ~4pm, whereas I'm used to seeing some blocky shapes particularly in the seismic rainbow. Could this possibly mean that the old WiFi router was somehow involved in all this? 

 

  13647   Wed Feb 21 17:20:32 2018 johannesUpdateVACHornet gauge connected to DAQ.

I wired the six available BNC connectors on the front panel of the new XEND slow DAQ to physical Acromag channels. There were two unused ADC channels and eight DAC channels, of which I connected four. The following entries were added to /cvs/cds/caltech/target/c1auxex2/ETMXAUX2.db /caltech/target/c1auxex2/ETMXaux2.db

Connector Acromag Channel EPICS Name
In1 XT1221C #6 C1:Vac-CC1_HORNET_PRESSURE_VOLT
In2 XT1221C #7 C1:PEM-SEIS_XARM_TEMP_MON C1:PEM-SEIS_EX_TEMP_MON
Out1 XT1541B #4 C1:PEM-SEIS_XARM_TEMP_CTRL C1:PEM-SEIS_EX_TEMP_CTRL
Out2 XT1541B #5 Not Assigned
Out3 XT1541B #6 Not Assigned
Out4 XT1541B #7 Not Assigned

C1:Vac-CC1_HORNET_PRESSURE_VOLT is converted to the additional soft channel C1:Vac-CC1_HORNET_PRESSURE in units of torr using the conversion  10^{(\mathrm{Voltage}-10)} stated in the manual. A quick check showed that the resulting number and the displayed pressure on the vacuum gauge itself agree to ~1e-8 torr. Gautam added the new EPICS calc channel to the C0EDCU and restarted FB, now the data is being recorded.

Three of the output channels do not have a purpose yet, so their epics records were created but remain inactive for the time being.

Attachment 1: VacLog.png
VacLog.png
  4856   Wed Jun 22 17:35:35 2011 IshwitaUpdateGeneralHot air station

This is the new hot air station for the 40m lab.........

 

Attachment 1: P6220212.JPG
P6220212.JPG
Attachment 2: P6220213.JPG
P6220213.JPG
  11634   Tue Sep 22 16:42:39 2015 ericqUpdateIOOHousekeeping

I've moved the OAF MC2 signal path to go directly from c1oaf to c1mcs, so that the LSC being ON/OFF doesn't interfere with the MC length seismic feedforward. Since the FB is currently down, I can't do a full test, but looking at monitor points in StripTool indicates it's working as intended. 

I also cleaned up some LSC medm stuff; exposing the existing SRCL UGF servo, and removing a misleading arrow. This reminds me that I need to get calibration lockins back up and running...

  15829   Sat Feb 20 16:20:33 2021 gautamUpdateGeneralHousekeeping + PRMI char

In prep to try some of these debugging steps, I did the following.

  1. ndscope updated from 0.7.9 to 0.11.3 on rossa. I've been testing/assisting the development for a few months now and am happy with it, and like the new features (e.g. PDF export). v0.7.9 is still available on the system so we can revert whenever we want.
  2. Arms locked on POX/POY, dither aligned to maximize TRX/TRY, normalization reset.
  3. PRMI locked, dither aligned to maximize POPDC.
  4. All vertex oplevs re-centered on their QPDs.

While working, I noticed that the annoying tip-tilt drift seems to be worse than it has been in the last few months. The IPPOS QPD is a good diagnostic to monitor stability of TT1/TT2. While trying to trend the data, I noticed that from ~31 Jan (Saturday night/Sunday morning local time), the IP-POS QPD segment data streams seem "frozen", see Attachment #1. This definitely predates the CDS crash on Feb 2. I confirmed that the beam was in fact incident on the IPPOS QPD, and at 1Y2/1Y3 that I was getting voltages going into the c1iscaux Acromag crate. All manner of soft reboots (eth1 network interface, modbusIOC service) didn't fix the problem, so I power cycled the acromag interface crate. This did the trick. I will take this opportunity to raise again the issue that we do not have a useful, reliable diagnsotic for the state of our Acromag systems. The problem seems to not have been with all the ADC cards inside the crate, as other slow ADC channels were reporting sensible numbers.

Anyways, now that the QPD is working again, you can see the drift in Attachment #2. I ran the dither alignment ~4 hours ago, and in the intervening time, the spot, which was previously centered on the AS camera CRT display, has almost drifted completely off (my rough calibration is that the spot has moved 5mm on the AS CCD camera). I was thinking we could try installing the two HAM-A coil drivers to control the TTs, this would allow us to rule out flaky electronics as the culprit, but I realize some custom cabling would be required, so maybe not worth the effort. The phenomenology of the drift make me suspect the electronics - hard for me to imagine that a mechanical creep would stop creeping after 3-4 hours? How would we explain the start of such a mechanical drift? On the other hand, the fact that the drift is almost solely in pitch lends support to the cause being mechanical. This would really hamper the locking efforts, the drift is on short enough timescales that I'd need to repeatedly go back and run the dither alignment between lock attempts - not the end of the world but costs ~5mins per lock attempt.


On to the actual tests: before testing the hardware, I locked the PRMI (no ETMs). In this configuration, I'm surprised to see that there is nearly perfect coherence between the MICH and PRCL error signals between 100Hz-1kHz 🤔 . When the AS55 demodulated signals are whitened prior to digitization (and then de-whitened digitally), the coherence structure changes. The electronics noise (measured with the PSL shutter closed) itself is uncorrelated (as it should be), and below the level of the two aforementioned spectra, so it is some actual signal I'm measuring there with the PRMI locked, and the coherence is on the light fields on the photodiode. So it would seem that I am just injecting a ton of AS55 sensing noise into the PRCL loop via the MICH->PRM LSC output matrix element. Weird. The light level on the AS55 photodiode has increased by ~2x after the September 2020 vent when we removed all the unused output optics and copper OMC. Nevertheless, the level isn't anywhere close to being high enough to saturate the ADC (confirmed by time domain signals in ndscope).

To get some insight into whether the whole RF system is messed up, I first locked the arm cavities with POX and POY as the error signals. Attachment #3 shows the spectra and coherence betweeen these two DoFs (and the dark noise levels for comparison). This is the kind of coherence profile I would expect - at frequencies where the loop gain isn't so high as to squish the cavity length noise (relative to laser frequency fluctuations), the coherence is high. Below 10 Hz, the coherence is lower than between 10-100 Hz because the OLG is high, and presumably, we are close to the sensing noise level. And above ~100 Hz, POX and POY photodiodes aren't sensing any actual relative frequency fluctuations between the arm length and laser frequency, so it's all just electronics noise, which should be incoherent.

The analogous plot for the PRMI lock is shown in Attachment #4. I guess this is telling me that the MICH sensing noise is getting injected into the PRCL error point between 100Hz-1kHz, where the REFL11 photodiode (=PRCL sensor) isn't dark noise limited, and so there is high coherence? I tuned the MICH-->PRM LSC output matrix element to minimize the height of a single frequency line driving the BS+PRM combo at ~313Hz in the PRCL error point. 

All the spectra are in-loop, the loop gain has not been undone to refer this to free-running noise. The OLGs themselves looked fine to me from the usual DTT swept sine measurements, with ~100 Hz UGF.

Attachment 1: IPPOSdeat.pdf
IPPOSdeat.pdf
Attachment 2: TTdrift.pdf
TTdrift.pdf
Attachment 3: POXnPOY.pdf
POXnPOY.pdf
Attachment 4: PRMI.pdf
PRMI.pdf
  15831   Sun Feb 21 20:51:21 2021 ranaUpdateGeneralHousekeeping + PRMI char

I'm curious to see if the demod phase for MICH in REFL & AS chamges between thi simple Mcihelson and PRMI. IF there's a change, it could point to a PRCL/f2 mismatch.

But I would still bet on demod chain funniness.

  15875   Sun Mar 7 15:26:10 2021 gautamUpdateLSCHousekeeping + more PRMI
  1. Beam pointing into PMC was tweaked to improve transmission.
  2. AS110 photodiode was re-installed on the AS table - I picked off 30% of the light going to the AS WFS using a beamsplitter and put it on the AS110 photodiode.
  3. Adjusted ASDC whitening gain - we have been running nominally with +18dB, but after Sept 2020 vent, there is ~x3 amount of light incident on the AS55 RFPD (from which the ASDC signal is derived). I want to run the dither alignment servos that use this PD using the same settings as before, hence this adjustment.
  4. Adjusted digital demod phases of POP22, POP110 and AS110 signals with the PRMI locked (sideband resonant). I want these to be useful to debug the PRMI. the phases were adjusted so that AS110_Q, POP22_I and POP110_I contain the signal (= sideband buildup) when the PRMI is locked.
  5. Ran the actuator calibration routine for BS, ITMX and ITMY - i'll try and do the PRM and ETMs as well later.
  6. With the PRMI locked (sidebands resonant), looked at the sideband power buildup. POP22 and POP110 remain stable, but there is some low frequency variation in the AS110_Q channel (but not the I channel, so this is really a time varying transmission of the f2 sideband to the dark port). What's that about? Also unsure about those abrupt jumps in the POP22/POP110 signals, see Attachment #1 (admittedly these are slow channels). I don't see any correlation in the MICH control signal.
  7. Measured the loop shapes of the MICH (UGF ~90 degrees, PM~30 degrees) and PRCL (UGF~110 Hz, PM~30 degreees) loops - stability margins and loop UGFs seem reasonable to me.
  8. Tried nulling the MICH-->PRCL coupling by adjusting the MICH-->PRM matrix element - as has been the case for a while, unable to do any better, and I can't null that line as we expect to be able to.
  9. Not expecting to get anything sensible, but ran some sensing matrix lines (at the correct frequencies this time).
  10. Tried locking the PRMI with MICH actuation to an ITM instead of the BS - I can realize the lock but the loop OLTF I measure with this configuration is very weird, needs more investigation. I may look into this later today evening.

I was also reminded today of the poor reliability of the LSC whitening electronics. Basically, there may be hidden saturations in all the channels that have a large DC value (e.g. the photodiode DC mon channels) due to the poor design of the cascaded gain stages. I was thinking about using the REFL DC channel to estimate the mode-matching into the PRC, but this has a couple of problems. Electronically, there may be some signal distortion due to the aforementioned problem. But in addition, optically, the estimation of mode-matching into the PRC by comparing REFL DC levels in single bounce off the PRM and the PRMI locked has the problem that the mode-matching is degenerate with the intra-cavity loss, which is of the same order as the mode mismatch (a percent or two I claiM). If Koji or someone else can implement the fix suggested by Hartmut for all the LSC whitening channels, that'd give us more faith in the signals. It may be less work than just replacing all the whitening filters with a better design (e.g. the aLIGO ISC whitening filter which implements the cascaded gain stages using single OP27s and more importantly has a 1 kohm series resistance with the input to the op amp (so the preceeding stage never has to drive > 10V/1kohms ~10mA of DC current) would presumably reduce distortion.

Attachment 1: PRMI_SBres.png
PRMI_SBres.png
Attachment 2: MICH_act_calib.pdf
MICH_act_calib.pdf
  16994   Tue Jul 12 19:46:54 2022 PacoSummaryALSHow (not) to take NPRO PZT transfer function

[Paco, Deeksha, rana]

Quick elog for this evening:

  • Rana disabled MC servo .
  • Slow loop also got disengaged.
  • AUX PSL beatnote is best taken with *free running lasers* since their relative frequency fluctuations are lowest than when locked to cavities.
  • DFD may be better to get PZT transfer funcs, or get higher bandwidth phase meter.
  • Multi instrument to be done with updated moku
  • Deeksha will take care of updated moku
  4005   Thu Dec 2 00:34:32 2010 ranaHowToLSCHow Does Cavity Locking Work (answered by Nikon)

https://nodus.ligo.caltech.edu:30889/gw.swf

Dr. Koji Arai and Nikon
  3822   Fri Oct 29 11:29:29 2010 josephbUpdateCDSHow I broke the frame builder yesterday

Problem:

Long before Yuta came along and deleted daqd, I had done something to prevent the framebuilder code from running at all.

Cause:

Alex pointed out via e-mail that the corresponded to the inability to access certain frame files due to their permissions being only for root. 

Turns out when I had run the code under the inittab, I forgot to make it use controls, instead of root (which is the default).  This later on caused problems for the code when it tried to access those files, resulting in the wierd errors we saw.

Solution:

Use chown to change the offending frame files back to controls.

Future:

Write a proper inittab script which uses "su controls" before running the daqd code.

  9093   Mon Sep 2 03:51:14 2013 ranaHowToGeneralHow To Coil Cables

 http://youtu.be/pEd7ru24Vx0

  9097   Tue Sep 3 10:54:33 2013 SteveHowToGeneralHow To Coil Cables

Quote:

 http://youtu.be/pEd7ru24Vx0

 B grade Nobel is awarded.

                                  If cables could dream?

This skill should be  mandatory for LIGOX graduates.

  1589   Fri May 15 14:05:14 2009 DmassHowToComputersHow To: Crash the Elog

The Elog started crashing last night. It turns out I was the culprit, and whenever I tried to upload a certain 500kb .png picture, it would die. It has happened both when choosing "upload" of a picture, and when choosing "submit" after successfully uploading a picture. Both culprits were ~500kb .png files.

  7484   Thu Oct 4 22:27:54 2012 KojiUpdateSUSHow about the slow machines?

One terrible concern of mine is that the slow machines were rebooted at the power interruption.
Based on the elog entries, I assume they have not been burtrestored...

If this is true, they may cause some weird behaviors of the PSL/IOO electronics.

 

  7485   Thu Oct 4 22:35:16 2012 DenUpdateSUSHow about the slow machines?

Quote:


Based on the elog entries, I assume they have not been burtrestored...

 Do you know how to burtrestore or restart slow machines?

Edit by Den: I did burtrestore of c1psl.snap from 2 days ago. Still slow machines behave not normal. For example, if I sweep C1:PSL-FSS_SLOWDC, SLOW monitor value does not change.

  7489   Fri Oct 5 04:34:31 2012 ranaUpdateSUSHow about the slow machines?

Quote:

Quote:


Based on the elog entries, I assume they have not been burtrestored...

 Do you know how to burtrestore or restart slow machines?

Edit by Den: I did burtrestore of c1psl.snap from 2 days ago. Still slow machines behave not normal. For example, if I sweep C1:PSL-FSS_SLOWDC, SLOW monitor value does not change.

 Problems with Slow Machines?

Read ELOG

  12639   Wed Nov 23 17:48:16 2016 rana, kojiUpdateIOOHow bad is the McWFS?

Medium.


Previous elog entries on this:

  10391   Thu Aug 14 19:23:25 2014 ranaHowToIOOHow do I set the FSS offset to make the PZT voltage start at the right place?

 When the IMC locks, we want the FAST OUT of the TTFSS box to be close to zero volts. We also want the control signal from the MC Servo board to be close to 0 V. How to set this up?

With the IMC locked, we just servo the FSS input offset to minimize the MC board output :

ezcaservo -r C1:IOO-MC_FAST_MON -g 0.1 -t 10 C1:PSL-FSS_INOFFSET

I would have used "CDSUTILS", but that seems to have some sort of ridiculous bug where we can't have prefixes on channel names, even on the command line. 

  1911   Sat Aug 15 18:35:14 2009 ClaraFrogsComputersHow far back is complete data really saved? (or, is the cake a lie?)

I was told that, as of last weekend, we now have the capability to save full data for a month, whereas before it was something like 3 days. However, my attempts to get the data from the accidentally-shorted EW2 channel in the Guralp box have all been epic failures. My other data is okay, despite my not saving it for several days after it was recorded. So, my question is, how long can the data actually be saved, and when did the saving capability change?

  7765   Fri Nov 30 09:59:53 2012 SteveHowToGeneralHow not to

Clean cabinet S15 doors were left open. You have to lock it up!

  3733   Mon Oct 18 09:01:48 2010 steveHowToGeneralHow not to

This BNC cable is crying for help. Please do not do this to me.  It should be reported  to the  abused center.Throw this cable into the garbage now.

Attachment 1: P1060926.JPG
P1060926.JPG
  11459   Wed Jul 29 14:32:01 2015 SteveUpdateGeneralHow not to solder

 

Quote:

 

Quote:

Koji and Steve,

The result: bad Guralp x-arm cable.

I will swap the short cables tomorrow at the base.

 

Short 46" long cables at the base plates were swapped. Their solderings looked horrible.

This cable actually worked at 5-5-2015

Bad cable at ETMY station now.  The new cable should be a little bit longer ~52"

Koji could pull out easily 11 of the wires  from their socket.

Attachment 1: coldSoldering.jpg
coldSoldering.jpg
  11701   Tue Oct 20 11:24:29 2015 ericqHowToLSCHow to DRFPMI

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 


Initial Alignment

  1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
  2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
  3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
  4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration

CARM, DARM

For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 

ALS

  • BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
  • Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
  • CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
  • DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0

RF

  • CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
  • MC Board: IN2 disabled, -32dB input gain
  • CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
  • CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
  • AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
  • DARM_B = -1e-4 x AS55 Q, G=0

DRMI 3F

For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

  • REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
  • REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
  • POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
  • AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
  • POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
  • MICH_B = 6.0 x REFL165Q, offset = 15.0
  • PRCL_B = 5.0 x REFL33I, offset = 45.0
  • SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

  • CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
  • PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
  • SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

  • MC2 = -1.0 x CARM
  • ETMX = -1.0 x DARM
  • ETMY = 1.0 x DARM
  • BS = 0.5 x MICH
  • PRM = 1.0 x PRCL - 0.2655 MICH
  • SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

  • Turn ON MC length feedforward and PRC angle feedforward
  • Set ALS phase tracker UGFs by looking at I and Q magnitudes
  • Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
  • Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
  • Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
  • When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
    • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
  • Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
  • DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
  • With an 8 second ramp, reduce CARM offset to 0 counts. 
  • MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
    • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

  • CARM and DARM FM1 (18,18:1,1 boosts) OFF
  • CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
  • DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
  • MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
  • Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
  • If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
  • CARM_A_GAIN 1.0 -> 0.7
  • CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
  • DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

  • Turn on transmon QPD servos.
  • Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

  • CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
  • MC2 viollin filters back on
  • CM boost(s) on
  • AS55 whitening on
  • Transition DRMI to 1F
  2403   Sat Dec 12 07:36:56 2009 ranaHowToElectronicsHow to Measure the Length of a Cable: Interferometry

Need to measure the length of the cable, but too lazy to use a measuring tape?

Then you too can become an expert cable length measurer by just using an RF signal generator and a scope:

  1. Disconnect or short (not 50 Ohm term) the far side of the cable.
  2. Put a T on the near side of the cable.
  3. Drive the input of the T with your signal source.
  4. Look at the output of the T with the scope while sweeping the signal source's frequency knob.

The T is kind of acting like a beamsplitter in an asymmetric length Michelson in this case. Just as we can use the RF phase shift between the arms to measure the Schnupp asymmetry, we can also use a T to measure the cable length. The speed of light in the cable is documented in the cable catalog, but in most cases its just 66% of the speed of light in the vacuum.

  2316   Mon Nov 23 19:36:28 2009 JenneUpdateAdaptive FilteringHow to add ASS channels, so that they're saved to frames

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

ELOG V3.1.3-