40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 79 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  433   Mon Apr 21 13:12:21 2008 robUpdateComputer Scripts / Programstdsread bugs

There seems to be a problem with reading the C1:IOO-MASTER_OVERFLOW field
when it is read in as part of an array. The only way for me to describe it
is to just attach the terminal output in this entry...this is mainly for
Matt and Rob

I first noticed that the output of the MC-WFS sensing matrix was different than
the outputs from a year ago, namely that the excitation channel was not being
processed and outputted to the file. This made the output matrix diagonalization
scripts fail.

I noticed that there are several different copies of tdsread.cc sitting around.
Looks like they have been hacked in the last year but I am not sure if this
excitation channel readback is an intentional change; email has been sent to the
authors to find out -- they will probably post some kind of response in the log
to resolve what's up.

My guess is that the problem with the IOO channel is not related, but I'm not sure:
op440m:WFS>set ioo_head = "${ifo}:IOO-"
op440m:WFS>set sus_head = "${ifo}:SUS-"
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${sus_head}MC3_MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0 0 0
op440m:WFS>echo `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"

This is the same bug described in entry 180. I believe it has nothing to do with tdsread, which did not change in the time period before the bug appeared, but perhaps has something to do with other EPICS libraries somewhere (tdsread relies on these epics libraries to do its dirty work). Here is entry 180 for reference:

tdsread has developed a strange new illness, whereby it cannot read EPICS values from two subsystems at once (e.g., getting an LSC and SUS value simultaneously). I thought this might have something to with the fact that both losepics and iscepics are running on the same box,
but the same thing happens with IOO EPICS records, so that's not the culprit.

This is new behaviour, and it's only happening on the solaris machines. I suspect some ENV/cshrc juju has caused it, as the tdsread executable is the same one from April, and I don't think our EPICS infrastructure has changed otherwise. In the near term we can either try running the scripts on linux, or modify the IFO scripts to not do these types of calls.

The solution that's been in effect for the past few months has just been to modify the scripts to not make these kinds of calls.
  435   Tue Apr 22 10:59:24 2008 robUpdateSUSMC1 electronics busted

I spent some time trying to fix the utter programming fiasco which was our MCWFS diagonalization script.

However, it still didn't work. Loops unstable. Using the matrix in the screen snapshot is OK, however.

Finally, I realized from looking at the imaginary part of the output matrix that there was something
wrong with the MC1 drive. The attached JPG shows TFs from pit-drives of the MC mirrors to WFS1.

MC1 & MC3 are supposed to have 28 elliptic low pass filters in hardware for dewhitening. The MC2
hardware is different and so we have given it a software 28 Hz ELP to compensate. But it looks like
MC1 doesn't have the low pass (no phase lag). I tried switching its COIL FM10 filters to make it
switch but no luck.

We'll have to engage the filters to make the McWFS work right and to get the MC noise down. This
needs someone to go check out the hardware I think.

I have turned the gain way down and this has stabilized the MC REFL signal as you can see from the StripTool screen.

This was just because the XYCOM was set to switch the "dewhites" based on FM9 rather than FM10. To check whether the hardware ellipDW filters were engaged, I drove MC1 & MC3 in position (using the MCL bank), and looked at the transfer functions MC2_MCL/MC1_MCL and MC2_MCL/MC3_MCL. This method uses the mode cleaner length servo to enable a relatively clear transfer function measurement of the ellipDW, modulo the loop gain of MCL and the fact that it's really hard to measure an ELP cascaded with a suspension. The hardware and the switching appear to be working fine.

It's now set up such that the hardware is ENGAGED when the coil FM10 filters are OFF, and I deleted all the FM10 filters from the coils of MC1 and MC3. Since we don't switch these filters on and off regularly, I see no need to waste precious SUS processor power on filters that just calculate "1".
  436   Tue Apr 22 16:17:48 2008 robUpdateSUSend station sus front-end bug fix

installed and started new susEtmx.o and susEtmy.o to fix a problem with ETMY optical lever variables.

What Alex means is that the EPICS values for the ETMY optical levers were being clobbered in the RFM. The calculations were being done correctly in the FE, so the DAQ/testpoints were working--it was just the EPICS/RFM communication via c1losepics that was bugged. This was a result of the recent SUS code changes to accept inputs from the ASS for adaptive feedforward.
  437   Tue Apr 22 17:08:04 2008 CarynUpdateIOOno signal for C1:IOO-MC_L
C1:IOO-MC_L signal was at zero for the past few days
  442   Thu Apr 24 14:10:26 2008 robUpdateLockinglocking work
Rob, Johnnie

We made some progress on locking last night (Wed night), namely that we were able to handoff (briefly) the CARM-MCL path the REFL-DC error signal. We tried this because we suspect that the reason the PO-DC is not a good CARM error signal is because at low powers, the dc light level in the recycling cavity is dominated by the +f2 RF sideband. Thus, REFL-DC should work a bit better at low powers, which it did. It wasn't super stable, though, so this will require a bit of work to make the transition reliable & stable. The next things to work on include setting the AO path gain properly and possibly going to higher arm powers before handing off (thus increasing the discriminant).

Another thing we found is that the alignment scripts are not working in an ideal fashion. Running the alignment scripts for the two arms (XARM & YARM) leaves the Michelson badly misaligned, making it impossible to get good DRM alignment. This will have to be fixed.
  445   Thu Apr 24 23:27:48 2008 ranaUpdatePEMacoustic noise in MC_F
I looked at the coherence between the Microphone in the PSL (PEM-AS_MIC) and the MC_F channel.

We want to use a microphone to do Wiener/Adaptive noise cancellation on the MC and so we need to
have a coherence of more than ~0.1 in order for that to have any useful effect.

The attached plot shows the spectrum and coherence with and without the HEPA turned up. As you can
see, the HEPA noise is just barely noticeable in this microphone. Mad

We will need to get something with at least 20 dB more sensitivity.:P
  446   Thu Apr 24 23:50:10 2008 ranaUpdateGeneralSyringes in George the Freezer
There are some packets of syringes in the freezer which are labeled as belonging to an S. Waldman.
Thu Apr 24 23:48:55 2008

Be careful of them, don't give them out to the undergrads, and just generally leave them alone. I
will consult with the proper authorities about it.
  448   Fri Apr 25 13:20:04 2008 AndreyUpdatePEMMicrophone test
In response to Rana's request, I tested the microphone (if it is alive or not) by clapping my hands and speaking aloud nearby.

The microphone is alive, see the attached "Full Data" for 5 minutes from Dataviewer.
Attachment 1: Microphone.png
  450   Fri Apr 25 15:44:21 2008 steveUpdatePSLscattering measurments
In pursuit of a low back scattering, high power beam dump we looked at materials such:
polished copper, polished aluminum, diamond cut aluminum, variety of polished & heat treated stainless steel and shades of black glasses.
Black glass is ideal at low power. Superpolished SS 304 #8 is the only material that measures close to bg
We are still looking for a conductive low back scattering material that would be ideal for a good high power beam trap.

Black glass-shade 12, ss304 superpolished #8 and white paper-B98-24lbs back scattering were compared at 1064 nm

Atm 1: data plot numbers from front panel of SR830 display,
sensitivity: 1x1 mV for bg and ss
1x1 V for wp

Atm 2: drawing of measurement set up
Atm 3: SR830 lock.amp settings
Atm 4: view from steering mirror
Atm 5: view from black glass trap
Atm 6: white paper
Attachment 1: scatmeas20080425.xls
Attachment 2: scattring_set_up_20080425.ppt
Attachment 3: sr830settings.pdf
Attachment 4: viewfmirror.pdf
Attachment 5: viewfbgtrap.pdf
Attachment 6: wpnmount.pdf
  458   Mon Apr 28 23:44:33 2008 AndreyUpdateComputer Scripts / ProgramsWeather.db

I was trying to figure out how to modify the file "Weather.db" so that the atm.pressure would be recalculated from Pa to bar before appearing in the EPICS screen, but so far I did not succeed. I restarted processor "c1pem1" several times. I will continue this tomorrow, and also I will modify the nmaes of the weather channels.
  460   Tue Apr 29 21:30:49 2008 AndreyUpdatePEMIn the process of renaming channels for Weather Station

I startted renaming channels for the weather station, and I will continue this tomorrow, on Wednesday.

I have restarted 'c1pem1' several times and reconfigured "C0DCU1" on the framebuilder MEDM screen.

Framebuilder now does not work.
  462   Thu May 1 08:31:51 2008 steveUpdateSUSearthquake trips etmy & mc1
Earthquake at Lake Isabel magnitude 4.4 at 1am today shakes the 40m
ETMY and MC1 watchdogs tripped.
Sus damping restored.
  465   Mon May 5 15:53:14 2008 steveUpdateVACdrypump replaced & readbacks are out
The small turbo pump of the annulus system is tp3
It's drypump was replaced at 1.4 Torr after 8 months of operation.
The rebuilding cost of this SH100 drypump is getting ridiculously high $1349.
I'll look for a replacement.

Joseph rebooted c1vac2 card on Apr 24 entry#441
This restarted the readbacks of the turbos and ion pumps for a while.
That was nice. The readbacks are not working again

  472   Fri May 9 08:40:24 2008 steveUpdateSUSETMY sus damping restored
ETMY lost damping at 19:10 last night.
There was no seismic event than.
Sus damping was restored this morning.
  473   Fri May 9 10:15:36 2008 josephbUpdateComputersNodus has moved
Steve and myself moved Nodus from under the table in the control room, to just above the Rana computer in the control room rack.
  474   Tue May 13 10:15:52 2008 steveUpdateSUSrestored damping of BS & PRM
I think our janitor was cleaning too heavy handedly.
The BS and PRM sus damping were lost.
They were restored.
  475   Tue May 13 10:38:28 2008 steveUpdateComputersrfm network is down
The RFM network went down yesterday around 5pm
Only c1susvme1 is alive but it's timing is off.
Andrey is bringing the network up.

Andrey wants to make an addition first that our situation is very much similar to that described by Rana in his elog entry # 353 (March 03). All of the rectangular boxes are red, except for SUS1-c1susvme1 and AWG (only these two rectangles are green).
  477   Wed May 14 14:05:40 2008 AndreyUpdateComputersComputer Linux-2, MEDM screen "Watchdogs"

Computer "Linux-2", MEDM screen "C1SUS_Watchdogs.adl": there is no indication for ETMY watchdogs, everything is white. There is information on that screen "C1SUS_Watchdogs.adl" about all other systems (MC, ETMX,...), but something is wrong with indicators for ETMY on that particular control computer.
  487   Mon May 19 11:49:57 2008 steveUpdateSUSetmy oplev laser replaced
The 9 years old Uniphase HeNe was replaced by a new JDSU 1103P
Power output ~3.5 mW, reflected light back on qpd ~140 microW, 12,800 counts
Andrey will get the ~2.5 mm od spot on the qpd smaller by replacing
the f1000 lens
  490   Wed May 21 15:21:33 2008 robUpdateComputer Scripts / Programsautolockers and cron

I added hourly cron jobs to op340m to ensure that

MC autolocker
FSS Slow Servo
PSL watch

are running. I've also edited the wiki procedure to reflect the fact that these no longer need to be restarted by hand.
  496   Sun May 25 19:33:16 2008 ranaUpdateIOOMC Bad after Re-alignment
The MC pointing was off and the transmitted power was down after John and Andrey brought it back after the bootfest.

I tried getting it back on Friday but was unsuccessful. Today, after the Phoenix Landing, I got it back to someplace
reasonable, but it still seems to be far off. I will check with Rob before we recenter and of the QPDs.

I had to move all of the MC SUS and also align the beam using the IOO periscope. The attached PDF shows some trends
over the last 80 days. You can see that the drop in MC TRANS is about the same as the drop in PMC TRANS.
Attachment 1: e.pdf
Attachment 2: pmc.png
  499   Sun May 25 22:33:00 2008 ranaUpdateSUSETMY Oplev Work
I found the ETMY table in disarray and put the panels back on and put the ETMY OL laser back on the quad.

The next thing to do is clean up the table (there's a lot of junk on it) and then put in a lens within
6" of the laser to focus the beam on the quad (no metal diving boards and the lens should be either
uncoated (from our Edmunds collection) or a red lens, not 1064).

Then we have to put the beam cover back on between the viewport and the table.
  502   Wed May 28 14:19:47 2008 steveUpdatePSLkaleidoscope of psl
atm 1: scattering psl table optics from the top of the output periscope f4, 60s @MOPA 3 W
atm 2: scattering psl table optics from the top of the output periscope f4, 20s
atm 3: competing GigE cameras on the north end of psl table
atm 4: yellow "soft" washer to be replaced on psl output periscope
atm 5: ETMY-ISCT in disarray
Attachment 1: pslscat.png
Attachment 2: pslscat2.png
Attachment 3: 2GigEs.png
Attachment 4: perwash.png
Attachment 5: etmydisarray.png
  504   Thu May 29 16:32:09 2008 steveUpdateSUSetmy oplev is back
I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd
Attachment 1: P1020417.png
Attachment 2: P1020420.png
  507   Fri May 30 12:37:45 2008 robUpdateSUSetmy oplev is back

I relayed the optics for ETMY-oplev as shown in pictures below.
The reflected beam goes directly to the qpd

I turned on the servo. UGFs in PIT and YAW are ~3Hz. I had to flip the sign of the YAW.
  515   Tue Jun 3 12:33:36 2008 AndreyUpdateCamerasAndrey, Josephb

Continuing our work with cameras,

1) we removed both cameras from their places on Monday afternoon, and were taking the beam-scans with a special equipment (see elog-entry 511) from Bridge bld.,

2) and on Tuesday morning we putted back the GC-750 camera into the transmitted beam path, camera GC-650 into the reflected beam path. We plan to compare the images from the "reflection camera" for several different angles of tilt of the camera.
  516   Wed Jun 4 10:18:52 2008 steveUpdatePSLwedged SS beam trap
I moved the SS trap over to the psl table.
Texas super # 8 was used from the large shipment.
TXs#8 scattering measured as before, meaning the polishing is good.

Go's squeezing power pick up 350 mW was used.
I made two ~30 degrees wedge traps using 6" x 4" and 12" x 4" SS 0.039" thick
with copper backing of similar size.

There was too much scattering and I could not minimize them all.
It is very helpful to have so much space on the psl table.
It shows more of the weakness of this kind of trap.
I did not dare to turn up the power.
Attachment 1: trap1.png
Attachment 2: trap2.png
  524   Fri Jun 6 16:10:51 2008 steveUpdatePSLHEPA filters are running at 100%
The psl HEPA filters were turned up to run at 100% to accommodate beam trap work on Tuesday, June 3, 2008
  528   Tue Jun 10 08:37:18 2008 steveUpdatePSLbeam trap is being tested
High power beam trap is being tested just west of FSS area on psl enclosure.

When the pmc is operating at low power that means that the rest of the 3W is going into the
circular SS trap.

Please beware of the high power beam trap test
Attachment 1: trapss3w.png
  529   Wed Jun 11 11:45:25 2008 steveUpdatePSLss trap works
The trap works well at 3 W level. No back reflected beam coming out of the trap on low power
sensing card level. The back scattering was not measured. The trap is insensitive to small pointing variations.
The SS surface did not show any visible degradation after 16 hrs of 3w exposure at elliptical beam size 4x8 mm

It is ready to be placed into the 35 W beam.
Attachment 1: P1020534.png
Attachment 2: P1020533.png
  531   Thu Jun 12 01:51:23 2008 robUpdateLockingreport
rob, john

We've been working (nights) on getting the IFO locked this week. There's been fairly steady incremental progress each night, and tonight we managed to control CARM(MCL) using PO-DC, with the CARM(AO) path also on PO-DC. In the past, reaching this state has usually meant we're home free, as we could just crank the gain on the common mode servo and merrily reduce the CARM offset. Tonight, however, this state has been very twitchy, and efforts to ramp up the gain have been unsuccessful.

I've attached a diagram which I hope makes clear where we are in the stages of lock acquisition.
Attachment 1: lock_control_sequence.png
  532   Thu Jun 12 15:09:33 2008 alanUpdateLockingreport
Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?
  533   Thu Jun 12 15:55:15 2008 robUpdateLockingreport

Rob: Awesome figure. As you can imagine, I have lots of questions, and hope that you will consider this figure to be the beginning, leading to ever-more detailed versions. But for now, I just want to ask whether you understand *what* is twitchy, and what the twitchiness does to prevent you from taking this further?

I definitely don't understand what's twitchy, but I have suspicions. Tonight we'll try to start by revisiting the other loops (the non-CARM loops) and see how they're dealing with the changing power levels. It may be that the DARM loop is going unstable due to gain variations (due to either increasing power or to rotation of demod phase) or it could be the PODD (or SPOB) saturating with increased power in the recycling cavity. I just hope the glitchiness doesn't have a digital origin.
  534   Fri Jun 13 11:17:25 2008 YoichiUpdatePSLPMC transmittance at high power
We received a new cable for the Scientech calorimeter. So I measured the transmittance of the PMC at higher power.

Input power = 2.298W
Output power = 1.364W
Transmittance = 59%

The input power to the PMC was measured between the two mode matching lenses by the calorimeter.
2.298W looks a bit too low. Actually, the calibrated monitor PD on the MEDM screen shows about 3W output from MOPA.
So we (me and Steve) measured the power right after the PBS after the periscope from MOPA with the HWP set to maximize the transmission of the PBS.
It was 2.77W. According to Steve's previous measurement, the first mirror of the periscope transmits about 200mW of the incoming light to the monitor PD. So the actual output of the MOPA is about 2.97W, which is consistent with the monitor PD reading.
The aperture of the EOM for the PMC control is glowing a lot. We suspect this is the main cause of the loss (from 2.77W to 2.298W).
We may want to re-align the EOM.

The output light from the PMC was picked off by a glass slide. The reflectance of the glass slide was measured first at a lower power (input 98mW, reflected power 1.58mW). Assuming that the reflectance is the same for the higher power, I turned up the input power to the PMC. This time, the picked off power was 22.45mW. This means the actual output power is 98/1.58*22.45=1364mW. The glass slide was kept at the same angle through out the measurement.
The measurement of the output power was done by the Ophir power meter. So calibration difference between the Ophir and the calorimeter may introduce some error.
  535   Mon Jun 16 18:26:01 2008 Max JonesUpdateComputer Scripts / ProgramsNoise Budget Changes
In the directory cvs/cds/caltech/NB the following changes were made:

I created temporary files in ReferenceData for the C1 by copying and renaming the corresponding H1 files.
- C1_SRD_Disp.txt
- C1IFOparams.m
- C1_NoiseParams.m

In getmultichan.m I added a C1 case.

In NoiseBudget.m I added a C1 case with modified sources array to include only DARM and Seismic

I appreciate and suggestions. Max.

  537   Wed Jun 18 00:19:29 2008 robUpdatePSLMOPA trend
15 day trend of MOPA channels. The NPRO temperature fluctations are real, and causing the PMC to consistently run up against its rails. The cause of the temperature fluctations is unknown. This, combined with the MZ glitches and Miller kicking off DC power supplies is making locking rather tetchy tonight. Hopefully Yoichi will find the problem with the laser and fix it by tomorrow night.
Attachment 1: MOPAtrend.png
  539   Wed Jun 18 16:37:54 2008 steve,ranaUpdateSAFETYCO2 test in the east arm
The CO2 laser and table are in the east arm for characterization of the mechanics. We
will not be operating it until we have an SOP (which is being written). No worries.
Attachment 1: co2.png
  540   Wed Jun 18 18:20:10 2008 YoichiUpdatePSLInvestigation on the NPRO temperature stabilization glitches
As Rob pointed out in http://dziban.ligo.caltech.edu:40/40m/537 the MOPA NPRO has been showing some glitchiness in the LTEC loop.
Following Rana's suggestion, Steve and I opened the MOPA and directed a heat gun for a minute to the NPRO hoping that we can see something in the LTEC loop.
The first attachment shows the behavior of LTMP and LTECH along with DTMP and DTECH at the time of the heat gun attack.
T=0 is the time when Steve directed the heat gun to the NPRO. There is no response neither in LTMP nor LTECH.
DTMP and DTECH look like responding.
Around the center, there is a dip in LTMP. This might be caused by removing the heat gun. But we are not sure. This kind of small glitches can be found in LTMP everywhere (see the attachment 2).
It looks like the LTMP sensor is not working, or the LTECH loop is actually working but the LTECH reading is broken.
However, the scan of the slow actuator (temperature) shows the LTECH loop is actually working. So it is a bit confusing.
More investigation is necessary.
See the next entry by me.
Attachment 1: LTEC-loop-HeatGun-Response.pdf
Attachment 2: LTMP-glitches.pdf
  541   Wed Jun 18 18:26:19 2008 YoichiUpdatePSLFinding the optimal operation temperature for the NPRO by the slow act scan
Being suspicious of the temperature stabilization of the NPRO crystal, I ran the slow scan script written by Rana to find the suitable operation temperature.
The procedure is the same as the one explained in the entry below:
The attached plots show the results. By looking at C1:PSL-126MOPA_126MON, I set the slow slider voltage to 0.
This time, it looks like the temperature control of the NPRO crystal is working fine.
Obviously, PMC picks up many higher order modes. I will try to mode match/align the PMC later.
Attachment 1: FSS-slow-scan.pdf
  542   Wed Jun 18 18:32:09 2008 Max JonesUpdateComputer Scripts / ProgramsNB Update
I am reconfiguring the the noisebudget code currently in use at the sights. To that end, I have done the following things (in addition to the elog I posted earlier)

In get_dtt_dataset.m - I added C1 specific cases for DARM_CTRL, SEIS, and ITMTRX changing the specific channels to make those in use at caltech

In LocalizeSite.m - I changed the NDS_PATH to match caltechs. I left NDS_HOST untouched.

Since I am trying to get SEIS and DARM to work initially I added C1 specific cases to both of these.

Better documentation may be found in /users/mjones/DailyProgressReport/06_18_08. Suggestions are appreciated. Max.
  544   Wed Jun 18 18:50:09 2008 ranaUpdateComputersIt can only be attributable to human error. (HAL - 2001)
There has been another one of "those" events and all of the front end machines are down.

We poked around and Rob determined that the FEs can't get the EPICS data from EPICS. The
dcuepics machine is hooked up and running and all of the epics binaries are running. We also
tried resetting its RFM switch as well as power cycling the box using the "poweroff" command.

Not a sausage.

Rob points out that although the Signal Detect lights are on on the cards, the 'Own Data' light
is not on on the dcuepics' card although it is on for some of the cards on the other boxes.

We have placed messages with the Russian. If anyone sees him, don't let him go without fixing things.
Also, make sure to follow him around with notepad and possibly a camera to record what it is that
he does. If he's muttering, maybe try to use a sensitive hidden sound recorder.
  546   Thu Jun 19 20:22:03 2008 ranaUpdateGeneralFE Computer Status
I called Rolf (@LLO) who called Alex (@MIT) who suggested that we power cycle every crate
with an RFM connection as we did before (twice in the past year).

Rob and I followed Yoichi around the lab as he turned off and on everything. There
was no special order; he started at the Y-end and worked his way into the corner and
finishing at the X-End. Along the way we also reset the 2 RFM switches around fb0.

This cured the EPICS problem; the FEs could now boot and received the EPICS data.

However, there are still some residual channel hopping-ish issues which Rob and Yoichi are
now working on.
  547   Fri Jun 20 01:38:55 2008 ranaUpdatePEM20 day Weather
Yoichi showed me that its possible to make PNG images from PS using GS:
gs -sDEVICE=png16m -sOutputFile=foo.png bar.ps
Attachment 1: test.png
  548   Fri Jun 20 02:20:33 2008 YoichiUpdate PMC transmittance degradation
The PMC transmitted light power has been degrading constantly for last two weeks (see the attachment 1).
I went down to 2.55V.
The output of the MOPA is constant during this period. More strangely, the reflected power from the PMC is also constant.
One possible explanation is the contamination of the PMC mirrors. But I don't know why it started two weeks ago.

I tweaked the alignment of PMC and was able to recover the transmitted power to above 2.7V (attachment 2).
I will keep eye on this issue.
Attachment 1: pmc_trans_long_trend.pdf
Attachment 2: pmc_trans_improvement.pdf
  549   Fri Jun 20 08:30:27 2008 stivUpdatePhotos40m summer line up 2008
atm1: John, Alberto, Yoichi, Koji, Masha, and Sharon

atm2: surf students Max of CIT, Sharon of MIT, Masha of Harvard, Eric of CIT not shown
Attachment 1: P1020559.png
Attachment 2: P1020560.png
  550   Fri Jun 20 17:42:48 2008 steveUpdatePSLSS trap scattering compared to black glass trap
Circular SS304 trap was compared to wedged black glass trap.

The measurement set up of entry 529 was changed to define polarization.
CrystaLaser was remounted in horizontal position and half wave plate was placed after it.
These measurements were done in horizontal polarization.

atm1: the cSSt and wBGt was moved horizontally, ~90 degrees of the incident beam
atm2: traps were rotated around the incident beam, ~20 degrees each direction
atm3: set up
atm4: top view of traps
atm5: side view of trap
Attachment 1: cSSt_1.png
Attachment 2: cSSt_2.png
Attachment 3: scatset_61908.png
Attachment 4: cSSt&wBGt.png
Attachment 5: cSStbeam.png
  553   Mon Jun 23 19:33:01 2008 rana, jenneUpdateIOOMC_F Noise check
We looked at the MC_F spectrum because Rob and Yoichi said that it had gone 'all crazy'. It
seemed fine as we looked at it (even with only one boost stage on) so we looked for things
that might be marginal and make it go nuts.

At the error point (Q mon on the demod board and TEST IN1) of the MC Servo board we saw the
old 3.7 MHz signal (comes from the 33 MHz RFAM getting demodulated by the 29.5 MHz MC LO)
and thought that this might cause some worries. So we installed Jenne's passive elliptic
low pass which has a 3.7 MHz zero.

This wiped out the 3.7 MHz noise but we were not able to re-create the extra frequency noise
so its unlikely to have fixed the main problem. However, we leave it in because its good. If
there is a need to revert it, we have left hanging on the side of the rack the old cable which
was a SMA->TNC making a direct, unfiltered connection between the MC Demod board and the MC
servo board.

More before and after results from Jenne tomorrow, but for now here is a calibrated MC_F spectrum
using the new MC_F-Reference.xml template file.

We also noticed that we could make some small effects on the MCF spec by adjusting the PMC gain so
there's probably more hay to be made there using a lead brick and a gain slider. More in Jenne's
Attachment 1: mcf.png
  555   Mon Jun 23 21:51:19 2008 AlbertoUpdateGeneralArm Cavity Length Measurement
We measured the arm cavity lengths sweeping the ETM mirror position and looking at the reflected demodulated output. We excited the mirror by a sine wave of 0.2 Hz and amplitude of 30000 counts. From the time series of the occurrences of the resonances of the sidebands and of the carrier we evaluated the free spectral range of the cavities and thus the lengths. The details of the procedure are explained in the attached document. As discussed in it, for each cavity we obtain two possible values of the length depending on which of the sideband resonances is that corresponding to the upper sideband and which corresponds to the lower one instead. The numbers are:
Lx=(38.30 +/- 0.08)m / (38.45 +/- 0.08)m
Ly=(38.16 +/- 0.08)m / (38.70 +/- 0.08)m

Since the difference between the two possibilities is quite large, we should be able to decide which one is correct by somehow measuring directly the cavity length. We want to try it tomorrow by a tape meter.

Alberto and Koji
Attachment 1: 40mLengthMeasure.pdf
40mLengthMeasure.pdf 40mLengthMeasure.pdf
  556   Tue Jun 24 10:24:43 2008 KojiUpdateGeneralAbs. Len. Meas. ~ Cavity Swing Measurement (2)
At the entry 555, Alberto reported the results of the cavity length measurement using cavity sweeping.
As expected, each result inevitably has an ambiguity depending on which resonance do we take as an upper sideband.

In order to exclude this ambiguity Steve and Koji performed a primitive non-optical measurement using a tape and photos:
This morning Steve and Koji did tape measurements to know the lengths between the ITM/ETM chambers.
Yesterday, Koji took photos of the optical tables in vacuum to know the actual positions of the suspensions.

The results are shown in the figures attached. From those non-optical measurements the lengths of the X/Y arm are known to be 38.48+-0.03 / 38.67+-/0.03 [m].

Then, we could exclude the shorter lengths of the values in the entry 555. i.e. The Y arm is longer than the X arm about 0.2 m.

These approximate lengths will be used in the further precise measurements which use precise scans of the FSR frequencies.
Attachment 1: armlength.png
Attachment 2: armlength2.png
  559   Tue Jun 24 22:31:10 2008 MashaUpdateAuxiliary lockingmy first step in fiber stabilization
There is a new 1W INNOLIGHT NPRO laser at the Symmetric Port.

Set up an interferometer to measure difference in phase noise introduced by a fiber. Works as expected without the fiber! (balanced intensity, out of phase noise in the two outputs).
ELOG V3.1.3-