ELOG 40m

SEI

seisBLRMS already lost

Can't find hostname 'fb40m'

it only lasted a few hours

1558

Thu May 7 23:21:04 2009

Quote:

I've plotted TRX, TRY, PD12I and PD11Q. Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.

I should have mentioned that the AS port camera image seems to get progressively uglier over the course of these locks. Maybe we can use the JoeCam to make a movie of it.

1557

Thu May 7 18:12:12 2009

I've plotted TRX, TRY, PD12I and PD11Q. Arm powers after locking increase for a few tens of minutes, peak out, and then decrease before lock is lost.

Attachment 1: 2009_may_7_powers.jpg

1556

Thu May 7 17:59:23 2009

Alberto

MC WFS

This afternoon the MC could not get locked.

I first checked the Osems values at the MC mirrors and compared them to the trend of the last few hours. That showed that the alignment of the mirrors had slightly changed. I then brought each mirror back to its old alignment state.

That let the LSC loop lock the MC, although the reflected power was still high (1.5V) and the WFS control wouldn't engage.

Since earlier during the day I was working on the AS table, it is possible that I inadvertently hit the MC REFL beam splitter misaligning the beam to the MC WFS.

To exclude that there was a problem in the suspensions, before touching the WFS, I checked that the cables at the MC's ends and those going to the ADC in the rack were well pushed in.

Then I proceeded in centering the beam on both the WFS, balancing the power over the QPDs.

In the end the MC could lock again properly.

1555

Thu May 7 15:22:19 2009

Quote:

Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.

We brought it down and up several times between 11 and noon. We eventually were able to daisy chain the old raid and the new raid so that fb40m sees both. At this time, the RAID arrays are still daisy chained, but the computer is setup to run on just the original raid, while the full 14 TB array is initialized (16 drives, 1 hot spare, RAID level 5 means 14 TB out of the 16 TB are actually available). We expect this to take a few hours, at which point we will copy the data from the old RAID to the new RAID (which I also expect to take several hours). In the meantime, operations should not be affected. If it is, contact one of us.

This afternoon the alignment script chrashed after returning sysntax errors. We found that the tpman wasn't running on the framebuilder becasue it had probably failed to get restarted in one of the several reboots executed in the morning by Alex and Jo.

Restarting the tpman was then sufficient for the alignment scripts to get back to work.

1554

Thu May 7 12:21:36 2009

Having determined that Rana (the computer) was having to many issues with testing the new Raid array due to age of the system, we proceeded to test on fb40m.

1553

Thu May 7 10:28:20 2009

retrofitted maglev's needs

Our spare Osaka maglev purchased in Oct 2005 turned out to be having a viton o-ring seal connection on the intake.

It was shipped back to San Jose for retrofitting it with 6" conflat flange ( CF ) This CF is using copper gasket so there will be no permeation of He when you leak check the IFO

The digital controller and cable are here. The controller needs to be interfaced with the interlocks and computer system; those have been in a neglected condition lately.

see elog #1505 Historically after every REBOOT of c1vac2 the readbacks works for 3-4 days only. Fixing of this was postponed many times in the past as low priority or lack of knowledgeable

enthusiast.

The maglev TG390MCAB wil be back on Tuesday, May 4, 2009. The mourning of our fateful 360 will only end at the first levitation of the 390.

1552

Wed May 6 19:04:11 2009

Since there's no documentation on this besides Steve's paper notebooks...

and BTW, since when did the elog start giving us PNG previews of PDFs?

Attachment 1: vacrack.pdf

1551

Wed May 6 16:56:35 2009

rana, alex, joe

Computers

daqd log, cront, etc.

While Alex came over, we investigated the log file problems with DAQD and NDS on FB0. There was a lot of
the standard puzzling and mumbling, but eventually we saw that it doesn't create its log file and so it
doesn't write to it. The log file is /usr/controls/main_daqd.log. The other files called daqd.log.DATE
in the logs/ directory are actually not written to. Its awesome.

We also have put in a fix for the overflowing jobs/ directory. It gets a file written to it every time
you make and NDS request and our seisBLRMS has been overloading it. There's now a cron for it in the fb0
crontab which cleans out week-old files at 6:30 AM every day.

We also changed the time of the daily backup from 3:30 AM (when people are still working) to 5:50 AM
(by which time the seismic has ramped up and interferometerists should be asleep). I didn't like the
idea of a bandwidth hog nailing the framebuilder during the peak of interferometer work.

#
# Script to backup via rsync the most recent 40m minute trends and
# any changes to the /cvs/cds filesystem.
#
50 05 * * * /cvs/cds/caltech/scripts/backup/rsync.backup < /dev/null > /cvs/cds/caltech/scripts/\
backup/rsync.backup.log 2>&1

30 06 * * * find /usr/controls/jobs -mtime +7 -exec /bin/rm -f {} \;

seisBLRMS.m restarted on mafalda.

1550

Wed May 6 02:39:20 2009

How to go to DC readout

I wrote a script called DC_readout, which you can find in /cvs/cds/caltech/scripts/DRFPMI/bang/nospring/.

Currently, the locking script succeeds 1/3 of the time. The freaky parts are the MC_F hand off and REFL_DC hand off.
MC_F hand off succeeds 70% of the time. REFL_DC goes well about a half of the time. Combined, the success rate is about 1/3.
We need some work on those hand offs.
Once you pass those freaky parts, the cm_step script usually goes smoothly and you will reach the full RF lock with the boost and the super boost1 engaged on the CM board.

To go to DC readout from there, run the DC_readout script.
First, this script will put some offset to the DARM loop so that some carrier light will leak to the AS port.
You are prompted to lock the OMC. Move the OMC length offset slider to find the carrier resonance and lock the OMC.
You have to make sure that it is carrier, not the 166MHz sideband. Usually the carrier light pulsates around 10Hz or so whereas the 166MHz SB is stable.
Once you locked the OMC to the carrier, hit enter on the terminal running the DC_readout script.
The script will do the rest of the hand off.
Once the script has finished, you may want to check darm_offset_dc in the C1LSC_LA_SET screen. This value sets the DC offset (a.k.a. the homodyne phase).
You may want to change it to what you want.

1549

Tue May 5 14:02:16 2009

DARM DC response varies with DARM offset

LSC

Note the effect of quadrature rotation for small offsets.

Attachment 1: DARM_DARM_AS_DC_2.png

Attachment 2: DARM_DARM_AS_DC_3.png

Attachment 3: DARM_DARM_AS_DC_2.pdf

Attachment 4: DARM_DARM_AS_DC_3.pdf

1548

Tue May 5 11:44:33 2009

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

1547

Tue May 5 10:42:18 2009

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

1546

Tue May 5 09:22:46 2009

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

1545

Tue May 5 08:26:56 2009

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

1544

Tue May 5 05:16:12 2009

DC Readout and DARM response

Attachment 1: DARM-TF.png

1543

Mon May 4 16:49:56 2009

Alberto

MOPA

laser 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

MOPA

laser power is dropped

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

Attachment 1: dtecup.jpg

1541

Sun May 3 22:48:12 2009

Some 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

1540

Sat May 2 16:34:31 2009

caryn

DAQ

PEM

Guralp 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

Earthquake 4.4 Leo Carrillo Beach.

Some of the watchdogs tripped out.

1538

Fri May 1 18:24:36 2009

Alberto

Summary

General

jitter 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

166MHz 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

166MHz LO phase adjustment

1535

Thu Apr 30 15:10:54 2009

CARM 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

166MHz 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

effect 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

1532

Wed Apr 29 10:20:14 2009

cryo 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

CARM RF changed to REFL_2I

1530

Tue Apr 28 17:51:13 2009

setting 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

Attachment 2: CARM_phases_POX.pdf

1529

Tue Apr 28 16:36:24 2009

setting 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

Attachment 2: SRCL_phases_REFL.pdf

1528

Tue Apr 28 12:55:57 2009

Caryn

DAQ

PEM

Unplugged 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

cryopump 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

Attachment 2: seiscryofl.jpg

1526

Tue Apr 28 04:30:16 2009

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

1525

Tue Apr 28 01:48:45 2009

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

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

Two 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

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

Reflector 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

Reflector for the cryopump temperature monitor changed

1519

Fri Apr 24 17:26:57 2009

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

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

Attachment 1: 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

cryo 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

1516

Fri Apr 24 11:34:32 2009

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.

Attachment 1: darm_phase_rotate.png

1515

Fri Apr 24 04:38:49 2009

Quote:

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

Thu Apr 23 21:13:37 2009