40m QIL Cryo_Lab CTN SUS_Lab CAML OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 317 of 355  Not logged in ELOG logo
ID Date Author Type Category Subject
  1922   Tue Aug 18 01:16:01 2009 JenneUpdatePSLMach Zehnder is realigned

The Mach Zehnder and I got to know each other today.  The reason for redoing the alignment was to improve pointing from the PSL table into the MC/IFO in hopes that this would solve the MC unlocking problems that we've been having lately.  Since Rana had aligned the IOO QPDs a few weeks ago when all of the alignments and things were good, I used them as a reference for my Mach Zehnder alignment activities. 

 
The order of operations were approximately as follows:

1. Block the secondary (west) arm of the Mach Zehnder using either an aluminum or razor dump.

2. Use SM1 in the MZ to align the beam to the IOO_QPDs (Pos and Ang).  I unfortunately also touched BS2 at this juncture, which made the refl path no longer a reference.

3.  Make sure that the QPD Sum on both Pos and Ang was sensible.  Since there are 2 beamsplitters in a Mach Zehnder, the power on the QPDs should be a quarter when only one beam is on them.  Be careful not to allow the beam no clip on anything.  The biggest problem was the bottom periscope mirror - if you hit it too high or too low, since it is a very thick optic, you end up coming out its side!  This is the frosty part on the edges, totally inappropriate for beams to go through!  Since the side of the periscope mirror isn't HR coated, when going through it like this, I was able to saturate the QPDs.  Not so good. 

4. Also, make sure that this first beam is on the MZ Refl PD.  Do this using the steering optics after the beam has left the MZ.  Use a viewer to look at the PD, and see the small spot of the beam on the diode.  We closed the iris which is present and was standing fully open to remove a spurious beam which was a parallel split-off of the main beam.  Since it was very weak, it is fine.

5.  Unblock the west arm, and block the east arm of the MZ.

6. Align this arm to both the IOO QPDs and the MZ refl diode using the adjustments on BS1, the PZT mirror and if necessary, BS2.  Note that the adjust knobs on the PZT mirror have lock screws.  Make sure to unlock them before adjusting, and relock afterward, to avoid slipping while the PZT is moving.

7.  Unblock all the beams, and make sure there is only one spot both on the transmission side and the reflection side, i.e. the 2 spots from the 2 arms are completely overlapping.  For the Trans side, make sure to look both in the near field and the far field (even after the periscope) to ensure that you really have one spot, instead of just the 2 spots crossing at a single location.

8.  Look at the MZ refl DC out and the PD out from the ISS box (which is essentially MZ trans, looking at Morag and Siobhan) on a 'scope.

9.  Touch / gently wiggle BS1 or another optic, and watch the 'scope.  At the same time, adjust BS1, the PZT mirror and BS2 to maximize the contrast between light and dark fringes.  Ideally, the refl PD should go almost to zero at the dark fringes.

10.  Check that you still have only one overlapping beam everywhere, and that you're actually hitting the MZ refl PD.

11. Because I was concerned about clipping while still figuring out the status of the lower periscope mirror, I removed the beam pipe holders between the last optic before the periscope, and the lower periscope mirror.  The beam pipe had already been removed, this was just the pedestals and the snap-in clamps.

All done for now!  Still to be done:  Optimize the position of the EOMs.  There is a waveplate out front and the EOMs are mounted in such a way that they can be moved in several directions, so that we can optimize the alignment into them.  They ideally only should see a single polarization, in order to apply solely a phase modulation on the beam.  If the input polarization isn't correct, then we'll get a bit of amplitude modulation as well, which on PDs looks like a cavity length change.  Also, the little blue pomona-type box which has the RF signals for the EOMs needs to be clamped to the table with a dog clamp, or better yet needs to be moved underneath the PSL table, with just the cables coming up to the EOMs.  The SMA connections and the SMA cable kept interfering with the MZ refl beam...it's a wonder anyone ever made the beam snake around those cables the way they were in the first place. Right now, the box is sitting just off the side of the table, just inside the doors.

 
Something else that Rana and I did while on the table:  We moved the PMC trans optics just a teensy bit toward the PSL door (to the east) to avoid coming so unbelievably close to the MZ refl optics.  The PMC trans beam shown in the lowest part of my sketch was very nearly clipping on the MZ refl steering optic just near it.  This situation isn't totally ideal, since (as it has been in the past), the first optic which is dedicated to the PMC trans isn't fully sitting on the PSL table.  The pedestal needs to hang off the edge of the table a bit to keep this beam from clipping.  Unfortunately there really isn't space to make a better beam path.  Since we're planning on getting rid of the MZ when the upgrade happens, and this isn't causing us noticeable trouble right now, we're going to let it stay the way it is.

Also, we dumped the reflection from the PMC RFPD onto a razor blade dump. And we noticed that the PZT mirror and BS2 in the MZ are badly vibrationally sensitive. BS2 has a ~400 Hz resonance (which is OK) but a ~150 ms ringdown time!! PZT mirror is similar.

Q = pi * f * tau = 200!  Needs some damping.

Attachment 1: MachZehnderOptics2.pdf
MachZehnderOptics2.pdf
  1921   Mon Aug 17 17:48:49 2009 robSummaryGeneralconlogger restarted

Quote:

I restarted the conlogger on op340m.  This needs to be done when op340m is rebooted--it wasn't done for some reason and so we've lost several days of controls records.

 I added a cronjob on op340m to check every half-hour if the conlog is running, and if not, restart it. 

  1920   Mon Aug 17 17:43:11 2009 ranaSummaryGeneralconlogger restarted

Added the conlog directory to the SVN, minus the enormous data directory. We are now free to make changes to the conlog code.

  1919   Mon Aug 17 09:52:04 2009 robSummaryGeneralconlogger restarted

I restarted the conlogger on op340m.  This needs to be done when op340m is rebooted--it wasn't done for some reason and so we've lost several days of controls records.

  1918   Mon Aug 17 07:01:09 2009 ClaraUpdatePEMADC noiseness

I shorted the inputs on three channels and the outputs on three channels of the Guralp box, and I did similar things with the accelerometers. I was going to move the instruments themselves back, but I didn't have time, so they are still in the box in the corner. If the setup could stay as-is for at least a few hours, that would be awesome.

  1917   Mon Aug 17 04:16:13 2009 YoichiUpdatePSLReference cavity reflection looks bad

Quote:
Rana, Yoichi
- We also moved the Refcav reflection camera to look at the leakage through a reflection steering mirror so that there's less chance of distortion. There was previously a W1 window in there as a pickofff. Also changed the camera to autogain so that we can see something.

- Re-aligned onto the refl pd.

- Tweaked alignment into RC. Mainly in yaw. Transmission went from 5V to 7V. In your face, Aso!


After our removal of the pick off window and Rana's re-alignment of the beam into the RC, the RC optical gain increased.
FSS was complaining about it by driving the PC feedback crazy.
I reduced the nominal common gain from 12.5dB to 11dB.
  1916   Mon Aug 17 02:12:53 2009 YoichiSummaryComputersFE bootfest
Rana, Yoichi

All the FE computers went red this evening.
We power cycled all of them.
They are all green now.

Not related to this, the CRT display of op540m is not working since Friday night.
We are not sure if it is the failure of the display or the graphics card.
Rana started alarm handler on the LCD display as a temporary measure.
  1915   Mon Aug 17 02:05:49 2009 Yoichi,ranaUpdatePSLReference cavity reflection looks bad
Rana, Yoichi

It has been a well known fact that the reference cavity reflection beam looks ugly.

We measured the visibility of the RC by locking and unlocking it.
Comparing the reflected beam powers, we got the visibility of 0.46,
which is pretty bad.

The beam going into the RC looks fine (circular on a sensor card).
However, the beam reflected back from the RC is distorted into a
horizontal ellipse, even when the RC is not locked.

We took a picture of the reflected beam hitting a white paper with the
infrared camera (see the attachment). It looks like two overlapping
circles horizontally separated. Could it be a badly coated optics
producing a secondary reflection ?

We looked into the RC's front mirror with an inspection mirror, but we
could not identify any obstructing object.

Rana is now touching the RC alignment.

We plan to remove the periscope before the RC to have a better look
into the cavity for inspection.


Late breaking update:
- We also moved the Refcav reflection camera to look at the leakage through a reflection steering mirror so that there's less chance of distortion. There was previously a W1 window in there as a pickofff. Also changed the camera to autogain so that we can see something.

- Re-aligned onto the refl pd.

- Tweaked alignment into RC. Mainly in yaw. Transmission went from 5V to 7V. In your face, Aso!
Attachment 1: P8170113.JPG
P8170113.JPG
Attachment 2: Untitled.png
Untitled.png
  1914   Sun Aug 16 04:33:11 2009 ClaraUpdateLockingMode Cleaner is out of lock again

Quote:

It was fine when I came in earlier today, but I just got back from dinner, and it's not good. I looked in dataviewer, and it seems to have been sliding out for the past couple of hours... Here is a picture:

MC_trans.png

I swear I am not responsible this time... all I've been doing is working in the control room.

 Mode cleaner bounced back on its own about 2 hours ago.

  1913   Sat Aug 15 22:50:18 2009 ClaraUpdateLockingMode Cleaner is out of lock again

It was fine when I came in earlier today, but I just got back from dinner, and it's not good. I looked in dataviewer, and it seems to have been sliding out for the past couple of hours... Here is a picture:

MC_trans.png

I swear I am not responsible this time... all I've been doing is working in the control room.

  1912   Sat Aug 15 18:57:48 2009 ranaUpdateVACUPS failed

As Rob noted last Friday, the UPS which powers the Vacuum rack failed. When we were trying to move the plugs around to debug it, it made a sizzling sound and a pop. Bad smells came out of it.

Ben came over this week and measured the quiescent power consumption. The low power draw level was 11.9 A and during the reboot its 12.2 A. He measured this by ??? (Rob inserts method here).

So what we want is a 120 V * 12.2 A  ~ 1.4 kVA UPS with ~30-50% margin. We look for this on the APC-UPS site:

On Monday, we will order the SUA2200 from APC. It should last for ~25 minutes during an outage. Its $1300. The next step down is $200 cheaper and gives 10 minutes less uptime.

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

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

  1910   Sat Aug 15 10:36:02 2009 AlanHowToComputersnodus boot procedure

Quote:
The restart procedures for the various processes running on nodus are explained here:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#nodus

Please go through those steps when you reboot nodus, or notice it rebooted then elog it.
I did these this time.


fb40m was also rebooted. I restarted the ssh-agent for backup of minute-trend and /cvs/cds.
  1909   Sat Aug 15 05:08:55 2009 YoichiUpdateLockingFriday night locking
Summary: DD hand off fails for DRFPMI.

Tonight, I did a lot of house keeping work.

(1) I noticed that the reference cavity (RC) was locked to TEM10.
This was probably the reason why we had to increase the FSS common gain.
I re-locked the RC to TEM00. Now the common gain value is back to the original.

(2) The MC WFS did not engage. I found that c1dcuepics had the /cvs/cds mounting problem.
I rebooted it. Then MC WFS started working.

(3) After checking that the MC WFS QPDs are centered for direct reflection (the MZ half fringe method),
I locked the MC and tweaked the mirror alignment (mainly MC3) to offload the WFS feedback signals.
Now the MC locks to TEM00 robustly.

(4) Since the MC mirror alignment is touchy recently, I did not like the idea of mis-aligning MC2
when you do the LSC PD offset adjustment. So I modified the LSCoffset script so that it will close
the PSL shutter instead of mis-aligning MC2.

(5) I changed the PD11_Q criteria for success in the alignment scripts because PD11_Q is now lower
than before due to the lower laser power.

(6) Since today's bootfest, some epics values were not properly restored. Some of the PD gains were
unmatched between I and Q. I corrected these with the help of conlog.

(7) By checking the open loop TFs, I found that the short DOFs have significantly lower UGFs than before,
probably due to the lower laser power. I increased the gains of MICH, PRCL and SRCL by a factor of 2 for
the full configuration.
For the DRM configuration the changes I made were:

PRC -0.15 -> -0.3
SRC 0.2 -> 0.6
MICH 0.5 -> 0.5

(8) I locked the DRFPMI with arm offsets, then adjusted the demodulation phases of PD6,PD7,PD8 and PD9 (DD PDs)
to minimize the offsets in the error signal, while locked with the single demodulation signals.

Change log:
PD6_PHASE 201 -> 270
PD7_PHASE 120 -> 105
PD8_PHASE 131 -> 145
PD9_PHASE -45 -> -65


(9) I ran senseDRM to get the sensing Matrix for the short DOFs using DD signals in DRM configuration.

(10) Still the DD hand off fails for DRFPMI. It succeeds for DRM.
  1908   Fri Aug 14 23:45:14 2009 ChrisUpdateGeneralLong Range Readout

The EUCLID-style Michelson readout is on the SP table now and is aligned.  See image below.  I took several power spectra with the plotter attached to the HP3563 (not sure if there's another way to get the data out) and I'm still waiting to calibrate (since dP/dL isn't constant as it isn't locked, this is taking a bit longer).  When put into XY mode on the oscilliscope (plotting Voltage at PD2 on the x and Voltage at PD3 on the y), a Lissajous figure as in the first plot below.  It's offset and elliptical due to imperfections (noise, dc offset, etc) but can ideally be used to calculate the L_ target mirror movement.  By rotating the first quarter wave plate by ~80.5deg counter-clockwise (fast axis was originally at Pi/8, now at 103deg), I was able to turn the Lissajous figure from an ellipse into a more circular shape, which would ideally allow for us to use a circular approximation (much simpler) in our displacement calculations.

Attachment 1: Table_Setup.png
Table_Setup.png
Attachment 2: Ellipse.jpg
Ellipse.jpg
Attachment 3: Circle.jpg
Circle.jpg
  1907   Fri Aug 14 18:33:02 2009 ClaraUpdate Record of Accelerometer and Seismometer Movements

Rather than make a new elog post every time I move something, I'm going to just keep updating this Google spreadsheet, which ought to republish every time I change it. It's already got everything I've done for the past week-ish. The spreadsheet can be accessed here, as a website, or here, as a pdf. I will still post something nightly so that you don't have to search for this post, but I wanted to be able to provide more-or-less real-time information on where things are without carpet-bombing the elog.

  1906   Fri Aug 14 15:32:50 2009 YoichiHowToComputersnodus boot procedure
The restart procedures for the various processes running on nodus are explained here:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#nodus

Please go through those steps when you reboot nodus, or notice it rebooted then elog it.
I did these this time.
  1905   Fri Aug 14 15:29:43 2009 JenneUpdateComputersc1susvme2 was unmounted from /cvs/cds

When I came in earlier today, I noticed that c1susvme2 was red on the DAQ screens.  Since the vme computers always seem to be happier as a set, I hit the physical reset buttons on sosvme, susvme1 and susvme2.  I then did the telnet or ssh in as appropriate for each computer in turn.  sosvme and susvme1 came back just fine. However, I couldn't cd to /cvs/cds/caltech/target/c1susvme2 while ssh-ed in to susvme2.  I could cd to /cvs/cds, and then did an ls, and it came back totally blank.  There was nothing at all in the folder. 

Yoichi showed me how to do 'df' to figure out what filesystems are mounted, and it looked as though the filesystem was mounted.  But then Yoichi tried to unmount the filesystem, and it claimed that it wasn't mounted at all.  We then remounted the filesystem, and things were good again.  I was able to continue the regular restart procedure, and the computer is back up again.

Recap: c1susvme2 mysteriously got unmounted from /cvs/cds!  But it's back, and the computers are all good again.

  1904   Fri Aug 14 15:20:42 2009 josephbSummaryComputersLinux1 now has 1.5 TB raid drive

Quote:

Quote:

nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.

cd /export/elog/elog-2.7.5/
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

 It looks like Alex also rebooted all of the control room computers.  Or something.  The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.

 Alex switched the mount point for /cvs/cds on Linux1 to the 1.5 TB RAID array after he finished copying the data from old drives.  This required a reboot of linux1, with all the resulting /cvs/cds mount points on the other computers becoming stale.  Easiest way to fix that he found was to do a reboot of all the control room machines.  In addition, a reboot fest should probably happen in the near futuer for all the front end machines since they will also have stale mount points as well from linux1.

The 1.5 TB RAID array mount is now mounted on /home of linux1, which was the old mount point of the ~300 GB drive.  The old drive is now at /oldhome on linux1.

 

  1903   Fri Aug 14 14:33:51 2009 JenneSummaryComputersnodus rebooted

Quote:

nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.

cd /export/elog/elog-2.7.5/
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

 It looks like Alex also rebooted all of the control room computers.  Or something.  The alarm handler and strip tool aren't running.....after I fix susvme2 (which was down when I got in earlier today), I'll figure out how to restart those.

  1902   Fri Aug 14 14:19:25 2009 KojiSummaryComputersnodus rebooted

nodus was rebooted by Alex at Fri Aug 14 13:53. I launched elogd.

cd /export/elog/elog-2.7.5/
./elogd -p 8080 -c /export/elog/elog-2.7.5/elogd.cfg -D

  1901   Fri Aug 14 10:39:50 2009 josephbConfigurationComputersRaid update to Framebuilder (specs)

The RAID array servicing the Frame builder was finally switched over to JetStor Sata 16 Bay raid array. Each bay contains a 1 TB drive.  The raid is configured such that 13 TB is available, and the rest is used for fault protection.

The old Fibrenetix FX-606-U4, a 5 bay raid array which only had 1.5 TB space, has been moved over to linux1 and will be used to store /cvs/cds/.

This upgrade provides an increase in look up times from 3-4 days for all channels out to about 30 days.  Final copying of old data occured on August 5th, 2009, and was switched over on that date.

  1900   Fri Aug 14 02:57:46 2009 ClaraUpdatePEMRedo of the Huddle Test

I put all three seismometers and all six accelerometers together in the foam box with peanuts. Three of the accelerometers are facing in the x-direction and three are in the y-direction. Both Guralps are aligned on the NS axis and the Ranger is pointing vertically.

**EDIT: The accelerometers are in the x and z directions, not x and y. Sorry, I was sleepy when I wrote this.**

One of the accelerometers was refusing to show anything, and after a few hours of checking connections and swapping cables, I discovered that someone had unplugged the cable from the ADC. A quick glance in the dataviewer shows that the channel has been unplugged since about 3 in the afternoon on August 8th (Saturday). So... obviously all the accelerometer measurements made with that channel since then did not actually get recorded. Yay.

Anyway, as of 2:45, everything is working and taking data. Clearly we're not getting a full night's worth... hopefully that's okay.

  1899   Thu Aug 13 22:53:48 2009 YoichiConfigurationPSLFSS nominal common gain changed, MC WFS centered

Koji, Yoichi

We found that the FSS PC feedback easily goes crazy (saturated).
It was because the common gain was too low. Probably the recent decrease of the
laser power is responsible for this.
We increased the nominal value of the common gain from 12 to 16.5.
The value was chosen just to make the PC path quiet. We should check
the FSS UGF later.
 
The MC WFS QPDs seemed off centered. So we unlocked the MC and lowered
the input power by the usual MZ half fringe technique.
Actually, the direct reflection beam was not much off the center. In anyway, we adjusted
the beam to the exact center of the QPDs.
The MC now locks fine.

 

  1898   Thu Aug 13 11:20:43 2009 janoschHowToPEMthree-channel self-noise estimation

There are two new Matlab files on the svn in /mDV/extra/C1. 'mycsd.m' is to calculate the cross-spectral density between two channels, 'csd_40T_40T_SS1.m' calls this function with the available seismic channels and derives a self-noise spectrum for the vertical axis using all three seismometers. The method requires that there are no correlations between two instruments only which is a bad idealization for certain frequencies if you have seismometers of totally different types.

'mycsd.m' uses the high-gain, low-resolution Nuttall window (built-in Matlab function 'nuttallwin.m'). High-gain windows are used for broad-band spectra like seismic spectra, but it should be exchanged by another window if you plan to look at small-bandwidth features like peaks.

Since the three-channel analysis does not require knowledge of response functions, it could be used to evaluate the performance of the adaptive filter. For example, if three channels responding to the same signal are available, then the ratio of any two csds corresponds to one of the relative transfer functions. You can then compare this function with the result produced by the adaptive filter.

  1897   Thu Aug 13 09:22:06 2009 ranaUpdatePEMranger

Rana, Jan, Jenne

We noticed that the Ranger data was all bogus at low frequencies. So we checked it and found that the proper procedure had not been used when changing it from horizontal to vertical last week. So the huddle test data from the weekend is not valid for the ranger; we will have to repeat it sometime.

So we used the manual, and extended the hanger rod on top of the Ranger to free the mass. It now has good response and coherence with the Guralps down to 0.1 Hz. See attached plot soon.

 

  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.

  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.

  1894   Wed Aug 12 23:45:03 2009 ChrisUpdateGeneralLong range michelson

Today I set up the EUCLID long range michelson design on the SP table; It's the same as the setup posted earlier, but without the pickoff (at PD1), which can be added later, and a few other minor changes (moved lenses, mirrors, PDs - nothing major).  I hooked up the two PD's to the oscilliscope and got a readout that pointed to more power hitting PD2 than PD3.

Attachment 1: Actual_Sensor.png
Actual_Sensor.png
  1893   Wed Aug 12 15:02:33 2009 AlbertoConfigurationComputerselog restarted

In the last hour or so the elog crashed. I  have restarted it.

  1892   Wed Aug 12 13:35:03 2009 josephb, AlexConfigurationComputersTested old Framebuilder 1.5 TB raid array on Linux1

Yesterday, Alex attached the old frame builder 1.5 TB raid array to linux1, and tested to make sure it would work on linux1.

This morning he tried to start a copy of the current /cvs/cds structure, however realized at the rate it was going it would take it roughly 5 hours, so he stopped.

Currently, it is planned to perform this copy on this coming Friday morning.

  1891   Wed Aug 12 12:08:16 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I measured the magnitude of modulation as a function of frequency using the optical spectrum analyzer and an oscilloscope while generating signals using a Marconi signal generator; the results are shown in the attached plot and are compared to the expected modulation given the measured transfer function of the circuit and the nominal modulation index of the EOM used (13 mrad/V). Using the oscilloscope, I found the resonant peaks to be at 11.11 MHz, 29.57 MHz, and 54.70 MHz. There are several different colors on the plot; this is because I had to take the data in several different segments and had to switch to measuring a different sideband partway through the measurment. I also separately found the modulation at each resonant peak for each sideband. The magnitude of modulation was measured  by finding the ratio between the magnitude of the carrier and sideband powers using an oscilloscope, and calculating the magnitude of modulation from this. This method was also used to quantify the dependence of modulation magnitude on input power at each resonant peak; these results are also attached. These same results can also be plotted as modulation magnitude as a function of voltage into the resonant circuit; this is also attached (I'm not sure which is more useful).

In order to produce these results (get the measurements in mrad/V) it was necessary to measure the gain of the amplifier. I used the signal generator to input signals of varying power and measured the output signal voltage using the oscilloscope; I then repeated this process at each resonant frequency. From this I was able to calculate the gain of the amplifier to be 28.1 dB at 11.11 MHz, 27.4 dB at 29.57 MHz, and 25.7 dB at 54.70 MHz. These values are in the same ballpark as the values in the Mini Circuits data sheet (all values are ~25-28 MHz).

Attachment 1: Modulation.png
Modulation.png
Attachment 2: Linearity.png
Linearity.png
Attachment 3: Linearity_V.png
Linearity_V.png
  1890   Wed Aug 12 10:35:17 2009 jenneSummaryComputersNodus rebooted / SVN down

Quote:

Looks like someone rebooted nodus at ~3 PM today but did not elog it. Also the SVN is not running. Why?

 The Nodus business was me....my bad.  Nodus and the elog were both having a bad day (we couldn't ssh into nodus from op440m (which doesn't depend on the names server)), so I called Alex, and he fixed things, although I think that all he did was reboot.  I then restarted the elog per the instructions on the wiki.

 

  1889   Wed Aug 12 02:00:32 2009 robUpdateLockingreport

Spent a lot of time aligning tonight.  The BS is not staying put--sometimes after a lock loss it gets badly mis-aligned. 

DD handoff is working, after putting beam on REFL diodes and running senseDRM script.

  1888   Tue Aug 11 23:55:04 2009 rana, richSummaryOMCQuantum Efficiency and Dark Current measurements of eLIGO Photodiodes

Rich Abbott, Rana

Summary: We found that the 3mm InGaAs photodiodes from eGTRAN which are being used for the DC Readout in eLIGO are bad. The QE is ~50%. We will have to replace them ASAP.

Valera and Nic Smith have pointed out out a factor of ~2 discrepancy between the estimated power transmission to the dark port in H1 and L1. So we decided to measure the QE of the accused diodes.

 The data of the QE and dark current are attached here.

We used a 1064 nm CrystaLaser (which does not have a very stable power output). We attenuated the light with an ND1.0 for all measurements.

The photocurrent is estimated by reading out the voltage across one leg of the differential drive of the DC PD preamp. The photocurrent goes across a 100 Ohm resistor and then through 2 gain of  1 stages to get to this testpoint, so the overall transimpedance gain is 100 Ohms for this measurement.

By far, the Ophir power meter is the biggest source of error. Its absolute calibration is only 5% and the variation across the sensor face is ~5%. There are some hot and not hot spots on the face which can make even more variation, but we tried to avoid these.

We also inserted the power meter very close to the time when we read the voltage, so that the photocurrent and power estimates are made within 10 seconds of each other. This should reduce the error from the laser's power fluctuations.

All diodes still had the glass case on. We measured the reflected power to be ~5-7% of the incident power. This reflected power is NOT accounted for in these estimates.

 

Punch line: The eGTRAN diodes that we currently use are definitely bad. The JDSU and EG&G 2mm diodes have a better QE. We should immediately purchase 3 mm versions and get them cut and measured to be ready for the Sep. 1 commissioning surge.

Attachment 1: IMG_0135.png
IMG_0135.png
  1887   Tue Aug 11 23:17:21 2009 ranaSummaryComputersNodus rebooted / SVN down

Looks like someone rebooted nodus at ~3 PM today but did not elog it. Also the SVN is not running. Why?

  1886   Tue Aug 11 14:15:28 2009 StephanieUpdateGeneralMultiply Resonant EOM Update

I was able to observe the three sets of modulation sidebands created by the EOM + triply resonant circuit yesterday. Quantitative results will be posted later.

  1885   Tue Aug 11 02:15:20 2009 ClaraUpdatePEMGuralp breakout box circuit diagram

While writing my progress report, I redrew the Guralp breakout box circuit diagram with all the changes marked. Since only one hard copy exists, I thought it might be useful to post my drawing up in case it is needed for any reason. The two drawings are the same - the second has just been broken into two parts to make it easier to fit on a normal 8.5 x 11 or A4 sheet of paper. The gains for each opamp have not been marked, but they could very easily be added in if necessary. The black resistances and capacitances are the originals. All changes have been indicated in blue.

Guralp_circuit_whole.png

Guralp_circuit_broken.png

  1884   Tue Aug 11 01:21:55 2009 robUpdatePSLMZ needs some attention

the servo needs some work. 

 

2 day trend

 

Attachment 1: badMZservo.png
badMZservo.png
  1883   Mon Aug 10 20:49:13 2009 Alberto, RanaUpdatePSLPMC Mode Matching Lenses Tuning

Rana, Alberto

This afternoon we tried to improve the mode matching of the beam to the PMC. To do that we tuned the positions of the two lenses on the PSL table that come before the PMC.

We moved the first lens back an forth the without noticing any improvement on the PMC transmitted and reflected power. Then we moved the first backwards by about one cm (the order is set according to how the beam propagates). That made the things worse so we moved also the second lens in the same direction so that the distance in between the two didn't change significantly. After that, and some more adjustments on the steering mirrors all we could gain was about 0.2V on the PMC transmission.

We suspect that after the problems with the laser chiller of two months ago, the beam size changed and so the mode matching optics is not adequate anymore.

We have to replace the mode matching lenses with other ones.

 

  1882   Mon Aug 10 18:12:25 2009 JenneUpdatePEM2nd set of Guralp channels plugged into ADCU

Quote:

The second set of Guralp channels is now plugged into the PEM ADCU, into channels which are confirmed to be working.  (Method: 1Vpp sine wave into channel, check with DataViewer).

 

Direction, Channel Name, .ini chnum, BNC plug # on ADCU

Vertical: C1:PEM-SEIS_GUR_VERT, 15023, #24

N/S (should be Y when the seismometer is put in place): C1:PEM-TEMP_2, 15001, #2

E/W (should be X when the seismometer is put in place): C1:PEM-TEMP_3, 15002, #3

 

There is IFO work going on, so I don't want to rename the channels / restart fb40m until a little later, so I'll just use the old TEMP channel names for now. 

 

There is something totally wrong with the E/W channel.  I can look at all 3 channels on a 'scope (while it's on battery, so the op-amps in the breakout box aren't grounded), and VERT and NS look fine, and when I jump around ("seismic testing"), they show spikes.  But the EW channel's signal on the 'scope is way smaller, and it doesn't show anything when I jump. 

 

I might use the handheld Guralp tester breakout box to check the seismometer.  Also, a suspicion I have is that whoever put the box back in on Friday night after our final noise measurements left the inputs shorted for this one channel.  It's the 3rd channel in the set, so it would be most likely to be stuck shorted...  Investigations will ensue.

 All the channels are now good, and all the names are back to making sense. 

The problem with EW2 was in fact that the alligator clip used to short the inputs during the noise test Friday night was left in the box.  Not great, but now it's taken care of, and we have recorded data of the noise of the breakout box, so we can include that in our plots to see if we're at the limit of how good we can do at subtracting noise.

 

The channels are now named thusly:

C1:PEM-SEIS_GUR_VERT  (BNC input #24, .ini channel #15023)

C1:PEM-SEIS_GUR_EW     (BNC input #3, .ini channel #15002)

C1:PEM-SEIS_GUR_NS      (BNC input #2, .ini channel #15001)

C1:PEM-SEIS_MC1_X         (BNC input #11, .ini channel #15010)

C1:PEM-SEIS_MC1_Y        (BNC input #12, .ini channel #15011)

C1:PEM-SEIS_MC1_Z       (BNC input #10, .ini channel #15009)

C1:PEM-SEIS_MC2_Y (Ranger, which for the Huddle Test is oriented VERTICALLY)   (BNC input #4, .ini channel #15003)

 

Now we wait.....and tomorrow extract the noise of each of the seismometers from this!

 

 

  1881   Mon Aug 10 17:49:10 2009 peteUpdateComputersRCG work - plans

Pete, Koji

 

We discussed a preliminary game plan for this project.  The thing I really want to see is an ETMX RCG controller hooked into the existing frontend via reflective memory, and the 40 m behaving normally with this hybrid system, and my list is geared toward this.  I suspect the list may cause controversy.

+ copy the MDC filters into SAM, and make sure everything looks good there with DTT and SR785.

+ get interface / wiring boards from Wilson House, to go between megatron and the analog ETMX system

+ test tying the ETMX pendulum and bare-bones SAM together (use existing watchdogs, and "bare-bones" needs defining)

+ work some reflective memory magic and create the hybrid frontend

 

In parallel with the above, the following should also happen:

+ MEDM screen design

+ add non-linear bits to the ETMX MDP/MDC model system

+ make game plan for the rest of the RCG frontend

  1879   Mon Aug 10 17:36:32 2009 peteUpdateComputersRCG work. PIT, YAW, POS in MDP/MDC system

I've added the PIT and YAW dofs to the MDC and MDP systems.  The pendula frequencies in MDP are 0.8, 0.5, 0.6 Hz for POS, PIT, and YAW respectively.  The three dofs are linear and uncoupled, and stable, but there is no modeled noise in the system (yet) and some gains may need bumping up in the presence of noise.  The MDC filters are identical for each dof (3:0.0 and Cheby). The PIT and YAW transfer functions look pretty much like the one Rana recently took of POS, but of course with the different pendulum frequencies.  I've attached one for YAW.

Attachment 1: mdcmdpyaw.jpg
mdcmdpyaw.jpg
  1878   Mon Aug 10 17:27:47 2009 robConfigurationLSCTRX, TRY gain

 

These are the settings which determine the transmon (eg, TRX) amplitude, and which are updated by the matchTransMon scripts.

For the X arm

 

op440m:AutoDither>tdsread C1:LSC-TRX_GAIN C1:LSC-LA_PARAM_FLT_01 C1:LSC-LA_PARAM_FLT_00
0.0023
0.155
119.775

 

For the Y arm

op440m:AutoDither>tdsread C1:LSC-TRY_GAIN C1:LSC-LA_PARAM_FLT_04 C1:LSC-LA_PARAM_FLT_03
0.00237196
-0.116
19.9809


  1877   Mon Aug 10 16:41:31 2009 AlbertoConfigurationPSLPMC Visibility

Alberto, Rana

lately we've been trying to better understand what's preventing the arm power to get high again. Last week I tuned the MZ and the PMC but we didn't gain much, if nothing at all.
Yesterday I measured the transmissivity, the reflectivity and the visibility of the PMC.
 
From the voltages at the PMC-REFL PD when the PMC was locked and when it was out of lock I estimated the cavity visibility:
V_locked = 0.42V
V_unlocked = 1.64V -> V = (V_unlocked - V_locked) / V_unlocked = 75%

With the high power meter I measured the reflected power when the PMC was unlocked and used that to obtain the calibration of the PMC-REFL PD: 1.12V/W.

Since the locked-cavity reflected power can't be directly measured with a power meter (since that would use the cavity control signal), I estimated the reflected power by the calibration of the PMC-REFL PD. Then I measured the input and the transmitted power with a high-power meter.
Result:

P_in = 1.98W ; P_trans = 1.28W ; P_refl = 0.45W

From that I estimated that the losses account to 13% of the input power.

I checked both the new and the old elogs to see if such a measurement had ever been done but it doesn't seems so. I don't know if such a value for the visibility is "normal". It seems a little low. For instance, as a comparison, the MC visibility, is equal to a few percents.

Also Rana measured the transmitted power after locking the PMC on the TEM20-02: the photodiode on the MEDM screen read 0.325V. That means that a lot of power is going to that mode.

That makes us think that we're dealing with a mode matching problem with the PMC.

  1876   Mon Aug 10 16:37:27 2009 robUpdatePSLMZ alignment touched

I aligned the MZ.  The reflection went from .86 to .374

  1875   Mon Aug 10 15:56:12 2009 robSummaryPSLMZ bad redux

Quote:

I think the MZ pzt is broken/failing.  I'm not sure how else to explain this behavior.

 

The first bit of the time series is a triangle wave into the DC offset (output) field, over approximately the whole range (0-250V).   You can see the fringe visbility is quite small.  The triangle wave is stopped, and I then maxed out the offset slider to get to the "high" power point from the triangle wave sweep. Then for a little while with the PZT is held still, and the power still increases.  The MZ is then locked, and you can see the PZT voltage stay about the same but the power continues to rise over the next ~10 minutes or so.

 

 

 

This plot answers the previous question, and raises a new one--what the heck is MZTRANSPD?  I'd guess the pins are unconnected--it's just floating, and somehow picking up the MZ_PZT signal.

 

 

Attachment 1: badMZtrans.png
badMZtrans.png
  1874   Mon Aug 10 15:24:17 2009 robSummaryPSLMZ bad

I think the MZ pzt is broken/failing.  I'm not sure how else to explain this behavior.

The first bit of the time series is a triangle wave into the DC offset (output) field, over approximately the whole range (0-250V).   You can see the fringe visbility is quite small.  The triangle wave is stopped, and I then maxed out the offset slider to get to the "high" power point from the triangle wave sweep. Then for a little while with the PZT is held still, and the power still increases.  The MZ is then locked, and you can see the PZT voltage stay about the same but the power continues to rise over the next ~10 minutes or so.

Attachment 1: brokenMZpzt.png
brokenMZpzt.png
  1873   Mon Aug 10 15:21:15 2009 JenneUpdatePSLNon-Elogged Beam dump on the PSL table - BadBadBad

Quote:

Big thumbs down to whoever put a beam dump on the PSL table in front of the PMC yesterday afternoon without noting it in the elog

The offending beam dump has been removed, and the PMC relocked.

 Maybe it was Russell Crowe

  1872   Mon Aug 10 14:58:01 2009 JenneUpdatePEM2nd set of Guralp channels plugged into ADCU

The second set of Guralp channels is now plugged into the PEM ADCU, into channels which are confirmed to be working.  (Method: 1Vpp sine wave into channel, check with DataViewer).

 

Direction, Channel Name, .ini chnum, BNC plug # on ADCU

Vertical: C1:PEM-SEIS_GUR_VERT, 15023, #24

N/S (should be Y when the seismometer is put in place): C1:PEM-TEMP_2, 15001, #2

E/W (should be X when the seismometer is put in place): C1:PEM-TEMP_3, 15002, #3

 

There is IFO work going on, so I don't want to rename the channels / restart fb40m until a little later, so I'll just use the old TEMP channel names for now. 

 

There is something totally wrong with the E/W channel.  I can look at all 3 channels on a 'scope (while it's on battery, so the op-amps in the breakout box aren't grounded), and VERT and NS look fine, and when I jump around ("seismic testing"), they show spikes.  But the EW channel's signal on the 'scope is way smaller, and it doesn't show anything when I jump. 

 

I might use the handheld Guralp tester breakout box to check the seismometer.  Also, a suspicion I have is that whoever put the box back in on Friday night after our final noise measurements left the inputs shorted for this one channel.  It's the 3rd channel in the set, so it would be most likely to be stuck shorted...  Investigations will ensue.

ELOG V3.1.3-