40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 273 of 344  Not logged in ELOG logo
ID Date Author Typedown Category Subject
  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

Comparing  PSL-FSS-RMTEMP and PEM-MC1-TEMPS

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:

TEMPERATURE[degC]=5/9*(((-CTS/16384/451.9/1.04094)-(.0499*10^-3))/(20*10^-6)-35);

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
compare_temperature_channels.png
Attachment 2: compare_temperature_channels_zoom1.pdf
compare_temperature_channels_zoom1.pdf
Attachment 3: compare_temperature_channels_zoom2.pdf
compare_temperature_channels_zoom2.pdf
Attachment 4: compare_temperature_channels_zoom4.pdf
compare_temperature_channels_zoom4.pdf
Attachment 5: compare_temperature_chamber_air.png
compare_temperature_chamber_air.png
Attachment 6: compare_temperature_air2chamber.pdf
compare_temperature_air2chamber.pdf
Attachment 7: compare_temperature_air_1day.pdf
compare_temperature_air_1day.pdf
Attachment 8: compare_temperature_chamber_1day.pdf
compare_temperature_chamber_1day.pdf
Attachment 9: noisetime.pdf
noisetime.pdf
Attachment 10: noisefreq.pdf
noisefreq.pdf
Attachment 11: ver2_mc1_rmtemp_8hr_appxcal.pdf
ver2_mc1_rmtemp_8hr_appxcal.pdf
Attachment 12: temperature_sensor_tau.pdf
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
Untitled.png
Attachment 2: Untitled.png
Untitled.png
Attachment 3: a.png
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
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:
MC INPUT GAIN = 6 dB
40:4000        Disable
FAST polarity  MINUS
VCO Gain       -3 dB
MC LIMITER     Disable

FSS TEST1      TEST
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

LR input   C1:PEM-OSA_APTEMP

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

We closed the PSL shutter and killed the MC autolocker.

Attachment 1: MC1_Drift.png
MC1_Drift.png
  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
CARMoffs1.png
Attachment 2: CARMoffs2.png
CARMoffs2.png
Attachment 3: CARMcarpet.png
CARMcarpet.png
  1466   Thu Apr 9 23:20:35 2009 robSummaryLockingLaser PM to REFL-DC transfer functions at multiple CARM offsets

Quote:

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
CARMoffs1_r.png
Attachment 2: CARMoffs2_r.png
CARMoffs2_r.png
Attachment 3: CARMcarpet_r.png
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
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)
Region	     GREATER LOS ANGELES AREA, CALIFORNIA
-------------------------------------------------------
  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
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
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)

Quote:

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
MC3sidemon.png
  1583   Wed May 13 21:15:04 2009 ranaSummarySUSChannel Hopping: That ancient enemy (MC problems)
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.
  1584   Thu May 14 00:15:39 2009 robSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.
Attachment 1: sidemon.png
sidemon.png
  1586   Thu May 14 15:28:28 2009 steveSummarySUSApril 24 earthquake effect on MC2

Quote:

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.



Only MC2 moved in this earth quake. Was the MC alignment touched up since than?
Have you guys swapped satellite amp of MC3 yet?
Attachment 1: eq042409.jpg
eq042409.jpg
  1587   Thu May 14 16:07:20 2009 peteSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.


I wonder if this is still a problem. It has been quiet for a day now. I've attached a day-long trend. Let's see what happens.
Attachment 1: mc3_5days.jpg
mc3_5days.jpg
  1598   Mon May 18 02:18:17 2009 ranaSummarySEIUsing STACIS w/ a good position sensor
WE turned off STACIS a few years ago because we noticed that it was causing noise below a few Hz and making
the overall velocity between the ends higher than with them off. I'm pretty sure they were causing noise
because they use little geophones which are noisy. Below ~0.2 Hz the horizontal geophones are also probably
limited by tilt-horizontal coupling.

Another concept (based on discussion with Brian Lantz and Matt Evans) is to instead put a good position sensor
between the ground and then blue support beam. Since the the STACIS rubber acts like a Q~2 passive resonance at
20 Hz, the whole seismic system (including the blue beams, in-vac tubes, and internal stack) act like a proof
mass of a seismometer.

So, in principle, if we use a very good position sensor and feedback to the STACIS piezo actuators, we can cancel
the ground motion before it enters the stacks. The initial LIGO OSEMs have a noise of 10^-10 m/rHz above 10 Hz
and going up like 1/f below 10 Hz. The AdvLIGO BOSEMs have a noise of ~2x better. Even better, however, are the
UK's EUCLID interferometric OSEMs (developed by Stuart Aston and Clive Speake).

In the attached plot, I show what we can get if we use these EUCLIDs make a ~60 Hz BW feedback loop w/ STACIS.

BLACK   - raw ground motion measured by the Guralp
MAGENTA - motion after passive STACIS (20 Hz harmonic oscillator with a Q~2)
GREEN   - difference between ground and top of STACIS
YELLOW  - EUCLID noise in air
BLUE    - STACIS top motion with loop on (60 Hz UGF, 1/f^2 below 30 Hz)
CYAN    - same as BLUE, w/ 10x lower noise sensor

One of the SURF projects this summer is to put together a couple different sensors like EUCLID to understand the noise.
Attachment 1: stacis40.png
stacis40.png
  1608   Tue May 19 16:08:03 2009 ranaSummarySEIEUCLID
From Stuart Aston, I've attached a picture of the EUCLID position sensor:
Attachment 1: Picture_6.png
Picture_6.png
  1618   Thu May 21 18:21:57 2009 ranaSummaryTreasureYoichi's words

Yoichi's final words on what do next with the interferometer (as of 5 PM on May 21, 2009):

  1. Measure laser noise couplings in spring and anti-spring configurations.
  2. Dewhitening filter turn on for the ETMs.
  3. Noisebudget - import from the sites.
  4. Stabilize CM handoff.

My personal sub-comments to these bullets:

  1. For the laser noise I'm not sure that we will be able to understand these if the couplings are mainly from junk light due to accidental HOM resonances.
  2. WE should look into putting a static passive stage of filtering into the ETMs if warranted by the NB.
  3. Because of the sad track record with this, I will start us off this time by importing and modifying the H1/L1 versions.
  4. I guess we can do this by just acquiring on MC2 with the huge CARM offset. It works for the single arm so it should work for offset CARM.
  1638   Mon Jun 1 14:49:07 2009 robSummaryPSLpsl thoughts

Some thoughts on what happened with the MOPA cooling. 

Some unknown thing happened to precipitate the initial needle valve jiggle, which unleashed a torrent of flow through the NPRO.  This flow was made possible by the fact that the cooling lines are labeled confusingly, and so flow was going backwards through the needle valve, which was thus powerless to restrict it.  The NPRO got extremely cold, and most of the chiller's cooling power was being used to unnecessarily cool the NPRO.  So, the PA was not getting cooled enough.  At this, point, reversing the flow probably would have solved everything.  Instead, we turned off the chiller and thus discovered the flaky start-motor capacitor. 

Now we have much more information, flow meters in the NPRO and main cooling lines, a brand-new, functioning needle valve, a better understanding of the chiller/MOPA settings necessary for operation, and the knowledge of what happens when you install a needle valve backwards.

 

  1685   Thu Jun 18 23:20:40 2009 robSummaryLSCI-Q ratio with RF detected DARM

This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state.  It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases.   So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature.  This measure is imperfect because it doesn't account for the effect of the DARM loop.

Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband.  The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.

Attachment 1: IQratio.jpg
IQratio.jpg
  1717   Tue Jul 7 15:08:49 2009 KojiSummaryPhotos40 high school students visited 40M

Alan and Alberto conducted a tour of 40 high-school students.
It may be the same tour that Rana found a spare PMC during the tour explanation as far as I remember...

Attachment 1: IMG_1848.jpg
IMG_1848.jpg
  1795   Mon Jul 27 09:34:07 2009 steveSummaryIOOAligning the mode cleaner

Quote:

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

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

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

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

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

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

Afterwards I rebooted c1susvme1 and c1susvme2 because they were skewed.

 

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

 

Attachment 1: 20dtrend.jpg
20dtrend.jpg
  1796   Mon Jul 27 14:12:14 2009 ranaSummarySUSTM Coil Noise Spectra
Rob noticed that the ITMY DAC channels were saturating occassionally. Looking at the spectrum we can see why.
With an RMS of 10000 cts, the peak excursions sometimes cause saturations.

There's a lot of mechanical noise which is showing up on the ITM oplevs and then going to the mirror via
the oplev servo. We need to reduce the mechanical noise and/or modify the filters to compensate. The ITM
COIL_OUT RMS needs to be less than ~3000.
Attachment 1: Coils.pdf
Coils.pdf
  1864   Fri Aug 7 19:34:40 2009 steveSummaryVACUPS failed

The Maglev is running on single phase 220V and that voltage  was not interrupted. TP1 was running undisturbed with V1 and V4 closed.

It is independent of the UPS 120V.

  1865   Fri Aug 7 19:55:08 2009 steveSummaryVACopening V1 when PTP1 is broken

The swapped in 307 convectron gauge controller  is very likely to have the  RS232 connection  wired differently from the old one.

PRP gauge has now the same error message as the PTP1:  "no comm"  I would look at RS232 wiring of the PRP gauge on the broken

controller and adapt the swapped in one to communicate. The PRP was reading 620 Torr before the swap.

  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
  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
  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?

  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
  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.

 

  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

  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.

  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.

 

  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.
  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.

  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.

  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. 

  1923   Tue Aug 18 14:24:43 2009 YoichiSummaryPSLReference Cavity Inspection
Rana, Koji, Yoichi

To see why the reflected beam from the RC is distorted, we took out
the periscope and the iris in front of the RC. The periscope mirrors
had some gunk and dusts on them. We blew nitrogen air onto them to
remove the dust. Since the gunk did not come off with the air, we
wrapped a Q-tip with lens cleaning paper soaked in Methanol, and wiped
the surface of the mirrors. We did this because it was hard to remove
the mirrors from the periscope (they were in a spring loaded mirror
holders. The springs were too strong to safely remove them without
damaging the mirrors).

Looking into the RC from the front mirror revealed nothing obstructing
in the path.

After the cleaning, we put the periscope back and observed the direct
reflection from the cavity (not locked). It was still distorted
exactly like before.

So we did some tests.
First we injected He-Ne to the RC. It turned out that multiple
reflections from the optical window (not AR coated for He-Ne) made it
almost impossible to investigate anything with He-Ne. But this
observation made us to suspect maybe one side of the window is not AR
coated.

We placed the periscope about 50cm away from the RC and injected the
beam from an angle, so that we can observe the direct reflection.

First, we checked the shape of the beam leaving the periscope. It was good.
We then observed the reflected beam from the RC. It was also good, no distortion.
We made sure that it was really the reflection from the mirror, not from the window
as follows.
We measured the separation between the in coming beam to the cavity and the reflected beam
at two locations. From this, we can guess where the two beams intersect (the reflection point).
The estimated reflection point was far inside the RC enclosure, indicating that it was really
reflection from the front mirror of the RC.
Since we did not see any other reflection beam, we concluded that the AR coating of the window
is good.

We checked the direct reflection beam shape with several different incident angles, but the
beam shape was always good.

We put back the periscope to the original position. This time, we put a high reflectivity mirror
after the output mirror of the periscope. The beam coming out of the circulator (PBS) had a good
circular shape. But still if we let the beam reflected by the cavity, the beam shape is distorted.
Something must be happening in the RC. Unfortunately, we could not figure out what it is.

We put everything back to the original configuration, except for the iris, and the RC alignment
was already good (surprise). After Koji's final tweak, the FSS is now doing fine, but still
the reflected beam is ugly.
ELOG V3.1.3-