40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 41 of 344 Not logged in
ID Date Author Type Category Subject
1535   Thu Apr 30 15:10:54 2009 robUpdateLockingCARM RF changed to REFL_2I

 Quote: Yoichi, Peter As Rob suggested, the optimal demodulation phase is easier to find for REFL_2I than POX_1I. Moreover, for 166MHz LO, we have a phase shifter (delay line) already installed. So we can easily change the demodulation phase of REFL_2I. Tonight, we switched the RF CARM signal to REFL_2I. To do so, I changed the signal going to the REFL1 input of the common mode board from POX_1I to REFL_2I. I moved a BNC-T installed at the output of POX_1I to the REFL_2I output to split the REFL_2I signal and send it to the CM board. Since the gain of the REFL_2I was about 20dB lower than that of POX_1I, I increased the gain of the SR560, which is installed between the REFL_2 demodulation board and the CM board, from 1 to 10. With some gain tweaks, we were able to hand off the CARM from REFL_DC to REFL_2I. We also succeeded in switching the REFL_2I ADC channel from PD11 to PD2_DC (the output of the length path from the CM board). This switching is necessary in order to engage the boost on the CM board. There remains some offset in the CARM when the arm power is maximized. This is expected because the REFL_2I demodulation phase is probably not exactly right. I will optimize the demodulation phase tomorrow.

From Optickle simulations, it looks like the SRCL/CARM gain ratio at REFL I2 is about 8e-4. So a 1 nanometer offset in SRCL yields 0.8 picometers of offset in CARM.
10971   Wed Feb 4 04:51:14 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Jenne, Eric]

Tonight we kept on following our current strategy for locking the PRFPMI:

• the first few tries were pretty unsuccessful: the PRMI lock wasn't much stable, and we never managed to reduce CARM offset to zero before losing lock;
• then we did some usual manteinance: we fixed the X arm green beatnote, fixed the phase tracker and given much attention to ASS alignment, since the X arm wasn't doing great;
• the last few locks were consintently better: we managed to get to CARM offset zero "easily", but the arm power was not very high (~8);
• then we tried to transition CARM to REFL11, both with the usual configuration and using CM_SLOW, using REFL11 as input for the Common Mode Board;
• with the usual configuration, we lost lock right after the transition, because of MICH hitting the rail;
• we did a very smooth CARM transition directly to REFL11 on the CM_SLOW path; we managed to take a spectrum with the SR785, but we couldn't take any more measurements before losing lock because of some weird glitch, as we can see from the lockloss plot;
• another thing that helped tonight was changing the ELP of the MICH filter bank: it went from 4th order to 6th order, and from 40 dB suppression to 60 dB suppression;

both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;

EDITs by JCD:  At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.

Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over.  Coherence was taken simultaneously as usual, I just printed it to another sheet.

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS.pdf

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS_Coh.pdf

Here is the lockloss plot for the very last lockloss.  This is the time that we were sitting on REFL11 coming through the CM_SLOW path.  A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots.  This isn't something that I've seen in our lockloss plots before.  I'm not sure if it's coming from REFL11, or the CM board, or something else.  We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.

Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile.

10979   Thu Feb 5 04:35:14 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Eric]

Tonight was a sad night... We continued to pursue our strategy, but with very poor results:

• before doing anything, we made sure we had a good initial configuration: we renormalized the arm powers, retuned the X arm green beatnote, did extensive ASS alignment;
• since the beginning of the night we faced a very uncooperative PRMI, which caused a huge number of locklosses, often just by itself, without even managing to reduce the MICH offset before reducing the CARM one;
• we had to reduce the PRCL gain to -0.002 in order to acquire PRMI lock, but keeping it such or restoring it to -0.004 once lock was acquired either didn't improve the PRMI stability at all;
• we also tweaked a bit the PRCL and MICH UGF servos (namely, their frequencies to ~80 Hz and ~40 Hz respectively) and that seemed to help earlier during the night, but not much longer;
• we only managed to transition CARM to REFL11 via CM SLOW twice;
• the first time we lost lock almost immediately, probably because of a non-optimal offset between CARM A and B;
• the second time we managed to stay there a little longer, but then some spike in the PRCL loop and/or the MICH loop hitting the rails threw us out of lock (see the lockloss plot);
• both times we transitioned at arm power ~18;
• during the night we used an increased analog ASDC whitening gain, as from Eric's elog here http://nodus.ligo.caltech.edu:8080/40m/10972 ; even with this fix, though, MICH is still often hitting the rails and causing the lock losses;
• the conclusion for tonight is that we need to figure what is going on with the PRMI...

10982   Fri Feb 6 03:21:17 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Jenne]

We kept struggling with the PRMI, although it was a little better than yesterday:

• we retuned the X Green beatnote;
• we managed to reach lower CARM offsets than yesterday night, but we still can't keep lock long enough to perform a smooth transition to CM SLOW/REFL11;
• we tweaked MICH a bit:
• the ELP in FM8 now is always on, because it seems to help;
• we tried using a new FM1 1,1:0,0 instead of FM2 1:0 because we felt we needed a little more gain at low frequencies, but unfortunately this didn't change much MICH's behaviour;
• now, after catching PRMI lock, the MICH limiter is raised to 30k (in the script), as a possible solution for the railing problem; the down/relock scripts take care of resetting it to 10k while not locked/locking;

So, still no exciting news, but PRMI lock seems to be improving a little.

10589   Thu Oct 9 16:31:53 2014 ericqUpdateLSCCARM W/N TFs

In my previous simulation results, I've always plotted W/m, which isn't exactly straightforward. We often think about the displacement that a given mirror actuator output will induce, but when we're locking the full IFO, radiation pressure effects modify the mechanical response depending on the current detuning, making the meaning of W/m transfer functions a little fuzzy.

So, I've redone my MIST simulations to report Watts of signal response due to actual actuator newtons, which is what we actually control with the digital system. Note, however, that these Watts are those that would be sensed by a detector directly at the given port, and doesn't take into account the power reduction from in-air beamsplitters, etc.

As an example, here are the SqrtInv and REFLDC CARM TFs for the anti-spring case:

The units of the SqrtInv plot are maybe a little weird, these TFs are the exact shape of the TRX W/N TFs with the DC value adjusted by the ratio of the DC sweep derivatives of TRX and SqrtInv.

All of the results live in /svn/trunk/modeling/PRFPMI_radpressure/

10591   Thu Oct 9 18:30:59 2014 JenneUpdateLSCCARM W/N TFs

Okay, here (finally) is the optickle version.

I have the antispring case, starting at 501pm and going roughly every 10pm down to 1pm.  I also have the spring case, starting at -501pm and going down every 10pm to roughly -113pm.  Rossa crashed partway through the calculation, which is why it's not all the way.

In the .zip is a .mat file called PDs_vs_CARMoffset_WattsPerNewton.mat, which has (a) a list of the 50 CARM offsets, (b) a frequency vector, and (c) several transfer function arrays.  The transfer function arrays are supposed to be intuitively named, eg. REFLDC_antispring.

In the .zip file are also the original .mat files that are a result of the tickle calculations, as well as a .m file for loading them and making the plots, etc.  For anyone who is trying to re-create the transfer function variables, I by-hand saved the variable called PD_WperN to the names like REFLDC_antispring.  Just kidding.  Those original mat files are over 100Mb each, and that's just crazy.  Anyhow, I think the .zip has everything needed to use the data from these plots.

Anyhow.  Here are plots of what are in the various transfer function arrays:

10593   Fri Oct 10 00:20:37 2014 ranaUpdateLSCCARM W/N TFs

Assuming that these Watts/Newtons TFs are correct, I've modeled the resulting open loop gain for CARM. The goal is to design a loop that is stable under a wide range of offsets and also has enough low frequency gain.

The attached PDF shows this. I used a CARM OLG Simulink model:

I've replaced the 'armTF' block with a digital gain of zero. After measuring the open loop gain of all but this piece, I multiply that 'OLG' with the W/N that Jenne extracted from Optickle for CARM->TR (not sqrtInv)

I plot the resulting estimate of the actual OLG in the following plot. Since the CARM-RSE peak is moving down, we use the LP filter that Den installed for us several months ago. To account for the radiation pressure spring, we use some low frequency boosts but not the crazy FM4 filter.

As you can see, the loop is stable from 500 to 200 pm, but then goes unstable around 110 pm. I expect that we will want to do some fancy shaping there or switch from TRX+TRY into something else.

This assumes we have filters 0, 1, 3, 5, and 7 on in the CARM filter bank - still need to add the digital AA/AI to make the loop phase lag a little more accruate, but I think this is looking promising.

10608   Wed Oct 15 02:59:04 2014 ranaUpdateLSCCARM W/N TFs

In my previous elog in this thread, I showed the CARM OLG given some new digital filters and the varying CARM plant (spring side, not anti-spring). Jenne has subsequently produced the TFs for all of the rest of the CARM offsets.

These attached plots for several CARM offsets show that the anti-spring side is much more stable than the spring side and so we should use that. Annecadotedally, we think that positive CARM offsets are more stable when going to arm powers of > 10, so perhaps this means that +CARM = -SPRING.

The first PDF shows the spring OLGs and the 2nd one shows the antispring OLGs. I have put in some gain changes to keep the UGF approximately the same as the offset is changed.

The PDF thumbnails will become visible once Q and Diego install the new nodus.

UPDATE OCt 16: this is all wrong! bad conversion of filters within the invbilinear.m function.

10609   Wed Oct 15 13:38:33 2014 JenneUpdateLSCCARM W/N TFs

Here are the same plots, but the legend also includes the arm power that we expect at that CARM offset.

Here is what the arm powers look like as a function of CARM offset according to Optickle.  Note that the cyan trace's maximum matches what Q has simulated in Mist with the same high losses.  For illustration I've plotted the single arm power, so that you can see it's normalized to 1.  Then, the other traces are the full PRFPMI buildup, with various amounts of arm loss.  The "no loss" case is with 0ppm loss per ETM.  The "150 ppm loss" case is with 150 ppm of loss per ETM.  The "high loss" case is representative of what Q has measured, so I have put 500 ppm loss for ETMX and 150 ppm loss for ETMY.

And, the transfer functions (all these, as with all TFs in the last week, use the "high loss" situation with 500ppm for ETMX and 150ppm for ETMY).

10620   Thu Oct 16 22:35:05 2014 ranaUpdateLSCCARM W/N TFs

In my last CARM loop modelling, all of the plots are phony, so don't trust them. The invbilinear function inside of StefanB's onlinefilter.m was making bogus s-domain representations of the digital filter coefficients.

So now I've just plotted the frequency response directly from the z-domain SOS coeffs using MattE's readFilterFile.m and FotonFilter.m.

Conclusions are less rosy. The anti-spring side is still easier to compensate than the spring side, but it starts to get hopeless below ~130 pm of offset, so there we really need to try to get to REFL_11/(TRX+TRY), pending some noise analysis.

** In order to get the 80 and 40 pm loops to be more stable I've put in a tweak filter called Boost2 (FM8). As you can see, it kind of helps for 80 pm, but its pretty hopeless after that.

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

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

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

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

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

Here are the revised plots:

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

[EricQ, Jenne]

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

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

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

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

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

[EricQ, Jenne]

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

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

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

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

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

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

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

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

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

9798   Fri Apr 11 10:30:48 2014 jamieUpdateLSCCARM and DARM both on IR signals!!!!!!!!!

 Quote: [EricQ, Jenne] We're still working, but I'm really excited, so here's our news:  We are currently holding the IFO on all IR signals.  No green, no ALS is being used at all!!!!

Phenomenal!!  Well done, guys!

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

A few time series from last night's data.

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

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

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

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

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

9800   Fri Apr 11 12:21:27 2014 KojiUpdateLSCCARM and DARM both on IR signals!!!!!!!!!

According to the elogs, DARM = AS55Q/400. So in the current level, the error has +/-40cntpp (even if I ignore the whitening).

The arm transmission this time was 0.1-0.3. This will go up to 100~300. So we potentially increase the AS55Q optical gain by factor of 1000.

So we get +/-40000. This is already too much. If we consider the whitening, the situation is more tough.

We need to lower the whitening gain. If it is not enough, we need to lower the power on the PD.

How much was the whitening gain for AS55 this time?

 Quote:

9801   Fri Apr 11 12:32:33 2014 ericqUpdateLSCCARM and DARM both on IR signals!!!!!!!!!

 Quote: How much was the whitening gain for AS55 this time?

21 dB. We played with the whitening gain a little bit; at around 30dB with the signal levels at TRX = .1ish, we were consistently saturating the ADC.

11136   Thu Mar 12 03:47:56 2015 JenneUpdateLSCCARM and DARM loop adjustments

No wins tonight.

I've tried playing with the shapes of the loops a little bit (mostly CARM so far), to no avail.  I think I made it to CARM RF-only only one time tonight.  I was able to turn on the REFL11 whitening, although I lost lock while about halfway through the DARM transition.

I tried making a double integrator instead of a single integrator for CARM_B, since that would allow me to make a complex zero pair which could help win back some phase. I also tried just straight copying FM1 from CARM into CARM_B, so that it could be turned off for the ALS part of the loop, but left on for the REFL part, but that didn't work very well.  Like Rana and I saw last Friday, we really need the REFL signal to have a true integrator, to force the PDH signal toward zero, before we can complete the transition.

I moved the cavity pole compensator's zero back up to 120 Hz, since that was what had worked on Saturday night.  That helped me get farther before running into gain peaking problems at ~50Hz.  This is because, as seen in my simulation earlier tonight, I win back some gain margin by having the pole compensator more closely matched with the pole frequency.

I've been turning off both FM1 and FM2 in CARM and DARM.  I think this is helping a lot, when I can get far enough to do so.  I don't want to turn off the second boost until after I'm about 50/50 on REFL.  (When  I have that much REFL, with the true integrator, the PDH signal sticks to zero).

I tried once turning off the bounce/roll filters for CARM and DARM, rather than the FM1 boost, since the bounce roll filters eat lots of phase, but I got pushed off resonance.  I think not having that focused boost may have made my overall RMS larger, which caused me to randomly jump too far outside of the good PDH range.

Early on in the evening, I turned off the MC2 violin filters in the ETM LSC-SUS filter banks, since I am actuating on only the ETMs tonight. However, I saw a violin mode ring up at ~642, which showed up in POX but not POY.  This was causing up-conversion, beating against the 40-50Hz buzzing from the IR resonance.   The MC2vio1,2 filter covers this frequency (because it's an absurdly wide notch), but the EXYvio1 filter does not.  There seems to be some confusion on the wiki as to what the ETMX violin mode frequency is - it says 631 (638??).  The notch that is in the EXYvio1 filter is for 631 Hz, but this is not correct.  DAYTIME self: Make the MC2 violin filter smaller than 40Hz(!) wide, and move the ETMX notch up to the correct frequency.  For tonight, I just turned back on the MC2 filter, and the mode has rung down.

Idea:  MICH offset, or ETM misalignment, enough to keep the power recycling low-ish, so that the CARM cavity pole doesn't come down too far in frequency?  Daytime brain should think about this.

11133   Wed Mar 11 18:02:02 2015 JenneUpdateLSCCARM and DARM loops marginal

I have looked at the CARM and DARM RF loops, assuming the loop shapes that we've been using, and it pretty much looks like a miracle that we were ever able to make the transition.  The CARM and DARM loops are very marginal.

The ALS CARM loop was already pretty close to marginal, but we lose an extra 12 degrees of phase with the REFL loop:

• -4 deg because REFL has analog AA, but ALS does not.
• -6 deg because FM1 is designed to have minimal phase loss at 100Hz, but the REFL integrator is not.
• -2 deg because the cavity pole compensator must have a zero at finite frequency.

However, if our cavity pole compensator's zero frequency is too low, we get all of that phase back, at the sacrifice of 2dB of gain margin at both ends of the phase bubble.

I looked at an Optical simulation to check what the cavity pole frequencies are expected to be, with the losses that we've measured.  In both cases, I assume the Xarm has about 150ppm of loss.  The DARM cavity pole is about 4.5kHz no matter what the Yarm loss is.  The CARM cavity pole is about 172 Hz if the Yarm has 500ppm of loss, or 120 Hz if the Yarm has 200ppm of loss.

In the plots below, I use a CARM cavity pole frequency of 150 Hz, to roughly split the difference.

Edit, 13Mar2015, JCD:  Rana points out to me that I was using from Foton the analog design strings, without including the fact that these are actually digital filters. This means that I am missing some phase lag.  Eeek.

The ALS loop includes:

• Actuator
• 3 16kHz computation cycles (includes computer hops)
• Pendulum
• Analog anti-imaging
• Digital anti-imaging
• 1 64kHz computation cycle
• Violin filters: ETM 1st, 2nd, 3rd order notches
• Plant
• Flat, not including the cavity pole at ~17kHz
• Sensor
• Closed loop response of phase tracker
• Digital anti-aliasing
• 1 64kHz computation cycle
• 1 16kHz computation cycle
• Servo (CARM filter bank)
• FM1
• FM2
• FM3
• FM5
• FM6
• 1 16kHz computation cycle

The REFL loop includes:

• Actuator
• 3 16kHz computation cycles (includes computer hops)
• Pendulum
• Analog anti-imaging
• Digital anti-imaging
• 1 64kHz computation cycle
• Violin filters: ETM 1st, 2nd, 3rd order notches
• Plant
• 150 Hz cavity pole
• Sensor
• Analog anti-aliasing
• Digital anti-aliasing
• 1 64kHz computation cycle
• Servo (CARM_B filter bank and CARM filter bank)
• Cavity pole compensator
• Integrator (20:0)
• FM2
• FM3
• FM5
• FM6
• 1 16kHz computation cycle

The first plot is the case of perfectly matched cavity pole and compensating zero (150Hz, with compensator having 3kHz pole):

This next version is the case where the compensating zero is a little too low, which is the case I think we have now:

The last plot is a DARM loop.  Everything is the same, except that the RF plant has a 4.5kHz pole, and no compensation:

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

[Jenne, EricQ]

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

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

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

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

11:14pm:  DARM transferred to AS55Q

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

(lockloss)

11:53pm:  CARM transition

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

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

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

(lockloss)

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

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

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

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

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

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

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

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

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

* Put in a 3 count offset to CARM loop.

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

* Reduce CARM offset to 2 counts.

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

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

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

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

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

Notes for going forward:

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

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

9818   Wed Apr 16 02:29:30 2014 ericqUpdateLSCCARM and DARM on IR signals, boosts engaged

As Jenne mentioned, we took OLTF transfer functions, and determined that we had more than enough phase margin to switch on the LSC boosts in FM4. This improved the error signal noise spectra quite a lot, and noticeably reduced the TRX/TRY fluctuations, and actuation output.

Here's the CARM OLTF (FM4 boost on in red, boost off in black)

Here's what happened to the CARM and DARM spectra when we turned on the boosts. (ALS only in black, initial IR signal transitions in mid-color, boosted IR signals in bright color)

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

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

Here is the 1:19am lockloss

And here is the 1:27am lockloss

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

0 sec:  Arms are held on resonance with ALS.

10 sec:  CARM offset of 3nm added.

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

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

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

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

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

120 sec:  DARM transitioned to AS55Q.

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

11116   Sat Mar 7 22:01:12 2015 JenneConfigurationLSCCARM and DARM on RF signals!!!!!!!!!!!!!!!!!!!!

[Jenne, with Matt and Fujimi as witnesses]

It might be about time to throw that champagne in the fridge.  Nice. Not quite close enough to talk about popping it open, but we'll want it chilled just in case...

I still haven't logged yesterday's work, and I'm still working now, so no details, but I just handed both CARM and DARM over to non-normalized RF signals, and had the arms stable at powers of about 105.  I was workinig on the ETM alignment, and the power was increasing, so I think that's where the extra power will come from. I was lowering the DARM gain as I improved the alignment, because the optical gain was increasing so much.  I probably just didn't do that fast enough for the last aligning, which is why I lost lock.

Anyhow, here's a plot, because I'm excited:

11117   Sun Mar 8 00:05:37 2015 KojiConfigurationLSCCARM and DARM on RF signals!!!!!!!!!!!!!!!!!!!!

Exciting! How long was it?

11118   Sun Mar 8 01:27:01 2015 JenneConfigurationLSCCARM and DARM on RF signals!!!!!!!!!!!!!!!!!!!!

I have in my notebook that at 9:49pm CARM was no longer using ALS as an error signal, and at 9:50pm, DARM was no longer using ALS as an error signal.  It looks like I was locked for 3+ minutes after getting to RF-only signals.

The increase in power near the end of the lock stretch was me trying to improve the dark port contrast by touching the ETMX alignment.  DARM was definitely oscillating as I improved the dark port contrast, so I was trying to hand-lower the gain as I worked on the alignment.

15015   Wed Nov 6 17:05:45 2019 gautamUpdateLSCCARM calibration

Summary:

A coarse calibration of the CARM error point (when on ALS control) is 7.040 +/- 0.030 kHz/ct. This corresponds to approximately 0.95nm/ct. I typically lose the PRMI lock when the CARM offset is ~0.2 cts, which means I am about 1kHz away from the resonance. This is >10 CARM linewidths.

Details:

The calibration was done by sweeping the CARM offset (no PRM) and identifying the arm cavity FSRs by looking for peaks in TRX / TRY. Attachment #1 shows the scan, while Attachment #2 shows a linear fit to the FSRs. In Attachment #2, the frequency axis is taken from the phase tracker servo, which was calibrated by injecting a "known" frequency with the Marconi, and there is good agreement to the expected FSR with 37.79 m long arm cavities. There is much more info in the scan (e.g. modulation depths, mode matching to the arm cavities etc) which I will extract later, but if anyone wants the data (pre-downsampled by me to have a managable filesize), it's attached as a .zip file in Attachment #3.

10933   Fri Jan 23 02:11:40 2015 JenneUpdateLSCCARM filters modified slightly

[Jenne, Diego]

One of tonight's goals was to tweak the CARM filters, so that we could engage the lowpass filter, to avoid the detuned double cavity pole resonance disturbing the CARM loop.

I increased the Q of the zeros in the FM3 boost so that it eats fewer than the original 18 degrees of phase at 100 Hz.  We kept losing lock though, so for each lock I backed off on the Q a little bit.  In the end, the filter eats 9 degrees of phase at 100 Hz.  I also moved the lowpass from 700 Hz to 1kHz, although that doesn't change the phase at 100 Hz very much.

We modified the carm_up script re: PRMI locking a little bit.  The PRMI is not so enthusiastic about locking immediately at 25% MICH fringe, so I backed that off.  It now acquires lock at a few percent, and then ramps up the offset.  Also, the MICH FM6 bounce roll filter is now turned on after lock is acquired, effectively giving it an extra second or two of delay beyond the rest of the filters.

We were able several times to get to some MICH offset and turn on the lowpass filter, but starting to reduce the CARM offset makes us lose lock.  I think the problem is that the UGF servo demod phase is changing as we are changing offsets, filters and error signals.  We see that the I-phase is servoed successfully to 0dB, but that the Q-phase is starting to move around by 30 degrees or more.  We either need to monitor this much more closely, and add the changing demod phases to the carm_up script, or we need to go back to the sum-of-squares situation that we had last week.  Note that we saw failures with that method for a completely separate reason:  we were getting too close to the limiters, which cause the UGF servos to glitch and the outputs jump by a significant amount.  So, the issues that we were seeing last week when we had the sum-of-squares were a different thing, that we noticed and understood later.

Anyhow, nothing too exciting and glorious tonight, but progress has been made.

Also, from some Mist simulations that Q did, Diego made a sweet plot that is now posted in the control room, so we can translate arm power to CARM offset, at various MICH offsets.

We also took some CARM loop measurements with the new filters.  We have a little more phase than we used to, which is nice.  These traces don't have the lowpass engaged, since I was trying to see how far we could get without it.  We lost lock right after the second measurement, but I think that was to do with the UGF servos.

15351   Tue May 26 03:01:35 2020 gautamUpdateLSCCARM loop

Summary:

I am able to realize ~8 kHz UGF with ~60 degrees of phase margin on the CARM loop OLTF (combination of analog and digital signal paths).

Details:

• Attachment #1 shows the measured OLTF.
• The measurement is made by using the "EXC A" bank on the CM board, with an SR785. With this technique, the measurement will be poor where the loop gain is high, as the excitation will be squished. Nevertheless, we can estimate the behavior in those regimes by using a model, and fitting it to the regions where the measurement is valid (in this case, above ~1 kHz).
• This measurement was made with IN1 Gain = +4 dB, AO gain = 0 dB, and IMC IN2 gain = 0 dB.
• The regular boost has been enabled, but no super-boosts yet, mainly because I think they consume too much phase close to the UGF.
• The modeling/fitting of this, including a more thorough characterization of the crossover, will follow...
15366   Wed Jun 3 01:46:14 2020 gautamUpdateLSCCARM loop

Summary:

The CARM loop now has a UGF of ~12 kHz with a phase margin of ~60 degrees. These values of conventional stability indicators are good. The CARM optical gain that best fits the measurements is 9 MW/m.

I've been working on understanding the loop better, here are the notes.

Details:

Attachment #1 shows a block diagram of the loop topology.

• The "crossover" measurement made at the digital CARM error point, and the OLG measurement at the CM board error point are shown.
• I've tried to include all the pieces in the loop, and yet, I had to introduce a fudge gain in the digital path to get the model to line up with the measurement (see below).

Attachment #2 shows the OLGs of the two actuation paths.

• Aforementioned fudge factor for the digital path is included.
• For the AO path, I assumed a value of the PDH discriminant at the IMC error point to be 13 kHz/V, per my earlier measurement.
• I trawled the elog for the most up-to-date info about the IMC servo (elog9457, elog13696, elog15044) and CM board, to build up the model.

Attachment #3 and #4 show the model, overlaid with measurements of the loop OLG and crossover TF respectively.

• No fitting is done yet - the next step would be to add the delay of the CDS system for the digital path, and the analog electronics for the AO path. Though these are likely only small corrections.
• For the crossover TF - I've divided out the digital filters in the CARM_B filter bank, because the injection is made downstream of it (see Attachment #1).
• There is reasonably good agreement between model and measurement.
• I think the biggest source of error is the assumed model for the IMC OLTF.

Attachment #5 shows the evolution of the CARM OLG at a few points in the lock acquisition sequence.

• "Before handoff" corresponds to the state where the primary control is still done by the ALS leg, but the REFL11 signal has begun to enter the picture via the CARM_B path.
• "IN2 ramped" corresponds to the state where the AO path gain (=IN2 gain on the IMC servo board) has been ramped up to its final value (+0 dB), but the overall loop gain (=IN1 gain on the CM board) is still low. So this is preparation for high bandwidth control. Typically, the arm powers will have stabilized in this state, but ALS control is still on.
• "Pre-boost" corresponds to an intermediate state - ALS control is off, but the low frequency boosts have not yet been enabled. I typically first engage some ASC to stabilize things somewhat, and then turn on the boosts.
• "Final" - self explanatory.

Next steps:

Now the I have a model I believe, I need to think about whether there is any benefit to changing some of these loop shapes. I've already raised the possibility of changing the shape of the boosts on the CM board, with which we could get a bit more suppression in the 100 Hz - 1kHz region (noise budget of laser frequency noise --> DARM required to see if this is necessary).

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

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

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

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

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

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

Here are the normalized plots:

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

1500   Mon Apr 20 18:17:44 2009 robSummaryLockingCARM offset/Power rubric

Plotted assuming the average arm power goes up to ~80.  No DARM offset.

10953   Thu Jan 29 04:27:35 2015 ericqUpdateLSCCARM on REFL11

[ericq, Diego]

Tonight, we transitioned CARM from ALS directly to REFL11 I at 25% Mich Offset.

We attempted the transition twice, the first time worked, but we lost lock ~5 seconds after full transition due to a sudden ~400Hz ringup (see attached lockloss plot). The second barfed halfway, I think because I forgot to remove the CARM B offset from the first time

The key to getting to zero CARM offset with CARM and DARM on ALS is ekeing out every bit of PRMI phase margin that you can. Neither MICH nor PRCL had their RG filters on and I tweaked the MICH LP to attenuate less and give back more phase (the HF still isn't the dominant RMS source.) PRCL had ~60 degrees phase margin at 100Hz UGF, MICH had ~50 deg at 47Hz UGF. The error signals were comparitively very noisy, but we only cared that they held on. Also important was approaching zero slooooooooowly, and having the CARM and DARM UGF servo excitations off, because they made everything go nuts. Diego stewarded the MICH and PRCL excitation amplitudes admirably.

Oddly, and worringly, the arm powers at zero CARM offset were only around 10-12. Our previous estimations already include the high Xarm loss, so I'm not sure what's going on with this. Maybe we need to measure our recycling gain?

I hooked up the SR785 by the LSC rack to the CM board after the first success. For the second trial, I also took TFs with respect to CM slow, but they looked nowhere near as clean as the normal REFL11 I channel; I didn't really check all the connections. I will be revisiting the whole AO situation soon.

In any case, I think we're getting close...

10960   Fri Jan 30 03:12:15 2015 diegoUpdateLSCCARM on REFL11I

[Jenne, Diego]

Tonight we continued following the plan of last night: perform the transition of CARM to REFL11_I while on MICH offset at -25%:

• we managed to do the transition several times, keeping the UGF servos on for MICH and PRCL but turning off the DARM and CARM ones, because their contribution was rather unimportant and we feared that their excitations could affect negatively the other loops (as loops tend to see each other's excitation lines);
• we had to tweak the MICH and PRCL UGF servos:
• the excitation frequency for MICH was lowered to ~41 Hz, while PRCL's one was lowered to ~50 Hz;
• PRCL's amplitude was lowered to 75 because it was probably too high and it affected the CARM loop, while MICH's one was increased to 300 because during the reduction of the CARM offset it was sinking into the noise; after a few tries we can say they don't need to be tweaked on the fly during the procedure but can be kept fixed from the beginning;
• after the transition to REFL11_I for CARM, we engaged also its UGF servo, still at the highest frequency of the lot (~115 Hz) and with relatively low amplitude (2), to help keeping the loop stable;
• as DARM was still on ALS, we didn't engage its UGF servo during or after the transition, but we just hold its output from the initial part of the locking sequence (after we lowered its frequency to 100 Hz;
• however, at CARM offset 0 our arm power was less that what we had yesterday: we managed to get higher than ~8, but after Koji tweaked the MC alignment we reached ~10; we still don't understand the reason of the big difference with respect to what the simulations show for MICH offset at 25% (arm power ~50);
• after the CARM transition to REFL11_I we felt things were pretty stable, so we tried to reduce the MICH offset to get us in the ~ -10% range, however we never managed to get past ~ -15% before losing lock, at arm power around 20;
• we lost lock several times, but for several different reasons (IMC lost lock a couple of times, PRCL noise increased/showed some ringing, MICH railed) but our main concern is with the PRCL loop:
• we took several measurements of the PRCL loop: the first one seemed pretty good, and it had a bigger phase bubble than usual; however, the subsequent measurements showed some weird shapes we struggle to find a reason for; these measurements were taken at different UGF frequencies, so maybe it is worth looking for some kind of correlation; morever, in the two weird measurements the UGFs are not where they are supposed to be, even if the servo was correctly following the input (or so it seemed); the last measurement was interrupted just before we lost lock because of PRCL itself;
• we noticed a few times during the night that the PRCL loop noise in the 300-500 Hz range increased suddenly and we saw some ringing; at least a couple of times it was PRCL who threw us out of lock; this frequency range is similar to the 'weird' range we found in our measurements, so we definitely need to keep an eye on PRCL on those frequencies;
• in conclusion, the farthest we got tonight was CARM on REFL11_I at 0 offset, DARM at 0 offset still on ALS and MICH at ~ 15% offset, arm power ~20.

573   Thu Jun 26 12:30:40 2008 JohnSummaryLockingCARM on REFL_DC
Idea:

Try REFL_DC as the error signal for CARM rather than PO_DC.

Reasoning:

The PO signal is dominated by sideband light when the arms are detuned so that any misalignment in the recycling cavity introduces spurious signals. Also, the transfer function from coupled cavity excitation to REFL signal is not so steep and hence REFL should give a little more phase. Finally, the slope of the REFL signal should make it easier to hand over to RF CARM.

Conclusion:

The REFL signal showed no clear improvement over PO signals. We've gone back to PO.

During the night we also discovered that the LO for the MC loop is low.
9793   Thu Apr 10 01:56:05 2014 JenneUpdateLSCCARM transitioned to IR error signals!

[Jenne, EricQ]

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

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

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

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

ALS lock conventions:

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

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

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

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

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

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

Transitioning CARM to 1/sqrt(trans) signals:

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

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

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

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

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

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

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

Attempt at transitioning DARM to AS55:

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

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

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

Conclusions / path(s) forward:

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

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

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

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

13653   Fri Feb 23 07:47:54 2018 SteveUpdateVACCC1 Hornet

We have the IFO pressure logged again! Thanks Johannes and Gautam

This InstruTech cold cathode ionization vacuum gauge " Hornet " was installed 2016 Sep 14

Here is the CC1 gauge history of 10 years from 2015 Dec 1

The next thing to do is put this channel C1:Vac-CC1_HORNET_PRESSURE  on the 40m Vacuum System Monitor   [ COVAC_MONITOR.adl ]

gautam 1pm: Vac MEDM screen monitor has been edited to change the readback channel for the CC1 pressure field - see Attachment #2. Seems to work okay.

11276   Fri May 8 14:30:09 2015 SteveUpdateVACCC1 cold cathode gauges are baked now

CC1s  are not reading any longer. It is an attempt to clean them over the weekend at 85C

These brand new gauges "10421002" sn 11823-vertical, sn 11837 horizontal replaced 11 years old 421 http://nsei.missouri.edu/manuals/hps-mks/421%20Cold%20Cathode%20Ionization%20Guage.pdf  on 09-06-2012 http://nodus.ligo.caltech.edu:8080/40m/7441

 Quote: We have two cold cathode gauges at the pump spool and one  signal cable to controller. CC1  in horizontal position and CC1 in vertical position.   CC1 h started not reading so I moved cable over to CC1 v

11287   Tue May 12 14:57:52 2015 SteveUpdateVACCC1 cold cathode gauges are baked now

Baking both CC1 at 85 C for 60 hrs did not help.

The temperature is increased to 125 C and it is being repeated.

Quote:

CC1s  are not reading any longer. It is an attempt to clean them over the weekend at 85C

These brand new gauges "10421002" sn 11823-vertical, sn 11837 horizontal replaced 11 years old 421 http://nsei.missouri.edu/manuals/hps-mks/421%20Cold%20Cathode%20Ionization%20Guage.pdf  on 09-06-2012 http://nodus.ligo.caltech.edu:8080/40m/7441

 Quote: We have two cold cathode gauges at the pump spool and one  signal cable to controller. CC1  in horizontal position and CC1 in vertical position.   CC1 h started not reading so I moved cable over to CC1 v

14264   Wed Oct 31 17:54:25 2018 gautamUpdateVACCC1 hornet power connection restored

Steve reported to me that the CC1 Hornet gauge was not reporting the IFO pressure after some cable tracing at EX. I found that the power to the unit had been accidentally disconnected. I re-connected the power and manually turned on the HV on the CC gauge (perhaps this can be automated in the new vacuum paradigm). IFO pressure of 8e-6 torr is being reported now.

14639   Sun May 26 21:47:07 2019 KruthiUpdateCamerasCCD Calibration

On Friday, I tried calibrating the CCD with the following setup. Here, I present the expected values of scattered power (Ps) at $\theta$s = 45°, where $\theta$s is scattering angle (refer figure). The LED box has a hole with an aperture of 5mm and the LED is placed at approximately 7mm from the hole. Thus the aperture angle is 2*tan-1(2.5/7) ≈ 40° approx. Using this, the spot size of the LED light at a distance 'd' was estimated. The width of the LED holder/stand (approx 4") puts a constraint on the lowest possible $\theta$s. At this lowest possible $\theta$s, the distance of CCD/Ophir from the screen is given by $\dpi{80} \sqrt{d^2 + (2'')^2}$. This was taken as the imaging distance for other angles also.

In the table below, Pi is taken to be 1.5mW, and Ps and $\Omega$ were calculated using the following equations:

$\dpi{80} \Omega = \frac{CCD \ sensor \ area}{(Imaging \ distance)^2}$            $\dpi{80} P_{s} = \frac{1 }{\pi} * P_{i} *\Omega *cos(45^{\circ})$

 d (cm) Estimated spot diameter (cm) Lowest possible $\theta$s  (in degrees) Distance of CCD/Ophir from the screen (in cm) $\Omega$ (in sr) Expected Ps at   $\theta$s = 45° (in µW) 1.0 1.2 78.86 5.2 0.1036 34.98 2.0 2.0 68.51 5.5 0.0259 8.74 3.0 2.7 59.44 5.9 0.0115 3.88 4.0 3.4 51.78 6.5 0.0065 2.19 5.0 4.1 45.45 7.1 0.0041 1.38 6.0 4.9 40.25 7.9 0.0029 0.98 7.0 5.6 35.97 8.6 0.0021 0.71 8.0 6.3 32.42 9.5 0.0016 0.54 9.0 7.1 29.44 10.3 0.0013 0.44 10.0 7.8 26.93 11.2 0.0010 0.34

On measuring the scattered power (Ps) using the ophir power meter, I got values of the same order as that of  expected values given the above table. Like Gautam suggested, we could use a photodiode to detect the scattered power as it will offer us better precision or we could calibrate the power meter using the method mentioned in Johannes's post: https://nodus.ligo.caltech.edu:8081/40m/13391.

14708   Sat Jun 29 03:11:18 2019 KruthiUpdateCamerasCCD Calibration

Finding the gain of the Photodiode: The three-position rotary switch of the photodiode being used (PDA520) wasn't working, so I determined its gain by making a comparative measurement between ophir power meter and the photodiode. The photodiode has a responsitivity of 0.34 A/W at 1064 nm (obtained from the responsitivity curve given in the spec sheet using a curve digitizing software). Using the following equation, I determined the gain setting, which turned out to be 20dB.

$\dpi{50} \large Transimpedance\ Gain (V/A) = \frac{Photodiode\ reading (V)}{Ophir\ reading (W) * Responsitivity (A/W)}$

Setup: Here a 1050nm (closest we have to 1064nm) LED is used as the light source instead of a laser to eliminate the effects caused by coherence of a laser source, which might affect our radiometric calibration. The LED is placed in a box with a hole of diameter 5mm (aperture angle = 40 degrees approx.). Suitable lenses are used to focus the light onto a white paper, which is fixed at an arbitrary angle and serves as a Lambertian scatterer. To make a comparative measurement between the photodiode (PDA520) and GigE, we need to account for their different sensor areas, 8.8mm (aperture diameter) and 3.7mm x 2.8 mm respectively . This can be done by either using an iris with a common aperture so that both the photodiode and GigE receive same amount of light , or by calculating the power incident on GigE using the ratio of sensor areas and power incident on the photodiode (here we are using the fact that power scattered by Lambertian scatterer per unit solid angle is constant).

Calibration of GigE 152 unit: I took around 50 images, starting with an exposure time of 2000 $\dpi{50} \LARGE \mu s$ in steps of 2000, using the exposure_variation.py code. But the code doesn't allow us to take images with an exposure time greater than 100 ms, so I took few more images at higher exposures manually. From each image I subtracted a dark image (not in the sense of usual CCD calibration, but just an image with same exposure time and no LED light). These dark images do the job of usual dark frame + bias frame and also account for stray lights. A plot of pixel sum vs exposure time is attached. From a linear fit for the unsaturated region, I obtained the slope and calculated the calibration factor.

Equations:      $\dpi{50} \LARGE Power (P)=\frac{Photodiode\ reading(V)}{Transimpedance\ gain (V/W) * Responsivity (A/W)}$                    $\dpi{50} \LARGE Calibration factor (CF) = \frac{P}{slope}$

Result: CF = 1.91x 10^-16 W-sec/counts  Update: I had used a wrong value for the area of photodiode. On using 61.36 mm^2 as the area, I got 2.04 x 10^-15 W-sec/counts.

I'll put the uncertainities soon. I'm also attaching the GigE spectral response curve for future reference.

14757   Sun Jul 14 00:24:29 2019 KruthiUpdateCamerasCCD Calibration

On Friday, I took images for different power outputs of LED. I calculated the calibration factor as explained in my previous elog (plots attached).

Vcc (V) Photodiode

Power incident on photodiode (W)

Power incident on GigE (W)
 Slope (counts/​𝝁s)
Uncertainity in
slope (counts/​𝝁s)
CF (W-sec/counts)
16 0.784 2.31E-06 3.89E-07 180.4029 1.02882 2.16E-15
18 0.854 2.51E-06 4.24E-07 207.7314 0.7656 2.04E-15
20 0.92 2.71E-06 4.57E-07 209.8902 1.358 2.18E-15
22 0.969 2.85E-06 4.81E-07 222.3862 1.456 2.16E-15
25 1.026 3.02E-06 5.09E-07 235.2349 1.53118 2.17E-15
Average  2.14E-15

To estimate the uncertainity, I assumed an error of at most 20mV (due to stray lights or difference in orientation of GigE and photodiode) for the photodiode reading. Using the uncertainity in slope from the linear fit, I expect an uncertainity of maximum 4%. Note: I haven't accounted for the error in the responsivity value of the photodiode.

 GigE area 10.36 sq.mm PDA area 61.364 sq.mm Responsivity 0.34 A/W Transimpedance gain (at gain = 20dB) 10^6 V/W +/- 0.1% Pixel format used Mono 8 bit

Johannes had reported CF as 0.0858E-15 W-sec/counts for 12 bit images, with measured a laser source. This value and the one I got are off by a factor of 25. Difference in the pixel formats and effect of coherence of the light used might be the possible reasons.

3655   Tue Oct 5 18:27:18 2010 Joonho LeeSummaryElectronicsCCD cable's impedence

Today I checked the CCD cables which is connected to the VIDEOMUX.

17 cables are type of RG59, 8 cables are type of RG58. I have not figured out the type of other cables(23 cables) yet.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

To check the impedance of each CCD cable, I went to the VIDEOMUX and looked for the label on the cable's surface.

Type of RG59 is designated to the cable of impedance 75ohm. I wrote down each cable's input or output channel number with observation(whether it is of type RG59 or not).

The result of observation is as follows.

 Type channel number where it is connected to Type 59 in#2, in#11, in#12, in#15, in#18, in#19, in#22, in#26, out#3, out#4, out#11, out#12, out#14, out#17, out#18, out#20, out#21 Type 58 in#17, in#23, in#24, in#25, out#2, out#5, out#7, out#19 unknown type others

For 23 cables that I have not figured out their type, cables are too entangled so it is limited to look for the label along each cable.

I will try to figure out more tomorrow. Any suggestion would be really appreciated.

3739   Mon Oct 18 22:11:32 2010 Joonho LeeSummaryElectronicsCCD cables for input signal

Today I checked all the CCD cables which is connected input channels of the VIDEOMUX.

Among total 25 cables for output, 12 cables are type of RG59, 4 cables are type of RG58, and 9 cables are of unknown type.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

Today, I check the cables in similar way as I did the last time.

I labeled all cables connected to input channels of VIDEO MUX and disconnect all of them since last time it was hard to check every cable because of cables too entangled.

Then I checked the types of all cables and existing label which might designate where each cable is connected to.

After I finished the check, I reconnected all cables into the input channel which each of cable was connected to before I disconnected.

4 cables out of 25 are type of RG58 so expected to be replace with cable of type RG59.

9 cables out of 25 are of unknown type. These nine cables are all orange-colored thick cables which do not have any label about the cable characteristic on the surface.

The result of observation is as follows.

Note that type 'TBD-1' is used for the orange colored cables because all of them look like the same type of cable.

 Channel number where its signal is coming type 1 C1:IO-VIDEO 1 MC2 TBD-1 2 FI CAMERA 59 3 PSL OUTPUT CAMERA 59 4 BS  C:1O-VIDEO 4 TBD-1 5 MC1&3 C:1O-VIDEO 5 59 6 ITMX C:1O-VIDEO 6 TBD-1 7 C1:IO-VIDEO 7 ITMY TBD-1 8 C1:IO-VIDEO 8 ETMX TBD-1 9 C1:IO-VIDEO 9 ETMY TBD-1 10 No cable is connected (spare channel) 11 C1:IO-VIDEO 11 RCR 59 12 C1:IO-VIDEO RCT 59 13 MCR VIDEO 59 14 C1:IO-VIDEO 14 PMCT 59 15 VIDEO 15 PSL IOO(OR IOC) 59 16 C1:IO-VIDEO 16 IMCT TBD-1 17 PSL CAMERA 58 18 C1:IO-VIDEO 18 IMCR 59 19 C1:IO-VIDEO 19 SPS 59 20 C1:IO-VIDEO 20 BSPO TBD-1 21 C1:IO-VIDEO 21 ITMXPO TBD-1 22 C1:IO-VIDEO 22 APS1 59 23 ETMX-T 58 24 ETMY-T 58 25 POY CCD VIDEO CH25 58 26 OMC-V 59

Today I could not figure out what impedance the TBD-1 type(unknown type) has.

Next time, I will check out the orange-colored cables' impedance directly and find where the unknown output signal is sent. Any suggestion would be really appreciated.

3694   Mon Oct 11 23:55:25 2010 Joonho LeeSummaryElectronicsCCD cables for output signal

Today I checked all the CCD cables which is connected output channels of the VIDEOMUX.

Among total 22 cables for output, 18 cables are type of RG59, 4 cables are type of RG58.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

Today, I labeled all cables connected to output channels of VIDEO MUX and disconnect all of them since last time it was hard to check every cable because of cables too entangled.

With thankful help by Yuta, I also checked which output channel is sending signal to which monitor while I was disconnecting cables.

Then I checked the types of all cables and existing label which might designate where each cable is connected to.

After I finished the check, I reconnected all cables into the output channel which each of cable was connected to before I disconnected.

4 cables out of 22 are type of RG58 so expected to be replace with cable of type RG59.

The result of observation is as follows.

 Ch# where its signal is sent type 1 unknown 59 2 Monitor#2 58 3 Monitor#3 59 4 Monitor#4 59 5 Monitor#5 58 6 Monitor#6 59 7 Monitor#7 58 8 unknown / labeled as "PSL output monitor" 59 9 Monitor#9 59 10 Monitor#10 59 11 Monitor#11 59 12 Monitor#12 59 13 Unknown 59 14 Monitor#14 59 15 Monitor#15 59 16 unknown / labeled as "10" 59 17 unknown 59 18 unknown / labeled as "3B" 59 19 unknown / labeled as "MON6 IR19" 58 20 unknown 59 21 unknown 59 22 unknown 59

I could not figure out where 10 cables are sending their signals to. They are not connected to monitor turned on in control room

so I guess they are connected to monitors located inside the lab. I will check these unknown cables when I check the unknown input cables.

Next time, I will check out cables which is connected to input channels of VIDEIO MUX. Any suggestion would be really appreciated.

4139   Tue Jan 11 21:08:19 2011 JoonhoSummaryCamerasCCD cables upgrade plan.

Today I have made the CCD Cable Upgrade Plan for improvement of sysmtem.

I have ~60 VIDEO cables to be worked for upgrades so I would like to ask all of your favor in helping me of replacing cables.

1. Background

Currently, VIDEO system is not working as we desire.

About 20 cables are of impedance of 50 or 52 ohm which is not matched with the whole VIDEO system.

Moreover, some cameras and monitors are out of connection.

2. What I have worked so far.

I have checked impedance of all cables so I figured out which cables can be used or should be replaced.

I measured cables' pathes along the side tray so that we can share which cable is installed along which path.

I have made almost of cables necessary for VIDEO system upgrades but no label is attached so far.

3. Upgrade plan (More details are shown in attached file)

 0 : Cable for output ch#2 and input ch#16 is not available for now 1 : First, we need to work on the existing cables. 1A : Check the label on the both ends and replace to the new label if necessary 1B : We need to move the existing cable's channel only for those currently connected to In #26 (from #26 to #25) 2 : Second, we need to implement new cables into the system 2A : Make two cable's label and attach those on the both ends 2B : Disconnect existing cables at the channel assigned for new cables and remove the cables from the tray also 2C : Move 4 quads into the cabinet containing VIDEO MUX 2D : Implement the new cable into the system along the path described and connect the cables to the assgined channel and camera or monitor

4. This is a kind of  a first draft of the plan.

Any comment for the better plan is always welcome.

Moreover, replacing all the cables indicated in the files is of great amount of work.

I would like to ask all of your favors in helping me to replace the cables (from 1. to 2D. steps above).

3950   Thu Nov 18 17:42:20 2010 Joonho LeeSummaryElectronicsCCD cables.

I finished the direct measurement of cable impedances.

Moreover, I wrote the cable replacement plan.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

Moreover, as Koji suggested, the VIDEO system will be upgraded for better interface.

I measured the cable impedance by checking the reflection ratio at the point connected to the terminator with 50 ohm or 75 ohm.

The orange colored cables are measured to be 75ohm so we do not need to replace them.

Combining the list of cable types and the list of desired length,

I need to make total 37 cables and to remove 10 cables from the current connection.

Detailed plan is attached below.

I currently ordered additional cables and BNC plugs.

From now on, I will keep making CCD cables for VIDEO upgrade.

Then, with your helps, we will replace the CCD cables.

In my opinion, I will finish VIDEO upgrade by this year.

13352   Mon Oct 2 23:16:05 2017 gautamHowToCamerasCCD calibration

Going through some astronomy CCD calibration resources ([1]-[3]), I gather that there are in general 3 distinct types of correction that are applied:

1. Dark frames --- this would be what we get with a "zero duration" capture, some documents further subdivide this into various categories like thermal noise in the CCD / readout electronics, poissonian offsets on individual pixels etc.
2. Bias frames --- this effect is attributed to the charge applied to the CCD array prior to the readout.
3. Flat-field calibration --- this effect accounts for the non-uniform responsivity of individual pixels on the CCDs.

The flat-field calibration seems to be the most complicated - the idea is to use a source of known radiance, and capture an image of this known radiance with the CCD. Then assuming we know the source radiance well enough, we can use some math to back out what the actual response function of individual pixels are. Then, for an actual image, we would divide by this response-map to get the actual image. There are a number of assumptions that go into this, such as:

• We know the source radiance perfectly (I guess we are assuming that the white paper is a Lambertian scatterer so we know its BRDF, and hence the radiance, perfectly, although the work that Jigyas and Amani did this summer suggest that white paper isn't really a Lambertian scatterer).
• There is only one wavelength incident on the CCD.
• We can neglect the effects of dust on the telescope/CCD array itself, which would obviously modify the responsivity of the CCD, and is presumably not stationary. Best we can do is try and keep the setup as clean as possible during installation.

I am not sure what error is incurred by ignoring 2 and 3 in the list at the beginning of this elog, perhaps this won't affect our ability to estimate the scattered power from the test-masses to within a factor of 2. But it may be worth it to do these additional calibration steps.

I also wonder what the uncertainty in the 1.5V/A number for the photodiode is (i.e. how much do we trust the Ophir power meter at low power levels?). The datasheet for the PDA100A says the transimpedance gain at 60dB gain is 1.5 MV/A (into high impedance load), and the Si responsivity at 1064nm is ~0.25A/W, so naively I would expect 0.375 V/uW which is ~factor of 4 lower. Is there a reason to trust one method over the other?

Also, are the calibration factor units correct? Jigyasa reported something like 0.5nW s / ct in her report.

 Camera IP Calibration Factor CF 192.168.113.152 8.58 W*s 192.168.113.153 7.83 W*s

The incident power can be calculated as Pin =CF*Total(Counts-DarkCounts)/ExposureTime.

References:

[1] http://www.astrophoto.net/calibration.php

[2] https://www.eso.org/~ohainaut/ccd/

[3] http://www.astro.ufl.edu/~lee/ast325/handouts/ccd.pdf

13354   Tue Oct 3 01:58:32 2017 johannesHowToCamerasCCD calibration

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The factors were indeed enormously off. The correct table reads:

 Camera IP Calibration Factor CF 192.168.113.152 85.8 pW*s 192.168.113.153 78.3 pW*s

I did subtract a 'dark' frame from the images, though not in the sense of your point 1, just an exposure of identical duration with the laser turned off. This was mostly to reduce the effect of residual light, but given similar initial conditions would somewhat compensate for the offset that pre-existing charge and electronics noise put on the pixel values. The white field is of course a difference story.

I wonder how close we can get to a white field by putting a thin piece of paper in front of the camera without lenses and illuminate it from the other side. A problem is of course the coherence if we use a laser source... Or we scrap any sort of screen/paper and illuminate directly with a strongly divergent beam? Then there wouldn't be a specular pattern.

I'm not sure I understand your point about the 1.5V/A. Just to make sure we're talking about the same thing I made a crude drawing:

The PD sees plenty of light at all times, and the 1.5V/uW came from a comparative measurement PD<-->Ophir (which took the place of the CCD) while adjusting the power deflected with the AOM, so it doesn't have immediate connection to the conversion gain of silicon in this case. I can't remember the gain setting of the PD, but I believe it was 0dB, 20dB at most.

13940   Mon Jun 11 17:18:39 2018 poojaUpdateCamerasCCD calibration

Aim: To calibrate CCD of GigE using LED1050E.

The following table shows some of the specifications for LED1050E as given in Thorlabs datasheet.

 Specifications Typical maximum ratings DC forward current (mA) 100 Forward voltage (V) @ 20mA (VF) 1.25 1.55 Forward optical power (mW) 1.6 Total optical power (mW) 2.5 Power dissipation (mW) 130

The circuit diagram is given in Attachment 1.

Considering a power supply voltage Vcc = 15V, current I = 20mA & forward voltage of led VF = 1.25V, resistance in the circuit is calculated as,

R = (Vcc - VF)/I = 687.5$\ohm$$\ohms$$\Omega$

Attachment 2 gives a plot of resistance (R) vs input voltage (Vcc) when a current of 20mA flows through the circuit. I hope I can proceed with this setup soon.

ELOG V3.1.3-