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 Subjectdown
  29   Tue May 4 13:35:13 2010 AidanComputingHartmann sensorHartmann temperature channels in frame builder

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

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

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

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

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

 

C4TCS.ini

 

[default]

dcuid=4

datarate=16

gain=1.0

acquire=1

ifoid=0

datatype=4

slope=1.0

offset=0

units=NONE

 

 

 

[C4:TCS-HWS_TEMP_SENSOR]

[C4:TCS-HWS_TEMP_DIGITIZER]


 

 

 

  47   Thu May 27 15:42:06 2010 AidanElectronicsHartmann sensorHartmann sensor with just the base piece

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

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

 

Attachment 1: HWS_CONFIG4.jpg
HWS_CONFIG4.jpg
  137   Sun Apr 17 21:55:51 2011 AidanLaserHartmann sensorHartmann sensor prism/displacement test

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

The experimental setup is shown below.

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

Attachment 1: HWS_prims.jpg
HWS_prims.jpg
  152   Mon May 30 20:11:27 2011 AidanLaserHartmann sensorHartmann sensor lever arm calibration

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

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

 

  45   Thu May 27 08:25:37 2010 AidanElectronicsHartmann sensorHartmann sensor cooling fins added - base piece removed

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

The photo below shows the current configuration.

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

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

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

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

 

 

Attachment 1: HWS_CONFIG1-tight.jpg
HWS_CONFIG1-tight.jpg
  44   Wed May 26 14:58:04 2010 AidanMiscHartmann sensorHartmann sensor cooling fins added

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

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

 

Attachment 1: HWS_CONFIG1.jpg
HWS_CONFIG1.jpg
  121   Tue Mar 8 11:30:26 2011 AidanComputingHartmann sensorHartmann sensor code changes and NTP server

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

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

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

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

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

  92   Wed Aug 18 18:38:11 2010 AidanComputingHartmann sensorHartmann sensor code

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

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

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

 

>> test_HS_Classes
Current plot held
Current plot released
----------------------------------------------------------------
Obtained reference and test centroids.
Number of centroids in reference centroids = 951
average position of reference centroids:
x = 506.39615297  y = 512.890603168
Number of centroids in test centroids = 951
average position of test centroids:
x = 506.396160891  y = 512.892513673

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

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

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

Attachment 1: test_HS_Classes.m
% test_HS_classes.m
%
% A script to test and demonstrate the usage of classes HS_Centroids and
% HS_Classes.

% (LIGO) If half_offset is set true, image and centroids won't be in
% sync in the scatter plot.

% Input parameters
background = 49.3;
... 107 more lines ...
Attachment 2: HS_Image.m
% HS_Image.m
%
%
% HS_Image is a class used to store and interact with images from
% Hartmann Sensor camera.
%
% An instance of the class HS_Image is also used as a property of an
% instance of the class HS_Centroids.
%
% Properties:
... 70 more lines ...
Attachment 3: HS_Centroids.m
% HS_Centroids.m
%
%
% HS_Centroids is a class used to generate and interact with centroids
% of Hartmann Sensor images.
%
% An instance of the class HS_Centroids holds a set of centroids of an
% image.
%
% Properties:
... 254 more lines ...
Attachment 4: HWS_code_output.png
HWS_code_output.png
Attachment 5: HWS_input_image.png
HWS_input_image.png
  113   Thu Feb 24 14:23:58 2011 AidanLab InfrastructureHartmann sensorHartmann Sensor box cut down to size

 I reduced the height of the Hartmann sensor box. This is what it looks like now:

 

Attachment 1: P1000109.jpg
P1000109.jpg
Attachment 2: P1000110.jpg
P1000110.jpg
Attachment 3: P1000111.jpg
P1000111.jpg
Attachment 4: P1000113.jpg
P1000113.jpg
  69   Thu Jul 22 21:46:55 2010 James KunertMiscHartmann sensorHartmann Sensor Thermal Defocus Measurement Noise & Ambient Light Effects

As discussed during the teleconference, a series of experiments have been conducted which attempt to measure the thermally induced defocus in the Hartmann sensor measurement. However, there was a limiting source of noise which caused a very large displacement of the centroids between images, making the images much too noisy to properly analyze.

The general setup of this series of experiments is as follows: the fiber output from the SLED was mounted about one meter away from the Hartmann sensor. No other optics were placed in the optical path. Everything except for the Hartmann sensor was enclosed (a box was constructed out of wall segments and posterboard, with a hole cut in the end which allowed the beam to propagate into the sensor. The sensor was a short distance from the end of the box, less than a centimeter. There was no obvious difference in test images taken with the lights on and the lights off, which previously suggested to me that ambient light would not have a large effect). Temperature variations in the sensor were induced by changing the set temperature of the lab with the thermostat. A python script was used to take cumulative sums of 200 images (taken at 11Hz) every ~5 minutes.

This overly large centroid displacement appeared only in certain areas of the images. However, changing the orientation of the plate appeared to change the regions which were noisy. That is, if the orientation of the Hartmann plate was not changed between measurements, the noise would appear in the same regions in consecutive experiments (even in experiments conducted on different days). However, if the orientation of the Hartmann plate was changed between measurements, the noise would appear in a different region in the next experiment. This suggests that the noise is perhaps due to a physical phenomenon which would change with the orientation of the plate.

There were a few hypotheses which attempted to explain this noise but were shown to not be the likely cause. I hypothesized that the large thermal expansion coefficient of the aluminum camera housing could be inducing a stress on the invar frontplate, causing the Hartmann plate to warp. This hypothesis was tested by loosening the screws which attach the front and back portion of the frontplate (such that the Hartmann plate was not strongly mechanically coupled with the rest of the frontplate) and running another iteration of the experiment. The noisy regions were seen to still appear, indicating that thermally induced stress was not the cause of the distortion. Furthermore, experiments done while the sensor was in relative thermal equilibrium over long periods still showed noisy regions, and there was no apparent correlation between noise magnitude and sensor temperature for any experiment, indicating that thermal effects in general were not responsible.

Another suspected cause was the increased noise at intensity levels of 128 (as discussed in a previous eLog). However, it was observed that there was no apparent difference in the prevalence of 128-count pixels between the noisy regions and the cleaner regions, indicating that this was not the cause either.

A video was made which shows vector plots of centroid displacements for each summed image relative to the first image taken in an experiment, and was posted as an unlisted youtube video at: http://www.youtube.com/watch?v=HUH1tHRr98I

The length of each vector in the video is proportional to the magnitude of the displacement. The localization of the noise can be seen. Notice also the sudden appearance and disappearance of the noise at images 19 and 33, indicating that the cause of the noise is relatively sudden and does not vary smoothly.

Another video showing a logarithmic plot of the absolute value of the difference of each image from the first image (for the same experiment as previous) can be seen here: http://www.youtube.com/watch?v=_CiaMpw9Ig0

Notice there are jumps in the background level which appear to correspond with the disappearance and appearance of the noisy regions in the centroids (at images 18 and 32) (I forgot to manually set the framerate on these last three .avi's, so they go by a little too quickly, but it's still all there). The one-image delay between the intensity shift and centroid noise shift is perhaps related to the fact that the analysis uses the previous image centroids as the reference to find the new image centroid locations.

A video showing histograms of the intensity of each pixel in an image (within the intensity range of 50 and 140 in the averaged summed-image) for this same experiment can be seen at: http://www.youtube.com/watch?v=MogPd-vaWn4

Notice that the peak of the distribution corresponding to the background appears to shift by ~5 counts at images 18 and 32.

 

An experiment was then done which had the exact same procedure except that it was done at a stabilized lab temperature and with the SLED turned off, such that only the background appears in each image. A logarithmic plot of the absolute value of the difference in intensity at each pixel for each image can be seen at: http://www.youtube.com/watch?v=Y66wL5usN18

Other work was being done in the lab throughout the day, so the lights were on for every image but one. I made a point of turning off the lights while the 38th image was being taken. The framerate of the linked video is unfortunately a little too fast to really see what goes on (I adjusted the framerate while viewing it in MATLAB but forgot to do so for the AVI), but you can clearly see a major change in the image during the 38th image, and during that image only (it looks like a red 'flash' at the 38th frame, near the very end). The only thing that was changed while taking this specific image was the ambient light level, so this major difference must be due to ambient light. A plot of the difference between images 38 and 1 is shown below:

72210b_ambient.png

Note that the maximum difference between the images is 1107 levels, which for the 200 images in each summed image corresponds to an average shift of ~5.5 levels. This is of a very similar magnitude to the shift that can be seen in the histogram of the previous experiment. This suggests that changes in ambient light levels are perhaps somehow responsible for the noisy regions of the image. Note also the non-uniformity of the ambient light; such a non-uniform change could certainly shift the centroid positions.

One question is how, exactly, this change might have propagated into the analysis. The shape of the background level change appears to be very different from the shape of the noisy regions seen for this plate configuration. This is something which I need to examine further; this, combined with the fact that the changes in the noise appear to occur one image after the actual change in intensities, suggests to me that there could perhaps be some subtle things going on with my data analysis procedures which I don't currently fully understand.

Still, I highly suspect that ambient light is the root cause of the noisy regions. It would be a remarkable coincidence if the centroid displacement shift was not ultimately due to the observed intensity shift, or if the intensity shift was not due to a change in ambient light (since the intensity shift in the histogram analysis and ambient light change in the background analysis are observed to correspond to roughly the same magnitude of intensity change). I had initially suspected that effects from ambient light would be negligible since, while taking test images while setting up each experiment, the image did not appear to change based upon whether I had the lights on or off. I checked this a few times, but did not examine the images closely enough to be able to detect such a small non-uniform change in the intensity of each image.

If ambient light was responsible, this could also perhaps explain why the location of the noise appeared to depend on the orientation of the plate. The Hartmann plate would be in the optical path of any ambient light leaking in, so a change in the orientation of the plate could perhaps change the way that the ambient light was propagating onto the sensor (especially since the Hartmann plates are slightly warped and not perfectly planar). That's all purely speculation at this point, but it's something that I intend to investigate further.

I tried analyzing some previous data by subtracting part of the background, but was unsuccessful at reducing the noise in the results. I attempted to reduce the background in previous data by setting all values below a certain threshold equal to zero (before inputting the image into the centroiding function). However, the maximum threshold which I could use before getting an error message was ~130. If I set the threshold to, say, 135, I received an error from the centroiding function that the image was 'too dissimilar to the hex grid'. I did analysis of the images with a threshold of 130, but this still left random patches of background spaced between the spots in each image. The presence of only patches of background as opposed to the complete background actually increased the level of noise in the results by about a factor of 3. I would need to come up with a better method of subtracting the background level if I wanted to actually reduce the noise in this data.

The next step in this work, I think, will perhaps be to better enclose the system from ambient light to where I'm confident that it could have little or no effect. If noisy regions were not seen to appear after this was done, that would more or less confirm that ambient light was the cause of all this trouble. Hopefully, if ambient light is indeed the cause of the noise, reducing it will enable an accurate and reliable measurement of thermally induced defocus within the Hartmann sensor.

  114   Mon Feb 28 17:33:07 2011 AidanComputingHartmann sensorHartmann Seidel abberation channels in frame builder

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

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

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

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


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

Quote:

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

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

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

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

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

 

C4TCS.ini

 

[default]

dcuid=4

datarate=16

gain=1.0

acquire=1

ifoid=0

datatype=4

slope=1.0

offset=0

units=NONE

 

 

 

[C4:TCS-HWS_TEMP_SENSOR]

[C4:TCS-HWS_TEMP_DIGITIZER]


 

 

 

 

  186   Mon Jun 5 16:41:59 2017 AidanLaserHartmann sensorHWS long term measurement results.

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

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

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

Attachment 1: HWS_envelope_long_term.pdf
HWS_envelope_long_term.pdf
Attachment 2: HWS_optical_parameters_long_term.pdf
HWS_optical_parameters_long_term.pdf
Attachment 3: HWS_envelope_long_term_mm.pdf
HWS_envelope_long_term_mm.pdf
Attachment 4: IMG_9836.JPG
IMG_9836.JPG
  210   Wed May 16 16:47:29 2018 AidanLaserHartmann sensorHWS green LED fiber launcher - D1800125-v5_SN01

Here is the output from D1800125-v5_SN01.

Quote:

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

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

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

Quote:

 [Aidan, Marie]

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

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

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

 

 

Attachment 1: HWS_LED_D1800125_V5_sn01.pdf
HWS_LED_D1800125_V5_sn01.pdf
Attachment 2: HWS_LED_D1800125_V5_sn01.m
% get the beam size from the HWS ETM source D1800125-v5_sn01

[out,r] = system('tar -xf HWS*.tar');

% load the files
dist = [1,10,29,51,84,105,140,180,240,295,351,435,490,565]; % beam propagation distance
files = dir('*.raw');
close all

... 49 more lines ...
Attachment 3: HWS_D1800125-v5_sn01_characterize_20180516.tar
  211   Fri May 18 16:32:37 2018 AidanLaserHartmann sensorHWS green LED fiber launcher - D1800125-v5_SN01

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

Quote:

Here is the output from D1800125-v5_SN01.

Quote:

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

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

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

Quote:

 [Aidan, Marie]

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

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

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

 

 

 

  208   Fri May 11 12:32:21 2018 AidanLaserHartmann sensorHWS green LED fiber launcher

 [Aidan, Marie]

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

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

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

Attachment 1: LED_test_01_20180511.pdf
LED_test_01_20180511.pdf
  209   Fri May 11 16:18:47 2018 AidanLaserHartmann sensorHWS green LED fiber launcher

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

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

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

Quote:

 [Aidan, Marie]

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

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

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

 

Attachment 1: LED_test_02_20180511.pdf
LED_test_02_20180511.pdf
  123   Tue Mar 8 18:48:00 2011 AidanComputingHartmann sensorHWS code is running and recording centroids

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

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

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

 

  150   Thu May 26 11:56:46 2011 AidanElectronicsLaserGreen Laser Pointer beam profile

This measurement was made with the Thorlabs DCC1545M-GL camera with an RG850 3mm long-pass filter over the CCD.

The beam radius (w) is 191 pixels, where the beam intensity = exp[-2 (x/w)^2 ]

The pixel size is 5.2um. Hence the beam size is 993.2um, which is basically near enough to 1mm radius.

 

Attachment 1: green_laser_pointer.bmp
Attachment 2: green_laser_pointer.pdf
green_laser_pointer.pdf
Attachment 3: Screen_shot_2011-05-26_at_12.28.20_PM.png
Screen_shot_2011-05-26_at_12.28.20_PM.png
  115   Mon Feb 28 17:56:32 2011 AidanComputingHartmann sensorGot HWS code running and interface to EPICS

Here are the notes from today's efforts:

 

 

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

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

- Now have to install MCA

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


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

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

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

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

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


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

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

-----------

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


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

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

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

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

hsep_secondary =

  HS_EPICS handle

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

  Methods, Events, Superclasses

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

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

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

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

Added the following lines to HWS.db

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

- restarting IOC with C4:TCS-HWSX channels

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

-time to add these to the frames



 

  206   Mon Feb 5 15:08:06 2018 AidanComputingDAQFrame builder clock is totally wrong

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.

  100   Thu Nov 4 13:31:19 2010 Won KimComputingHartmann sensorFrame Grabber SDK installation

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

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

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

Won

---

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

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

2. Ensure that the script is executable.

: chmod +x EDTpdv_lnx_4.2.4.3.run

3. Run the script.

: sudo ./EDTpdv_lnx_4.2.4.3.run

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

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

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

: cd /opt/EDTpdv

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

: ./initcam -f camera_config/dalsa_1m60.cfg

  Which will output the message (if successful)

opening pdv unit 0....
done


7. Take an image frame.

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

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

reading image from Dalsa 1M60 12 bit dual channel camera link
width 1024 height 1024 depth 12  total bytes 2097152
writing 1024x1024x12 raw file to /home/won/matlab/images/test.raw

(actual size 2097152)

1 images 0 timeouts 0 overruns



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

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

  142   Mon Apr 25 16:28:27 2011 Aidan, JoeComputingNetwork architectureFixed problem network drive fb1:/cvs on Ubuntu & CentOS machines

With Joe's help we fixed the failure of princess_sparkle to mount the fb1:/cvs directory when relying on /etc/fstab.

First we changed the mounting options in fstab to the following:

fb1:/cvs        /cvs            nfs     rw,bg,soft        1 1

When we got the following error trying it directly from the command line,

controls@princess_sparkle:~$ sudo mount /cvs
[sudo] password for controls:
mount: wrong fs type, bad option, bad superblock on fb1:/cvs,
       missing codepage or helper program, or other error
       (for several filesystems (e.g. nfs, cifs) you might
       need a /sbin/mount.<type> helper program)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

some quick Google searches suggested installing nfs-common, so we tried sudo apt-get install nfs-common and that seemed to do the trick.

CentOS

For the CentOS machines, the following was done:

sudo mkdir /cvs

and then the same mounting configuration was added to /etc/fstab
 

Additionally, all three machines now have a /users symbolic link to /cvs/users

  106   Fri Feb 18 13:26:23 2011 AidanThings to BuyDelivery NoteFirst parts of Bosch framing have arrived from Valin

The first pieces of the Bosch framing have arrived from Valin Corporation. These are just small pieces such as the fasteners and the gussets. There are no custom lengths of framing yet.

The details are in the attached Packing List. [1:25PM] I haven't verified that everything is there yet.

 

Attachment 1: Packing_List_01.pdf
Packing_List_01.pdf Packing_List_01.pdf
  108   Wed Feb 23 18:04:38 2011 AidanThings to BuyDelivery NoteFirst parts of Bosch framing have arrived from Valin

Quote:

The first pieces of the Bosch framing have arrived from Valin Corporation. These are just small pieces such as the fasteners and the gussets. There are no custom lengths of framing yet.

The details are in the attached Packing List. [1:25PM] I haven't verified that everything is there yet.

 

 Another box of Bosch stuff arrived in my office. The packing list is attached

Attachment 1: Packing_List_02.pdf
Packing_List_02.pdf Packing_List_02.pdf
  18   Mon Apr 12 17:25:01 2010 AidanElectronicsHartmann sensorFiber-Camera Link demonstration

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

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

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

 

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

The attached images:

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

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

 

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

 

 

 

 
 
 
 
 
 
 
 
 

 

Attachment 1: hartmann_sensor.JPG
hartmann_sensor.JPG
Attachment 2: Fiber_Camera_Link_1.jpg
Fiber_Camera_Link_1.jpg
Attachment 3: Fiber_Camera_Link_3.jpg
Fiber_Camera_Link_3.jpg
  124   Tue Mar 8 18:57:50 2011 AidanThings to BuyDelivery NoteFiber optics cable and Bosch Fastener
Attachment 1: deliveries_2011-03-08.pdf
deliveries_2011-03-08.pdf deliveries_2011-03-08.pdf
  241   Fri Aug 16 17:05:14 2019 Edita BytyqiElectronics FLIR Images of new reflector focusing heat

We got 11 new semi-circle cut reflectors of radius ~3.6 cm. I glued a screw to the back of one reflector using the same epoxy as for the previous reflectors. Due to the bigger ROC of the reflector, a tight focus is achievable at greater distances (~15 cm).

  202   Thu Nov 9 14:18:56 2017 AidanComputingDAQFB4 ip address has changed

We've had trouble logging into FB4. I access the computer directly in the AWC lab and found that the IP address had changed from 10.0.1.156 to 10.0.1.161.

I'm not sure how this happened. It's possible that the IP address is not set to a static value and FB4 was rebooted. I'm not familar with Debian so I don't know where to look to find whether the IP address is static or not.

The DAQD is still running.

  213   Wed May 30 18:59:49 2018 awadeComputingDAQFB4 ip address has changed

Maybe you've resolved this now. I moved the DHCP allocation to 10.0.1.160 and above around that time because a bunch of misc devices were starting to populate the dynamically allocated IP space around there.  I'd say FB4 was not setup with a manual IP at the time.

 

Quote:

We've had trouble logging into FB4. I access the computer directly in the AWC lab and found that the IP address had changed from 10.0.1.156 to 10.0.1.161.

I'm not sure how this happened. It's possible that the IP address is not set to a static value and FB4 was rebooted. I'm not familar with Debian so I don't know where to look to find whether the IP address is static or not.

The DAQD is still running.

 

  242   Tue Sep 3 10:49:57 2019 AidanLab InfrastructureGeneralExhaust duct added for new bake area in TCS lab

Facilities came in on Friday and teed off a new duct to provide exhaust for the proposed new vacuum bake area in the TCS Lab. Photos are attached. 

We installed a plastic sheet between the work area and the rest of the lab (the rest of the lab was overpressurized relative to the work area). Also, they use a vacuum when doing any drilling.

 

Attachment 1: IMG_1627.jpg
IMG_1627.jpg
Attachment 2: IMG_1629.jpg
IMG_1629.jpg
Attachment 3: IMG_1628.jpg
IMG_1628.jpg
Attachment 4: IMG_1626.jpg
IMG_1626.jpg
  94   Mon Sep 13 18:24:52 2010 AidanLaserHartmann sensorEnclosure for the HWS

I've assembled the box Mindy ordered from Newport that will house the Hartmann sensor. It's mainly to reduce ambient light, air currents and to keep the table cleaner than it would otherwise be.

We need to add a few more holes to allow access for extra cables.

 

Attachment 1: 00001.jpg
00001.jpg
Attachment 2: 00002.jpg
00002.jpg
Attachment 3: 00003.jpg
00003.jpg
Attachment 4: 00005.jpg
00005.jpg
  116   Tue Mar 1 10:47:18 2011 AidanMiscHartmann sensorElectron to Counts conversion efficiency

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

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

noiseE = sqrt(Ne);

Number of Counts (NCo)= CE*Ne

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

noiseCo = sqrt(CE * NCo)

log(CE) = 2*noiseCo - NCo

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

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

 

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

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

 

  120   Thu Mar 3 07:30:18 2011 WonComputingHartmann sensorEffect of high pixel count on rms

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

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

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

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

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

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

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

rms-low.png
 

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

rms-all.png


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

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

2. centroids whose peak pixel counts are above 2047 (859 out of 904 centroids). 
rms-under.pngrms-over.png
Peak pixel counts were obtained from the first image frame. As pixel counts fluctuate between image frames, it would perhaps be better to use averaged images but the outcome will still be qualitatively the same.

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

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

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

:PS:

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

rms_v_c_with.png

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

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

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

rms_v_pc-with.png slope_v_pc-with.png

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

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

rms_v_pc-without.pngslope_v_pc-without.png

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

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

Attachment 2: rms-low.png
rms-low.png
  91   Tue Aug 17 22:34:14 2010 ranaMiscGeneralETM temperature after a 1W step

This attachment is a Shockwave Flash animation of the iLIGO ETM getting a 1 W beam with a 3.5 cm radius getting fully absorbed onto the surface at t = 0.

Attachment 1: etmt.swf
  83   Fri Jul 30 11:01:31 2010 AidanComputingHartmann sensorEPICS softIoc alias

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

 

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

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

 

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

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

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

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

 

Attachment 1: history.txt
    1  cd
    2  mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
    3  echo '%_topdir %(echo $HOME)/rpmbuild' > .rpmacros
    4  ls
    5  cd rpmbuild/
    6  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18.15.1.el5.src.rpm 2
    7  cd ..
    8  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18.15.1.el5.src.rpm 2>&1 | grep -v mockb
    9  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.e15.src.rpm 2>&1 | grep -v mockb
   10  rpm -i http://mirror.centos.org/centos/5/updates/SRPMS/kernel-2.6.18-164.15.1.e15.src.rpm 2>&1 | grep -v mockb
... 183 more lines ...
Attachment 2: history_root.txt
    1  yum
    2  yum install gcc
    3  yum install make
    4  yum install tk
    5  yum install tcl
    6  yum install mm
    7  yum install kernel
    8  yum install source
    9  yum install include
   10  yum install kernel-source
... 797 more lines ...
  32   Thu May 6 10:34:38 2010 AidanComputingHartmann sensorEPICS and MEDM screen for Hartmann sensor - part 2

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

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

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

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

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

# Import the Dalsa1M60 packzge
import Dalsa1M60, subprocess

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

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

# NAME
#       GetCameraParameters - a module for getting the Dalsa 1M60 parameters
#
# PACKAGE
#       Part of the Dalsa1M60 python package
#
# SYNOPSIS
#       GetCameraParameters( serial_cmd_location  )
... 412 more lines ...
Attachment 3: HWS.db
record(ai,"C4:TCS-HWS_TEMP_DIGITIZER")
record(ai,"C4:TCS-HWS_TEMP_SENSOR")
record(ai, "C4:TCS-HWS_TAP1GAIN")
record(ai, "C4:TCS-HWS_TAP2GAIN")
record(ai, "C4:TCS-HWS_PRETRIGGER")
record(ai, "C4:TCS-HWS_DATA_MODE")
record(ai, "C4:TCS-HWS_BINNING_MODE")
record(ai, "C4:TCS-HWS_GAIN_MODE")
record(ai, "C4:TCS-HWS_OUTPUT_CONFIG")
record(ai, "C4:TCS-HWS_EXPOSURE_MODE")
... 27 more lines ...
Attachment 4: C4TCS.ini
[default]
dcuid=4
datarate=16
gain=1.0
acquire=1
ifoid=0
datatype=4
slope=1.0
offset=0
units=NONE
... 14 more lines ...
  28   Tue May 4 10:30:07 2010 AidanComputingHartmann sensorEPICS and MEDM screen for Hartmann sensor

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

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

Response from 1M60

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

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

 

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

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

 

 

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


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

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


ii = 1;
while ii == 1
    [s, r] = unix('/opt/EDTpdv/serial_cmd vt');
... 54 more lines ...
  103   Tue Nov 30 11:03:19 2010 AidanComputingFrame GrabberEDT frame grabber works under Ubuntu

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

  17   Mon Apr 12 08:55:37 2010 AidanComputingHartmann sensorEDT frame grabber is here

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

  240   Mon Aug 12 21:15:12 2019 Edita BytyqiElectronics Determining heater/reflector focus

I took images of the heat pattern projected on a piece of paper produced by the semi-circle reflector. I used 108V to drive current throught he heater. I tested the reflector without any coating and then with the dull and shiny sides of Al foil. I wasn't able to test the focal-point cut reflector because I had to glue a screw to it with epoxy which cures overnight. I will do these measurements tomorrow. Figure 2 shows the setup I used to get the data. The shiny side of Al foil is better at IR, so we will use that for the wavefront measurements.

Attachment 1: 20190812_151316.jpg
20190812_151316.jpg
Attachment 2: 20190812_151258.jpg
20190812_151258.jpg
  151   Mon May 30 10:53:00 2011 AidanLaserHartmann sensorDefocus vs time

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

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

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

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

Attachment 1: HWS_defocus_vs_temperature.pdf
HWS_defocus_vs_temperature.pdf
  70   Fri Jul 23 10:33:08 2010 AidanComputingHartmann sensorDalsa camera ADC 8th digitizer error

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

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

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

 

Number of counts Hex Code

128

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

 

Attachment 1: histogram_of_dalsa_intensity.pdf
histogram_of_dalsa_intensity.pdf
  73   Fri Jul 23 19:52:49 2010 AidanComputingHartmann sensorDalsa camera ADC 8th digitizer error

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

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

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

Quote:

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

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

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

 

Number of counts Hex Code

128

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

 

 

Attachment 1: image-location-of-excess_pixel_count_pixels.jpg
image-location-of-excess_pixel_count_pixels.jpg
  119   Tue Mar 1 17:05:45 2011 AidanElectronicsHartmann sensorDalsa 1M60 current draw

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

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

12.7V       0.6A              0.8A              1.11A

15.0V       0.55A             0.69A             0.91A

18.0V       0.41A             0.57A             0.75A

20.0V       0.42A             0.52A             0.67A

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

Exposure Mode 4: current = 0.67A

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

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

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

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

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

  170   Mon Jun 18 23:42:39 2012 Aditi MittalMiscLIGO 3GCryogenic Shielding

 -Read about blue team design for maximum power budget.

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

  96   Tue Sep 28 17:53:40 2010 AidanLaserHartmann sensorCrude alignment of cross-sampling measurement

I've set up a crude alignment of the cross-sampling system (optical layout to come). This was just a sanity check to make sure that the beam could successfully get to the Hartmann sensor. The next step is to replace the crappy beam-splitter with one that is actually 50/50.

Attached is an image from the Hartmann sensor.

Attachment 1: 2010_09_28-HWS_cross_sample_expt_crude_alignment_01.pdf
2010_09_28-HWS_cross_sample_expt_crude_alignment_01.pdf
  97   Wed Sep 29 16:49:36 2010 AidanLaserHartmann sensorCross-sampling experiment power budget

I've been setting up the cross-sampling test of the Hartmann sensor, Right now I'm waiting on a 50/50 BS so I'm improvising with a BS for 1064nm.

The output from the SLED (green-beam @ 980nm) is around 420uW (the beam completely falls on the power meter.) There are a couple of irises shortly afterwards that cut out a lot of the power - apparently down to 77uW (but the beam is larger than the detection area of the power meter at this point - by ~50%). The BS is not very efficient on reflection and cuts down the power to 27uW (overfilled power meter). The measurement of 39uW is near a focus and the power meter captures the whole beam. There is a PBS cube that is splitting the beam unequally between s- and p-polarizations (I think this is due to uneven reflections for s- and p-polarizations from the 1064nm BS). The beam is retro-reflected back to the HWS where about 0.95uW makes it to the detector.

There is a 1mW 633nm laser diode that is used to align the optical axis. There are two irises that are used to match the optical axis of the laser diode and the SLED output.

 

Attachment 1: 00001.jpg
00001.jpg
  98   Mon Oct 4 19:44:03 2010 AidanLaserHartmann sensorCross-sampling experiment - two beams on HWS

I've set up the HWS with the probe beam sampling two optics in a Michelson configuration (source = SLED, beamsplitter = PBS cube). The return beams from the Michelson interferometer are incident on the HWS. I misaligned the reflected beam from the transmitted beam to create two Hartmann patterns, as shown below.

The next step is to show that the centroiding is a linear superposition of these two wavefronts.

Attachment 1: test001_two_beams_on_HWS.pdf
test001_two_beams_on_HWS.pdf
ELOG V3.1.3-