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

Quote:

Yoichi, Pete

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

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

The test channels:

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

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

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

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

We closed the PSL shutter and killed the MC autolocker.

 

Attachment 1: MC1_Drift.pdf
MC1_Drift.pdf
Attachment 2: MC2_Drift.pdf
MC2_Drift.pdf
  1436   Fri Mar 27 02:50:54 2009 YoichiUpdateLockingDD demodulation phase suspicious
I noticed that the gain of PD6_Q (before the phase rotation) was 0 whereas PD6_I gain was 15.
This means the demodulation phase of the PD6 had no meaning other than changing the gain.
According to the conlog, it has been zero since March 2nd. I don't know how it happened.

While I was re-adjusting the DD phase, the MC started to unlock frequently (every 10 minutes or so).
MC1 is again drifting a lot (it is getting step-function like alignment changes intermittently).
This practically made it impossible to work on locking. So I decided to fix the MC first.
See Peter's elog entry for the MC work.
  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
  1434   Thu Mar 26 09:08:18 2009 KakeruUpdateoplevsarm cavity oplev calibration
I uploaded a document about my oplev calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev.pdf

At same place I put my matlab codes for calibration.
/cvs/cds/caltech/users/kakeru/oplev_calibration/oplev_calibration.m
  1433   Thu Mar 26 04:27:26 2009 YoichiUpdateLocking3.8kHz peak as a function of the arm power
During the power ramp-up, I actuated CARM using ETMs and measured the transfer functions to the PO_DC at several arm powers.
The peak grows rapidly with the power. It also seems like the frequency shifts slightly as the power goes up, but not much.

Some sort of an RSE peak ? An offset in the PRC lock point ?
Attachment 1: CARM-PODC.pdf
CARM-PODC.pdf
  1432   Thu Mar 26 04:09:38 2009 YoichiUpdateIOOSingle X arm lock spectra with different MC lock schemes
The attached plots show MC_F, FSS_FAST_F and XARM IN/OUT spectra with different MC locking modes.
The conventional locking means the FSS is used. The direct frequency lock is the new way.
You can see that at low frequencies, the frequency actuator is working hard to suppress the MC pendulum motions.
The X-arm also sees a lot of frequency noise at low frequencies because of this.
The transmitted power of the X-arm fluctuates a lot making it difficult to align the mirrors.

The zoomed plots show that the structures in the kHz band are also present in the case of the direct frequency lock, although the frequencies are somewhat different.
Attachment 1: XarmSpectra.pdf
XarmSpectra.pdf
Attachment 2: XarmSpectraZoom.pdf
XarmSpectraZoom.pdf
  1431   Thu Mar 26 04:01:24 2009 YoichiUpdatePSLFSS Open Loop Gain
Yoichi, Peter, Jenne

Attached is the open loop transfer function of the FSS as of today with the common gain = 12dB and the fast gain = 16dB.
The UGF is only 250kHz. If we increase the common gain, the PC goes crazy. Exactly the same symptom as before I fixed the oscillating op-amp.

I wanted to check the cross over frequency but there is no excitation point in the fast path nor PC path. Therefore, it is not easy.
Attachment 1: OpenLoopTF.png
OpenLoopTF.png
  1430   Thu Mar 26 00:45:24 2009 JenneUpdateIOOMode Cleaner Servo Board Transfer Functions (to be updated)

Quote:

netgpibdata.py is giving me weird data.  When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function.  I don't really know what's up. 

 Yoichi, in all his infinite wisdom, reminded me that the netgpibdata script saves the data as the REAL and IMAGINARY parts, not the Mag and Phase.  Brilliant.   Using that nugget of information, here are the TFs that I measured earlier:

The last attachment is the .dat and .par files which contain the data and measurement parameters for the 3 TFs in the plots.

Attachment 1: MCwithandwithoutfilter25Mar2009.png
MCwithandwithoutfilter25Mar2009.png
Attachment 2: PomonaBoxMCfilter25Mar2009.png
PomonaBoxMCfilter25Mar2009.png
Attachment 3: MCServoData25Mar2009.tar.gz
  1429   Wed Mar 25 20:41:43 2009 JenneUpdateIOOMode Cleaner Servo Board Transfer Functions (to be updated)

When all things fail (netgpibdata.py is giving me weird data.  When I plot the data it has saved from the 4395A, it's some wierd other universe's version of my transfer function.  I don't really know what's up.  I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely like it should, but with some crazy humps.  I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can always take a picture of the Agilent 4395's screen, as shown below.

* Mode cleaner and PMC are both relocked after my shenanigans, and I'll try again in the morning (I assume locking is going on tonight) to get real TF's with real data, as opposed to the photo method.

Note to self:  post the data of the TFs in the elog along with the plots, for posterity.

 

These TFs are of the Mode Cleaner servo board, exciting IN1 (or the 3.7MHz notch pomona box which is connected to IN1), and measuring at the SERVO out of the board.

One with the box, one without the box, and one of just the box for good measure.

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

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

[FSS box]
C1:PSL-FSS_SW1 0 (Test1 ON)
C1:PSL-FSS_INOFFSET 0.1467
C1:PSL-FSS_MGAIN 30
C1:PSL-FSS_FASTGAIN 14 (Do not increase it, at least while locking. Otherwise the phase lag from the PZT loop gets significant and the MC loop will be conditionally stable).
I also turned down the FSS slow servo's RC transmission threshold to zero so that the slow servo works even without the RC locked.
Attachment 1: MC-loop-gain.png
MC-loop-gain.png
  1427   Wed Mar 25 09:55:45 2009 steveUpdateIOOglitching sensors of MC

SUS-MC1_SENSOR_SIDE and SUS-MC2_SENSOR_UL are glitching

Yesterday's 4.8mag earthquake at Salton Sea is shown on Channel 1

Attachment 1: glitchesofMC.jpg
glitchesofMC.jpg
  1426   Wed Mar 25 04:18:28 2009 YoichiUpdateLockingTuesday Locking
After the new PO_DC PD was installed, I tweaked several gains to make the locking scripts work right.
First of all, I increased the gain of PD12 (PD12_I is SPOB) by a factor of 1.4 to compensate for the power decrease
by the insertion of the BS. SPOB is used by the PRM alignment script. I was too lazy to modify the scripts.

Then I optimized the SRC DD signal which is taken from the POB.

I also had to do some gain adjustments for the CARM loop.

The attachment (AO path open loop TF) shows a depressing fact that the 3.8kHz peak is still there with the new PO_DC PD. So it was not a problem of the SPOB PD.
Next, I will check the cross over frequencies of the PZT and PC paths in the FSS and the VCO/MCL cross over.
Attachment 1: AO-Loop-p9.png
AO-Loop-p9.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.
  1424   Tue Mar 24 23:23:05 2009 ranaUpdateLSCNew PO DC
We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). Using 50m Ohm devices without terminated inputs is illegal. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
the splitter and ran the cable straight. So expect some change in the SPOB gain and phase plus some shame.
  1423   Tue Mar 24 19:55:24 2009 JenneUpdateLSCNew PO DC

[Rana, Jamie, Jenne]

SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table.  We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff).  We didn't check with a power meter that it's a 30% BS, but it seems like that's about right.  The beamsplitter is as close as we could get to the shutter immediately in front of the regular POB/SPOB PD's, since that's where the beam gets narrow.   The new picked-off-pickoff beam goes to a Thorlabs 100A PD.  We haven't yet checked for reflected beams off the PD,  but there is a spare razor blade beam dump on the table which can be used for this purpose.  The output of this PD goes to the LSC rack via a BNC cable.  (This BNC cable was appropriated from it's previous "use" connecting a photodiode from the AP table to a bit of air just next to the LSC rack.)  Our new cable is now connected where the old SPOB DC cable used to be, at the input of a crazy Pomona Box tee.

For reference, the new levels of POB DC and SPOB DC, as measured by their BNC DC out connections is ~4mV each.  Since the beamsplitter is 70% transmissive, we used to be getting about 5.7mV on each PD.

The new photodiode puts out about 40mV, but it has an ND1.0 filter on, so if more gain is needed, we can take it off to get more volts.

 

  1422   Tue Mar 24 13:54:49 2009 JenneUpdateSUSOp Levs Centered

ITMX, ITMY, BS, SRM, PRM op levs were all recentered.  ETM's looked okay enough to leave as-is. 

  1421   Tue Mar 24 13:10:07 2009 AlbertoConfigurationPSLnew mirror installed on the AP table

New flipping mirror installed on the AP table on the beam path to the REFL199 PD.

If you're missing the double demod signal, please check that it is actually down.

  1420   Tue Mar 24 09:04:02 2009 steveUpdateSUS4.8 mag earthquake

SRM, ITMX, ETMX, ITMY and ETMY lost damping at 4:55am this morning from 4.8 magnitude earthquake.

Their damping were restored.

C1:SUS-ITMX_URSEN_OUTPUT swich was found in off position. It was turned on.

MZehnder  and MC were locked.

The WFS qpd spot needs recentering

  1419   Tue Mar 24 03:05:25 2009 YoichiUpdateLockingLocking tonight
MC1 issue:
The MC1 seems to be drifting still. I found it was off from the SUS drift-mon reference values and restored the alignment using the SUS drift-mon before I went home for dinner.
But when I came back being happy with the Japanese victory over S-Korea at the WBC final, the MC was unhappy again.
I restored the alignment of the MC1 using the SUS drift-mon once again and centered the WFS QPDs.
I will leave the MC unlocked again tonight to see the drift. You are welcome to lock the MC in the morning as I will have corrected enough data by the time people come in.

Computer overloads:
I removed some filters from suspensions to off load susvme computers.
Nonetheless, both susvme1 and susvme2 are still over loaded during the dither alignment. The alignment results are in general ok. So this is not a too serious problem.
But still it would be nice to resolve.

3.8kHz hunting:
I made several measurements of the AO path loop gains (using the SR785) and the transfer functions from the CARM excitation (actuation to the ETMs) to the PO_DC signal as the arm powers are increased.
There is a similar structure as in the AO loop found also in the CARM->PO_DC transfer functions. This implies that the problem is likely to be in the PO_DC sensor not in the MC->VCO actuator. But the MC and the VCO could still be the
cause of the problem because they were in the control loop when the CARM->PO_DC TF were measured.
The peak frequency does not seem to depend on the arm power, but the conclusion is not definite because I was only able to measure the TFs from arm power 5 to 10 (not much difference).
I will make plots and post them later.

To Do for tomorrow:
Tonight the CARM error signal was noisier than the reference spectra (broad band white noise appeared). I should check the beam centering of the SPOB PD.
Also someone should center the oplevs of the mirrors as some of them are off.
Continue to measure the TFs at various power levels.
Try to put another (Thorlabs?) PD at the POB port to get PO_DC from it.
  1418   Mon Mar 23 15:50:44 2009 ranaConfigurationLSCfilters deleted, lsc rebooted

The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.

The filters all looked like old trash to me, but its possible they were used.

I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the

filter_archive/

  1417   Sun Mar 22 23:16:41 2009 ranaDAQComputer Scripts / Programstpman restart
Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.

Still no log file. Mad
  1416   Sun Mar 22 22:47:58 2009 ranaUpdateDMFseisBLRMS compiled but still dying
Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;
let's see how it does. I'm not optimistic.
  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
  1414   Fri Mar 20 15:54:29 2009 steveOmnistructureGeneral480V crane power switch on MEZ

CES Mezzanine is beeing rebuilt to accommodate our new neighbor: the 20ft high water slide...& .jacuzzi

All our ac power transformers are up there. Yesterday we labelled the power switch of 480VAC on the mezz

that we need to keep to run the 3 cranes in the lab.

  1413   Fri Mar 20 15:37:58 2009 KakeruUpdateoplevsarm cavity oplev calibration

I calibrated several oplevs with OSEM signal as a confirmation of my fitting method the method is:

1) I tilted mirrors and get signals from oplevs (C1:SUS-XXXX_OPLEV_PERROR) and OSEM (C1:SUS-XXXX_SUS{PIT/YAW}_IN1).
2) I compared amplitudes of two signals and calculated conversion factors.
3) I calibrated factors above to microrad/counts with
i) The calibration factor of OSEM (2 V/mm)
ii) The calibration factor from count to V of OSEM; 1/16384 V/counts
iii) The shape of whitening filter of OSEM: 30, 100:3 (these values is taken from http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=04/07/2005&anchor_to_scroll_to=2005:04:07:20:28:36-rana).
iv) The size of mirrors; 125mm for large optics and 75.5mm for small optics.


This calibration has some uncirtainties.

1) The calibration factor of OSEM looks very rough.
2) Output matrixes looks not to be normalized. It looks vary from 0.5 to 1.5 .
3) I don't know where OSEMs are put on mirrors accurately.

So, this calibration is very rough and may have uncertnty of a few factors, I could confirm my fitting calibration in orders.

From this calibration, I got calibration factors listed below.

ITMY Pit: 76 microrad/counts (257 microrad/counts with fitting method)
ITMY Yaw: 58 microrad/counts (206 microrad/counts)
BS Pit : 27 microrad/counts (70.9 microrad/counts)
PRM Yaw : 22 microrad/counts (79.9 microrad/counts)

For the other mirrors, OSEM outputs matrixes are not optimized and I couldn't get fine signals (I think this is not good!).

Each value is smaller than the value calibrated with fitting method in factor 3-4. There looks to be some systematic error, so there must be some difference in parameters used in OSEM calibration.
  1412   Fri Mar 20 12:07:19 2009 YoichiConfigurationASCETMY beam centering
I forgot to put this in the elog.
Last Sunday night, I centered the beam on the ETMY because it was too low.
To do so, I wrote scripts (beamCenterETMY-P and beamCenterETMY-Y) to continuously align the Y-arm while I'm moving the beam on the end QPD.
These scripts will continuously do the dithering servo and QPD centering in one direction (pitch for beamCenterETMY-P, yaw for the other).
So if you move the steering mirror in front of the end QPD, the servo will eventually move the beam spot on the ETM.
I centered the beam just by looking at the camera image.
No coupling measurements from Pitch/Yaw to length was done.
  1411   Fri Mar 20 11:01:02 2009 steveUpdatePEMparticle counts are high

The outside particle counts for 0.5 micron are 3 million this morning at 9am. Low clouds, foggy condition with low inversion layer.

This makes the 40m lab 30-50K

I just turned on the HEPA filter at the PSL enclosure.

Please, leave it on high

 

Attachment 1: particles32d.jpg
particles32d.jpg
  1410   Thu Mar 19 10:45:43 2009 YoichiConfigurationIOOA loose wire found for MC1
I attached a 6-hour trend of the MC mirror OSEM signals with the MC unlocked.
The drift of the MC1 is within 20 counts (0.6um in terms of each OSEM).
This is comparable to the other MC mirrors.
Attachment 1: AfterWireFix-1.pdf
AfterWireFix-1.pdf
  1409   Thu Mar 19 02:45:36 2009 YoichiConfigurationIOOA loose wire found for MC1
I found a loose connection of a wire in the cross-connect between an ADC and the MC1 coil driver's UL bias input.
I tightened it.
To see if this fixes the MC1 drift problem, I will do another round of MC1 drift measurement.
You can lock the MC if you need to use the IFO but please note it in the elog.

Thanks.
  1408   Tue Mar 17 08:44:37 2009 YoichiConfigurationIOOMC1 drift
I'm done with the MC1 drift measurement.
The result is attached. It is clear that MC1 is in trouble. The small drifts in the MC2/MC3 are insignificant compared to the crazy MC1 behavior.
Since there is no drift in the coil feedback voltage monitors, it is probably not a problem of the DACs.
We may be able to fix this by pushing the cables for the MC1 satellite amplifier. But it may require replacement of the coil driver.


Quote:
There seems to be a large drift of MC1 even when there is no WFS feedback.
The attached plot is an example a 20min trend. You can see that MC1 OSEM signals drift significantly larger than that of MC2/MC3.
You can also be sure that there is no drifting voltage applied to the coils on the MC1 during this period.

If no one is working on the IFO today during the LV meeting, I'd like to leave the MC unlocked and see the trend of the MC1 OSEM signals.
Please do not turn on the MC auto locker unless you want to use the IFO.
If you want to do some measurements, please go ahead and lock the MC, but please write it down in the elog.
Thanks.
Attachment 1: MC1_Drift3.pdf
MC1_Drift3.pdf
  1407   Mon Mar 16 15:19:52 2009 OsamuDAQElectronicsSR785

I borrowed SR785 to measure AA, AI noise and TF.

  1406   Mon Mar 16 12:26:59 2009 YoichiConfigurationIOOMC1 drift
There seems to be a large drift of MC1 even when there is no WFS feedback.
The attached plot is an example a 20min trend. You can see that MC1 OSEM signals drift significantly larger than that of MC2/MC3.
You can also be sure that there is no drifting voltage applied to the coils on the MC1 during this period.

If no one is working on the IFO today during the LV meeting, I'd like to leave the MC unlocked and see the trend of the MC1 OSEM signals.
Please do not turn on the MC auto locker unless you want to use the IFO.
If you want to do some measurements, please go ahead and lock the MC, but please write it down in the elog.
Thanks.
Attachment 1: MC1_Drift1.pdf
MC1_Drift1.pdf
  1405   Mon Mar 16 01:20:40 2009 ranaConfigurationIOOMCWFS noise filtered on the SUS-MC
Recently, we noticed that the IOO-WFS system runs at 2048 Hz and sends its signals to the MC SUS
systems which run at 16 kHz. There is no upsampling filter or anti-imaging filter.

So, I've implemented an RLP666 filter as FM1 in the SUS-MCn_ASC(PIT/YAW) filter banks. This is like a 4th order
Cheby low pass with a low Q notch at 2048 Hz to catch the first image.

The attached PNG shows the ASCPIT_OUT signals before and after the filter is implemented. As you can see, the
big aliased spikes are gone. The reason that MC2 is different from MC1/3 is that they have a hardware 28Hz low pass
and MC2 doesn't. So MC2 had a 28 Hz low pass in software already to match the actuation phase between all the MC
mirrors. The apparent power law noise floor from 40-300 Hz in MC2 is not real - just the Hanning window tail.

And yes, it has been this way for several years and none of us noticed. It remains to be seen if this was causing
any noise in the MC coil drivers via slew rate limiting.
Attachment 1: xarm.png
xarm.png
  1404   Sun Mar 15 21:50:29 2009 Kakeru, Kiwamu, OsamuUpdateComputersSome computers are rebooted

We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We  turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.

So, we turned off and on key switches of these machines physically, and login to them to run startup scripts.

Then we turned on all watchdogs and restored all IFO.

Now they look like they are working fine.
 

  1403   Sat Mar 14 22:53:12 2009 KakeruUpdateoplevsarm cavity oplev calibration
I finished a calibration of optical levers.

To calibrate oplevs, I locked appropriate cavity and tilted a mirror.
A cavity with tilted mirror decrease its arm power. So I can know how much the tilt is.
For calibration of ITMX and ETMX, I locked X arm and measured TRX.
For ETMX, ETMY and BS, I locked Y arm and measured TRY
For PRM, I locked PRC and measured SPOB
For SRM, I locked SRC and measured REFL166

I used, for example, C1:SUS-ITMX_OPLEV_PERROR as an oplev signal.

The calibration factors for each mirror is below. The attachment is figures of my fitting.
I used modified equation for ITM calibration from my last calibration, so the value become small around 30%.

ITMX Pitch: 142   microrad/counts
ITMX Yaw:   145   microrad/counts
ITMY Pitch: 257   microrad/counts
ITMY Yaw:   206   microrad/counts

ETMX Pitch: 318   microrad/counts
ETMX Yaw:   291   microrad/counts
ETMY Pitch: 309   microrad/counts
ETMY Yaw:   299   microrad/counts

BS Pitch:    70.9 microrad/counts
BS Yaw:      96.3 microrad/counts

PRM Pitch:   78.5 microrad/counts
PRM Yaw:     79.9 microrad/counts

SRM Pitch:  191   microrad/counts
SRM Yaw:    146   microrad/counts


It looks strange that ITMY, BS and SRM has different value. I think this is a fitting problem.
These data have some asymmetry and cause these 20%-30% difference.
Actually, PRM Yaw has a little asymmetry but the value doesn't differ from Pitch.
This means that this calibration factor potentially has below 30% error.
(These data are the most fine data. I think we must adjust Y arm yaw alignment. The beam spot of ETMY looks too low!)
For SRM, I couldn't get fine data because it was very sensitive to tilt and easily lose its lock.
When I tuned cavity enough, The data become almost flat, so I used detuned cavity.

It is also strange that ITMX and ITMY is different. I guess that this is caused by the difference of the QPD input. The sum of QPD is around 10000 for ITMX and around 4500 for ITMY.
The difference between BS or PRM and SRM is same, I guess. The sum of QPD input for BS and SRM is around 1500, but for SRM, it is around 10000.

I will write more detailed document and upload it with my calibration code.
Attachment 1: oplev.pdf
oplev.pdf oplev.pdf oplev.pdf
  1402   Fri Mar 13 22:07:14 2009 YoichiUpdateLockingCalibrated XARM error signal spectrum
Of course I made a mistake.
I put a pole at 1525Hz whereas it should have been a zero.

The correct calibration factor is:
G: 4.2e-13
P:
Z: 1525

I attached a revised spectrum.


Quote:
I did a rough calibration of the XARM error spectrum.
See the attached calibrated spectrum.

I started from this Rana's elog entry.
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=04/07/2005&anchor_to_scroll_to=2005:04:07:20:28:36-rana

I first injected a 20Hz sin signal into C1:SUS-ETMX_LSC_EXC and measured the response to the ETMX SUSPOS.
Using the calibration of the SUSPOS given in the above entry, I calibrated the ETMX coil actuation efficiency.
It was 3.4e-12 m/cnt @20Hz for C1:SUS-ETMX_LSC_EXC.

Then I locked the X-arm and injected a calibration peak at 20Hz.
From the ratio of the peaks in C1:SUS-ETMX_LSC_IN2 and C1:LSC-XARM_IN1, I calibrated the X-arm error signal to be 4.2e-13 m/cnt.
We have to also take into account the cavity pole of the arm, 1525Hz (the design value, may not be actual).
So I used the following calibration in the DTT:

G: 4.2e-13
P: 1525
Z:

Note that the attached spectrum shows the actual motion of the X-arm (or equivalent frequency noise) after suppressed by the feedback servo,
unlike conventional noise spectra showing "virtual" displacement which would have been induced in the absence of servos.
Attachment 1: XarmErrorSpeCalibrated.pdf
XarmErrorSpeCalibrated.pdf
  1401   Fri Mar 13 20:23:37 2009 YoichiUpdateLSCAO path transfer function with X-arm locked
I measured the AO path transfer function while the X-arm is locked with the POX PDH signal.
The POX-I signal was already connected to the input 1 of the CM board. So I injected a signal from the EXC-B channel of the board and measured the transfer function from TP2B to TP1A. To open the loop, I disabled the switch befor the EXC-B.
The attached plot shows the measured transfer function.
There is a bump around 2kHz, which can also be seen in the AO path TF posted in elog:1399, but not the large structure at around 3.8kHz.
The 3.8kHz structure is probably created by the feedback.
Attachment 1: AOPath-Xarm.png
AOPath-Xarm.png
  1400   Fri Mar 13 19:26:09 2009 YoichiUpdateDMFseisBLRMS compiled

 I compiled seisBLRMS.

The tricks were the following:

(1) Don't add path in a deployed command.
It does not make sense to add paths in a compiled command because it may be moved to anywhere. Moreover, it can cause some weird side effects. Therefore, I enclosed the addpath part of mdv_config.m in a "if ~isdeployed ... end" clause to avoid adding paths when deployed. Instead of adding paths in the code, we have to add paths to necessary files with -I options at the compilation time. This way, mcc will add all the necessary files into the CTF archive.

(2) Add mex files to the CTF archive by -a options.
For some reason, mcc does not add necessary mex files into the CTF archive even though those files are called in the m-file which is being compiled. We have to add those files by -a options.

(3) NDS_GetData() is slow for nodus when compiled.
NDS_GetData(), which is called by get_data() stops for a few minutes when using nodus as an NDS server.
This problem does not happen when not compiled. I don't know the reason. To avoid this, I modified seisBLRMS.m so that when an environmental variable $NDS is defined, it will use an NDS server defined in this variable.

I wrote a Makefile to compile seisBLRMS. You can read the file to see the details of the tricks.
I also wrote a script start_seisBLRMS, which can be found in /cvs/cds/caltech/apps/DMF/compiled_matlab/seisblrms/. To start seisBLRMS, you can just call this script.
At this moment, seisBLRMS is running on megatron. Let's see if it continues to run without crashing.

Quote:

The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This

is because I couldn't get the compiled matlab functionality to work.

Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I

have set the NDS server for mDV on megatron to be fb40m:8088 instead of nodus.ligo.caltech.edu. If this seems to fix the problem

I will make this permanent by putting in a case statement to check whether or not the mDV'ing machine is a 40m-martian or not.

  1399   Fri Mar 13 05:16:21 2009 YoichiUpdateLockingLocking update
Yoichi, Osamu,

With adjustments of the loop gains during the CARM offset reduction, the IFO reaches arm_power = 25 sort of robustly unless the 3.8kHz oscillation rings up.
At arm_power = 25, the CARM and DARM start to oscillate at around 400Hz. Probably I need more gain tweaks.
Annoying thing is that the 3.8kHz oscillation sometimes rings up suddenly and kills the lock.
This can happen anywhere above arm_power = 6 or so.
Because of a strange structure in the CARM loop gain around 3.8kHz, we cannot increase the CARM UGF beyond 1kHz.
The attached plots are the AO path open loop transfer function (attm2 is the zoom of attm1) measured at arm_power = 13.

Tomorrow, I will lock the X-arm and measure the transfer function from the AO path input to the X-arm error signal to see
if there is the same structure at 3.8kHz (X-arm error signal has the 3.8kHz peak).
Attachment 1: AOTF2.png
AOTF2.png
Attachment 2: AOTF2-zoom.png
AOTF2-zoom.png
  1398   Thu Mar 12 20:59:04 2009 KakeruUpdateIOOMC drift is terrible
After Rana went for his dinner, I aligned periscope to make the MC output 3.2 (Attachment 1).

After that, to align WFS, I unlocked the MC, unlocked the MZ and decrease the beam power to WFS QPD, and re-centerd WFC beam.
I restored MZ and MC lock.
I enabled MC autolocker, and change C1:IOO-WFS_Gain_Slider from 0 to 0.02 to lock WFS.


Quote:
Kakeru, Rana, Yoichi

We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.

We then used the MC_ALIGN screen to set the angle bias sliders.

Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.
Attachment 1: MCtrans090312.png
MCtrans090312.png
  1397   Thu Mar 12 19:11:27 2009 ranaUpdateIOOMC drift is terrible
Kakeru, Rana, Yoichi

We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.

We then used the MC_ALIGN screen to set the angle bias sliders.

Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.
  1396   Thu Mar 12 18:48:37 2009 YoichiUpdateIOOMC aligned but ...
After the MZ alignment, I aligned the MC with the periscope mirrors.
It looked like the MC mis-alignment was mainly caused by the input beam change.
So I left the MC mirrors as they were to keep the output beam pointing.
However, after I finished the alignment, the MC output beam was too low on the Faraday.
Also the X-arm did not lock to TEM00 mode. So the MC mirrors must have also shifted to a weird alignment state.
I should have restored the MC mirror alignment to a good state using the OSEM DC signals.

Rana came in and restored the MC mirror alignment using the SUS drift mon.
He and Kakeru is now working on the periscope to align the beam into the MC.
  1395   Thu Mar 12 18:44:02 2009 YoichiUpdatePSLMZ aligned
The MC lost the alignment somehow this afternoon.
So I thought it was good time to touch the MZ because I had to align the MC using the periscope anyway.

I mainly touched the mirror with a PZT. The MZ reflection went down from 0.5 to 0.3.
  1394   Thu Mar 12 15:57:53 2009 YoichiUpdateIOOMC drift is terrible
Yoichi, Osamu,

Last night's locking work was totally interrupted by the sabotage by the MC.

First, after I measured the RF_AM, the MC alignment was somehow shifted largely and the MC did not lock to TEM00 mode.
I only mis-aligned MC2 to measure the RF_AM, but the MC reflection beam was also shifted (looking at the WFS QPD), that means MC1 was mis-aligned somehow.
Moreover, even when the MC is not locked, i.e. no feedback to the mirrors, the OSEM values of the MC mirrors (all of them) drift a lot in 10min scale.
I was totally puzzled. So I rebooted c1iovme and c1sosvme. Then this strange drift of the OSEM values stopped.
Even though, the MC tended to lose lock within ten minutes because the WFS QPDs were not centered.
We did several iterations of re-centering and finally the MC started to stay locked happily. The MC reflection beam was symmetric.

Then this morning when I came in (to be honest, afternoon), the MC reflection looked asymmetric again. The WFS QPDs were mis-centered again.
The attached files show an 8-hour trend of various MC related signals.
There was a half-degree temperature change starting from around 11AM. Corresponding to that, the IOO-QPD signals drifted indicating that the PSL beam pointing
was shifted. The MZ PZT signal shows a similar trend, so the beam pointing may have been shifted by the MZ (not sure).
The MC WFS, transmission QPD signals show the same trend.
This is too bad.

Right now, the PSL beam pointing is monitored by the QPDs detecting the transmitted beam through the first mirror of the periscope.
This means even if we can track the beam pointing drift with the QPDs, we can't correct the beam pointing using the periscope mirrors.
I don't want to touch the MZ mirrors for this purpose.
I propose to put a pick-off mirror after the second mirror of the periscope to send light to the IOO-QPDs. This way, we can use the periscope
mirrors to restore the beam pointing screwed up by the MZ.
Attachment 1: MC_Drift-1.pdf
MC_Drift-1.pdf
Attachment 2: MC_Drift-2.pdf
MC_Drift-2.pdf
  1393   Thu Mar 12 02:18:42 2009 YoichiUpdateLockingMC_I spectra (RF_AM)
I took several spectra of MC_I signal (see attm1).

The blue curve is when the MC was locked. The green curve (RF_AM) shows the MC_I spectrum when the MC is unlocked and MC2 is mis-aligned,
so that no resonance should happen. The brown curve is when the PSL shutter was closed (dark noise).
There are some structures in the green curve but not at 3.8kHz.

The second attachment compares the MC_I spectrum (the same as the green one in the first attachment) with the Xarm error signal.
Of course these two spectra were taken at different times.

Some of the peaks in the X-arm error signal seem to be coming from the MC RF_AM.
Attachment 1: MC_I_Spe.png
MC_I_Spe.png
Attachment 2: MC_I-Xarm.png
MC_I-Xarm.png
  1392   Thu Mar 12 00:29:39 2009 JenneOmnistructureDMFDMF being whiny again

Quote:
The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running.


[Yoichi, Jenne]

seisBLRMS was down again. I assumed it was just because the DMF Master Enable was in the 'Disabled' state, but enabling it didn't do the trick. Rana's green terminal window was complaining about not being able to find nodus.ligo.caltech.edu. Yoichi and I stopped it, closed and restarted Matlab, ran mdv_config, then ran seisBLRMS again, and it seems happy now.

On the todo list still is making the DMF / seisBLRMS stuff happy all the time.
  1391   Wed Mar 11 23:41:33 2009 Kakeru, YoichiUpdateIOOWFS centering

We found the MC reflection was distorted . And WFC beam went to upward of QPD

We recentered WFC beam and these problems were fixed

  1390   Wed Mar 11 22:57:48 2009 YoichiUpdateLockingCalibrated XARM error signal spectrum
I did a rough calibration of the XARM error spectrum.
See the attached calibrated spectrum.

I started from this Rana's elog entry.
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=04/07/2005&anchor_to_scroll_to=2005:04:07:20:28:36-rana

I first injected a 20Hz sin signal into C1:SUS-ETMX_LSC_EXC and measured the response to the ETMX SUSPOS.
Using the calibration of the SUSPOS given in the above entry, I calibrated the ETMX coil actuation efficiency.
It was 3.4e-12 m/cnt @20Hz for C1:SUS-ETMX_LSC_EXC.

Then I locked the X-arm and injected a calibration peak at 20Hz.
From the ratio of the peaks in C1:SUS-ETMX_LSC_IN2 and C1:LSC-XARM_IN1, I calibrated the X-arm error signal to be 4.2e-13 m/cnt.
We have to also take into account the cavity pole of the arm, 1525Hz (the design value, may not be actual).
So I used the following calibration in the DTT:

G: 4.2e-13
P: 1525
Z:

Note that the attached spectrum shows the actual motion of the X-arm (or equivalent frequency noise) after suppressed by the feedback servo,
unlike conventional noise spectra showing "virtual" displacement which would have been induced in the absence of servos.
Attachment 1: XarmErrorSpeCalibrated.pdf
XarmErrorSpeCalibrated.pdf
  1389   Wed Mar 11 21:03:51 2009 Kakeru and KiwamuUpdateIOOPSL angle QPD

Kakeru and Kiwamu

We placed a QPD on the PSL bench for PSL angle monitor.

 

Quote:

I checked a broken QPD, which was placed for PSL angle monitor, and finally I cocluded one segment of the quadrant diode was broken.

The broken segment has a offset voltage of -0.7V after 1st I-V amplifier. It means the diode segment has a current offset without any injection of light.

Tomorrow I will check a new QPD for replacement.

Kiwamu IZUMI

 

 As we mentioned before, old QPD which used to be placed is broken.

 And we put broken QPD into the "photodiodes" box under the soldering table.

 

 

  1388   Wed Mar 11 16:53:48 2009 YoichiUpdateLockingJunks in around kHz
Rana, Yoichi

Last night, we tried to find out the source of the kHz region peaks in the DARM and CARM error signals.
These peaks are also present in the error signal of the single arm locking by RF (both X and Y).
The attachment 1 shows spectra of MC_F and XARM error signal when XARM is locked by the POX PDH signal.
There is a sharp peak at 3.8kHz in MC_F. This peak was there in a reference spectrum taken on June 24 2008.

In the XARM error signal, there is also a broad peak around 3.8kHz. This peak moves between 3.75kHz and 3.8kHz from time to time.
(the brown curve was taken when the peak moved to 3.75kHz).
Also there is a notch like structure at 3.8kHz in the XARM error spectrum. Looks like the peak in the MC_F is creating a notch here, but
no idea why.

We tapped on the PSL table, the end chambers and the SPOB table and looked at the spectra to see if there is any change.
Rana also developed a cool Walkie-Talkie excitation technique, where he put one of the walkie-talkies on the PSL table by the MZ and yelled at the other one while looking at a DTT screen in the control room.
None of these had any effect on the XARM error, while MC_F responded to the disturbances.

We also turned on and off the steering mirror PZT closed loop buttons, moved the PMC, MZ and the ISS gain sliders and changed the MC gain, offset.
Nothing affected the XARM error.

Osamu found old spectra of the XARM signal (attm2). The legends say DARM but these are XARM signals.
Almost the same structures can be seen including the notch at 3.8kHz. Seems like it's been like this for long time.

We should check, RF-AM, MC coil dirivers, Piezo-Jena noise etc.
Attachment 1: MC_F-XARM.pdf
MC_F-XARM.pdf
Attachment 2: old-xarm.pdf
old-xarm.pdf
ELOG V3.1.3-