I installed a recycled VME crate in the electronics rack. It currently has a Baja 4700E CPU card in it - and this needs to be configured. We also have the following cards, which are not plugged in right now.

1. ICS-110A-32 Analogue-to-Digital Converter - the jumpers need to be set on this to give it a unique memory address in the VME bus.

2. D000186 LIGO-type Anti Image card.

The CPU card needs to be configured to search it's OS binaries on the network (in this case we're going to store them on the framebuilder in Rana's lab). These settings are accessed by plugging a serial cable into the front of the card and using a terminal window to access the menu system. There are some screen caps of this below. As the card is reset we get the Start-up screen and then we can either do nothing (and a full boot will take place) or we can press a key and access the menu. From there we can restart the boot process by entering "@" or we can change the boot settings by entering "c". These are shown below:

 http://nodus.ligo.caltech.edu:8080/AdhikariLab/514

We fixed the start-up settings on the VME crate to look for a TCS startup file on fb0. The settings on the Baja 4700 are now:

 On the advice of Ben Abbott, I've ordered the Diamond Systems Athena II computer w/DAQ, as well as an I/O board, solid state disk and housing for it. The delivery time is 4-6 weeks.

Diamond Systems Athena II

 The EDT PCIe4 DV C-Link frame grabber arrived this morning. There is a CD of drivers and software with it that I'll back up to the wiki or 40m svn sometime soon.

* EDT PCIe4 DV frame grabber: installation notes for linux system 

(Note)

Main issue I encountered was the fact that most of the shell scripts
did not run by simply entering them. It's bit strange because if you
do ls -al to view the file lists they are made executable. So it's
possible that others don't encounter the same kind of problems as I
did.

However, if one executes the command "./linux.go", for example, and
receives the message saying

 bash: ./linux.go: /bin/sh: bad interpreter: Permission denied

then one may follow the steps I took as below.


1. Make a folder to put the content of CD, for example:

     mkdir ~/fgdriver

2. Copy the content of the CD-ROM to the folder.

3. Go to the folder.

     cd ~/fgdriver

4. Change or check the mode of the following script files (using the 
   command chmod) to be executable (using "chmod a+x filename"):

     linux.go

     ~/fgdriver/linux/EDTpdv/installpdv (this one should already be 
     executable)

     ~/fgdriver/linux/EDTpdv/pdv/setup.sh      

5. run ./linux.go and choose DV by clicking it.

(Note)

I am assuming that the programming language Tcl is already installed
in the machine. CentOS 5.4 that I have installed came with Tcl. If Tcl
is not installed, I think that linux.go will run cli_startmenu.sh
instead (located in the same directory as linux.go). So make sure
cli_startmenu.sh is executable (see step 4).

6. Choose default installation directory and start installation

(Note) 

In my first attempt to install the files, the installation message
window hung after displaying many lines of "........". That was
because the file setup.sh was not made executable (see step 4). So I
made setup.sh executable, ran linux.go again, then I could see further
messages flowing through (basically compiling c source files). I'm not
sure whether others will enounter the exactly same problem though.

7. After the installation completes, go to the /opt/EDTpdv folder.

     cd /opt/EDTpdv

8. Final Step: Make edt_load and edt_unload executable. (See step 4)

(Note)

Most of the other executables we need for running the frame
grabber/camera should already be executable at this point; but somehow
in my installation the above two files were not made executable. I
again do not know whether others will experience the same
problem. Since there are lots of executables generated when
installation completes, I advise that, whenever a certain command does
not run, one should check if that command file is executable or not.

----

Please let me know if you find any parts of the above confusing. I will
do my best to clarify.

 I installed CentOS on the machine with the EDT frame-grabber. I then installed the frame-grabber software from the CD.

In the /opt/EDTpdv/ directory the camconfig program was run and I entered "331" to start the frame-grabber and run with the Dalsa 1M60 settings ... this was necessary to get the frame grabber running, but didn't seem to force pdvshow, installed at a later point, to use this configuration file. At this point I could access the camera menu with the serial_cmd program.

After some effort, which will be detailed shortly, I managed to finally get the pdv_show GUI program compiled and installed. I found that trying to run that program with the dalsa_1m60.cfg configuration file resulted in a segmentation fault.

However, when I ran it with the default Dalsa configuration file, pantera11m4fr.cfg, and selected "Continuous Exposure" I got a stream of illuminated pixels on the screen. It was clear that the display was displaying the pixels coming back from the camera in the wrong way (for instance, trying to load a 1024x1024 image into a 1440x900 array), however, by changing the frame rate on the camera to 20Hz and waving my hand around in front of the camera I was able to modulate the intensity of the hash of pixels being displayed. This means that the frame-grabber is successfully getting data - it just isn't interpreting it correctly yet.

Here are a couple of images from pdv_show (hit Alt+PrtScrn to get a screenshot of the active window):

 1. Screenshot-PCI_DV_Display.png - the image on the computer with the camera running unobscured

2. Screenshot-PCI_DV_Display-1.png - the image on the computer with me covering the camera with my hand.

3. -opt-EDTpdv.png - the camera parameters at the time of this test (running serial_cmd)

Yesterday, I installed CentOS 5.3 on the Gateway GT5482 machine that housed the EDT frame-grabber.

1. I installed CentOS 5.3 with all the default options
2. As recommended by the README.lnx_pkg_reqs, I tried and failed to install the "Development Tools", "Development Libraries" and the "X Software Development" using the Add/Remove Software.
3. I copied the entire install CD to ~/fgdriver on the hard disk.
4. Installed the following packages at the command line

> yum install gcc

> yum install make

> yum install tk

> yum install kernel

I tried to run ~/fgdriver/linux.go at this point to install the EDT driver, but the installation failed about halfway through with the message "problem making the driver module". An investigation revealed that this was the due to the failure of ~/fgdriver/linux/module/makefile. I tried running that makefile separately to build the driver module and it crashed with the message: Can't find /lib/modules/2.6.18-128.el5/source/include/linux/mm.h. I concluded that the kernel source code wasn't installed

• Added "Development Libraries" with Add/Remove Software
• Ran the following command lines

> yum install kernel-devel

> yum install kernel-xen-devel

 And then I followed the instructions at the link: http://wiki.centos.org/HowTos/I_need_the_Kernel_Source

from: > yum install rpm-build redhat-rpm-config unifdef

 to:  > rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.el5.src.rpm 2>&1 | grep -v mockb

and at the latter point the rpm build  pissed and moaned that it couldn't find the file kernel-2.6.18-164.15.1.el5.src.rpm

However, some combination of the above must have worked. I rebooted the computer and logged in again as root. At this point the install script ~/fgdriver/linux.go ran from start to finish without complaining. A quick test of the resulting /opt/EDTpdv/camconfig and then /opt/EDTpdv/serial_cmd showed that I could access the Dalsa 1M60 camera through the frame grabber.

Regarding the installation of EDT software, I overlooked a note from the install.pdf  file.

The gist of it is that if the scripts do not run, then remount the CD-ROM by typing the

following:

mount /mnt/cdrom -o remount,exec

which will then allow the scripts to be run. The directory /mnt/cdrom should be changed if

the cdrom is mounted somewhere else. (The note can be found in the page 1 of the file

install.pdf.)

Unfortunately I don't have linux installed at the moment so I cannot test this. My computer was

reinstalled with Windows XP, the previous CentOS system being wiped out. However if this works,

then there is probably no need to copy the files to the hard drive. 

I installed a Windows XP virtualization on the Hartmann machine. It can be accessed from the desktop, or by running virt-manager at the command line. Once the virtualization manager starts the virtualization of Windows needs to be started. It runs quite slowly.

I also installed MATLAB on this machine in /apps/. TThis was intended to be /apps/MATLAB/ but apparently the install program doesn't add a top directory called MATLAB as you might expect. I had to run a yum install libXp because it was complaining that "/apps/bin/glnxa64/MATLAB: error while loading shared libraries: libXp.so.6: cannot open shared object file: No such file or directory"

I saw this and tried it when i was installing, but I had more flexibility when I copied the files directly to the hard drive.

Alex Ivanov came in on Friday and demonstrated his EPICS kung-fu. His EPICS knig-fu is strong.

We fixed the IP address of the Hartmann machine, renamed it hartmann, and mounted the cvs drives from the frame builder. - including the EPICS base from that machine. In principle, with a new softIoc, this should have been enough to run EPICS on the hartmann machine. However, whilst the softIoc would start, it wouldn't broadcast any channels. Eventually we figured out that this was because of the Windows Virtualization adding another IP address to the hartmann machine (revealed with /sbin/ifconfig). So we removed the virtualization system and then EPICS seemed to broadcast much better.

The minutia of install isshown in the history files for the controls and root users - attached.

I noticed that when i ran /opt/EDTpdv/camconfig and selected camera 331, which appeared to be closest to the Dalsa Pantera 1M60 camera, the software loaded the configuration file pantera11m4fr.cfg.

I tried to locate which entry in the camconfig list corresponded to the dalsa_1m60.cfg configuration file, but none of them seemed to. I couldn't select any entry and get it to report that it was using the 1m60 config file.

Next I noticed that there were 659 configuration files in the /opt/EDTpdv/camera_config directory but only 460 configuration options in camconfig. This seemed like 1/3 of the config files were somehow not formatted correctly, including,possibly the 1M60 config file.

By editing the pantera11m4fr.cfg I verified that the name of the camera, as it appears in the camconfig program, is the second line in the configuration file. For that file it was:

# CAMERA_MODEL 	"Dalsa Pantera 12 bit single channel camera link"

where the first line is just a single hash. The dalsa_1m60.cfg file did not have a name formatted in the same way as above: it was originally as shown below:

# Dalsa 1m60 config file (freerun)

so i changed the name in that configuration file to the following and it was suddenly available in the list when ./camconfig was run

# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"

I selected that camera (number 53 in the list). Once this was done I ran pdv_flshow/pdvshow again the image that was displayed from the camera appeared to be correctlty demodulated.

Actually, the very first time i ran pdvshow the image was demodulated correctly but it appeared that the origin was offset and then the image wrapped around a little at the edges. However, every successive time I've run pdvshow since then I've had a perfectly demodulated image.

I ran some test patterns by changing the video mode using the serial communications menu in the camera. I also illuminated the Hartmann sensor with a torch/flashlight and got some spot patterns - see attached images.

Also, I've attached the dalsa_1m60.cfg file.

I updated the .bashrc file in controls@hartmann to include aliases for the ezca EPICS commands and a few others. Details shown below:

Also added launchers to the top panel for MATLAB, sitemap, dataviewer and StripTool. The icons for the launchers are located in:

/cvs/users/ops/ligo-launchers/icons

Changes to .bashrc

alias dv="/cvs/opt/apps/Linux/dataviewer/dataviewer"
alias StripTool = "/cvs/opt/apps/Linux/medm/bin/StripTool"
alias medm="/cvs/opt/apps/Linux/medm/bin/medm"
alias sitemap='medm -x /cvs/cds/caltech/medm/c2/atf/C2ATF_MASTER.adl'

# EPICS aliases
alias ezcademod="/cvs/opt/apps/Linux/gds/bin/ezcademod"
alias ezcaread="/cvs/opt/apps/Linux/gds/bin/ezcaread"
alias ezcaservo="/cvs/opt/apps/Linux/gds/bin/ezcaservo"
alias ezcastep="/cvs/opt/apps/Linux/gds/bin/ezcastep"
alias ezcaswitch="/cvs/opt/apps/Linux/gds/bin/ezcaswitch"
alias ezcawrite="/cvs/opt/apps/Linux/gds/bin/ezcawrite"

I added the Dalsa 1M60 temperature measurements to EPICS. The break down is as follows:

I added a softIoc called HWS to /cvs/cds/caltech/target/softIoc. It added the channels following channels: C4:TCS-HWS_TEMP_DIGITIZER and C4:TCS-HWS_TEMP_SENSOR. The ioc (input/output controller) is run with the following command:

/cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc HWS.cmd

 I've added the digitizer and sensor board temperature readings from the HWS to the frames. This was done in the following way

1. Create a new file /cvs/cds/caltech/chans/daq/C4TCS.ini - with the channels in it - see below

2.  open /cvs/cds/caltech/target/fb1/master

3. add a line that includes the C4TCS.ini file when the frame builder starts

4. restart frame-builder by killing the daq daemon - kill <process id for daqd> (this is the only thing that needs to be entered as it will automatically restart)

C4TCS.ini

[default]

dcuid=4

datarate=16

gain=1.0

acquire=1

ifoid=0

datatype=4

slope=1.0

offset=0

units=NONE

[C4:TCS-HWS_TEMP_SENSOR]

[C4:TCS-HWS_TEMP_DIGITIZER]

 I added the following line to ~/.bashrc

export PYTHONPATH=/home/controls/scripts/modules:/usr/local/lib/python

Python script

I wrote a Python script, ~/scripts/dalsa_to_epics.py that reads the temperature off the camera using serial_cmd vt and then it writes this to the EPICS channels using ezcawrite. See attached. It is now running continuously in the background as dalsa_to_epics.

Dalsa1M60 baud rate

Also I accessed the menu of the 1M60 and changed the baud rate to 115200 using sbr 115200. Then I edited the dalsa_1m60.cfg file to set the baud rate to 115200 in that file. Finally, I changed the settings on the camera so that it will boot with the new baud rate when it is turned off and on again - this was with wus in the camera menu.

All the files are attached.

~/scripts/dalsa_to_epics.py

~/scripts/Dalsa1M60/VerifyTemperature.py

/opt/EDTpdv/camera_config/dalsa_1m60.cfg

I added the camera parameters to EPICS and the MEDM screen. These are available as channels now in EPICS and eventually there will be a python script that writes the EPICS value to those channels, but right now it is just a python script that reads the values off the Dalsa camera.

I updated the channels in /cvs/cds/caltech/chans/daq/C4TCS.ini so that these are saved to the daq and I also restarted the daq daemon.

The python script that gets the camera parameters is here: scripts/Dalsa1M60/GetCameraParameters.py and the script that writes the parameters to the EPICS channels is here scripts/dalsa_to_epics.py.

These are attached as is C4TCS.ini and HWS.db which defines the new channels.

Here's the error:

 Traceback (most recent call last):

Attached is .m file of the custom function that I wrote and used to automatically detect peaks in a Hartmann image,
and calculate the centroid corrdinates of each of those peaks.

A simple example of its usage,  provided that myimage is a two-dimensional image array obtained from the camera, is

radius = 10;

peak_positions = detect_peaks_uml(myimage,radius);

no_of_peaks = length(peak_positions);

centroids_array = zeros(no_of_peaks);

for k = 1:no_of_peaks

  centroids_array(k,1) = peak_positions(k).WeightedCentroid(1);

  centroids_array(k,2) = peak_positions(k).WeightedCentroid(2);

end

I chose my value of radius by looking at spots in a sample image and counting the number of pixels across a peak. It may be 
more useful to automatically obtain a value for the radius. I may run some tests to see how different choices of radius
affect the centroid calculations. 

I may also need to add some error checking and/or image validating codes, but so far I have not encountered any problems. 

Please let me know if anyone needs more explanation!

Won

This looks really efficient! However, I think there's a systematic error in the calculation. I tested it on some simulated data and it had trouble getting the centroids exactly right. I need to better understand the functions that are called to get an idea of what might be the problem.

 After much effort trying to get a MATLAB routine to compile in C I discovered the following pieces of information.

1. CentOS will not install a gcc compiler more recent than 4.1.2 with yum install. This is circa 2007. If you want a more recent compiler it must be installed manually.

2. To compile and link C programs that call the MATLAB engine, they must be compiled in MATLAB using the mex command. Every version of MATLAB after R2008b requires the gcc compiler 4.2.3.

3. Building gcc 4.2.3 takes a lot more than 1 hour of compile time. I accidentally killed the build process and gave it up as a lost cause. 

This is an amended version of simple_take.c.

The files below are all in the directory /opt/EDTpdv/hartmann/src

1. simple_hartmann.c   - the C code to access the frame grabber, retrieve an image, load the MATLAB engine and pass the image to MATLAB for centroiding
2. centroid_image.m  - the MATLAB routine that centroids the image
3. get_defocus.m - the MATLAB function that determines the defocus in the centroids
4. build_simple_hartmann.sh - a shell script I wrote that contains the compile and link options to build the thing correctly 

 I've added the following channels to the HWS softIoc in /cvs/cds/caltech/target/softIoc/HWS.db

EPICS and DAQ restart procedure

1. Kill the existing softIoc. Use a "ps -e | grep softIoc" command to determine the process id.
2. After editing the HWS.db file restart the softIoc with the following command:

        3. Edit the /cvs/cds/caltech/chans/daq/C4TCS.ini file and kill the daqd process on fb1. It should restart automatically.

Done!

 Here's a copy of an email I distributed today that describes the centroid and simulation code I wrote.

Hi Won,

I've written some code that generates an image of Gaussian spots and provides you with the coordinates of the centers used to generate those spots. There is the facility to turn on i) photo-electron shot noise, ii) random displacement of the nominal positions of the centers from a regular array and iii) 12-bit digitization to more accurately model the output from a CCD.

I've included an example routine that calls this function and then centroids those spots using a variant of your centroiding algorithm.

You should be able to use this to generate reliable simulated data to test versions of your centroiding algorithm.

Cheers,
Aidan.

Attached files: 
1. test_spot_generation_and_centroiding.m     - the example routine. Run this first
2. generate_simulated_spots.m         - the function to generate the simulated spots in an image and as a set of positions
3. centroid_image.m - the function to centroid an image

Given below is a brief overview of calculating rms of spot position changes to test the accuracy/precision of the centroiding code. Centroids are obtained by summing over the array of size 30 by 30 around peak pixels, as opposed to the old method of using matlab built-in functions only. Still peak pixel positions were obtained by using builtin matlab function. Plese see the code detect_peaks_bygrid.m for bit more details.

My apologies for codes being well modularised and bit messy...

Please unzip the attached file to find the matlab codes.

The rest of this log is mainly put together by Kathryn.

Won

(EDIT/PS) The attached codes were run with raw image data saved on the hard disk, but it should be relatively easy to edit the script to use images acquired real time. We are yet to play with real-time images, and still operating under Windows XP...

---
When calculating the rms, the code outputs the results of two
different methods. The "old" method is using the built-in matlab
method while the "new" method is one Won constructed and seems to
give a result that is closer to the expected value. In calculating
and plotting the rms, the following codes were used:

- centroid_statics_raw_bygrid.m (main script run to do the analysis)
- process_raw.m (takes raw image data and converts them into 2D array)
- detect_peaks_bygrid.m (returns centroids obtained by old and new methods)
- shuffle.m (used to shuffle the images before averaging)

The reference image frame was obtained by averaging 4000 image frames,
the test image frames were obtained by averaging 1, 2, 5, 10 ... 500,
1000 frames respectively, from the remaining 1000 images.

In order to convert rms values in units of pixels to wavefront
aberration, do the following:

aberration = rms * pixel_width * hole_spacing / lever_arm

pixel_width: 12 micrometer
hole_spacing: about 37*12 micrometer
lever_arm: 0.01 meter

rms of 0.00018 roughly corresponds to lambda over 10000.

Note: In order to get smaller rms values the images had to be shuffled
before taking averages. By setting shuffle_array (in
centroid_statics_raw_bygrid.m) to be false one can
turn off the image array shuffling.

N_av        rms

1     0.004018866673087
2     0.002724680286563
5     0.002319477846009
10    0.001230553835673
20    0.000767638027270
50    0.000432681002432
100   0.000427139665006
200   0.000270955332752
500   0.000226521040455
1000  0.000153760240692

fitted_slope = -0.481436501422376

Here are some plots:

---

Next logs will be about centroid testing with simulated images, and wavefront changes due to the change in the camera temperature!

(PS) I uploaded the same figure twice by accident, and the site does not let me remove a copy!...

Happy Fourth of July!

The following is a brief overview of how we are analyzing the wavefront aberration and includes the aberration parameters calculated for 9 different temperature differences. So far we are still seeing the cylindrical power even after removing the tape/glue on the Hartmann plate. Attached are the relevant matlab codes and a couple of plots of the wavefront aberration.

We took pictures when the camera was in equilibrium at room temperature and then at each degree increase in camera temperature as we heated the room using the air conditioner. For each degree increase in camera temperature, we compared the spot positions at the increased temperature to the spot positions at room temperature. We used the following codes to generate the aberration parameters and make plots of the wavefront aberration:

-build_M.m (builds 8 by 8 matrix M from centroid displacements)
-wf_aberration_temperature_bygrid.m (main script)
-wf_from_parms.m (generates 2D aberration array from aberation parameters)
-intgrad2.m (generates 2D aberration array from an interpolated array of centroid displacements)

In order to perform the "inverse gradient" method to obtain contours, we first interpolated the centroid displacement vectors to generate a square array. As this array has some NaN (not a number) values, we cropped out some outer region of the array and used array values from (200,200) to (800,800). Sorry we forgot to put that part of the code in wf_aberration_temperature_bygrid.m.

The main script wf_aberration_temperature_bygrid.m needs to be revised so that the sign conventions are less confusing... We will update the code later.

The initial and final temperature values are as follows:

Aberration parameters:

1) Comparing high temp (+10)  with room temp

        p: 1.888906773203923e-004
       al: -0.295042766811686
      phi: 0.195737681653530
        c: -0.001591869846958
        s: -0.003826146141562
        b: 0.098283157674967
       be: -0.376038636781319
        a: 5.967617809296910

2) Comparing +9 with room temp

        p: 1.629083055002727e-004
       al: -0.222506109890745
      phi: 0.193334452094940
        c: -0.001548838746542
        s: -0.003404217451916
        b: 0.091368295953142
       be: -0.351830698303612
        a: 5.764068008962653

3) Comparing +8 with room temp

        p: 1.485283322069376e-004
       al: -0.212605187544093
      phi: 0.206716196097728
        c: -0.001425962488852
        s: -0.003148796701331
        b: 0.089936286297599
       be: -0.363538909377296
        a: 5.546514425485094

4) Comparing +7 with room temp

        p: 1.284124028380585e-004
       al: -0.163672705473379
      phi: 0.229219952949728
        c: -0.001452457146947
        s: -0.002807207555944
        b: 0.084090100490331
       be: -0.379195428095102
        a: 5.289173743478881

5) Comparing +6 with room temp

        p: 1.141756950753851e-004
       al: -0.149439038317734
      phi: 0.240503450300707
        c: -0.001350015836130
        s: -0.002529240946848
        b: 0.078118977034120
       be: -0.326704416216547
        a: 4.847406652448727

6) Comparing +5 with room temp

        p: 8.833496828581757e-005
       al: -0.071871278822766
      phi: 0.263210114512376
        c: -0.001257787180513
        s: -0.002095618522105
        b: 0.069587080420443
       be: -0.335912998511077
        a: 4.542557551218057

7) Comparing +4 with room temp

        p: 6.217428324604411e-005
       al: 0.019965235199575
      phi: 0.250991433584904
        c: -0.001266061216964
        s: -0.001568527823273
        b: 0.058323732750548
       be: -0.289315790283207
        a: 3.957825468583509

8) Comparing +3 with room temp

        p: 4.781068895714900e-005
       al: 0.140720713391208
      phi: 0.270865276786418
        c: -0.001228146894728
        s: -0.001371110045136
        b: 0.052794990899554
       be: -0.273968130963666
        a: 3.591187350052610

9) Comparing +2 with room temp

        p: 2.491163442408281e-005
       al: 0.495136135872766
      phi: 0.220727346409557
        c: -9.897729773516012e-004
        s: -0.001076008621974
        b: 0.048467660428427
       be: -0.280879088681660
        a: 3.315430577872808

10) Comparing +1 with room temp

       p: 8.160828332639811e-006
      al: 1.368853902659128
     phi: 0.116300954280238
       c: -6.149390553733007e-004
       s: -3.621216621887707e-004
       b: 0.025454969698557
      be: -0.242584267252882
       a: 1.809039775332749

The first plot is of the wavefront aberration obtained by integrating the gradient of the aberration and the second plot fits the aberration according to the aberration parameters so is smoother since it is an approximation.

http://nodus.ligo.caltech.edu:8080/AdhikariLab/859

 http://nodus.ligo.caltech.edu:8080/AdhikariLab/860

 contents of tcs_daq: /target/TCS_westbridge.db

hartmann had started responding to requests to log-in with the a request to change the password. Attempts to change the password proved unsuccessful. I tried to access the machine locally to change the password but I couldn't the display started, so I had to reboot it.

I plotted a histogram of the total intensity of the Hartmann sensor when illuminated and found that the 128 count problem extends all the way up through the distribution. This isn't unreasonable since that digitizer is going to be called on mutliple times.

First things first, the value of 128 equals a 1 in the 8th digitizer, so for a 16-bit number in binary, it looks like this: 0000 0000 1000 0000 and in hex-code 080

The values of the peaks in the attached distribution are as follows:

I illuminated the Hartmann sensor with the output of a fiber placed ~1m away.

I noticed that the illumination was not uniform, rather there was some sort of 'burst' or 'star' right near the center of the image. This turned out to be due to the Hartmann plate clamps - it disappeared when I removed those. It appears that there is scatter off the inner surface of the holes through the clamp plates. I'm not sure if it's from the front or back plates.

Needs further investigation ...

Attached are the background and 80% illumination (~uniform spatially uniform) images that Dalsa requested.

Note that the gain of the taps does not appear to be balanced.

I've attached an image that shows the locations of those pixels that record a number of counts = (2*n-1)*128. 

The image is the sum of 200 binary images where pixels are given values of 1 if their number of counts = (2*n-1)*128 and 0 otherwise.

The excess of counts is clearly coming from the left hand tap. This is good news because the two taps have independent ADCs and it suggests that it is only a malfunctioning ADC on the LHS that is giving us this problem.

 I added some new channels to the Athena DAQ that record the diagnostic channels from the Superlum SLED.

• C4:TCS-ATHENA_I_SET_VOLTS:  - the set current signal in Volts (1V = 1A)
• C4:TCS-ATHENA_I_ACTUAL_VOLTS:   - a signal proportional to the actual current flowing to the SLED (1V = 1A)
• C4:TCS-ATHENA_I_LIM_VOLTS: - the current limit signal in volts (1V = 1A)
• C4:TCS-ATHENA_TEMP_SENS_V:   - the signal from the on-board temperature sensor [thermistor] (1V = 10kOhm ?)
• C4:TCS-ATHENA_PD_VOLTAGE: - the signal from the on-board photodetector (1V = 1A?)

The ioc that handles the EPICS channels is on tcs_daq(10.0.1.34) in /target/TCS_westbridge.db

The channels are added to the frame builder in /cvs/cds/caltech/chans/daq/C4TCS.ini

Currently, the driver for the SLED is ON but the current to the SLED is off. This is to check that the zero value of the PD_VOLTAGE signal doesn't wander.

Also, the input noise of the Athena is around +/- 10 counts (where 2^15 counts = 10V) which is a pretty poor 3mV.

 I set up the SLED to test its long term performance. The test began, after a couple of false starts, around 9:15AM this morning.

The output of the fiber-optic patch cord attached to the SLED is illuminating a photo-detector. The zero-level on the PD was 72.7mV (with the lights on). Once the PD was turned on the output was ~5.50 +/- 0.01V. This is with roughly 900uW exiting the SLED.

The instructions from Superlum suggest limiting the amount of power coupled back into the fiber to less than 3%. With the current setup, the fiber is approximately 2" from the photodetector. What is the power coupled back into the fiber?

Assume a worst case of 100% of the light reflected from the PD, the wavelength is 830nm and a waist size of about 6um radius at the output of the fiber. The beam size at 4" (from the fiber output to the PD and back again) or ~100mm from the fiber is about 4.4mm radius. Therefore about (6um/4.4mm)^2 or ~2ppm will be coupled back into the fiber. This is sufficiently small.

The attached plots from dataviewer show measurements from the SLED (on-board photodetector, on-board temperature sensor, current setpoint, current limit, current to diode) over the last 15 hours.

 Restarted the HWS EPICS channels on hartmann with the following command:

 I added an alias HWSIoc to controls which can be used to start the HWS EPICS softIoc.

Below is a table summarizing the results of recent thermal defocus experiments. The values are the calculated change in measured defocus per unit temperature change of the sensor:

More detail on these experiments will be available in my second progress report, which will be uploaded to the LIGO DCC by next Monday.

The main purpose of this particular eLog is to summarize what functions I wrote and used to do this data analysis, and how I used them. All relevant code which is referenced here can be found on the SVN; I uploaded my most recent versions earlier today.

Here is a flowchart summarizing the three master functions which were specifically addressed for each experiment:

py4plot.m is probably the most complicated of these three functions, in terms of the amount of data analysis done, so here's a flowchart which shows how the function works and the main subfunctions that it addresses:

Also, here is a step-by-step example of how these functions might be used during a particular experiment:

(1)Suppose that I have an experiment which I have named "73010a", in which I wish to take 40 images of 200 sums. I would open the code for framesumexport2.py and change lines 7, 8 and 17 to read:

7  LoopN=40
8 SumN=200
17 mainoutbase="73010a"

And I would then save the changes. I would double-check that the output basename had indeed been changed to 73010a (it will overwrite existing data files, if you forget to change the basename before running it). I would then let the script run (changing the set temperature of the lab after the first summed image was taken). Note that the total duration of the measurement is a function of how many images are summed and how many summed images are taken (in this example, if I was taking each single image at a rate of 11Hz, data collection would take ~20 seconds and data processing (summing the images) would take ~4 minutes (on the order of ~1 second per image in the sum) (the script isn't very quick at summing images, obviously).

EDIT(7/30 3:40pm):  I just updated framesumexport2.py so that the program prompts you for this information. I also changed enabled execute permissions on the copy of the code on the Hartmann machine located in /users/jkunert/, so going to that directory and typing ./framesumexport2.py then inputting the information when prompted is all you need to do now. No need to go change around the actual code every time, any more.

(2)Once data collection had ceased entirely, I would open MATLAB and enter the following:

[x,y,dx,dy,time,M,centroids]=pyanalyze_uni('73010a',40);

The function would then look for 73010a.raw and 73010a.txt in ./opt/EDTpdv/ and import the 40 images individually and centroid them. The x and y outputs are the centroid locations. If, for example, 952 centroids were located, x and y would be 952x1x40 arrays. M would be a 40x4 array of the form:

[time_before_img_taken      time_after_img_taken      digitizer_temp      sensor_temp]

(3)Once MATLAB had finished the previous function, I would input:

tG=struct;
py4plot('73010a',0,39,x,y,'73010a','200',[1 952],2,tG)

The inputs are, respectively:

(1)python output basename,
(2)first image to analyze (where the first image is image 0),
(3)last image to analyze,
(4)x data (or, rather, data to analyze. to analyze y instead, just flip around "x" and "y" in the input),
(5)y data (or, if you want to analyze the y-direction, "x" would be the entry here),
(6)experiment name,
(7)number of sums in each image (as a string),
(8)range of centroids to include in analysis (if you have 952 centroids, for example, and no ridiculous noise at the edges of the CCD, then [1 952] would be the best entry here),
(9)outlier tolerance (number of standard deviations from initial fit line that a datapoint must be within to be included in the second line fitting, in the dx vs x plot),
(10)exponential fitting structure (input an empty structure unless the temperature/time exponential fit turns out poorly, in which case a better fit parameter guess can be inputted as field tG.guess)

 A waveform channel was added to the HWS softIoc on hartmann. This allows arrays of data to be stored in a single channel. It's not clear whether it is storing this data as a set of number or strings. However, the values can be changed by the following command:

caput -a -n C4:TCS-HWS_CENTROIDSX 5 1,2,3,4,5

Although the <no of values> entry doesn't seem to actual enforce anything - you can have more or less values than this in the array and they are still added to the channel. What does seem to be necessary is no spaces between the commas and the values of the array.

This also works:

[controls@fb1 cds]$ caput -a -n C4:TCS-HWS_CENTROIDSX 2 1,2,3n

Old : C4:TCS-HWS_CENTROIDSX          1,2,35.4342 

New : C4:TCS-HWS_CENTROIDSX          1,2,3n 

which suggests that this is really a string variable - even with the -n enforce. The cainfo command suggests this as well. 

Usage: caput [options] <PV name> <PV value>

       caput -a [options] <PV name> <no of values> <PV value> ...

  -h: Help: Print this message

Channel Access options:

  -w <sec>:  Wait time, specifies longer CA timeout, default is 1.000000 second

Format options:

  -t: Terse mode - print only sucessfully written value, without name

Enum format:

  Default: Auto - try value as ENUM string, then as index number

  -n: Force interpretation of values as numbers

  -s: Force interpretation of values as strings

Arrays:

  -a: Put array

      Value format: number of requested values, then list of values

After some discussion with Frank we figured out how to edit the record type in HWS.db so that the waveform/array channel actually behaved like a numerical array and not like a single string. This just involved defining the data type and the element count in the record definition, like so:

and then when the ioc was rebooted, examination of the channel showed the following:

[controls@fb1 cds]$ caput -a -n C4:TCS-HWS_CENTROIDSX 2 1,2,3n

Old : C4:TCS-HWS_CENTROIDSX          1,2,35.4342 

New : C4:TCS-HWS_CENTROIDSX          1,2,3n 

which suggests that this is really a string variable - even with the -n enforce. The cainfo command suggests this as well. 

Main Points

• Re-set SLED current set-point control voltage to 0.111V
• SLED current set-point voltage drops by about 5mV when the SLED is dis-engaged
• Resetting was around 11:45AM PDT 31st-Jul-2010

I turned off the SLED for 10s and reset the current set-point voltage (read using a mutlimeter and probing a couple of pins at the back of the driver board). The initial voltage when the test started on Monday was 0.111V when the SLED was engaged. This drooped to 0.109V over the week and there was a corresponding (but possible not resulting) drop in on-board photo-diode voltage. When the SLED was disengaged the set-point current control voltage dropped to 0.104V. I turned the LP pot on the front of the SLED driver board until the multimeter read 0.106V and re-engaged the SLED. The curernt set-point voltage then read 0.111V, occasionally popping up to 0.112V for a moment or two.

The DC Power Supply to the SLED reads 8.9V with 0.26A current being drawn.

[INCOMPLETE ENTRY]

We set up the Hartmann sensor and illuminated it with the output from the fiber-coupled SLED placed about 1m away. The whole arrangement was covered with a box to block out ambient light. The exposure time on the Hartmann sensor was adjusted so that the maximum number of counts in a pixel was about 95% of the saturation level.

We recorded a set of 5000 images to file and analyzed them using the Caltech and Adelaide centroiding codes. The results are shown below. Basically, we see the same deviation from ideal improvement that is observed at Adelaide.

 I downloaded and tested revision 47 of the Adelaide Hartmann sensor code from the SVN (https://trac.ligo.caltech.edu/Hartmann_Sensor/browser/users/won/HS_OO?rev=47). After giving it the correct input filenames it centroided the Hartmann sensor images pretty seamlessly. The output and code is attached below.

The code takes two Hartmann images. Locates the centroids in both instances and then determines the displacements of all the centroids between the two images. The locations of the centroids are plotted in a diagram and the x- and y- centroid displacements are plotted vs the index of each centroid.

The following comments are output on the command line in MATLAB:

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

HWS_code_output.png - shows the output from the code: we'll need to get more labels on these plots.

HWS_input_image.png - the reference input image (using false color scale) to the Hartmann code

 Appended below is the step by step procedure that I used to install and
use the frame grabber SDK. Note that the installation process was a lot
simpler with the SDK version 4.2.4.3 than the previous version.

Lines starting with ":" are my inputs and with ">" the computer outputs.

I tried to put this into elog but the web page says the laser password is
wrong so I could not.

Won

---

0. Turn on or restart the computer. For installation of the frame grabber
  SDK, go to step 1. If using the existing installation go to step 5.

1. Copy the script EDTpdv_lnx_4.2.4.3.run to my home folder.

2. Ensure that the script is executable.

: chmod +x EDTpdv_lnx_4.2.4.3.run

3. Run the script.

: sudo ./EDTpdv_lnx_4.2.4.3.run

4. After entering the root password, the script asks for the installation
  directory. Default is /opt/EDTpdv, to which I type 'y'.

  The script then runs, printing out a massive log. This completes the
  installation process.

5. Move to the directory in which the SDK is installed.

: cd /opt/EDTpdv

6. Initialise the camera by loading a camera configuration file
  dalasa_1m60.cfg located in the camera_config folder.

: ./initcam -f camera_config/dalsa_1m60.cfg

  Which will output the message (if successful)

opening pdv unit 0....

done

7. Take an image frame.

: ./take -f ~/matlab/images/test.raw

  which will save the raw file as specified above and generate following
  message on the terminal:

reading image from Dalsa 1M60 12 bit dual channel camera link

width 1024 height 1024 depth 12  total bytes 2097152

writing 1024x1024x12 raw file to /home/won/matlab/images/test.raw

(actual size 2097152)

1 images 0 timeouts 0 overruns

Whether the image taken was valid or not, I followed the exactly same
procedure. In step 7, when the image was not valid, the message after
executing the take command said "1 timeoutouts", and when the image was
valid I got "0 timeouts".

You will also get "1 timeouts" if you turn off the camera and execute the
take command. So at least I know that when an image taken was not valid it
is due to the frame grabber failing to obtain the image from the camera.

Attached below is a diagram that describes the organisation of image folders that I am using at the moment with Run_initialize and Run_acquire scripts.

Once the uppermost folder 'image' is set up, other folders in it will be created by the matlab codes if not present. Still it may be of less hassle to create the folders beforehand.

Images that are used during State 1 are saved inside 'probe' and 'secondary' folders (but not inside 'cbt' folders) with prefixes, e.g., 'dark' (for background count estimation) 'expadj' (for exposure adjustments), 'test' etc.

Hope this helps to understand image saving/reading procedures used throuout the two Run scripts. 

I added a workstation at 10.0.1.26 in the TCS lab.

The new machine in the TCS lab is running Ubuntu. I installed the frame-grabber into it and, after loading the configuration file for the camera, was able to access the serial port on the camera and also was able to record a properly formatted image from the Hartmann sensor.

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]