40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  TCS elog, Page 3 of 5  Not logged in ELOG logo
ID Date Authordown Type Category Subject
  16   Fri Feb 12 21:00:06 2010 AidanElectronicsRing HeaterRing heater step function response - time series

Hideously slow internet at airport is making me write a brief entry. This is the times series of the hesilver watlow heater radiative response to a step function.

Laso United airlines are a bit cheap ....

Attachment 1: silver_watlow_heater_step_function_response_2010-02-12.pdf
silver_watlow_heater_step_function_response_2010-02-12.pdf
  17   Mon Apr 12 08:55:37 2010 AidanComputingHartmann sensorEDT frame grabber is here

 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.

  18   Mon Apr 12 17:25:01 2010 AidanElectronicsHartmann sensorFiber-Camera Link demonstration

 I installed the EDT PCIe4 DV C-Link frame grabber in a spare Windows XP PC and connected the Dalsa 1M60 camera directly to it via the CameraLink cable. In this configuration I was able to access the menu system in the camera using the supplied serial_cmd.exe routine.

PC --> Frame-Grabber --> Camera-Link Cable --> Dalsa 1M60: works OK

Next, I attached the RCX C-Link: Fiber to Camera Link converters to either end of a 300' fiber, plugged them into the PC and the Dalsa 1M60 and then supplied them with 5V of power. Once again, I was able to access the on-board menu system in the camera (as the attached screen-capture shows). I also did a quick-test using the in-built video display program and verified that I could get an image from the camera - by waving around my hand in front of the CCD I was able to modulate the light in the image on the computer. This, therefore, demonstrates that the camera can be easily accessed and run at a distance of at least 300' via optical fiber.

 

PC --> Frame-Grabber --> RCX C-Link --> 300' optical fiber --> RCX C-Link --> Dalsa 1M60works OK

The attached images:

 hartman_sensor.JPG: a screencap of the Dalsa 1M60 on-board menu system captured with the C-Link to fiber connector running

Fiber_Camera_Link_1.jpg: A RCX C-Link and one end of the 300' fiber connected to the Dalsa 1M60

 

Fiber_Camera_Link_3.jpg: A RCX C-Link and the other end of the 300' fiber connected to the PC

 

 

 

 
 
 
 
 
 
 
 
 

 

Attachment 1: hartmann_sensor.JPG
hartmann_sensor.JPG
Attachment 2: Fiber_Camera_Link_1.jpg
Fiber_Camera_Link_1.jpg
Attachment 3: Fiber_Camera_Link_3.jpg
Fiber_Camera_Link_3.jpg
  20   Tue Apr 20 18:05:24 2010 AidanComputingHartmann sensorImages off the Dalsa Camera in CentOS

 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)

 

Attachment 1: Screenshot-PCI_DV_Display.png
Screenshot-PCI_DV_Display.png
Attachment 2: Screenshot-PCI_DV_Display-1.png
Screenshot-PCI_DV_Display-1.png
Attachment 3: -opt-EDTpdv.png
-opt-EDTpdv.png
  21   Wed Apr 21 06:49:51 2010 AidanComputingFrame GrabberInstalling CentOS 5.3 and the EDT frame-grabber - Part 1

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.

 

 

 

 

 

 

  23   Thu Apr 22 08:20:51 2010 AidanComputingHartmann sensorInstalled MATLAB and Windows XP Virtualization on Hartmann machine

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"

  24   Thu Apr 22 08:22:18 2010 AidanComputingFrame Grabberfrom the manual install.pdf

Quote:

 

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 saw this and tried it when i was installing, but I had more flexibility when I copied the files directly to the hard drive.

 

  25   Mon May 3 17:42:20 2010 AidanComputingEPICSEPICS install by Alex

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.

 

Attachment 1: history.txt
    1  cd
    2  mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
    3  echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmacros
    4  ls
    5  cd rpmbuild/
    6  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18.15.1.el5.src.rpm 2
    7  cd ..
    8  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18.15.1.el5.src.rpm 2>&1 | grep -v mockb
    9  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.e15.src.rpm 2>&1 | grep -v mockb
   10  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.e15.src.rpm 2>&1 | grep -v mockb
... 183 more lines ...
Attachment 2: history_root.txt
    1  yum
    2  yum install gcc
    3  yum install make
    4  yum install tk
    5  yum install tcl
    6  yum install mm
    7  yum install kernel
    8  yum install source
    9  yum install include
   10  yum install kernel-source
... 797 more lines ...
  26   Mon May 3 17:43:48 2010 AidanComputingFrame GrabberSuccessful image capture with EDT frame grabber

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.

 

 

Attachment 1: 20100503_dalsa1m60_configuration_notes.txt
Configuring HWS to get image in CentOS
----------

9:34AM - Dalsa 1m60 turned on

----
$ /opt/EDTpdv
$ ./serial_cmd
%%this starts the serial communications device in the EDT FG but it isn't configured.

... 123 more lines ...
Attachment 2: 2010-05-03_dalsa1m60_image_test_pattern_and_spots.tif
2010-05-03_dalsa1m60_image_test_pattern_and_spots.tif
Attachment 3: 2010-05-03_dalsa1m60_image_test_pattern_right_side.tif
2010-05-03_dalsa1m60_image_test_pattern_right_side.tif
Attachment 4: dalsa_1m60.cfg
#
# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"
#

# camera name/description
#
camera_class:                  "Dalsa"
camera_model:                  "1M60"
camera_info:                   "12 bit dual channel camera link"

... 39 more lines ...
  27   Tue May 4 09:18:15 2010 AidanComputingHartmann sensorAdded aliases and icons for EPICS commands and dataviewer etc. to hartmann

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"

  28   Tue May 4 10:30:07 2010 AidanComputingHartmann sensorEPICS and MEDM screen for Hartmann sensor

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

  Digitizer Board Temperature Sensor Board Temperature
Dalsa 1M60 menu command vt vt

Response from 1M60

Camera Temperature on Digitizer Board: 47.2 Celsius Camera Temperature on Sensor Board: 39.4 Celsius
Menu accessed via MATLAB: unix('/opt/EDTpdv/serial_cmd vt') MATLAB: unix('/opt/EDTpdv/serial_cmd vt')
Temperature stored in MATLAB: local variable called DBtemp (from the numerical sub-string) MATLAB: local variable called SBtemp (from the numerical sub-string)
EPICS channel written via MATLAB: unix(['ezcawrite {channel-name} ' num2str(DBtemp)]) MATLAB: unix(['ezcawrite {channel-name} ' num2str(SBtemp)])
EPICS channel defined in HWS.db HWS.db
Channel name C4:TCS-HWS_TEMP_DIGITIZER C4:TCS-HWS_TEMP_SENSOR

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

although this doesn't execute it in the background. The MATLAB routine /home/controls/matlab_scripts/read_dalsa_temperature_write_to_epics.m is run continuously to access the serial port, get the temperature data and to write it to the EPICS channels. These were then available to read in the Hartmann sensor MEDM screen which is shown below. Also shown is a StripTool monitoring the temperatures. I had just turned off a fan that was cooling the 1M60 which is why the temperature is rising.
 
 
 

 

 

Attachment 1: Screenshot-C4HWS_medm_21.adl_(edited).png
Screenshot-C4HWS_medm_21.adl_(edited).png
Attachment 2: Screenshot-StripTool_Graph_Window.png
Screenshot-StripTool_Graph_Window.png
Attachment 3: HWS.db
record(ai,"C4:TCS-HWS_TEMP_DIGITIZER")


record(ai,"C4:TCS-HWS_TEMP_SENSOR")
Attachment 4: HWS.cmd
dbLoadRecords "HWS.db"
iocInit
Attachment 5: read_dalsa_temperature_write_to_epics.m
% get the temperature off the 1M60
% written by Aidan Brooks. 22nd Apr 2010

% define aliases
ezcawrite = '/cvs/opt/apps/Linux/gds/bin/ezcawrite';


ii = 1;
while ii == 1
    [s, r] = unix('/opt/EDTpdv/serial_cmd vt');
... 54 more lines ...
  29   Tue May 4 13:35:13 2010 AidanComputingHartmann sensorHartmann temperature channels in frame builder

 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]


 

 

 

  30   Wed May 5 09:04:01 2010 AidanComputingHartmann sensorAdded /home/controls/scripts/modules directory to PYTHONPATH on hartmann

 I added the following line to ~/.bashrc

 

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

This adds the above directory to PYTHONPATH and allows those modules in that directory to be access from anywhere.

 

  31   Wed May 5 18:45:51 2010 AidanComputingHartmann sensorPython code to interface the Dalsa1M60 and export the temperature to EPICS

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

Attachment 1: dalsa_to_epics.py
#!/usr/bin/python

# Import the Dalsa1M60 packzge
import Dalsa1M60, subprocess

# define the serial command location
serial_cmd_location = '/opt/EDTpdv/serial_cmd'

# start a loop that continually gets the temperatures
getTemperatures = 1
... 18 more lines ...
Attachment 2: VerifyTemperature.py
#!/usr/bin/python

# part of the Dalsa1M60 package
# a module for verifying the temperature of the Dalsa 1M60
#
# The serial command 'vt' is sent to the camera. The camera responds as follow
s
#    > vt
#    Camera Temperature on Digitzer Board: 47.2 Celsius
#    Camera Temperature on Sensor Board: 39.4 Celsius
... 65 more lines ...
Attachment 3: dalsa_1m60.cfg
#
# CAMERA_MODEL "Dalsa 1m60 config file (freerun)"
#

# camera name/description
#
camera_class:                  "Dalsa"
camera_model:                  "1M60"
camera_info:                   "12 bit dual channel camera link"

... 51 more lines ...
  32   Thu May 6 10:34:38 2010 AidanComputingHartmann sensorEPICS and MEDM screen for Hartmann sensor - part 2

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.

Attachment 1: dalsa_to_epics.py
#!/usr/bin/python

# Import the Dalsa1M60 packzge
import Dalsa1M60, subprocess

# define the serial command location
serial_cmd_location = '/opt/EDTpdv/serial_cmd'

# start a loop that continually gets the temperatures
getTemperatures = 1
... 75 more lines ...
Attachment 2: GetCameraParameters.py
#!/usr/bin/python

# NAME
#       GetCameraParameters - a module for getting the Dalsa 1M60 parameters
#
# PACKAGE
#       Part of the Dalsa1M60 python package
#
# SYNOPSIS
#       GetCameraParameters( serial_cmd_location  )
... 412 more lines ...
Attachment 3: HWS.db
record(ai,"C4:TCS-HWS_TEMP_DIGITIZER")
record(ai,"C4:TCS-HWS_TEMP_SENSOR")
record(ai, "C4:TCS-HWS_TAP1GAIN")
record(ai, "C4:TCS-HWS_TAP2GAIN")
record(ai, "C4:TCS-HWS_PRETRIGGER")
record(ai, "C4:TCS-HWS_DATA_MODE")
record(ai, "C4:TCS-HWS_BINNING_MODE")
record(ai, "C4:TCS-HWS_GAIN_MODE")
record(ai, "C4:TCS-HWS_OUTPUT_CONFIG")
record(ai, "C4:TCS-HWS_EXPOSURE_MODE")
... 27 more lines ...
Attachment 4: C4TCS.ini
[default]
dcuid=4
datarate=16
gain=1.0
acquire=1
ifoid=0
datatype=4
slope=1.0
offset=0
units=NONE
... 14 more lines ...
  33   Thu May 6 12:32:11 2010 AidanComputingHartmann sensordalsa_to_epics Python script crashed ...

Here's the error:

 

 Traceback (most recent call last):

  File "./dalsa_to_epics.py", line 81, in ?
    stdout = subprocess.PIPE)    
  File "/usr/lib64/python2.4/subprocess.py", line 550, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.4/subprocess.py", line 916, in _execute_child
    errpipe_read, errpipe_write = os.pipe()
OSError: [Errno 24] Too many open files

[2]+  Exit 1                  ./dalsa_to_epics.py  (wd: ~/scripts)
(wd now: /cvs/users/abrooks/advLigo/HWS)
 
  35   Tue May 11 10:32:00 2010 AidanComputingHartmann sensorPeak detection and centroiding code - review

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.

 

Quote:

 

 

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

 

 

 

Attachment 1: test_centroid_code.m
% generate an blank image
imarr = zeros(1024, 1024);

% get the background and intensity levels
bckgrd = 700.0;
I1 = 56000.0;

% get the 2D coordinate arrays
x = 1:1024;
... 61 more lines ...
  36   Thu May 13 16:54:46 2010 AidanComputingHartmann sensorRunning MATLAB programs in C on CentOS - only use R2008b for less hassle

 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. 

 

  37   Mon May 17 19:41:13 2010 AidanComputingFrame GrabberC code that calls MATLAB engine and centroiding algorithms

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 
Attachment 1: simple_hartmann.c
/**
 * @file
 * An example program to show usage of EDT PCI DV library to acquire and
 * optionally save single or multiple images from devices connected to EDT
 * high speed digital video interface such as the PCI DV C-Link or PCI DV
 * FOX / RCX.
 * 
 * Provided as a starting point example for adding digital video acquisition
 * to a user application.  Includes optimization strategies that take
 * advantage of the EDT ring buffer library subroutines for pipelining image
... 521 more lines ...
Attachment 2: centroid_image.m
function centroids = centroid_image(image, centroids)
%
% This function centroids a supplied image. It returns a centroids structure
%
% 'centroids' structure
% --------------------
% centroids.image_background_level  - the background intensity of an image
%                                     with no illumination on it
%          .spot_radius             - the radius of a hartmann spot
%          .spot_threshold_level    - the minimum intensity of pixels used to
... 98 more lines ...
Attachment 3: get_defocus.m
function defocus = get_defocus(centroids)
% 
% a function to extract the defocus of the gradient field
%
% 'centroids' structure
% --------------------
% centroids.image_background_level  - the background intensity of an image
%                                     with no illumination on it
%          .spot_radius             - the radius of a hartmann spot
%          .spot_threshold_level    - the minimum intensity of pixels used to
... 56 more lines ...
Attachment 4: build_simple_hartmann.sh
#!/bin/bash


gcc -O2 -I/opt/EDTpdv -I/apps/matlab_R2008b/extern/include -I/apps/matlab_R2008b/simulink/include -DMATLAB_MEX_FILE -c -D_GNU_SOURCE -fexceptions -I/apps/matlab_R2008b/extern/include -DMX_COMPAT_32 -O -DNDEBUG simple_hartmann.c


gcc -O2 -I/opt/EDTpdv -I/apps/matlab_R2008b/extern/include -I/apps/matlab_R2008b/simulink/include -DMATLAB_MEX_FILE -c -D_GNU_SOURCE -fexceptions -I/apps/matlab_R2008b/extern/include -DMX_COMPAT_32 -O -DNDEBUG /apps/matlab_R2008b/extern/src/mexversion.c

gcc -O2 -O -I/opt/EDTpdv -o /opt/EDTpdv/hartmann/bin/simple_hartmann simple_hartmann.o mexversion.o -L/opt/EDTpdv -lpdv -lpthread -lm -ldl -Wl,-rpath-link,/apps/matlab_R2008b/bin/glnxa64 -L/apps/matlab_R2008b/bin/glnxa64 -leng -lmx -lstdc++
  38   Tue May 18 09:33:44 2010 AidanComputingEPICSAdded defocus and other Hartmann sensor channels to EPICS and DAQ

 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:
[controls@hartmann softIoc]$  /cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc -S  HWS.cmd &
[3] 11280
[controls@hartmann softIoc]$ dbLoadRecords "HWS.db"
iocInit
Starting iocInit
############################################################################
## EPICS R3.14.10- $R3-14-10-RC2$ $2008/10/10 15:01:51$
## EPICS Base built Oct 28 2009
############################################################################
iocRun: All initialization complete

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

Done!

 

  39   Thu May 20 08:20:54 2010 AidanComputingHartmann sensorCentroiding algorithm and code to generate simulated data

 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

Attachment 1: test_spot_generation_and_centroiding.m
% example usage of generate_simulated_spots and centroid_image

clear all
close all



%% example 1 - 
%----------------------------------------------------------
npixels = 1024;          % the number of pixels in the image
... 143 more lines ...
Attachment 2: generate_simulated_spots.m
function output = generate_simulated_spots(npixels, digitizeFLAG, ...
                          IntensityNoiseFLAG, positionNoiseFLAG)
%
% a function to generate an image of spots to centroid and to provide the original 
% locations of the spots. 
% 
% input
% -----
% npixels - pixels in output image
% digitizeFLAG:          0 - floating point array is output
... 160 more lines ...
Attachment 3: centroid_image.m
function centroids = centroid_image(image, centroids)
%
% This function centroids a supplied image. It returns a centroids structure
%
% 'centroids' structure
% --------------------
% centroids.image_background_level  - the background intensity of an image
%                                     with no illumination on it
%          .spot_radius             - the radius of a hartmann spot
%          .spot_threshold_level    - the minimum intensity of pixels used to
... 95 more lines ...
  40   Thu May 20 10:44:13 2010 AidanElectronicsSLEDQPhotonics 980nm source power

dV = 0.385V

Responsivity= 0.65A/W

Transimpedance = 1.5E4 V/A

therefore power= 0.385V / (1.5E4 * 0.65 V/W) = 40uW

 

 

  41   Thu May 20 17:08:36 2010 AidanElectronicsSLEDSLED module - and driver - LIGO D1000892 - and Hartmann sensor

Verified that the test-point for the current limit pot on the driver (Wavelength Electronics - LDTC 0520) was at 0.5V. Driver is set to INTERNAL set point at the moment. This is down about 10% below the current limited point.

Voltage across TP7 and TP9 = 0.970V = LD Current Mon

Voltage across TP2 and TP3 = 0.017V = LD P Mon

 

--- Hartmann sensor ---

-set the sampling rate on the CCD to 16HZ. With the current alignment and intensity this gives as maximum intensity of around 3850 out of 4095. Thus the pixels are not saturated.

- centroid_image located some of the spots - see attached image of spots where those located by the algorithm and circled. I need to play with the threshold level and spot_radius to get this to work properly.

 

 

Attachment 1: 2010-05-20_hartmann_image_and_located_spot.jpg
2010-05-20_hartmann_image_and_located_spot.jpg
  42   Mon May 24 19:17:32 2010 AidanLaserHartmann sensorReplaced Brass Plate with Invar Hartmann Plate

I just replaced the brass Hartmann plate with the Invar one. The camera was off during the process but has been turned on again. The camera is now warming up again. I've manually set the temperature in the EPICS channels by looking at the on-board temperature via the serial communications.

 I also made sure the front plate was secured tightly.

  43   Wed May 26 06:47:02 2010 AidanLaserSLEDSwitched off SLED - 6:40AM
  44   Wed May 26 14:58:04 2010 AidanMiscHartmann sensorHartmann sensor cooling fins added

14:55 -  Mindy stopped by with the copper heater spreaders and the cooling fins for the Hartmann sensor. We've set them all up and have turned on the camera to see what temperature above ambient is achieves.

17:10 - Temperature of the HWS with no active cooling( Digitizer = 44.1C, Sensor = 36.0C, Ambient = 21.4C)

 

Attachment 1: HWS_CONFIG1.jpg
HWS_CONFIG1.jpg
  45   Thu May 27 08:25:37 2010 AidanElectronicsHartmann sensorHartmann sensor cooling fins added - base piece removed

 8:10AM - I removed the base plate from the Hartmann sensor. I want to know what steady-state temperature the HWS achieves without the plate.

The photo below shows the current configuration.

11:22AM - (Digitizer - 52.2C, Sensor - 43.8C, Ambient - 21.8C)

Attachment 1: HWS_CONFIG2.jpg
HWS_CONFIG2.jpg
  46   Thu May 27 13:18:51 2010 AidanElectronicsHartmann sensorRemoved Cooling fins from Hartmann sensor

I removed the cooling fins from the Hartmann sensor to see what steady-state temperature it reached without any passive cooling elements. I also dropped the set-point temperature for the lab to help keep for getting too hot.

After nearly 3 hours the temperature is:

(Digitizer: 54.3C, Sensor: 46.6C, Ambient: 19.6C)

 

 

Attachment 1: HWS_CONFIG3.jpg
HWS_CONFIG3.jpg
  47   Thu May 27 15:42:06 2010 AidanElectronicsHartmann sensorHartmann sensor with just the base piece

I switched in just the base piece of the Hartmann sensor. The cooling fins are removed. I bolted the camera securely to the base plate and I bolted the plate securely to the table.

 5:00PM - (Digitizer = 41.9C, Sensor = 33.8C, Ambient = 19.3C)

 

Attachment 1: HWS_CONFIG4.jpg
HWS_CONFIG4.jpg
  48   Thu May 27 17:49:02 2010 AidanElectronicsHartmann sensorHartmann sensor cooling fins added - base piece added

 Back to Configuration 1 again - this time the fins were bolted very securely to the camera.

 7:25 PM - [about 2 hours later] - Digitizer = 39.7C, Sensor = 31.4C, Ambient = 19.0C

 

 

Attachment 1: HWS_CONFIG1-tight.jpg
HWS_CONFIG1-tight.jpg
  50   Wed Jun 16 11:47:11 2010 AidanMiscHartmann sensorSpot displacement maps - temperate sensitivity tests - PRISM

I think that the second plot is just showing PRISM and converting it to its radial components. This is due to the fact that the sign of the spot displacement on the LHS is the opposite of the sign of the spot displacement on the RHS. For spherical or cylindrical power, the sign of the spot displacement should be the same on both the RHS and the LHS.

I've attached a Mathematica PDF that illustrates this.

 


Quote:

Results of initial measurement of temperature sensitivity of Hartmann sensor

"Cold" images were taken at the following temperature:
| before | 32.3 | 45.3 | 37.0 |
| after  | 32.4 | 45.6 | 37.3 |

"Hot" Images were taken at the following temperature:

| before | 36.5 | 48.8 | 40.4 |
| after  | 36.4 | 48.8 | 40.4 |

"before" are the temperatures just before taking 5000 images, and "after" are
the temperatures just after taking the images. First column is the temperature
measured using the IR temp sensor pointed at the heat sink, the second column the
camera temperature, and the third column the sensor board temperature.

Temperature change produced by placing a "hat" over the top of the HP assembly and the top of the heatsinks.

Averaged images "cool" and "hot" were created using 200 frames (each).

Aberration parameter values are as follows:

Between cool and hot images (cool spots - hot spots)

     p: 4.504320557133363e-005
    al: 0.408248504544179
   phi: 0.444644135542724
     c: 0.001216006036395
     s: -0.002509569677737
     b: 0.054773177423349
    be: 0.794567342929695
     a: -1.030687344054648

Between cool images only

     p: 9.767143368103721e-007
    al: 0.453972584677992
   phi: -0.625590459774765
     c: 2.738206187344315e-004
     s: 1.235384158257808e-006
     b: 0.010135170457321
    be: 0.807948378729832
     a: 0.256508288049258

Between hot images only

     p: 3.352035441252169e-007
    al: -1.244075541477539
   phi: 0.275705676833192
     c: -1.810992355666772e-004
     s: 7.076678388064736e-005
     b: 0.003706221758158
    be: -0.573902879552339
     a: 0.042442307609231

Attached are two contour plots of the radial spot displacements, one between
cool and hot images, and the other between cool images only. The color
bars roughly indicate the values of maximum and minimum spot
displacements.

Possible causes:

1. anisotropy of the thermal expansion of the invar foil HP caused by the rolling

2. non-uniform clamping of the HP by the clamp plate

3. vertical thermal gradient produced by the temperature raising method

4. buckling of the HP due to slight damage (dent)

 

Attachment 1: Prism_as_radial_vector.pdf
Prism_as_radial_vector.pdf Prism_as_radial_vector.pdf Prism_as_radial_vector.pdf
  56   Wed Jun 23 06:49:48 2010 AidanMiscHartmann sensorSURF Log -- Day 5, more Hartmann image preliminary analysis

Nice work!

 

Quote:

 Today I spoke with Dr. Brooks and got a rough outline of what my experiment for the next few weeks will entail. I'll be getting more of the details and getting started a bit more, tomorrow, but today I had a more thorough look around the Hartmann lab and we set up a few things on the optical table. The OLED is now focused through a microscope to keep the beam from diverging quite as much before it hits the sensor, and the beam is roughly aligned to shine onto the Hartmann plate. The Hartmann images currently look like this (on a color scale of intensity):

hws.png

Where this image was taken with the camera set to exposure time 650 microseconds, frequency 58Hz. The visible 'streaks' on the image are believed to possibly be an artifact of the camera's data acquisition process.

I tested to see whether the same 'flickering' is present in images under this setup.

For frequency kept at 58Hz, the following statistics were found from a 200x200 pixel box within series of 10 images taken at different exposure times. Note that the range on the plot has been reduced to the region near the relevant feature, and that this range is not being changed from image to image:

750 microseconds:

750us.png

1000 microseconds:

1000us.png

1500 microseconds:

1500us.png

2000 microseconds:

2000us.png

3000 microseconds:

3000us.png

4000 microseconds:

4000us.png

5000 microseconds. Note that the background level is approaching the level of the feature:

5000us.png

6000 microseconds. Note that the axis setup is not restricted to the same region, and that the background level exceeds the level range of the feature. This demonstrates that the 'feature' disappears from the plot when the plot does not include the specific range of ~115-130:

8000us.png

 

When images containing the feature intensities are averaged over a greater number of images, the plot takes on the following appearance (for a 200x200 box within a series of 100 images, 3000us exposure time):

hws3k.png

This pattern changes a bit when averaged over more images. It looks as though this could, perhaps, just be the result of the decrease in the standard deviation of the standard deviations in each pixel resulting from the increased number of images being considered for each pixel (that is, the line being less 'spread out' in the y-axis direction). 

 

To demonstrate that frequency doesn't have any effect, I got the following plots from images where I set the camera to different frequencies then set the exposure time to 3000us (I wouldn't expect this to have any effect, given the previous images, but these appear to demonstrate that the 'feature' does not vary with time):

 

Set to 30Hz:

f30Hz.png

Set to 1Hz:

f1Hz.png

 

To make sure that something weird wasn't going on with my algorithm, I did the following: I constructed a 10-component vector of random numbers. Then, I concatenated that vector besides itself ten times. Then, I concatenated that vector into a 3D array by scaling the 2D vector with ten different integer multiples, ensuring that the standard deviations of each row would be integer multiples of each other when the standard deviation was found along the direction of the random change (I chose the integer multiples to ensure that some of these values would fall within the range of  115-130). Thus, if my function wasn't making any weird mistakes, I would end up with a linear plot of standard deviation vs. mean, with a slope of 1. When the array was inputted into the function with which the previous plots were found, the output plot was indeed observed to be linear, and a least squares regression of the mean/deviation data confirmed that the slope was exactly 1 and the intercept exactly 0. So I'm pretty certain that the feature observed in these plots is not any sort of 'artifact' of the algorithm used to analyze the data (and all the functions are pretty simple, so I wouldn't expect it to be, but it doesn't hurt to double-check).

 

I would conjecture from all of this that the observed feature in the plots is the result of some property of the CCD array or other element of the camera. It does not appear to have any dependence on exposure time or to scale with the relative overall intensity of the plots, and, rather, seems to depend on the actual digital number read out by the camera. This would suggest to me, at first glance, that the behavior is not the result of a physical process having to do with the wavefront.

 

EDIT: Some late-night conjecturing: Consider the following,

I don't know how the specific analog-to-digital conversion onboard the camera works, but I got to thinking about ADCs. I assume, perhaps incorrectly, that it works on roughly the same idea as the Flash ADCs that I dealt with back in my Digital Electronics class -- that is, I don't know if it has the same structure (a linear resistor ladder hooked up to comparators which compare the ladder voltages to the analog input, then uses some comb logic circuit which inputs the comparator outputs and outputs a digital level) but I assume that it must, at some level, be comparing the analog input to a number of different voltage thresholds, considering the highest 'threshold' that the analog input exceeds, then outputting the digital level corresponding to that particular threshold voltage.

Now, consider if there was a problem with such an ADC such that one of the threshold voltages was either unstable or otherwise different than the desired value (for a Flash ADC, perhaps this could result from a problem with the comparator connected to that threshold level, for example). Say, for example, that the threshold voltage corresponding to the 128th level was too low. In that case, an analog input voltage which should be placed into the 127th level could, perhaps, trip the comparator for the 128th level, and the digital output would read 128 even when the analog input should have corresponded to 127.

So if such an ADC was reading a voltage (with some noise) near that threshold, what would happen? Say that the analog voltage corresponded to 126 and had noise equivalent to one digital level. It should, then, give readings of 125, 126 or 127. However, if the voltage threshold for the 128th level was off, it would bounce between 125, 126, 127 and 128 -- that is, it would appear to have a larger standard deviation than the analog voltage actually possessed.

Similarly, consider an analog input voltage corresponding to 128 with noise equivalent to one digital level. It should read out 127, 128 and 129, but with the lower-than-desired threshold for 128 it would perhaps read out only 128 and 129 -- that is, the standard deviation of the digital signal would be lower for points just above 128.

This is very similar to the sort of behavior that we're seeing!

Thinking about this further, I reasoned that if this was what the ADC in the camera was doing, then if we looked in the image arrays for instances of the digital levels 127 and 128, we would see too few instances of 127 and too many instances of 128 -- several of the analog levels which should correspond to 127 would be 'misread' as 128. So I went back to MATLAB and wrote a function to look through a 1024x1024xN array of N images and, for every integer between an inputted minimum level and maximum level, find the number of instances of that level in the images. Inputting an array of 20 Hartmann sensor images, along with minimum and maximum levels of 50 and 200, gave the following:

levelinstances.png

Look at that huge spike at 128! This is more complex of behavior than my simple idea which would result in 127 having "too few" values and 128 having "too many", but to me, this seems consistent with the hypothesis that the voltage threshold for the 128th digital level is too low and is thus giving false output readings of 128, and is also reducing the number of correct outputs for values just below 128. And assuming that I'm thinking about the workings of the ADC correctly, this is consistent with an increase in the standard deviation in the digital level for values with a mean just below 128 and a lower standard deviation for values with a mean just above 128, which is what we observe.

 

This is my current hypothesis for why we're seeing that feature in the plots. Let me know what you think, and if that seems reasonable.

 

 

  59   Fri Jun 25 10:47:08 2010 AidanMiscaLIGO ModelingUploaded aLIGO axicon+ITM COMSOL model to the 40m SVN

I added a COMSOL model of the aLIGO ITM being heated by an axicon-formed annulus to the 40m SVN. The model assumes a fixed input beam size into an axicon pair and then varies the distance between the axicons. The output is imaged onto the ITM with varying magnitudes. The thermal lens is determined in the ITM and added  to the self-heating thermal lens (assuming 1W absorption, I think - need to check). The power in the annulus is varied until the sum of the two thermal lenses scatters the least amount of power out of the TEM00 mode of the IFO.

https://nodus.ligo.caltech.edu:30889/svn/trunk/comsol/TCS/aLIGO/

The results across the parameter space (axicon separation and post-axicon-magnification) are attached. These were then mapped from this space to the space of annulus thickness vs annulus diameter, (see elog here).

 

 

Attachment 1: aLIGO_axicon_spacing_post-magnification_optimization.jpg
aLIGO_axicon_spacing_post-magnification_optimization.jpg
  60   Fri Jun 25 10:59:43 2010 AidanMiscaLIGO ModelingUploaded aLIGO axicon+ITM COMSOL model to the 40m SVN

Here are the results in the annulus thickness vs annulus diameter space ...

Quote:

I added a COMSOL model of the aLIGO ITM being heated by an axicon-formed annulus to the 40m SVN. The model assumes a fixed input beam size into an axicon pair and then varies the distance between the axicons. The output is imaged onto the ITM with varying magnitudes. The thermal lens is determined in the ITM and added  to the self-heating thermal lens (assuming 1W absorption, I think - need to check). The power in the annulus is varied until the sum of the two thermal lenses scatters the least amount of power out of the TEM00 mode of the IFO.

https://nodus.ligo.caltech.edu:30889/svn/trunk/comsol/TCS/aLIGO/

The results across the parameter space (axicon separation and post-axicon-magnification) are attached. These were then mapped from this space to the space of annulus thickness vs annulus diameter, also attached.

 

 

 

Attachment 1: Screen_shot_2010-06-25_at_11.01.38_AM.png
Screen_shot_2010-06-25_at_11.01.38_AM.png
  66   Tue Jul 20 15:45:51 2010 AidanComputingGeneralAdd fixed IP addresses to local machines in TCS lab

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

  67   Tue Jul 20 18:13:06 2010 AidanComputingGeneralAdded TCS channels to frame builder

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

 contents of tcs_daq: /target/TCS_westbridge.db

grecord(ai,"C4:TCS-ATHENA_ADC0")
{
field(DTYP,"ATHENA")
field(INP,"#C0 S0")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC1")
{
       field(DTYP,"ATHENA")
field(INP,"#C0 S1")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC2")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S2")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC3")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S3")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC4")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S4")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC5")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S5")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC6")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S6")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC7")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S7")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC8")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S8")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC9")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S9")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC10")
{
        field(DTYP,"ATHENA")
        field(INP,"#C0 S10")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC11")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S11")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC12")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S12")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC13")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S13")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC14")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S14")
        field(SCAN,".1 second")
}
grecord(ai,"C4:TCS-ATHENA_ADC15")
        field(DTYP,"ATHENA")
        field(INP,"#C0 S15")
        field(SCAN,".1 second")
}
grecord(ao,"C4:TCS-ATHENA_DAC0")
{
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S0")
        field(HOPR,"32768")
        field(LOPR,"-32768")
}
 
grecord(ao,"C4:TCS-ATHENA_DAC1")
{
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S1")
}
grecord(bi,"bi0")
{
        field(SCAN,".1 second")
field(DTYP,"ATHENA")
field(INP,"#C0 S8")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
grecord(bo,"C4:TCS-ATHENA_BO0")
{
        field(DOL,"HeartBeat")
        field(OMSL,"closed_loop")
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S1")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
grecord(bo,"C4:TCS-ATHENA_BO1")
{
        field(DOL,"LevelAlarm")
        field(OMSL,"closed_loop")
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S2")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
grecord(bo,"C4:TCS-ATHENA_BO2")
{
        field(DOL,"Pressure_OK")
        field(OMSL,"closed_loop")
        field(DTYP,"ATHENA")
        field(OUT,"#C0 S3")
        field(ZNAM,"zero")
        field(ONAM,"one")
}
 
 

 

  68   Thu Jul 22 11:02:59 2010 AidanComputingGeneralRestarted hartmann machine

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.

 

 

  70   Fri Jul 23 10:33:08 2010 AidanComputingHartmann sensorDalsa camera ADC 8th digitizer error

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:

 

Number of counts Hex Code

128

 080
384  180
640  280
896  380
1152  480
1408  580
1664  680
1920  780
2176  880
2432  980
2688  A80
2944  B80
3200  C80

 

Attachment 1: histogram_of_dalsa_intensity.pdf
histogram_of_dalsa_intensity.pdf
  71   Fri Jul 23 12:33:51 2010 AidanComputingHartmann sensorInvar clamp scatter

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

  72   Fri Jul 23 12:38:58 2010 AidanComputingHartmann sensorImages for Dalsa

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.

 

Attachment 1: dark_0000.jpg
dark_0000.jpg
Attachment 2: bright_0000.jpg
bright_0000.jpg
  73   Fri Jul 23 19:52:49 2010 AidanComputingHartmann sensorDalsa camera ADC 8th digitizer error

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.

Quote:

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:

 

Number of counts Hex Code

128

 080
384  180
640  280
896  380
1152  480
1408  580
1664  680
1920  780
2176  880
2432  980
2688  A80
2944  B80
3200  C80

 

 

Attachment 1: image-location-of-excess_pixel_count_pixels.jpg
image-location-of-excess_pixel_count_pixels.jpg
  74   Sat Jul 24 10:50:14 2010 AidanElectronicsHartmann sensorLab Temperature and HWS temperature: pre-indium

 Hour-long trend puts the lab temperature at 19.51C

Dalsa temperature:

 

Camera Temperature on Digitizer Board: 41.0 Celsius
Camera Temperature on Sensor Board: 32.9 Celsius
OK>
 
There is currently no Indium in the HWS.

 

  75   Sun Jul 25 16:24:56 2010 AidanComputingSLEDSuperlum SLED test integrated with DAQ - new channel names

 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.

  76   Mon Jul 26 09:42:30 2010 AidanComputingSLEDLong term test on SLED started - Day 0

 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.

Attachment 1: SLED_superlum_long_term_test_0001A.pdf
SLED_superlum_long_term_test_0001A.pdf
Attachment 2: SLED_superlum_long_term_test_0001B.pdf
SLED_superlum_long_term_test_0001B.pdf
  77   Mon Jul 26 12:17:25 2010 AidanElectronicsHartmann sensorAdded Indium to HWS

 I added some 0.004" thick indium sheet to the copper heat spreaders and and the heat sinks on the side of the HWS to try and improve the thermal contact. Once installed the steady state temperature of the sensor was the same as before. It's possible that the surface of the copper is even more uneven than 0.004".

 

 

Attachment 1: indium-01.jpg
indium-01.jpg
Attachment 2: indium-03.jpg
indium-03.jpg
Attachment 3: indium-05.jpg
indium-05.jpg
Attachment 4: indium-02.jpg
indium-02.jpg
Attachment 5: indium-04.jpg
indium-04.jpg
  79   Tue Jul 27 08:31:10 2010 AidanElectronicsSLEDLong term SLED test - Day 1

 The measurement from the on-board PD of the Superlum SLED seems to be falling. This effect started around 5PM last night which is right about the time we moved the position of the PD that the SLED is illuminating on the optical table (via optical fiber).

Curiously, the current set point and delivered current to the SLED are dropping as well. 

Attachment 1: SLED_superlum_long_term_test_0002A.pdf
SLED_superlum_long_term_test_0002A.pdf
  80   Wed Jul 28 18:32:12 2010 AidanElectronicsSLEDSLED long term test - Day 2

Here's the data from the last 2 1/2 days of running the SLED. The decrease in photo-current measured by the on-board photo-detector is consistent with the decrease in the current set-point and the delivered current, but it is not clear why these should be changing.

Strictly speaking I should add some analysis that shows that delta_PD_voltage_measured = delta_I_set_measured * [delta_PD_voltage/delta_I_set (I_set)]_calculated ...

Attachment 1: SLED_superlum_long_term_test_0003A.pdf
SLED_superlum_long_term_test_0003A.pdf
  81   Thu Jul 29 10:09:19 2010 AidanElectronicsSLEDSLED long term test - Day 2

I've attached the Acceptance Test Report data from SUPERLUM for this SLED. I've also determined the expected percentage decrease in power/photo-current per mA drop in forward current.

The measured decrease in forward current over the last 2 1/2 days is around 1.4mA from around 111mA. The expected drop in power is thus (4.5% per mA)*(1.4mA) = 6.3%.

The drop in photo-current is around 37.5mA to 35mA = 2.5mA. The percentage drop is around 100*(2.5mA)/(36.3mA) = 6.9%. 

Therefore, the drop in measured power is consistent with what we would expect given the decrease in forward current (which is consistent with the drop in the set point). Why the set-point is dropping is still a mystery.

Quote:

Here's the data from the last 2 1/2 days of running the SLED. The decrease in photo-current measured by the on-board photo-detector is consistent with the decrease in the current set-point and the delivered current, but it is not clear why these should be changing.

Strictly speaking I should add some analysis that shows that delta_PD_voltage_measured = delta_I_set_measured * [delta_PD_voltage/delta_I_set (I_set)]_calculated ...

 

Attachment 1: superlum_SLED_ATR.pdf
superlum_SLED_ATR.pdf
  82   Fri Jul 30 10:04:54 2010 AidanComputingHartmann sensorRestarted the HWS EPICS channels

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

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

  83   Fri Jul 30 11:01:31 2010 AidanComputingHartmann sensorEPICS softIoc alias

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

 

alias HWSIoc='/cvs/cds/caltech/target/softIoc/startHWSIOC.sh'
 
and the bash script is:
 

#!/bin/bash
 
cd /cvs/cds/caltech/target/softIoc
 
/cvs/opt/epics-3.14.10-RC2-i386/base/bin/linux-x86/softIoc -S  /cvs/cds/caltech/
target/softIoc/HWS.cmd &
 
cd -
 

 

ELOG V3.1.3-