40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 274 of 339  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  16144   Tue May 18 00:52:38 2021 ranaUpdatePSLHEPA speed raised

Looks like the fan lowered the temperature as expected. Need to get a few more days of data to see if its stabilized, or if that's just a fluke.

The vertical line at 00:00 UTC May 18 is about when I turned the fans up/on.

Attachment 1: Untitled.png
Untitled.png
  16145   Tue May 18 20:26:11 2021 ranaUpdatePSLHEPA speed raised

Fluke. Temp fluctuations are as usual, but the overall temperature is still lower. We ought to put some temperature sensors at the X & Y ends to see what's happening there too.

  16400   Thu Oct 14 09:28:46 2021 YehonathanUpdatePSLPMC unlocked

PMC has been unlocked since ~ 2:30 AM. Seems like the PZT got saturated. I moved the DC output adjuster and the PMC locked immidiatly although with a low transmission of 0.62V (>0.7V is the usual case) and high REFL.

IMC locked immidiately but IFO seems to be completely misaligned. The beams on the AS monitor are moving quite alot syncronously. BS watchdog tripped. I enabled the coil outputs. Waiting for the RMS motion to relax...

Its not relaxing. RMS motion is still high. I disabled the coils again and reenabled them. This seems to have worked. Arms were locked quite easily but the ETMs oplevs were way off and the ASS couldn't get the TRX and TRY more than 0.7. I align the ETMs to center the oplev. I realign everything else and lock the arms. Maximium TR is still < 0.8.

 

 

  16401   Thu Oct 14 11:25:49 2021 YehonathanUpdatePSLPMC unlocked

{Yehonathan, Anchal}

I went to get a sandwich around 10:20 AM and when I came back BS was moving like crazy. We shutdown the watchdog.

We look at the spectra of the OSEMs (attachment 1). Clearly, the UR sensing is bad.

We took the BS sattelite box out. Anchal opened the box and nothing seemed wrong visually. We returned the box and connected it to the fake OSEM box. The sensor spectra seemed normal.

We connected the box to the vacuum chamber and the spectra is still normal (attachment 2).

We turn on the coils and the motion got damped very quickly (RMS <0.5mV).

Either the problem was solved by disconnecting and connecting the cables or it will come back to haunt us.

 

 

 

Attachment 1: BS_OSEM_Sensor_PSD.pdf
BS_OSEM_Sensor_PSD.pdf
Attachment 2: BS_OSEM_Sensor_PSD_AfterReconnectingCables.pdf
BS_OSEM_Sensor_PSD_AfterReconnectingCables.pdf
  16886   Thu Jun 2 20:05:37 2022 yutaConfigurationPSLIMC input power recovered to 1W, some alignment works

[Paco, Yuta]

We have increased the output power from the PSL table to 951 mW (it was 96.7 mW).
IMC was recovered including WFS, and both arms are flashing nicely in IR.
We tweaked the alignment of GRX and GRY injection to align them with IR, but it was hard.
Right now IR beams are not centered on TMs. We should center them first.

What we did:
Power increase and IMC recovery
 - Replaced a beam splitter which splits the beam into IMC REFL RF PD path and WFS path from R=98% to R=10% one. Reflection goes to RF PD.
 - Put a R=98% beam splitter back into WFS path.
 - We also tried to put a window in front of IMC REFL camera to recover the arrangement in 40m wiki, but the beam reflected from the window was too weak for us to align. So, we decided not to place a window in front of the camera.
 - Attached photos are the IMC REFL path before and after the work.
 - Measured the PSL output power as Koji did in elog 40m/16672. It was measured to be 96.7+/- 0.5 mW.
 - Rotated the HWP using the Universal Motion Controller (it was not possible for us to do it from the MEDM screen). The position was changed from 73.99 deg to 36.99 deg. Output power was measured to be 951 +/- 1 mW
 - IMC locked without any other changes.
 - Changed C1:IOO-WFS_TRIGGER_THRESH_ON to 5000 (was 500). IMC WFS also worked.
 - After running MC WFS relief script, WFS DC offsets and RF offsets are adjusted following the steps in elog 40m/16835. Below are the results.

C1:IOO-WFS1_SEG1_DC.AOFF => -0.0008882080010759334
C1:IOO-WFS1_SEG2_DC.AOFF => -0.0006527877490346629
C1:IOO-WFS1_SEG3_DC.AOFF => -0.0005847311617496113
C1:IOO-WFS1_SEG4_DC.AOFF => -0.0010395992663688955
C1:IOO-WFS2_SEG1_DC.AOFF => -0.0025944841559976334
C1:IOO-WFS2_SEG2_DC.AOFF => -0.003191715502180159
C1:IOO-WFS2_SEG3_DC.AOFF => -0.0036688060499727726
C1:IOO-WFS2_SEG4_DC.AOFF => -0.004011172490815322


IOO-WFS1_I1         :  +1977.7 ->    +2250 (Significant change)
IOO-WFS1_I2         :  +3785.8 ->  +3973.2
IOO-WFS1_I3         :  +2014.2 ->  +2277.7 (Significant change)
IOO-WFS1_I4         :  -208.83 ->  +430.96 (Significant change)
IOO-WFS1_Q1         :  +2379.5 ->  +1517.4 (Significant change)
IOO-WFS1_Q2         :  +2260.4 ->  +2172.6
IOO-WFS1_Q3         :  +588.86 ->  +978.98 (Significant change)
IOO-WFS1_Q4         :  +1654.8 ->  +195.38 (Significant change)
IOO-WFS2_I1         :  -1619.9 ->  -534.25 (Significant change)
IOO-WFS2_I2         :  +1610.4 ->  +1619.8
IOO-WFS2_I3         :  +1919.6 ->  +2179.8 (Significant change)
IOO-WFS2_I4         :    +1557 ->  +1426.6
IOO-WFS2_Q1         :   -62.58 ->  +345.56 (Significant change)
IOO-WFS2_Q2         :  +777.01 ->  +805.41
IOO-WFS2_Q3         :  -6183.6 ->  -5365.8 (Significant change)
IOO-WFS2_Q4         :  +4457.2 ->  +4397.


IFO Alignment
 - Aligned both arms using IR. Both arm flashes at the following, which is consistent with the power increase.
 C1:SUS-ETMX_TRX_OUT_DQ ~1.1
 C1:SUS-ETMY_TRY_OUT_DQ ~0.6
 - With this, we tried to tweak GRX and GRY injection. The following is after the work. We could increase GTRX to 0.204 when the Xarm is aligned to green. This suggests that GRX injection is not aligned nicely yet. But the beams are also not centered on TMs. We should center them first.
 C1:ALS-TRX_OUT_DQ ~0.13
 C1:ALS-TRY_OUT_DQ ~0.07
 - GTRX and GTRY cameras are adjusted to have nicer images. In GRX path, the second and last lens before the PD and CCD was pulled ~ 1 cm behind its original position and both beams realigned. Then, on GRY path, the beam was re-centered on the first and only lens, the whole assembly pushed forward by ~ 2 cm and the beams re-centered.

Next:
 - Center the IR beam on TMs (first by our eyeballs; better to use A2L after arm locking is recovered and coils are balanced)
 - Tweak GRX and GRY injection (restore GRY PZTs?)
 - Install ETMXT camera (if it is easy)
 - Lock Xarm and Yarm (C1:LSC-TRX/Y_OUT needs to be fixed for triggering. Can we use other PDs for triggering?)
 - MICH locking (REFL and AS PDs might need to be re-aligned; they are not receiving much light)
 - RTS model for BHD needs to be updated

Attachment 1: Before.JPG
Before.JPG
Attachment 2: After.JPG
After.JPG
  16917   Wed Jun 15 15:03:41 2022 KojiUpdatePSLPMC input beam aligned

The commissioners complained about the PMC alignment. The PMC input beam was aligned. It made the transmission improved from 0.72 to 0.74.

FYI: Which steering mirrors do we use for the PMC beam alignment?
The mounts are indicated with the red arrows in Attachment 2.
You have to move these two in common and differential for each pitch and yaw.
The first steering (the right one in the picture) has the beam going through the immediate back of the mount.
So touching the yaw knob of this mount needs some care so that you don't block the PMC refl beam.

Attachment 1: Screenshot_2022-06-15_15-03-16.png
Screenshot_2022-06-15_15-03-16.png
Attachment 2: PXL_20220615_212304650.jpg
PXL_20220615_212304650.jpg
  16922   Thu Jun 16 15:29:03 2022 yutaUpdatePSLPMC input beam aligned again, IMC

[Paco, Tomislav, Yuta]

Somehow, when we were trying to measure WFS open loop transfer functions, PMC unlocked many times for the past two hours and PMC transmission got low.
PMC iput beam was aligned again, and IMC WFS DC offsets and RF offsets were adjusted.
PMC transmission is now C1:PSL-PMC_PMCTRANSPD~0.75, and IMC transmission is C1:IOO-MC_TRANS_SUM~1.4e4.
Actually, IMC transmission once reached 1.5e4 at 06-16-2022 20:01 UTC with PMC transmission of 0.75 (see Attached). There might be a better alignment.

Attachment 1: Screenshot_2022-06-16_15-27-30.png
Screenshot_2022-06-16_15-27-30.png
  16966   Thu Jun 30 19:04:55 2022 ranaSummaryPSLPSL HEPA: How what when why

For the PSL HEPA, we wanted it to remain at full speed during the vent, when anyone is working on the PSL, or when there is a lot of dust due to outside conditions or cleaning in the lab.

For NORMAL conditions, the policy is to turn it to 30% for some flow, but low noise.

I think we ought to lock one of the arms on IR PDH and change the HEPA flow settings and plot the arm error signal, and transmitted power for each flow speed to see what's important. Record the times of each setting so that we can make a specgram later

  17047   Fri Jul 29 20:21:11 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

MCAutolocker/FSSSlow are not properly documented and not properly working.
Tidy up the script and documentation, or bring it back to megatron


I was aware that the FSSSlow was misbehaving since the shutdown upon the July power outage.
- FSS Slow servo did nothing even though the apparent settings in C1:PSL_SLOW screen looked fine and heart beat blinking
- Wanted to restart FSSSlow at megatron. Despite the login message showing how to do it, the system service does not exist anymore, because it was moved somewhere.
- Searched 40m wiki but found no info how to kill and restart it
- Found an elog. It was moved to docker on optimus ELOG 16480 . The restart procedure can only be found here. Please fix all the documentation inconsistency >> Anchal

According to this elog, the following commands need to be run for starting up MCAutolocker and FSSSlow on optimus:

cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
sudo docker-compose up -d

- Problem continues. Now FSSSlow is running but only when the IMC is locked. It does not stop even when the IMC lock is lost. How can we debug docker thing?
- This is minor but the MCAutolocker log (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log) is no longer updated even though MCAutolocker is running. Was it moved somewhere?

 

  17049   Sat Jul 30 10:38:12 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDLocker.py

and uses a configuration file

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDConfigFSS.yml

The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.

 


docker instructions:

The following message is displayed on login in optimus:

-------------------------------------------------------------------------
This computer runs four services as of Feb 18, 2022 for 40m lab. To check
status of these services, type
> sudo docker ps
For restarting a particular service, type:
> sudo docker restart container_name
where container name can be found from ps command above.
Fimilarly, to check status of a service, type:
> sudo docker logs container_name

In case, you have just rebooted the machine, to start these services do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose up -d
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose up -d

To stop the docker services completely, for example before a reboot, do
following:
> cd /opt/rtcds/caltech/c1/Git/40m/scripts
> sudo docker-compose down
> cd /opt/rtcds/caltech/c1/Git/40m/softchansmodbus
> sudo docker-compose down

This should remove all active containers from the computer.

To check IP address of running containers, type:
> sudo docker inspect -f '|| {{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}   ||   {{.Name}} ||' $(sudo docker ps -aq)

The softchansmodbus directory runs modbusEPICS docker image to host some
useful soft EPICS channels. The scripts directory runs pyep docker
image to run MC autolocker, PMC autolocker and FSS PID locker.
-------------------------------------------------------------------------

For checking log files of autolocker script, on optimus do:

sudo docker logs scritps_AL_MC_1

For checking log files of FSS PID loop, on optimus do:

sudo docker logs scripts_PID_

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.


Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

sudo docker stop container_name

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

sudo docker restart container_name

I'll add this procedure to a wiki page as well.


Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

sudo systemctl enable FSSSlow
sudo systemctl restart FSSSlow

For MC autolocker:

sudo systemctl enable MCautolocker
sudo systemctl restart MCautolocker

For diabling these services again, do:

sudo systemctl stop FSSSlow
sudo systemctl disable FSSSlow
sudo systemctl stop MCautolocker
sudo systemctl disable MCautolocker

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

  17050   Sat Jul 30 12:48:18 2022 KojiUpdatePSLFSSSlow/MCAutolocker issue (docker)

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

  17057   Thu Aug 4 11:28:22 2022 AnchalUpdatePSLFSSSlow/MCAutolocker issue (docker)

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

  17065   Mon Aug 8 14:47:10 2022 ranaUpdatePSLFSSSlow/MCAutolocker issue (docker)

can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.

Quote:

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

 

  113   Fri Nov 16 18:46:49 2007 steveBureaucracyPSL MOPA was turned off & on
The "Mohana" boys scouts and their parents visited the 40m lab today.
The laser was turned off for their safety.
It is back on !
  2951   Wed May 19 14:36:46 2010 AidanHowToPhase CameraPhase Camera algorithm and stuff

 I had a think about the algorithm we might use for the phase camera measurement. MATLAB has an fft function that will allow us to extract the data that we need with a single command.

We record a series of images from a camera and put them into a 3D array or movie, image_arr, where the array parameters are [x-position, y-position, time], i.e. a 2D slice is a single frame from the camera. Then we can do an FFT on that object with the syntax, f3D = fft(image_arr, [ ], 3), which only does the FFT on the temporal components. The resulting object is a 3D array where each 2D slice is an 2D array of amplitude and phase information across the image for a single temporal frequency of the movie.

So if we recorded a movie for 1s where the sample rate is 58Hz, then the 1st frame of f3D is just a DC image of the movie, the 2nd frame are the complex 1Hz components of the movie, etc all the way up to 29Hz. 

Suppose then that we have a image, part of which is being modulated, e.g. a chopper wheel rotating at 20 or 24Hz, or a laser beam profile which contains a 1kHz beat between a sideband and a reference beam. All we have to do is sample at at least twice that modulation frequency, run the command in MATLAB, and then we immediately get an image which contains the phase and magnitude information that we're interested in (in the appropriate 2D slice o the FFT).

As an example, I recorded 58 frames of data from a camera, sampling at 58Hz, which was looking at a spinning chopper wheel. There was a white sheet of paper behind the wheel which was illuminated from behind by a flashlight. The outer ring was chopping at 24Hz and the inner ring was chopping at 20Hz. I stuck all the images into the 3D array in MATLAB, did the transformation and picked out the DC, 20Hz and 24Hz signals. The results are shown in the attached PDFs which are:

  1. phase_camera_DC_comp.pdf - a single image from the camera and the DC component (zoomed in) of the FFT
  2. phase_camera_F1_comp.pdf - the magnitude and phase information of the 20Hz component of the FFT
  3. phase_camera_F2_comp.pdf - the magnitude and phase information of the 24Hz component of the FFT (this PDF contains a typo that says 25Hz).
  4. load_raw_data.m - the MATLAB routine that loads the saved data from the camera and does the FFT

You can, and I have, run the MATLAB engine from C directly. This will allow you to transfer the data from the camera to MATLAB directly in memory, rather than via the disk, but it does need proper memory allocation to avoid segmentation faults - that was too frustrating for me in the short term. In this case, the 58 frames were recorded to a file as a contiguous block of data which I then loaded into MATLAB, so it was slower than it might've otherwise been. Also the computer I was running this on was a bit of a clunker so it took a bit of time to do the FFT.

The data rate from the camera was 58fps x (1024 x 1024) pixels per frame x 2 bytes per pixel = 116MB per second. If we were to use this technique in a LIGO phase camera, where we want to measure a modulation which is around 1kHz, then we'd need a sample rate of at least 2kHz, so we're looking at at least a 30x reduction in the resolution. This is okay though - the original phase camera had only ~4000 spatial samples. So we could use, for instance, the Dalsa Falcon VGA300 HG which can give 2000 frames per second when the region of interest is limited to 64 pixels high.

Attachment 1: phase_camera_DC_comp.pdf
phase_camera_DC_comp.pdf
Attachment 2: phase_camera_F1_comp.pdf
phase_camera_F1_comp.pdf
Attachment 3: phase_camera_F2_comp.pdf
phase_camera_F2_comp.pdf
Attachment 4: load_raw_data.m
% load a raw data file into MATLAB

fid = fopen('phase_camera_data.dat');
n1 = 750;
A3D = ones(n1, n1, 58);

for jj = 1:58
    A = fread(fid, [1024, 1024], 'uint16');
    A3D(:,:,jj) = A((512-floor(n1/2)):(512-floor(n1/2))+n1-1, ...
                    (512-floor(n1/2)):(512-floor(n1/2))+n1-1);
... 64 more lines ...
  2955   Thu May 20 10:06:56 2010 AidanHowToPhase CameraPhase Camera- raw data video


 

  3096   Tue Jun 22 09:45:21 2010 Aidan, Joe, RazibUpdatePhase CameraCurrent phase camera setup. Seeing Acoustic beat

 We've set up a preliminary test bed for the phase camera. It simply uses a HeNe that is split into two beams. One is frequency shifted by an AOM by -40 MHz - df, where df is some acoustic frequency. The second beam is transmitted through a 40MHz EOM to get sidebands. The two beams are recombined and are, currently, incident on a photodetector, but this can be replaced by the phasecamera.

We turned everything on with df = 1kHz and confirmed that a 1kHz signal is visible on the output from the photodetector (PD). The signal looks to be about 1:300 of the DC level from the PD.

Attachment 1: 2010-06-22_Phase_camera_layout_version_1.pdf
2010-06-22_Phase_camera_layout_version_1.pdf
  3097   Tue Jun 22 13:38:13 2010 KojiUpdatePhase CameraCurrent phase camera setup. Seeing Acoustic beat

1. In terms of the AOM:

How much beam power is incident on the AOM? How much is the deflection efficiency?
i.e. How much is the power lost by the crystal, deflected in the 1st order, and remaining in the oth order?

I am curious because I assume the AOM (which vender?) is designed for 1064nm and the setup uses 632nm.

2. In terms of the EOM:

How much sidebands do you expect to have?

I assume the EOM is designed for 1064nm, the only difference is the coating at the end. Is this right? 

3. Beating

How much beating strength do you expect?

Is your beating level as expected?

How much is the contrast between the PM sideband and the frequency shifted carrier?
This must include the consideration on the presence of the carrier and the other sidebands.

Quote:

 We've set up a preliminary test bed for the phase camera. It simply uses a HeNe that is split into two beams. One is frequency shifted by an AOM by -40 MHz - df, where df is some acoustic frequency. The second beam is transmitted through a 40MHz EOM to get sidebands. The two beams are recombined and are, currently, incident on a photodetector, but this can be replaced by the phasecamera.

We turned everything on with df = 1kHz and confirmed that a 1kHz signal is visible on the output from the photodetector (PD). The signal looks to be about 1:300 of the DC level from the PD.

 

  3102   Wed Jun 23 12:28:34 2010 RazibSummaryPhase CameraWeeekly Summary

This past week I have completed the following tasks:

 

1. Built a trigger and power box for the camera GC 750M (06058) and took some test images to see whether the trigger box really works. Result: It is doing fine!

2. Went over the setup that is already sitting on the table. Ref: Aidan's elog entry

3. Attended seminars and talks given by Alan, Jahms, Koji and Rana.

4. Attended the mandatory laser safety training by Peter.

 

Expected task for this week (could be more):

1. Work out analytical expressions of the power of the carrier and sidebands going to the camera in the setup. (As suggested by Rana and Joe)

2. Work on producing beat signal to the camera using the He-Ne laser setup.

3. Move,if possible, to the Nd:YAG setup.

4. Go over the codes and paper by the past SURFers on the phase camera experiment.

 

trigger-box_circuit.png

 


 

Attachment 2: test1.png
test1.png
  3146   Wed Jun 30 12:20:49 2010 RazibUpdatePhase CameraWeekly update

This week I have completed following tasks:

1. Worked out the analytical expressions for the amount of power of the DC and oscillatory part going into the camera.

2. Realigned the He-Ne PhaseCam setup as we had to replace the first steering mirror after the laser with a silvered mirror ( one without a dielectric coating for 1064 nm).

3. Gone through the code written by a previous surfer (Zach Cummings).

4. Read the paper 'Real-time phase-front detector for heterodyne interferometers'- F. Cervantes et. el. where they talk about constructing a phase detector for LISA pathfinder mission. One interesting fact I found was that, they used InGaAs chip for their CCD Cam which has a amazing QE of 80% @ 1064 nm. Unfortunately, the one we are using (Micro MT9V022 CMOS) has only ~5% QE for 1064 nm and 50% for 633 nm. One top of it MT9V022 has a built-in infra-red filter infront of it to make it more insenstive to 1064. In such limitations, we may have to find a work-around for this issue. Any idea?

5. Read about the EOM and AOM and their vibrating (!) way to add on and alter the incident light on them. (Source: Intro to Optical Electronics-Yariv)

 

One task that we couldn't accomplish even though I planned on doing is:

1. Move,if possible, to the Nd:YAG setup.

 

Task for this week:

1. Produce breathtaking calibration of the camera at He-Ne setup.

2. Read 'Fringe Analysis'-Y.Surrel and 'Phase Lock Technique'-Gardner.

3. Modify the phasecam code.

4. Produce an alternate triggerbox using diodes instead of Op-Amp as op-amp is suspected to fail at some point driving the camera due to impedance mismatch.

5. Answer Koji's question at Aidan's ELOG .

  3167   Wed Jul 7 12:17:36 2010 RazibUpdatePhase CameraWeekly update

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

DC_1Hz_beat_sig.jpgDC_5Hz_beat_sig.jpg

Attachment 1: DC_1Hz_beat_sig.jpg
DC_1Hz_beat_sig.jpg
  3187   Fri Jul 9 12:07:26 2010 RazibUpdatePhase CameraWeekly update

Here are some more details about the current phasecam setup. We are using a He-Ne laser setup

phase_cam_setup_09_08_10.jpg

A crude snap shot of the setup....

mod_setup_(copy)_annotated.jpg

 

We sent light through SM2 (Steering Mirror 2)  to BS1(Beam-Splitter 1) where the laser light is split into two parts, one going to the AOM and the other to the EOM. The EOM adds 40 MHz sidebands to the incoming carrier light after SM3, and the AOM shifts the frequency of the incident light on it to 40.000 005 MHz. The purpose for doing this juggling is to intentionally create a beat signal off the reference beam from the AOM with the sidebands added at the EOM. Note that, we are driving the AOM at 7dBm and the EOM at 13 dBm with 0 (nil) modulation. The two lights are combined at the BS2 and sent off through SM5 to the camera. The CMOS of the camera contains silicon based Micro MT9V022 chip which has a quantum efficiency of 50% at 633 nm. Thus we expected a fairly good response to this He-Ne setup from the camera. 

Using a trigger circuit, we triggered the camera at 20 Hz by sending a 20Hz sinusoidal signal to it. The trigger circuit converts this to a positive square waves. Then I roughly figured out the optimum exposure time for the camera before the DC levels saturates it by writing a code for taking a series of 25 images at different exposure time. I found that 500µs seems to be a reasonable exposure time. So, using this data, I took 20 consecutive images and sent them through a short Fourier Transform segment using Matlab to see the beat signal. Note that the DC component from these processing of the images have some fringe pattern which is due to the ND 2.5 filter that we were using to reduce the light power incident on the camera. The FT method also gave us the presence of the beat signal at the corresponding bin of the FT (for example: for 5Hz beat signal, I got the DC at bin 1 of the FT and 5Hz component at bin 6 as expected). Then I changed the AOM driving frequency to 40.000 001 MHz in order to see a 1 Hz beat signal. The results for both is in my previous post. 

Quote:

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

DC_1Hz_beat_sig.jpgDC_5Hz_beat_sig.jpg

 

  3213   Wed Jul 14 10:00:14 2010 josephbUpdatePhase CameraWork near 1Y2 yesterday

Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera.  This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).

Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc).  This equipment output a DC voltage proportional to the amplitude of the RF signals.  The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc.  These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system).  The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.

We simply chose one, the 33 MHz channel in this case, and connected.  At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping.  The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection.  We were able to restore the watchdog and confirm that the optic started to settle down again.  Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.

  3215   Wed Jul 14 11:51:48 2010 RazibUpdatePhase CameraWork near 1Y2 yesterday

Quote:

Razib and I were attempting to get the output of a photodiode (PD55A in this case) recorded, so that we could independently measure the slow (~1-10 Hz) fluctuations of the light incident on the camera.  This would then allow us to subtract those fluctuations out, letting us get at the camera noise in the case with signal present (as opposed to just a dark noise measurement when we look at the noise with no signal present).

Originally I was thinking of using one empty patch panel BNCs used for PEM channels down by the 1Y7 rack and go through a 110B, although Alberto pointed out he had recently removed some monitoring equipment, which watched the amplitude modulation at various frequencies of the RF distribution (i.e. 33 MHz, etc).  This equipment output a DC voltage proportional to the amplitude of the RF signals.  The associated channel names were C1:IOO-RFAMPD_33MHZ, C1:IOO-RFAMPD_33MHZ_CAL, C1:IOO-RFAMPD_133MHZ, etc.  These are slow channels, so I presume they enter in via the slow computers, probably via pentek (I didn't check that, although in hindsight I probably should have taken the time to find exactly where they enter the system).  The connections them selves were a set of BNCs on the south side, half way up the 1Y2 rack.

We simply chose one, the 33 MHz channel in this case, and connected.  At around this time, the MC did become unlocked, although it looked like it was due to the MC2 watchdog tripping.  The initial theory was we had bumped the Mode Cleaner while looking around for some BNC cables, although from what Rana had to do last night, it probably was the connection.  We were able to restore the watchdog and confirm that the optic started to settle down again.  Unfortunately, I had to leave about 5 minutes later, and didn't do as thorough an investigation as was warranted.

 Before I left, I disconnected the PD55, so the 33 MHz channel wasn't physically connected to anything!!! Only one end of the wire was connected to the rack while the other was free...

So it wasn't the PD connection that is responsible for MC tripping at the later time...

  3217   Wed Jul 14 12:12:03 2010 RazibSummaryPhase CameraWeekly update

This week I was mainly interested in investigating the noise source at the phase camera. So having this issue in mind, my activities are the following:

1. I worked on producing multiple beat signal (1Hz and 5Hz). Elog entry.

2. I altered the setup so that instead of triggering the camera from the signal generator, we are now triggering it from the beat signal from the reference beam and sideband.

3. I made the nice little aluminium table for all the amplifiers, mixer and splitters to sit at one place instead of floating around.

4. I talked with Aidan and Joe and verified my calculation and extended it to further investigation of the noise source in the setup.

 

Plan for the upcoming week:

1. Measure and calibrate the camera w.r.t the power incident on it.

2. Investigate the noise source.

  3221   Wed Jul 14 18:09:50 2010 josephb, razibUpdatePhase CameraSome cleanup behind 1Y2 rack of phasecamera electronics

We made an attempt at cleaning up the phase camera setup electronics.

We have moved a portion of the electronics onto the SP table (specifically the mixer, splitters, amplifiers, and associated power).  We put away a large number of cables which were unneeded, both BNC and power cables. The Innolight Mephisto power supply and one signal generator are still behind 1Y2 on top of a non-functioning VME crate.  The second VME crate was put along the south arm where two other VME crates already were.  We placed a fair number of BNC cables and power cords back on their cable racks or approriate storage space, so the rats nests of cables has been reduced.

We moved one power strip from plugging in beyind 1Y1, to the far side of the SP table (closer to the 1Y3 rack), and also found and plugged in another power strip (also on the far side of the SP table) and placed this underneath the SP table to be able to power the signal generator and Innolight Mephisto laser (its not plugged in currently, but we'd like to do so next week).

 

  3258   Wed Jul 21 12:20:58 2010 RazibUpdatePhase CameraWeekly update

This past week I have worked on the following:

1. Setting up the infrastructure to do noise analysis: We added a temporary channel on the DAQ to connect to the PD 55 which we are using to take the power measurement. Before that, I connected the PD55 to an oscilloscope and recorded the power.

    phase_cam_setup_21_07_2010.jpg

The power at PD55 as measured using the oscilloscope = 600 µV.

Then I tried to calibrate the channel by sending up a signal from the function generator and measuring up the offset.. However, the channels seems noisy enough, especially due to electronics noise as suggested by the measurements and FFT calculation.

2. I worked on trying to sync the data acquisition of the PD and the CAM. After sometime spent on fiddling with the software method such as taking images at stamped time and then lining them up with the daq timestamps, I found a hardware method as suggested by Aidan. It was putting up a shutter (Uniblitz shutter and driver VMMD1) in the setup. I synced the shutter with the camera for which I had to tear apart the previously made trigger box and add a sync output from the camera (took a while as I also had to make a new cable).

3. I worked (still working) on making a differential amplifier to blow up the signal from the PD.

 

 

 

  3309   Wed Jul 28 13:06:47 2010 RazibUpdatePhase Camera 

Attached are some calculation that I did previously for the phasecamera setup. This shows the nature of the beat signal that we are measuring.

I am also trying to characterize the noise source of the camera also. Following images shows the mean dark noise (with no light on the camera) and the standard deviation for 100 snaps at an exposure time of 500 µs.

mean_100_snaps.pngstd_100_snaps.png

My target now is to measure the response gain of each pixel and how they vary over intensity. I already have a simplified setup on the table and will work on it today. Details will follow at the end of the day.

Attachment 3: phase_cam_calc.pdf
phase_cam_calc.pdf phase_cam_calc.pdf phase_cam_calc.pdf
  3360   Wed Aug 4 16:52:59 2010 Razib, AidanUpdatePhase CameraSideband power measurement (updated)

Aidan and I made some attempt to measure the power of the sidebands so that we can calculate our expected signal strength.

Our setup looks like the following:

Setup_08_04_2010.jpg

 

As light from the laser is split into two at BS1, the transmitted beam has higher power as our BS1 is only coated for 1064nm. We get two reflected beams from BS1, one reflected of the front surface and the other from the back surface. We took the stronger back reflected beam to the EOM driven at 40 MHz (also at 25 MHz at  a later time). The AOM produced a reference beam with 40 .000 005 MHz offset which we recombined with the sidebands obtained from the EOM. The beat produced is sent off to PDA 10CF connected to 4395A spectrum analyzer.

The plots for 40MHz sidebands and 25 MHz sidebands looks like this:

power_40MHz.png

From the above spectra, at 40 MHz sideband regime:

Power of the carrier @ 40 MHz = -39.72 dBm

Power of the sideband @ 80 MHz = -60.39 dBm

 

 

power_25MHz.png

At 25 MHz sideband regime,

Power of the carrier @ 40 MHz = -40.22 dBm

Power of the upper sideband @ 65 MHz = -61.72 dBm

Power of the lower sideband @ 15 MHz = -60.99 dBm

 

Power Measurement:

We made some necessary power measurement using a PD connected to a voltmeter after the EOM and the AOM when the EOM is driven at 40 MHz:

___________________________________________________________

Dark :  0.025 V

AOM on: 4.10 V    (EOM blocked)

EOM : 2.425 V      (AOM blocked)

___________________________________________________________

 From the earlier calculation (ref: Elog entry July 28) the power that we expect to see at the PD is,

P= A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 +2* A_r* A_sb * cos ( w_(r,sb) t ) ,                         where A_c= carrier;   A_r= reference beam;     A_sb=Upper sideband;    A_(-sb)= Lower sideband,     w_(r,sb) = w_r - w_sb

P = A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 +2* A_r* A_sb  , letting cos (w_(r,sb) go to 1) is order to approximate the maximum signal

So the signal that we expect to see relative to the DC ( i.e    A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2,    the first four terms of the power equation) is,

Sig = 2* A_r* A_sb    / { A_c ^2 + A_r^2 + A_(-sb)^2+ A_sb ^2 },

Since the modulation index is small, the power in the sideband is very small compared to carrier and the reference beam. So we can ignore the sideband power for the signal expression.

So,

Sig = 2* A_r* A_sb  /  ( A_c ^2 + A_r^2 )

So if we want to maximize this signal w.r.t the reference then,

d (sig)/ d(A_r) = 2 { ( A_c ^2  - A_r^2) *A_sb } / {( A_c^2 + A_r^2)} ^2

Thus, the signal is maximized when,

A_r^2 = A_c^2

 

We adjusted the AOM to be driven at + 7.7 dBM so that the new power at the AOM matched the EOM power, which is 2.397 in the voltmeter.

So the power at both the AOM and the EOM are:

P_AOM = ( V_AOM - V_dark) / (PD responsitivity * Transimpedance gain)

               = ( 2.397 - 0.025 ) / ( 0.45  * 1.5 x 10 ^5 )

               = 3.51 x 10 ^ - 5  W

P_EOM = (V_EOM - V _dark) / (PD responsitivity * Transimpedance gain)

               = ( 2. 425 - .0.025) / ( 0.45 * 1.5 x 10 ^5 )

               = 3.55 x 10^ - 5  W

 

From the spectra of the 40 MHz sideband above, the ratio of the carrier and the sideband amplitude is:  A_c / A_sb = 10.8 .

P_EOM = A_c ^2 + 2 A_sb ^2

Therefore, A_sb = sqrt ( P_EOM / 118.64) = 5.47 x 10^ - 4   V/m

Thus,     A_c = 5.908 x 10^ -3   V/m

and    A_r = sqrt ( P_AOM) = 5.92 x 10 -3    V/m.

 

This measurement can be used to calculate the signal to contrast ratio (SCR) that we expect to see:

SCR = 2 A_r * A_sb  / ( A_c^2  + A_r^2 )  = 0.09

 

Our next step is to measure the actual signal to constrast ratio as seen by the camera. Details of that will be posted soon.

  3411   Thu Aug 12 16:52:02 2010 RazibUpdatePhase CameraSideband power measurement (updated)

I made some measurement of the SCR (signal to contrast ratio) from the signal from the EOM and the AOM.

The recipe for that was:

1. Trigger the camera at 20 Hz (from function generator).

2. Take a series of 20 images.

3. Do FFT to take out the DC component.

4. Extract the beat signal out of the FFT'd data.

5. Block the EOM.

6. Take another set of images of the AOM beam.

7. Take more(!) images, but this time of the background (blocking both EOM and AOM).

 

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry.

The plot for that is:

SCR.jpg

 After measuring the SCR, I also measured the amplitude of the sideband and made an amplitude profile of the 40 MHz sideband.

The amplitude measurement is done as follows:

We know that the our 5 Hz signal consists of,

Sig = A_r * A_sb    where A_r = amplitude of the reference beam, A_sb= amplitude of the sideband

So, A_sb = Sig / A_r .

But,  A_r = sqrt ( P_AOM - Background),

Thus  A_sb = Sig / sqrt( P_AOM - Background) .

So the amplitude profile is done by taking the 5 Hz beat signal and dividing by the square root of the AOM beam minus the background light.

The plots looks like this:

DC_sig_sideband_profile.jpg

The solo sideband profile looks like this:

sideband_profile.jpg

Next we plan to trigger the camera with a 1 KHz signal and take snaps at n* T/4 (where n=0,1,2,3) of the period of the beat signal. So the plan is to trigger the camera at the point where the red dots appear in following cartoon.

sine_trig.jpg

Some more details of this setup will be posted later.

  

Quote:
 

 

Attachment 4: sine_trig.jpg
sine_trig.jpg
  3412   Thu Aug 12 17:10:07 2010 KojiUpdatePhase CameraSideband power measurement (updated)

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Ed: I meant time series of the PD output

Quote:

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 

 

  3413   Thu Aug 12 17:28:28 2010 RazibUpdatePhase CameraSideband power measurement (updated)

Quote:

This sounds very relieving although this could be a lower bound of the number.
Why didn't you use the output on the PD which just give us the direct observation of your so-called SCR.

Quote:

So the SCR is calculated by the ratio of the FFT'd DC and the 5 Hz signal. Using the CCD, I obtained the SCR to be 0.075 ± 0.01. Previously, we expected our SCR to be 0.09 as in the previous e-log entry. 

 

 The SCR was at first measured using the output of the PD. That was exactly from where we got our 0.09 (previous elog entry). The second measurement was from the CCD.

  50   Thu Nov 1 19:53:02 2007 Andrey RodionovBureaucracyPhotosTobin's picture
Attachment 1: DSC_0053.JPG
DSC_0053.JPG
  51   Thu Nov 1 19:53:34 2007 Andrey RodionovBureaucracyPhotosRobert's photo
Attachment 1: DSC_0068.JPG
DSC_0068.JPG
  52   Thu Nov 1 19:54:22 2007 Andrey RodionovBureaucracyPhotosRana's photo
Attachment 1: DSC_0120.JPG
DSC_0120.JPG
  53   Thu Nov 1 19:55:03 2007 Andrey RodionovBureaucracyPhotosAndrey's photo
Attachment 1: DSC_0055.JPG
DSC_0055.JPG
  54   Thu Nov 1 19:55:59 2007 Andrey RodionovBureaucracyPhotosAndrey, Tobin, Robert - photo
Attachment 1: DSC_0092.JPG
DSC_0092.JPG
  55   Thu Nov 1 19:58:07 2007 Andrey RodionovBureaucracyPhotosSteve and Tobin's picture
Attachment 1: DSC_0023.JPG
DSC_0023.JPG
  56   Thu Nov 1 20:03:00 2007 Andrey RodionovSummaryPhotosProcedure "Drop and Drag" in pictures
Attachment 1: DSC_0072.JPG
DSC_0072.JPG
Attachment 2: DSC_0083.JPG
DSC_0083.JPG
Attachment 3: DSC_0099.JPG
DSC_0099.JPG
Attachment 4: DSC_0100.JPG
DSC_0100.JPG
  210   Fri Dec 21 20:32:25 2007 tobinUpdatePhotosGigE camera
I couldn't resist any longer: I plugged in the Prosilica GC 750 GigE camera and took it for a spin. This is the little CMOS camera which sends out video over gigabit ethernet.

There were no difficulties at all in getting it running. I just plugged in the power, plugged in ethernet, and put on a lens from Steve's collection. I downloaded the "Sample Viewer" from the Prosilica website and it worked immediately.

It turns out that "Kirk's" computer has not only a gigabit ethernet card, but a little gigabit ethernet switch. I plugged the camera into this switch. The frame rate is amazing. With the camera under fluorescent lights I thought I saw some wacky automatic gain control, but I think this ~10Hz flicker is aliasing of the 60 Hz room lighting.

I put the camera on the PSL table briefly and tried viewing the image from a laptop over the (54mbs) wireless network. This didn't work so well: you could get a couple frames out of the camera, but then the client software would complain that it had lost communications. It appeared that scattered 1064nm light did show up brightly on the camera image. There is a green ethernet cable currently stashed on the roof of the PSL that appears unused. We can try mounting the gigE CMOS cable in place of one of the CCD video cameras.

I did not try the Linux software.

The camera is currently set up at Kirk's desk, using the cool little tripod Rana got from CyberGuys.

This camera looks very promising! Also, in the test image attached below, a very unusual condition has been documented.
Attachment 1: robs_desk.png
robs_desk.png
  243   Wed Jan 16 19:57:49 2008 tobinConfigurationPhotosISCT_EX
Here's a photo of the ISCT_EX table, for the purpose of planning our auxiliary laser arm locking scheme. Note the (undumped!) beam from the beamsplitter before QPDX (the leftmost gold-colored box); perhaps we could inject there.
Attachment 1: trx-annotated-small.jpg
trx-annotated-small.jpg
  413   Thu Apr 3 19:27:50 2008 AndreySummaryPhotosTour for prospective grad students
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
Rana_Lecturing.pdf Rana_Lecturing.pdf Rana_Lecturing.pdf Rana_Lecturing.pdf
  505   Thu May 29 16:49:49 2008 steveBureaucracyPhotosYoichi has arrived
Yoichi had his first 40m meeting. We welcomed him and Tobin, who is visiting, by sugar napoleons that
Bob made.
Attachment 1: yoichi.png
yoichi.png
Attachment 2: bobsn.png
bobsn.png
  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
P1020559.png
Attachment 2: P1020560.png
P1020560.png
  652   Wed Jul 9 15:04:22 2008 steveMetaphysicsPhotosSURFs helping hands
Surf students are helping out with baffle cleaning.
Attachment 1: surfjob.png
surfjob.png
  792   Mon Aug 4 16:20:20 2008 DmassConfigurationPhotosITMX magnet position relative to OSEMS
We have vented, and taken the following pics of the magnets to document their position before we ruin everything.
Attachment 1: DSC_0151.JPG
DSC_0151.JPG
Attachment 2: DSC_0150.JPG
DSC_0150.JPG
  819   Sun Aug 10 16:57:02 2008 ranaSummaryPhotosPhotos from Vent 8/4 - 8/8
http://www.ligo.caltech.edu/~rana/40m/VentAug08/

I've added the D40 pictures from last week to this web page. I have done some cropping and
rotating to make things look better.

On page 3, there are some over head shots of the Michelson area so that one can use screw holes
to judge what the spacing between the suspensions is and also possibly the cavity lengths. Lets
also remember to measure the ITM-BS distance accurately using a tape measure or ruler while we
have the thing open.
  1094   Mon Oct 27 11:23:10 2008 steveUpdatePhotosnew Olympus camera with IR vision
The IR blocker was removed from our new Olympus camera
SP 570UZ camera.
It has image stabilization, zoom 26-520 mm (20x optical)
and 10.7 Mpixel
Attachment 1: IRisin.JPG
IRisin.JPG
  1717   Tue Jul 7 15:08:49 2009 KojiSummaryPhotos40 high school students visited 40M

Alan and Alberto conducted a tour of 40 high-school students.
It may be the same tour that Rana found a spare PMC during the tour explanation as far as I remember...

Attachment 1: IMG_1848.jpg
IMG_1848.jpg
  1931   Thu Aug 20 09:16:32 2009 steveHowToPhotosControl Room Workstation desks lowered to human height

Quote:

There were no injuries...Now we need to get some new chairs.

 The control room desk tops heights on the east side were lowered by 127 mm

 

Attachment 1: P1040788.png
P1040788.png
Attachment 2: P1040782.png
P1040782.png
Attachment 3: P1040786.png
P1040786.png
Attachment 4: P1040789.png
P1040789.png
Attachment 5: P1040785.png
P1040785.png
ELOG V3.1.3-