40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 215 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  9030   Mon Aug 19 11:30:20 2013 JenneUpdateIOOMC mirrors' ASC has non-zero inputs

[Masayuki, Jenne]

When I came in this morning, I noticed that the Mode Cleaner had not been locked for at least the past 8 hours.  We moved the MC SUS sliders until the MC SUSPIT and SUSYAW values for each mirror were back to approximately the place they were the last time the MC was nicely locked (~12 hours ago).  This got the MC flashing TEM00, so we thought we were doing well. 

However, if the servo was enabled, any time the cavity flashed a small-order mode (especially 00), the mirrors would get super kicked.  Not good

We went to investigate, and discovered that the RFPD aux laser was left on again.  We turned that off, however that didn't fix the situation. 

Manasa suggested checking that the WFS were really, really off.  When we looked at the WFS master screen, we noticed that although the WFS servos were off, the MC mirrors' ASC filter banks had non-zero inputs.  We checked, and this is not from the MCASS, nor is it from the MC WFS lockins.  At this point, I have no idea where these signals are coming from.  I have turned off the ASC outputs for all the MC mirrors (which means that we cannot turn on the WFS), and the MC locks fine

So, we need to know where the ASC signals are coming from.  There isn't anything that I can see, from any screen that I can find, that indicates some signals being sent over there.  Has anyone done anything lately?  I know Koji was working on IPC stuff the other day, but the MC was locking fine over the weekend until yesterday afternoon, so I suspect that's not the culprit. 

I have turned off the outputs of the WFS lockins, as part of my turning things off, so if whatever script needs them doesn't enable them, they should be turned back on by hand.

  9032   Mon Aug 19 15:23:07 2013 KojiUpdateIOOMC mirrors' ASC has non-zero inputs

[Jenne, Koji]

This disturbance in the MC ASC channels were fixed.

This craziness happened ~10pm last night. Was there any action at the time? >> Sunday-night workers? (RXA: No, Nakano-kun and I left before 9:30 PM)

We found that the signals came from c1ioo. However, restarting, recompiling c1ioo and c1mcs didn't help
to clean up this issue. Just in case we cleaned up the corresponding entries in the ipc file /opt/rtcds/caltech/c1/chans/ipc/C1.ipc
and recomplied c1ioo and c1mcs because these are the channels we touched last week to mitigate the timing out issue of c1rfm.

Incidentally, we fell into a strange mode of the RCG: IOPs could not restart. We ended up running "sudo shutdown -r now"
on each machine (except for c1lsc which was not affected by this issue). This solved the issue.

Even now c1oaf could not be running properly. This is not affecting the IFO operation right now, but we need to look into this issue again
in order to utilize OAF.

  8906   Tue Jul 23 13:55:08 2013 KojiUpdateIOOMC manually aligned

The MC was manually aligned. The spot positions were measured and it is consistent with the measurements done yesterday.

Attachment 1: MCalignment.png
MCalignment.png
Attachment 2: MCspot.png
MCspot.png
  10851   Sun Jan 4 22:08:46 2015 ranaUpdateIOOMC loop characterizations: PZT/EOM crossover

 * PMC + MC were unlocked when I came in.

* I fiddled around some more with the mcup/down scripts to make locking snappier. The locking was breaking the PMC lock often, so I re-enabled the MC servo board output limiter during acquisition. It is disabled in the MC UP script.

* Re-measured the MC OLG. Still OK.

* Measured the PZT / EOM crossover (aka the FAST / PC crossover) using the connectors on Koji's summing box. With the FAST gain at 18 dB, the crossover is ~10 kHz. Looks way to shallow. Plots to follow.

* I finally discovered today that the PMC PZT stroke is what's causing the main mis-alignment of the beam going to the IMC. By relocking at a few positions, I could see that the IOO QPDs have steps when the PMC relocks. So the IO beam wander is NOT due to temperature effects on the optics mounts of the PSL table. I wonder if we have a large amount of length to angle coupling or if this is the same as the OMC PZTs ?

P.S. I found that someone is using a temporary bench power supply to power the summing box between the TTFSS and the Thorlabs HV driver...whoever did this has ~48 hours to hook up the power in the right way or else Koji is going to find out and lose it and then you have to wear the Mickey Mouse hat.

http://www.arroyoinstruments.com/files/Arroyo-UsingBenchPowerSupplies_11Apr.pdf


The first attachment shows the OLG measurements with 2 different values of the fast gain (our nominal FG is 18 dB). You can see that the higher gains produce some crossover instability; when tuning the gain we notice this as an increase in the PCDRIVE rms channel.

The second attachment shows the measurement of the 'crossover'. Its really just the direct measurement of the IN1 / IN2 from the FAST summing box, so its the crossover measurement where the OLG is high.

Attachment 1: MC_OLGs.pdf
MC_OLGs.pdf
Attachment 2: MC_xover.pdf
MC_xover.pdf
  125   Tue Nov 27 15:47:17 2007 robConfigurationIOOMC loop
After the FSS running pretty quick, I checked the MC loop. I used TPA 1&2.

MC loop
UGF: 70kHz
Input Gain: 29dB
Boost Level: 2
phase: 40 deg
Attachment 1: MCsmall.jpg
MCsmall.jpg
  126   Tue Nov 27 16:18:58 2007 robConfigurationIOOMC loop
Reduced the common gain to 22dB in the mcup script, so that the WFS would not blow the lock. The above measure of the OLG was done without the mcWFS running, so may be a low estimate as compared to when the alignment is perfect.
  1821   Mon Aug 3 14:47:53 2009 JenneUpdateIOOMC locks again

The mode cleaner seems to be locking again.  I've manually unlocked it a few times in the past 20min, and most of the time it catches lock again (maybe about 80% of the time).  Other times, it starts to lock in a bad mode, and can't fix itself, so I unlock it, and let it restart and it usually does fine the second time around. 

 

I'd like it to be a little more robust, but I'm having a bit of trouble zeroing in on the optimal alignment for quickest, most durable lock aquisition of the MC.  Right now I'm going to leave it for a little while to make sure it doesn't fall apart.

  8424   Mon Apr 8 22:43:44 2013 ranaUpdatePSLMC locking troubles: MC/FSS servo unstable

The MC seemed to be losing lock recently quite a bit. I noticed that the PC Drive RMS signal was red.

This means that the high frequency drive to the Pockels cell was too high by a factor of 2-3 and sometimes saturating and breaking the lock.

I fiddled with the gains on the FSS screen until this value went down. It looks like there is some kind of high Q oscillation; it takes a couple minutes for the PC Drive RMS to settle to its new position after changing the gains.

The attached trend plot show the last 2 hours. The mean is now back to ~1 V and seems OK. We should really examine the FSS or MC error point spectra with the RF analyzer while exploring this gain space.

Attachment 1: Untitled.png
Untitled.png
  1229   Thu Jan 15 09:19:32 2009 steveUpdateIOOMC locking
MC2 sus damping was found tripped at the morning the second time this week.

Damping was restored, ISS gain lowered to avoid saturation, MZ manually locked
and MC locking was back.
  8469   Mon Apr 22 11:46:09 2013 KojiSummaryIOOMC locked/aligned. MC WFS offloading by ezcaservo

Еру ьс шы тщц дщслув фтв фдшптувю

Фдыщ ш кфт еру ащддщцштп ыскшзе ещ щаадщфв еру ЬС ЦАЫ ыукмщю

I blame Den for russian keyboard installation on the control machines.

ezcaservo -r 'C1:SUS-MC2_ASCPIT_OUT16' -g '0.00001' -t 60 C1:SUS-MC2_PIT_COMM&
ezcaservo -r 'C1:SUS-MC2_ASCYAW_OUT16' -g '0.00001' -t 60 C1:SUS-MC2_YAW_COMM&
ezcaservo -r 'C1:SUS-MC1_ASCPIT_OUT16' -g '0.00001' -t 60 C1:SUS-MC1_PIT_COMM&
ezcaservo -r 'C1:SUS-MC1_ASCYAW_OUT16' -g '0.00001' -t 60 C1:SUS-MC1_YAW_COMM&
ezcaservo -r 'C1:SUS-MC3_ASCPIT_OUT16' -g '0.00001' -t 60 C1:SUS-MC3_PIT_COMM&
ezcaservo -r 'C1:SUS-MC3_ASCYAW_OUT16' -g '0.00001' -t 60 C1:SUS-MC3_YAW_COMM&

  8471   Mon Apr 22 17:06:42 2013 ranaSummaryIOOMC locked/aligned. MC WFS offloading by ezcaservo

 

 Why use the PSL beam as a reference? Don't we want to keep the MC pointing in a good direction through the Faraday instead???

  7591   Tue Oct 23 00:41:55 2012 JenneUpdateAlignmentMC locked, spots centered

[Jenne, Raji]

We replaced the MC Refl path BS with the Y1, as usual, so that the full ~100mW goes to the REFL PD, so we don't have WFS or MC refl camera. 

The MC spots were all outside of 1mm, and some were beyond 2mm (for MC1,3, P,Y....MC2 is of course free since we have more DoFs than we need), so we touched (very, very slightly) the zigzag mirrors on the PSL table.  We realigned the MC, and now the spots are centered to my satisfaction.

MC1,2,3 Pit,    MC1,2,3 Yaw (in mm):

[0.46444020918749457, 8.2634316545130009, -0.41417975237831089, -0.89401481457980592, -0.9323196976382162, -1.543145765853893]

MC2 is way off in pitch, according to this measurement, and it's been consistently going down as we move the MC2 spot in the same direction (up on the monitor), but since we started at +15mm and are now at +8, and we've gone quite a ways, I'm not sure that we really want to go all the way to 0.  Anyhow, MC1 and MC3 are the ones which define our input pointing, so we're quitting for tonight.

We will turn on the PZTs and begin with the official vent list for dummies tomorrow.

Attachment 1: Screenshot-Figure_1.png
Screenshot-Figure_1.png
  7702   Tue Nov 13 00:28:10 2012 AyakaUpdateIOOMC locked, spots centered

[Rana, Ayaka, Jenne]

We aligned the REFL beam to the center of PD.
Also we removed the small black parts from mirror holder so that the beam is not clipped. They are originally for holding the mirror, but the mirror should be held by the small screw on the side of the mirror mount. This screw was hidden by the label, so we moved the label on the right hand side of the mirror mount (See a picture below).  
DSC_4902.JPG

Also we removed the half-wave plates and PBS so that laser power is increased.
DSC_4904.JPG

Then I aligned the beam for PMC, locked MC, and centered the beam spots.

 spot1112.png

The MC2 pitch is a little bit high but still close enough to the center.

Jenne had also centered the beam spots on QPDs for WFS.

  3791   Wed Oct 27 02:26:15 2010 kiwamuUpdateIOOMC locked

(Rana, Koji, Suresh, Yuta, Thanh, Kiwamu)

 MC was locked successfully !

 Instead of feeding back the signal to the MC length we just injected it to the NPRO pzt with a high voltage (HV) amplifier.

So now we can move on to an in-vac work which needs the main beam to align the stuff.

 


(mode matching to MC)

Suresh and Thanh (a visitor from ANU) improved the mode matching to the MC. 

As written in the entry #3779  the beam after the mode matching lenses were diverging.

It is supposed to converge from 1.7mm radius at the last lens to 1.6 mm radius at the middle point of MC1 and MC2.

They slided the last lens toward the MC to make it more collimated and roughly measured the beam size using a sensor card.

As a fine tuning, they looked at some higher order modes showing up in the MC2 camera, and tried reducing the higher order modes by slightly sliding the last lens.

(assuming the lens position doesn't so much change the alignment)

During the work we removed a steering mirror for green locking because it was on the way of the lens slider.

 

- - measured optics' distances - - 

25.5 cm  from 1st lens to the front surface of the EOM

5.5 cm  length of the EOM

24.5 cm from the front surface of the EOM to the 2nd lens (concave)

15.5 cm  from the 2nd lens to the 1st steering mirror in the zig-zag path

20.5 cm  from the steering mirror to the last lens

 

(preparation for locking) 

Rana, Yuta and Koji prepared an old instant amplifier which can produce +/-13V output instead of usual SR560s.

We added an offset (~5V) on the signal to make it within 0-10V which is the input range of the HV amplifier.

If we take SR560, it's probably not sufficiently wide range because they can handle handle only about +/-4V.

 

We strung a cable from Marconi via the RF stabilizer to the wideband EOM in order to drive the EOM at 24.5MHz.

SInce the EOM doesn't have 50 Ohm input impedance we had to put a 50 Ohm load just before the EOM in order to drive it efficiently.

From a medm screen we set the driving RF amplitude slider (C1:IOO_MCRF_AMPADJ) to 0.0, which provides the maximum RF power on it.

 

(locking mode cleaner)

At first we unlocked the PMC to see an offset in the error signal without any lights on the MC_REFL PD.

Then we adjusted the offset to zero on the MC servo screen.

At the beginning of the locking the PMC was not stable for some reasons during the MC was locked.

But after increasing the laser power to the MC twice bigger, it looks like the PMC and the MC are quite stable.

 

 

  757   Tue Jul 29 18:15:36 2008 robUpdateIOOMC locked

I used the SUS DRIFT MON screen to return the MC suspensions to near their pre-quake values. This required fairly large steps in the angle biases. Once I returned to the printed values on the DRIFT screen (from 3/08), I could see HOM flashes in the MC. It was then pretty easy to get back to a good alignment and get the MC locked.
  1633   Sat May 30 12:03:34 2009 robUpdatePSLMC locked

I locked to PSL loops, then tweaked the alignment of the MC to get it to lock. 

I first steering MC1 until all the McWFS quads were saturated.  This got the MC locking in a 01 mode.  So I steered MC1 a little more till it was 00.  Then I steered MC2 to increase the power a little bit.  After that, I just enabled the MC autolocker.

  5939   Fri Nov 18 01:27:04 2011 DenUpdateIOOMC locked

[Mirko, Den]

While the MC was unlocked (and the local damping off) we've measured the coherence between GUR1_X and OSEM sensors. It was rather high, close to 1 at frequencies 0.1 - 1 Hz. That means that stack does not kill all coherence between seismic noise and mirror motion.

Then we've turned on the local damping and measured the coherence again between GUR1_X and OSEM sensors. It decreased due to some noise and was on the level of ~0.5. We did reduced the motion between the mirror and the frame by local damping but it is not obvious that we lost some coherence due to this effect. Probably, actuator adds some noise.

When we locked the MC, we did not see any coherence at 0.1 - 1 Hz between GUR1_X or STS1_X and OSEM sensors of MC1 and MC3 but we did see with MC2. The MC1 sensor was fixed by Suresh.

 

Attachment 1: cohnolocalpumping-crop_4.pdf
cohnolocalpumping-crop_4.pdf
Attachment 2: cohlocalpumping4-crop.pdf
cohlocalpumping4-crop.pdf
Attachment 3: cohlock4-crop.pdf
cohlock4-crop.pdf
  8142   Sat Feb 23 00:36:52 2013 ManasaSummaryLockingMC locked

[Yuta, Manasa, Sendhil, Rana]

With MC REFL PD fixed, we aligned MC in high power enabling a fully functional MC autolocker.
We then unlocked MC and aligned the PD and WFS QPDs. Also we checked the MC demodulator and found a ~20% leakage between the Q-phase and I-phase. This must be fixed later by changing the cable length.

We adjusted MC offsets using /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets.
We then measured the MC spot positions using  /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter
Spot positions seem to have shifted by 2mm in yaw.

We will proceed with aligning the arms now.

Attachment 1: MCdecenter_23Feb2013.png
MCdecenter_23Feb2013.png
  14793   Sun Jul 21 20:23:35 2019 ranaUpdateIOOMC locked

I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.

  14797   Mon Jul 22 13:26:41 2019 KruthiUpdateIOOMC locked

The MC2 has 2 GigE cameras right now. I'll put back the analog asap.

Quote:

I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.

  1428   Wed Mar 25 17:22:58 2009 YoichiUpdateIOOMC lock without FSS
I made 40k:4k passive filter in a POMONA box and connected it to IN1 (not TEST IN1) of the FSS box.
With this modification and cut-and-tries with the gain sliders, I was able to lock the MC with 80kHz bandwidth by feeding back directory to the laser frequency.
The attached figure shows the open loop transfer function.
The phase margin is thin at 80kHz. Because of this, I could not turn on the MC super boost filters.
But I believe that we can increase the gain further by modifying the filter shape.

I used the following settings:
[MC Board]
C1:IOO-MC_REFL_GAIN 14
C1:IOO-MC_REFL_OFFSET -4.2381
C1:IOO-MC_BOOST1 0   (You can turn it on if you want, but turn it off for locking)
C1:IOO-MC_BOOST2 0
C1:IOO-MC_POL 1   (Minus)
C1:IOO-MC_VCO_GAIN 4
C1:IOO-MC_LIMITER 1 (Disable)

[FSS box]
C1:PSL-FSS_SW1 0 (Test1 ON)
C1:PSL-FSS_INOFFSET 0.1467
C1:PSL-FSS_MGAIN 30
C1:PSL-FSS_FASTGAIN 14 (Do not increase it, at least while locking. Otherwise the phase lag from the PZT loop gets significant and the MC loop will be conditionally stable).
I also turned down the FSS slow servo's RC transmission threshold to zero so that the slow servo works even without the RC locked.
Attachment 1: MC-loop-gain.png
MC-loop-gain.png
  5551   Mon Sep 26 20:04:03 2011 KojiUpdatePSLMC lock has been recovered

[Kiwamu Suresh Koji]

Some main parameters of the PSL has been recovered using Dataviewer and some screen snapshots, as seen in the screenshots below.

Attachment 1: snapshot1.png
snapshot1.png
Attachment 2: snapshot2.png
snapshot2.png
Attachment 3: snapshot3.png
snapshot3.png
  12878   Thu Mar 9 20:38:19 2017 ranaConfigurationIOOMC lock acquisition settings changed; no more HOM locks

The MC was sort of misaligned. It was locking on some vertical HOMs. So I locked it and aligned the suspensions to the input beam (not great; we should really align the input beam to the centered spots on the MC mirrors).

With the HOMs reduced I looked at the MC servo board gains which Guatam has been fiddling with. It seems that since the Mod Depth change we're getting a lot more HOM locks. You can recognize this by seeing the longish stretches on the strip tool where FSS-FAST is going rail-to-rail at 0.03 Hz for many minutes. This is where the MC is locked on a HOM, but the autolocker still thinks its unlocked and so is driving the MC2 position at 0.03 Hz to find the TEM00 mode.

I lowered the input gain and the VCO gain in the mcdown script and now it very rarely locks on a HOM. The UGF in this state is ~3-4 kHz (I estimate), so its just enough to lock, but no more. I tested it by intentionally unlocking ~15 times. It seems robust. It still ramps up to a UGF of ~150 kHz as always. 'mcdown' commited to SVN.

  16222   Wed Jun 23 09:05:02 2021 AnchalUpdateSUSMC lock acquired back again

MC was unable to acquire lock because the WFS offsets were cleared to zero at some point and because of that MC was very misaligned to be able to catch back lock. In such cases, one wants the WFS to start accumulating offsets as soon as minimal lock is attained so that the mode cleaner can be automatically aligned. So I did following that worked:

  • Made the C1:IOO-WFS_TRIG_WAIT_TIME (delay in WFS trigger) from 3s to 0s.
  • Reduced C1:IOO-WFS_TRIGGER_THRESH_ON (Switchin on threshold) from 5000 to 1000.
  • Then as soon as a TEM00 was locked with poor efficiency, the WFS loops started aligning the optics to bring it back to lock.
  • After robust lock has been acquired, I restored the two settings I changed above.
Quote:

 


At the end, since MC has trouble catching lock after opening PSL shutter, I tried running burt restore the ioo to 2021/Jun/17/06:19/c1iooepics.snap but the problem persists

 

  16223   Thu Jun 24 16:40:37 2021 KojiUpdateSUSMC lock acquired back again

[Koji, Anchal]

The issue of the PD output was that the PD whitened outputs of the sat amp (D080276) are differential, while the successive circuit (D000210 PD whitening unit) has the single-ended inputs. This means that the neg outputs (D080276 U2) have always been shorted to GND with no output R. This forced AD8672 to work hard at the output current limit. Maybe there was a heat problem due to this current saturation as Anchal reported that the unit came back sane after some power-cycling or opening the lid. But the heat issue and the forced differential voltage to the input stage of the chip eventually cause it to fail, I believe.

Anchal came up with the brilliant idea to bypass this issue. The sat amp box has the PD mon channels which are single-ended. We simply shifted the output cables to the mon connectors. The MC1 sus was nicely damped and the IMC was locked as usual. Anchal will keep checking if the circuit will keep working for a few days.

Attachment 1: P_20210624_163641_1.jpg
P_20210624_163641_1.jpg
  752   Tue Jul 29 01:03:17 2008 robConfigurationIOOMC length measurement
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method. We used c1omc DAC outputs to inject a signal (at 2023Hz) into the AO path of the mode cleaner and another at DC into the EXT MOD input of the 166MHz IFR2023A. We then moved an offset slider to change the 166MHz modulation frequency until we could not see the 2023Hz excitation in a single-bounce REFL166. This technique could actually be taken a step further if we were really cool--we could actually demodulate the signal at 2023Hz and look for a zero crossing rather than just a powerspec minimum. In any case, we set the frequency on the Marconi by looking at the frequency counter when the Marconi setting+EXT MOD input were correct, then changed the Marconi frequency to be within a couple of Hz of that reading after removing the EXT MOD input. We then did some arithmetic to set the other Marconis.

The new f2 frequency is:

New              OLD
--------------------------
165983145        165977195

  753   Tue Jul 29 09:12:43 2008 KojiConfigurationIOOMC length measurement
I found that the prev modulation freq had been determined with a same kind of measurement by Osamu, which also looked accurate.
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/12/2002&anchor_to_scroll_to=2002:09:12:17:10:30-ajw

(There is also a document by Dennis to note about this measurement
http://www.ligo.caltech.edu/docs/T/T020147-00.pdf )

So, it means that the round trip length of the MC shortened by 1mm in the 6 years.
New              OLD
--------------------------
27.0924          27.0934    [m]

Quote:
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method.
....
The new f2 frequency is:
New              OLD
--------------------------
165983145        165977195
  1664   Wed Jun 10 01:52:34 2009 AlbertoUpdateElectronicsMC length and Marconis' frequencies

Pete, Rob, Alberto,

yesterday we thought that some of the problems we were having in locking the IFO might be related to a change of the length of the mode cleaner. So today we decided to measure it again.

We followed the Sigg-Frolov technique (see 40m Wiki, Waldman, Fricke). For the record, the MC_AO input corresponds to IN2 on the MC Servo board.

We obtained: L = 27.092 +/- 0.001 m

From the new measurement we reset the frequencies of the Marconis to the following values:

33196450 Hz

132785800 Hz

165982250 Hz

199178700 Hz

 

  952   Wed Sep 17 12:55:28 2008 robConfigurationIOOMC length
I measured the mode cleaner length last night:

SR620                Marconi
                     199178070
165981524            165981725
                     132785380
                      33196345


I did the division in Marconi-land, rather than SR620-land.
If someone wants to do this in SR620-land, feel free to do it and post the numbers.
  3383   Sat Aug 7 11:07:44 2010 KojiConfigurationPSLMC kept locked / PMC control gain reduced to +13dB

Jenne asked us to keep th MC locked and let the seismometers happy through this weekend.
Note that the work at the control room and the desks are no problem as far as you are quiet.

Nancy told Jenne and me that she finished the work and reverted the WFS to the old state at 4:30AM.
She could not make the elog as it has been crashed.

MC and old MC WFS looks working as usual.

From 6:40AM to 9:40AM the oscillation of the PMC looks present.

At 10:30AM I reduced the gain of the PMC from +15dB to +13dB.

  3350   Mon Aug 2 21:52:57 2010 KojiUpdateIOOMC is running at the full power

[Nancy and Koji]

We restored the full power operation of the MC.

Restoration of the suspensions

  1. Found the suspension watch dogs are left turned off.
  2. Found c1susvme1/2 were not running.
  3. Launched the realtime processes on c1susvme1/2 and c1iscey
  4. Restored the watch dogs. The suspensions looked fine.

Preparations for the high power

  1. Put an ND2.0 before the MCT CCD. Confirmed the ND reflection is damped.
    MCT QPD is not necessary to be touched.

The high power operation of the MC / post lock adjustment

  1. Locked the MC under the autolocker being disabled.
  2. Adjusted the aperture on the MC2 face camera
  3. Adjusted the spot positions on the WFS QPDs
  4. Reverted the scripts to the high power ones
    (mcup / mcdown / autolockMCmain40m)
  5. Logged in to op340m and restarted autolockMCmain40m

The autolocker seems working correctly.

  920   Thu Sep 4 07:46:10 2008 YoichiUpdateIOOMC is now happy
The MC has been locked for more than 12 hours continuously now !
Changes I made yesterday were:
(1) Removed the 20dB attenuator before the EOM.
(2) Reduced the Fast Gain from 21dB to 16dB, which made the PC to be a little bit more loaded (~0.6Vrms).

As Rana pointed out in the meeting, setting the Fast Gain a bit lower may have put the FSS in a stabler state.
Attachment 1: MC-lock.png
MC-lock.png
  3779   Mon Oct 25 23:10:06 2010 KojiUpdateIOOMC is now flashing

[Suresh / Koji]

The MC mirrors are aligned. Now the flashing of the resonances are visible on the MC2 CCD

although the modematching seemed pretty poor.


- The incident power was adjusted to be ~20mW by rotating HWP after the laser source.
The power before the window of the chamber was ~450mW. Where are those missing 1.5W?

- We checked the spot on the last two steering mirrors and the incident beam on MC1.
The beam was too much off from the center of the 1st steering mirror. It was also hitting 1cm north of the MC1.
We adjusted the steering mirrors such that the incident and reflected beams are symmetrically visible at the MC1 tower.

- The MC mirrors are aligned. We first tried to use only MC2 and MC3. And then we used MC1 too as the spot on the MC2 was too high.

- We saw some TEM00 flashes but with many other modes flashing. We checked the beam diameter on the PSL table and on the MC REFL.
The latter one looked twice large as the former one. We concluded the beam is diverging.

- We closed the tank and decided to work on the mode matching tomorrow.

  11739   Mon Nov 9 09:27:44 2015 SteveUpdatePSLMC is not happy

I just turned off the PSL enclousure lights.
 

Attachment 1: ioo8d.png
ioo8d.png
  5115   Thu Aug 4 01:49:08 2011 SureshUpdateIOOMC is locked

I measured the power transmitted from the PSL to the MC. It is 19mW.

The MC is now locked.  The MC Autolocker script cannot be used now since the tigger conditions are not met.  It has been disabled on the C1IOO-LOCK_MC screen.  The boost switch also is set to zero.  Increasing the boost results in MC unlocking. 

The C1:IOO-MC_RFPC_DCMON was going from 1.4 (MC Unlocked) to 0.66 (MC_locked).  I thought we ought to have a factor of ten drop in this since under high power conditions we used to have a drop of about 5.6 to 0.6.   So I adjusted the zig-zag at the end of the PSL table to improve the alignment.  It now goes from 1.4 to 0.13 when the MC is locked.   The lock is also much more stable now.  It still does not tolerate any boost though.

I checked to make sure that the beam centering on MC_REFL PD is optimal since I touched the zig-zag.  The RFPD output is now 0.7V (MC unlocked).  This matches well with the fact that we used to have 3.5V on it with the MC unlocked.  And we have cut the down the power incident on this by a factor of 5.  Because 1W -> 20mW at the PSL table  and 10% BS -> 100% Y1-...

 

 

  6292   Fri Feb 17 01:02:22 2012 kiwamuUpdateIOOMC is back to normal

[Koji / Kiwamu]

 The MC is now back to normal. The beam pointing to the interferometer is good.

There were two different issues :

  • A mechanical mount was in the MC WFS path.
  • There were some loose connections in the SUS rack

 

Slid have we the position of the mechanical mount. Nicely the WFS beam go through now.

And also I pushed all the connectors associated with the MC SUS OSEMs in the SUS rack.

After pushing the connectors, the MC1 OSEM readouts dramatically changed, which actually more confused us.

As shown in the 3 hours trend below, the OSEM readouts have changed a lot (shown in the middle of the plot with arrows). Some bumps after the steps correspond to our alignment efforts.

MCconnections.png

Quote from #6291

The MC became crazy again.

 

  5367   Thu Sep 8 20:13:24 2011 kiwamuUpdateIOOMC is back to full power

[Suresh / Kiwamu]

 The attenuator was removed and now the MC is happily locked with the full power of 1.2 W.

 

(what we did)

 + replaced the perfect reflector, which was before the MCREFL_PD, by a 10% beam splitter like it used to be.

 + removed the attenuator (combination of HWP and PBS).

 + realigned the beam path on the AP table, including the MCREFL path and WFS path.

 + made the aperture of the MC2F camera narrower in order to avoid a saturation.

 + aligned the MC suspensions so that it resonates with the TEM00 mode.

 + put a ND filter on the AS camera

 

(notes)

C1:IOO-MC_RFPD_DCMON = 0.98 (locked)

C1:IOO-MC_TRANS_SUM = 17500 (locekd)

 

(next things to do)

 + measurement of the spot positions on each MC mirror.

 + centering of the beam spot by steering the input mirrors on the PSL table

  5725   Fri Oct 21 16:06:12 2011 SureshUpdateComputer Scripts / ProgramsMC input matrices empty again

The MC suspensions were not damping and the reason was traced to the empty imput matrices in the suspension controls.  This has been an issue in the past as well when the sus machine is rebooted some of the burt restore does not populate these matrices.

I ran the burtgooey and restored c1mcs.snap file.  from a couple of hours ago.

 

 

  2899   Sat May 8 02:38:08 2010 KojiSummaryIOOMC incident power

As per Steve's request I checked the MC incident power as a function of time.

The output is negative: the lower voltage, the higher power.

Before I put the attenuator the incident power was 1.1W. It appear as -5V.

Now the output is -0.1V. This corresponds to 22mW.

 

Attachment 1: MC_input.png
MC_input.png
  2643   Fri Feb 26 11:48:36 2010 KojiUpdateGeneralMC incident beam shift

Last night I worked on the MC incident beam such that we can hit the center of the MC mirrors.

Steve and I checked the incident beam on MC1. We found the beam is ~5mm south.
This was not too critical but it is better to be realigned. I moved the steering mirror on the OMC
table (in vac). We kept the MC resonated. After the maximization of the resonance, I realigned the
MC1 and MC3 such that the resonance in dominated by TEM00.

Jenne, Kiwamu, and I then closed the light door on to the OMC/IMC.

I will make more detailed entry with photos in order to explain what and how I did.

  6910   Tue Jul 3 20:51:06 2012 yutaUpdateIOOMC in vacuum is back

MC came back to the state as it was before the vent.

What I did:
  1. Removed beam attenuating setup on PSL table(see elog #6892).

  2. Removed 100% reflection mirror before the MC reflection PD and put 10% BS back, so that we can have MC WFS. Also, I changed C1:IOO-MC_RFPD_DCMON.HOPR to 5.

  3. Removed autolockMCmain40m_low_power from crontab on op340m, and put autolockMCmain40m again.

  4. Aligned MC and ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to adjust WFS offsets.

  5. Measured beam spot positions. They looked same as before the vent.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent
./dataMCdecenter/MCdecenter201207032009.dat    3.737099    3.994597    3.087857    -6.442053    -0.992543    4.714607    after pumping (now)

  6. I also turned on high voltage power supplies for input and output PZTs

  7. Below is captured Sensoray images of the current state.
ALL_1025408289.bmp


Next:
  I will go on to check if IFO works as it was before or not, but I think we should center MC beam spot positions and see if we can avoid clipping in the near future.

  6899   Sun Jul 1 13:20:09 2012 yutaUpdateIOOMC in low power

I modified autolocker for MC in low power mode (/opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m_low_power) to make it work with the current directory structure.
autolockMCmain40m_low_power currently runs on op340m and it is in crontab.

34 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m_low_power >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1


MC intra-cavity power:
  Currently, incident beam to the MC measured at PSL table is ~15 mW. Reflected power from MC (C1:IOO-MC_RFPD_DCMON) is 0.94 when MC unlocked, and is 0.088 when locked.
  That means, considering MC1/3 power transmission is 2000ppm (calculated finnesse=1570), intra-cavity power in MC is ~7 W.

  15 mW * (0.94-0.088)/0.94 / 2000ppm = 7 W

  We can increase the power by factor of ~2, if needed.


MC beam spot positions:

  I aligned MC to maximize transmission (C1:IOO-MC_TRANS_SUM_ERR), and measured the MC beam spot posisions in atm, low power.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent

  They look the same within the error of the measurement, except for the spot positions on MC2, which we don't care.


Autolocker should be refined:
  To make autolockMCmain40m_low_power, I copied autolockMCmain40m and just changed

- lockthresh from 500 to 100
- use mcdown_low_power instead of mcdown
- use mcup_low_power instead of mcup

  The difference between mcdown_low_power and mcdown should be only

- ezcawrite C1:IOO-MC_REFL_GAIN 31 for lowpower, 9 for usual
- ezcawrite C1:IOO-MC_VCO_GAIN 10 for lowpower, -5 for usual

  The difference between mcup_low_power and mcup should be only

- ezcawrite C1:IOO-MC_REFL_GAIN 31 for lowpower, 12 for usual
- ezcawrite C1:IOO-MC_VCO_GAIN 31 for lowpower, 25 for usual

  Currently, they are not like that. Somebody good at shell scripts should combine them and make it into one code with an option something like usual/low-power.

  1435   Fri Mar 27 02:40:06 2009 peteSummaryIOOMC glitch investigation

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils. 
We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board. 
We suspect either the UL or LR coil bias circuits (Pete would bet on UL).  If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).  
These bumps do not show up in the VMONS which is why we are suspicious of the bias.
To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils. 
 

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil      C1:IOO-MC_DRUM1  (Caryn was using, we will replace when we are done)

UL input   C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

Attachment 1: MC1_Drift.png
MC1_Drift.png
  1437   Fri Mar 27 15:05:42 2009 YoichiUpdateIOOMC glitch investigation
Attached plots are the result of the MC1 trend measurement.
See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.
From the VMon channels, you can see that the control voltages were quiet.
 
The monitor channels we added were:
 
MC_TMP1 = UL coil bias. Input to the coil driver board.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = LR coil bias. Input to the coil driver board.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.
 
The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).
There is no correlation between the OSEM signals and the bias voltages.
 
Since we were only monitoring UL and LR coils, I changed the monitor points as follows.
 
MC_TMP1 = LL coil bias. Output of the current buffer.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = UR coil bias. Output of the current buffer.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
I will leave the MC unlocked for a while.

Quote:

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils. 
We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board. 
We suspect either the UL or LR coil bias circuits (Pete would bet on UL).  If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).  
These bumps do not show up in the VMONS which is why we are suspicious of the bias.
To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils. 
 

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil      C1:IOO-MC_DRUM1  (Caryn was using, we will replace when we are done)

UL input   C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

 

Attachment 1: MC1_Drift.pdf
MC1_Drift.pdf
Attachment 2: MC2_Drift.pdf
MC2_Drift.pdf
  1438   Fri Mar 27 17:52:16 2009 YoichiUpdateIOOMC glitch investigation
Per Rob's suggestion, I put the probes across the output resistors of the bias current buffers instead of measuring the output voltage with respect to the ground.
This way, we can measure the current flowing the resistor. The change was made around 17:30.

Quote:
Attached plots are the result of the MC1 trend measurement.
See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.
From the VMon channels, you can see that the control voltages were quiet.
 
The monitor channels we added were:
 
MC_TMP1 = UL coil bias. Input to the coil driver board.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = LR coil bias. Input to the coil driver board.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.
 
The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).
There is no correlation between the OSEM signals and the bias voltages.
 
Since we were only monitoring UL and LR coils, I changed the monitor points as follows.
 
MC_TMP1 = LL coil bias. Output of the current buffer.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = UR coil bias. Output of the current buffer.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
I will leave the MC unlocked for a while.

 

 

 

  1081   Fri Oct 24 10:06:16 2008 YoichiConfigurationIOOMC gain and FSS gain changed
Following the measurements of MC and FSS loop gains, I modified mcup script to set the MC VCO gain to 2dB (it was -4dB before).
I also changed the normal value of the FSS common gain to 7dB. The open loop transfer functions posted in the previous two entries
were measured with those settings.
  4145   Wed Jan 12 22:19:54 2011 KojiUpdateIOOMC flakiness solved

[Koji Suresh Kiwamu]

Suresh modified the MC board to have +5V offset at the output. (To be reported in the separated elog)

The MC lock has not been obtained at this point. An investigation revealed that there was very small (~5mVpp) PDH signal.

Kiwamu removed his triple resonant adapter and put the 50Ohm termination insted.
This restored the signal level normal although this changed the demodulation phase about 20deg.
We left the demodulation phase as it is because this is a temporary setup and the loss of the signal is not significant.

Now the MC is steadily locked with the single super boost.

  8575   Tue May 14 20:30:29 2013 JamieSummaryIOOMC error spectrum at various FSS gain settings.

I used the Agilent 4395A and the GPIB network bridge to measure the MC error spectrum at the MC servo board.

I looked at various settings of the FSS Common and FAST gains.

Here is the spectrum of various Common gain settings, with a fixed FAST setting of 23.5:

f23.5.pdf

The peak at 34k is smallest at the largest Common gain setting of 13.0 (probably expected).  The other higher frequency peaks are higher, though, such as the ones at 24.7k, 29.6k, 34.5k, etc.:

f23.5z1.pdf

Here's a blow up of the peak at 1.06M, which peaks at about 9dB of common gain:

f23.5z2.pdf

 Here's the spectrum with a fixed Common gain of 10.5, and various FAST gains:

c10.5.pdf

and here's a zoom around that 1.06 MHz peak, which is smallest at a FAST gain of 23.5 dB:

c10.5z1.pdf

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

If this does turn out to be a good setting we'll need to adjust some of the alarm levels.

Various settings:

MCS
  in1 gain: 15
  offset: 1.174
  boost enabled
  super boost: 2
  VCO gain: 25

FSS:
  input offset: -0.8537
  slow actuator: 0.6304

I include the python scripts I used to remotely control the AG4395 to take the measurements, and make the plots.

PS: I made some changes/improvements to the netgpib stuff that I'll cleanup and commit tomorrow.

 

Attachment 6: getdata
#!/usr/bin/env python

import os
import sys
import time
import numpy as np
sys.path.append('/opt/rtcds/caltech/c1/scripts/pylibs/')
import pyezcalib as ca
sys.path.append('/opt/rtcds/caltech/c1/scripts/general/netgpibdata/')
import netgpib
... 64 more lines ...
Attachment 7: plot
#!/usr/bin/env python

import os
#import numpy as np
from pylab import *

#name = sys.argv[1]

#atten = 10 # 10dB

... 31 more lines ...
  10784   Thu Dec 11 18:00:43 2014 ericqUpdateComputer Scripts / ProgramsMC error signal monitoring

The other day, I hooked up the agilent analyzer to OUT2 of the MC board, which is currently set to output the MC refl error signal.  I've written a GPIB-based program that continuously polls the analyzer, and plots the live spectrum, an exponentially weighted running mean, and the first measured spectrum. 

The intended use case is to see if the FSS or MC loops are going crazy when we're locking. Sometimes the GPIB interface hangs/loses its connection, and the script needs a restart.

The script lives in scripts/MC/MCerrmon

 

 

  13696   Wed Mar 21 15:52:45 2018 gautamUpdateIOOMC error point calibration

As discussed at the meeting, I decided to calibrate the MC error point into physical units of Hz/rtHz (a.k.a. the PDH discriminant). This is to facilitate the debugging of the hypothesized excess IMC sensing noise. I did this as follows.

  1. Trust the POX calibration that was last updated in Aug 2017.
  2. Hook up spare DAC channel (piped from LSC rack to 1X2) to IN2 of IMC CM board.
  3. Inject excitation into MC error point via "IN2" input of the common board. For an excitation of 30cts with the IN2 gain at -32dB, I was able to see a peak in the calibrated X arm control signal that was ~x10 above the nominal noise level around 150Hz without seeing any nonlinear coupling effects in the DTT spectrum (I'm assuming 150Hz is sufficiently above the UGF of the X arm locking loop such that no loop correction is necessary).
  4. Took a spectrum of the IMC error signal, teed off into the SR785 at the I output of the demod board with the same linewidth as the DTT spectrum.
  5. Confirmed that without any excitation,
  6. Did the math to make these two peaks line up. The resulting calibration is: 13kHz/Vrms.

Math details:

  • DTT peak height @ 150 Hz with Hanning window, 25 avgs = 1.97e-4 nm/rtHz (See Attachment #1).
  • X arm cavity length = 37.79m, using which the above number becomes 1.47 Hz/rtHz.
  • Peak height in SR785 spectrum with Hanning window, 25 avgs = 1.13e-4 Vrms/rtHz (See Attachment #2).
  • Dividing, we get 13kHz/Vrms.

Using this, I can now make up a noise budget of sorts for the IMC sensing.


gautam 20180327 4.30pm: I re-checked the PDH error signal calibration using the oscilloscope method. Attachment #3 shows the PDH I and Q error signals and also the output of the RF monitor port, during a TEM00 flash. This attachment should be compared to Attachment #2 of elog 12822, and the answer lines up quite well. From my Finesse model of the IMC, I calculated that the x-axis of the PDH horn-to-horn is ~12.3kHz. Comparing to the top row of Attachment #3, I get a PDH error signal calibration of ~12.4kHz/Vrms, which lines up well with the number quoted above. So I trust my calibration, and hence, the y-axis of my noise budgets in reply to this elog.

Attachment 1: IMC_PDHdisc_20180321.pdf
IMC_PDHdisc_20180321.pdf
Attachment 2: IMC_PDHdisc785_20180321.pdf
IMC_PDHdisc785_20180321.pdf
Attachment 3: IMC_oscope.pdf
IMC_oscope.pdf
ELOG V3.1.3-