40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 166 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  1451   Wed Apr 1 23:18:07 2009 rana, kojiSummaryIOONo Reference Cavity Required
Koji sent us a note about our "No Reference Cavity Required" entry. I thought that it nicely summarizes the
whole shebang and so I post it here for its pedagogical value.

Generally, frequency stabilization is a comparison of the two
frequency references.

1. In the conventional case you are comparing the NPRO stability with
the RC stability. The NPRO cavity is short and probably placed in a
less stable environment than that of the RC. Therefore, the PDH
signal only feels the frequency fluctuation of the NPRO, resulting
in the laser PZT fast feedback dominated by the NPRO stability. As
the MC length at low frequency is controlled by the mass feedback,
the resulting laser stability through the MC is virtually limited
by the RC stability.

2. On the other hand, you are comparing the stabilities of the NPRO
crystal and the MC cavity in the direct control configuration. The
stability of the MC at high frequency is better than that of the
NPRO. It is opposite at low frequency, of course, because of the
pendulum motion. The resulting laser stability through the MC is
limited by the MC stability.

3. In the CM servo, the length of the MC is stabilized such that the
arm stability is duplicated to the MC. As a result, your MC servo
compares the stability between the NPRO and the arm cavity. Again
at around 1Hz, the arm cavity is noisier than the NPRO. (This is
true at least TAMA case. I am quite unsure about it in the LIGO
long arm cases.)

One useful consequence is that in those configurations, the laser PZT
feedback at around 1Hz represents the stability of the NPRO, the MC,
and (possibly) the arm cavity, respectively. It was clearly seen
Yoichi's e-log entry 1432. At TAMA we call this signal as "MCPZTfb"
and use this for the diagnostic purposes of the suspended cavities. As
the laser fast PZT is rarely replaced and considered as a stable
actuator, this signal is considered as a good reference at low
frequency which is consistent across various configurations
(e.g. before/after replacement of the suspensions etc). Once the
response and the coefficient are calibrated you can easily convert
this signal to the length displacement.

Another remark: In the direct configuration, the frequency stability
of the beam goes through the MC is determined by the MC stablity. It
means that the beam to the arm has essentially worse stability than
the arm stability by factor of L_arm/L_MC. In the 40m case this factor
is just 3 or so. This is ok. However, for the LIGO 4km arm, the factor
becomes something like 300. This means that if you have 1um_rms of the
MC length fluctuation, the arm PDH feels 300um_rms. (Maybe some extent
less because of the common mode rejection of the MC suspensions.)

Yes, the actuator to the MC length is very strong this time, and
should be able to stop this amount of fluctuation easily... if the
things are all linear. I am not certain whether you can acquire the
lock even by this strong actuator when the arm is crazily swinging,
the PDH signals are ringing all the way, etc, etc...Particularly in
the recycling case!

One possible remedy is a technique developed by the German
necromancers, as always. They used the NPRO cavity as a reference
cavity. They actuate the MC length at low frequency. But I don't know
the exact configuration and how they accomplished the CM hand-off. We
have to ask Hartmut.

The other possibility is your adaptive stabilization of the MC by the
FIR technique. So far I don't know how much stability you can improve
in the LIGO 4km case.

There would be many possibilities like feedforward injection from the
green arm locking signal to the MC length, etc, etc.
  1503   Mon Apr 20 20:00:44 2009 ranaConfigurationIOOMcWFS gains re-allocated
Since it looks like the night time people have been running with a WFS gain of 0.05 and I like the slider
to be at 1.0, I lowered all of the WFS1/2_P/Y gains by 10 and increased the overall slider from 0.05 to 1.0.
So the loop gains are now 2x higher; with it like this I guess the UGFs are in the ~0.2-0.5 Hz range.
  1607   Tue May 19 15:57:07 2009 steveUpdateIOOMC2 damping restored after EQ

  Earthquake mag 4.0 at Lennox, Ca     trips MC2 watchdogs       http://quake.usgs.gov/recenteqs/Quakes/ci10411545.html

See 40m accelerometers as they see it.

Attachment 1: acc.jpg
acc.jpg
  1768   Tue Jul 21 15:32:47 2009 JenneUpdateIOOMC_L flatlined

[Clara, Jenne]

While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined.  I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night.  Bootfest-type activities shall commence shortly.

  1770   Tue Jul 21 17:52:12 2009 JenneUpdateIOOMC_L flatlined

Quote:

[Clara, Jenne]

While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined.  I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night.  Bootfest-type activities shall commence shortly.

 Under Alberto's tutalage, I rebooted the whole vme set (iovme, sosvme, susvme1, susvme2), and after that MC_L was all good again.

  1795   Mon Jul 27 09:34:07 2009 steveSummaryIOOAligning the mode cleaner

Quote:

I set the MC back to its good alignment (June 21st) using this procedure. The trend of the OSEM values over the last 40 days and 40 nights is attached.

Then I aligned the periscope to that beam. This took some serious periscope knob action. Without WFS, the transmission went to 2.7 V and the reflection down to 0.6V.

Then I re-aligned the MC_REFL path as usual. The beam was far enough off that I had to also re-align onto the MC LSC PD as well as the MC REFL camera (~2 beam radii).

Beams are now close to their historical positions on Faraday and MC2. I then restored the PZT sliders to their April snapshot and the X-arm locked.

Steve - please recenter the iris which is on the periscope. It has been way off for a long time.

So it looks OK now. The main point here is that we can trust the MC OSEMs.

Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.

 

 I'm impressed by Rana's simple way to align the MC. IFO arms are locked or flashing. 20 days trend attached.

 

Attachment 1: 20dtrend.jpg
20dtrend.jpg
  1799   Mon Jul 27 19:55:19 2009 KojiHowToIOOLens selection: plano-convex? or bi-convex?

Q. When should we use plano-convex lenses, and when should we use bi-convex?

As I had the same question from Jenne and Dmass in a month,
I just like to introduce a good summary about it.
Lens selection guide (Newport)
http://www.newport.com/Lens-Selection-Guide/140908/1033/catalog.aspx

At a first order, they have the same function.
Abberation (= non-ideal behavior of the lens) is the matter.

  1812   Thu Jul 30 03:10:18 2009 robUpdateIOOMC tweaked further

I tilted the periscope beam and aligned the MC.  Now the spot at the Faraday entrance is near the center of the aperture in up/down space.  The arm powers are only going up to ~0.8, though.  Maybe we should try a little bit of left/right. 

I looked at the IP POS spot with a viewer card, and it looked round, so no obvious egregious clipping in the Faraday.  Someone might take a picture with one of the GigE camera and get us a beam profile there.

We no longer have an MC1 and MC3 camera view.

I can see a bright scatterer that can be seen from the east viewport of the BSC, but I can't tell what it is.  It could be a ghost beam. 

It would be nice to get an image looking into the north viewport of the IOO chamber.  I can't see in there because the BS oplev table is in the way. 

  1814   Thu Jul 30 21:26:16 2009 ranaUpdateIOOMC Drumhead mode
I used COMSOL 3.5a to do a FEA of one of the MC flat mirrors. Should be close to the same for all the mirrors.

The model is very simple- it includes just the cylindrical shape (no magnets, curvature, or coating or bevels).
This is good enough, since we don't really know all of the material properties at the 1% level.

The attached plot shows the MC drumhead mode. The color scale shows the displacement along the optic axis.
The model predicts 28.855 kHz and the measured value was 28.2 kHz.

I used COMSOL in the multiphysics mode which includes the Structural Mechanics and Heat Transfer modules at the
same time. For the material I used the built in properties of Corning 7940 (fused silica). In reality we have
7980 (I don't know all of the material differences). In any case, this model includes the temperature dependence
of the Young's modulus, so it should be possible to use this to predict the absorption numbers.

The model file (mc2.mph) has been added to our COMSOL SVN directory.
Attachment 1: mc2drum.png
mc2drum.png
  1820   Mon Aug 3 14:15:50 2009 JenneUpdateIOOWFS recentered

I am (was) able to get the mode cleaner mostly locked, but because WFS2 wasn't centered, the MC would drift, then lose lock.  I recentered both the WFS (after unlocking the MC and the MZ), and am now about to commence relocking both of those.

 

/end{quick update}

 

Note to self:  WFS get centered based on the direct reflection from MC1.  Once the MC is close enough, the WFS are enabled, and they twiddle all 3 MC mirrors to minimize their error signal.  Moral of the story: make sure the WFS are centered.

  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.

  1823   Mon Aug 3 22:54:53 2009 Jenne, Koji, ranaUpdateIOOMC_trans is now better, but not best

Jenne, Koji, Rana

After fixing up the Mode Cleaner a bit more (fiddling more with the MC_align sliders to get the alignment before locking, making sure that it is able to lock), we noticed that the MC Trans path could use some help. To align the MC, we put MC1 and MC3 back into the position where Rob left it on Thursday and then maximized the transmission with MC2. Then we went back and maximized with MC1/3 keeping in mind the Faraday. We got a good transmission and the X-arm had a transmission of 0.8 without us touching its alignment.

Upon looking at the AP table portion of the MC_trans path, we decided that it was all pretty bad.  The light travels around the edge of the AP table, then out the corner of the table toward the PSL table.  A periscope brings it down to the level of the PSL table, and then it travels through a few optics to the MC_trans QPD. 

The light was clipping on the way through the periscope, and so the MC_trans QPD was totally unreliable as a method of fine-tuning the alignment of the Mode Cleaner.  Ideally we'd like to be able to maximize MC_trans, and say that that's a good MC alignment, but that doesn't work when the beam is clipped.

 

Things done:

1. The first turning mirror on the AP table after the beam comes out of the vacuum was changed from a 1" optic to a 2" optic, because the spot size is ~4-6mm.  We were careful to avoid clipping the OMCT beam, by using a nifty U200 mount (C-shaped instead of ring-shaped). 

2.  We placed a lens with a RoC of 1m (focal length for 1064nm is ~2m), a 2" optic, between the first two mirrors, to help keep the beam small-ish when it gets to the periscope, to help avoid clipping.

3. Rana adjusted the angle of the upper periscope mirror, because even when the beam was centered on the steering mirror directly in front of the periscope and the spot was centered on the first periscope mirror, the beam wouldn't hit the bottom periscope mirror. 

4. We noticed that the bottom periscope mirror was mounted much too low.  It was mounted as if the optics after it were 3" high, which is true for all of the input optics on the PSL table.  However, for the MC_trans stuff, all the optics are 4".  We moved the periscope up one hole, which made it the correct height.

5. We removed the skinny beam tube which guided/protected the beam coming off the periscope after a steering mirror since it (a) wasn't necessary and (b) was clipping the beam. We cannot use such skinny tubes anymore Steve.

6. There was a lens just before the 2nd steering mirror on the PSL table portion, which we removed since we had placed the other lens earlier in the path.  2 lenses made the beam too skinny at the QPD.

7.  After this 2nd steering mirror, there had been a pickoff, to send a bit of beam at a crazy angle over to the RFAM mon, which we removed.  This results in a much brighter beam at the MC_trans QPD, and at the camera.  The QPDs readouts are now a factor of ~3.5 higher than they used to be.  These (especially the camera) could use some ND-filtering action.

8.  The steering optic directly in front of the MC_trans QPD is a beamsplitter, and instead of dumping the light which doesn't go to the MC_trans QPD, we used this to go over to the RFAM mon (instead of the pickoff which we had removed). 

9.  Koji fixed up the optics directly in front of the RFAM mon, accomodating the new position of the input light (now at a much more reasonable angle, and about 15cm farther back from the PD). Note the beam dump which is preventing the cables from the FSS board from entering the beam path. This included removing an ND filter wheel, so the RFAM mon values will all be higher now.  Koji also has the beam going to the PD going at a slight angle, so that the beam isn't directly reflected on itself, so that it can be dumped.

10. We aligned the beam onto the MC_trans QPD using the first steering mirror on the PSL table.

11. We also removed the giant wall of beam dumps separating the squeezing section of the table from the rest of the table.

Alberto will elog things about the RFAM mon, including different values of the PD output, etc.

 

Still on the to-do list:

A.  Replace the second steering mirror on the AP table after the MC_trans light leaves the vacuum with a 2" optic, since the lens we placed isn't tight enough to make the spot small there yet.  Us a U200A mount if possible, because they are really nice mounts.

B.  Put an ND filter in front of the MC_trans camera, because the image is too bright.

C.  Normalize the MC_trans QPD - the horz and vert are pretty much direct voltage readouts, with no normalization.  They should be divided by the DC value.  This lack of normalization results in higher sensitivity to input pointing.

D.  Long term, next time someone wants to optimize the MC_trans path, move all the optics, including the MC_trans QPD and the camera closer to the periscope on the PSL table.  There's no reason for the beam to be traveling nearly the full width of the PSL table when we're not manuvering around squeezing stuff.

E. Never, ever purchase these horrible U100 or U200 mounts with the full ring and the little plastic clips. They are the "AC28" version. Bad, bad, bad.

 

Image 1:  The new setup of the AP table, Mc_trans portion. 

Image 2:  New setup of the MC_trans part of the PSL table.

Attachment 1: P8030099_copy.JPG
P8030099_copy.JPG
Attachment 2: P8030102_copy.JPG
P8030102_copy.JPG
  1825   Tue Aug 4 11:54:20 2009 JenneUpdateIOOMC_trans readout on LOCK_MC screen now normalized

The MC_trans QPD Pitch and Yaw readout on the Lock_MC screen are now normalized by the trans_sum. I used the method described in my entry elog 1488

/caltech/target/c1iool0/ioo.db now includes:

grecord(calc, "C1:IOO-MC_TRANS_P")
{
        field(INPA, "C1:IOO-MC_TRANS_VERT")
        field(INPB, "C1:IOO-MC_TRANS_SUM")
        field(SCAN, ".1 second")
        field(PREC, "3")
        field(CALC, "A/B")
}

grecord(calc, "C1:IOO-MC_TRANS_Y")
{
        field(INPA, "C1:IOO-MC_TRANS_HOR")
        field(INPB, "C1:IOO-MC_TRANS_SUM")
        field(SCAN, ".1 second")
        field(PREC, "3")
        field(CALC, "A/B")
}

 

The Lock_MC screen was changed to show these new P and Y channels. 

  1895   Thu Aug 13 00:11:43 2009 JenneUpdateIOOMode Cleaner Unlock

So that I can collect a bit of free-swinging Mode Cleaner data, I started a script to wait 14400 seconds (4 hours), then unlock the mode cleaner.  It should unlock the MC around 4am.  As soon as someone gets in in the morning, you can relock it.  I should have plenty of data by then.

  1896   Thu Aug 13 02:17:56 2009 JenneUpdateIOOMode Cleaner Alignment

When Rob and I were getting started on locking for the evening, Mode Cleaner lost lock a few times, but every time it lost lock, it took forever to reaquire, and was pretty insistent on locking in the TEM10 mode.  I proposed that the alignment might be sketchy.  I've been fiddling with the MC alignment sliders for the last hour and a half or so, but I think I'm not 100% in tune with the 3 mirror parameter space.  The mode cleaner now locks, but I'm not in love with its' alignment.  The WFS are definitely catywhompus.  Before doing hardware things like recentering the WFS, I'm going to wait until tomorrow to consult with an alignment expert.

In case this is helpful for tomorrow, before I touched any of the sliders:

Optic, Pitch, Yaw

MC1, 3.1459, -0.7200

MC3, -0.8168, -3.0700

MC2, 3.6360, -1.0576

 

Now that mode cleaner locks, although not in a great alignment:

MC1, 3.1089, -0.7320

MC3, -0.7508, -3.0770

MC2, 3.6610, -1.0786

 

If I knew how to kill my script to unlock the mode cleaner, I would.  But I sourced it, and Rob didn't know earlier this evening how to kill something which is started with 'source' since it doesn't seem to get a process number like when you './'  to run a script. So the Mode Cleaner will probably be unlocked in the morning, and it may be persnickity to get it relocked, especially if the tree people are doing tree things with giant trucks again in the morning.

  1924   Tue Aug 18 15:16:15 2009 robUpdateIOOMC WFS working again

Rob, Yoichi

 

The MC WFS have apparently been bad for a few days, causing the MC alignment to drift away at DC.  We tried a few things to fix it, including jiggling some EPICS settings in the WFS head & demod screens.  This seemed to work for WFS1 but not WFS2.  Confused, we decided to go stare at the rack 1Y2.  While doing that, we noticed that the top two Sorensens in 1Y1 (these are directly below the Guralp box) were at different voltages from nominal.  The 5V had dropped to 4.2V and the 24V was at 24.6V.  We adjusted the knobs until these were set correctly.  After this, the MC WFS appear to work again.

 

When working in a rack, you must be as careful about accidentally touching things as when working on an optical table.

  1928   Wed Aug 19 17:11:33 2009 JenneUpdateIOOQPDs aligned

Quote:

 

If Rob/Yoichi say the alignment is now good, the we absolutely must center the IOO QPDs and IP POS and IP ANG and MC TRANS  today so that we have good references.

  

 IOO_QPD_POS,    IOO_QPD_ANG,    MC_TRANS,    IP_POS, IP_ANG    have all been centered.

Also, the MCWFS have been centered.

I'm now working on making sure beam is hitting all of the RF PDs around.

  1997   Thu Sep 24 15:45:27 2009 robUpdateIOOMC OLG

I measured the mode cleaner open loop gain with the HP3563A

The UGF is 64kHz, phase margin is 28 deg.

  2043   Fri Oct 2 15:24:29 2009 sanjit, ranaSummaryIOOmcwfs centered

we set the offsets for the MCWFS DC and for the MCWFS demod outputs and then turned off the lights put the MZ at half fringe and then centered the spots on the MCWFS heads.

The MCREFL beam looks symmetric again and the MC REFL power is low. 

Attachment 1: Untitled.png
Untitled.png
  2062   Wed Oct 7 06:26:09 2009 ranaHowToIOOMC_L calibration + some DTT lore

I drove MC2 in POS and used the resulting response in MC_F to calibrate the IOO-MC_L channel.

Yoichi did an excellent job of calibrating MC_F last year. I have used his calibration of MC_F (220 Hz/count @ DC) to get the MC_L calibration at DC as well as at high frequencies. The hardware dewhitening was OFF for all these measurements.

Method

1. For the DC measurement I excited C1:SUS-MC2_MCL_EXC at 0.0731 Hz. At these frequencies, the MC_L path has much more gain than the MC_F path. So this excitation at the error point makes the length path to drive itself to cancel the digital excitation. Since the overall MC servo gain is huge, this causes the MC_F path to compensate the residual MC_L motion. One can simply take the ratio of MC_L/MC_F to get the calibration of MC_L in Hz.

2. For the AC measurement, I engaged FM9 of the MC2_MCL filter bank. This guy is an elliptic LP with a notch at 660.38 Hz. I then drove MC2_LSC at 660.38 Hz with a sine wave of 500 counts amplitude. The notch makes the gain of the MC_L feedback zero at that frequency. So MC_F has to do all the work. We can simply measure the ratio of MC2_LSC/MC_F to get the AC calibration of MC2_MCL_OUT (aka IOO-MC_L) and MC2_LSC_OUT (aka LSC-MC_L).

 

Results:

MCF/MCL @ 0.0731 Hz = 569.4. So the MC_L calibration at DC is 220 x 569.4 = 125 kHz/count or 6.02 nm/count.

From this we would expect the AC calibration to be (6 nm/count)*(660.38/f_pend)^2 = 13.0 x10^-15 m/count.

The AC measurement gave 1445 counts_peak** of MC_F for the 500 counts (peak) excitation in MC2_LSC. From Yoichi's entry we get that the high frequency calibration of MC_F should be 0.089 Hz/count. So the MC_L calibration at 660 Hz is 0.089*1445/500 = 0.25 Hz / count or 12.3 x 10^-15 m/count. So the AC/DC ratio is close to 1.

Splitting the difference, the new official MC_L calibration is 5.87 nm/counts @ DC with a complex pole pair at 0.972 Hz.

 

** note:  To convert from the peak height observed in DTT with a 50% Overlap Hanning window you must use the following intuitive formula:  counts_peak = (counts / rHz) * sqrt(2 * BW). In this case, BW is the number that DTT reports as BW on the screen, NOT the BW that you asked for on the measurement tab.

*** note: when measuring peak heights in a DTT FFT, make sure to unclick the box for 'Bin' under the config tab. Bin suppresses peaks in a plot with a lot of points and is ON by default.

**** note: I have updated the MCF reference in the Templates directory with the Yoichi calibration - spectrum attached. This is probably the most accurate MCF spectrum we have ever put in the elog in the history of the 40m. The implication is that the VCO phase noise is ~5 mHz/rHz. Not bad.

***** note: with the OAF off, I drove a 1.55 Hz sine wave into MC1 and measured the ratio of MC1_MCL_OUT/IOO-MC_L. This gives the DC calibration of MC1_MCL_OUT = 7.98 nm/count.

Attachment 1: mcl-cal.png
mcl-cal.png
Attachment 2: a.png
a.png
  2076   Fri Oct 9 16:36:13 2009 rob UpdateIOOfrequency noise problem

I used the XARM as a reference to measure the frequency noise after the MC.  It's huge around 4kHz--hundreds of times larger than the frequency noise the MC servo is actually squashing.  This presents a real problem for our noise performance.

An elog search reveals that this noise has been present (although not calibrated till now) for years.  We're not sure what's causing it, but suspicion falls on the piezojena input PZTs. 

I didn't bother too much about it before because we previously had enough common mode servo oomph to squash it below other DARM noises, and I didn't worry too much about stuff at 4kHz..  Now that we have a weaker FSS and thus much weaker CM servo, we can't squash it, and the most interesting feature of our IFO is at 4kHz. 

I'll measure the actual voltage noise going to the PZTs.  I remember doing this before and concluding it was ok, but can't find an elog entry.  So this time maybe I'll  do it right.

Attachment 1: freqnoiseaftermc.png
freqnoiseaftermc.png
  2077   Fri Oct 9 17:37:21 2009 JenneUpdateIOOMC2 trans beam is dumped

Last night while noise hunting, Rana found that the MC2 trans beam has been left for an unknown length of time just hitting the side of the black enclosure box.  Today I put a brand-spankin'-new razor dump on the MC2 table, to dump the beam.

  2102   Fri Oct 16 10:15:02 2009 steveUpdateIOOIP ang & pos recentered

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

Attachment 1: ip4d.jpg
ip4d.jpg
  2123   Tue Oct 20 02:14:29 2009 robUpdateIOOMC2 alignment bias changed

the mode cleaner was having trouble locking in a 00 mode, needing several tries.  I changed the MC2 coil biases, and it seems better for now.

  2124   Tue Oct 20 10:46:18 2009 steveUpdateIOOclipping IP-ANG beam at ETMX chamber

Initial pointing beam is clearly clipping on 2" pick off mirror in  ETMX vacuum chamber.

Atm. 1  The pick off mirror is just north west of the ETMX test mass

Atm. 2 The camera is looking in from the north view port of ETMX chamber. The back side of pick off mirror is visible now with the face view of the "IP-ANG-OUT" mirror.

 

Attachment 1: PA200175.JPG
PA200175.JPG
Attachment 2: PA200177.JPG
PA200177.JPG
  2132   Thu Oct 22 08:45:58 2009 steveUpdateIOOIP ang & pos recentered

Quote:

Pointing stability of 4 days. Initial pointing does not go through suspended optics. It is launched  right after the Piezo Jena steering mirrors in the BS chamber.

IP-ANG on epics screen is  C1:ASC-IBQPD_X and Y in dataviewer  were recentered. This beam is clipping a bit in ETMX chamber  pick off mirror.

IP-POS pick  off is in the BS chamber and it's qpd on the BS_ISCT This beam is also clipping just a little bit. This is easy to fix. We'll have to remove an iris from the BS optical levers table.

note: arms were not locked when I recentered

 IP-ANG clipping can be traced back to our last vent of Aug. 18, 2008  See elog entry #845

This was an after earth quake - sus repair vent

Attachment 1: pointing1000.jpg
pointing1000.jpg
  2144   Mon Oct 26 18:15:57 2009 robUpdateIOOMC OLG

I measured the mode cleaner open loop gain.  It's around 60kHz with 29 degs of phase margin.

  2168   Mon Nov 2 13:00:55 2009 KojiUpdateIOOPMC aligned, MC WFS aligned

The beam to PMC aligned. The beam to MC WFS cameras aligned.
PMC Trans increased from 2.73 to 2.75 (+1%).
MC Trans increased from 7.80 to 7.87 (+1%).

  2172   Tue Nov 3 03:45:04 2009 rob UpdateIOOfrequency noise problem

Quote:

I used the XARM as a reference to measure the frequency noise after the MC.  It's huge around 4kHz--hundreds of times larger than the frequency noise the MC servo is actually squashing.  This presents a real problem for our noise performance.

An elog search reveals that this noise has been present (although not calibrated till now) for years.  We're not sure what's causing it, but suspicion falls on the piezojena input PZTs. 

I didn't bother too much about it before because we previously had enough common mode servo oomph to squash it below other DARM noises, and I didn't worry too much about stuff at 4kHz..  Now that we have a weaker FSS and thus much weaker CM servo, we can't squash it, and the most interesting feature of our IFO is at 4kHz. 

I'll measure the actual voltage noise going to the PZTs.  I remember doing this before and concluding it was ok, but can't find an elog entry.  So this time maybe I'll  do it right.

 

This level of frequency noise has not changed, but we now have increased common mode servo gain and so it's not as huge of a deal, although we should still probably do something about it. 

 

Attached is a plot of the piezojena noise measurement, estimated into Hz, along with another measurement of frequency noise as described above. 

To get the piezojena voltage noise into Hz, I estimated the PZTs within have a flat 2 micron/V response (based on a rough knowledge of their geometry and assuming a 10 milliradian / 150V steering range).  This is the voltage noise with the PZTs operating in closed loop mode, which is how we normally run them.  This plot also ignores the transfer function of the Pomona box, as we are mainly looking at noise in the kHz band.  I think this plot shows that these PZTs are a good candidate for creating this frequency noise, especially near their mechanical resonances (the manual says the unloaded resonances are in the 3-4kHz range).   

I've been operating one DOF of the piezojenas in open loop mode for a couple of weeks now, and the feared drift has not been a problem at all.  If we plan to keep using these after the upgrade, we should definitely put some big resistors in series at the outputs and operate them in open loop mode.

Also attached is a plot of RF DARM noise, with a frequency noise spectrum.  That spectrum is a REFL 2I spectrum put into DARM units using a measured TF (driving MC_L and measuring REFL 2I and DARM_ERR), and then put into meters using the same DARM calibration as used for the DARM curve.

Attachment 1: noise.png
noise.png
Attachment 2: spectra.pdf
spectra.pdf
  2227   Tue Nov 10 17:01:33 2009 AlbertoConfigurationIOOc1ioovme and c1iool0 rebooted

This afternoon, while I was trying to add the StochMon channels to the frames, I rebooted the c1ioovme and c1iool0.

I had to do it twice because of a mispelling in the C1IOO.INI file that the first time prevented the computer to restart properly.

Eventually I restored the old .ini file, as it was before the changes.

After rebooting I also burtrestored.

During the process the mode cleaner got unlocked. Later on the autoclokcer couldn't engage. I had to run the MC_down and MC_up scripts.

  2234   Wed Nov 11 09:48:04 2009 steveUpdateIOOwhere is IOO-RFAMPD_DCMON ?

RFAMPD_DCMON disappered on Nov 5, 2009

Attachment 1: rfampddc.jpg
rfampddc.jpg
  2318   Mon Nov 23 21:36:38 2009 KojiUpdateIOOAligned PMC/RC

I aligned the beam goes to PMC. It increased the MC Trans from 8.25 to 8.30.

I also aligned the beam goes to RC.
When I touched the FSS box (wrong: this was the VCO driver) that was close to one of the steering mirror, suddenly the RC trans increased.
It is now 9.8. I am afraid that it gets saturated. I could not reproduce the phenomenon. This could be caused by a bad contact?
Note that I didn't see there is any loose optic.

Attachment 1: 091123_PSL.png
091123_PSL.png
  2357   Sat Dec 5 17:34:30 2009 robUpdateIOOfrequency noise problem

There's a large broadband increase in the MC_F spectrum.  I'm not totally sure it's real--it could be some weird bit-swapping thing.  I've tried soft reboots of c1susvme2 and c1iovme, which haven't helped.  In any case, it seems like this is preventing any locking success today.  Last night it was fine.

Attachment 1: mcf.png
mcf.png
  2359   Sat Dec 5 22:31:52 2009 robUpdateIOOfrequency noise problem

Quote:

There's a large broadband increase in the MC_F spectrum.  I'm not totally sure it's real--it could be some weird bit-swapping thing.  I've tried soft reboots of c1susvme2 and c1iovme, which haven't helped.  In any case, it seems like this is preventing any locking success today.  Last night it was fine.

 Rebooting c1iovme (by keying off the crate, waiting 30 seconds, and then keying it back on and restarting) has resolved this.  The frequency noise is back to the 'usual' trace.

  2406   Sun Dec 13 20:50:45 2009 ranaSummaryIOOMach Zender Calibration

I ramped the MZ PZT (with the loop disabled on the input switch) to calibrate it. Since the transmission has been blocked, I used the so-called "REFL" port of the MZ to do this.

The dark-to-dark distance for the MZ corresponds to 2 consecutive destructive interferences. Therefore, that's 2 pi in phase or 1 full wavelength of length change in the arm with the moving mirror.

Eyeballing it on the DTT plot (after lowpassing at 0.1 Hz) and using its cursors, I find that the dark-to-dark distance corresponds to 47.4 +/- 5 seconds.

So the calibration of the MZ PZT is 88 +/- 8 Volts/micron.

Inversely, that's a mean of 12 nm / V.

why am I calibrating the MZ? Maybe because Rob may want it later, but mainly because Koji won't let me lock the IFO.

Apparently, we haven't had a fast channel for any of the MZ board. So I have temporarily hooked it up to MC_DRUM at 21:13 and also turned down the HEPA. Now, let's see how stable the MZ and PMC really are overnight.

EDIT: it railed the +/- 2V ADCwe have so I put in a 1:4 attenuator via Pomona box. The calibration of MC_DRUM in terms of MZ_PZT volts is 31.8 cts/V.

So the calibration of MC_DRUM1 in meters is: 0.38 nm / count


Attachment 1: Untitled.png
Untitled.png
  2407   Sun Dec 13 23:18:09 2009 ranaSummaryIOODisplacement noise on the PSL table

For the Laser Gyro, I wondered how much mechanical noise we might get with a non-suspended cavity. My guess is that the PMC is better than we could do with a large ring and that the MZ is much worse than we could do.

Below 5 Hz, I think the MZ is "wind noise" limited. Above 10 Hz, its just ADC noise in the readout of the PZT voltage.

Attachment 1: mz.pdf
mz.pdf
  2431   Fri Dec 18 15:40:33 2009 KojiUpdateIOOMC2 spot centered / MCT QPD issue

This afternoon I felt like saying hello to the input mode cleaner. So I decided to center the spot on MC2.

Motivation

MC has 6 alignment dofs. 4 of them are controlled by the WFSs. Remaining 2 appears at the spot position on MC2.
If the spot on the MC2 is fixed, the beam hits the same places of three mirrors. If the mirrors are completely fixed
in terms of the incident beam, I suppose the reflected beam is also fixed. This makes the WFS spots more stable.
Then I feel better.

Today's goal is to confirm the behaviour of MC such as dithering amplitude, response of the couplings to the alignment,
behavior of the WFS, and the transmitted power.


Method

1) Turned off MC auto locker. Turned off MC WFS as the WFS servos disturbs my work.
2) Dithered MC2 in Pitch and Yaw using DTT. There looks elliptic filter (fc=28Hz) in the ASC path, I used 20Hz-ish excitations.
- C1:SUS-MC2_ASCPIT_EXC 100cnt_pk@19Hz
- C1:SUS-MC2_ASCYAW_EXC 100cnt_pk@22Hz
3) Looked at C1:SUS-MC2_MCL_OUT to find the peaks at 19Hz and 22Hz. These are caused by alignment-length coupling.
If they are minimized I assume the spot is somehow centered on MC2.
Note: This may not be the true center. The suspension response should be investigated. But this is a certain reporoducible spot position.
Note: I should use ezcademod in order to obtain the phase information of the dither result.

4) Move MC2 Pitch for certain amount (0.01cnt) by the alignment slider. Align MC1/MC3 to have max transmittion.
5) If the Pitch peak got lower, the direction of 4) was right. Go further.
5') If the Pitch peak got higher, the direction of 4) was wrong. Go the other direction.

6) Repeat 4)&5) for Yaw.


Result

After the adjustment, the couplings got lower about 10 times. (Sorry! The explanation is not so scientific.)
Next time I (or someone) should make a script to do it and evaluate the coupling by the estimated distance of the spot from the center of the mirror (the center of the rotation).
I have not seen visible change in the spectrum of C1:SUS-MC2_MLC_OUT.


MCT QPD issue

By the spot centering, I could expected to see some improvement of the transmittion. But in reality, there was no change.
In fact, the transmittion power was getting down for those weeks.

I checked WFS and MCT paths. Eventually I found that a couple of possible problems:
1) MCT Total output varies more than 10% depending on the spot position on MCT QPD.
2) Just before the QPD, there is a ND1 filter.
This may suggest that:
a) Four elemtns of the MCT QPD have different responses.
b) The ND filter is causing a fringe.

So far I aligned the ND filter to face the beam. The reflection from the filter was blocked at a farther place.
Still the output varies on the spot position. Probably I have to look at the QPD someday.

So far the spot on the QPD was defined so that I get the maximum output from the QPD. This is about 8.8.
As I touched the steering mirrors, the X and Y outputs of the QPD are no longer any reference.

For now, I closed the PSL table. The full IFO was aligned.

  2435   Sun Dec 20 23:42:44 2009 JenneUpdateIOONew Input Mode Matching Telescope

I've got most of the new Mode Matching Telescope figured out.  The scripts and an example result are at: MMT09 wiki  (Rather, the scripts are in the svn: MMT svn)

Issues still to be resolved: 

* We're getting pretty iffy 'angles' between tilt and translation when using the mode matching mirrors for steering.

* I haven't taken into account the astigmatism which occurs when you tilt the mode matching mirrors. 

The nifty thing about these scripts is that they take a look at the mode matching overlap:  For each possible mode matching solution it adds noise to all of the distances and radii of curvature during ~10,000 iterations and plots a histogram of the overlap so that we can see which solutions have a better chance of giving us the optimal overlap, even if we place the optics in slightly the wrong place.

 

I'd like to update the overlap part of the script with the astigmatism business:  do we lose goodness of overlap if we tilt the mirrors by a bit?  I think this will require redoing the overlap part with the X and Y directions separate.  Koji has done this in the past.  My current code assumes that the beam is always symmetric in X and Y. 

  2444   Tue Dec 22 11:23:51 2009 kiwamu, SteveUpdateIOOMC relocked

In this morning I found MC unlocked.

Steve restored the watchdogs before I found that.

Then I relocked MC and now MC is locked and working well.

The reflected DC power is ~0.38, which is usual number.

 

  2448   Wed Dec 23 16:34:25 2009 KojiUpdateIOOMCT QPD/MC REFL QPD disabled

For a certain investigation of the sum/diff module for MCT QPD/MC REFL QPD, I removed it from the system.

 

  2451   Thu Dec 24 19:13:29 2009 KojiUpdateIOOMCT QPD investigation

I found that MCT QPD has a dependence of the total output on the position of the spot. Since the QPD needs the supply and bias voltages from the sum/diff amp, I could not separate the problems of the QPD itself and the sum/diff amplifier by the investigation on Tuesday. On Wednesday, I investigated a generic quad photodiode interface module D990692.

...I was so disappointed. This circuit was left uninvestigated and used so long time with the following sorrowful conditions.
- This circuit has 4 unbuffered inputs with input impedance of 300~400 Ohm. It's way too low!
- Moreover, those channels have different input impedances. Ahhhh.
- Even worse, the QPD circuit D990272 has output impedance of 50 Ohm.
- The PCB of this circuit has four layers. It is quite difficult to make modifications of the signal route.
- It is a headache: this circuit is "generic" and used in many places.

D990692 has 4 channel inputs that are not buffered. Each channel has two high impedance buffers but they are used only for the monitors. The signal paths have no buffer.

The differential amplifier is formed by R=1k Ohm. The inverted side of the input has 1kOhm impedance. The non-inverted side has 1.5kOhm impedance.

CH1: 10K // 1.5k // 1.5k // 1k = 411 Ohm
CH2: 10K // 1.5k // 1k // 1k = 361 Ohm
CH3: 10K // 1k // 1k // 1k = 323 Ohm
CH4: 10K // 1k // 1.5k // 1k = 361 Ohm

Considering the output impedance of 50Ohm for the QPD, those too low input impedances result in the following effect:
- Because of the voltage division, we suffer absolute errors of 10.8~13.4%. This is huge.
- Because of the input impedance differences, we suffer a relative error of 1.5%~3%. This is also huge.

Unfortunately, the circuit has no room to modify; the signal paths are embedded in the internal layer.

I decided to replace the resistors of the sum/diff amps from 1k to 10k. Also the input impedance of the buffer was removed as the input is terminated by the sum/diff amps in any case.This changes the input inpedance to the followings:

CH1: 15k // 15k // 10k = 4286 Ohm
CH2: 15k // 10k // 10k = 3750 Ohm
CH3: 10k // 10k // 10k = 3333 Ohm
CH4: 10K // 15k // 10k = 3750 Ohm

These yield the absolute error of 1.2-1.5%. The relative error is now 0.3%. I can accept these numbers, but later I should put additional terminating resistors to compensate the differencies.

So far I have modified the resistors for the MCT as the modification for a QPD needs 17 10k resistors.
Next thing I have to check is the dependence of the QPD outputs on the spot positions.

-----------------------------------------------

Edit: Feb 11, 2010

I talked with Frank and he pointed out that the impedances are not the matter but the gains of the each channels are the matters (after considering the output impedance of the QPD channels).
If we assume the ideal voltage sources at the QPD and the symmetric output impedances of 50Ohm, the gain of the each circuit are affected but the change should be symmetric.

He found that several things:
- The analog switch (MAX333) used in the QPD unit adds more output impedance (somewhat randomly!).
- The resistance of the sum/diff circuits may vary each other unless we use 0.1% resistors.

 

Attachment 1: D990692.png
D990692.png
  2473   Mon Jan 4 17:21:30 2010 JenneConfigurationIOOElusive Mode Matching Solution found!

I think I have finally found a Mode Matching solution for our new Input Mode Matching Telescope!  And after looking at the layout diagram with Koji and Raffaele, it seems like all of the optics will fit into the chambers / onto the tables (not true as of last week). 

3. RoCMMT1 is -5m
   RoCMMT2 is 8m,
   with the MMTs 1.89m apart.
   This is a 1.6x telescope.
   MMT2 is 2.2641m from the PRM
   MMT1 is 2m from MC3.
   The Condition Number for this optical chain is 89219047.5781.

This layout is very similar to the one that Koji posted on the wiki yesterday:  Upgrade09/Optical Layout.  The difference is that I want to move MMT1 ~20cm closer to the MC13 table, so just on the other side of the main red beam that goes directly to PRM.  There is plenty of space there, so it should be all good.  The tricky bit is that the flat steering mirrors fit into things now while they are piezos, but they will be trickier to fit if we make them into Tip Tilts.  But I have full faith in Koji's amazing optical table layout skills, that he can make it happen. 

Unless there are major objections, I think this is the MMT that we're going to go with. (So speak now or forever hold your peace.)  The angle between tilt and translation isn't quite what we'd like it to be (at ~18deg), but it's not too terrible.  And we still have 99.5% overlap which is very important.

Attachment 1: Awesome_MM_Solution.png
Awesome_MM_Solution.png
  2481   Wed Jan 6 03:44:41 2010 KojiConfigurationIOOElusive Mode Matching Solution found!

I am in the way to get a reasonable optical layout.
Please calculate the final results with the following conditions.

"Result" =
- mode overlapping with astigmatism
- alignment matrix (m/rad, rad/rad) for Pitch and Yaw
- alignment orthogonality
- sensitivity of the mode overlapping to the perturbations
  * histgram
  * individual scan of the optic positions

Optics chain: MC3 - SM1(flat) - MMT1(f=-5m) - MMT2(f=+8m) - SM2(flat) - PRM

Incident angles: SM1 24deg, MMT1 3deg, MMT2 1deg, SM2 44.5deg

Distances:
MC3 HR - SM1: 884mm
SM1 - MMT1: 1058.2mm
MMT1 - MMT2: 1890mm
MMT2 - SM2: 2007.9mm
SM2 - PRM HR: 495.6mm

It has ~200mm deviation from the solution. I can move only MMT1 for final optimization.
Give us the numbers if it can improve the performance.
Note that this move changes SM1-MMT1 and MMT1-MMT2 simultaneously.

Quote:

I think I have finally found a Mode Matching solution for our new Input Mode Matching Telescope!  And after looking at the layout diagram with Koji and Raffaele, it seems like all of the optics will fit into the chambers / onto the tables (not true as of last week). 

3. RoCMMT1 is -5m
   RoCMMT2 is 8m,
   with the MMTs 1.89m apart.
   This is a 1.6x telescope.
   MMT2 is 2.2641m from the PRM
   MMT1 is 2m from MC3.
   The Condition Number for this optical chain is 89219047.5781.

This layout is very similar to the one that Koji posted on the wiki yesterday:  Upgrade09/Optical Layout.  The difference is that I want to move MMT1 ~20cm closer to the MC13 table, so just on the other side of the main red beam that goes directly to PRM.  There is plenty of space there, so it should be all good.  The tricky bit is that the flat steering mirrors fit into things now while they are piezos, but they will be trickier to fit if we make them into Tip Tilts.  But I have full faith in Koji's amazing optical table layout skills, that he can make it happen. 

Unless there are major objections, I think this is the MMT that we're going to go with. (So speak now or forever hold your peace.)  The angle between tilt and translation isn't quite what we'd like it to be (at ~18deg), but it's not too terrible.  And we still have 99.5% overlap which is very important.

 

  2535   Thu Jan 21 10:09:27 2010 KojiSummaryIOOPhotos of the optical tables

I made a wiki page dedicated for the photos of the optical tables.
The current layouts were uploaded.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Optical_Tables

  2559   Tue Feb 2 13:14:09 2010 KojiHowToIOOAnatomy of New Focus Resonant EOM

Joe let me use the resonant EOM for GigE phase camera for a while.
Then, I immediately started to open it :)

it uses the MiniCIrcuits T5-1T transformer and a TOKO RCL variable inductor.

The photos are on the Picasa 40m album.

http://lhocds.ligo-wa.caltech.edu:8000/40m/40m_Pictures

  2584   Tue Feb 9 17:51:48 2010 JenneSummaryIOOInput Mode Matching Telescope design is complete

The upgrade's input mode matching telescope design is complete.  A summary document is on the MMT wiki page, as are the final distances between the optics in the chain from the mode cleaner to the ITMs.  Unless we all failed kindergarden and can't use rulers, we should be able to get very good mode matching overlap.  We seem to be able (in Matlab simulation land) to achieve better than 99.9% overlap even if we are wrong on the optics' placement by ~5mm.  Everything is checked in to the svn, and is ready for output mode matching when we get there.

  2698   Tue Mar 23 00:31:51 2010 KojiUpdateIOOMC realigned

This is the first touch to the MC mirrors after the earthquake on 16th.

  • I made an aluminum access connector so that we can work on the MC even the door is open. We still can be able to open the aluminum tube. The photos are attached. Steve, could you please look it at a glance whether the seal is enough or not.
  • MC resonances were flashing. Align MC2 and MC3 so that we have many TEM00s.
  • Found c1vmesus2 gone mad. Restarted remotely according to the wiki entry. 
  • Reset the MC coil output matrix to 1. (Previously, balance was adjusted so that A2L was minimized.)
  • Excite MC2 Pitch/Yaw at 8 and 9 Hz, looking at the peaks in the MC-MCL output. Move MC2 Pitch/Yaw so that the peak
    is reduced. (*)
  • MC1/MC3 were aligned so that we get the maximum transmission (or minimum reflection). (**)
  • Repeat (*) and (**)

So far, I have aligned in Yaw such that the yaw peak is minimized.

Attachment 1: IMG_2346.jpg
IMG_2346.jpg
Attachment 2: IMG_2347.jpg
IMG_2347.jpg
  2699   Tue Mar 23 09:37:36 2010 steveUpdateIOOvac envelope has to be sealed as antproof for overnight

Quote:

This is the first touch to the MC mirrors after the earthquake on 16th.

  • I made an aluminum access connector so that we can work on the MC even the door is open. We still can be able to open the aluminum tube. The photos are attached. Steve, could you please look it at a glance whether the seal is enough or not.
  • MC resonances were flashing. Align MC2 and MC3 so that we have many TEM00s.
  • Found c1vmesus2 gone mad. Restarted remotely according to the wiki entry. 
  • Reset the MC coil output matrix to 1. (Previously, balance was adjusted so that A2L was minimized.)
  • Excite MC2 Pitch/Yaw at 8 and 9 Hz, looking at the peaks in the MC-MCL output. Move MC2 Pitch/Yaw so that the peak
    is reduced. (*)
  • MC1/MC3 were aligned so that we get the maximum transmission (or minimum reflection). (**)
  • Repeat (*) and (**)

So far, I have aligned in Yaw such that the yaw peak is minimized.

 This seal is good for daily use- operation only. The IFO has to be sealed  with light metal doors every night so ants and other bugs can not find their way in.

Our janitor Kevin is mopping the hole IFO room floor area with 5%  ant killing solution in water in order to discourage bugs getting close to our openings of the vented chamber.

You may be sensitive to this chemical too.  Do not open chamber till after lunch.

Attachment 1: pc3.JPG
pc3.JPG
Attachment 2: pc4.JPG
pc4.JPG
  2700   Tue Mar 23 09:55:20 2010 KojiUpdateIOOvac envelope has to be sealed as antproof for overnight

Roger.

Quote:

 This seal is good for daily use- operation only. The IFO has to be sealed  with light metal doors every night so ants and other bugs can not find their way in.

 

  2705   Wed Mar 24 02:06:24 2010 KojiUpdateIOOvac envelope has to be sealed as antproof for overnight

Matt and Koji:

We closed the light doors of the chambers.

Quote:

Roger.

Quote:

 This seal is good for daily use- operation only. The IFO has to be sealed  with light metal doors every night so ants and other bugs can not find their way in.

 

 

ELOG V3.1.3-