Using the same methods as before, see below, I've added some Hartmann sensor EPICS channels to the frames.

The channels record the Hartmann sensor Probe (and Secondary) Coefficients of the Seidel aberrations (PSC, SSC) that are specified (PRISM, ALPHA, PHI, etc).

1. Created /cvs/cds/caltech/chans/daq/C4HWS.ini with the attached contents.
2. Added a line to /cvs/cds/caltech/target/fb1/master to load C4HWS.ini
3. restarted the frame builder by killing daqd

[default]
dcuid=4
datarate=16
gain=1.0
acquire=1
ifoid=0
datatype=4
slope=1.0
offset=0
units=NONE


[C4:TCS-HWSX_PSC_PRISM]
[C4:TCS-HWSX_PSC_ALPHA]
[C4:TCS-HWSX_PSC_PHI]
[C4:TCS-HWSX_PSC_CYLINDRICAL_PO]
[C4:TCS-HWSX_PSC_SPHERICAL_POWE]
[C4:TCS-HWSX_PSC_COMA]
[C4:TCS-HWSX_PSC_BETA]
[C4:TCS-HWSX_PSC_SPHERICAL_ABER]
[C4:TCS-HWSX_SSC_PRISM]
[C4:TCS-HWSX_SSC_ALPHA]
[C4:TCS-HWSX_SSC_PHI]
[C4:TCS-HWSX_SSC_CYLINDRICAL_PO]
[C4:TCS-HWSX_SSC_SPHERICAL_POWE]
[C4:TCS-HWSX_SSC_COMA]
[C4:TCS-HWSX_SSC_BETA]
[C4:TCS-HWSX_SSC_SPHERICAL_ABER]

Here are the notes from today's efforts:

- When you 'Run_HWS' in MATLAB and the camera has not been initialized, it says the camera is not accessible. Either that or you need to run 'sudo matlab' (no, sudo doesn't help)

- In Ubuntu have to run '/opt/EDTpdv/initcam -f ~/dalsa_1m60.cfg' to start the camera

- Now have to install MCA

- MCA installed by is crashing MATLAB - not sure why. Maybe its a 'sudo' problem again?
- sudo matlab has the following problem:
mca
??? Invalid MEX-file
'/home/controls/base-3-14-11/extensions/lib/linux-x86_64/mca.mexa64':
libdbStaticHost.so.3.14: cannot open shared object file: No such file or
directory.
 
- adjusting Makefile for MCA to include the correct suffix for a Linux based MEX file ('mexa64', not 'mexglnx') gets the program to compile correctly and then MATLAB runs MCA fine.


- Running 'Run_HWS' with EPICS running but no channels crashes the program

- copy the HWS.db file to the EPICS db location

- cannot create the matlab images folder when the program runs.
- created these manually
- program is trying to adjust the maximum pixel count - it is failing and the camera is complaining (intensity is quite low right now)
- why exposure mode 6? - requires an external SYNC signal
- can't handle low exposure - FIX THIS!!
- why is the expsoure time increased in stepwise fashion? Use algorithm!
      - Commenting this out!!
    - same for the secondary beam
- After running State 1 it asks to continue to State 2 - if you select 'n' the program crashes

- steered beam properly onto HWS
-----------
- continue to State 2 - 'yes' crashes the program
- HS_report is doesn't work
- commented out lines 37 to 47

- get rid of constant requests to continue [run_acquire_auto.m]
- change names of EPICS variables [done]
- add an RMS variable
- the named EPICS variables need to be dynamically named rather than statically named.


--------
run_acquire_auto.m CHANGES
0. Update sensor date: mres = 'y'
1. pres = 'n'; - don't update reference centroids
2. sres = 'n'; - don't update secondary reference centroids
3. select probe beam commented out
4. select secondary beam commented out
5. State 2B - select probe live commented out
6. set user_response = 'y' for continue

A1 - added a loopcounter that starts at zero. the first loop includes user prompts and then they're bypassed in subsequent loops.

-----------

-Seidel aberration fitting seems wrong - not resembling the integrated field
- get rid of the constant pop ups
- have a network license EPICS variable
- how many images are used for reference image?
    - added a variable in run_acquire_auto.m :
        - no_of_cim_ref = 200; (no_of_cim = 5 images was previous)
    - changed the averaging in reference image acquisition from
        - "no_of_cim" to "no_of_cim_ref"
    - didn't change the take command from 5 to 200 images
- commented out lines 239-242 in run_initialize - gives a second way to start run_acquire.m
- probe and secondary beams share the probe background - deliberate?
- average all the images and save as a single matlab 16-bit array
- what is the rms noise as a function of the reference image number of averages?


------
Changing the EPICS variable names.
1. HS_WF - where Seidel coefficients are named.
    - in function seidel_from
2. changed the following lines in 'run_acquire_auto.m'
        %channelname = ['probe-seidel-',fn{counter}];
            channelname = ['C4:TCS-HWSX_PSC_', fn{counter}];

        %channelname = ['secondary-seidel-',fn{counter}];
            channelname = ['C4:TCS-HWSX_SSC_', fn{counter}];
3. ammended the following code in 'run_acquire_auto.m'

    maxEPICSLength = 14;
    for counter = 1:length(fn)
        %channelname = ['probe-seidel-',fn{counter}];
        strname = upper(fn{counter});
        if (numel(strname) > maxEPICSLength)
            strname = strname(1:maxEPICSLength);
        end     
        channelname = ['C4:TCS-HWSX_PSC_', strname];
        probe_seidel_array{counter} = HS_EPICS(channelname);
    end
-----
- bug: on restarting and pressing 'space' and enter at approximately the same times here, the program crashed:

Is it okay to assign one of the already existing handle (y or n)? y
Assigned handle 2 to the instance.
Established the connection to the channel secondary_shutter_open.

hsep_secondary =

  HS_EPICS handle

  Properties:
         channelname: 'secondary_shutter_open'
             handler: 2
    EPICS_is_running: 1

  Methods, Events, Superclasses

Please select the probe beam as the light source. Hit any key to continue.

??? Error using ==> textscan
First input can not be empty.

Error in ==> HS_Camera>HS_Camera.get_exposure_time at 942
        ccet = textscan(ccet,'%f %s');

-----------------

Added the following lines to HWS.db

record(ai, "C4:TCS-HWSX_PSC_PRISM")
record(ai, "C4:TCS-HWSX_PSC_ALPHA")
record(ai, "C4:TCS-HWSX_PSC_PHI")
record(ai, "C4:TCS-HWSX_PSC_CYLINDRICAL_PO")
record(ai, "C4:TCS-HWSX_PSC_SPHERICAL_POWE")
record(ai, "C4:TCS-HWSX_PSC_COMA")
record(ai, "C4:TCS-HWSX_PSC_BETA")
record(ai, "C4:TCS-HWSX_PSC_SPHERICAL_ABER")
record(ai, "C4:TCS-HWSX_SSC_PRISM")
record(ai, "C4:TCS-HWSX_SSC_ALPHA")
record(ai, "C4:TCS-HWSX_SSC_PHI")
record(ai, "C4:TCS-HWSX_SSC_CYLINDRICAL_PO")
record(ai, "C4:TCS-HWSX_SSC_SPHERICAL_POWE")
record(ai, "C4:TCS-HWSX_SSC_COMA")
record(ai, "C4:TCS-HWSX_SSC_BETA")
record(ai, "C4:TCS-HWSX_SSC_SPHERICAL_ABER")

- restarting IOC with C4:TCS-HWSX channels

-------------

-time to add these to the frames



 

Using some of the old data from James (attached below), I calculated the CCD conversion efficiency (CE) from electrons to bits (Counts).

Number of electrons(Ne) = QE*Number of Photons(Np)

noiseE = sqrt(Ne);

Number of Counts (NCo)= CE*Ne

Noise in Counts (noiseCo)= CE*sqrt(Ne)

noiseCo = sqrt(CE * NCo)

log(CE) = 2*noiseCo - NCo

Therefore CE = 10.0^(2*noiseCo - NCo)

From James's data on the intensity noise in the CCD, CE = 0.0269

Quote:

Using this function, I did the same analysis of the upper-left 200x200 pixels over all 200 images: (data from 200 images, over the upper-left 200x200 pixels)

Steve and I measured the current drawn by the Dalsa 1M60 by connecting it to the BK Precision 1735 lab power supply that display current and voltage supplied. We tried the camera at a variety of different voltages. The results are presented below:

Voltage  Current(t<5s)  Current(5s<t<10s)   Current(t>10s)

12.7V       0.6A              0.8A              1.11A

15.0V       0.55A             0.69A             0.91A

18.0V       0.41A             0.57A             0.75A

20.0V       0.42A             0.52A             0.67A

Additionally, we tried running the other camera with the lab power supply. I varied the exposure mode and exposure time and checked the current drawn. The supplied voltage was 18.0V.

Exposure Mode 4: current = 0.67A

Exposure Mode 2: 58Hz, exposure time = 16 ms, current = 0.70A

Exposure Mode 2: 58Hz, exposure time = 100 us, current = 0.72A

Exposure Mode 2: 1Hz, exposure time = 998 ms, current = 0.68A

Exposure Mode 2: 1Hz, exposure time = 16 us, gm 0, current = 0.69A

Exposure Mode 2: 1Hz, exposure time = 16 us, gm 2, current = 0.69A

We have been investigating how pixel count is related to the centroid displacements by taking several sets of image frames with different camera
exposure time and input current.

It appears that the reason why rms value did not drop as fast as it should (as the number of averaged image frames increases) is that the pixel counts were too high.

As was previously done, we took 5000 images for rms analysis, and the reference set of centroids were generated from averaging 4000 sets of centroids using first 2000 and last 2000 images. Once a set of centroids for each image frame is obtained and saved (it took about 30 minutes to obtain centroids of 5000 image frames), rms analysis could be done in seconds.

(Alternatively, one could average the images first then find centroids, but this is much slower and the rms values do not change much.)

First figure is the log plot of rms versus N_av (number of image frames that are averaged over), where the maximum pixel count was about 2000.

Blue line is the calculated rms values, red line is the linear fit of the rms values, and black line is the line of the ideal slope -0.5. The rms values are in pixel units. The slope of the linear fit is -0.487. 

Centroids are obtained from the images taken with the exposure time of 23ms, the value of the current driving light source 28 mA, and the distance between the CCD and the light source was about 50 cm. 


 

Second figure is the plot using images whose max pixel counts were about 2700 (30ms exposure, same current): this gave the fitted slope to be -0.07.

Next two figures are the plots of rms with the same image set (images with max pixel count of 2700), using 

1. centroids whose peak pixel counts are below 2048 (45 out of 904 centroids), and

2. centroids whose peak pixel counts are above 2047 (859 out of 904 centroids). 

Peak pixel counts were obtained from the first image frame. As pixel counts fluctuate between image frames, it would perhaps be better to use averaged images but the outcome will still be qualitatively the same.

These plots clearly show that centroids with high peak pixel counts are responsible for poor reproducibility of the centroids.

The reason why the value of 2048 was chosen to separate centroids is because the camera will have to use the 12th bit for pixel counts 2048 or above.

I need to do more analysis to determine conclusively if the 12th bit is indeed responsible. What is clear at this point is that, once peak pixel counts go over about 2000, the reproducibility of centroids worsens significantly.

:PS:

 
Further investigation revealed that, for the second centroids set (i.e., the centroids obtained from 30ms images) I discussed here, the decrease in centroids reproducibility is due to one spot whose position fluctuated much more wildly than others. That same spot does not cause problems in my first set with lower pixel counts. Here is the 2D plot of rms values of individual centroids fluctuations over image frames. I used griddata command to interpolate values between centroids to get this false color map;



The spot shown on the plot corresponds to the centroid located at the pixel (x,y) = (749,353). Its rms value with N_av = 1000 was 0.055 pixel uniits, which is more than ten times as big as average centroid displacements between two images (which is about 0.003).

Once you remove this centroid from the reference set and redo the analysis, the fitted slope goes back to -0.46.

 
Since I was wondering if high pixel counts worsens the reproducibility of the centroids, I also generated scatter plot of (1) rms vs peak pixel counts and (2) fitted slope for each centroid vs peak pixel counts (without removing the problematic centroid):

 

It is evident that one centroid is a huge outlier in rms vs pixel counts plot, but it is not so obvious in the plot of slopes vs pixel counts. Furthermore, there does not appear to be any correlation between pixel counts and the values of the fitted slopes. 

And here are the scatter plots after removing the problematic centroid:



which suggests that there is no real correlation between peak pixel counts of centroids and their values of rms or fitted slope. What is still happening, although, is that as we increase pixel counts by either increasing the camera exposure time or the intensity of the light source, the value of the fitted slope increases as well (hence decreases the reproducibility of centroids).

I will continue this discussion in my next post...

I've made the following changes to the Hartmann sensor code and to the machine running the HWS.

• Machine name is now princess_sparkle (10.0.1.26)

• I set up ntpd on that machine to sync the clock to GPS - roughly.
• I added a MATLAB function (store_current_centroids.m) to the Hartmann sensor that saves the centroids and peak intensities to file in GPS labeled files
• ~/Hartmann_Sensor_Data/centroids/<GPSTIME1>/<GPSTIME2>/<GPSTIME>_<name>.mat

GPSTIME1 = floor(GPSTIME/4E4)*4E4

GPSTIME2 = floor(GPSTIME/2E2)*2E2

I had to add a line in the run_acquire_auto.m script to accommodate this new function and I had to add a function that calculates the peak intensities to the HS_Centroids.m class.

The Hartmann sensor is running continuously and is now recording data to file. The formatting has changed slightly with the data now stored in structures called store_measurement every 200s in files in the following way:

• store_measurement(ii).centroids - the ii-th centroids
• store_measurement(ii).intensities - the ii-th intensity list
• store_measurement(ii).time - the time of the ii-th measurement

The files are stored in ~/Hartmann_Sensor_Data/centroids/<GPSTIME rounded to nearest 4E4 seconds>/<GPSTIME rounded to nearest 2E2 seconds>_<subname>.mat

We managed to successfully apply frame rate control via external trigger from a pulse generator.

We supplied 5V pulse train when connected to the optocoupler load, and connected to pins 1 and 2 of external trigger (on the frame grabber board) for using camera 0 (which is the case for us).

Then made the following changes to the config file dalsa_1m60.cfg;

MODE_CNTL_NORM: A0 (previously this value would have been 00)

user_timeout: 0    (this line should be added)

Then I saved the new config file as dalsa_1m60_et.cfg

Next, I loaded the new config using initcam command, then set the exposure mode to be 3. This can be done either using serial_cmd directly or using HS_Camera method set_exposure_mode.

In exposure mode 3, the exposure time is set by the time separation between the falling edges of the pulses, and the camera sets the expousure time to be the maximum value possible (as specified in the camera manual). 

Then I took 10 images using take command, and verified that the frame rate is equal to the frequency of the pulse. We tested 1 Hz and 2 Hz pulse trains, and the frame grabber recoded 1 frames per sec and 2 frames per sec respectively.

We could not yet test the frequency values < 1 Hz as pulse generator we used could not go under 1 Hz.

(EDIT)

We used another pulse generator to test pulse frequencies under 1 Hz, and verified that external trigger mode still works.
 

I've set up a quick experiment to modulate the angle of the Hartmann sensor probe beam at 10mHz and to monitor the measured prism. The beam from the SLED is collimated by a lens and this is incident on a galvo mirror. The reflection travels around 19" and is incident on the HWS. When the galvo mirror is sent a 1.1Vpp sine wave, then beam moves around +/- 0.5" on the surface of the Hartmann sensor, giving around 50mrad per Vpp.

The galvo is currently being sent a 0.02Vpp sine wave at 10mHz.

I changed the drive amplitude on the function generator to 0.05Vpp and have measured the angle of deflection by bouncing a laser off the laser mirror and projecting it 5.23m onto the wall. The total displacement of the spot was ~3.3mm +/- 0.4mm, so the amplitude of the angular signal is 1.6mm/5.23m ~ 3.1E-4 radians. The Hartmann Sensor should measure a prism of corresponding magnitude.

The frequency is still 10mHz.

 Here is a brief and preliminary summary of rms of centroid displacements calculated at a number of different exposure time values. To get the results I did the following for each value of exposure time:

1. Take a set of images. I took 2000 images for shorter exposure times, 1000 images with exposure times greater than 1 second, and 200 images with exposure time 4.4 second. I tried to keep the maximum pixel count to be roughly the same (about 2430 plus/minus 40).

2. Obtain the centroids for each image frames in a set. I saved centroids as an array of n by m by 2, where n is the number of image frames that I took, m is the number of centroids in each frame, and 2 for x and y coordinates.

Then I iterated through the centroid sets to calculate total rms, using various N_av values. If N_av = 100; then reference centroids were obtained by averaging the centroids of first 50 and the last 50 frames, and remaining 100 frames are averaged to get the other (or non-reference) centroids. I think this method gives a better view of the centroid reproducibility than fixing the number of reference centroids to be, say, first 1000 and last 1000 frames and varying the number of frames to be averaged for non-reference centroid.

Datasets of centroids are labelled as spcdet_I_t, where spcdet stands for "same (maximum) pixel count (with) differen exposure times", I the value of the current that drives the light source, and t the exposure time that I used.

Here are the plots:

It can be seen from these plots that the benefit of averaging multiple frames quickly diminish once we go over 1 second. I am investigating if there is any way to improve the reproducibility while using the same sets of images.

Issues that need further investigation:

  1. Effect of pixels with unusually high pixel count. Dark images that we took show that, with longer exposure times, not only overall dark noise increase (and become less uniform) but also several pixels show unusually high pixel count (even higher than 2000), without a light source on. More investigation is needed to determine how much this affects the centroids calculation and to devise an way to deal with it.

  2. Extra/Duplicate centroids. As exposure time increased, I observed that duplicate centroids start to appear, i.e., HS_Centroids##centroids had duplicate entries. The number of duplicate entries increased as exposure time increased. I believe this is due to the images getting noisier as exposure time increases. So After taking initial reference centroids, I removed duplicate centroid entries before calculating rms. I am thinking about adding a method to do this in HS_Centroids class.

In addition, there were one 'false' centroid when the exposure time was 4.4 seconds. For now I chose to manually remove it myself before calculating rms.

 I analyzed the results from the prism experiment. The time series and spectra of the prism are attached.

Conclusions to follow ...

I've set up an experiment to test the HWS intensity distribution displacement measurement code. Basically the beam from a SLED is just reflecting off a galvo mirror onto the HWS. The mirror is being fed a 0.02Vpp *10 gain, 10mHz sinewave from the function generator.

The experimental setup is shown below.

I hacked the HWS code to export the Gaussian X and Y centers to Seidel Alpha and Beta channels in EPICS (C4:TCS-HWSX_PSC_ALPHA, C4:TCS-HWSX_PSC_BETA)

 Given that the HWS requires several 2" optics to handle the big beam size, I've ordered the following items from Newport:

• 2x 2" 50/50 beam splitter: 20B20BS.2
• 6x 2" NIR mirrors: 5122
• 8x 2" Ultima mirror mounts: U200-A2K

I have spent some time with Matlab Compiler and Matlab Compiler Runtime (MCR). I could only get my hands on 2008b version so far, but I believe 2009b version will work in the same way.

Below is a set of notes based on my experience so far.

Matlab compiler installation

1. Copy the toolbox archive files to the folder where matlab is installed. To me this is /usr/matlab_2008b/ (may need to do as root or use sudo). Two files to be copied are tbx.compiler.common and tbx.compiler.glnxa64.

sudo cp tbx.compiler.* /usr/matlab_2008b/

2. Execute the install script.

cd /usr/matlab_2008b
sudo ./install

3. Enter the file installation key that came with the matlab compiler files.

4. Leave the root directory as it was.

5. Finish the installation by activating the toolbox with the license file.

Build a standalone application using matlab compiler

I created a folder called matlab_project as a place to put compiled applications, and matlab_predep as a place to put files to be deployed.

Once Matlab Compiler is installed, it can be launched from the matlab console by typing deploytool. Then I proceeded as below:

1. Create a new project by clicking the New icon (the first one from the left).

2. Choose a standalone application.

3. Click main file and Go to menu Project -> Add Files (or right_click on "main file" icon).

4. Choose the matlab file hello.m (in my case, from matlab_predep folder). hello.m could be, for example, a simple script like

function hello
     disp('Hello!');
end

5. Click the Build icon (third from the right).

When the process finishes, inside matlab_project folder I found a file called "hello.prj" and a folder called "hello". Insider the hello folder was two folders "distrib" and "src".

Install Matlab Compiler Runtime

1. Run MCRinstaller.bin as root. I found this file in the folder /usr/matlab_2008b/toolbox/compiler/deploy/glnxa64

2. Go along with the default options unless desired otherwise.

3. Add following to .bashrc, below the entries regarding EPICS. $LD_LIBRARY_PATH should now be aware of EPICS as well as MCR related paths. 

export MCR_ROOT=/opt/MATLAB/MATLAB_Compiler_Runtime
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$MCR_ROOT/v79/runtime/glnxa64:$MCR_ROOT/sys/os/glnxa64:$MCR_ROOT/v79/sys/java/jre/glnxa64/jre1.6.0/lib/amd64/native_threads:$MCR_ROOT/v79/sys/java/jre/glnxa64/jre1.6.0/lib/amd64/server:$MCR_ROOT/v79/sys/java/jre/glnxa64/jre1.6.0/lib/amd64
export XAPPLRESDIR=$MCR_ROOT/v79/X11/app-defaults

4. Run the revised .bashrc by typing 'source ~/.bashrc'. Next time the user logs in, doing this won't be necessary.

Run the built application

1. Go to distrib folder to find the executable application file (e.g., hello). You will also find the executable shell script (e.g., run_hello.sh), the role of which is basically to set up environment variables and run the application, in case the environment variables are not globally set up.

2. Once in that folder, run the application by simply typing ./ and its name (e.g., ./hello). If the library environment variable is set up as in the step 3 of "Install Matlab Compiler Runtime", the application will be run and you should see the hello message as the output.


Build an application that uses HS classes

I wrote a simple script test_HS.m that takes and saves 10 images using the camera, averages the images and finds centroids. Thus the script requires the class files HS_Base, HS_Camera, HS_Image, and HS_Centroids.

I added those four class files by right-clicking Other Files (found below Main function) then choosing Add File, then clicked the build icon.
 

 I changed the ownership of /opt/EDTpdv to controls with the command:

controls@princess_sparkle:/opt/EDTpdv$ sudo chown controls EDTpdv/

 From Won: (the zip file is also on the SVN /users/won/compiled_code/test_HS.zip)

Attached is test_HS.zip file, that contains

- test_HS.prj: project file created by Matlab Compiler. This file is not
 required to run the application but I included it just in case someone's
 insterested.

- test_HS folder contains two subfolders src and distrib, each of which
 contains the standalone application test_HS.

Usage: test_HS <path to the image folder>, for example

 test_HS ~/test_images/

Make sure you create the folder prior to running the application, and the
folder name ends with "/". Running test_HS will take and save 10 images
using the camera (provided the frame grabber applications are installed in
/opt/EDTpdv), averages those 10 images and find centroids, then plots the
result.

As I put in the eLOG, one needs MCRInstaller.bin and run it to install MCR
(probably 2008b 64bit version to test my files). If there are difficulties
getting MCRInstaller, let me know.

Won
<test_HS.zip>

Installing MCR

I located the MCRInstaller on our distribution of MATLAB on the Ubuntu machine (/MATLAB_R2009b/toolbox/compiler/deploy/glnxa64/MCRInstaller.bin). I ran the installer, as root,and followed the default options to install it. Next I updated the .bashrc file to include the necessary pointers to various libraries:

I've downloaded the test_HS binary from the SVN and added the ~/test_images/ directory as recommended by Won. I then ran the code by entering ./test_HS ~/test_images/

The code ran successfully through the serial_cmd access and the image acquisition process and only crashed when it tried to access the variable mes_message. This indicates a run-time error, not a compilation error. If you examine lines 751 and 752 of HS_Camera.m you can see the typo (mes_meesage vs mes_message) in the code that is the source of the error:

Here's the output:

 The attached file shows the output of the command. The maximum average frame rate is 57.2Hz when the nominal frame rate was 58Hz:

/opt/EDTpdv/take -f max_frame_rate_image -l 120 -N 4 -d > max_frame_rate_data.txt

 I measured the prism and displacement of the Gaussian beam on the Hartmann sensor. The beam pointing was modulated at 10mHz using a galvo mirror as illustrated in Attachment 1. The galvo was around 680mm from the Hartmann sensor. The amplitude of the prism modulation was approximately 1E-5 radians. The displacement of the beam was measured using a new algorithm that tries to fit a parabola to the logarithm of the intensity of each Hartmann spot. The amplitude of the displacement modulation was measured at around 42 microns: corresponding to around 6E-5 radians (=42um/680mm).

To resolve the discrepancy between the prism and displacement measurements, I removed the Hartmann plate to simply get a Gaussian beam on the CCD (bottom right image in Figures 2 & 3 - the beam is slightly clipped and there is a ghost beam in the center - I'm not yet certain where this is coming from). I measured the Gaussian beam displacement directly by fitting a Gaussian to the mean horizontal cross-section of the intensity distribution (top right plot in Figures 2 & 3). Using this technique the measured displacement on the CCD had an amplitude of around 0.7 +/- 0.05 pixels = 8.4 +/- 0.6 microns, corresponding to a prism of 12.5E-6 radians (seen in top left plot in Figures 2 and 3). This indicates that there is an error in the Gaussian fitting algorithm using the Hartmann sensor data.

 The second plot simply shows the position modulation of the beam as I increased the amplitude of the signal going to the galvo. 

 I've had the output from a fiber projected about 400mm onto the Hartmann sensor for around 5 days now. (The divergence angle from the fiber is around 86 mrad).

I played around with the temperature of the lab to induce some defocus changes in the Hartmann sensor. The system is mostly linear, but there are relatively frequent jumps in the defocus of the order of 1E-4 m^-1. This may be due to a number of things - the Hartmann plate may be moving, the fiber holder may be shifting back and forth, there may be some issue with the source wavelength shifting.

• A change in defocus, dS, of around 1E-4 m^-1 from a point source at 400mm from the Hartmann plate (dS/dx = -1/x^2), corresponds to a change in the end position of the fiber of around 16 microns. Seems a little big ... unless it's not secured properly ...
• Also the defocus vs temperature slope is different from what James measured last year. There is an additional -4E-5 m^-1 K^-1 due to the expansion of the stainless steel table moving the point source further or closer to the Hartmann plate. That leaves about -3E-4 m^-1 K^-1 for the Hartmann sensor. This is roughly twice what James measured last year. 

Sun 30th May 2011 - 11:40AM - the z-axis control on the NewFocus 9091 fiber coupling mount was not tightened. I tightened that to secure the control.

 I ran through the procedure to calibrate the lever arm of the Hartmann sensor. The beam from a 632.8nm HeNe laser was expanded to approximately 12mm diameter and injected into a Michelson interferometer. The Hartmann sensor was placed at the output port of the Michelson.

1. I tilted one of the mirrors of the interferometer to induce a prism between the two beams at the output. This created about 135 vertical fringes on the CCD.
2. With the Hartmann plate removed, I recorded the interference pattern and took its 2D FFT. There was a peak in the Fourier transform about 134 pixels from the DC level. 
3. This next part is questionable ...  I centroided the frequencies around the peak in the FFT to try to determine the spatial frequency of the fringes to better than the bandwidth of 1/1024 pixels^-1 (yes, they're strange units). This is, probably acceptable at improving the accuracy of the frequency measurement if it is known that the signal is a generated by a pure sine wave in the spatial domain - this is not an unreasonable assumption for the output of an interferometer. Anyway, the peak fluctuated around 133.9 units from DC by around +/- 0.1 units.
4. The prism between the two beams is the measured spatial frequency (measured as 133.9 oscillations across the CCD) multiplied by the wavelength and divided by the width of the CCD (= 1024 x 12um). In other words, the prism is the ratio of the wavefront change across the CCD divided by the diameter of the CCD (= 6.895 +/- 0.005 mrad)
5. Next, I inserted the Hartmann plate, blocked one of the beams and recorded the spot pattern. I then blocked the other beam and unblocked the first and recorded another spot pattern. 
6. The mean displacement between the spot patterns was calculated. Due to a fairly noisy intensity distribution (the 2" mirrors were AR coated for 700-1000nm and hence there were some stray beams), the mean displacement was relatively noisy - about 5.60 pixels with a standard deviation of around 0.3 pixels and a standard error of around 0.01 pixels ( = 67.2 um)
7. The lever arm is equal to the mean displacement of the spots divided by the prism. In this case, 9.75 +/- 0.02 mm
8. I removed the Hartmann plate and confirmed that the FFT of the fringes from the IFO still had a peak at 133.9 +/- 0.1 units. It did.

I ran a test of the HWS with the QFLD-950-3S for 5 days. The test was terminated as we need to disconnect all the cabling and tidy up all the computers in the lab.

9:40PM PDT - I've just restarted the long term measurement of the Hartmann sensor noise with the QFLD-950-3S.

I've started a long-term measurement of the HWS fiber-launcher. I'm interested in seeing how stable the output is. The HWS is currently running in the following configuration:

• SLED: QFLD-635-1S (635nm, 1mW) - current driver set to 38.02mA, thermistor set point = 10.778kOhm
• SLED coupled to patch cable
• Patch cable coupled to Newport fiber launcher FPR1-C1A which contains a FPH-CA4 fiber optic chuck (FC/APC connector). All grub screws are tighten on this (two for holding chuck, one for roll motion, one for X translation lock and one for Y translation lock)
• Output of fiber hits a 100m focal length lens (SPX043AR.16 BBAR 0.65 - 1.0um) placed approximately 100mm from the fiber output
• Output of lens is projected approximately 125mm onto the HWS where it is centered on the HWS plate

The HWS is currently running at 57Hz. The HWS code is running on HWS (10.0.1.167). It is the same as the site code with some modifications to determine information about the Gaussian beam envelope. The following data is written to file on the HWS machine in files containing 10,000 cycles. Each cycle (or row) the following data is recorded:

• GPS TIME
• PRISM_X
• PRISM_Y
• SPHERICAL_POWER
• CYLINDRICAL_POWER 
• Envelope peak intensity
• Envelope X centroid
• Envelope Y centroid
• Envelope X width
• Envelope Y width

These are saved to files on the HWS machine: ~/framearchive/C4/HWSlongterm/<GPSTIME>_CIT_HWS.txt

The data from the long-term measurement of the HWS is presented here. The beam envelope moves by, at most, about 0.3 pixels, or around 3.6 microns. The fiber-launcher is about 5" away from the HWS. Therefore, the motion corresponds to around 30 micro-radians (if it is a tilt). The beam displacement is around 4 microns.

The optical properties change very little over the full 38 days (about 2 micro-radians for tilt and around 2 micro-diopters for spherical power).

The glitches are from when the SLED drivers were turned off temporarily for other use (with the 2004nm laser).

Today I made the first characterization measurements of the mocked-up adaptive wavefront control system planned for the signal recycling mirrors.

The Setup

Inside the light-tight enclosure on the center table, I've assembled and aligned a 10.2 micron CO₂ projector which provides a heating beam of up to 150 mW incident on an SRM-like test optic. A co-aligned 633 nm probe beam and Hartmann wavefront sensor are used to measure the resulting thermal lens. I've written and installed new software on the machine hws (10.0.1.167) for viewing the wavefront distortion in real time, as shown in the below screenshot. This viewer is launched from the terminal via the command $stream_gradient_CIT

There is also a second utility program for displaying the raw Hartmann sensor CCD image in real time, which is useful for aligning the probe beam. It is launched by the terminal command $stream_intensity_CIT

Initial Thermal Lens Measurements

Lens Formation Time Scale

First, I made a time-resolved measurement of the thermal lens formation on the test optic at maximum heating beam power (150 mW). The lens appears to reach steady-state after 30 s of heating. When the heating beam is turned off, the lens decays on a very similar time scale.

Lens Strength v. Incident Heating Power

Second, I measured the thermal lens strength as a function of incident heating beam power, which I measured via a power meter placed directly in front of the test optic. Below is the approximate maximum optical path difference induced at several heating beam powers.

The above optical path differences are approximate and were read-off from the live display. I recorded Hartmann sensor frame data during all of these measurements and will be analyzing it further.

There were known to be huge (65%) heating beam power losses on the SRM AWC table, somewhere between the CO2 laser and the test optic. Today I profiled the setup with a power meter, looking for the dominant source of losses. It turned out to be a 10" focusing lens which had the incorrect coating for 10.2 microns. I swapped this lens with a known ZnSe 10" FL lens (Laser Research Optics LX-15A0-Z-ET6.0) and confirmed the power transmittance to be >99%, as spec'd. There is now ~310 mW maximum reaching the test optic, meaning that the table losses are now only 10%.

Using a single-axis micrometer stage I also made an occlusion measurement of the heating beam radius just in front of the test optic. I moved the 10" focusing lens back three inches away from the test optic to slightly enlarge the beam size. In this position, I measure a beam radius of 3.5+/-0.25 mm at 1.5" in front of the test optic (the closest I can place the power meter). The test optic is approximately 20" from the 10" FL lens, so the beam has gone through its waist and is again expanding approaching the test optic. I believe that at the test optic, the beam is very close to 4 mm.

For archive purposes, attached is a write-up of all the HWS measurements I've made to date for the SRM CO2 projector mock-up.

 [Aidan, Marie]

We tested the output of the fiber launcher D1800125-v3. We were using a 6mm spacer in the SM1 lens tube and 11mm spacer in the SM05 lens tube and the 50 micron core fiber.

The output of the fiber launcher was projected directly onto the CCD. Images of these are attached (coordinates are in pixels where 100 pixels = 1.2mm)

There is a lot of high-spatial frequency light on the output. It looks like there is core and cladding modes in addition to a more uniform background. There was an indication that we could clear up these annular modes with an iris immediately after the fiber launcher but I didn't get any images. We're going to test this next week when we get an SM1 mountable iris.

And here's the output of the fiber launcher when I fixed it at 313mm from the camera, attached an iris to the front and slowly reduced the aperture of the iris.

The titles reflect the calculated second moment of the intensity profiles (an estimate of the equivalent Gaussian beam radius). The iris is successful in spatially filtering the central annular mode at first and then the outer annular mode. 

We'll need to determine the optimum diameter to get good transmission spatially without sacrificing too much power.

Here is the output from D1800125-v5_SN01.

Title was wrong - this is actually config [12,2,4,125]

I'm considering the 86-711 2" 532nm PBS from Edmund Optics for the ETM HWS at the sites.

https://www.edmundoptics.com/optics/polarization/linear-polarizers/532nm-50mm-diameter-high-energy-laser-line-polarizer/

The effect on the transmission through the system, compared to the THorlabs PBS, is shown in the attached plot.

Conclusion: it looks almost as effective as the Thorlabs PBS with the added benefit of being 2" in diameter.

I changed the HWS code to the new git.ligo HWS version.

• Object files are in ~/hws
• scripts are in ~/hws-server
• utilities are still in old git repo moved to ~/.HWS_code_temporary_home

I've set up some symbolic links to these directories to mimic the old directory structure, so ..

• ~/pyHWS links to new object file directory
• ~/pyHWS/scripts lnks to new scripts directory
• ~/pyHWS/utilities links to old utilities directory

 Around a year ago, Phil and I discussed the possibility of using an OPO to possibly generate our own laser beam at ~2 microns for TCS. This was to avoid all of the usual hassle of the 10 micron CO2 laser.

As it turns out, the 1.5-3 micron range doesn't have enough absorption in fused silica: the absorption depth would be basically the whole thickness of the optics and this is not so useful when trying to correct surface heating.

During my recent trip to JILA, Jan Hall mentioned to me that it should be possible to operate instead at ~5 microns, where laser technology may be solid state and where we can use Si:As detectors instead of the inefficient HgCdTe ones which we use now.

JWST, in partnerships with industry, have developed some Si:As detectors:  http://www.jwst.nasa.gov/infrared.html   

Some internet searching shows that there are now several laser technologies for the mid-IR or MWIR range. Some are <1 W, but some are in the ~10 W range.

Of course, its possible that we'll switch to Silicon substrates, in which case we need to re-evaluate the goals and/or existence of TCS.

 June 5

-Discussed the actual project outline 

-Installed Comsol on the system

-Learned the basics of Comsol with the help of tutorials available on 40m wiki

and others.

June 6

-Made few simple models in Comsol 

-Studied LIGO GWADW slides for a better understanding of the project.

-Setup SVN to access remote repository.

-Created a COMSOL model for variation of temperature in two mass system.

-Used the above model for cryogenic conditions.

-checked it analytically.

-Created a COMSOL model for cryogenically shielded test mass with compensation plate.

-Analyzed the behavior of the model in different size configurations.

 -Continued with the same cryogenic model created and varied the length of  outer shield and studied the temperature variation inside.

-Compared the temperature difference given by COMSOL with manually calculated one.

-Derived formula for manual calculation of temperature due to total influx.

-Compared the results by COMSOL and by the formula.

 -Read about blue team design for maximum power budget.

-Read third generation talks to get a better understanding of the work. 

 -Attented LIGO orientation meeting and safety session.

-Prepared 3 week report

 -Updated 3 week progress report with new additions and deletions.

-Attended LIGO lecture which was very interesting and full of information.

- Discussed the further project with Dr. Brooks.

-Tried to derive formula for the test mass inside cryogenic shield(infinitely long shield from one side)

 -Discussed the project outline for next 6 weeks.

-made a write up for the tasks. (attached)

-Analyzed the variation of temperature of the test mass with input power for different lengths of the shield. 

 Does this work?

Yes.

http://www.thorlabs.com/thorProduct.cfm?partNumber=CPS180

I bought this laser diode from Thorlabs today to try the current modulation trick Phil and I discussed last Friday. 

That is:

1. Accept that there will be interference fringes on the Hartmann sensor probe beam with a laser diode source (especially if the probe beam is the retro-reflection from a Michelson interferometer with a macroscopic arm length difference)
2. Modulate the current of the laser diode source to vary its wavelength by a few hundreds on nm. Do this on a time scale that is much faster than the exposure time for a Hartmann sensor measurement
3. The contrast of the interference fringes should average out and the exposure should appear to be the sum of two incoherent beams.