40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 311 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  1682   Wed Jun 17 01:07:50 2009 robConfigurationComputersmatapps on /cvs/cds

I checked out a copy of matapps into /cvs/cds/caltech/apps/lscsoft so that I could find the matlab function strassign.m, which is necessary for some old mDV commands to run.  I don't know why it became necessary or why it disappeared if it did.

  1681   Tue Jun 16 20:03:41 2009 AlbertoUpdateElectronicsRequirements on Wenzel Multiplier

For the 40m Upgrade, we plan to eliminate the Mach-Zehnder and replace it with a single EOM driven by all three modulation frequencies that we'll need: f1=11MHz, f2=5*f1=55MHz, fmc=29.5MHz.

A frequency generator will produce the three frequencies and with some other electronics we'll properly combine and feed them to the EOM.

The frequency generator will have two crystals to produce the f1 and fmc signals. The f2 modulation will be obtained by a frequency multiplier (5x) from the f1.

The frequency multiplier, for the way it works, will inevitably introduce some unwanted harmonics into the signals. These will show up as extra modulation frequencies in the EOM.

In order to quantify the effects of such unwanted harmonics on the interferometer and thus to let us set some limits on their amplitude, I ran some simulations with Optickle. The way the EOM is represented is by three RF modulators in series. In order to introduce the unwanted harmonics, I just added an RF modulator in series for each of them. I also made sure not to leave any space in between the modulators, so not to introduce phase shifts.

To check the effect at DC I looked at the sensing matrix and at the error signals. I considered the 3f error signals that we plan to use for the short DOFs and looked at how they depend on the CARM offset. I repeated the simulations for several possible amplitude of the unwanted harmonics. Some results are shown in the plots attached to this entry. 'ga' is the amplitude ratio of the unwanted
harmonics relative to the amplitude of the 11 & 55 MHz modulations.

Comparing to the case where there are no unwanted harmonics (ga = 0), one can see that not considerable effect on the error signals for amplitudes 40dB smaller than that of the main sidebands. Above that value, the REFL31I signals, that we're going to use to control PRCL, will start to be distorted: gain and linearity range change.

So 40 dB of attenuation in the unwanted harmonics is probably the minimum requirement on the frequency multiplier, although 60dB would provide a safer margin.

I'm still thinking how to evaluate any AC effect on the IFO.

 

** TODO: Plot DC sweeps with a wider range (+/- 20 pm). Also plot swept sines to look for changes in TFs out to ~10 kHz.

Attachment 1: SummaryOfResult.pdf
SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf SummaryOfResult.pdf
  1680   Tue Jun 16 17:38:35 2009 robUpdateLockingDeWhites ON

With the common mode servo bandwidth above 30kHz and the BOOST on (1), I was able to switch on the test mass dewhitening.  Finally.

  1679   Tue Jun 16 16:10:01 2009 peteUpdateLockinginput matrix experiments

Last night Rob ran senseDRM and loadDRMImatrixData and came up with the following for the input matrix:

tdswrite C1:LSC-ITMTRX_b2 0.065778 \
C1:LSC-ITMTRX_d2 2.2709 \
C1:LSC-ITMTRX_f2 2.9361 \
C1:LSC-ITMTRX_122 0.42826 \
C1:LSC-ITMTRX_b3 -0.064839 \
C1:LSC-ITMTRX_d3 -0.016913 \
C1:LSC-ITMTRX_f3 -0.021576 \
C1:LSC-ITMTRX_123 -0.0025243 \
C1:LSC-ITMTRX_b5 0.3719 \
C1:LSC-ITMTRX_d5 1.3109 \
C1:LSC-ITMTRX_f5 -0.16412 \
C1:LSC-ITMTRX_125 0.39574 \
C1:LSC-ITMTRX_33 0 \
C1:LSC-ITMTRX_42 0 \
C1:LSC-ITMTRX_155 0

Today, I reran these and got the following, and DD_handoff remained happy:

tdswrite C1:LSC-ITMTRX_b2 -0.10329 \
C1:LSC-ITMTRX_d2 2.0344 \
C1:LSC-ITMTRX_f2 3.2804 \
C1:LSC-ITMTRX_122 0.22516 \
C1:LSC-ITMTRX_b3 -0.076292 \
C1:LSC-ITMTRX_d3 -0.014603 \
C1:LSC-ITMTRX_f3 -0.12101 \
C1:LSC-ITMTRX_123 0.0054128 \
C1:LSC-ITMTRX_b5 0.33521 \
C1:LSC-ITMTRX_d5 1.1425 \
C1:LSC-ITMTRX_f5 -0.32759 \
C1:LSC-ITMTRX_125 0.25877 \
C1:LSC-ITMTRX_33 0 \
C1:LSC-ITMTRX_42 0 \
C1:LSC-ITMTRX_155 0

I wanted to remeasure with the canonical output matrix (-0.7 from MICH to PRM and 0.7 from MICH to SRM), but the DRM freaked out when MICH to PRM went below -0.3.

  1678   Tue Jun 16 14:02:16 2009 robUpdateLockinglocked

The IFO is locked, at the operating point (zero CARM offset).  The problem with reducing the residual CARM offset in the last stage appears to have been because the common mode gain was getting too high, and so the loop was going unstable at high frequencies. 

The cm_step script is currently a confusing mess, with all the debugging statements.  I'll clean it up this afternoon and check that it still works.

  1677   Tue Jun 16 09:02:30 2009 steveConfigurationVACnew maglev RGA scan

The maglev fore line pressure is 3e-6 torr at CC2 after 4 days of pumping. Varian turbo V-70 is pumping on it through V4 and VM2

Actual pumping speed ~10 l/s for N2. There was no baking. The maglev performance looks good : 3e-9 torr on CC4  with RGA -region only.

Attachment 1: nmagd4scan.jpg
nmagd4scan.jpg
Attachment 2: nmagd4.jpg
nmagd4.jpg
  1676   Tue Jun 16 03:43:04 2009 robUpdateLockingsame troubles

Lock is still being lost, right at the end of the process when trying to reduce the CARM offset to zero.

  1675   Tue Jun 16 02:09:31 2009 robUpdateLockingDD handoff finally working

I had trouble getting the SRC handoff from SD to DD to work.  I tried different gains, flipping the PD7 & 8 demod phases by 180 degrees, and messing with the output matrix to reduce cross-couplings in the state with MICH & PRC on DD and SRC on SD.  Eventually I decided to try to make the DRM matrix diagonalization work. 

It does, mostly.  The handoff is now stable, and the loops all have UGFs around 100Hz.  So, tonight anyways, it's possible to run senseDRM and then loadDRMImatrixData.m and run the resulting tdswrite command, and have a working handoff.  I had to eliminate a few PDs (PD5 & PD10) to get it to work properly. 

It would be nice if this script would measure all the PDs and allow individual setting of loop UGFs and measurement frequencies. 

 

 

  1674   Mon Jun 15 16:31:36 2009 steveConfigurationVACRGA is scanning new Maglev

Quote:

Quote:

Joe and Steve

 

The retrofitted Osaka 390 was installed on the pumpspool yesterday.

V1 gate valve is disabled for safety by disconnected pneumatic power plug.

The foreline of this maglev now have a KF25 size viton o-ring directly on the turbo.

This is bad for leak hunting.

Joe is ready with new interface cable. Power supply and cables are in place.

The maglev was pumped down this morning.

All new gas kits and metal hose were leak checked by sprayed methanol.

There is no obvious sign of leak. I was expecting the pressure to drop below 1e-5 Torr in one hour.

TP2 is drying out the levitating coils of the turbo at ~7 l/s for N2

We'll start the pump as soon as Joe is in.

 

 

 Joe and Steve

 

The Maglev is running at 680 Hz, 40,800 RPM with V1 gate valve  closed and  valve disabled to change position. C1vac2 was rebooted before starting.

Interlocks are not tested yet, but the medm COVAC_MONITOR.adl screen is reading correctly. RGA scan will determine the need for baking on Monday

The foreline pressure is still  ~2e-5 Torr

Acceleration takes 3 minutes 30sesconds without load. There is no observabale temp effect on the body of the turbo during braking and acceleration.

 

The IFO is still pumped by the CRYO only

 The new Maglev fore line pressure is at 4e-6 torr at day 3

Valve VM1 was closed to isolate IFO from RGA and valve VM2 was opened so the RGA can scan the Maglev only.

 

  1673   Mon Jun 15 15:17:33 2009 josephb, SteveConfigurationVACVacuum control and monitor screens

We updated the vacuum control and monitor screens  (C0VAC_MONITOR.adl and C0VAC_CONTROL.adl).  We also updated the /cvs/cds/caltech/target/c1vac1/Vac.db file.

1) We changed the C1:Vac-TP1_lev channel to C1:Vac-TP1_ala channel, since it now is an alarm readback on the new turbo pump rather than an indication of levitation.  The logic on printing the "X" was changed from X is printed on a 1 = ok status) to X is printed on a 0 = problem status.  All references within the Vac.db file to C1:Vac-TP1_lev were changed.  The medm screens also now are labeled Alarm, instead of Levitating.

2) We changed the text displayed by the CP1 channel (C1:Vac-CP1_mon in Vac.db) from "On" and "Off" to "Cold - On" and "Warm - OFF".

3) We restarted the c1vac1 front end as well as the framebuilder after these changes.

  1672   Fri Jun 12 15:34:49 2009 steveConfigurationVACmaglev is running

Quote:

Joe and Steve

 

The retrofitted Osaka 390 was installed on the pumpspool yesterday.

V1 gate valve is disabled for safety by disconnected pneumatic power plug.

The foreline of this maglev now have a KF25 size viton o-ring directly on the turbo.

This is bad for leak hunting.

Joe is ready with new interface cable. Power supply and cables are in place.

The maglev was pumped down this morning.

All new gas kits and metal hose were leak checked by sprayed methanol.

There is no obvious sign of leak. I was expecting the pressure to drop below 1e-5 Torr in one hour.

TP2 is drying out the levitating coils of the turbo at ~7 l/s for N2

We'll start the pump as soon as Joe is in.

 

 

 Joe and Steve

 

The Maglev is running at 680 Hz, 40,800 RPM with V1 gate valve  closed and  valve disabled to change position. C1vac2 was rebooted before starting.

Interlocks are not tested yet, but the medm COVAC_MONITOR.adl screen is reading correctly. RGA scan will determine the need for baking on Monday

The foreline pressure is still  ~2e-5 Torr

Acceleration takes 3 minutes 30sesconds without load. There is no observabale temp effect on the body of the turbo during braking and acceleration.

 

The IFO is still pumped by the CRYO only

  1671   Fri Jun 12 09:56:38 2009 steveConfigurationVACnew maglev installed

Joe and Steve

 

The retrofitted Osaka 390 was installed on the pumpspool yesterday.

V1 gate valve is disabled for safety by disconnected pneumatic power plug.

The foreline of this maglev now have a KF25 size viton o-ring directly on the turbo.

This is bad for leak hunting.

Joe is ready with new interface cable. Power supply and cables are in place.

The maglev was pumped down this morning.

All new gas kits and metal hose were leak checked by sprayed methanol.

There is no obvious sign of leak. I was expecting the pressure to drop below 1e-5 Torr in one hour.

TP2 is drying out the levitating coils of the turbo at ~7 l/s for N2

We'll start the pump as soon as Joe is in.

 

 

Attachment 1: m390pd.jpg
m390pd.jpg
  1670   Fri Jun 12 02:01:03 2009 robUpdateComputer Scripts / ProgramsDRM matrix diagonalization

I started two scripts, senseDRM and loadDRMImatrixData.m, which Peter will bang on until they're correct.  They're in the $SCRIPTS/LSC directory.  The first is a perl script which uses TDS tools to drive the DRM optics and measure the response at the double demod photo-detectors, and write these results to a series of files loadable by matlab.  The second loads the output from the first script, inverts the resulting sensing matrix to get an input matrix, and spits out a tdswrite command which can be copied and pasted into a terminal to load the new input matrix values. 

What's left is mainly in figuring out how to do the matrix inversion properly.  Right now the script does not account for the output matrix, the gains in the feedback filters at the measurement frequency, or the fact that we'll likely want the UGF of our loops to be less than the measurement frequency.  Peter's going to hash out these details.

  1669   Thu Jun 11 22:14:10 2009 AlbertoUpdateLSCDD Handoff for the Short DOFs completed

This afternoon I tuned the handoff script for the SRC, after that Rob eralier during the day had already adjusted that for PRC. To do that, I followed the procedure in the Wiki.

  • I measured the OL transfer function of the single demod path and of the double demod path and tuned thier gains so that they matched
  • I tuned the double demod pahses of PD_7 and PD_8 in order to reduce the offset in the PD_x_I signals

After that the SRC could get locked with the double demod signals. the open loop transfer function emasurement on the PRC loop showed that it was nearly unstable. Rob reduced a little its gain to improve the stability.

The DD handoff is now working and we can get back to locking the interferometer.

  1668   Thu Jun 11 14:54:18 2009 josephb, albertoUpdateComputersWireless network

After poking around for a few minutes several facts became clear:

1) At least one GPIB interface has a hard ethernet connection (and does not currently go through the wireless).

2) The wireless on the laptop works fine, since it can connect to the router.

3) The rest of the martian network cannot talk to the router.

This led to me replugging the ethernet cord back into the wireless router, which at some point in the past had been unplugged.  The computers now seem to be happy and can talk to each other.

 

  1667   Thu Jun 11 03:15:15 2009 AlbertoUpdateLSCDD Handoff attempts

Pete, Alberto,

tonight we worked on the tuning of the double demod phases for the handoff of the short DOFs control signals.

Only MICH can now undergo the handoff. PRC can't make it.

Basically, we tuned the PD6 demod phase and reduced the offset in PD6_I. Then we tuned the relative gain of PD6_I and PD2_I so that the two open loop transfer function of the control loops would match. We tried that in several ways and several times but without success.

I guess we're missing to do/check something.

  1666   Wed Jun 10 09:28:14 2009 steveUpdatePSLPMC

The PMC alarm was on this morning. It was relocked at lower HV

The FSS_RMTEMP jumped 0.5 C so The PZT was compensating for it.

 

Attachment 1: pmctemphv.jpg
pmctemphv.jpg
  1665   Wed Jun 10 09:06:12 2009 steveUpdatePEMparticle counts and turbulance

I moved the mobile HEPA filter from ITMX's north door to ITMX-ISCT and covered it up with a merostate tent to accommodate the aluminum foil particle measurement on June 5

It lowered the 40m baseline counts by about a factor of 3 of 0.5 micron and a factor of 2 of 1.0 micron.

The HEPA filter is sweeping the floor and blowing the particles upwards. The MET ONE counter is on the top of the IOOC looking south at ~75 degrees upward.

 

Attachment 1: parturbulnc.jpg
parturbulnc.jpg
  1664   Wed Jun 10 01:52:34 2009 AlbertoUpdateElectronicsMC length and Marconis' frequencies

Pete, Rob, Alberto,

yesterday we thought that some of the problems we were having in locking the IFO might be related to a change of the length of the mode cleaner. So today we decided to measure it again.

We followed the Sigg-Frolov technique (see 40m Wiki, Waldman, Fricke). For the record, the MC_AO input corresponds to IN2 on the MC Servo board.

We obtained: L = 27.092 +/- 0.001 m

From the new measurement we reset the frequencies of the Marconis to the following values:

33196450 Hz

132785800 Hz

165982250 Hz

199178700 Hz

 

  1663   Tue Jun 9 23:25:24 2009 robUpdateLocking?

Quote:

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

 

Well, it hasn't gone away yet.  It happened Sat, Mon, and Tues afternoon, as well as Friday.  The threshold varies slightly, but is always around ~200-300 cnts.   I've tried reducing the offset with the signal coming from the CM board and the signal not going through the CM board, I've also tried jumping the signal to zero (rather than a gradual reduction). 

Tonight we'll measure the MC length and set the modulation frequencies, and maybe try some MZ tweaking to do RFAMMon minimization.    

  1662   Tue Jun 9 11:29:07 2009 JenneUpdateoplevsMeasured ETMY oplev beam size...put everything back

I measured the ETMY oplev beam size at a couple different distances away from the HeNe by taking out the steering mirror and letting the light propagate a ways.  I put the steering mirror back, aligned the oplev, and was able to relock the Yarm, so I think it's all back as it has been the last couple of weeks.

 

Now I need t o do some geometry and ray-tracing matrices to decide what focal length lens to buy, then we'll have  a shiny new ETMY oplev. 

  1661   Mon Jun 8 18:22:27 2009 AlbertoDAQLSCAdded PD11 I amd Q slow channels

I just added two slow channels to C0EDCUEPICS to monitor the input of PD11. The names are:

[C1:LSC-PD11_I_INMON]
[C1:LSC-PD11_Q_INMON]

  1660   Sun Jun 7 04:57:39 2009 YoichiUpdateLocking?

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

  1659   Sat Jun 6 01:44:53 2009 rob UpdateLocking?

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

  1658   Fri Jun 5 17:22:55 2009 peteUpdateLockingdaytime locking

After fixing the tp problem, I tried locking again.  Grabbing and DD handoff, no problem.  Died earlier than last night, handing off CARM to REFL_DC, around arm power of 4 or so.  Seems to happen after turning off the moving zero, Rob says it might be touchy in daytime.

  1657   Fri Jun 5 16:45:28 2009 rob, peteHowToComputerstdsavg failure in cm_step script

Quote:

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

Restarting the framebuilder didn't work, but the problem now appears to be fixed.

Upon reflection, we also decided to try killing all open DTT and Dataviewer windows.  This also involved liberal use of ps -ef to seek out and destroy all diag's, dc3's, framer4's, etc.

 

That may have worked, but it happened simultaneously to killing the tpman process on fb40m, so we can't be sure which is the actual solution.

 

To restart the testpoint manager:

what you type is in bold:

rosalba> ssh fb40m

fb40m~> pkill tpman

The tpman is actually immortal, like Voldemort or the Kurgan or the Cylons in the new BG.  Truly slaying it requires special magic, so the pkill tpman command has the effect of restarting it.

 

In the future, we should make it a matter of policy to close DTTs and Dataviewers when we're done using them, and killing any unattended ones that we encounter.

 

  1656   Fri Jun 5 13:51:49 2009 robUpdateLockingtdsavg failure in cm_step script

Quote:

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

 Did you try restarting the framebuilder?

 

What you type is in bold:

op440m> telnet fb40m 8087

daqd> shutdown

 

  1655   Fri Jun 5 02:59:03 2009 pete, albertoUpdateLockingtdsavg failure in cm_step script

the command

tdsavg 5 C1:LSC-PD4_DC_IN1

was causing grievous woe in the cm_step script.  It turned out to fail intermittently at the command line, as did other LSC channels.  (But non-LSC channels seem to be OK.)  So we power cycled c1lsc (we couldn't ssh).

Then we noticed that computers were out of sync again (several timing fields said 16383 in the C0DAQ_RFMNETWORK screen).  We restarted c1iscey, c1iscex, c1lsc, c1susvme1, and c1susvme2.  The timing fields went back to 0.  But the tdsavg command still  intermittently said "ERROR: LDAQ - SendRequest - bad NDS status: 13".

The channel C1:LSC-SRM_OUT16 seems to work with tdsavg every time.

Let us know if you know how to fix this. 

 

  1654   Fri Jun 5 01:10:13 2009 rob, peteUpdateLockingundermined

We were stymied early in the evening by a surreptitiously placed, verbo-visually obfuscated command in the drstep script. 

  1653   Thu Jun 4 23:39:23 2009 peteUpdatePEM5 days, 20 days of accelerometers

Looks like yesterday was particularly noisy.  It's unclear to me why diurnal variation much more visible in MC1_Y, and why the floor wanders.

 

The first plot shows 5 days.  The second plot shows 20 days.

Attachment 1: acc_5day.png
acc_5day.png
Attachment 2: acc_20days.png
acc_20days.png
  1652   Thu Jun 4 16:54:19 2009 peteUpdateLockingdaytime DD handoff

I played with the DD handoff during the day.  The DRM dark port was flickering like a candle flame in Dracula's castle.  The demod offsets for the handoff signals looked fine.  After MICH handoff, the MICH_CTRL started to get unstable at some low frequency, maybe 3 Hz (I didn't measure).  So I increased the MICH gain from 0.1 to 0.17 and it settled down.  PRC and SRC went fine.  Then the DD_handoff script raised the MICH gain to 0.7, and an instability started to grow in MICH_CTRL (at some higher frequency).  I decreased the MICH gain from 0.7 to 0.5, and it settled down and stayed stable.

  1651   Thu Jun 4 15:53:15 2009 steveUpdatePSLNPRO cooling flowrate adjusted

The Neslab chiller is working well. It's temp display shows 20.0 C rock solid. Flow meter rotating at 13.5Hz at the out put of the chiller.

The MOPA temp was measured with a hand held thermocouple . The  PA was  34 C and 29 C at NPRO heat sink.

The NPRO flow meter was not rotating at this time. There was just trickeling water flow though the meter.

I closed the needle valve this point. It needed 8 turns clockwise. This drives head temp to 19.9 C

Than I opened the needle valve 9 turns and the flow meter wheel was  rotaing at ~ 1 Hz

We gained a little power. Can you explain this?

 

Attachment 1: needlevalve.jpg
needlevalve.jpg
  1650   Thu Jun 4 01:32:20 2009 robConfigurationLSCAS port mode scan

Here is a set of mode scans of the AS port, using the OMC as a mode scanner.  The plot overlays various configurations of the IFO.  

To remove PZT nonlinearity, each scan was individually flattened in fsr-space by polynomial (3rd order) fitting to some known peak locations (the carrier and RF sidebands).
 

Attachment 1: modes.png
modes.png
  1649   Wed Jun 3 18:55:27 2009 ranaUpdateCOCsnapshot of upgrade layout
Attachment 1: layout.png
layout.png
  1648   Wed Jun 3 12:31:13 2009 carynUpdatePEMplugged in guralp channels
  1647   Wed Jun 3 11:28:01 2009 carynUpdatePEMUnplugged Guralp channels
  1646   Wed Jun 3 03:30:52 2009 ranaUpdateMOPANPRO current adjust
I increased the NPRO's current to the max allowed via EPICS before the chiller shutdown. Yesterday, I did this
again just to see the effect. It is minimal.

If we trust the LMON as a proportional readout of the NPRO power, the current increase from 2.3 to 2.47 A gave us
a power boost from 525 to 585 mW (a factor of 1.11). The corresponding change in MOPA output is 2.4 to 2.5 W
( a factor of 1.04).

Therefore, I conclude that the amplifier's pump has degraded so much that it is partially saturating on the NPRO
side. So the intensity noise from NPRO should also be suppressed by a similar factor.

We should plan to replace this old MOPA with a 2 W Innolight NPRO and give the NPRO from this MOPA back to the
bridge labs. We can probably get Eric G to buy half of our new NPRO as a trade in credit.
Attachment 1: Untitled.png
Untitled.png
  1645   Wed Jun 3 03:22:16 2009 peteUpdateLockingDD handoff

Rana, Alberto, Pete

We have the DD handoff nominally working.  Sometimes, increasing the SRC gain at the end makes MICH get unstable.  This could be due to a non-diagonal term in the matrix, or possibly because the DRM locks in a funky mode sometimes. 

To get the DD handoff working, first we tuned demod phases in order to zero the offsets in the PD signals handed-off-to.  Based on transer function measurements, I set the PRC PD6_I element to 0.1, and set the PD8_I signal to 0, since it didn't seem to be contributing much.  We also commented out the MICH gain increase at the end of the DD_handoff script.

It could still be more stable, but it seems to work most of the time.

 

 

  1644   Tue Jun 2 23:55:45 2009 AlbertoUpdateoplevsoplevs centerd

Tonight I centered the oplevs for ITMX/Y, SRM, PRM, BS.

After doing that I noticed that the BS drifted a little from where I had set it.

  1643   Tue Jun 2 23:53:12 2009 peteDAQComputersreset c1susvme1

rob, alberto, rana, pete

we reset this computer, which was out of sync (16384 in the FE_SYNC field instead of 0)

  1642   Tue Jun 2 23:12:08 2009 robConfigurationComputersntp on op440m

I restarted ntpd on op440m to solve a "synchronization error" that we were having in DTT.  I also edited the config file (/etc/inet/ntp.conf) to remove the lines referring to rana as an ntp server; now only nodus is listed.

To do this:

log in as root

/usr/local/bin/ntpd -c /etc/inet/ntp.conf

  1641   Tue Jun 2 02:28:58 2009 peteUpdateLockingDD handoff work

alberto, pete

 

We worked on tuning the DD handoff tonight.  We checked the DD PD alignments and they looked fine.  First I tuned the 3 demod phases to minimize offsets.  Then I noticed that the post-handoff MICH xfer function needed an increase in gain to look like the pre-handoff xfer function (which has a UGF of about 25 Hz).  I increased the MICH PD9_Q gain from 2 to 7 in the input matrix.   But, the handoff to PRC still failed, so tomorrow we will try to find out why.

In the plot, ref0 is before MICH handoff, and ref1 is after MICH handoff.  There is also a PRC trace (before PRC handooff).

 

 

Attachment 1: mich_dd.pdf
mich_dd.pdf mich_dd.pdf
  1640   Mon Jun 1 19:19:26 2009 ranaUpdatePSL1000 days of hour-trend
Attachment 1: u.png
u.png
  1639   Mon Jun 1 15:01:31 2009 ranaUpdatePSLLaser Power after fixing the laser chiller: more traces
If you look at the correlation between RMTEMP and HTEMP, you see what we knew: namely that there
was a 1:1 correlation before. After the chiller fix, I can see no correlation between the room and
amplifier temperature at the resolution of 10:1. So the chiller loop has a gain > 10 at 24 hour time
scales.

I don't understand why the PMC looks more stable.
Attachment 1: Picture_7.png
Picture_7.png
  1638   Mon Jun 1 14:49:07 2009 robSummaryPSLpsl thoughts

Some thoughts on what happened with the MOPA cooling. 

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

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

 

  1637   Mon Jun 1 14:33:42 2009 robConfigurationComputer Scripts / Programsop540m Monitor added to web status

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

 

Now we can see the StripTool displays that are usually parked on that screen.

 

 

  1636   Mon Jun 1 13:56:52 2009 AlbertoUpdatePSLLaser Power after fixing the laser chiller

The laser power seems to have become more stable after fixing the laser chiller. The power is lower than it used to be (MOPA amplitude 2.5 versus 2.7) but, as shown in the attchement, it became more steady.

Attachment 1: MOPAtrend.jpg
MOPAtrend.jpg
  1635   Mon Jun 1 13:25:00 2009 robUpdateComputersc1susvme2, c1iscex running late

Quote:

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

 

 

The reboot appears to have worked.

Attachment 1: doublesync.jpg
doublesync.jpg
  1634   Sat May 30 12:36:52 2009 robUpdateComputersc1susvme2, c1iscex running late

c1susvme2 has been running just a bit late for about a week.  I rebooted it. 

The plot shows SRM_FE_SYNC, which is the number of times in the last second that c1susvme2 was late for the 16k cycle.   Similarly for ETMX.

 

Attachment 1: srmsync.jpg
srmsync.jpg
Attachment 2: etmxsync.jpg
etmxsync.jpg
  1633   Sat May 30 12:03:34 2009 robUpdatePSLMC locked

I locked to PSL loops, then tweaked the alignment of the MC to get it to lock. 

I first steering MC1 until all the McWFS quads were saturated.  This got the MC locking in a 01 mode.  So I steered MC1 a little more till it was 00.  Then I steered MC2 to increase the power a little bit.  After that, I just enabled the MC autolocker.

ELOG V3.1.3-