I moved the MC1 set of accelerators. Might have bumped things. If things aren't working, look around the MC1 chamber.
Also, I constructed two new XLR cables, but have not tested them yet.
The 40m lab specific safety training is done. The participants were
Stephanie Erickson, Clara Bennett, Chris Zimmerman, Zach Commings, Michelle Stephen surfs and Drew Cappel postock.
They have already went through the Caltech Safety Office laser and general safety training.
They still have to read, understand and sign the the SOP for the laser & lab
tdsresp is broken on our linux control room machines. I made a little perl replacement which uses the DiagTools.pm perl module, called pzresp. It's in the $SCRIPTS/general directory, and so in the path of all the machines. I also edited the cshrc.40m file so that on linux machines tdsresp points to this perl replacement.
I've patched DiagTools.pm to circumnavigate the tdsdmd bug described here. I also added a function to DiagTools.pm called diagRespNoLog, which is just like diagResp but without that pesky log file.
Here's the output from the tdsresp binary on CentOS:
allegra:~>tdsresp 941.54 10000 100 10 C1:LSC-ITMX_EXC C1:LSC-PD1_Q C1:LSC-PD1_I
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
nan nan nan nan nan nan nan
*** glibc detected *** tdsresp: free(): invalid next size (fast): 0x089483e8 ***
======= Backtrace: =========
======= Memory map: ========
00242000-00249000 r-xp 00000000 fd:00 15400987 /lib/librt-2.5.so
00249000-0024a000 r--p 00006000 fd:00 15400987 /lib/librt-2.5.so
0024a000-0024b000 rw-p 00007000 fd:00 15400987 /lib/librt-2.5.so
009f9000-00a13000 r-xp 00000000 fd:00 15400963 /lib/ld-2.5.so
00a13000-00a14000 r--p 00019000 fd:00 15400963 /lib/ld-2.5.so
00a14000-00a15000 rw-p 0001a000 fd:00 15400963 /lib/ld-2.5.so
00a17000-00b55000 r-xp 00000000 fd:00 15400974 /lib/libc-2.5.so
00b55000-00b57000 r--p 0013e000 fd:00 15400974 /lib/libc-2.5.so
00b57000-00b58000 rw-p 00140000 fd:00 15400974 /lib/libc-2.5.so
00b58000-00b5b000 rw-p 00b58000 00:00 0
00b5d000-00b70000 r-xp 00000000 fd:00 15400984 /lib/libpthread-2.5.so
00b70000-00b71000 r--p 00012000 fd:00 15400984 /lib/libpthread-2.5.so
00b71000-00b72000 rw-p 00013000 fd:00 15400984 /lib/libpthread-2.5.so
00b72000-00b74000 rw-p 00b72000 00:00 0
00b76000-00b78000 r-xp 00000000 fd:00 15400981 /lib/libdl-2.5.so
00b78000-00b79000 r--p 00001000 fd:00 15400981 /lib/libdl-2.5.so
00b79000-00b7a000 rw-p 00002000 fd:00 15400981 /lib/libdl-2.5.so
00b7c000-00ba1000 r-xp 00000000 fd:00 15400975 /lib/libm-2.5.so
00ba1000-00ba2000 r--p 00024000 fd:00 15400975 /lib/libm-2.5.so
00ba2000-00ba3000 rw-p 00025000 fd:00 15400975 /lib/libm-2.5.so
00bca000-00bdd000 r-xp 00000000 fd:00 15401011 /lib/libnsl-2.5.so
00bdd000-00bde000 r--p 00012000 fd:00 15401011 /lib/libnsl-2.5.so
00bde000-00bdf000 rw-p 00013000 fd:00 15401011 /lib/libnsl-2.5.so
00bdf000-00be1000 rw-p 00bdf000 00:00 0
00dca000-00dd5000 r-xp 00000000 fd:00 15400986 /lib/libgcc_s-4.1.2-20080825.so.1
00dd5000-00dd6000 rw-p 0000a000 fd:00 15400986 /lib/libgcc_s-4.1.2-20080825.so.1
08048000-080b7000 r-xp 00000000 00:17 6455328 /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080b7000-080ba000 rw-p 0006e000 00:17 6455328 /cvs/cds/caltech/apps/linux/tds/bin/tdsresp
080ba000-080bb000 rw-p 080ba000 00:00 0
0893d000-0896b000 rw-p 0893d000 00:00 0 [heap]
f5e73000-f5e74000 ---p f5e73000 00:00 0
f5e74000-f6874000 rw-p f5e74000 00:00 0
f692d000-f6931000 r-xp 00000000 fd:00 15400995 /lib/libnss_dns-2.5.so
f6931000-f6932000 r--p 00003000 fd:00 15400995 /lib/libnss_dns-2.5.so
f6932000-f6933000 rw-p 00004000 fd:00 15400995 /lib/libnss_dns-2.5.so
f6956000-f6a12000 rw-p f6a31000 00:00 0
f6a74000-f6a7d000 r-xp 00000000 fd:00 15400997 /lib/libnss_files-2.5.so
f6a7d000-f6a7e000 r--p 00008000 fd:00 15400997 /lib/libnss_files-2.5.so
f6a7e000-f6a7f000 rw-p 00009000 fd:00 15400997 /lib/libnss_files-2.5.so
f6a7f000-f6a80000 ---p f6a7f000 00:00 0
f6a80000-f7480000 rw-p f6a80000 00:00 0
f7480000-f7481000 ---p f7480000 00:00 0
f7481000-f7e83000 rw-p f7481000 00:00 0
f7e83000-f7f63000 r-xp 00000000 fd:00 6236924 /usr/lib/libstdc++.so.6.0.8
f7f63000-f7f67000 r--p 000df000 fd:00 6236924 /usr/libAbort
I spent the week reading up on filter algorithm theory, particularly Wiener filtering. I have also learned how to get data from specific channels at specific times, and I've been getting myself acquainted with Matlab (which I have not previously used). Finally, I started messing around with the positioning of the accelerometers and seismometers in order to try to find the setup that yields the best filtration.
This week, I've been reading some literature concerning PLL and familiarizing myself with LINUX, MATLAB, and high-pass filter circuits. In MATLAB, I started constructing matrices to be used for a beam path analysis from the laser output to the ccd camera. I also built a simple high-pass filter on a bread-board that Joe and I are currently testing with the spectrum analyzer.
When I said "MC1/MC2 accelerometers," I meant the entire three-axis accelerometer set at each point.
I have created the attached EOM circuit with resonances at 11 MHz, 29.5 MHz, and 55 MHz (the magnitude and phase of the voltage across the EOM are shown in the attached plot). The gain is roughly the same for each resonant peak. Although I have managed to get the impedances at all of the resonant frequencies to equal each other, I am having more trouble getting the impedances to be 50 Ohms (they are currently all around 0.66 Ohms).
For the current circuit, initial calculations show that we will need around 4.7 - 14.2 A of current to drive the EOM at the desired voltage (8 - 24 V); this is much higher than the current rating of most of the available transformers (250 mA), but the necessary current will change as the impedance of the circuit is corrected, so this is probably not a cause for concern. For example, the necessary driving voltages for the current circuit are (2.8 - 8.5 V); if we assume that the 50-Ohm impedance will be purely resistive, then we get a current range of 56 - 170 mA.
I've spent most of the last week doing background reading; fourier transforms, shm, e&m, and other physics that I didn't cover at school. I also read a few chapters in Saulson, especially the chapter on noise and shot noise. To get a better grip on what I'm going to be doing I read through the polarization chapter in Hobbs' "Optics" text, mostly on wave plates since that's a large part of this readout. Since then I've been working up to calculating the shot noise, starting with the electric field throughout the new interferometer readout.
The Maglev is running for 10 days with V1 closed. The pressure at the RGA-region is at 2e-9 torr on CC4 cold cathode gauge.
Valve VM2 to Rga-only was opened 6 days ago. The foreline pressure is still 2.2e-6 torr with small Varian turbo ~10 l/s on cc2
Daily scans show small improvement in large amu 32 Oxygen and large amu 16, 17 and 18 H20 water peaks.
Argon calibration valve is leaking on our Ar cylinder and it is constant.
The good news is that there are no fragmented hydrocarbons in the spectrum.
The Maglev is soaked with water. It was seating in the 40m for 4 years with viton o-ring seals
However I can not explan the large oxygen peak, either Rai Weiss can not.
The Maglev scans are indicating cleanliness and water. I'm ready to open V1 to the IFO
V1 valve is open to IFO now. V1 interlock will be tested tomorrow.
Valve configuration: VAC NORMAL with CRYO and Maglev are both pumping on the IFO
The IFO RGA scan is normal.
The Cryo needs to be regenerated next. It has been pumping for 36 days since last regenerated.
This has to be done periodically, so the Cryo's 14 K cold head is not insulated by by ice of all things pumped away from the IFO
Both accelerometers have been moved in an attempt to optimize their positions. The MC1 accelerometer was moved from one green bar to the other (I don't know what to call them) at the base of the MC1 and MC3 chambers. That area is pretty tight, as there is an optical table right there, and I did my best to be careful, but if you suspect something has been knocked loose, you might check in that area. The MC2 accelerometer was moved from the horizontal bar down to the metal table on which the MC2 chamber rests.
Sun Jun 21 00:06:43 PDT 2009
Mar 6 15:46:32 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 126.96.36.199
Mar 10 11:11:32 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 188.8.131.52
Mar 11 13:27:37 nodus sshd: [ID 800047 auth.error] error: connect_to 184.108.40.206 port 7000: Connection refused
Mar 11 13:27:37 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:31:40 nodus sshd: [ID 800047 auth.error] error: connect_to 220.127.116.11 port 7000: Connection refused
Mar 11 13:31:40 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:31:45 nodus sshd: [ID 800047 auth.error] error: connect_to 18.104.22.168 port 7000: Connection refused
Mar 11 13:31:45 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 11 13:34:58 nodus sshd: [ID 800047 auth.error] error: connect_to 22.214.171.124 port 7000: Connection refused
Mar 11 13:34:58 nodus sshd: [ID 800047 auth.error] error: connect_to nodus port 7000: failed.
Mar 12 16:09:23 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 126.96.36.199
Mar 14 20:14:42 nodus sshd: [ID 800047 auth.crit] fatal: Timeout before authentication for 188.8.131.52
Mar 25 19:47:19 nodus sudo: [ID 702911 local2.alert] controls : 3 incorrect password attempts ; TTY=pts/2 ; PWD=/cvs/cds ; USER=root ; COMMAND=/usr/bin/rm -rf kamioka/
Mar 25 19:48:46 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/2
Mar 25 19:49:17 nodus last message repeated 2 times
Mar 25 19:51:14 nodus sudo: [ID 702911 local2.alert] controls : 1 incorrect password attempt ; TTY=pts/2 ; PWD=/cvs/cds ; USER=root ; COMMAND=/usr/bin/rm -rf kamioka/
Mar 25 19:51:22 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/2
Jun 8 16:12:17 nodus su: [ID 810491 auth.crit] 'su root' failed for controls on /dev/pts/4
12:06am up 150 day(s), 11:52, 1 user, load average: 0.05, 0.07, 0.07
12:06am up 150 day(s), 11:52, 1 user, load average: 0.05, 0.07, 0.07
Today I found the elog down, so I rebooted it following the instructions in the wiki.
I have the impression that Nodus has been rebooted since last night, hasn't it?
I measured the scatter from the eLIGO beam dumps as best I could. The experiment setup is shown in the attached diagram.
After familiarizing myself with the equipment in the morning I noticed three issues with the setup
1 - around the minimum scatter the back scatter from the beam dump is very susceptible to the incident angle (makes sense since the Si plate inside the beam dump at Brewster's angle when there is minimum scatter).
2 - The mirrored plug (Part 20 in D0900095) which is suppose to be used for alignment is not very effective. It moves around too much in its hole in the front face of the beam dump. Just by touching it I could make the reflected beam jump around by about 0.1 radians.
- I think to align these properly we'll have to partly assemble the dumps. If we leave off the front plate of the horn then we can measure the reflection off the Si. If we measure this with a power meter then alignment becomes a simple matter of rotating until this reflection is minimized.
3. - For this measurement the incident beam was a small (~ 1mm diameter) central beam with a small amount of spray of laser light beyond that central region. This spray was hitting the aluminium front face of the beam dump and was scattering back to the photodiode. This was clearly the limiting factor in the measurement. Most of this light was spread horizontally so I placed a couple of pieces of black glass on either side of the aperture, just blocking the edges a little. This reduce the background reading at the minimum scatter from 17.0uV to around 4.5uV with still a little bit of light hitting the top and bottom of beam dump face.
The incident power on the beam dump fluctuated a little but was in the range 20.5 to 22mW. The response of the PD is approximately 0.2 A/W and the transimpedance is 7.5E4 V/A.
The SR830 Sensitivity was set to 1x1 mV.
It was difficult to measure the actual angle of incidence. The dump pivoted about a point directly under the input aperture at the front. By measuring the displacement of a point on the back of the dump as I rotated it and knowing the distance between this point and the pivot point I was able to make a reasonably accurate measurement of a range of angles about the minimum.
The measured scatter (in V measured directly by the PD and as a fraction of the incident power) is shown in the attached plots.
I think I can do a better job cleaning up the incident beam - so these numbers only represent an upper limit on the scatter.
attachment 1: beam dump assembly
attachment 2: experimental layout
attachment 3: scatter measurement
attachment 4: BRDF - (scatter divided by the solid angle = 1.1 m steradians)
attachment 5: (slightly blurred )photo of dump - overhead view
This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state. It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases. So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature. This measure is imperfect because it doesn't account for the effect of the DARM loop.
Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband. The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.
Here's a noise spectrum of the RSE interferometer, in anti-spring mode, with RF readout. I'd say the calibration is "loose."
I used the Buonanno & Chen modification of the KLMTV IFO transfer functions to model the DARM opto-mechanical response. I just guessed at the quadrature, and normalized the optical gain at the frequency of the calibration line used (927Hz, not visible on the plot).
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.
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.
With the common mode servo bandwidth above 30kHz and the BOOST on (1), I was able to switch on the test mass dewhitening. Finally.
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 \
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 \
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.
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.
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.
Lock is still being lost, right at the end of the process when trying to reduce the CARM offset to zero.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
I just added two slow channels to C0EDCUEPICS to monitor the input of PD11. The names are:
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.
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
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.
We were stymied early in the evening by a surreptitiously placed, verbo-visually obfuscated command in the drstep script.