40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 43 of 335  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  900   Fri Aug 29 12:43:44 2008 josephbSummaryComputersc1susvme1 down
Around noon today, c1susvme was having problems. The C0DAQ_RFMNETWORK light was red. The status light was off, the sig det light was amber and the own data light was green. I could also ssh in, but could not not run startup. I switched off the watchdogs for c1susvme2 (the watchdogs for c1susvme1 had already been tripped), and manually power cycled the crate.

However, when c1susvme1 when it came back up it had not mounted the usual cvs/cds/ directories. c1susvme2 did however. c1susvme1 has been on the new network for awhile, while c1susvme2 was switch over today. So apparently switching networks doesn't help this particular problem.

I did a remote reboot of c1susvme1, and it came up with the correct files mounted. Both machines ran their approriate startup.cmd files and are currently green.
  909   Tue Sep 2 07:58:34 2008 ranaSummaryPSLFSS & PMC LO trends for 2 years
The attached plot is a 2 year minute trend of the EPICS readback of the PMC & FSS LO Monitors (FSS_LODET & PMC_LODET).
Clearly the FSS LO has been dying for at least 2 years. The step up from 10 months
ago is probably when Rob removed a 3dB attenuator from in front of the box.
Attachment 1: psl-lo-trend.png
  914   Wed Sep 3 12:26:49 2008 EricSummaryCamerasWeekly Summary
Finished up simulating the end mirror error in order to test the whether the fitting code still provides reasonable answers despite the noise caused by the defects on the end mirror. The model I used to simulate the defects is far from perfect, but its good enough given the time I have remaining, and I have no reason to believe the differences between it and the real noise would cause any radical changes in how the fit operates. A comparison between a modeled image and a real image is attached. Average error (difference between the estimated value and the real value) for each of the parameters is

For the fit:
Max Intensity: 2767.4 (Max intensities ranged from 8000 to 11000)
X-Position: 0.9401 pixels
X Beam Waist: 1.3406 pixels (beam waists ranged from 35 to 45)
Y-Position: 0.9997 pixels
Y Beam Waist: 1.3059 pixels (beam waists ranged from 35 to 45)
Intensity Offset: 12.7705 (Offsets ranged from 1000 to 4000)

For the center of mass calculation (with a threshold that cut off everything above 13000)
X-Position: 0.0087 pixels
Y-Position: 0.0286 pixels

Thus, the fit is generally trustworthy for all parameters except for maximum intensity, for which it is very inaccurate. Additionally, this shows that the center of mass calculation actually does a much better job than the fit when this much noise is in the image. For the end mirrors, the fit is really only useful for finding beam waist, and even this is not extremely accurate (~3% error). All the parameters for the modeling is on the svn in /trunk/docs/emintun/MatLabFiles/EndMirrorErrorSimulation.txt.

Finished working on the calculations that convert a beam misalignment as measured as a change in the beam position on the two mirrors to a power loss in the cavity. Joe calculated the minimum measurable change in beam position to be around a tenth of a pixel, which corresponds to half a micron when the beam is directly incident on the camera. This gives the ability to measure fractional power losses as low as 2*10^-10 for the 40m main arm cavities. To me, this seems unusually low, though it scales with beam position squared, so if anything else limited the ability to measure changes in the beam position, it would have a large effect on the sensitivity to power losses. Additionally, it scales inversely with length, so shorter cavities provide less sensitivity.

This morning Joe and I tested the ability for the camera code to servo the ITMX in order to change the beam's position on the ETMX. Two major things have been changed since the last time we tried this. First, the calculated beam center that gets output to the EPICS channels now first goes through a transform that converts it from pixels into physical units, and should account for the oblique angle of the camera. The output to the EPICS channels should now be in the form of 'mm from the center of the optic', although this is not very precise at the moment. The second thing that was changed was that the servo was run with a modified servo script that included options to set a minimum, maximum, and slew rate in order to protect the mirrors from being swung around too much. The servo was generally successful: for a given x-position, it was capable of changing the yaw of ITMX so that the position seen on the camera moved to this new location. The biggest problem is that the x and y dimensions do not appear to be decoupled (the transform converting it to physical units should have done this), so that modifying the yaw of the mirror changed both the x and y positions (the y about half as much) as output by the camera. This could cause a problem when trying to servo in both dimensions at once, since one servo could end up opposing the other. I don't know the cause of this problem yet, since the transform that is currently in use appears to be correctly orienting the image.
Attachment 1: SimulatedErrorComparison.png
  939   Wed Sep 10 13:28:25 2008 YoichiSummaryElectronicsIOO rack lost -24V (recovered)
Alberto, Yoichi

This morning, the MC suddenly started to be unwilling to lock.
I found a large offset in the MC servo board.
It turned out that -24V was not supplied to the Eurocard crate of the IOO rack.
We found two loose cables (violet, that means -24V) around the cross connects with fuses.
We connected them back, and the -24V was back.
The MC locks fine now, and Alberto can continue his arm length experiment.
  961   Thu Sep 18 01:14:23 2008 robSummaryComputersEPICS BAD

Somehow the EPICS system got hosed tonight. We're pretty much dead in the water till we can get it sorted.

The alignment scripts were not working: the SUS_[opt]_[dof]_COMM CA clients were having consistent network failures.
I figured it might be related to the network work going on recently--I tried rebooting the c1susaux (the EPICS VME
processor in 1Y5 which controls all the vertex angle biases and watchdogs). This machine didn't come back after
multiple attempts at keying the crate and pressing the reset button. All the other cards in the crate are displaying
red FAIL lights. The MEDM screens which show channels from this processor are white. It appears that the default
watchdog switch position is OFF, so the suspensions are not receiving any control signals. I've left the damping loops
off for now. I'm not sure what's going on, as there's no way to plug in a monitor and see why the processor is not coming up.

A bit later, the c1psl also stopped communicating with MEDM, so all the screens with PSL controls are also white. I didn't try
rebooting that one, so all the switches are still in their nominal state.
  970   Fri Sep 19 01:55:41 2008 ranaSummarySUSSUS Drift Screen Updated
I wrote 2 matlab scripts to update the SUS DRIFT screen:
- setsval.m   uses mDV to get the minute trend from some specified start time
              and duration in the past. It then writes that 'good' value to the
              .SVAL field of the SUSPOS, SUSPIT, and SUSYAW records for all the

- setHILO.m   reads the .SVAL field and then sets the alarm levels and severity
              for the same records given a "sigma" as an argument. i.e. 1 sigma = HIGH,
              2 sigma = HIHI.

Attached is the new screen. WE can now use this to judge when the optics have moved alot.

If someone will edit the BURT .req file to have these subfields
(.HIHI .HIGH .LOW .LOLO .HHSV .HSV .LSV .LLSV) then they will come back after a reboot as well.

Below I'm also attaching the matlab code for people at the observatories who don't have
access to the SVN here.
Attachment 1: infection-3.png
Attachment 2: setsvals.m
function varargout = setsvals(varargin)
% sets the SVAL records for the SUS

debug = 0;

if nargin < 2
  error('Needs 2 arguments.')
elseif nargin > 2
... 56 more lines ...
Attachment 3: setHILO.m
function setHILO(varargin)
%  Ex.  setHILO(1000);
%      this sets the SUS alarm levels to be 1000 counts
%      from the nominal

% 1 for debugging
debug_flag = 0;

if nargin == 1
... 62 more lines ...
  989   Thu Sep 25 02:35:21 2008 ranaSummaryPSLFAST is moving alot
It looks like the FAST signal has started moving a lot - this is partly what inspired us to tune the SLOW loop.

Some of the spiking events happen when people go on the table or the MC loses lock. But at other times it just
spikes for no apparent reason. You can also see from the first plot (9 day 10-minute trend) that there is no
great change in DTEC so we shouldn't be worried about clogging in the NPRO head.

The second plot is a 1 day minute-trend.
Attachment 1: Untitled.png
Attachment 2: Untitled.png
  990   Thu Sep 25 03:12:13 2008 ranaSummaryComputersconlog and linux1
It would be nice to have conlog from outside. Right now its on linux1 and so its unavailable. To
test it for speed we ran the command line conlog on linux1, linux2, and nodus.

It was slightly faster on nodus than linux1, implying that its not a network speed issue. It was
phenomenally slower on linux2.

I used the command '/sbin/lspci -vvv' to check what network cards are installed where. As it turns
out, linux2 has a GigE card, but linux1, our NFS server, has only a 100 Mbit card:
01:08.0 Ethernet controller: Intel Corporation 82562EZ 10/100 Ethernet Controller (rev 01)
        Subsystem: Intel Corporation Unknown device 304a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2000ns min, 14000ns max), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 209
        Region 0: Memory at ff8ff000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at bc00 [size=64]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

We (Joe) need to buy a GigE card for linux1 and to also set up conlog and conlogger to run on Nodus.
  1003   Mon Sep 29 01:19:40 2008 ranaSummaryPSLLaser chiller running a little hot
I looked at it some last night and my suspicion was the ISS. Whenever the ISS switch came on the FAST got a kick.

We should try to disable the MC locking and ISS and see if the FSS/PMC/MZ are stable this way. If so this may be
a problem with the ISS / Current Shunt.
  1005   Mon Sep 29 13:23:40 2008 robSummaryPSLLaser chiller running a little hot

I looked at it some last night and my suspicion was the ISS. Whenever the ISS switch came on the FAST got a kick.

We should try to disable the MC locking and ISS and see if the FSS/PMC/MZ are stable this way. If so this may be
a problem with the ISS / Current Shunt.

My entry about the laser chiller got deleted. The PSL appears to be running with the ISS gain at -5dB, so that's good, but the
chiller is still showing 21+ degrees. It should be at twenty, so there's something causing it to run out of
headroom. We'll know more once Yoichi has inspected the ISS.

In the deleted entry I noted that the VCO (AOM driver), which is quite warm, has been moved much closer to the MOPA.
This may be putting some additional load on the chiller (doubtful given the amount of airflow with the HEPAs on,
but it's something to consider).
  1020   Thu Oct 2 16:44:28 2008 steveSummaryoplevsoptical levers
The idea is to push the UGF to 10 Hz of the TM oplev servos with quiet HeNe laser.
We measured good intensity noise of JDS 1103P in May 2007 and converted most of the TM oplevs to it.
The ITMs still have the noisy 670nm , 1 mW, diode lasers to begin with.
In order to get 1 mW power returning to the qpds I measured the power going to TMs
and returning on qpds ...so we can select the appropriate laser power for the conversion.

40m optical lever lasers:

HeNe laser JDS 1103P, 633nm, linear polarization 500:1,

ETMX: qpd 0.12 mw (4%) reflected of 3 mW,
ETMY: qpd 0.1o (3.8%) " 2.6
BS: qpd 0.02 ( 2.5%) " 0.8
PRM: qpd 0.01 (1.3%) " 0.75
SRM: qpd 0.08 (10%) " 0.8

Coherent 670 nm Diode Lasers VLM-tm, 0.95 mW, linear polarization 100:1,

ITMX: qpd 0.1 mW (11%) reflected back from TM of 0.9 mW
ITMY: qpd 0.04 (7%) " " 0.6

It seems that JDS HeNe laser 633 nm, linear polarization 500:1, 10 mW will do the job
  1021   Thu Oct 2 18:56:19 2008 ranaSummarySUSResistivity of Suspension Wire
Bob and Steve measured the resistance of the suspension wire today:
OD     = 0.0036" =  0.091 mm
Length = 46"     = 1168.4 mm
Resistance     =   33.3 Ohms

resistivity = R * pi * (OD/2)^2
              ----------------- = 1.85e-7 Ohm-meters

This was a batch of California Fine Wire from 2001 (same as used at LHO and LLO).

By comparison the standard tabulated resistivity for steels is (http://hypertextbook.com/facts/2006/UmranUgur.shtml):
                  resistivity (Ohm-meter x 10^-7)
-------------     ----------------
304 Stainless       7.2
316 Stainless       7.4
Cast Steel          1.6

This is all to see whether or not the 60 Hz fields produce forces on the suspension wires via coupling with the Earth's DC field.

  1064   Tue Oct 21 17:52:30 2008 ranaSummaryPSLFSS Photo: early October
This is a photo of the FSS board before Yoichi did his surgery - it was taken with the D40 in macro mode, sitting on the big Gorilla pod.
Attachment 1: fss.jpg
  1113   Tue Nov 4 01:03:01 2008 ranaSummaryPEMperiodic thump noise in MC1_ACC
There seems to be a periodic thump seen by the MC1 Accelerometers as well as the surrounding optics.

The first 5 hour minute-trend plot shows the periodic thumping as well as the one large saturating event which ruins the
Wiener noise subtraction.

The second plot is a 30 minute second-trend zoom in.
Attachment 1: Untitled.png
Attachment 2: Untitled2.png
  1142   Mon Nov 17 20:47:19 2008 CarynSummaryGeneralDrove MC at 28kHz to excite drum modes
Rana, Alberto and I observed drum mode frequencies at 23.221kHz(MC1), 28.039kHz(MC2), 28.222kHz(MC3) while driving the mode cleaner. We observed no peaks when we didn't drive the mode cleaner. We used the SR785 to send a ~80mV noise signal in the 28-28.2kHz band to the mode cleaner mirrors via 1Y4-MC1,2,3-POSIN. Then we looked at 1Y2-Mode Cleaner-Qmon on the SR785 and saw peaks.
  1157   Fri Nov 21 21:28:32 2008 ranaSummaryComputersc0daqawg restart
A few minutes after restarting fb0 for the Guralp channels, the DAQAWG lights went red on the DAQ screens.
Why?? I chose revival procedure #3 for c0daqawg from the Wiki and it came back in a couple minutes.
  1167   Tue Dec 2 19:18:10 2008 ranaSummaryPEMRanger SS-1
In entry http://dziban.ligo.caltech.edu:40/40m/881 and a follow up from Jenne I put in the Ranger calibration.
Since then, we've reduced the SR560 gain from 200 to 100 so the calibration factor is now:

1e-9 (m/s)/count and then 2 poles at 0 Hz, and a Q~1 zero pair at 1 Hz.
in DTT:
G = 1e-9
p = 0, 0
z = 0.7 0.7
  1180   Fri Dec 5 14:13:41 2008 ranaSummaryIOOMC trend for the last 4 days
The MC has stayed locked for ~3 days! I just broke it to reset the MZ.
Attachment 1: g.png
  1185   Mon Dec 8 00:10:42 2008 carynSummaryGeneralcalibrating the jenne laser
I apologize in advance for the long list of numbers in the attachment. I can't seem to make them hide for some reason.

So, since Jenne's laser will probably be used for the Stoch mon calibration, Alberto and I took some measurements to calibrate Jenne's laser.
We focused the beam onto the New Focus RF 1GHz photodetector that we stole from rana's lab (powered with NewFocus power 0901). Measured the DC output of the photodetector with scope. Aligned the beam so DC went up (also tried modulating laser at 33MHz and aligning so 33MHz peak went up). Hooked up the 4395a Spectrum/Network Analyzer to the laser and to the AC out of the photodetector (after calibrating Network analyzer with the cables) so that the frequency response of the laser*photodetector could be measured.
(Note: for a while, we were using a splitter, but for the measurements here, I got rid of the splitter and just sent the RFout through the cables to channel A for the calibration, sent RFout to the laser and photodetector to channel A for the measurement)

Measured the frequency response. At first, we got this weird thing with a dip around 290MHz (see jcal_dip_2_norm.png below).
After much fiddling, it appeared that the dip was from the laser itself. And if you pull up just right on the corner of this little metal flap on the laser (see picture), then the dip in the frequency response seems to go away and the frequency response is pretty flat(see jcal_flat_3_norm below). If you press down on the flap, the dip returns. This at least happened a couple of times.
Note that despite dividing the magnitude by the DC, the frequency responses don't all line up. I'm not sure why. In some cases the DC was drifting a bit(I presume the laser was coming out of alignment or decided to align itself better) and maybe with avgfactor=16, and measuring mean DC on the scope, it made the DC meas not match up the the frequ resp meas...
I've attached the data for the measurements made (I'm so sorry for all the #'s. I can't figure out how to hide them)
name/lasercurrent/DC/analyzer SourcePower/analyzer avgfactor
Note also that the data from the 4395a seems to have column1-frequency, column2-real part, column3-imaginary part...I think. So, to calculate the magnitude, I just took (column2)^2+(column3)^2.

To get sort of an upper-bound on the DC, I measured how DCmax varied with laser current, where DCmax is the DC for the best alignment I could get. After setting the current, the laser was modulated at 33MHz and the beam was aligned such that the 33MHz peak in the photodetector output was as tall as I could manage. Then DC was measured. See IvsDCmax.png. Note the DC is negative. I don't know why.

Also, the TV's don't look normal, the alarm's going off and I don't think the mode cleaner's locked.
Attachment 1: IvsDCmax.png
Attachment 2: data.tar.gz
Attachment 3: jcal_dip_2_norm_log.png
Attachment 4: jcal_flat_3_norm_log.png
  1186   Mon Dec 8 11:41:27 2008 YoichiSummaryVACThe rough pump for the TP2 replaced
Bob, Yoichi

The foreline pressure of the TP2 (the foreline pump for the main mag-lev turbo (TP1)) was at 2.8torr this morning
when Bob came in.
Looked like the foreline pump (Varian SH-110) was leaking.
Bob started the backup rough pump in parallel with the "leaking" one to keep the foreline pressure low.
We then closed the valve 4 (between TP2 and TP1) and stopped the TP2 and the SH-110.
We replaced SH-110 with another one, but still the foreline pressure was high.
So we replaced it with yet another one. We also changed the quick coupling fasteners on the SH-110 and wiped the O-rings.
This time, it worked fine and the foreline pressure dropped to around 38 mTorr.

Since there is no valve between the TP2 and the SH-110, we could not keep the TP2 running while we were replacing the
problematic SH-110. This means the TP1 was running without a foreline pump during the work. We tried to minimize the
down time of the TP2. The temperature of the TP1 was 33.6C before we stopped the TP2 and it went up to 37.3C during the
work. It is now coming down to the original temperature.

Since we don't know if the problem was caused by bad SH-110s or leaking quick couplings, Bob is checking these apparently
"leaking" SH-110s.
  1189   Tue Dec 9 10:48:17 2008 CarynSummaryGeneralcalibrating the jenne laser: impedance mismatch?

We sent RFout of network analyzer to a splitter, with one side going back to the network analyzer and the other to the laser modulation input. We observed a rippled transfer function through the splitter. The ripple is probably due to reflection due to an impedance mismatch in the laser.
Attachment 1: reflection.png
  1209   Wed Dec 31 22:59:40 2008 YoichiSummaryEnvironmentParticle counts going crazy
Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1211   Thu Jan 1 01:07:03 2009 YoichiSummaryEnvironmentParticle counts going crazy
I increased the fan speed of the PSL HEPA filter to the maximum.

Yes it is a new year's eve, and a lot of crazy people are on Colorado to secure seats for the parade tomorrow.
They are burning woods to warm themselves. So smoky smell is floating around in the campus
and naturally the particle count is going up.

Actually at first I thought some building is on fire and called the security. Then they found
that it is the people on Colorado.

Now C1:PEM-count_half is 28400 and it is still climbing up.
  1212   Thu Jan 1 01:15:45 2009 YoichiSummaryVACN2 line leak ?
I've been replacing the N2 bottles recently.
I noticed that the consumption is too high. I had to replace them every two days.
Normally the interval is three or more days.
I suspect there is some leak in the line.

Strangely, it is always the left hand bottle which goes empty. The right hand bottle has been
there for more than a week at about 1000 psi.

We should check it when Steve is back.
  1213   Fri Jan 2 17:20:44 2009 ranaSummaryComputer Scripts / Programs40m GWINC
I have made a '40m' directory in the iscmodeling CVS tree which allows one to run a 40m version of GWINC.

As does the previous one, it takes the default advLIGO config file and modifies some of the struct parameters
to make it appropriate for the 40m.

To make it run, I have added susp1.m to the GWINC directory. This calculates suspension thermal noise using
the Gonzalez-Saulson method that was later extended to
mirrors by Y. Levin. This is also the code used in the LIGO Noise Budget at the sites.

The previous code was giving a much larger value for thermal noise (probably because I didn't understand how
to use it right). It was based on a SURF report from '99.

Since we will have a mixture of MOSs and SOSs in the arms, I have just used SOSs in the model. So the suspension
thermal noise is overestimated by ~sqrt(2) (and realistically its uncertain by a much larger factor).

Since the new code now uses GWINC, the mirror and coating thermal noise are now more correct and use the
coherent therm-optic noise picture.

The 2 page PDF file shows the noise for 0 deg and 90 deg tuning of the SRC.

Although it looks like, from this plot, that we could measure coating thermal noise at the 40m, in reality we would have
to fix all of the technical noise sources first. Just the coil driver noise is probably at the level of 3 x 10^-17 m/rHz
at 100 Hz.
Attachment 1: bench40.pdf
bench40.pdf bench40.pdf
  1235   Fri Jan 16 18:33:54 2009 YoichiSummaryComputersc1lsc rebooted to fix 16Hz glitches
Kakeru, Yoichi

There were 16Hz harmonics in the PD3 and PD4 channels even when there is no light falling on it.
Actually, even when the connection to the ADC was removed, the 16Hz noise was still there.

Rob suggested that this might be digital problem, because data is sent to the daq computer very 1/16 of a second.

We restarted c1lsc and the problem went away.
  1280   Fri Feb 6 14:49:31 2009 steveSummarySAFETYlaser inventory
40M Laser Inventory at Feb 05, 2009

1, Lightwave PA#102 @ 77,910 hrs 1064nm of 2.8W @ 27.65A
                   NPRO#206 @ 2.4A                    at PSL enclosure............"Big Boy" is waiting for to be retired but not now.

2, Lightwave  NPRO 1064nm of 700mW  #415   at AP table.......cavity length measurements of Alberto

3, CrystaLaser  IRCL-100-1064S, 1064nmS of 100mW  ,sn#IR81132 at east arm cabinet

4, CrystaLaser 1064nm of 180mW # -1274 flq at scattering setup.........flashlight quality

5, RF-PD tester 1064nm of 1.2mW @20mA at SP table

6, Lumix 800-1100nm of 500mW at east arm cabinet

7, JDS-Uniphase 633nmP of 4mW oplev sus laser at 5 places,
    plus four spares in east arm cabinet
The same information is posted at the 40M WIKI also
  1297   Thu Feb 12 14:39:07 2009 ranaSummaryGeneralSilicon Beam Dump test
Yesterday evening, Ken Mailand and I tested the reflectivity of a piece of polished Silicon. Since Silicon has such a high thermalconductivity (compared to stainless and fused silica) and can take much more heat than black glass and should have a very good BRDF and should absorb most of the 1064 nm light if we hit it at Brewster's angle, we want to try it out in the first version high power, low scatterbeam dump. This dump will be a 'V' style dump like what Steve has tested nearly a year ago, but the incoming beam will first hit this piece of Silicon.

The pictures of the setup and the Silicon with the beam hitting it are here.

Brewster's angle for p-pol at 1064 nm is 74.2 deg (n = 3.53 @ 1064 nm). We set up a cube polarizer on the output of the ~1064 nm CrystaLaser. 144 mW got to the Si; the reflected beam was ~1.9-2.0 mW after tuning the angle for minimum power. Via eyeball and protractor it seems that we're at ~74 deg. So the reflectivity is < 1.5-2%. This is good enough; the reflected power will be < 1 W in all cases for eLIGO and that can be absorbed by the rest of the stainless V dump. The 35 W of heat in the silicon will be mostly gotten rid of through conduction into the attached heat sink fins.

This kind of dump would go into places like the PMC-REFL, MC-REFL, & IFO-REFL, where we occasionally need to take high power, but also are sensitive to backscatter.
  1331   Sun Feb 22 23:43:07 2009 carynSummaryGeneraltemperature sensor


So, to compare temp channels, I made a plot of PSL-FSS_RMTEMP and PEM-MC1_TEMPS(the test temp sensor channel after converting from cts to degC). This plot begins about 2 months ago t_initial=911805130. The temperature channels look kinda similar but MC1-TEMPS (the temp sensor clamped to MC1,3 chamber) is consistently higher in temperature than FSS_RMTEMP. See compare_temperature_channels.png.

MC1-TEMPS isn't exactly consistent with FSS-RMTEMP. I attached a few plots where I've zoomed in on a few hours or a few days. See compare_temperature_channels_zoom1.pdf & compare_temperature_channels_zoom2.pdf

Change the room temperature, see what happens to the chamber temperature

A while ago, somebody was fiddling around with the room temperature.  See compare_temperature_channels_zoom4.pdf.  This is a plot of PEM-MC1_TEMPS and PSL-FSS_RMTEMP at t0=911805130. You can see the chamber heating up and cooling down in happy-capacitory-fashion. Although, the PSL-FSS_RMTEMP and the PEM-MC1_TEMPS don't really line up so well. Maybe, the air in the location of the MC1,3 chamber is just warmer than the air in the PSL or maybe there's an offset in my calibration equation.

Calibration equation for PEM-MC1-TEMPS

For the calibration (cts to degC) I used the following equation based on the data-sheet for the LM34 and some measurements of the circuit:


How does the chamber temperature compare with the air temperature?

It looks like the chamber may be warmer than the air around it sometimes.

I wanted to check the temperature of the air and compare it with the temperature the sensor had been measuring. So, at t=918855087 gps, I took the temp sensor off of the mc1-mc3 chamber and let it hang freely, close to the chamber but not touching anything. See compare_temperature_chamber_air.png. MC1_TEMPS increases in temperature when I am handling the temp-sensor and then cools down to below the chamber temperature, close to FSS_RMTEMP, indicating the air temperature was less than the chamber temperature.

 When, I reattached temp sensor to the chamber at t=919011131 gps, the the temperature of the chamber was again higher than the temperature of the air. See compare_temperature_air2chamber.pdf.

Also, as one might expect, when the temp-sensor is clamped to the chamber, the temperature varies less, & when it's detached from the chamber, the temperature varies more. See compare_temperature_air_1day.pdf & compare_temperature_chamber_1day.pdf.

New temp-sensor power supply vs old temp-sensor power supply

The new temp-sensor is less noisy and seems to work OK. It's not completely consistent with PSL-FSS_RMTEMP, but neither was the old temp-sensor. And even the air just outside the chamber isn't the same temperature as the chamber. So, the channels shouldn't line up perfectly anyways.

I unplugged the 'old' temp-sensor power supply for a few hours and plugged in the 'new' one, which doesn't have a box but has some capacitors and and 2 more voltage regulators. The MC1_TEMPS channel became less noisy. See noisetime.png & noisefreq.pdf. For that time, the minute trend shows that with the old temp-sensor power supply the temp sensor varies +/-30cts and with the new power supply, it is more like +/-5cts (and Volt/16,384cts * 1degF/10mV -->  apprx +/-0.03degF). So, it's less noisy. 

I kept the new temp-sensor power supply plugged in for about 8 hours, checking if new temp sensor power supply worked ok. Compared it with PSL-FSS_RMTEMP after applying an approximate calibration equation. See ver2_mc1_rmtemp_8hr_appxcal.png.

Just for kicks

Measuring time constant of temp sensor when detached from chamber. At 918858981, I heated up the temp sensor on of the mc1-mc3 chamber with my hand. Took hand off sensor at  918859253 and let it cool down to the room temperature. See temperature_sensor_tau.pdf. 

Attachment 1: compare_temperature_channels.png
Attachment 2: compare_temperature_channels_zoom1.pdf
Attachment 3: compare_temperature_channels_zoom2.pdf
Attachment 4: compare_temperature_channels_zoom4.pdf
Attachment 5: compare_temperature_chamber_air.png
Attachment 6: compare_temperature_air2chamber.pdf
Attachment 7: compare_temperature_air_1day.pdf
Attachment 8: compare_temperature_chamber_1day.pdf
Attachment 9: noisetime.pdf
Attachment 10: noisefreq.pdf
Attachment 11: ver2_mc1_rmtemp_8hr_appxcal.pdf
Attachment 12: temperature_sensor_tau.pdf
  1338   Thu Feb 26 00:36:53 2009 YoichiSummaryComputersC1:LSC-TRX_OUT broken (and fixed later).
Today, Kakeru tried to convert C1:LSC-TRX_OUT and C1:LSC-TRY_OUT to DAQ channels.
He edited C1LSC.ini in the chans/daq directory to add the channel but it did not work.
Then he reverted the file back to the original one.
But after we still could not access these channels from dataviewer nor tds tools.
We restarted daqd and tpman on fb40m, but the problem persisted. Even rebooting the whole fb40m did not help.
After inspecting the log file of daqd, it was clear that tpman was failing to create test points for those channels.
I rebooted c1daqawg and then restarted tpman and daqd on fb40m again.
This time, the problem went away.
  1367   Fri Mar 6 18:22:42 2009 YoichiSummaryComputersScripts to restart the FE computers
While doing locking, the FE computers are overloaded sometimes and I have to reboot them.
Being sick of logging into the FE computers one by one to start front end codes, I wrote scripts to do this automatically.
The scripts are in /cvs/cds/caltech/scripts/FE/.
For example, you can restart c1lsc by typing
restartFE c1lsc
You can give multiple computer names to the restartFE command like,
restartFE c1lsc c1asc c1susvme1

To restart all the FE computers, type
restartFE all

For the scripts to work properly, the computers have to accept login, i.e. you either have to power cycle the computers or push "Reset" buttons on the RFMNETWORK medm screen prior to running the scripts.
  1383   Wed Mar 11 01:16:40 2009 ranaSummaryIOOrogue trianglewave in the MC Servo offset slider

On Monday evening, I ran this command: trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET 1.76

which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds. In actuality, the last argument is the

run time in number of periods. So the offset slider has been changing by 8 Vpp for most of the last day. Oops. The attached image shows what effect

this had in the MC transmitted power (not negligible). This would also make the locking pretty difficult.


In the second plot you can see the zoom in view for ~30 minutes. During the first part, the MCWFS are on and there are large fluctuations

in the transmitted power as the WFS offset changes. This implies that the large TEM00 carrier offset we induce with the slider couples into

the WFS signals because of imbalances in the quadrant gains - we need someone to balance the RF gains in the WFS quadrants by injecting

an AM laser signal and adjusting the digital gains.


Since there is still a modulation of the MC RFPD DC with the WFS on, we can use this to optimize the REFL OFFSET slider. The third plot

shows a 8 minute second trend of this. Looks like the slider offset of zero would be pretty good.

Attachment 1: Untitled.png
Attachment 2: Untitled.png
Attachment 3: a.png
  1415   Sun Mar 22 22:39:24 2009 ranaSummaryLSCCalibration of the ITM and ETM Actuation
I used the following procedure to calibrate the ITMX actuation signal.

Free Swinging Michelson:
- Restore Michelson
- Align Michelson: Minimize AS_DC (PD3_DC_OUT) by tweaking BS alignment.
- Enable Whitening filters for PD1_Q and PD3_DC.
- Run offsets script to get rid of DC and RF offsets.
- Use DTT Triggered Time Series to get time series and measure peak-peak
amplitude of PD1_Q using DTT horizontal cursors. (Templates/Calibration/090322/FreeSwing.xml)

Michelson Sweeps:
- Lock Michelson
- Drive ITMX_LSC_EXC using ITMX-MI-Sweep.xml template.
- (Next time remember to turn on a low pass in the MICH loop so that its an open loop measurement below 50 Hz).
- Fit and so some math.

Arm Sweeps for the ETMs:
- Lock a single arm
- Sweep ITM & ETM.
- Then sweep MC2 and record drive signal from MC board to the VCO driver.
- Compare and contrast.
Attachment 1: free.png
  1425   Wed Mar 25 01:37:35 2009 rana, yoichiSummaryIOONo Reference Cavity Required
We were wondering if we need to have a reference cavity. One possible reason to have one is to reduce the free running
frequency noise by some level so that the MC can handle it. According to my manifesto,
the free running noise of the laser is (10 kHz / f) Hz/rHz. The mode cleaner loop gain is sufficient to reduce this to
0.001 Hz/rHz everywhere below 1 kHz - radiation pressure noise and coating thermal noise limit the mode cleaner below
these levels.

So, since it seems like the reference cavity is superfluous (except for the 1 - 10 kHz band), we unlocked it and locked the
MC by feeding back directly to the laser.

In the old set up, the low frequency feedback is to MC2 and the high frequency to the VCO which actuates the FSS which
drives the NPRO PZT and the Pockel cell.

In this new way, we take the MC board's output to the VCO (the TNC monitor point) and send that to the TEST IN1 of the FSS
box. The FSS box then splits the drive to go to the PZT and the PC path. We also turned off the 40:4000 filter in the MC
board and inverted the sign of the MC FAST path.
Good settings for acquisition:
40:4000        Disable
FAST polarity  MINUS
VCO Gain       -3 dB
MC LIMITER     Disable

FSS CG         -3 dB
FSS FG         13 dB

After our initial locking success, we realized that the new MC-FSS loop is conditionally stable: the old loop relied on
the 40 kHz refcav pole to make it stable. The new loop has a 4 kHz pole and so the phase lag in the MC-PZT path is too
much. We need to build a passive lead filter (40 kHz : 4 kHz) in a Pomona box to compensate.

There are several more issues:

- I think this will make the whole CM servo handoff easier: there is no more handoff.

- This will make the lock acquisition fringe velocity higher by a factor of the arm/mc length (40 m / 13 m) since
the frequency will be slewing around along with MC2 now. However, Jenne's FF system ought to take care of that.

- Having the laser frequency stabilized to the MC during lock acquisition will make all of the error signals quieter
immediately. This can only be good.

- If we can make this work here, it should translate to the sites directly since they have exactly the same electronics.
  1435   Fri Mar 27 02:40:06 2009 peteSummaryIOOMC glitch investigation

Yoichi, Pete

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

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

The test channels:

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

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

LR coil      C1:PEM-OSA_SPTEMP


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

We closed the PSL shutter and killed the MC autolocker.

Attachment 1: MC1_Drift.png
  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.
  1465   Thu Apr 9 23:11:27 2009 robSummaryLockingLaser PM to PO-DC transfer functions at multiple CARM offsets

I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise.  There are transfer functions for multiple CARM offsets.  Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere.  POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer.  We should look into switching back to REFL-DC.


Attachment 1: CARMoffs1.png
Attachment 2: CARMoffs2.png
Attachment 3: CARMcarpet.png
  1466   Thu Apr 9 23:20:35 2009 robSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets


I've plotted some transfer functions showing the response at POB DC to laser frequency (phase) noise.  There are transfer functions for multiple CARM offsets.  Basically, the transfer function looks like the DARM transfer function when the CARM is at zero offset, and is super-wonky elsewhere.  POB-DC is not a good CARM signal for intermediate stages of lock acquisition in a dual-recycled interferometer.  We should look into switching back to REFL-DC.


 Here are the corresponding transfer functions for REFL-DC.

Attachment 1: CARMoffs1_r.png
Attachment 2: CARMoffs2_r.png
Attachment 3: CARMcarpet_r.png
  1468   Fri Apr 10 03:10:08 2009 ranaSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets

I hereby award the previous rainbow transfer functions the plot innovation of the month award for its use of optical frequency to denote CARM offset.

The attached movie here shows the sensing matrix (minus MICH) as a function of CARM offset. There are 3 CARM signals plotted:

GREEN - tonights starting CARM signal - REFL_DC

RED - my favorite CARM signal - REFL 166 I

CYAN - runner up CARM signal - POX 33 I

  1476   Sun Apr 12 19:31:43 2009 ranaSummaryElectronicsAmphony 2500 Headphones
We bought the Amphony 2500 Digital Wireless headphones recently. The other cheapo headphones we have are OK for control room use, but have a lot of noise
and are, therefore, not useful for noise hunting.

The new digital ones are pretty much noise-free. With the transmitter next to rosalba, you can walk halfway down the east arm and all around the MC area
before the reception goes bad. For real noise hunting, we will want to put the transmitter next to the BS chamber and take an analog pickoff from the DC PDs.

In the OMC diagram, we should put an AUDIO filterbank and wire it to the DAC so that we can do arbitrary IIR filtering on the audio signal.
  1500   Mon Apr 20 18:17:44 2009 robSummaryLockingCARM offset/Power rubric

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

Attachment 1: ARMpowersCARM.png
  1505   Mon Apr 20 23:27:59 2009 ranaSummaryVACc1vac2 rebooted: non-functional for several months
We found several problems with the framebuilder tonight. The first symptom was that it was totally out of
disk space. The latest daqd log file had gone up to 500 MB and filled the space. The log file was full of
a lot of requests from my seisBLRMS.m code, but what was really making it so big was that it couldn't
connect to c1vac2 (aka scipe4) to make connections for some channels.

We looked into the daqd log files and this has been going on since at least December. There were several
'whited out' records for TP2 and TP3 in the Vacuum overview as well as the Checklist screen! Why did no
one notice this and fix it??
WE cannot function if we just ignore any non-functioning displays and say
"Oh, that never worked."

For sure, we know that it was working in 2005. Jay and Steve and Alan looked at it.

Today it was responding to ping and telnet, but not allowing any new connections. I hit the RESET button
on it. Several lights went RED and then it came back up. The readbacks on the EPICS screens are OK too.

I went into fb0 and deleted many of the GB size log files from the past several months. There is now
19GB free out of its local 33GB disk.
  1510   Thu Apr 23 16:35:23 2009 YoichiSummaryComputer Scripts / ProgramsrestoreWatchdog script
When the IFO loses lock during the lock acquisition steps, it often kicks the MC2 (through the CM servo) and trips the watchdog.
I wrote a script to restore the tripped watchdog (/cvs/cds/caltech/scripts/SUS/restoreWatchdog).
The script takes the name of a mirror (such as MC2) as an argument.
It will enable the coils and temporarily increase the watchdog threshold to a value higher than the current OSEM RMS signals.
Then it will bring the watchdog back to the normal state and wait for the mirror to be damped. After the mirror is damped enough, the
watchdog threshold will be restored to the original value.
The script will do nothing if the watchdog is not tripped.
I put this script in the drdown_bang so that the MC2 watchdog will be automatically restored when a lock loss kicks out the MC2.
  1513   Thu Apr 23 21:13:37 2009 YoichiSummaryEnvironmentMag. 4 earthquake in LA tripped the watchdogs of the most optics
So far, no damage is noticeable.
restoreWatchdog script was useful Smile
Magnitude    4.0
Date-Time    * Friday, April 24, 2009 at 03:27:50 UTC
             * Thursday, April 23, 2009 at 08:27:50 PM at epicenter 
Location     33.910N, 117.767W
Depth	     0 km (~0 mile) (poorly constrained)
  1538   Fri May 1 18:24:36 2009 AlbertoSummaryGeneraljitter of REFL beam ?
Some loud thinking.
For the measurement of the length of the PRC, I installed a fast photodiode in the path of the beam reflected by PRM which goes to the 199 PD on the AS table. I picked up the beam by a flipping mirror on the same table.
I have the problem that the DC power that I measure at the PD when the PRC is locked is not constant but fluctuates. This fluctuation is irregular and has a frequency of about one Hz or so. I.e. it makes the 33 Mhz line on the PD oscillate by +/- 10 dBm.
Since this fluctuation does not appear at the REFL 33 PD, which has a much larger surface, but also shows up on the REFL 199 PD, I suspected that it was due to the very small size of the fast PDs. If the spot is too large, I thought, the power on the PD should be affected by the beam jitter.
Trying to avoid any beam jitter, I placed two lenses with focal lengths one ten times the other on the optical path in such a way to reduce the spot size on my fast PD by the same factors. The DC power was still fluctuating, so I'm not sure it's beam jitter anymore.
SPOB is definitely not constant when the PRC is normally locked, even with high loop gains, so maybe the reflected power really fluctuates that much.
Although, if it's actually the DC power that is fluctuating, shouldn't it appear also at the REFL 33 and shouldn't it be a problem that it shows up also in REFL 199? The elog doesn't say anything about that.

It's crucial that I get a stable transmitted power to have an accurate measurement of the PRC transmissivity and thus of its macroscopic length.

  1539   Fri May 1 18:51:34 2009 AlbertoSummaryEnvironmentearthquake

Earthquake 4.4 Leo Carrillo Beach.

Some of the watchdogs tripped out.

  1552   Wed May 6 19:04:11 2009 ranaSummaryVACvac images
Since there's no documentation on this besides Steve's paper notebooks...

and BTW, since when did the elog start giving us PNG previews of PDFs?
Attachment 1: vacrack.pdf
  1563   Fri May 8 04:46:01 2009 rana, yoichiSummaryoplevsBS/PRM/SRM table bad!
We went to center the oplevs because they were far off and found that (as usual) the numbers changed
a little after we carefully centered the oplevs and came back to the control room.

To see if the table was on something soft, we tried pushing the table: no significant effect with ~10 pounds of static force.

With ~10 pounds of vertical force, however, we saw a large change: ~0.25 Oplev units. This corresponds to
~20-30 microradians of apparent optic pitch.

In the time series below you can see the effects:

2.5 s: lid replaced on table after centering.

2.5 - 11 s: various force tests on table

11 s: pre-bias by aligning beams to +0.25 in pitch and then add lid.

So there's some kind of gooey behavior in the table. It takes ~1 s to
settle after we put the lid on. Putting the laptops on the table also
has a similar effect. Please do not put anything on this table lid.
Attachment 1: a.png
  1579   Wed May 13 02:53:12 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

  1582   Wed May 13 14:43:29 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)


We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

 Lies!  The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday.   So we'll try a hard-reboot.

Attachment 1: MC3sidemon.png
ELOG V3.1.3-