ELOG 40m

Dissapointing Results of XARM optimization (PDF-file)

I attach a PDF-file which summarizes briefly the results of measurements/calculations of Q-factors for ITMX mass as a function of suspension damping gain,

and this file contains the results of measurements of RMS peaks on the values of suspension gains of ITMX and ETMX (see ELOG entries from December 2007, specifically #202, #199, #194)),
but now those dependences are plotted in Q-ITMX and Q_ETMX axes.

Unfortunately, there are no clear narrow areas of minimum in those dependences (that explains the sad title of this ELOG entry).

The attached pdf-file can be shown as a short presentation for a wall during our Wednesday meeting.

Attachment 1: Sad_Results_XARM.pdf

257

Wed Jan 23 20:52:40 2008

Flooding from construction area

Environment

We noticed tonight around 7 PM that there was a lot of brown water in the control room and also in the interferometer area mostly concentrated around the north wall between the LSC rack and the AP table.

The leak was mainly in the NW corner of the interferometer area.

The construction crew had set up sandbags, plastic sheet, and gravel to block the drains outside of the 40m along the north wall. The rain had produced ponds and lakes outside in the construction area. Once the level got high enough this leaked through holes in the 40m building walls (these are crappy walls).

We called the on-call facilities team (1 guy). He showed up, cut through the construction fence lock, and then unblocked the drains. This guy was pretty good (although inscrutable); he adjusted the sandbags to control the flow of the lake into the drains. He went along the wall and unblocked all 3 drains; there were mini-lakes forming there which he felt would eventually start leaks all along our north wall.

In the morning we'll need volunteers to move equipment around under Steve's direction while the floor gets mopped up. There's dirt and mud all over, underneath the chambers and racks.

Luckily Alberto spotted this early and he, Jon, Andrey and Steve kept the water from spreading and then scooped it all up with a wet-vac that the facilities guy brought over.
Extra Napoleon to them for late evening mud clearing work.

Many pictures were taken: Update and pictures will appear later.

Attachment 1: Shop-Vac_Action.MOV

Attachment 2: Flooding.pdf

258

Thu Jan 24 11:52:56 2008

steve

the mud is cleaned up & MOPA shutter is opened

Safety glasses are required again!

I have just opened the mopa shutter.
One janitor came to help with muddy floor.
Rack 1x1 toward ITMX chamber and the south wall of these area
were completely covered by mud. I wiped the floor of bottom of the rack
with towels. The cables were lifted and still should be wiped.

The bottom of LSC rack got less water, only on the west side.

We are ready to bring up the computers.

Thanks to ALL with the clean up, including Alan Rice
who was really helpful.

259

Thu Jan 24 12:50:50 2008

Some pictures from the group meeting yesterday.

Attachment 1: Sweeties.pdf

260

Thu Jan 24 20:03:40 2008

Changes to Dataviewer channels (XARM)

1) Good news. I added a chanel "C1:SUS-ETMX_POS" to Dataviewer.

I followed the instructions from WIKI-40:

modify the file "C1SUS_EX.ini" in /cvs/cds/caltech/chans/daq,
then telnet to fb40m,
then "click the appropriate blue button on the DAQ MEDM screen".

So, I can now read a signal from the channel "C1:SUS-ETMX_POS" in Dataviewer,

and this allows me to measure Q-factors of ETMX this evening (make similar work for what I did on Tuesday for ITMX).

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).

Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line, while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.

Again, I apologize and hope that the problem is not very serious.

261

Thu Jan 24 22:10:49 2008

Computer Scripts / Programs

Problem with channels - help of Rana, Robert or Steve is needed

I definitely spoiled something (changes some settings) by chaotically clicking those blue buttons (see my previous entry # 260).

Unfortunately, I cannot use standard library of functions for reading from channels from mDV directory.

Although I see the curve of a noise in the Dataviewer from the channel "Ch1:SUS_ETMX_POS", when I try to read data from the channel using the program "get_data" from MDV directory, I get the error message
"Warning: No data available for [numbers representing "gps_start_time" and "gps_end_time"].
In new_readframedata at 136
In new_fetch_shourov at 71
In get_data at 98"

I checked, both gps-times are in the past from now, so as far I understand, nothing is recorded into the channels.
Of course, I added two hours ago to the directory "mDV", that is I used addpath(pwd) in that directory.

And I also cannot run the program that I used on Tuesday evening which takes data from "C1:SUS_ITMX_POS" (no data from that channel), which worked perfectly on Tuesday.

I again apologize for clicking the wrong blue button (see my explanation in my previous message #260). I ask someone who knows how to return normal working of channels (normal interaction of computer and channel memory) to do that.

Before that I cannot take data. I do not know how to restore the initial settings which existed before I started adding the channel to Dataviewer.

Andrey.

262

Thu Jan 24 22:52:18 2008

Bureaucracy

Ants around a dirty glass (David - please read!)

Dear coleagues,

there are rains outside these days, so ants tend to go inside our premises.

David was drinking some beverage from a glass earlier today (at 2PM) and left a dirty glass near the computer.

There are dozens, if not hundreds, of ants inside of that glass now.

Of course, I am washing this glass.

A.

263

Fri Jan 25 08:55:26 2008

rob

Changes to Dataviewer channels (XARM)

As a general rule,

Quote:

clicking random blue buttons chaotically

is not a good problem solving technique. It is thus now explicitly discouraged as an option in the LIGO 40m Lab.

264

Fri Jan 25 09:22:21 2008

steve

burned toast award goes to

DYM for collaborating with the enemy.

In order to minimize the number of ants visiting our lab we have to take out side the lab
all food left over and organic waste. If you are eating here do not expect someone else
to clean up after you.

Thanks for your cooperation.

265

Fri Jan 25 10:14:35 2008

rob

Changes to Dataviewer channels (XARM)

Quote:

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).

Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line, while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.

I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.

266

Fri Jan 25 11:38:16 2008

Working GiGE video on Linux - sort of

1)I have been able to compile the SampleViewer program which can stream the video from the Prosilica 750C camera. This was accomplished on my 64-bit laptop running Ubuntu, after about 3 hours of explicitly converting strings to wxStrings and back again within the C++ code. (There was probably an easier way to simply overload the functions that were being called, but I wasn't sure how to go about doing so). By connecting it to the CDS network, I was able to immediately detect the camera and display the images.

Unfortunately, I have not yet been able to get it to compile on Mafalda with the x86 architecture. This may be do the fact that it has wxWidgets version 2.8.7 while my laptop has 2.8.4. Certainly the failure at compile time looks different from the errors earlier, and seem to be within the wxWidget code rather than the SampleViewer code. I may simply need to uninstall 2.8.7 and install 2.8.4 of wxWidgets.

The modified code that will compile on my machine has been copied to /cvs/cds/caltech/target/Prosilica/examples/SampleViewer2b.

2)The Snap program (under /cvs/cds/caltech/target/Prosilica/examples/Snap) also will now take full resolution images even on Mafalda. This was achieved by reducing the packet size to 1000 and also increasing the wait until timeout time up to 400 ms, which originally was at 100. Apparently, it takes on the order of 1 ms per packet as far as I can tell. So full resolution at 752x480 required something of order 360 packets.

To Do:
1) Get sample viewer to compile on Mafalda, and then statically compile it so it can be run from any Linux based machine.
2) Get a user friendly version of Snap up and running, statically compiled, with options for a continuous loop every X seconds and also to set desired parameters (such as height, width, file name to save to, save format, etc).
3) Figure out data analysis with the images in Matlab and an after the fact image viewer.

Attached is an example .tiff image from the Snap program.

Attachment 1: snap.tiff

267

Fri Jan 25 13:36:13 2008

Working GiGE video on Mafalda

Finally got the GiGE camera sample viewer video running on Mafalda by updating to the latest API (version 1.16 from Dec 16, 2007) from Prosilica and then using the modified Sample Viewer code I had written. The API version previously in cvs was 1.14.

It can currently be run by ssh -X into Mafalda and going to /cvs/cds/caltech/target/Prosilica/bin-pc/x86 and running the SampleViewer executable found there.

268

Fri Jan 25 15:53:59 2008

Alberto

40 dB from the 3rd order Chebyschev

Electronics

I managed to tune the 7 knobs in the 3rd order Chebyshev bandpass filter obtaining the tranfer function attached to this entry. We have now 40 dB of attenuation between 166 Mhz and 133 and 199. With this tuning the insertion loss is rather high. We need a better one.

Alberto

Attachment 1: 166MhzElog.png

269

Fri Jan 25 17:11:07 2008

Max , Andrey

NEW_FETCH_SHOUROV and GET_DATA do not work

The problem which started yesterday after Andrey's framebuilder restart still persists.

It is still impossible to read data in the past from the channels using "get_data" which in turn uses "new_fetch_shourov".

Max was trying to read data from the channel
"C1:LSC-DARM_CTRL",

and he got the same error messages as Andrey.

Andrey tried earlier today to read data from "C1:SUS-ITMS_SUS" or "C1:SUS-ETMX_SUS" with the error meassge
Error in ==> new_fetch_shourov at 22
at (start_time+duration) > stops(end)

So, it seems that Robert Ward fixed just one problem out of two problems.

Robert revived the realtime signals in Dataviewer,
but did not revive the memory of channels for new_fetch_shourov.

To be more precise, channels have memory (it is possible to see the "Playback" curves in Dataviewer"),
but "get_data" and "new_fetch_shourov" do not see the data from those channels. The problem appeared immediately after Andrey's clicking on blue buttons to restart the framebuilder.

Andrey again apologizes.

270

Fri Jan 25 21:36:40 2008

Fri Jan 25 21:30:00 2008

As it turns out, the residual problem with the mDV stuff was not to do with our button pushing episode but instead fallout from the 'turning off of the computers' during the water leak caused by the rain and construction.

The /frames partition from fb0 (the FrameBuilder) is not mounted to the control machines via vfstab; it does not remount on bootup. I originally did this because Ben Johnson and Dave Barker had warned me that during a power outage, fb0 may not come up right away. This could make the control room machines hang up for awhile. I elected to have the mount be by hand.

So the thing to do is to put the mount command into the cold start procedures (Andrey). Its in an old elog entry of mine from Feb '07.

271

Sat Jan 26 02:02:43 2008

I added the following channels.

# C1ASC_QPDs
[C1:SUS-ETMY_QPDSUM_MON]
[C1:SUS-ETMY_QPDYAW_MON]
[C1:SUS-ETMY_QPDPIT_MON]

[C1:SUS-ETMX_QPDSUM_MON]
[C1:SUS-ETMX_QPDYAW_MON]
[C1:SUS-ETMX_QPDPIT_MON]

The old .ini file is /cvs/cds/caltech/chans/daq/C0EDCU_26_1_2008.ini

272

Sat Jan 26 02:08:53 2008

There is now a fibre running from the SP table to the ISCT at the Y-end. In the coming days I will try to mode match the beam from this fibre into the arm through ETMY. To achieve this I will be altering the optical layout of this table.

273

Sat Jan 26 02:34:34 2008

Computer Scripts / Programs

Overnight Measuremts in XARM

I am running the program for measuring RMS of peaks in XARM tonight. I just started it, and it will run for about 9 hours until noon on Saturday. Please do not disturb the interferometer. Now the XARM is locked, it should stay locked over the night.

Andrey.

274

Sat Jan 26 18:12:45 2008

extra processes and crashes

HowTo

Computers

There were a load of extra processes on op440m; they were all related to rogue DV processes (frameMemRead, framer4, xmgrace, etc.)

You can check this by running top. IF there's lots of them you can kill them by using 'pkill'.

I'm attaching the screen cap of a 'top' session. You can also see that the cron of updatedb is running and taking upp all the CCPU. Thee result is that the delay puts misspellings and doouble characters intoo my elog entry. Clearly wwe'll have to fix the cron setup.

275

Sat Jan 26 18:48:43 2008

iscepics died this afternoon. We restarted it and restored settings from yesterday. I've written up instructions in the wiki.

276

Sat Jan 26 22:00:03 2008

John

LSC-TRY_OUT and ETMY-QPD

In the path from the ETM to the trans PD and QPD at the Y end I have replaced a BS1-1064-10-2037-45P with a polariser. The power falling on these diodes has been reduced. When the arm is locked in its nominal state the transmitted power is now less than 1.

This polariser should serve as an injection point for the auxiliary arm locking. I am attempting to use crossed polarisations to separate this loop from the main arm light.

277

Sun Jan 27 13:13:21 2008

It's been grand. Thanks for having me!

GWAVES IN '08!

Sugar napoleons may be forwarded to T. F., c/o LLO, P.O. Box 940, Livingston, LA 70754-0940.

278

Sun Jan 27 21:44:48 2008

running compiled matlab DMF tools

CDS

Seismic BLRMS on Matlab

I wrote a matlab script to produce band limited RMS trends from our accelerometers. It mimics the code written
by Ed Daw which makes the seismic FOMs at the sites.

Here's how it works:

Use mDV to get data by reading directly from frames.
Use the Matlab pwelch function to produce a power spectrum of the channels.
Use the Matlab find function and rms.m to get the RMS in user-defined frequency bands.
Makes a tdswrite command string which writes all the values to EPICS channels.
The EPICS channels are just a list of simple names in a database file.
The channel names are (will be) added to the C0EDCU.ini file so that its all trended.

The code is in the mDV/extra/C1 directory; its ~20 lines of code (excluding comments and spaces).

Next up is to add more DMF trend channels to the database and upgrade the code to use a .conf file
instead of hardcoded channel names. We should also evaluate if the bands I used are appropriate for the 40m;
I just used Ed's choices (0.1-0.3, 0.3-1, 1-3, 3-10, and 10-30 Hz).

In the medium term, we should make this compiled (like what RW did with the linetracker), and explore if we
want it to write values faster than 1/minute.

Attachment 1: seisBLRMS.m

% Seismic BLRMS Monitor
%
%
%
% RA 08-01-26

% 0 for no messages, 1 for debugging
debug_flag = 1;

% ------------ Build channel list

... 82 more lines ...

279

Mon Jan 28 12:42:48 2008

There is tea in the coffee carafe @ the 40m. It is sitting as though it were fresh coffee. There is also nothing on the post it.

280

Mon Jan 28 15:11:38 2008

rob

HowTo

DMF

I compiled Rana's seisBLRMS monitor, and it's now running on mafalda. To start your own DMF tools, here is a procedure:

1) build your tool in mDV, get it working the way you'd like.
2) Make a new directory /cvs/cds/caltech/apps/DMF/compiled_matlab/{your_new_directory} and copy the *.m file there.
3) Make the *.m in your new directory into a function with no args (just add a function line at the top)
4) compile it (from within a fully mDV-configured matlab) with mcc -m -R -nojvm {yourfile}.m at the matlab command line.
5) add a line corresponding to your new tool to the script /cvs/cds/caltech/apps/DMF/scripts/start_all
6) Run the start_all script referenced in part (5).

NB: Steps (4) and (6) must be carried out on mafalda.

281

Mon Jan 28 17:16:54 2008

Matlab libraries DO NOT WORK properly sometimes

Computers

Working in Matlab, I encountered at two different times today the license distribution problem:

??? License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
Try again later.
To see a list of current users use the lmstat utility or contact your License Administrator.

Troubleshoot this issue by visiting:
http://www.mathworks.com/support/lme4a

282

Mon Jan 28 18:56:47 2008

I made all of the updates I aludded to before:

Expanded the dmf.db file on c1aux to include all accelerometers and the seismometer.
Added the channels to the C0EDCU.ini file and restarted the framebuilder daqd.
Modified seisBLRMS.m to use .conf files for the channels. The .conf files are now residing in the compiled matlab directory that Rob made.

I still have yet to compile and test the new version. Its running on linux3 right now, but feel free to kill it and compile it to run on Mafalda.

It should be making trends overnight and so we can finally see what the undergrads are really up to.

283

Mon Jan 28 19:35:55 2008

Accelerometer and Seismometer Coherences

The attached PDF shows that there is some strange behavior at low frequencies.

From the plot it looks like to me that the Wilcoxon accelerometers (which are supposed to have good response down to 0.05 Hz) are not displaying real seismic motion below 0.3 Hz. Because the coherence length for seismic waves at those frequencies should be 100's of meters we should expect that the accelerometers would have good coherence (>0.8) down there. Instead, my guess is that its all air currents, temperature, or electronics noise. These sensors are not reliable indicators for the microseism.

The Ranger seismometer, however, seems to work fine down to just below the microseism. The Ranger is mounted down around the X end and pointing in the z-direction. The coherence I plotted between it and EX_Z is larger than any other acc/seis pair (as expected).

JM and I discussed what could be done; if we get a SURF student who's into building stuff we can ask them to make a styrofoam hut for the Wilcoxons to see if that helps anything. JM also asked what the point of all this is.

IF we want to do good Adaptive Noise subtraction then we need sensors which can sense the motion which disturbs the mirrors and they need to sense it with a good SNR to get a good subtraction ratio. If the styrofoam thing doesn't work, we should probably look into getting a Guralp 3-axis seismometer for the corner area and just move the accelerometers down to the ends. The sites have Guralp CMG-40T units (~ 8k$). I think we should check out the CMG-3T or the CMG-3ESP.

Does anyone know someone in the Geo depts that we can borrow one from?

Attachment 1: Acc.pdf

284

Tue Jan 29 14:56:39 2008

The seisBLRMS 1.0 program crashed at ~7:20 pm last night, so we didn't get data from overnight. It crashed when framecaching failed. I added
a try-catch-end statement around the call to dttfft2 to let the program survive this, then compiled it and started it on mafalda. After ~45 minutes, the compiled version encountered the same error, and while it didn't crash per se, after 20 minutes it still wasn't able to read data. We may have to dig deeper into the guts of mDV to make this stuff run more robustly.

285

Wed Jan 30 11:49:30 2008

Alberto

RF monitor's filters final schematics and transfer functions

Electronics

These are the final schematics for the 6th order Chebyshev filters of the RF monitor board. I'm also attaching the TF as I measured. The tuning is probably not optimal, less insertion noise could be achieved.

Attachment 1: 33Melog30Jan08.png

Attachment 2: 133Melog30Jan08.png

Attachment 3: 166Melog30Jan08.png

Attachment 4: 199Melog30Jan08.png

Attachment 5: 33elog30Jan08.png

Attachment 6: 133elog30Jan08.png

Attachment 7: 166elog30Jan08.png

Attachment 8: 199elog30Jan08.png

286

Wed Jan 30 13:09:55 2008

New results for XARM (pdf)

See attachments: pdf-presentation with plots in "true" axes Q_ETMX and Q_ITMX, and seismic backgound measurement.

Results that were shown a week ago turned out to be not sad at all!

Attachment 1: New_Results_XARM.pdf

Attachment 2: Accel-Seismic_10AM.pdf

287

Wed Jan 30 20:39:31 2008

In order to reduce the probability of seisBLRMS crashing due to unavailability of data, I edited seisBLRMS.m so that it displays data from 6 minutes in the past, rather than 3. After compiling, this version ran for ~8 hours without crashing. I've killed the process now because it seems to interfere with alignment scripts that use ezcademod, causing "DATA RECEIVING ERROR 4608" messages. These don't cause ezcademod to crash, but so many of them are spit out that the scripts don't work very well. I guess running DMF constantly is just making the framebuilder work too hard with disk access. In the near term, we can maybe work around this by having DMF programs check the AutoDithering bit of the IFO state vector, and just not try to get data when we're running these sorts of scripts.

288

Thu Jan 31 12:39:14 2008

John

Y arm test mass cameras

I've adjusted the test mass cameras on the y arm to make the beam injected through ETMY more visible.

289

Thu Jan 31 16:53:41 2008

Improving camera user interface

There's a new and improved version of Snap program at the moment people are free to play with.

Located in /cvs/cds/caltech/target/Prosilica/40mCode/

The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.

At the moment, it only runs on mafalda.

Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.

After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).

Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.

I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' "

Attachment 1: Camera_exp_15000.tiff

Attachment 2: Camera_exp_3000.tiff

290

Fri Feb 1 10:43:05 2008

The boys next door have some bigger noisier toys.

Attachment 1: DSC_0433.JPG

291

Fri Feb 1 12:37:39 2008

Here are DV trends of the output of seisBLRMS over the last ~36 hours (which is how long it's been running), and another of the last 2 hours (which show the construction crew taking what appears to be a lunch break).

Attachment 1: seis36hours.png

Attachment 2: seis2hours.png

292

Fri Feb 1 15:04:54 2008

Snap with looping functionality available

New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.

Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.

"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).

It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.

Use --help for a full list of options.

Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera 131.215.113.104 (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment.

293

Fri Feb 1 17:17:05 2008

I helped Rob adjust the alignment of the Mach-Zender to try and reduce any AM on the laser light. Our goal was to reduce the large offsets in the DD signals.

We reduced the MZ refl from 0.54 to 0.39. We were able to re-lock the mode cleaner without problems. We then centred the WFS heads.

No change in the DD signal offsets.

294

Sat Feb 2 14:11:27 2008

I changed the layout of the optlev master screen. The old version is /cvs/cds/caltech/medm/old/C1ASC_OPTLEVmaster080202.adl

295

Sun Feb 3 05:02:41 2008

Attachment 1: Screenshot.png

296

Mon Feb 4 22:01:57 2008

John

Fibres auxiliary locking - Fibers

LSC

I managed to couple ~75% of the light transmitted from the y arm, through the fibre, back to the SP table. I hoped that this would be a good way to match the beam from the fibre into the arm. Still no flashes. It looks like the cameras just aren't sensitive enough.

297

Tue Feb 5 15:32:29 2008

PMC and the GigE Camera

The PMC transmission video camera has been removed and replaced with the GigE GC750 camera for the moment.

A ND4.0 filter has been added in the path to that camera to reduce saturation for the moment.

The old camera has been placed on the elevated section inside the enclosure, and the cable for it is still on the table proper.

The Gige camera is currently running the Snap code on Linux3 with the following command line:

./Snap -E 2000 -l 60 -m 1440 -f './pmc_trans/pmc_trans'

So its going to be taking tiff images every minute for the next 24 hours into the cvs/cds/caltech/target/Prosilica/40mCode/pmc_trans/ directory.

Attached is an example image with exposure set to 2000, loaded into matlab and plotted with the surf command. 2500 microseconds looked like it was still saturating, but this seems to be a good level (with a max of 58560 out of 65535).

Attachment 1: pmc_trans.jpg

298

Tue Feb 5 17:39:05 2008

jweiner

PEM-AS_MIC taken down from AS table, will put in PSL enclosure soon

I took down the microphone that Andrey hung above the AS table his first week in lab. I want to hang the microphone above the PMC to check the effect of acoustic noise on the PMC. The cables were a little more tangled than I thought so I've only taken the microphone down and haven't hung it back up yet, but on Thursday I'll have enough time to carefully put it up inside the PSL and see what I can find out about acoustic noise inside the PSL. I think the microphone should be sensitive enough for the frequencies we're interested in, and I'll hopefully find out if it's sufficient once I put it up in the PSL. The microphone cable and microphone are on top of the PSL for now.

299

Wed Feb 6 09:17:31 2008

steve

IST building construction continoues

The bulldosers at work

Attachment 1: seismic8d.jpg

Attachment 2: seisioo.jpg

300

Wed Feb 6 16:50:47 2008

Regions of Interest and max frame rate

The Snap code has once again been modified such that setting the -l option to 0 will take images as fast as possible. Also, the -H and -W options set the height and width, while in principle the -Y and -X options set the position in pixels of the top edge and left edge of the image. It also seems possible to set these values such that the saved image wraps around. I'll be adding some command checking so that the user can't do this in the near future.

Doing some timed runs, using a -H 350 and -W 350 (as opposed to the full 752x480), 100 images can be saved in roughly 8 seconds, and 1000 images took about 73 seconds. This corresponds to a frame rate of about 12-13 frames per second (or a 12-13 Hz display). The size of this area was sufficient to cover the current PMC transmission beam.

The command line I used was

time ./Snap -l 0 -m 1000 -f 'test' -W 350 -H 350 -Y 50 -X 350 -E 2000

Interestingly enough, there would be bursts of failed frame saves if I executed commands in another terminal (such as using ls on the directory where the files were being stored).

As always, this code is available in /cvs/cds/caltech/target/Prosilica/40mCode/.

301

Wed Feb 6 19:39:11 2008

Regions of Interest and max frame rate

We really need to look into making the 40m CDS network have an all GigE backbone so that we can have cooler cameras as well as collect multiple datastreams...

302

Fri Feb 8 17:09:52 2008

Max Jones

Computers

Changes to NoiseBudget

Today I altered the following files

caltech/NB/matlab/utilities/get_dtt_dataset
In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.

caltech/NB/matlab/noise/getUGF.m
I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.

Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you.

303

Fri Feb 8 17:55:53 2008

josh