ELOG 40m

Summary of DC readout PD non-linearity measurements

LSC

From March 21-26, I conducted some measurements of the response non-linearity of some mock-up DC readout photodetectors. The detectors are simple:

Vbias ---
        |
       PD
        |-------- output
     resistor
        |
       ---
        -

This is a description of the final measurement.

The laser current modulation input was given a 47Hz sine wave at 20mV. A constant small fraction of the beam was shown onto the reference detector, and a beam that was varied in DC power level was incident on the test detector. Spectra were taken from both detectors at the same time, 0.25Hz bandwidth, over 100 averages.

At each incident power level on the test detector, the Vpk in all multiples of the modulation frequency were measured (ie. V[i*w]). The difference between the 2f/1f ratio in the test and reference was then calculated, ie:

V_test[2*w]/V_test[1*w] - V_ref[2*w]/V_ref[1*w]

This is the solid black line in the plot ("t21-r21_v_power.png").

The response of a simulated non-linear detector was also calculated based on the Vpk measured at each harmonic in the reference detector, assuming that the reference detector had a purely linear response, ie:

V_nl[beta,2*w]/V_nl[beta,1*w] - V_l[2*w]/V_l[1*w]

these are the dashed colored lines in the plot ("t21-r21_v_power.png").

The result of the measurement seems to indicate that the non-linearity in the test detector is less than beta=-1.

The setup that was on the big optics table south of the laser, adjacent to the mode cleaner, is no longer needed.

Attachment 1: t21-r21_v_power.png

408

Mon Mar 31 14:14:16 2008

Quote:

c1susvme2 is getting worse and worse. it won't run for more than ~45 minutes without fatally de-syncing. for now I've turned off c1iovme (which sends the MCL signal) to see if that's causing the problem. next I'll swap the boards for c1susvme1 and c1susvme2 to see if it's the cpu (or maybe the RFM card) itself, rather than the timing/pentek systems.

I swapped the processors for c1susvme1 and c1susvme2. So for now, to startup, you should ssh into c1susvme1 and run the startup.cmd for c1susvme2, and vice versa.

409

Wed Apr 2 15:03:51 2008

reflectivity of black glass

General

The reflectivity of black glass, shade 12 was supplied by Donald O'Shea
of Emerald Glass Inc., Westlake, OH 44145

The reflectivity of this glass was measured as shown

Old 1064 nm Crysta Laser with poor beam quality was the source.

Attachment 1: bg12refl.pdf

Attachment 2: bg12refsetup.pdf

410

Thu Apr 3 18:33:17 2008

Status of Weather Station

Environment

During the last two days some things related to weather station have been improved.

1) Startup file for the computer (processor) 'c1pem1' was changed so that now 'c1pem1' can be rebooted from "Linux1". Computer 'c1pem1' is responsible for communicating data between 'Weather Monitor' and control UNIX machines. Before April 1st it was impossible to reboot the computer 'c1pem1'. Now 'c1pem1' runs without difficulties.

2) It was determined that some ethernet cables of category "cat 5" were bad. I replaced one short cat 5 cable between 'c1pem1' and 'network-switch board' in the neighboring computer rack, and I still need to replace the internet ending of another long (~20 meters) cat 5 cable after Alex Ivanov will bring the tool for that.

3) 'Weather monitor' and 'WeatherLink' are temporarily moved away from their "nested" positions on the north wall, and they are now in the proximity of processor 'c1pem1'. Thus the signal about "Inside Temperature" goes into 'c1pem1' computer without any additional ethernet cables, and "inside temperature" is correctly displayed on the "Checklist" adl. MEDM screen on the control UNIX machines. The cable with a signal from the roof sensors (which might be dead due their 7-year age) is temporarily disconnected from the 'Weather Monitor'.

Result: 'Weather Monitor' and computer (processsor) 'c1pem1' are alive, they communicate reasonable "Inside Temperature" to the control UNIX-machines.

The fate of the outside sensors is currently unknown, I plan to go to the roof together with Mr. Steve Vass tomorrow and try to determine what should be done with them.

I am also writing (right now) a wiki-40 page which explains what is the "Weather Station" and what is its status.

412

Thu Apr 3 18:46:04 2008

"Network switch board" and "c1pem1 crate" were touched

While working with the weather station, I did two things that potentially (with a very small probability) might influence the smooth work of other processors/computers.
I did the following on Wednesday, April 2nd, in times between 1PM and 3PM.

(1) I turned off for several seconds and returned into the initial position the switch-key on the rack with computer (processor) 'c1pem1' in order to reboot processor 'c1pem1'. The turning off/on of that key-switch was repeated several times.

(2) I pulled gently the whole "Network-Switch Board" towards me in order to replace an ethernet cat 5 cable going into the board form the processor 'c1pem1'. Some other connections of other ethernet cables might be flimsy, and then other people in 40-meter might have problems with computers other than 'c1pem1'. It should not happen, but in case of extraordinary behaviour of any other computer in our lab, people should check the connectors on the network-switch board. It is located near the middle of Y-arm. See picture.

Attachment 1: Computer_Rack.JPG

413

Thu Apr 3 19:27:50 2008

Tour for prospective grad students

Photos

Last Friday (March 28), there was a tour of 40-meter lab for prospective graduate students.

Rana showed to the prospective students the interferometer. See pdf-attachment with pictures (two pictures of Rana with undergraduates (I took them) and two old pictures which I discovered on the memory card of Nikon d-40, it was not me who took those two last pictures).

Attachment 1: Rana_Lecturing.pdf

414

Fri Apr 4 16:54:06 2008

Weather station is fully alive

Environment

After today's trip to the roof of our building the weather station seems to be completely resurrected!

We went to the roof together with Steve Vass, and we discovered that:

(1) Sensors of wind speed, wind direction and the bowl that measures the amount of precipitation do not have any visible defects, so there is no problem with all those sensors even after being outside for seven years.

(2) We discovered that there are cable junctions located on the roof, and those junctions were located close to the rim (edge) of the roof, before the cables go inside of 40-meter lab room. The taping in the place of the junction was not good due to the age, and the connections between the cables were disrupted (cable endings were out of the connectors). Therefore, no signal from the roof sensors could be transferred to the 'Weather Monitor'. It was not wise from the person who installed the weather station to leave the fragile cable connections outside, on the roof, because the length of the cables allowed to locate those three connectors inside of the building.

See the attached PDF-file with pictures.

(3) After the cables were plugged into the connectors, these cable junctions were gently pulled into the inside of the 40-meter interferometer room. These cable junctions should not be located outside of the building!

Immediately after all the above-mentioned steps, the reasonable indications of outside temperature, humidity, pressure, wind speed and direction appeared on the 'Weather Monitor'.

In order to see if there is any problem of communication between the 'Weather Monitor' and UNIX control computers through 'c1pem1', I rolled out two brand new black cat-5 ethernet cables on the floor of the interferometer room (they are on the floor temporarily, the ethernet cable will go from the floor into the ceiling cable tray eventually), connected the two cables together through freshly purchased from Caltech bookstore cable connectors, and thus connected the 'Weather Monitor' to the processor 'c1pem1'.

Result: Now we can see reasonable indications of outside temperature, pressure, amount of precipitation, wind speed and direction on the EPICS screen! Moreover, these indications are changing with time.

As a reminder for everyone: standard atmospheric pressure is about 101kPa, so the indications of pressure as 99900Pa is quite reasonable.

One thing is not clear for me yet: wind speed on the 'Weather Monitor' is fluctuating between 2 and 4 mph, while MEDM EPICS-screen values are fluctuation in the range between 0 and 3mph.

Many thanks to Steve Vass and Alexander Ivanov for their help.

Attachment 1: Work_on_the_Roof.pdf

416

Mon Apr 7 16:42:56 2008

Phil Ehrens restarted Dziban again this morning. Looks like its still crashing each Monday around 8 AM.

Here is the latest suspect:

http://open.itworld.com/5040/reboot-unix-nlsunix-071225/page_1.html

417

Mon Apr 7 18:58:49 2008

General

reflectivity of SS304

The reflectivity of stainless steel 304 super polished # 8 was measured the same way as elog entry 409

The reflectivity: 74 +- 1 % from incident angle 10 to 80 degrees

Attachment 1: ss304s8refl.pdf

418

Tue Apr 8 09:08:54 2008

weather station disconnected

We can not leave cables in the walkways and go on vacation.
I disconnected the weather station from the DAQ
Every Tuesday is janitor day in the 40m.
We have to give him free space for doing a good job.

Burned toast award goes to Andrey.

Attachment 1: toast.jpg

419

Tue Apr 15 18:44:25 2008

There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that's going to cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.

420

Wed Apr 16 09:47:35 2008

The weather station is functional again.

The long ethernet Cat5 cable connecting 'WeatherLink' and processor 'c1pem1' was repaired yesterday, namely the RJ45 connector was replaced,
and information about weather conditions is now again continuously being transferred from the 'Weather Monitor' to the control UNIX computers. We can see this information in 'c0Checklist.adl' screen and in Dataviewer.

Below are the two sets of trends for the temperature, wind speed and direction, pressure and the amount of precipitation.

The upper set of trends ("Attachment 1") is "Full Data" in Dataviewer for the 3 hours from 6.30AM till 9.30AM this morning,
and the lower set of trends ("Attachment 2") is "Minute Trend" in Dataviewer for 15 hours from 6.30PM yesterday till 9.30AM this morning.

I also updated the wiki-40 page describing the Weather Station and added to there a description of the process of attaching the RJ45 connector to the end of ethernet Cat5 cable. To access the wiki-40 page about the "weather station" you should go from the main page to "PEM" section and click on "Weather Station".

Attachment 1: Weather-FullData_3hrs.png

Attachment 2: Weather_Trend_15hrs.png

421

Wed Apr 16 10:20:01 2008

Quote:

There is a new computer in the control room -- its called Rosalba,
in keeping with our naming convention. Its a quad-core machine that
Dmass found for cheap somewhere; we've installed the CentOS on it
that Alex recommended.

Its a 64-bit Linux and so that may cause some problems. Alex has done this
before and so we have some confidence that we can get our regular tools (DTT, Dataviewer)
to run on it.

I have made a new apps tree for all of our future 64-bit Linux machines. So far, there is
a 64-bit firefox and a 64-bit matlab in there. As we start using this machine some more, we
will be forced to install more 64-bit Linux stuff.

We also didn't have enough network cables to run to both linux3 and rosalba. Andrey has decided that we
should not ditch linux3 and so he will run another cable for it tomorrow.

The ethernet cable for linux3 was installed on Wednesday morning. Now linux3 has Internet connection again.

422

Wed Apr 16 21:11:12 2008

AA/AI Filters for the DAQ & FE systems

DAQ

I used Foton to make up some new filters which will be used all over the project in order to downsample/upsample.

There will be 2 flavors:

The first one will be a downsampling filter for use in the DAQ system.
Whenever you specify a sampling rate in the .ini files below the natural rate of the ADC,
the data will be downsampled using this filter (called ULYAW_0 in the plot). This one was
designed for flat bandpass and a 'good' bandstop but no care given to the phase shift.
The second one will be used in the FE systems to downsample the ADC signal which is often
sampled at 64 kHz down to something manageable like 2k or 16k. This one was tweaked for
getting less phase lag in the 'control' band (usually 3x or so below Nyquist).

Here is the associated filter file:
# SAMPLING ULYAW 16384
# DESIGN   ULYAW 0 zpk([0.512+i*1024;0.512-i*1024;2.048+i*2048;2.048-i*2048], \
#                      [515.838+i*403.653;515.838-i*403.653;318.182+i*623.506;318.182-i*623.506;59.2857+i*827.88; \
#                      59.2857-i*827.88],0.988553,"n")
# DESIGN   ULYAW 1 zpk([0.512513+i*1024;0.512513-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [200+i*346.41;200-i*346.41;45+i*718.592;45-i*718.592],1,"n")
# DESIGN   ULYAW 2 zpk([0.768769+i*1024;0.768769-i*1024;1.53754+i*2048;1.53754-i*2048], \
#                      [194.913-i*331.349;194.913+i*331.349;53.1611+i*682.119;53.1611-i*682.119],1,"n")
###                                                                          ###
ULYAW    0 21 3      0      0 DAQAA         0.00091455950698073    -1.62010355523604     0.67259370084279    -1.84740554170818     0.99961738977942
                                                                   -1.72089534598832     0.78482029284220    -1.41321371411946     0.99858678588255
                                                                   -1.85800352005967     0.95626992044093     2.00000000000000     1.00000000000000
ULYAW    1 21 2      0      0 FEAA            0.018236566955641    -1.83622978049494     0.85804776530302    -1.84740518752455     0.99961700649533
                                                                   -1.89200532023258     0.96649324616546    -1.41346289594856     0.99893883979950
ULYAW    2 21 2      0      0 ELP             0.015203943102927    -1.84117829296043     0.86136943504058    -1.84722827171918     0.99942556512240
                                                                   -1.89339022414279     0.96048849609619    -1.41346289594856     0.99893883979950

Attachment 1: DAQ_filters_080416.pdf

423

Thu Apr 17 15:00:59 2008

vac controller computer to be replaced

VAC

Now that Rosalba is up and running someone should step forward to volunteer for this job.

Old desk top at the Vacuum Rack should be replaced by a functional less old computer so
the vacuum controller can count on an emergency situation. It's only has to be able to run medm
The existing one is dying.

424

Thu Apr 17 20:17:37 2008

Two issues with our weather station

I encountered two difficulties working with the "Weather Station".

(1) It turns out that there is no indication for "outside humidity" on the "weather monitor" (a small black box located on the north wall of the interferometer). I realized that "outside humidity" is absent in our system when I tried to see the Dataviewer trend and real-time value from the channel "C1: PEM-weather-outsideHumid". It shows impossible number 128%.

It follows from the "Davis" technical documentation that the outside sensor can be of two types: either "External Temperature Sensor" or "External Temperature/Humidity Sensor". I suspect (I do not know for sure) that we have the first type of sensor "external temperature only" and therefore we in principle cannot have information about outside humidity. I propose to Steve to climb to the roof on Friday to resolve this uncertainty looking at the sensor.

(2) I wanted to change the units of pressure from "Pascal" (force/area) to other units, "mbar" for example. For this purpose I need to edit the file "Weather.st" in the directory /cvs/cds/caltech/target/c1pem1 (this file is run on the VME processor "c1pem1"). Unfortunately, when I try to open the file with emacs, I get the message that the file exists but protected from modifications. I do not know how to unblock the file "Weather.st". I need some help with that.

I thought that switching-off the processor "c1pem1" could resolve the issue, so I switched-off the whole crate where the processor "c1pem1" is installed for about 5 minutes, turning the metallic key. As it did not make any difference for the accessibility of the file "Weather.st", I switched-on the crate after 5 minutes. There are other processors besides "c1pem1", so they were turned-off for several minutes earlier today.

Also, I created a new MEDM screen which has information about weather only, a smaller version of the "C0Checklist.adl" MEDM screen. Both screens are now located under the most top-left button "Checklist" of the main MEDM screen.

425

Fri Apr 18 16:02:58 2008

alex

end station sus front-end bug fix

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

426

Fri Apr 18 16:27:04 2008

end station sus front-end bug fix

Quote:

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

But where is the code?

427

Fri Apr 18 16:48:13 2008

Rain collector of weather station

Today the rain collector of our weather station was cleaned. As a result, we checked that the rain indication on the weather monitor and on the MEDM screens is alive and working properly. I am adding some details about the roof sensors to the wiki-40 page about the weather station. See especially the link "More description of the roof sensors and their interaction with UNIX computers" from the main Weather Station page in wiki-40.

Pictures of the rain collector before (dirty, the opening is fully clogged with dust and dirt) and after (clean opening in the bottom of the bowl) the cleaning are attached.

Attachment 1: DSC_0520--before.JPG

Attachment 2: DSC_0537--after.JPG

428

Fri Apr 18 19:46:08 2008

I restarted the adaptive code today using 'startass' and 'upass'.
I moved them into the scripts/ASS/ subdirectory.

Things seem OK. With a MU=0.03 and a TAU=0.00001, there is a still
a good factor of 10 reduction of the 3 Hz stack peak from the MC2
drive by doing FF into MC1.

I edited the ASS-TOP screen so that we could see such small numbers. I
also re-aligned the MC SUS to match the input beam (mainly MC3). The
cavity was locking on a TEM10 mode mostly -- we should look in the SUS
OSEM trends to see if MC3 has moved a lot in the last month or so.

Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.

A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.

Duh.

The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab.

Attachment 1: 0052_xray_thm45.jpg

429

Sun Apr 20 18:23:27 2008

I noticed that the adaptive FF for the MC had stopped doing anything; this turned out
to be that the MC lost lock and the mcdown script turned off the FF path to MC1.

Although there's no elog, it looks like there was ~60 attempts at locking the IFO
between 12:38 and 4:27 on Saturday afternoon. I'm attaching here a plot showing
lock attempt durations and a histogram of lock times.

Attachment 1: quix.png

430

Sun Apr 20 20:29:46 2008

tdsread 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
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
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`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>

431

Sun Apr 20 23:39:57 2008

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

Attachment 1: mcwfs.jpg

432

Mon Apr 21 12:58:42 2008

Quote:

Caryn Palatchi (a Caltech undergrad who just started working with us)
illustrated to me today that using even 1000 FIR taps is not very effective
for low frequency noise cancellation if you have a 2048 Hz sample rate. More
precisely, the asymptotic Wiener filter which our 'LMS' algorithm converges
to, can often amplify the noise at frequencies below f_sample/N_taps.

A less obvious thing that she also noticed is that there is almost no cancellation
of the 16.25 Hz bounce mode when using such a short filter. That's because that
mode is fairly high Q: the transfer function from the Z-ACC to the cavity signal
goes through the high-Q vertical suspension resonance; the FF signal we send back
goes through the low-Q horizontal pendulum response only. Therefore the filter
needs to be able to simulate ~100 cycles at 16.25 Hz in order to cancel that peak.

Duh.

The message here is: we need to find a computationally efficient way to do FIR filtering
or its not going to ever be cool enough to help us find the Crab.

This is the reason for "RDNSAMP" parameter in the ASS code. The FIR filtration is applied at the downsampled rate, not the machine rate. So, if RDNSAMP=32, the effective sampling rate of the FIR filter is 64Hz, and thus noise cancellation should be good down to 64Hz/1000, or 64mHz, and the filter has an impulse response time that extends to 15 secs. I'm not convinced the filter length is what's limiting the performance at the bounce mode, but I agree that a faster FIR implementation would be good.

433

Mon Apr 21 13:12:21 2008

tdsread bugs

Quote:

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
_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW ${ioo_head}MAS
TER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>set oflows = `tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
op440m:WFS>echo $oflows
0
op440m:WFS>set oflows = `tdsread ${ioo_head}MASTER_OVERFLOW`
op440m:WFS>echo $oflows
0
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`
ERROR: C1:IOO-MASTER_OVERFLOW value not read
0
op440m:WFS>echo "tdsread ${sus_head}MC1_MASTER_OVERFLOW ${ioo_head}MASTER_OVERFLOW ${sus_head}MC2_MASTER_OVERFLOW"
tdsread C1:SUS-MC1_MASTER_OVERFLOW C1:IOO-MASTER_OVERFLOW C1:SUS-MC2_MASTER_OVERFLOW
op440m:WFS>

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:

Quote:

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.

434

Tue Apr 22 08:34:22 2008

josephb

Cameras

Current Network Diagram

The attached network diagram has also been added to the 40m Wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Image_Processing_with_GigE_Cameras

Attachment 1: Network.pdf

435

Tue Apr 22 10:59:24 2008

MC1 electronics busted

Quote:

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

end station sus front-end bug fix

Quote:

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

Caryn

no signal for C1:IOO-MC_L

IOO

C1:IOO-MC_L signal was at zero for the past few days

438

Tue Apr 22 22:19:02 2008

In the interests of tacit communication of scientific knowledge, I here reveal a nugget of knowledge which may or may not prove useful to new LIGOites: sometimes when front-end machines are rebooted, the hardware they control can wind up in a state which is not accurately represented by the EPICS values you may see. This can be easily rectified by momentarily changing the EPICS settings in question. For reference, this came up tonight in the context of the whitening gain sliders for the TransMon QPDs.

439

Tue Apr 22 22:51:30 2008

I've been working a little on the MC WFS in the last few days. I have made many
changes to the sensing matrix script and also to the MCWFSanalyze.m script.

The output matrix, as it was, was not bad at low frequencies but was making noise in
the ~1 Hz band. Turning the gain way down made it do good things at DC and not make
things work higher.

The output matrix generating script now works after Rob fixed the XYCOM issue. Not sure
what was up there. As Caryn mentioned the SUS2.ini channels were all zero after Andrey's
PEM power cycle a few days ago. Rob booted c1susvme to get the SUS1 channels back and
today we did c1susvme2 to get the IOO-MC_L et. al. back.

Even after doing the matrix inversion there is some bad stuff in the output matrix. I
checked that the sensing matrix measurement has good coherence and I measured and set the
MC WFS RF phases (they were off by ~20-30 deg.). Still no luck.

My best guess now is that the RG filters I've used for POS damping and the movement of the
beam on the MC mirror faces has made a POS<->YAW instability at low frequencies. My next
move is to revert to velocity damping and see if things get better. Should also try redoing
the A2L on the MC1-3.

440

Wed Apr 23 22:39:54 2008

DAQ

Problem with "get_data" and slow PEM channels

It turns out that I cannot read minute trends for the slow weather channels for more than 1000 seconds back (roughly more than 15 minutes ago) using "get_data" script.

For comparison, I tried MC1 slow channels, and similar problem did not arise there. Probably, something is wrong with the memory of slow weather channels. At the same time, I can see minute-trends in Dataviewer as long ago as I want.

In response to
>>get_data('C1: PEM-weather_outsideTemp', 'minute', gps('now') - 3690, 3600);
I get the error message:
"Warning: Missong C1: PEM-weather_outsideTemp M data at 893045156".

441

Thu Apr 24 11:50:10 2008

josephb

Useful tidbits learned while tracking the network setup

In process of understanding the network setup I've learned several things:

1) The status lights on C0DAQ_RFMNETWORK.adl are controlled by the fiber network, as opposed to the ethernet network. However, even if everything is working properly on the VME end, you may still need to reboot it in order to be able to contact it via the ethernet (ssh or telnet).

2) After disconnecting the hub out by 1Y9, I was able to telnet into c1vac1, but not c1vac2. I was told that the Turbo pump and Ion pump readbacks on C0VACMONITOR.adl had not been working for awhile (years?). So I went out and rebooted the c1vac2 card. This seemed to restore the epic channels and we now have correct readbacks on the turbo pumps. The ion pumps all are reading no voltage, which is good because they're turned off. However C1:Vac-IPSE_mon is reading "On", although Steve assures me the actual unit is currently off, so there may be a minor channel issue there.

442

Thu Apr 24 14:10:26 2008

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.

443

Thu Apr 24 15:57:53 2008

I measured the output power of the psl after the mechanical shutter.

It was 1.1 W with Ophir power meter, than unlocked the MC and measured
the power at the MC-REFL Beam Dump at the AP-ISCT 0.9 W
Power on MC-REFL photodiode 92 mW

High power metal beam shields were installed around the beam path of
MC-REFL between AP-Viewport and MC-REFL Beam Dump.
Placed HIGH POWER LASER BEAM PATH warning signs on table frame and top
covers.

Last week I placed a small monitor on the top of the OOC that
monitors the resonant spot of MC2. Please keep an eye on this monitor
when working on the AP-ISCT

AP table should NOT be left uncovered. One experienced laser operator
has to be present if the top is removed and IR-viewer scan required.
We need your full cooperation to keep this lab safe.

Attachment 1: P1020197.JPG

Attachment 2: mcrefl3.JPG

444

Thu Apr 24 22:06:47 2008

Ethernet Cables and Hubs

Today in the morning (between 8.30AM and noon) Joe and I were working on understanding which ethernet cables connect "processors controlling the work of equipment in the interferometer room" and "Internet hub in the computer room".

Firstly, we took off several times the blue ethernet cables from the router located near ETMX in the morning. We were trying to understand which port in the hub is responsible for the interaction with that processor.

Secondly, we were working on reviving the connection with the computer controlling vacuum in the interferometer.

Later in the middle of the day (around 2PM) Joe continued some work with ethernet cables without me. We plan on continuing the cable work on Friday morning. A better and more detailed elog will appear then.

445

Thu Apr 24 23:27:48 2008

acoustic 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

Syringes in George the Freezer

General

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.

447

Fri Apr 25 11:33:40 2008

Computer controlling vaccum equipment

Old computer (located in the south-end end of the interferometer room) that was almost unable to fulfill his duties of controlling vacuum equipment has been replaced to "Linux-3". MEDM runs on "Linux-3".

We checked later that day together with Steve Vass that vacuum equipment (like vacuum valves) can be really controlled from the MEDM-screen 'VacControl.adl'.

Unused flat LCD monitor, keyboard and mouse (parts of the former LINUX-3 computer) were put on the second shelf of the computer rack in the computer room near the HP printer.

448

Fri Apr 25 13:20:04 2008

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

449

Fri Apr 25 13:53:11 2008

This is the promised more in detail summary from Andrey's log ID 444.

What we did was go around to each hub, one at a time, unplug the network connection, and figure out which light on which hub went out. We then, went back to the control room, confirmed that we were still able to talk to the devices connected to the hub, and if not, rebooted them. This process was repeated for each hub.

As it stands, the hubs located at the ends of arms (in racks 1X4 and 1Y9) are connected to the really old 24 port 10 Base T hub located in 1Y7. In addition, the 5 port SMC hub is plugged into the 8 port SMC switch in 1Y5 (which actually has enough ports to simply move all the connections over to it, so I'm not sure why there are two...).

All other hubs/switches are connected back to the control room 24 port switch.

Attached is a simple diagram of the network connections for the 40m lab.

Attachment 1: 40m_network_90.pdf

450

Fri Apr 25 15:44:21 2008

PSL

scattering 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

451

Fri Apr 25 20:53:02 2008

IOO

MC WFS with more gain

Quick update: we found that the reason for the MC WFS instability was that the digital anti-whitening was one but not the analog whitening.

We turned off the digital filters and were able to increase the gain by a factor of ~30. It is left like this, but if it hampers IFO locking then best to just turn it back down to an overall gain of 0.1 or 0.05.

452

Sat Apr 26 01:45:38 2008

Weather Station enhancement

Two more things concerning weather monitoring have been done during this week.

1) A Dataviewer template was created, so that it allows to see "real-time" information from weather channels immediately, without adding many channels "manually".

If one wants to use this template,
open Dataviewer -> "File" -> "Restore Settings", /cvs/cds/caltech/users/Templates/Dataviewer_Templates/Weather.xml.

2) I wrote a couple of Matlab scripts that allow to read data (minute trends) from the Dataviewer channels over some time in the past, save the received data in mat-files, and plot those minute-trends. Thus, one can get plots that are very much similar to what one can see in Dataviewer. These two Matlab files are located in the directory
"/cvs/cds/caltech/users/weather_station". File "WeatherReading.m" allows reading from the weather channels (paths to mDV directory must be configured before using my script), file "WeatherTrends.m" allows plotting of those minute trends.

Unfortunately, hardware problems arise very often if we want to read for a somewhat long time in the past, so until now I have not succeeded in getting trends for more than 20 minutes. As an example, see the attached png-file with the 20-minutes trends of data from Thursday evening.

3) So far I did not have success in learning how to recalculate pressure from Pascals to mbars in EPICS (although I tried google-search).

4) I am making every effort in recent weeks not to put any personal or non-scientific information into elog, but this message could be important for all of us, so I cannot resist:
a shark in the Pacific Ocean has killed a swimmer near San-Diego (I saw this in russian news and then made a quick google-search).
http://latimesblogs.latimes.com/lanow/2008/04/this-just-in-fa.html

Attachment 1: Matlab_Weather_Trends.png

453

Sat Apr 26 11:21:15 2008

ajw

Omnistructure

backup of /cvs/cds restarted

The backup of /cvs/cds (which runs as a cron job on fb40m; see /cvs/cds/caltech/scripts/backup/000README.txt) 
has been down since fb40m was rebooted on March 3.
I was unable to start it because of conflicting ssh keys in /home/controls/.ssh .
With help from Dan Kozak, we got it to work with both sets of keys
( id_rsa, which allows one to ssh between computers in our 113 network without typing a password,
 and backup2PB which allows the cron job to push the backup files to the archive in Powell-Booth).

It still goes down every time one reboots fb40m, and I don't have a solution.
A simple solution is for the script to send an email whenever it can't connect via ssh keys
(requiring a restart of ssh-agent with a passphrase), but email doesn't seem to work on fb40m.
I'll see if I can get help on how to have sendmail run on fb40m.

454

Sun Apr 27 02:11:11 2008

As noted in the elog from Friday, the WFS has been bad ever since someone switched on the digital whitening filters (FM1 & FM2)
in the MC WFS I&Q filter banks.

On Friday evening, John, Alan, and I went to the rack and verified that although the drawing shows a hookup for the whitening
filters, there is actually no such thing and so we can't have the whitening. So the anti-whitening turns on two lag filters
(2 poles at 4 Hz) and without the hardware this makes the servos unstable by adding 90 deg of phase lag at 4 Hz.

There are still several problems in this system:

- AD797 is used after the mixer. This is an unreliable, noisy part. We need to change this out
  with some OP27s so that this becomes reliable and has a more reasonable noise figure.

- Hard wire the whitening filters ON. We never want these to be off. Then we can turn on the
  anti-whitening. This will give us a factor of 100 better noise without filtering.

- The AD602 on the front of the whitening board has a 100 Ohm internal impedance and the 
  resistor between the demod board and the AD602 is 909 Ohms. This results in dividing the
  signal by 10.

- The signal at the ADC is ~100 cts peak-peak. The full ADC range is, of course, 65000 cts. So
  we could use a lot more gain. The mean quadrant signals are also ~100 cts so we could easily
  up the analog DC gain by a factor of 30 on top of the whitening filter increase.

- The AD602 at the input and the AD620 on the output are both variable gain stages but because
  of our lack of control are set to ambiguous gain levels. We should set the AD602 on the input
  to its max gain of 30 dB. With the -20 dB from the x10 voltage division, this will give us
  an overall gain of 3 for the puny demod signals.

455

Sun Apr 27 05:09:30 2008

MC WFS Whitening turned on

IOO

I hardwired on the MC WFS whitening filters.

The MAX333A switches which choose between whitening and bypass on that board were in the bypass position
because the Xycom220 connections are not there. So the control switch gets +15V but there is no pull
down to set it to the whitened mode.

The least invasive (easiest) change I could do was to tie all of those inputs to ground. This pulls a few mA
through the pull-down resistors but is otherwise innocuous. All of these control lines come in on the A-row
of the P1 connector, so I was able to solder a single wire across all of them to ground them all.

The WFS2 board had a blown electrolytic capacitor on the -15 V line and so there was probably some extra noise
getting in that way. I couldn't find any extra SMD to replace it so I cut the legs off of a 22 uF polarized
tantalum and stuck it in there. Its even close to being the same color. I checked out the other caps, and they were all
close to 68 uF as spec'd. This one had luckily blown open and so didn't suck down the Sorensen and destroy everything.

Plugged everything back in switched the WFS servos back on. Looks good. Took before and after spectra.

In the plot:

GREEN: Open loop dark noise before changes
RED: Open loop bright (MC locked but MCWFS off)
BLUE: Closed loop, MC locked

BLACK: Dark noise after whitening
ORANGE:Closed loop after whitening

The cursor is at 16.25 Hz, the SOS bounce mode.

The I ran the new setMCWFSgains script which uses pzgain to set the UGFs of the 4 loops to 4.01 Hz.
We have in the past had problems with high WFS gains causing instabilities with the CM servo around 10-30 Hz. If this happens we should
just lower the gain by a factor of ~5.

Attachment 1: mcnoise.png

456

Sun Apr 27 18:11:58 2008

The testpoint manager (which runs on fb40m) crashed this afternoon. Upon re-starting it, I found there was a rogue dtt process on op440m and also a daqd daemon running on br40m. One or both of these caused the tpman to crash. br40m is the frame broadcaster, which is never used here as we don't run DMT. I killed the daqd process there.

The way to find if there is a rogue process is to watch the output to the console from the tpman when you start it:

Allocate new TP handle 56 by 131.215.113.203
Allocate new TP handle 57 by 131.215.113.203
Allocate new TP handle 58 by 131.215.113.203
Allocate new TP handle 59 by 131.215.113.203
Allocate new TP handle 60 by 131.215.113.203
Allocate new TP handle 61 by 131.215.113.203
Allocate new TP handle 62 by 131.215.113.203
Allocate new TP handle 63 by 131.215.113.203
Allocate new TP handle 64 by 131.215.113.203
Allocate new TP handle 65 by 131.215.113.203
Allocate new TP handle 66 by 131.215.113.203
Allocate new TP handle 67 by 131.215.113.203
Allocate new TP handle 68 by 131.215.113.203

If you see something like this, with a new TP handle being allocated every few seconds, you need to log in to the corresponding host and kill whatever process has run away.

457

Sun Apr 27 22:57:15 2008

Quote:

I *think* Alex is responsible for the daqd daemon running on br40m (he set up some new stuff recently, a data concentrator and broadcaster); I'll make sure he sees this post.

458

Mon Apr 28 23:44:33 2008