40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 89 of 339 Not logged in
ID Date Author Type Category Subject
1463   Thu Apr 9 12:23:49 2009 peteUpdateLockingtuning ETM common mode

Pete, Yoichi

Last night, we put the IFO in FP Michelson configuration.  We took transfer functions of CARM and DARM, first using CM excitations directly on the ETMs, and then using modulations of the laser frequency via MC excitation.  We found that there was basically no coupling into DARM using the MC excitation, but that there was coherence in DARM using the ETM excitation.  Therefore, I tuned the ETM common mode in the output matrix.  I did this by taking transfer functions of PD1_Q with PD2_I (see attached plot).  I changed the  drdown_bang script to set C1:LSC-BTMTRX_14 0.98 and C1:LSC-BTMTRX_24 1.02.

Attachment 1: FPMI-DARM-CARM-ETM-fineScan.pdf
1467   Fri Apr 10 01:24:08 2009 ranaUpdateComputersallegra update (sort of)

I tried to play an .avi file on allegra. In a normal universe this would be easy, but because its linux I was foiled.

The default video player (Totem) doesn't play .avi or .wmv format. The patches for this work in Suse but not Fedora. Kubuntu but not CentOS, etc.I also tried installing Kplayer, Kaffeine, mplayer, xine, Aktion, Realplay, Helix, etc. They all had compatibility issues with various things but usuallylibdvdread or some gstreamer plugin.So I pressed the BIG update button. This has now started and allegra may never recover. The auto update wouldn't work in default mode becauseof the libdvdread and gstreamer-ugly plugins, so I unchecked those boxes. I think we're going to have this problem as long as we used any kind ofadvanced gstreamer stuff for the GigE cameras (which is unavoidable).

1469   Fri Apr 10 04:54:24 2009 YoichiUpdateLockingREFL_DC for CARM
Suggested by Rob and Rana's simulation works, I tried to use REFL_DC for the CARM error signal.

My current guess for the cause of the 3.8kHz peak is the following.
The AF sidebands created by the laser frequency drive are reflected by the IFO to the symmetric port if the arms are perfectly symmetric.
However, if there is asymmetry in the arm cavities (such as loss imbalance, ITM transmission difference etc) the sidebands are scattered from the common mode to the differential mode. If our CARM error signal has a large response also to the differential mode (i.e. DARM), the loop is closed. At the DARM RSE frequency, the AF sideband in the differential mode is enhanced and creates a peak in the CARM response.
What Rob's plots show is that PO_DC has a larger response to DARM than REFL_DC has. You can see this from the curves of CARM offset = 0 (black ones).
When the CARM offset is zero, the CARM signal should go to zero. Therefore, the black curves show the residual DARM response. In the case of PO_DC, the black curve is very large suggesting a large DARM coupling.

Now I changed the cabling at the LSC rack to put REFL_DC into the REFL2 input of the CM board.
The REFL_DC signal is put through a 160kHz RC LPF and split to the ADC and the CM board (AC coupled by a large capacitor).
I modified the cm_step script to use PD4_DC as CARM error signal. (The old script is saved as cm_step.podc).
Since the polarity of the REFL_DC signal is opposite to the PO_DC, I flipped the polarity switch of the CM board.
This will flip the sign of the RF CARM signal because this switch flips the polarity of the both inputs.
We have to flip the sign of the RF CARM signal with the SR560 sitting on the LSC rack, which I haven't done yet.

With some tweaks of the gains and addition of two lag-lead filters to PD4_DC, I was able to completely hand off the CARM error signal to REFL_DC.
The attached plot shows the AO path loop gain at arm power = 7. The 3.8kHz is gone, although there is some phase ripple around 3.8kHz.

Since the gain behavior of the REFL_DC is different from the PO_DC, I'm now working on the power up part of the script, adjusting the gains as the power goes up.
Attachment 1: AO-loop-gain-CARM-REFL_DC.png
1470   Fri Apr 10 18:11:18 2009 JenneUpdatePSLISS has a bad cable?

[Rob, Jenne]

I noticed that the ISS Mean Value and CS Saturation were both RED and unhappy. (The alarms were going off, and they were both red on the MEDM screen).  None of the MEDM settings seemed off kilter, so we went out to take a look at the PSL table.

Rob checked that light is indeed going to both of the ISS photodiodes (Morag and Siobhan).  Next we checked that all the cables were good, and that the power to the ISS box was plugged in. In this process, Rob wiggled all the cables to check that they were plugged in.  Just after doing this, the Mean Value and CS Sat were happy again.  Rob thinks the current shunt connection might be bad, but we don't really know which one it was since all of the cables were jiggled between our checking the screens.

Right now, everything is happy again, but as with all bad-cabling-problems, we'll probably see this one again.

I don't know why in particular the connection decided to spaz out this afternoon...I don't think anyone opened the PSL table before Rob and I went to investigate.  I was working on the PMC servo (checking the LO levels...to be posted in a couple minutes), but didn't have anything to do with the ISS. After I was done, I put everything back, and locked the PMC and the MC, and everything was good, until some time later when the ISS started flipping out.

1471   Fri Apr 10 19:09:48 2009 JenneUpdatePSLPMC LO Calibration
I measured the RF LO output level from the PMC's LO board which goes directly into the LO input on the PMC Servo board. This goes hand-in-hand with Rana's thoughts
that we might be giving the PMC mixer a too-low LO value, and we might need to switch out the mixer. Steve ordered some new mixers today to try out.

The RF Output Adjust slider (on the C1:PSL_PMC_PS screen) goes from 0-10V; The nominal value (or at least the value I found it at today) is 2.014V.

To measure the RF level: I unlocked the Mode Cleaner and turned off the ISS servo per Yoichi's suggestion. I then unplugged the input to the PMC servo board's LO input,
and put that cable into a 300MHz 'scope, with 12dB attenuation. The 'scope was AC coupled, with the input set to 50Ohms.

I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account
the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.

 RF Output Adjust Output measured on scope Oscillator Output Monitor [V] [Vpp] [no units given on MEDM screen] All \pm 0.0159 all of this column is NEGATIVE 0.0000 3.838 0.007 0.5000 3.854 0.007 1.0000 3.838 0.006 1.5000 3.838 0.007 2.0000 3.838 0.006 2.5000 3.838 0.007 3.0000 3.838 0.007 3.5000 3.838 0.007 4.0000 3.838 0.007 4.5000 3.822 0.007 5.0000 3.822 0.012 5.5000 3.790 0.076 6.0000 3.758 0.257 6.5000 3.694 0.555 7.0000 3.615 0.931 7.5000 3.535 1.277 8.0000 3.456 1.532 8.5000 3.392 1.709 9.0000 3.344 1.829 9.5000 3.312 1.908 10.0000 3.296 1.966

I think it's kind of funky that it's so flat for ~half the slider. Also, the third column includes the Oscillator Output Monitor value from the MEDM screen at various RF Adjust slider values. All of these should be negative (i.e. -0.007), but the TABLE function doesn't like "-" signs. I don't know if this information is degenerate with the 'scope measurements, or if it's an indicator of what (might be) wrong.

After finishing, I plugged the cable back into the PMC servo board as it was, turned back on the ISS and relocked the PMC and the MC.
Attachment 1: RFSliderAdjustCalib.png
Attachment 2: RFSliderAdjustCalibWithOsc.png
1472   Fri Apr 10 19:10:53 2009 JenneUpdateGeneralXarm locked?

I don't know who left the X arm locked, but I just ran the Align Full IFO script, so everything is good in case Yoichi/someone comes in to lock the IFO this weekend.

1473   Sat Apr 11 00:45:41 2009 YoichiUpdatePSLPMC LO Calibration

 Quote: I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.

3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?
1475   Sun Apr 12 19:27:20 2009 ranaUpdatePSLPMC LO Calibration

 Quote: 3.8Vpp is about 16dBm. The mixer for the PMC demodulator is level 23. So 16dBm is insufficient. What is the level of the new mixer Steve ordered ? 13 ?

Since Steve and Jenne were on it, I'm sure they ordered the optimum values...

From the table, it looks like the drive level adjuster is busted. Its not supposed to just give a
1-2 dB change over the full range. We'll have to think about what exactly to do, but we should
probably install the level 13 mixer and put in the right attenuation to make the LO be ~13.5 dBm
including the filter. Also need to calibrate the LO readback on the board like what Peter did for
the FSS.
1477   Mon Apr 13 08:59:57 2009 steveUpdatePSLmixers on order

Quote:

 Quote: I then changed the RF Output Adjust slider in increments of 0.5, and measured the peak-to-peak values on the scope. In the table and on the plots, I've taken into account the 12dB attenuation. i.e I actually measured 964mV, so 964mV*10^.6 = 3838mV.

3.8Vpp is about 16dBm.
The mixer for the PMC demodulator is level 23. So 16dBm is insufficient.
What is the level of the new mixer Steve ordered ? 13 ?

I ordered mixers level 13, 17 on Friday and level 23 now.
They should be here Tuesday

NOTE: level 23 power is illegal to use in the 40m lab
They get hot
1478   Mon Apr 13 17:55:37 2009 JenneUpdatePSLPMC LO Mon Calibration

I have calibrated the PMC LO Mon (C1:PSL-PMC_LODET) on the PMC's EPICS screen, by inputting different RF LO levels into the LO input of the PMC servo board.

Since the RF output adjust slider on the PMC's Phase Shifter screen doesn't do a whole lot (see elog 1471), I used a combination of attenuators and the slider to achieve different LO levels. I measured the level of the attenuated RF out of the LO board using the 4395A in spectrum analyzer mode, with the units in dBm, with 50dB attenuation to make it stop complaining about being overloaded.  For each row in the table I measured the RF level using the 4395, then plugged the cable back into the PMC servo board to get the EPICS screen's reading.

The last 2 columns of the table below are the 'settings' I used to get the given RF LO level.

 RF LO Input to PMC Servo Board [dBm] LO Mon on EPICS Screen [no units] RF Output Adjust Slider [V] Attenuators used [dB] 16.004 +- 0.008 0.1200 +- 0.0003 0 0 15.001 +- 0.004 0.0708 +- 0.0008 0 1 14.079 +- 0.008 0.0318 +- 0.0001 8 1 13.002 +- 0.006 0.0126 +- 0.0004 0 3 11.992 +- 0.010 0.0024 +- 0.0008 0 4 10.994 +- 0.010 -0.0024 +- 0.0003 0 4+1=5 9.993 +- 0.008 -0.0047 +- 0.0007 0 3+3=6

When the new mixers that Steve ordered come in (tomorrow hopefully), I'll put in a Level 13 mixer in place of the current Level 23 mixer that we have.  Also, Rana suggested increasing the gain on the op-amp which is read out as the LO Mon so that 13dBm looks like 1V.  To do this, it looks like I'll need to increase the gain by ~80.

Attachment 1: LOmonCalibration.png
1480   Tue Apr 14 02:59:02 2009 YoichiUpdateLockingPower up until 26
Yoichi, Peter,

With careful adjustments of the common mode gains, we were able to go up to arm power = 26, sort of robustly (more 50% chance).
At this arm power level, the common mode loop shape still looks good. But the interferometer loses lock easily.
I have to check other DOFs, but the interferometer does not stay locked long enough.
Today, lock losses of the IFO were associated with the lock loss of the PMC whereas the FSS stayed locked.
Probably the AO path got large kicks, which could not be handled by the PMC PZT.

The cause for the IFO lock loss is under investigation.
1482   Tue Apr 14 17:20:36 2009 YoichiUpdateComputer Scripts / ProgramsParallel Optickle
I wrote a parallel version of tickle() function for Optickle.
The attached ptickle.m, which provides ptickle() command, can be used as a drop-in replacement of tickle() command.
Just download it and place it in the @Optickle directory.
This command will run multiple instances of Matlab to calculate the frequency responses in parallel.
The speed gain is roughly proportional to the number of CPU cores you use.

To use multiple cores, you have to run matlabpool() command first. See the comment at the beginning of ptickle.m for more detail.
The progress bar is disabled at this moment because it is not clear for me how to make a single progress bar from multiple instances of Matlab.

I sent the code to Matt, so this may be included in the next release of Optickle.
Attachment 1: ptickle.m
% Compute DC fields, and DC signals, and AC transfer functions
%
% This is a parallelized version of tickle. You have to run matlabpool(n)
% command before using this command. matlabpool(n) will invoke n instances
% of matlab workers in your computer. Once you have started those workers,
% you can reuse them many times (i.e. you don't have to run matlabpoo(n)
% every time you use ptickle). Usually n should be equal to the number of
% CPU cores in your computer, but the Matlab parallel computing toolbox has
% the limit of maximum 4 workers for a local computer. If you use a cluster
% of computers across a network, this limit does not apply. But I haven't

... 393 more lines ...
1484   Wed Apr 15 02:20:46 2009 rana, yoichiUpdateDMFDMF now working copy

We found that DMF/ was not an SVN working copy, so I wiped out the SVN version, imported the on-disk copy, moved it to DMFold/ and then checked out the SVN version.

We can delete DMFold/ whenever we are happy with the SVN copy.

1485   Wed Apr 15 03:52:27 2009 ranaUpdateDMFNDS client32 updated for DMF
Since our seisBLRMS.m complains about 'can't find hostname' after a few hours, even though matlab is able to ping fb40m,
I have recompiled the NDS mex client for 32-bit linux on mafalda and stuck it into the nds_mexs/ directory. This time I

compiled using the 'gcc' compiler instead of the 'ANSI C' compiler that is recommended in the README (which, I notice,

is now missing from Ben Johnsons web page!). Let's see how long this runs.

1487   Wed Apr 15 17:11:37 2009 JenneUpdatePSLEdited c1psl.db to calibrate PMC's LO mon


Following the method in Peter's Elog,

I edited c1psl.db to include the following:

grecord(calc, "C1:PSL-PMC_LOCALC")
{
field(INPB,"C1:PSL-PMC_LODET")
field(SCAN,".1 second")
field(PREC,"4")
field(CALC,".955*LOGE(B)-17.11")
}

I restarted c1psl (had to go hit the physical reset button since it didn't come back after telnet-ing and "reboot"ing) to make this take effect.

Next step is to tell the PMC screen to look at this _LOCALC rather than _LODET, and the screen will be calibrated into dBm.

Right now, the screen is as it always has been, because after relooking at the calibration, I no longer believe it.  This calibration claimes -19dBm for an LOmon value of 0.1200, when I actually measured +16dBm for this LOmon value.  So I've screwed something up in doing my MatLAB calibration.  I'll fix it tomorrow, and put in the correct calibration before I change the PMC screen.

RefCav, PMC, MC are all back and locked after my shenanigans.

1488   Thu Apr 16 11:17:56 2009 JenneUpdatePSLEdited c1psl.db to calibrate PMC's LO mon

 Quote:  I edited c1psl.db to include the following: grecord(calc, "C1:PSL-PMC_LOCALC") { field(INPB,"C1:PSL-PMC_LODET") field(SCAN,".1 second") field(PREC,"4") field(CALC,".955*LOGE(B)-17.11") }

As it turns out, I apparently can't tell X from Y when fitting a function in a rush.  The real calibration stuff which is now in c1psl.db is:

grecord(calc, "C1:PSL-PMC_LOCALC")
{
field(INPB,"C1:PSL-PMC_LODET")
field(SCAN,".1 second")
field(PREC,"4")
field(CALC,"1.004*LOGE(B)+17.76")
}

I restarted c1psl (again, had to go hit the physical reset button since it didn't come back after a telnet-reboot) to have it take in the changes.  The psl.db file that was in place before yesterday (before I touched it) is saved as psl.db.15Apr2009 just in case.


I edited the PMC EPICS screen to have the LO mon look at C1:PSL-PMC_LOCALC, which is the calibrated channel in dBm.  I also stuck a little label on the screen saying what units it's in, because everyone likes to know what units they're looking at.

1489   Thu Apr 16 16:26:57 2009 peteUpdateLockingWed. night locking
yoichi, pete

We installed the watchLockLoss script in scripts/AutoDTT/.  This script monitors arm power and uses command line
DTT to save 5 s snapshot of the interferometer when it senses loss of lock.  We ran it on linux and it seemed to
save an xml file about half the time; we'll try it on solaris.

I managed to get up to arm power of about 20 a couple of times.  IFO lost lock a couple of times after turning
off moving zero.  MC2 would often get tripped by lock loss and need resetting.  Maybe we will try to stiffen the
op levs.
1490   Thu Apr 16 16:37:42 2009 AlbertoUpdateAuxiliary lockingthe zipper

It takes 18 months to double the computational power of microprocessors but it took man thousands of years to invent the zipper. I never really understood that till these days.

Here is a sample of my latest results from Optickle simulations of the locking signal for the Power Recycling Cavity.

Thanks also to Rob's revolutionary bidimensional rotating matrix idea (I can see entire books of linear algebra going to be rewritten now because of that) I could find the way to determine the optimal demodulation phases for the demod signals.

There were also an other couple of missing details. But that came easily along.

The parfor function for the parallel computation in Matlab sped up some loops by a factor of 100.

In these particular plots there's still no CARM offset scan. That's what I'm going to post next on the elog, together with the signals for the other degrees of freedom.

Attachment 1: 19_3f_Current_40m_plots_SUCCESS.pdf
1491   Thu Apr 16 17:19:44 2009 AlbertoUpdateAuxiliary lockingthe zipper

 Quote: It takes 18 months to double the computational power of microprocessors but it took man thousands of years to invent the zipper. I never really understood that till these days. Here is a sample of my latest results from Optickle simulations of the locking signal for the Power Recycling Cavity. Thanks also to Rob's revolutionary bidimensional rotating matrix idea (I can see entire books of linear algebra going to be rewritten now because of that) I could find the way to determine the optimal demodulation phases for the demod signals. There were also an other couple of missing details. But that came easily along. The parfor function for the parallel computation in Matlab sped up some loops by a factor of 100.   In these particular plots there's still no CARM offset scan. That's what I'm going to post next on the elog, together with the signals for the other degrees of freedom.

Just to show that I'm confident I'm getting reasonable results, I'll post two PRC scans for different CARM. One set of plots is for the current 40m with -19.78 deg of SRM detuning phase, the other is for the Old Upgrade (9 Mhz vs the 11 currently planned) with no detuning phase.

I'm going to put together the results and get some conclusion about the 3f locking scheme for the current 40m and the upgrade.

Attachment 1: 04_3f_Current_40m_plots.pdf
Attachment 2: 11_3f_40mUpgrade_plots.pdf
1493   Fri Apr 17 11:05:22 2009 YoichiUpdateLockingThursday night locking status
The last night, it was sort of robust to go up until arm power = 26.
The REFL_DC gain seems to change a lot around this region. So I did fine adjustments of the gain with small incremental steps of the arm power.
This work will continue.
The AutoDTT shows that the lock loss happens with an oscillation of CARM at around 100Hz. This indicates that the cross-over is the culprit.
I was also able to increase the CM UGF up to 10kHz.
1495   Sun Apr 19 03:34:05 2009 YoichiUpdateLockingSaturday night lock
Tonight I was able to go up to arm power = 33, by mainly tweaking the DARM gain. A small progress.
In order to give more phase margin to the CARM MC_L path, I added a 300:100 filter to C1:LSC-MC.
To reduce the load to the lsc computer I deleted several filters from the filter bank, which were not used in the locking scripts.
Before I deleted the filters, I checked in the current chans directory into the svn repository.
If you want to restore the deleted filters, go back to the revision 36142.
1497   Sun Apr 19 11:51:05 2009 josephbUpdateCamerasMafalda may need an update

I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package.

I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing.  Basically I had all 404 Not Found errors.

Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008.  So there's a couple things that can be done:

1) Ignore it, and simply not update Mafalda anymore.  This also means some newer software and hardware simply won't work with it (like the usb frame grabber)

2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages.

3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10.

I'd personally lean towards the 3rd option, and go to the 8.04 long term support version.  If people agree with it, I could do the upgrade sometime Monday or Tuesday.

1499   Mon Apr 20 11:57:27 2009 robUpdateCamerasMafalda may need an update

 Quote: I tried installing libusb-dev on mafalda in order to try getting the usb frame grabber to work on it, but could not as it could not download the package. I then tried to do a sudo apt-get update, which failed completely, as the repository seems to have ceased existing.  Basically I had all 404 Not Found errors. Turns out Mafalda is still running Ubuntu 7.04, whose support ended late 2008.  So there's a couple things that can be done: 1) Ignore it, and simply not update Mafalda anymore.  This also means some newer software and hardware simply won't work with it (like the usb frame grabber) 2) Try to find another, unofficial repository which still has all of the Ubuntu 7.04 packages. 3) Upgrade to a newer, still supported Ubuntu, such as 7.10, 8.04, or 8.10. I'd personally lean towards the 3rd option, and go to the 8.04 long term support version.  If people agree with it, I could do the upgrade sometime Monday or Tuesday.

I don't see a reason to proliferate operating systems.  Is there any reason we actually need Ubuntu? Can we put CentOS on it?

1501   Mon Apr 20 18:36:37 2009 ranaUpdateCamerasMafalda may need an update
Sadly, the sensoray crap doesn't seem to build on CentOS. I too would prefer a homogenous solution,
but I don't know how to make this happen without punishing Joe with sensoray driver development on CentOS.
1506   Tue Apr 21 18:18:27 2009 steveUpdateVACmaglev failed

Our Osaka TG360MB maglev failed with CSB error message. This means that the dry emergency landing bearing has to be replaced.

I will consalt with Osaka about the choice of replacing bearing or installing new spare  tomorrow.

Mean while V1 is closed and the vac envelope is not pumped.

Valve configuration: BG -background, pumping on the RGA-only

High voltage to IOO PZT steering mirrors and OMC are turned off.

PSL output shutter is closed and manual block is in place.

I will start cooling the CYO pump in the morning, so the IFO will be pumped by noon.

Outgassing plus leakrate after  10 hrs the pressure is 2.3 mTorr

This rate of rise is normal and it is safe to work with the ifo.

Attachment 1: nopumping10h.jpg
1508   Thu Apr 23 13:55:43 2009 josephb, peterUpdateComputersRCG example

We successfully compiled and installed the Real time Code Generator "Hello World" example (which is a skeleton for the ETMX suspension controller) on megatron.  In order to get it to compile, we had to add a flag indicating the computer is stand alone, and not using a myrinet card at the moment.  This was done by adding the shmem_daq = 1 flag to the cdsParameters module.  The symptom was it was unable to find gm.h (and there is no installed /opt/gm directory).

It is called "sam".  It was installed to /cvs/cds/caltech/target/sam, and produced medm screens in /cvs/cds/caltech/medm/c1/sam.  As nothing points to these, I figure it won't harm any of the current configuration, but lets us play around a bit.  If by some strange reason, these do cause problems, feel free to remove them.

1509   Thu Apr 23 16:27:24 2009 YoichiUpdateLockingLocking with the cryo-pump
The last night, the IFO was unstabler than usual and the locking script often failed before reaching the power up stage.
The failure happened at random points.
I'm not sure if this is related to the operation of the cryo-pump.
The mode cleaner reflection image seemed to move around more than usual. Maybe it was just a high seismic night.
1511   Thu Apr 23 16:38:33 2009 steveUpdateVACvac valve relay box is shorting

Ben and I found this vacuum valve relay box intermittently shorthing yesterday.

It effects V4, V5, VA6 and VM1........   Please do not touch this box under the beam pipe next to the vac rack!

The function of this box to send 120VAC to the vacuum valve to move.

Attachment 1: vacrel.png
1512   Thu Apr 23 18:09:11 2009 YoichiUpdateEnvironmentEffect of cryopump
The attached is the trend plot of the MC1 accelerometer for 3 days.
It is evident that the seismic level increased by a factor of two on Wednesday morning (when Steve started the cryopump).
Attachment 1: SeisTrend.pdf
1514   Fri Apr 24 03:57:30 2009 YoichiUpdateLockingDARM demod phase
Tonight, I was able to go up to arm power = 40 by tweaking the DARM demodulation phase.
I think the DARM loop became unstable because the demodulation phase was not right and the error signal contained some junk from I-phase.
I did not do any sophisticated demodulation phase optimization. Rather I just tweaked the phase so that the dark port image becomes stable.
I will do more careful demodulation phase tuning next time.
1515   Fri Apr 24 04:38:49 2009 YoichiUpdateLockingDARM demod phase

 Quote: Tonight, I was able to go up to arm power = 40 by tweaking the DARM demodulation phase. I think the DARM loop became unstable because the demodulation phase was not right and the error signal contained some junk from I-phase. I did not do any sophisticated demodulation phase optimization. Rather I just tweaked the phase so that the dark port image becomes stable. I will do more careful demodulation phase tuning next time.

In the next try, I was actually able to go up to arm power = 70 stably.
At this power level we are ready for the RF CARM hand off.
1516   Fri Apr 24 11:34:32 2009 robUpdateLockingDARM demod phase

Quote:

 Quote: Tonight, I was able to go up to arm power = 40 by tweaking the DARM demodulation phase. I think the DARM loop became unstable because the demodulation phase was not right and the error signal contained some junk from I-phase. I did not do any sophisticated demodulation phase optimization. Rather I just tweaked the phase so that the dark port image becomes stable. I will do more careful demodulation phase tuning next time.

In the next try, I was actually able to go up to arm power = 70 stably.
At this power level we are ready for the RF CARM hand off.

There's actually code in place in the LSC to dynamically adjust the demod phase for AS1. I've never made much use of it, because it's possible to get around the problem with some gain tweaking if you start at the right phase, or because I did the DC readout handoff earlier.

Attached is a cartoon showing how the demod phase at the dark port changes as the CARM offset is decreased.
Attachment 1: darm_phase_rotate.png
1519   Fri Apr 24 17:26:57 2009 YoichiUpdateLockingDARM demod phase

 Quote: There's actually code in place in the LSC to dynamically adjust the demod phase for AS1. I've never made much use of it, because it's possible to get around the problem with some gain tweaking if you start at the right phase, or because I did the DC readout handoff earlier. Attached is a cartoon showing how the demod phase at the dark port changes as the CARM offset is decreased.

The cartoon is very nice.
I actually changed the demod phase continuously as the CARM offset was reduced to get up to arm power = 70.
As the CARM offset is changed, not only the DARM signal gain but also the phase margin around 100Hz changes if you use a fixed demodulation phase.
So it was necessary to change the demodulation phase to keep the DARM loop stable.
1522   Sat Apr 25 03:27:34 2009 YoichiUpdateLockingLocking status
Yoichi, Peter,

We are working on the final step of the lock acquisition, RF CARM hand off.
I was able to hand off the CARM error signal to RF once, but lost lock when decreasing the CARM offset to zero (it was too rapid).
I will try to make the process more robust tomorrow.
1523   Sun Apr 26 02:13:18 2009 YoichiUpdateLockingTwo more successes of RF CARM handoff
Tonight, the RF CARM hand off (mostly) succeeded twice.
But still, the IFO lost lock when I reduced the REFL_DC gain in the AO path to zero.

At the beginning of tonight's work, MICH DD hand off failed several times. This was because the the PD9 gains were set to zero.
I found that the offset script, which I called before starting the locking, fails to restore the gain values sometimes.
This happens when ezcaread fails to read the current gain. We have to be careful when running the LSCoffsets script.
1526   Tue Apr 28 04:30:16 2009 YoichiUpdateLockingRF full lock
Yoichi, Peter

I believe we have succeeded in the full lock of the interferometer with the RF signals.
The lock process is reasonably robust and repeatable.

I did a scan of the RF CARM offset and plotted the arm power as a function of the CARM offset (see the attachment).
The arm power goes maximum at non-zero CARM offset. I guess the RF CARM error signal has some offset.
Maybe the demodulation phase is wrong ? I will tweak this tomorrow.
The script to do this scan can be found at /cvs/cds/caltech/scripts/CM/CARMSweep.

I haven't tried DC readout yet.
Attachment 1: Sweep1.png
1531   Wed Apr 29 04:03:51 2009 YoichiUpdateLockingCARM RF changed to REFL_2I
Yoichi, Peter

As Rob suggested, the optimal demodulation phase is easier to find for REFL_2I than POX_1I.
Moreover, for 166MHz LO, we have a phase shifter (delay line) already installed. So we can easily change the demodulation phase of REFL_2I.
Tonight, we switched the RF CARM signal to REFL_2I.
To do so, I changed the signal going to the REFL1 input of the common mode board from POX_1I to REFL_2I.
I moved a BNC-T installed at the output of POX_1I to the REFL_2I output to split the REFL_2I signal and send it to the CM board.
Since the gain of the REFL_2I was about 20dB lower than that of POX_1I, I increased the gain of the SR560, which is installed between the REFL_2 demodulation board and the CM board, from 1 to 10.

With some gain tweaks, we were able to hand off the CARM from REFL_DC to REFL_2I. We also succeeded in switching the REFL_2I ADC channel from PD11 to PD2_DC (the output of the length path from the CM board). This switching is necessary in order to engage the boost on the CM board.

There remains some offset in the CARM when the arm power is maximized. This is expected because the REFL_2I demodulation phase is probably not exactly right.
I will optimize the demodulation phase tomorrow.
1533   Wed Apr 29 15:56:43 2009 robUpdateLockingeffect of SRCL detune on ARM powers in a CARM sweep

With no DARM offset, sweeping CARM shows an asymmetry between the state where we lock to a DARM spring and the state with a DARM anti-spring.  This is why we have a link between the DARM and CARM optical springs.

For each DARM detune direction (positive or negative, spring or anti-spring), there is only one CARM direction which can yield a DC-based error signal lock with a CARM offset but no DARM offset, which is what we want.

Attachment 1: CARMsweep_DARMspringnospring.png
1534   Thu Apr 30 05:49:06 2009 YoichiUpdateLocking166MHz LO phase changed
In order to optimize the REFL_2I demod phase, I changed the delay line setting for the 166MHz LO.
Right now, the delay is not yet optimal.
Since the AS166 shares the same LO, the digital demodulation phase of the AS166 had to be changed too.
The DD demod phases and the DD hand off script were also tweaked to improve the resonant condition of the central part.
Now we have more 166MHz coming out of the AS port and the SPOB is larger (more 33MHz resonant in PRC).

Since REFL166 and AS166 demodulation phases are not yet optimized, the cm_step script won't work at this moment.
1535   Thu Apr 30 15:10:54 2009 robUpdateLockingCARM RF changed to REFL_2I

 Quote: Yoichi, Peter As Rob suggested, the optimal demodulation phase is easier to find for REFL_2I than POX_1I. Moreover, for 166MHz LO, we have a phase shifter (delay line) already installed. So we can easily change the demodulation phase of REFL_2I. Tonight, we switched the RF CARM signal to REFL_2I. To do so, I changed the signal going to the REFL1 input of the common mode board from POX_1I to REFL_2I. I moved a BNC-T installed at the output of POX_1I to the REFL_2I output to split the REFL_2I signal and send it to the CM board. Since the gain of the REFL_2I was about 20dB lower than that of POX_1I, I increased the gain of the SR560, which is installed between the REFL_2 demodulation board and the CM board, from 1 to 10. With some gain tweaks, we were able to hand off the CARM from REFL_DC to REFL_2I. We also succeeded in switching the REFL_2I ADC channel from PD11 to PD2_DC (the output of the length path from the CM board). This switching is necessary in order to engage the boost on the CM board. There remains some offset in the CARM when the arm power is maximized. This is expected because the REFL_2I demodulation phase is probably not exactly right. I will optimize the demodulation phase tomorrow.

From Optickle simulations, it looks like the SRCL/CARM gain ratio at REFL I2 is about 8e-4. So a 1 nanometer offset in SRCL yields 0.8 picometers of offset in CARM.
1536   Fri May 1 01:32:43 2009 YoichiUpdateLocking166MHz LO phase adjustment
I continued to adjust the REFL_2I demodulation phase.
I first optimized the demod phase for SRCL in the DRMI configuration (the error signals were DDs).
Then I restored the full IFO and offset locked it.
Before handing the DARM to RF, I adjusted the 166MHz delay line to maximize the SRCL signal at REFL_2I.
I did this before the DARM RF hand off because changing the delay line setting also changes the AS166 demodulation phase.
After this, I adjusted the digital phase shifter for AS166 to maximize the DARM signal for this port.

I also adjusted the digital demodulation phase of PD11 (REFL_2I) because the optimal demodulation phase for the initial lock acquisition is somewhat (15deg)
different from the optimal demodulation phase for the SRCL when the central part is locked with the DD signals.
This happens because the resonant condition of the central part (lock points of the recycling cavities) changes when the error signals are switched to the DD signals,
due to the offset in the DD signals. This is not good and should be fixed by the optimization of the DD demodulation phases.

Finally, I reduced the CARM offset to zero and tweaked the delay line a bit to maximize the arm power.

Right now, the locking script runs fine until the end.
At the end of the script, I was able to engage the boost on the CM board.
1537   Fri May 1 10:04:10 2009 robUpdateLocking166MHz LO phase adjustment

 Quote: I continued to adjust the REFL_2I demodulation phase. I first optimized the demod phase for SRCL in the DRMI configuration (the error signals were DDs). Then I restored the full IFO and offset locked it. Before handing the DARM to RF, I adjusted the 166MHz delay line to maximize the SRCL signal at REFL_2I. I did this before the DARM RF hand off because changing the delay line setting also changes the AS166 demodulation phase. After this, I adjusted the digital phase shifter for AS166 to maximize the DARM signal for this port. I also adjusted the digital demodulation phase of PD11 (REFL_2I) because the optimal demodulation phase for the initial lock acquisition is somewhat (15deg) different from the optimal demodulation phase for the SRCL when the central part is locked with the DD signals. This happens because the resonant condition of the central part (lock points of the recycling cavities) changes when the error signals are switched to the DD signals, due to the offset in the DD signals. This is not good and should be fixed by the optimization of the DD demodulation phases. Finally, I reduced the CARM offset to zero and tweaked the delay line a bit to maximize the arm power. Right now, the locking script runs fine until the end. At the end of the script, I was able to engage the boost on the CM board.

Awesome. Up next: dewhitening.
1541   Sun May 3 22:48:12 2009 YoichiUpdateLockingSome measurements at the lock point
I attached some measurement results at when the IFO is at the full lock point.

The first plot shows the trend of the arm powers after the interferometer was locked.
The arm powers slowly increased after the lock. This increase is observed every time the IFO is locked.
Probably this is some sort of a thermal effect (mirror lensing, PD efficiency etc).

The second plot is a CARM offset sweep. Even after the demodulation phase optimization, the lock point is not exactly at the resonance.

The third plot is the open loop TF of the AO path. The CM loop UGF is about 20kHz.
The boost and the superboost1 were turned on when this TF was measured. The IFO loses lock if the superboost2 is turned on.

TO DO LIST
Measured the DARM loop shape.
I could not turn on the dewhitening filter for ETMY. ETMX had no trouble. I will check the dewhitening circuit.
Attachment 1: ArmPowerTrend.png
Attachment 2: CARMSweep.png
Attachment 3: CM-AO-Loop-SB1.png
1542   Mon May 4 10:38:52 2009 steveUpdateMOPAlaser power is dropped

As PSL-126MOPA_DTEC went up, the power out put went down yesterday

Attachment 1: dtecup.jpg
1543   Mon May 4 16:49:56 2009 AlbertoUpdateMOPAlaser power is dropped

 Quote: As PSL-126MOPA_DTEC went up, the power out put went down yesterday

Alberto, Jenne, Rob, Steve,

later on in the afternoon, we realized that the power from the MOPA was not recovering and we decided to hack the chiller's pipe that cools the box.

Without unlocking the safety nut on the water valve inside the box, Jenne performed some Voodoo and twisted a bit the screw that opens it with a screw driver. All the sudden some devilish bubbling was heard coming from the pipes.
The exorcism must have freed some Sumerian ghost stuck in our MOPA's chilling pipes (we have strong reasons to believe it might have looked like this) because then the NPRO's radiator started getting cooler.
I also jiggled a bit with the valve while I was trying to unlock the safety nut, but I stopped when I noticed that the nut was stuck to the plastic support it is mounted on.

We're now watching the MOPA power's monitor to see if eventually all the tinkering succeeded.

[From Jenne:  When we first opened up the MOPA box, the NPRO's cooling fins were HOT.  This is a clear sign of something badbadbad.  They should be COLD to the touch (cooler than room temp).  After jiggling the needle valve, and hearing the water-rushing sounds, the NPRO radiator fins started getting cooler.  After ~10min or so, they were once again cool to the touch.  Good news.  It was a little worrisome however that just after our needle-valve machinations, the DTEC was going down (good), but the HTEMP started to rise again (bad).  It wasn't until after Alberto's tinkering that the HTEMP actually started to go down, and the power started to go up.  This is probably a lot to do with the fact that these temperature things have a fairly long time constant.

Also, when we first went out to check on things, there was a lot more condensation on the water tubes/connections than I have seen before.  On the outside of the MOPA box, at the metal connectors where the water pipes are connected to the box, there was actually a little puddle, ~1cm diameter, of water. Steve didn't seem concerned, and we dried it off.  It's probably just more humid than usual today, but it might be something to check up on later.]

1544   Tue May 5 05:16:12 2009 YoichiUpdateLockingDC Readout and DARM response
Tonight, I was able to switch the DARM to DC readout a couple of times.
But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain.

I also measured DARM response when DARM is on RF.
The attached plot shows the DARM optical gain (from the mirror displacement to the PD output).
The magnitude is in an arbitrary unit.

I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below.

There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown.
I will consult with the Optickle model.
I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases).
Seems like the DARM loop gain measured at those frequencies are too low.
I will retry the measurement.
Attachment 1: DARM-TF.png
1545   Tue May 5 08:26:56 2009 robUpdateLockingDC Readout and DARM response

 Quote: Tonight, I was able to switch the DARM to DC readout a couple of times. But the lock was not as stable as the RF DARM. It lost lock when I tried to measure the DARM loop gain. I also measured DARM response when DARM is on RF. The attached plot shows the DARM optical gain (from the mirror displacement to the PD output). The magnitude is in an arbitrary unit. I measured a transfer function from DARM excitation to the DARM error signal. Then I corrected it for the DARM open loop gain and the pendulum response to get the plot below. There is an RSE peak at 4kHz as expected. The origin of the small bump and dip around 2.5kHz and 1.5kHz are unknown. I will consult with the Optickle model. I don't know why the optical gain decreases below 50Hz (I don't think it actually decreases). Seems like the DARM loop gain measured at those frequencies are too low. I will retry the measurement.

The optical gain does decrease below ~50Hz--that's the optical spring in action. The squiggles are funny. Last time we did this we measured the single arm TFs to compensate for any tough-to-model squiggles in the transfer functions which might arise from electronics or the suspensions.
1546   Tue May 5 09:22:46 2009 carynUpdatePEMzeros

For several of the channels on the PEM ADCU, zeros are occuring at the same time. Does anyone know why that might happen or how to fix it?

Attachment 1: zerotest2.png
Attachment 2: zerotest.png
1547   Tue May 5 10:42:18 2009 steveUpdateMOPAlaser power is back

 Quote: As PSL-126MOPA_DTEC went up, the power out put went down yesterday

The NPRO cooling water was clogged at the needle valve. The heat sink temp was around ~37C

The flow-regulator  needle valve position is locked with a nut and it is frozen. It is not adjustable. However Jeenne's tapping and pushing down on the plastic hardware cleared the way for the water flow.

We have to remember to replace this needle valve when the new NPRO will be swapped in. I checked on the heat sink temp this morning. It is ~18C

There is condensation on the south end of the NPRO body, I wish that the DTEC value would just a little higher like 0.5V

The wavelenght of the diode is temp dependent: 0.3 nm/C. The fine tuning of this diode is done by thermo-electric cooler ( TEC )

To keep the diode precisely tuned to the absorption of the laser gain material the diode temp is held constant using electronic feedback control.

This value is zero now.

Attachment 1: uncloged.jpg
1548   Tue May 5 11:44:33 2009 robUpdateLocking DARM response

Here's the RF DARM optical response, on the anti-spring side, from optickle. Note that for the f1 sideband, changing the demod phase mostly adjusts the overall gain, while for the f2 sideband a change in demod phase alters the shape of the response. This is the quadrature-selecting power of using a single RF sideband as a local oscillator.
Attachment 1: DARMtf_nospring.png
Attachment 2: DARMtf_demodphases.png
ELOG V3.1.3-