40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  TCS elog, Page 4 of 5  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  139   Mon Apr 18 15:06:53 2011 AidanThings to BuyHartmann sensorOrdered 2" optics from Newport

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

  • 2x 2" 50/50 beam splitter: 20B20BS.2
  • 6x 2" NIR mirrors: 5122
  • 8x 2" Ultima mirror mounts: U200-A2K
  34   Thu May 6 21:32:26 2010 Won KimComputingHartmann sensorPeak detection and centroiding code

 

 

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: detect_peaks_uml.m
function ctr = detect_peaks_uml(image,radius)
% Usage example:
% positions = detect_peaks_uml(myimage,10);
% 
% total number of peaks detected: length(positions.WeightedCentroid)
% access the coordinates of the nth peak:
% positions(n).Weightedcentroid(1), positions(n).WeightedCentroid(2)

weighted_image = image .^ 2;
background = imopen(weighted_image,strel('disk',radius));
... 11 more lines ...
  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 ...
  239   Fri Aug 9 20:33:11 2019 JonElectronicsRing HeaterPower-regulated heater ready to use

Despite some considerable time spent, I was not able to get the Omega SCR controllers working. The first unit definitely arrived damaged. None of its LED indicator lights ever functioned, despite those on the second controller working fine under the same setup. I tried swapping in the second controller, but it has no voltage output and a red LED is illuminated which, according to the manual, means "malfunction on trigger board" or "open SCR."  Either way, the remedy is to "consult factory."

Since we have get moving with data collection, I installed a simple variable transformer (borrowed from the 40m) which steps up/down the AC voltage from 0-120 V with the turn of a knob. I soldered the leads of one of the heaters to a standard power cable which plugs directly into the transformer. I have tested it and confirmed it to work.

Attachment 1: IMG_3576.jpg
IMG_3576.jpg
Attachment 2: IMG_3577.jpg
IMG_3577.jpg
  132   Fri Apr 1 09:51:45 2011 AidanComputingHartmann sensorPrism measurement

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

Conclusions to follow ...

Attachment 1: Hartmann_Sensor_prism_measurement_2011-03-31.pdf
Hartmann_Sensor_prism_measurement_2011-03-31.pdf
Attachment 2: Hartmann_Sensor_Prism_measurement_times_series_2011-03-31.pdf
Hartmann_Sensor_Prism_measurement_times_series_2011-03-31.pdf
  129   Wed Mar 30 12:55:54 2011 AidanLaserHartmann sensorPrism modulation experiment

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

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

  130   Thu Mar 31 11:27:02 2011 AidanLaserHartmann sensorPrism modulation experiment

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

The frequency is still 10mHz.

Quote:

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

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

 

  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 ...
  154   Fri Sep 2 14:41:48 2011 AidanComputingHartmann sensorQFLD-950-3S long term test finished

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

  238   Tue Aug 6 19:22:28 2019 JonElectronicsComputingQIL NFS server set up

I've started building the NFS server for the QIL cymac. It's sitting on the workbench in the TCS lab next to the rack. Please don't move it or any of the parts behind it.

  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

 

 

  204   Thu Jan 18 10:09:50 2018 Jon RichardsonLaserGeneralRIN Measurement of 400 mW CO2 Laser in Progress

The 400 mW CO2 laser on the Hartmann table is currently configured for a measurement of its relative intensity noise. It is aligned to a TCS CO2P photodetector powered by a dual DC power supply beside the light enclosure. I got some data last night with the laser current dialed back for low output power (0.5-10 mW incident), but still need to analyze it. In the meantime please don't remove parts from the setup, as I may need to repeat the measurement with better power control.

  205   Mon Jan 22 10:39:32 2018 Jon RichardsonLaserGeneralRIN Measurement of 400 mW CO2 Laser in Progress

Attached for reference is the RIN measurement from the initial data.

Quote:

The 400 mW CO2 laser on the Hartmann table is currently configured for a measurement of its relative intensity noise. It is aligned to a TCS CO2P photodetector powered by a dual DC power supply beside the light enclosure. I got some data last night with the laser current dialed back for low output power (0.5-10 mW incident), but still need to analyze it. In the meantime please don't remove parts from the setup, as I may need to repeat the measurement with better power control.

 

Attachment 1: SRM_CO2_RIN_v1.pdf
SRM_CO2_RIN_v1.pdf SRM_CO2_RIN_v1.pdf
  88   Wed Aug 4 09:57:38 2010 Aidan, JamesComputingHartmann sensorRMS measurements with Hartmann sensor

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

Attachment 1: rms_analyze_centroids_aidan.pdf
rms_analyze_centroids_aidan.pdf
Attachment 2: RMS_WonCode.png
RMS_WonCode.png
Attachment 3: RMS_WonCodeLessPrism.png
RMS_WonCodeLessPrism.png
  212   Wed May 30 18:50:05 2018 awadeComputingDAQRebooted fb4

Time was still off by nine days as of yesterday.  I tried rebooting remotely to see if time would correct to system clock.  It didn't and fb4 hung.

Just manually restarted the box.  Now dataviewer is showing a 'Time Now'  of 5 Jan 1980.   

Not sure how to set the frame builder clock time. Ultimately the best solution is to have ADC cards but can we find a hack for now? Is it possible to run a cron script it to reset time to the computer time?

 

 

 

Quote:

The framebuilder on FB4 thinks the current time is 26-Jan-2018 6:18AM UTC. The date command on FB4 yields the correct date and time (5-Feb-2018 15:17 PST).

There is a major error with the framebuilder clock.

 

  237   Thu Aug 1 15:20:39 2019 Edita BytyqiLab InfrastructureOpticsReflector Mount and DC Supply

Yesterday, we were able to take some data using the 120 V DC power supply. The reflectors cut at the focal point and radius were both tested; the semi-circle cut proved to give a better focus, likely because roughly half the heat is lost using the focal-point reflectors. For upcoming tests, the semicircle reflectors will be used. We varied the surface shine by using the dull and reflective side of Al foil, as well as using the machined Al itself. The best result was given by using the more reflective side of Al foil.

Figure 1 shows the steady-state surface deformation profile detected by the HWS. The heaters don't have a uniform distribution along the wire, so more heat is radiated in the center of it, thus more of it is being focused to the center of the test optic. The data needs to be analyzed to determine the radius of the focus. Our rough estimate is about ~1.5 - 2 cm. We cannot collect any more data until we get a new power supply (AC 120 V).

Today, I came up with a new design for mounting the reflectors. I used a big 3-axis stage and a small 4-axis stage. This provides 5 degrees of freedom: 3 translational and 2 rotational, which is what we need for fine-tuning the focus and directing it at different angles incident to the test optic. The only problem with this design is that the 3-axis stage is too tall for the box, so the lid won't close.There is a smaller one available, but I have to figure out a way to increase its height, since the screw size is different from the ones on the pedestals available.

Additionally, Chub used metal-to-metal epoxy to glue a screw to the back of a reflector. I will wait until tomorrow to test it, because it is a slow acting epoxy. If it works, I have the necessary tools to do the same with the other reflectors. With the current deisgn the reflector wil be screwed in to where the round screw is in the stage. If it heats up a lot and affects the material of the stages, a small optical post (top of stage) will be used to make up for the absorbed heat.

 

Attachment 1: 20190731_170920.jpg
20190731_170920.jpg
Attachment 2: 20190801_145836.xcf
Attachment 3: 20190801_145836.jpg
20190801_145836.jpg
Attachment 4: 20190801_150635.jpg
20190801_150635.jpg
Attachment 5: 20190801_145842.jpg
20190801_145842.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
  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.

  189   Wed Oct 11 19:14:16 2017 Jon RichardsonComputingElectronicsReplaced TCS Monitor

I replaced the dead 24" monitor on the work bench, which is connected to the video multiplexer. Mike Pedraza was kind enough to bring us us a new one and take away the old 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.

 

 

  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 &
 

  155   Fri Sep 2 21:41:01 2011 AidanElectronicsHartmann sensorRestarting long term test of QFLD-950-3S

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

 

  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
  13   Thu Feb 11 18:04:08 2010 AidanLaserRing HeaterRing heater time constant

I've been looking to see what the time constant of the ring heater is. The attached plot shows the voltage measured by the photodiode in response to the heater turning on and off with a period of 30 minutes.

The time constant looks to be on the order of 600s.

  14   Thu Feb 11 21:46:23 2010 AidanElectronicsRing HeaterRing heater time constant measurement - start time

After leaving the ring heater off for several hours I turned on a 40V, 0.2A supply at a gps time of 949 988 700

The channel recording the PD response is C2:ATF-TCS_PD_HGCDTE_OUT.

However, there is a delay between the time at which something is supposed to be recorded and the time at which it is recorded. I looked at the GPS clock and it read that time when I started the heater voltage. If you play the channel back in dataviewer you see the temperature start to increase around 80s BEFORE the heater current was switched on. This needs to be calibrated away!!!

  15   Fri Feb 12 11:39:28 2010 AidanElectronicsRing HeaterRing heater transfer function

I applied a step function to the silver WATLOW heater and measured the response with the photodiode. The power spectrum of the derivative of the PD response is attached. The voltage isn't calibrated, but that's okay because right now we're just interested in the shape of the transfer function. It looks like a single pole around 850uHz. The noise floor is too great above 4 or 5 mHz to say anything about the transfer function.

 

 

Attachment 1: watlow_heater_transfer_fn.jpg
watlow_heater_transfer_fn.jpg
  9   Thu Feb 4 19:45:56 2010 AidanMiscRing HeaterRing heater transfer function - increasing collection area

I mounted the thinner Aluminium Watlow heater inside a 14" long, 1" inner diameter cylinder. The inner surface was lined with Aluminium foil to provide a very low emissivity surface and scatter a lot of radiation out of the end. ZEMAX simulations show this could increase the flux on a PD by 60-100x. 

There was 40V across the heater and around 0.21A being drawn. The #9005 HgCdTe photo-detector was placed at one end of the cylinder to measure the far-IR. (Bear in mind this is a 1mmx1mm detector in an open aperture of approximately 490 mm^2), The measured voltage difference between OFF and the steady-state ON solution, after a 5000x gain stage, was around 270mV. This corresponds to 0.054mV at the photo-diode. Using the responsivity of the PD ~= 0.05V/W then this corresponds to about 10mW incident on the PD.

 

Attachment 1: low-emissivity-tube.jpg
low-emissivity-tube.jpg
  7   Thu Feb 4 14:05:59 2010 AidanElectronicsRing HeaterRing heater transfer function measurement 240mHz-5Hz

I've been trying to measure the ring heater transfer function (current to emitted power) by sweeping the supply voltage and measuring the emitted power with a photodector positioned right next to the ring heater.

Last night the voltage was sweeping with a 1000mV setting on the SR785 which was fed into the Voltage Control of the Kepco Bipolar Operational Power Supply/Amplifier which was biased around 10V.

The results are very, very strange. The magnitude of the transfer function decreases at lower frequency. I'll post the data just as soon as I can (ASCII dumps 13 and 14 on the disk from the SR785).

The circuit looks like this:

 

SR785 drive ----> Amplifier ----> Ring Heater : Photodetector ---> SR560 (5000x gain) ----> SR785 input

 

 

  8   Thu Feb 4 15:26:37 2010 AidanElectronicsRing HeaterRing heater transfer function measurement 240mHz-5Hz

Quote:

I've been trying to measure the ring heater transfer function (current to emitted power) by sweeping the supply voltage and measuring the emitted power with a photodector positioned right next to the ring heater.

Last night the voltage was sweeping with a 1000mV setting on the SR785 which was fed into the Voltage Control of the Kepco Bipolar Operational Power Supply/Amplifier which was biased around 10V.

The results are very, very strange. The magnitude of the transfer function decreases at lower frequency. I'll post the data just as soon as I can (ASCII dumps 13 and 14 on the disk from the SR785).

The circuit looks like this:

 

SR785 drive ----> Amplifier ----> Ring Heater : Photodetector ---> SR560 (5000x gain) ----> SR785 input

 

 

 This is wrong. It turns out the SR785 was wired up incorrectly.

  203   Tue Nov 14 19:08:00 2017 Jon RichardsonComputingNetwork architectureRsync Server for Automatic LDAS Backups

I implemented an access point for LDAS to pull data from the TCS lab EPICS frame archive (fb4:/frames) via rsync. The setup is analogous to what is already running at the 40m for automated backups. Here are the implementation details in case we want to replicate this in other W. Bridge labs.

Two lab machines are needed, the frame builder machine (fb4; 10.0.1.156) and a second machine to handle the network interfacing with the outside world (tcs-ws; 10.0.1.168).

1. Set up an NFS mount on tcs-ws to remotely access the frame archive on fb4.

i. NFS server-side setup:

a. Install the required packages

controls@fb4:~$ sudo apt-get install rpcbind nfs-common nfs-kernel-server

b. Add the following line to the file /etc/exports

/frames 10.0.1.168(rw,sync,no_root_squash)

c. Restart the NFS-related services

controls@fb4:~$ sudo /etc/init.d/rpcbind restart

controls@fb4:~$ sudo /etc/init.d/nfs-common restart

controls@fb4:~$ sudo /etc/init.d/nfs-kernel-server restart

ii. NFS client-side setup:

a. Install the required packages

controls@tcs-ws:~$ sudo apt-get install rpcbind nfs-common

b. Add the following line to the file /etc/fstab

10.0.1.156:/frames /fb4/frames nfs rw,nofail,sync,hard,intr 0 0

c. Create the directory for the mount point, then set ownership and permissions

controls@tcs-ws:~$ sudo mkdir /fb4/frames

controls@tcs-ws:~$ sudo chmod -R 775 /fb4

controls@tcs-ws:~$ sudo chown -R controls.root /fb4

c. Mount the new network drive

controls@tcs-ws:~$ sudo mount -a

2. Configure the rsync daemon on tcs-ws.

i. Create a new file named /etc/rsyncd.conf with the following content. These settings match those of the 40m setup.

max connections = 10

read only = yes

log file = /var/tmp/rsyncd.log

list = yes

uid = controls

gid = controls

use chroot = yes

strict modes = yes

pid file = /var/run/rsyncd.pid

 

[ldasaccess]

        comment = For LDAS access to TCS lab frame files

        read only = yes

        path = /fb4/frames

        hosts allow = ldas-grid.ligo.caltech.edu,localhost

ii. Kill, then restart the rsync daemon. The daemon may not be already running.

controls@tcs-ws:~$ sudo kill `cat /var/run/rsyncd.pid`

controls@tcs-ws:~$ sudo rsync --daemon

3. Open a port through the gateway firewall for LDAS to access.

To do this, configure a new port forwarding on the linksys gateway router in the usual way (access the router settings via http://10.0.1.1 from the web browser of any subnet machine). For the TCS lab, the external-facing gateway port 2046 is forwarded to port 873 of tcs-ws (the standard rsync port).

Security is handled by the tcs-ws rsync daemon. Its config file allows outside access to only the hostname ldas-grid.ligo.caltech.edu, and that access is read-only and restricted to the /fb4/frames directory.

4. Testing.

For testing purposes, another outside machine name can be temporarily appended to the "hosts allow" parameter of /etc/rsyncd.conf. For example, I appended my office desktop machine. From the outside machine, the connectability of the rsync server can be tested with:

user@outside-hostname:~$rsync -dt rsync://131.215.115.216:2046/ldasaccess

If successful, the command will return an output similar to

drwxr-xr-x        4096 2017/08/28 16:13:31 .
drwxr-xr-x        4096 2017/11/14 02:30:38 full
drwxr-xr-x        4096 2017/08/28 16:13:38 trend

showing the contents of the frame archive.

  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. 

 

  89   Mon Aug 9 10:58:37 2010 AidanLaserSLEDSLED 15-day trend

 Here's a plot of the 15-day output of the SLED.

Currently there is an 980nm FC/APC fiber-optic patch-cord attached to the SLED. It occurred to me this morning that even though the patch cord is angle-cleaved, there may be some back-reflection than desired because the SLED output is 830nm (or thereabouts) while the patch cord is rated for 980nm.

 I'm going to turn off the SLED until I get an 830nm patch-cord and try it then. 

Correction: I removed the fiber-optic connector and put the plastic cap back on the SLED output. The mode over-lap (in terms of area) from the reflection off the cap with the output from the fiber is about 1 part in 1000. So even with 100% reflection, there is less than the 0.3% danger level coupled back into the fiber. The SLED is on again.

Attachment 1: SLED_superlum_long_term_test_0005A_annotated_15-day_result.pdf
SLED_superlum_long_term_test_0005A_annotated_15-day_result.pdf
  87   Sat Jul 31 11:54:20 2010 AidanComputingSLEDSLED Test Day 5 - Re-tuned current set-point control voltage

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.

  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
  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
  51   Thu Jun 17 07:40:07 2010 James KMiscHartmann sensorSURF Log -- Day 1, Getting Started

 For Wednesday, June 16:

I attended the LIGO Orientation and first Introduction to LIGO lecture in the morning. In the afternoon, I ran a few errands (got keys to the office, got some Computer Use Policy Documentation done) and toured the lab. I then got Cygwin installed on my laptop along with the proper SSH packets and was successfully able to log in to and interact with the Hartmann computer in the lab through the terminal, from the office. I have started reading relevant portions of Dr. Brooks' thesis and of "Fundamentals of Interferometric Gravitational Wave Detectors" by Saulson.
  52   Thu Jun 17 22:03:51 2010 James KMiscHartmann sensorSURF Log -- Day 2, Getting Started

For Thursday, June 17:

Today I attended a basic laser safety training orientation, the second Introduction to LIGO lecture, a Summer Research Student Safety Orientation, and an Orientation for Non-Students living on campus (lots of mandatory meetings today). I met with Dr. Willems and Dr. Brooks in the morning and went over some background information regarding the project, then in the afternoon I got an idea of where I should progress from here from talking with Dr. Brooks. I read over the paper "Adaptive thermal compensation of test masses in advanced LIGO" and the LIGO TCS Preliminary Design document, and did some further reading in the Brooks thesis.

I'm making a little bit of progress with accessing the Hartmann lab computer with Xming but got stuck, and hopefully will be able to sort that out in the morning and progress to where I want to be (I wasn't able to get much further than that, since I can't access the Hartmann computer in the lab currently due to laser authorization restrictions). I'm currently able to remotely open an X terminal on the server but wasn't able to figure out how to then be able to log in to the Hartmann computer. I can do it via SSH on that terminal, of course, but am having the same access restrictions that I was getting when I was logging in to the Hartmann computer via SSH directly from my laptop (i.e. I can log in to the Hartmann computer just fine, and access the camera and framegrabber programs, but for the vast majority of the stuff on there, including MATLAB, I don't have permissions for some reason and just get 'access denied'). I'm sure that somebody who actually knows something about this stuff will be able to point out the problem and point me in the right direction fairly quickly (I've never used SSH or the X Window system before, which is why it's taking me quite a while to do this, but it's a great learning experience so far at least).

Goals for tomorrow: get that all sorted out and learn how to be able to fully access the Hartmann computer remotely and run MATLAB off of it. Familiarize myself with the camera program. Set the camera into test pattern mode and use the 'take' programs to retrieve images from it. Familiarize myself with the 'take' programs a bit and the various options and settings of them and other framegrabber programs. Get MATLAB running and use fread to import the image data arrays I take with the proper data representation (uint16 for each array entry). Then, set the camera back to recording actual images, take those images from the framegrabber and save them, then import them into MATLAB. I should familiarize myself with the various settings of the camera at this stage, as well.

 

--James

  53   Sat Jun 19 17:31:46 2010 James KMiscHartmann sensorSURF Log -- Day 3, Initial Image Analysis
For Friday, June 18:
(note that I haven't been working on this stuff all of Saturday or anything, despite posting it now. It was getting late on Friday evening so I opted to just type it up now, instead)

(all matlab files referenced can be found in /EDTpdv/JKmatlab unless otherwise noted)

I finally got Xming up and running on my laptop and had Dr. Brooks edit the permissions of the controls account, so now I can fully access the Hartmann computer remotely (run MATLAB, interact with the framegrabber programs, etc.). I was able to successfully adjust camera settings and take images using 'take', saving them as .raw files. I figured out how to import these .raws into MATLAB using fopen and display them as grayscale images using the Imshow command. I then wrote a program (readimgs.m, as attached) which takes inputs a base filename and number of images (n), then automatically loads the first 'n' .raw files located in /EDTpdv/JKimg/ with the inputted base file name, formatting them properly and saving them as a 1024x1024x(n) matrix.

After trying out the test pattern of the camera, I set the camera into normal operating mode. I took 200 images of the HWS illuminated by the OLED, using the following camera settings:

 
Temperature data from the camera was, unfortunately, not taken, though I now know how to take it.
 
The first of these 200 images is shown below:
 
hws0000.png

As a test exercise in MATLAB and also to analyze the stability of the HWS output, I wrote a series of functions to allow me to find and plot the means and standard deviations of the intensity of each pixel over a series of images. First, knowing that I would need it in following programs in order to use the plot functions on the data, I wrote "ar2vec.m" (as attached), which simply inputs an array and concatenates all of the columns into a single column vector.

Then, I wrote "stdvsmean.m" (as attached), which inputs a 3D array (such as the 1024x1024x(n) array of n image files), which first calculates the standard deviation and mean of this array along the 3rd dimension (leaving, for example, two 1024x1024 arrays, which give the mean and standard deviation of each pixel over the (n) images). It then uses ar2vec to create two column vectors, representing the mean and standard deviation of each pixel. It then plots a scatterplot of the standard deviation of each pixel vs. its mean intensity (with logarithmic axes), along with histograms of the mean intensities and standard deviation of intensities (with logarithmic y-axes).

"imgdevdat.m" (as attached) is simply a master function which combines the previous functions to input image files, format them, analyze them statistically and create plots.

Running this function for the first 20 images gave the following output:

(data from 20 images, over all 1024x1024 pixels)

Note that the background level is not subtracted out in this function, which is apparent from the plots. The logarithmic scatter plot looks pretty linear, as expected, but there are interesting features arising between the intensities of ~120 to ~130 (the obvious spike upward of standard deviation, followed immediately by a large dip downward).

MATLAB gets pretty bogged down trying to plot over a million data points at a time, to the point where it's very difficult to do anything with the plots. I therefore wrote the function "minimgstat.m" (as attached), which is very similar to imgdevdat.m except that before doing the analysis and plotting, it reduces the size of the image array to the upper-left NxN square (where N is an additional argument of the function).

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

(data from 200 images, over the upper-left 200x200 pixels)

The intensities of the pixels don't go as high this time because the upper portion of the images are dimmer than much of the rest of the image (as is apparent from looking at the image itself, and as I demonstrate further a little bit later on). Do note the change in axis scaling resulting from this when comparing the image. We do, however, see the same behavior in the ~120-128 intensity level region (more pronounced in this plot because of the change in axis scaling).

I was interested in looking at which pixels constituted this band, so I wrote a function "imgbandfind.m" (as attached), which inputs a 2D array and a minimum and maximum range value, goes through the image array pixel-by-pixel, determines which pixels are within the range, and then constructs an RGB image which displays pixels within the range as red and images outside the range as black.

I inputted the first image in the series into this function along with the range of 120-129, and got the following:

(pixels in intensity range of 120-129 in first image)

So the pixels in this range appear to be the pixels on the outskirts of each wavefront dot near the vertical center of the image. The outer circles of the dots on the lower and upper portions of the image do not appear, perhaps because the top of the image is dimmer and the bottom of the image is brighter, and thus these outskirt pixels would then have lower and higher values, respectively. I plan to investigate this and why it happens (what causes this 'flickering' and if it is a problem at all) further.

The fact that the background levels are lower nearer to the upper portion of the image is demonstrated in the next image, which shows all intensity levels less than 70:
(pixels in intensity range of 0-70 in first image)

So the background levels appear the be nonuniform across the CCD, as are the intensities of each dot. Again, I plan to investigate this further. (could it be something to do with stray light hitting the CCD nonuniformly, maybe? I haven't thought through all the possibilities)
 
The OLED has been turned off, so my next immediate step will be to investigate the background levels further by analyzing the images when not illuminated by the OLED.
 
In other news: today I also attended the third Intro to LIGO lecture, a talk on Artificial Neural Networks and their applications to automated classification of stellar spectra, and the 40m Journal Club on the birth rates of neutron stars (though I didn't think to learn how to access the wiki until a few hours right before, and then didn't actually read the paper. I fully intend to read the paper for next week before the meeting).
 
Attachment 2: ar2vec.m
function V = ar2vec(A)
%AR2VEC V=ar2vec(A)
%concenates the columns of 2D array A into a single column vector V

sz = size(A);
n=sz(1,2);
i=1;
V=[];

while i<(n+1)
... 7 more lines ...
Attachment 3: readimgs.m
function arr = readimgs(imn,n)
%readimgs('basefilename',n) 
%- A function to load a series of .raw files outputted by 'take'
%and stored in /opt/EDTpdv/JKimg/
%  Inputs: 'basefilename' is a string input (for example, for series of
%   images "testpat####.raw" input 'testpat'). "n" is the number of images,
%   so for testpat0000-testpat0004 input n=5

i=0;
arr=[];
... 32 more lines ...
Attachment 4: stdvsmean.m
function M = stdvsmean(A)
%STDVSMEAN takes a 3D array of image data and computes
%stdev vs. mean for each pixel

%find means/st devs between each image
astd = std(double(A),0,3);
armn = mean(double(A),3);

%convert into column vectors of pixel-by-pixel data
asvec=ar2vec(astd);
... 33 more lines ...
Attachment 5: imgdevdat.m
function imgdevdat(basefilename,imgnum)
%IMGDEVDAT Inputs base file name and number of images stored as .raw files
%in ../EDTpdv/JKimg/, automatically imports as 1024x1024x(n) matrix, finds
%the mean and standard deviation of each pixel in each image and plots
A=readimgs(basefilename,imgnum);
stdvsmean(A)
end

Attachment 6: minimgstat.m
function imgdevdat(basefilename,imgnum,size)
%IMGDEVDAT Inputs base file name and number of images stored as .raw files
%in ../EDTpdv/JKimg/, automatically imports as (size)x(size)x(n) matrix, finds
%the mean and standard deviation of each pixel in each image and plots
A=readimgs(basefilename,imgnum);
smA=A(1:size,1:size,:);
stdvsmean(smA)
end
Attachment 7: imgbandfind.m
function [HILT] = imgbandfind(img,minb,maxb)
%IMGBANDFIND inputs an image array and minimum and maximum value,
% then finds all values of the array within that range, then plots with
%values in range highlighted in red against a black background

img=double(img);
maxv=max(max(img));
sizm=size(img);
rows=sizm(1,1);
cols=sizm(1,2);
... 20 more lines ...
  55   Tue Jun 22 22:30:24 2010 James KMiscHartmann sensorSURF Log -- Day 5, more Hartmann image preliminary analysis

 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.

 

  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.

 

 

  57   Wed Jun 23 22:57:22 2010 James KMiscHartmann sensorSURF Log -- Day 6, Centroiding

 So in addition to taking steps towards starting to set stuff up for the experiment in the lab, I spent a good deal of the day figuring out how to use the pre-existing code for finding the centroids in spot images. I spent quite a bit of time trying to use an outdated version of the code that didn't work for the actual captured images, and then once I was directed towards the right version I was hindered for a little while by a bug.

The 'bug' turns out to be something very simple, yet relatively subtle. In the function centroid_images.m in '/opt/EDTpdv/hartmann/src/', the function was assuming a threshold of 0 with my images, even though it has not long before been working with an image that Dr. Brooks loaded. Looking through the code, I noticed that before finding the threshold using the MATLAB function graythresh, several adjustments were made so as to subtract out the background and normalize the array. After estimating and subtracting a background, the function divides the entries of the image array by the maximum value in the image so as to normalize this. For arrays composed of numbers represented as doubles, this is fine. However, the function that I wrote to import my image arrays into MATLAB outputs an image array with integer data. So when the function divided my integer image arrays by the maximum values in the array, it rounded every value in the array to the nearest integer -- that is, the "normalized" array only contained ones and zeros. The function graythresh views this as a black and white image, and thus outputs a threshold of 0.

To remedy this, I edited centroid_images.m to convert the image array into an array of doubles near the very beginning of the function. The only new line is simply "image=double(image);", and I made a note of my edit in a comment above that line. The function started working for me after I did that.

 

I then wrote a function which automatically centroids an input image and then plots the centroids as scatter-plot of red circles over the image. For an image taken off of the Hartmann camera, it gave the following:

centroidplot_nozoom.png

Zoomed in on the higher-intensity peaks, the centroids look good. They're a little offset, but that could just be an artifact of the plotting procedure; I can't say for certain either way. They all appear offset by the same amount, though:

centroidplot_zoom.png

One problem is that, for spots with a much lower relative intensity than the maximum intensity peak, the centroid appears to be offset:

centroidplot_zoom2.png

Better centering of the beam and more even illumination of the Hartmann plate could mitigate this problem, perhaps.

 

I also wrote a function which inputs two image matrices and outputs vector field plots representing the shift in each centroid from the first to the second images. To demonstrate that I could use this function to display the shifting of the centroids from a change in the wavefront, I translated the fiber mount of the SLED in the direction of the optical axis by about 6 turns of the z-control knob  (corresponding to a translation of about 1.9mm, according to the user's guide for the fiber aligner). This gave the following images:

 

Before the translation:

6turn_before.png

After:

6turn_after.png

 This led to a displacement of the centroids shown as follows:

6turnDisplacementVectors.png

Note that the magnitudes of the actual displacements are small, making the shift difficult to see. However, when we scale the displacement vectors up, we can get much more readily visible Direction vectors (having the same direction as the actual displacement vectors, but not the same magnitude):

6turnDirectionVectors.png

This was a very rough sort of measurement, since exposure time, focus of the microscope optic, etc. were not adjusted, and the centroids are compared between single images rather than composite images, meaning that random noise could have quite an effect, especially for the lower-magnitude displacements. However, this plot appears to show the centroids 'spreading out', which is as expected for moving the SLED closer to the sensor along the optical axis.

 

The following MATLAB functions were written for this (both attached):

centroidplot.m -- calls centroid_image and plots the data

centroidcompare.m -- calls centroid_image twice for two inputs matrices, using the first matrix's centroid output structure as a reference for the second. Does a vector field plot from the displacements and reference positions in the second output centroids structure.

Attachment 5: 6turn_before.png
6turn_before.png
Attachment 9: centroidplot.m
function centroiddata=centroidplot(M,N)
%a function to read the image matrix M and plot the centroids of each plot
%on the image
H=M(:,:,N);
cd /opt/EDTpdv/hartmann/src/
centroiddata = centroid_image(H);
cd /opt/EDTpdv/JKmatlab/

v=centroiddata.current_centroids;
r=v(:,1);
... 6 more lines ...
Attachment 10: centroidcompare.m
function centroiddata=centroidcompare(A,B,M,N)
%compares the Mth image in 3D image matrix A to Nth in B
H=A(:,:,M);
I=B(:,:,N);
cd /opt/EDTpdv/hartmann/src/
cent0=centroid_image(H);
centroiddata=centroid_image(I,cent0);
cd /opt/EDTpdv/JKmatlab
v=centroiddata.reference_centroids;
dv=centroiddata.displacement_of_centroids;
... 16 more lines ...
  58   Fri Jun 25 00:11:13 2010 James KMiscHartmann sensorSURF Log -- Day 7, SLED Beam Characterization

BACKGROUND:


In order to conduct future optical experiments with the SLED and to be able to predict the behavior of the beam as it propagates across the table and through various optics, it is necessary to know the properties of the beam. The spot size, divergence angle, and radius of curvature are all of interest if we wish to be able to predict the pattern which should appear on the Hartmann sensor given a certain optical layout.

It was therefore necessary to conduct an experiment to measure these properties. The wavefront emanating from the SLED is assumed to be approximately Gaussian, and thus has an intensity of the form:

 

where A is some amplitude, w is the spot size, x and y are the coordinates transverse to the optical axis, and x0 is the displacement of the optical axis in the x-direction from the optical axis. The displacement of the optical axis in the y-direction is assumed to be zero (that is, y0=0). A and w are both functions of z, which is the coordinate of displacement parallel to the optical axis.

 

Notice that the total intensity read by a photodetector reading the entire beam would be the double integral from negative infinity to infinity for both x and y. If a opaque plate was placed such that the the beam was blocked from some x=xm to x=inf (where xm is the location of the edge of the plate), then the intensity read by a photodetector reading the entire non-blocked portion of the beam would be:

 

Mathematica was used to simplify this integral, and it showed it to be equivalent to:

where Erfc() is the complementary error function. Note that for fixed z, this intensity is a function only of xm. If an experiment was carried out to measure the intensity of the beam blocked by a plate from x=-inf to x=xm for multiple values of xm, it would therefore be possible via regression analysis to compute the best-fit values of A, w, and x0 for the measured values of Ipd and xm. This would give us A, w and x0 for that z-value. By repeating this process for multiple values of z, we could therefore find the behavior of these parameters as a function of z.

Furthermore, we know that at z-values well beyond the Rayleigh range, w should be linear with respect to z. Assuming that our measurements are done in the far-field (which, for the SLED, they almost certainly would be) we could therefore find the divergence angle by knowing the slope of the linear relation between w and z. Knowing this, we could further calculate such quantities as the Rayleigh range, the minimum spot size, and the radius of curvature of the SLED output (see p.490 of "Lasers" by Milonni and Eberly for the relevant functional relationships for Gaussian beams).


EXPERIMENT:

An experiment was therefore carried out to measure the intensity of of beam blocked from x~=-inf to x=xm, for multiple values of xm, for multiple values of z. A diagram of the optical layout of the experiment is below:

 

(top view)


The razor blade was mounted on a New Focus 9091 Translational Stage, the relative displacement of which in the x-direction was measured with the Vernier micrometer mounted on the base. Tape was placed on the front of the razor so as to block light from passing through any of its holes. The portion of the beam not blocked by the razor then passed through a lens which was used to focus the beam back onto a PDA1001A Large Area Silicon Photodiode, the voltage output of which was monitored using a Fluke digital multimeter. The ruler stayed securely clamped onto the optical table (except when it was translated in the x-direction once during the experiment, as described later).

The following is a picture of this layout, as constructed:

 

 
The procedure of the experiment was as follows: first, the translational stage was clamped securely with the left-most edge of its base lined up with the desired z-value as measured on the ruler. The z-value as measured on the ruler was recorded. Then, the translational stage was moved in the negative x-direction until there was no change in the voltage measured on the DMM (which is directly proportional to the measured intensity of the beam). When no further DMM readout change was yielded from -x translation, it was assumed that the the razor was no longer blocking the beam. Then, the stage was moved in the +x direction until the voltage output on the DMM just began to change. The micrometer and DMM values were both recorded. The stage was then moved inward until the DMM read a voltage which was close to the nearest multiple of 0.5V, and this DMM voltage and micrometer reading were recorded. The stage was then translated until the DMM voltage dropped by approximately 0.5V, the micrometer and DMM readings were recorded, and this process was repeated until the voltage reached ~0.5V. The beam output was then covered by a card so as to completely block it, and the voltage output from the DMM was recorded as the intensity from the ambient light from that measurement. The stage was then unclamped and moved to the next z-value, and this process was repeated for 26 different values of z, starting at z=36.5mm and then incrementing z upwards by ~4mm for the first ten measurements, then by increments of ~6mm for the remaining measurements.
 
The data from these measurements can be found on the attached spreadsheet.
 
A few notes on the experiment:
 
The vernier micrometer has a measurement limit of 13.5mm. After the tenth measurement, the measured xm values began to exceed this limit. It was therefore necessary to translate the ruler in the negative x-direction without translating it in the z-direction. Plates were clamped snugly to either side of the ruler such that the ruler could not be translated in the z-direction, but could be moved in the x-direction when the ruler was unclamped. After securing these plates, the ruler was moved in the negative x-direction by approximately 5mm. The ruler was then clamped securely in place at its new x location. In order to better estimate the actual x-translation of the ruler, I took the following series of measurements: I moved the stage to z-values at which sets of measurements were previously taken. Then, I moved the razor out of the beam path and carefully moved it back inwards until the output on the DMM matched exactly the DMM output of the first measurement taken previously at that z-value. The xm value corresponding to this voltage was then read. The translation of the stage should be approximately equal to the difference of the measured xm values for that DMM voltage output at that z-value. This was done for 8 z-values, and the average difference was found to be 4.57+-0.03mm, which should also be the distance of stage translation (this data and calculation is included in the "x translation" sheet of the attached excel workbook).
 
At this same point, I started using two clamps to attach the translational stage to the table for each measurement set, as I was unhappy with the level of secureness which one clamp provided. I do not, however, believe that the use of one clamp compromised the quality of previous sets of measurements.

 

RESULTS:


A MATLAB function 'gsbeam.m' was written to replicate the function:

and then another function 'beamdata.m' was written to input each dataset, fit the data to a curve of the functional form of the previous function for each set of data automatically, and then output PDF files plotting all of the fit curves against each other, each individual fit curve against the data from that measurement, and a plot showing the widths w as a function of z. Linear regression was done on w against z to find the slope of the w(z) (which, for these measurements, is clearly shown by the plot that the beam was measured in the far-field and thus w is approximately a linear function of z). An array of the z-location of the ruler, the fit parameters A, x0, x, and the 2-norm of the residual of the fit is also outputted, and is shown below for the experimental data:

 

z(ruler) A x0 w 2normres
36.5 7.5915 11.089 0.8741 0.1042
39.9 5.2604 11.1246 1.048 0.1013
44 3.8075 11.1561 1.2332 0.1164
48 2.777 11.1628 1.4479 0.0964
52 2.1457 11.1363 1.6482 0.1008
56 1.6872 11.4206 1.858 0.1029
60 1.3831 11.2469 2.0523 0.1021
64 1.1564 11.1997 2.2432 0.1059
68 0.972 11.1851 2.4483 0.0976
72 0.8356 11.1728 2.6392 0.1046
78 0.67 6.8821 2.9463 0.0991
84 0.5559 6.7548 3.2375 0.1036
90 0.4647 6.715 3.5402 0.0958
96 0.3993 6.7003 3.8158 0.1179
112 0.2719 6.8372 4.6292 0.0924
118 0.2398 6.7641 4.925 0.1029
124 0.2117 6.7674 5.2435 0.1002
130 0.189 6.8305 5.5513 0.0965
136 0.1709 6.8551 5.8383 0.1028
142 0.1544 6.8243 6.1412 0.0981
148 0.1408 6.7993 6.4313 0.099
154 0.1286 6.8062 6.7322 0.0948
160 0.1178 6.9059 7.0362 0.1009
166 0.1089 6.904 7.3178 0.0981
172 0.1001 6.8817 7.6333 0.1025
178 0.0998 6.711 7.6333 0

 

All outputted PDF's are included in the .zip file attached. The MATLAB functions themselves are also attached.The plots of the fit curves and the plot of the widths vs. the ruler location are also included below:

 

(note that I could probably improve on the colormap that I chose for this. note also that the 'gap' is because I temporarily forgot how to add integers while taking the measurements, and thus went from 96mm on the ruler to 112mm on the ruler despite going by a 6mm increment otherwise in that range. Also, note that all of these fit curves were automatically centered at x=0 for the plot, so they wouldn't necessarily intersect so neatly if I tried to include the difference in the estimated 'beam centers')

(note that the width calculated from the 26th measurement is not included in the regression calculation or included on this plot. The width parameter was calculated as being exactly the same as it was for the 25th measurement, despite the other parameters varying between the measurements. I suspect that the beam size was starting to exceed the dimensions blocked by the razor and that this caused this problem, and that would be easy to check, but I have yet to do it. Regardless, the fit looks good from just the other 25 measurements)

These results are as expected: that the beam spot-size should increase as a function of z and that it should do so linearly in the far-field. My next step will be to use the results of this experiment to calculate the properties of the SLED beam, characterizing the beam and thusly enabling me to predict its behavior within further optical systems.

 

Attachment 1: BeamData.xlsx
Attachment 2: beam_pdfs.zip
Attachment 3: beamdata.m
function D=beamdata(M,guess)
%Imports array of beam characterization measurements. Structure of M is 
% [z, x, I, a] where z is the displacement of the beam blockage along
% the optical axis, x is the coordinate of razor edge, I is the measured
% output of the photodetector and a is the ambient light level
%and guess is an estimate of the parameters [Amplitude x0 width] for the
%first measurement
%Output Structure [z A x0 w residual_2norm]
thisfile=mfilename('fullpath');
thisdir=strrep(thisfile,mfilename(),'');
... 105 more lines ...
Attachment 4: gsbeam.m
function I=gsbeam(x,xdat)
I=pi/4*x(1)*x(3)^2*erfc(sqrt(2)*(x(2)-xdat)/x(3));
end
  64   Tue Jul 6 21:57:19 2010 James KunertMiscHartmann sensorSURF Log -- SLED fiber output temporal analysis

In the previous log, I describe the direct measurement of the fiber output beam using the Hartmann sensor with the plate removed. In order to analyze how these properties might change as a function of time, we left the camera running over the holiday weekend, Dr. Brooks having written a bash script which took images from the sensor every 500 seconds. This morning I wrote a MATLAB script to automatically analyze all of these images and plot the fit parameters as a function of time (weekendbeamtime.m, attached). Note that the formatiing of a few of the following graphs was edited manually after being outputted by the program (just to note why the plots look different than the code might imply).

The following plots were made:

Amplitude as a function of time:

Amplitude.png

Amplitude again, focused in with more analysis:

Amplitude2.png

 

Offset level:

Offset.png

 

Beam Size:

BeamSize.png

 

Centroid Displacement (note the axis values, it's fairly zoomed in):

CentroidDisplacement.png

Note that these values were converted into radians by approximating the fiber-output/CCD distance and dividing this from the displacement in mm (after converting from pixels). This distance was approximated by assuming a divergence angle of 0.085 and a beam size of ~5.1mm (being a value inbetween the horizontal and vertical beam sizes calculated). This gave a value of ~60mm, which was confirmed as plausible by a quick examination in the lab.

In the first three plots, there are obvious temporary effects which seem to cause the values to fluctuate much more rapidly than they do for the rest of the duration. It is suspected that this could be related to temperature changes within the sensor as the camera begins taking images. Further investigation (tomorrow) will investigate these effects further, while collecting temperature data.

Attachment 1: weekendbeamtime.m
function [X Y wX wY]=weekendbeamtime(basename,guess,N)
%fits 1D gaussian curve to N images in sequence of basename basefile
thisfile=mfilename('fullpath');
thisdir=strrep(thisfile,mfilename(),'');

i=0;
X=[];
Y=[];
wX=[];
wY=[];
... 82 more lines ...
  62   Thu Jul 1 09:40:13 2010 James KunertMiscHartmann sensorSURF Log 8 -- more SLED characterization

As I started setting up my next experiment, I noticed that the beam size from the SLED appeared to be larger than expected from previous analysis. It was therefore necessary to conduct further experiments to characterize the divergence angle of the beam.

First, I set up the photodetector attached to an SLED and mounted a razor blade on a translational stage, in the same manner as done previously. All of these components were the exact same ones used in the previous beam size experiment. The only differences in the components of the apparatus were as follows: first, the photodetector was placed considerably closer to the SLED source than was done previously. Second, a different lens was used to focus the light onto the photodetector. Lens LX082 from the lenskit was used, which is a one-inch lens of focal length f=50.20mm.

Experiment 1: Columnated Beam Size Measurement

Before repeating the previous experiment, the following experiment was done: the beam was columnated by placing the lens 50.20mm away from the source and then adjusting until columnation was observed. Columnation was confirmed by setting a mirror in the optical path of the beam directing it to the other side of the room. The position of the lens along the optical axis was adjusted until the beam exiting the lens did not change in size across the length of the table and appeared to be roughly the same size as the spot on the opposite side of the room (as gauged roughly by the apparent size on an IR card and through an IR viewer).

Then,the translational stage onto with the laser was mounted was placed after the lens against the ruler clamped to the table, and beam size was measured using the same experimental procedure used to find the width in the previous experiment. The only variation in the experimental procedure was that measurements were not taken strictly at 0.5V intervals; rather, intensity readings were taken for 28 different intensity outputs. The following measurements were collected:


x(mm)   V(V)
13.00  7.25
12.00  7.24
10.80   7.18
10.15   7.09
9.50   6.92
9.30   6.86
9.00   6.74
8.75   6.61
8.50   6.47
8.25   6.31
8.00   6.12
7.75   5.92
7.50   5.69
7.30   5.49
7.15   5.33
7.00   5.17
6.75   4.88
6.50   4.58
6.25   4.27
6.00   3.95
5.75   3.63
5.50   3.32
5.25   3.02
5.00   2.729
4.60   2.306
4.50   2.205
4.25   1.981
4.00 1.770
ambient 0.585

When fit to gsbeam.m using lsqcurvefit, this yielded a width of 4.232mm. Since the beam is columnated through the lens, we know that it is approximately f=50.2mm from the source. Thus the divergence angle is approximately 0.084.

At this point, to double-check that the discrepency between this value and the previous experiment was not a result of a mistake in the function, I wrote a simpler function to go through the steps of using lsqcurvefit and plotting the fit curve versus the data automatically, 'manualbeam.m' (attached), which simply fits a curve to one set of data from a constant z-value. Using this one-by-one on each z-value in the previous experiment, it was shown that the slope of the widths was still ~0.05, so this discrepency was not the result of a mistake in the previous function somewhere.

Experiment 2: Blocked Beam Analysis 2

I then placed the razor before the lens in the beampath and repeated the previous experiment exactly. See the previous eLog for details on experimental procedure. Sets of measurements were taken at 6 different z-values, and widths were found using manualbeam.m in MATLAB. A curve of the calculated widths versus the z-position of the stage on the ruler is below:

BeamSpot_Exp3.tif

Note that this appears to be consistant with the first experiment.

Experiment 3: Direct Beam Measurements on CCD

The front-plate of the Hartmann sensor was replaced with the new invar design (on a related note, the thread on the front plate needs a larger chamfer). In doing this, the Hartmann plate was removed. The sensor was moved much closer to the SLED along the optical axis, and an optical filter of OD 0.7 was screwed into the new frontplate. This setup allows for the direct imaging of the intensity of the beam, as shown below:

directbeam.PNG

The spots and distortions on the image are from dust and other blemishes on the optical filter, as was confirmed by rotating the filter and observing the subsequent rotation of each feature.

Note that in some images, there may be a jump in intensity in the middle of the image. This is believed to be due to a inconsistant gain between the two sides of the image.

The means of the intensities of each row and each column will be Gaussian, and thus can be fit to a Gaussian using lsqcurvefit. Function 'gauss_beam1D.m' was written and this function was fit to using function 'autogaussfit1', which automatically imports the data from .raw files, fits Gaussians to the means of each row and column, and plots everything.

An example of the fit for the means of the columns of one image is as follows:

beamfit100mm.PNG

 And for the rows:

beamfit100mmRows.PNG

Note that for all the fits, the fitting generally looks a little better along the row than along the column (which is true here, as well).

The following procedure was used to calculate the change of the beam width as a function of distance: the left edge of the base of the Hartmann sensor was measured against a ruler which was clamped to the table. The ruler position z was recorded. Then, preliminary images would be taken and the exposure time would be adjusted as needed. The exposure time was then noted. Then, an image was taken and curves were fit to it, and the width was calculated. This was done for 15 different positions of the Hartmann sensor along the optical axis.

The calculated widths vs. displacements plot from this can be seen below:

DirectBeams1.tif

Note that the row width and column width are not the same, implying that the beam is not circularly symmetric and is thusly probably off alignment by a little bit. Also, the calculated slopes are different than the value of 0.085 acquired from the previous two measurements. Further investigation into the beam size and divergence angle is required to finally put this question to rest.

Attachment 6: manualbeam.m
function x=manualbeam(M,guess)
    x=lsqcurvefit(@gsbeam,guess,M(:,2),M(:,3)-M(:,4));
    figure
    hold
    grid on
    xlabel('Stage Translation (mm)')
    ylabel('Photodetector Output (V)')
    text(0.8,0.2,['A = ' num2str(x(1))],'FontSize',12,'Interpreter','none','Units','normalized');
    text(0.8,0.15,['x0 = ' num2str(x(2))],'FontSize',12,'Interpreter','none','Units','normalized');
    text(0.8,0.1,['w = ' num2str(x(3))],'FontSize',12,'Interpreter','none','Units','normalized');
... 7 more lines ...
Attachment 7: gauss_beam1D.m
function result = gauss_beam1D(x0, xdata)
% x0(1) = offset
% x0(2) = amplitude
% x0(3) = x centroid location
% x0(4) = x width

result = x0(1) + x0(2).*exp(-2.0.*( ...
                           ((xdata - x0(3)).^2)/(x0(4).^2)));
                       
Attachment 8: autogaussfit1.m
function [x y wx wy]=autogaussfit1(imgname,guess,imgdetails)
%guess = [offset amplitude centroidlocation width]
%imgdetails = [HWSrulerlocation exp.time]
%output vectors same format as guess
thisfile=mfilename('fullpath');
thisdir=strrep(thisfile,mfilename(),'');

rulerz = imgdetails(1,1);
exposure = imgdetails(1,2);

... 56 more lines ...
  65   Thu Jul 15 20:06:37 2010 James KMiscHartmann sensorSURF Log: Thermally Induced Defocus Experiments

A quick write-up on recent work can be found at: Google Docs

 

I can't find a Tex interpreter or any other sort of equation editor on the eLog, is why I kept it on Google Docs for now instead of transferring it over.

 

--James

 

Attachment 1: pydefoc.m
function slopes=pydefoc(mainout,N,tol)
[x,y,dx,dy,time,M,centroids]=pyanalyze(mainout,N);
slopes=xdxslope(x,dx,time,tol);
Attachment 2: pyanalyze.m
function [x,y,dx,dy,time,M,centroids]=pyanalyze(mainout,N)
n=0;
centroids=[];
while n<N
    display(['Image Number ' num2str(n)])
    if n==0
        I=pyimportsingle(mainout,n);
        cent=centroid_image(I);
    else
        I=pyimportsingle(mainout,n);
... 22 more lines ...
Attachment 3: pyimportsingle.m
function I=pyimportsingle(mainoutbase,Nimg)
%Imports mainoutbase.raw generated by python framesumexport2 and outputs
%Nth image matrix I

mainout=['/opt/EDTpdv/' mainoutbase '.raw'];
%open main output array
fid = fopen(mainout,'r');
fseek(fid,4*1024*1024*(Nimg-1),'bof');
arr = fread(fid,1024*1024,'float');

... 16 more lines ...
Attachment 4: pyimportM.m
function M=pyimportM(mainoutbase,N)
maintxt=['/opt/EDTpdv/' mainoutbase '.txt'];
fid=fopen(maintxt);
str=fread(fid,'*char');
fclose(fid);
str=str';
str=strrep(str,'Camera Temperature on Digitizer Board:','');
str=strrep(str,'Camera Temperature on Sensor Board:','');
str=strrep(str,' Celsius','');
str=strrep(str,'Start Time','');
... 14 more lines ...
Attachment 5: framesumexport2.py
#!/bin/python

import array
import os
import time
#Number of loops LoopN over which to sum SumN images of dim num_H by num_W
LoopN=100
SumN=200
num_H = 1024
num_W = 1024
... 94 more lines ...
  229   Mon Jun 17 20:29:34 2019 JonLab InfrastructureComputingServer rack cleaned up, new workstation installed

In anticipation of the point absorber SURF project, I cleaned up the server rack and installed a new workstation today.

The workstation replaces the old one, whose hard drive had failed, with a more powerful machine. The hostname (tcs-ws), IP address (10.0.1.168), user name (controls), and standard password (written in the secret place) are all the same as before.

I moved the control consol from its old spot in the back corner of the lab to the bench beside the rack. This is a more convenient location because the Hartmann sensor realtime GUIs can now be easily seen from the optical tables. I mounted the HWS machine in the rack as well and reconnected the video multiplexer to all the machines.

I tested the Hartmann sensor Python software and confirmed it to be working. It required a minor bug fix to the realtime gradient field GUI code. It seems that since this script was last run, the input data file type has switched from pickled numpy to HDF5.

Attachment 1: IMG_3419.jpg
IMG_3419.jpg
  49   Tue Jun 15 16:30:10 2010 Peter VeitchMiscHartmann sensorSpot displacement maps - temperate sensitivity tests

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: spot_displacements_same_temp_0611.jpg
spot_displacements_same_temp_0611.jpg
Attachment 2: spot_displacements_diff_temp_0611.jpg
spot_displacements_diff_temp_0611.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
  223   Fri Oct 26 09:49:47 2018 AidanMiscOpticsStarting 80C cure of epoxy

I've started an 80C cure of two materials bonded by EPOTEK 353ND. The objective is to see (after curing) how much the apparent glass transition temperature is increased over a room-temperature cure.

Attachment 1: IMG_7054.jpg
IMG_7054.jpg
ELOG V3.1.3-