40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 309 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  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
DARM-TF.png
  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.]

  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
dtecup.jpg
  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
ArmPowerTrend.png
Attachment 2: CARMSweep.png
CARMSweep.png
Attachment 3: CM-AO-Loop-SB1.png
CM-AO-Loop-SB1.png
  1540   Sat May 2 16:34:31 2009 carynDAQPEMGuralp channels plugged back in

I plugged the Guralp cables back into the PEM ADCU

       Guralp NS1b ---> #11

       Guralp Vert1b --->#10

       Guralp EW1b --->#12

  1539   Fri May 1 18:51:34 2009 AlbertoSummaryEnvironmentearthquake

Earthquake 4.4 Leo Carrillo Beach.

Some of the watchdogs tripped out.

  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.

  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.
  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.
  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.
  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.
  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
CARMsweep_DARMspringnospring.png
  1532   Wed Apr 29 10:20:14 2009 steveHowToVACcryo pump interlock rule is waved

Quote:

I tested the cryopump interlock today. It is touchy. I do not have full confidence in it.

I'm proposing that VC1 gate valve should be kept closed while nobody is working in the 40m lab.

How to open gate valve:

1, confirm temp of 12K on the gauge at the  bottom of the cryopump

2, if medm screen cryo reads OFF( meaning warm) hit reset will result reading ON (meaning cold 12K )

3, open VC1 gate valve if P1 is not higher than 20 mTorr

 

VC1 was closed at 18:25,

IFO condition: not pumped,

expected leak plus  out gassing should be less than 5 mTorr/day

The RGA is in bg-mode, annuloses are closed off

 The Cryo pump is running reliably since April 22 hence there is no need to close VC1 repeatedly.

The photo switch interlock was put back onto the H2 vapor pressure gauge and it is working.

  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.
  1530   Tue Apr 28 17:51:13 2009 robHowToLockingsetting the RF CARM demod phase

Quote:

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

 

For POX33, the ideal phase for single arm locking does not yield a zero-offset CARM signal.  So the offset needs to be manipulated digitally. 

Attachment 1: XARM_phases_POX.pdf
XARM_phases_POX.pdf XARM_phases_POX.pdf XARM_phases_POX.pdf XARM_phases_POX.pdf
Attachment 2: CARM_phases_POX.pdf
CARM_phases_POX.pdf CARM_phases_POX.pdf CARM_phases_POX.pdf CARM_phases_POX.pdf
  1529   Tue Apr 28 16:36:24 2009 robHowToLockingsetting the RF CARM demod phase

To set the demod phase for RF CARM, sensed at REFL2 (REFL 166I), it suffices to set the demod phase for REFL2 to be the optimal phase for controlling SRCL in a no-arm state.

Attachment 1: CARM_phases_REFL.pdf
CARM_phases_REFL.pdf CARM_phases_REFL.pdf CARM_phases_REFL.pdf CARM_phases_REFL.pdf
Attachment 2: SRCL_phases_REFL.pdf
SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf SRCL_phases_REFL.pdf
  1528   Tue Apr 28 12:55:57 2009 CarynDAQPEMUnplugged Guralp channels

For the purpose of testing out the temperature sensors, I stole the PEM-SEIS_MC1X,Y,Z channels.

I unplugged Guralp NS1b, Guralp Vert1b, Guralp EW1b cables from the PEM ADCU(#10,#11,#12) near 1Y7 and put temp sensors in their place (temporarily).

  1527   Tue Apr 28 09:27:32 2009 steveConfigurationVACcryopump deserves some credit

Congratulation Yoichi and Peter for full rf locking at night. Let's remember that the cryopump was shaking the hole vac envelope and ifo during this full lock.

Attachment 1: cryfl.jpg
cryfl.jpg
Attachment 2: seiscryofl.jpg
seiscryofl.jpg
  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
Sweep1.png
  1525   Tue Apr 28 01:48:45 2009 peteConfigurationVACVC1 open

At about 1am or so Yoichi and I opened VC1.  CC1 had fallen to about 5e-5 torr.

  1524   Mon Apr 27 18:31:44 2009 steveConfigurationVACVC1 closed

CC1 5e-7 Torr,  VC1 closed at 18:25,  IFO is not pumped, RGA is in bg-mode

 

  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.
  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.
  1521   Sat Apr 25 02:54:25 2009 YoichiConfigurationVACReflector for the cryopump temperature monitor changed

Quote:
The temperature of the cryopump head is monitored by a photo switch looking at an aluminum foil reflector attached to the needle of the temperature gauge.
If the needle moves out of the 14K position, the photo switch will be triggered to close the cryopump gate valve.
However, this photo switch system has been touchy.
Tonight, the switch falsely tripped several times and closed the gate valve, which caused lock losses as the motion of the valve generates a lot of vibrations.
Seems to me, it was caused by the poor/irregular reflection from the wrinkled aluminum foil on the needle.
So I replaced the aluminum foil with a brand-new shiny one.


The photo switch still trips randomly. We need a better interlock.
  1520   Sat Apr 25 00:45:31 2009 YoichiConfigurationVACReflector for the cryopump temperature monitor changed
The temperature of the cryopump head is monitored by a photo switch looking at an aluminum foil reflector attached to the needle of the temperature gauge.
If the needle moves out of the 14K position, the photo switch will be triggered to close the cryopump gate valve.
However, this photo switch system has been touchy.
Tonight, the switch falsely tripped several times and closed the gate valve, which caused lock losses as the motion of the valve generates a lot of vibrations.
Seems to me, it was caused by the poor/irregular reflection from the wrinkled aluminum foil on the needle.
So I replaced the aluminum foil with a brand-new shiny one.
  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.
  1518   Fri Apr 24 16:24:25 2009 robOmnistructureVACPaschen

In response to Steve's elog entry, and for 40m posterity, I provide the Paschen Curve.

Attachment 1: paschens.png
paschens.png
Attachment 2: paschenplot.m
% Paschen Curve plotting

% From http://home.earthlink.net/~jimlux/hv/paschen.htm

% Breakdown voltage:
% Vbreakdown = B * p * d / (C + ln( p * d))
% 
% Breakdown field strength:
% Ebreakdown = p * ( B / ( C + ln ( p * d)))
% 
... 38 more lines ...
  1517   Fri Apr 24 16:02:31 2009 steveHowToVACcryo pump interlock rule

I tested the cryopump interlock today. It is touchy. I do not have full confidence in it.

I'm proposing that VC1 gate valve should be kept closed while nobody is working in the 40m lab.

How to open gate valve:

1, confirm temp of 12K on the gauge at the  bottom of the cryopump

2, if medm screen cryo reads OFF( meaning warm) hit reset will result reading ON (meaning cold 12K )

3, open VC1 gate valve if P1 is not higher than 20 mTorr

 

VC1 was closed at 18:25,

IFO condition: not pumped,

expected leak plus  out gassing should be less than 5 mTorr/day

The RGA is in bg-mode, annuloses are closed off

Attachment 1: cryo.png
cryo.png
  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
darm_phase_rotate.png
  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.
  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.
  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
-------------------------------------------------------
  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
SeisTrend.pdf
  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
vacrel.png
  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.
  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.
  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.

  1507   Wed Apr 22 11:16:26 2009 steveConfigurationVACCryo pump is ON and the Maglev is dead

The CRYO pump cooled down and VC1 was opened. This valve configuration is Cryo-only


PSL output shutter opened at 4pm 

PZT HV power supplies turned on for OMC and IOO steering mirrors.

There positions were not corrected to strain gauge values.

 

Ben helped us to conclude that the FAILURE led indicator is working correctly and

has nothing to do with the one lose, dangling wire#258 in the side connects of the vac rack.

 

I reset the CSB switch inside the Maglev controller and tried to start accelerating.

It fails after 2-3 sec and failure led light comes on.

Now we can say the MAGLEV 360 is DEAD and the new OSAKA TG420M can be swapped in.

However it requires new interface with our epics based MEDM or better...?

 

 

Attachment 1: cryoOn.jpg
cryoOn.jpg
  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
nopumping10h.jpg
  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.
  1504   Mon Apr 20 20:45:25 2009 ranaConfigurationGeneralSVN: project area added
I added the /cvs/cds/project/ directory to the SVN. I've noticed that we've been using target/ for code which is not
being targeted for any IOCs. This is out of line with the intention of separating real time FE code from just regular
code that we use for diagnostics or otherwise.

So please move all of your non-FE code over to project from target. And if you didn't have it in SVN at all, you
should experience level 3 shame and then import it.
  1503   Mon Apr 20 20:00:44 2009 ranaConfigurationIOOMcWFS gains re-allocated
Since it looks like the night time people have been running with a WFS gain of 0.05 and I like the slider
to be at 1.0, I lowered all of the WFS1/2_P/Y gains by 10 and increased the overall slider from 0.05 to 1.0.
So the loop gains are now 2x higher; with it like this I guess the UGFs are in the ~0.2-0.5 Hz range.
  1502   Mon Apr 20 19:51:51 2009 JenneConfigurationPSLPMC has new Level 13 Mixer installed

The new Level 13 mixer on the PMC servo board is installed (minicircuits SRA-3MH).   Since the RF output of the LO board was ~16dBm, I put a 3dB attenuator between the LO board and the LO input on the servo board.  Since the previous cable was *just* the right length, this required adding a tiny bit of cable.  I found a very short cable, which worked out nicely, and didin't leave bunches of extra cable between the two boards.  One of these days if I have time (i.e. if it is necessary), I'll make a new cable for this purpose, so that we don't have 2 cables daisy-chained. 

A note on the Mixer-replacement:  The mixer on the PMC servo board is soldered in a set of 8 through-holes, not stuck in a socket.  So I had to desolder the old Level 23 Mixer (minicircuits RAY-3) which was a total pain.  Unfortunately, in this process, I lifted one of the pads off the back side of the board.  Once the old mixer was removed, it became clear that the pin for the pad I had lifted was shorted via a trace on the front side of the board to the pin directly across from it.  So when installing the new mixer, I did my best to get some solder into the through-hole for the lifted-pad-pin, and then tied it using a jumper wire to the pin that it's shorted to on the front of the board.  You can't see the trace that shorts the two pins because it's underneath the mixer, when the mixer is installed.  (Sidenote: after talking with Rana, this should be okie-dokie, especially if these are ground pins).

The PMC and MC locked nice and happily after I replaced the board and turned all the HV supplies back on, so I call this a success!

I also measured the OLG of the PMC servo after today's adventures in mixer-land.  I get a UGF of 1.4kHz, with 66 degrees of phase margin.  The method for this is in elog 924.

I checked the phase slider setting of the PMC phase screen by putting 30kHz at 100mV into the Ext DC input of the servo board, and looking at the 30kHz peak output of the Mixer Out.  I fiddled with the phase slider, and chose the value for which the 30kHz peak was maximized.  The phase slider is now set to 5.0V. 

Attachment 1: PMColg20Apr2009.png
PMColg20Apr2009.png
  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.
  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
  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?

  1498   Mon Apr 20 05:18:42 2009 YoichiConfigurationLockingFM6 and FM10 of LSC-MC were restored
During tonight's locking work, I realized that FM6 and FM10 (both resonant gains around 20Hz) were actually activated by cm_step.
So I restored those filters from the svn history.
Instead, I removed a bunch of unused filters from LSC-DEMOD and LSC-DEMOD_A (moving zero filters) to off load c1lsc.

As for the locking itself, the DARM loop becomes unstable at around arm power = 30. I may have to add a filter to give a broader phase bubble.
  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.

 

 

  1496   Sun Apr 19 11:34:33 2009 josephbHowToCamerasUSB Frame Grabber - How to

To use the Sensoray 2250 USB frame grabber:

Ensure you have the following packages installed: build-essential, libusb-dev

Download the Linux manual and linux SDK from the Sensoray website at:

http://www.sensoray.com/products/2250data.htm

Go to the Software and Manual tab near the bottom to find the links.  The software can also be found on the 40m computers at /cvs/cds/caltech/users/josephb/sensoray/

The files are Manual2250LinuxV120.pdf and s2250_v120.tar.gz

Run the following commands in the directory where you have the files.

tar -xvf s2250_v120.tar.gz

cd s2250_v120

make

cd ezloader

make

sudo make modules_install

cd ..

At this point plug in the 2250 frame grabber.

sudo modprobe s2250_ezloader

Now you can run the demo with

./sraydemo or ./sraydemo64

Options will show up on screen.  A simple set to start with is "encode 0", which sets the recording type, "recvid test.mpg", which starts the recording in file test.mpg, and "stop", which stops recording.  Note there is no on screen playback.  One needs an installed mpeg player to view the saved file, such as Totem (which can screen cap to .png format) or mplayer.

All these instructions are on the first few pages of the Manual2250LinuxV120 pdf.

 

 

  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.
ELOG V3.1.3-