40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 66 of 341  Not logged in ELOG logo
ID Date Author Type Categoryup Subject
  11851   Sat Dec 5 12:02:25 2015 yutaroHowToCamerasWhen image capture does not work...

Today image capture did not work again, though it had worked 3 days before. I also found that red indicator light on the front pannel of SENSORAY was not turned on, which had been turned on 3 days before (you can find SENSORAY on the floor near Pianosa). Possible reason that it did not work again was I restarted Pianosa last night. Anyway, it works now. Here I report what I did to make it work.

 

I ran thes commands in shell, following the instruction of the manual of SENSORAY 2253 (Page 5; link or you can find the manual in /users/sensoray; I put it there). 

> cd /users/sensoray/sdk_2253_1.2.2_linux

> make all

> sudo make install

> modprobe s2253

Then the red light got turned on, and image capture worked.

 

If you recieve an error like "No such file or directory: /dev/video0" at the beginning of the error message when you run image capture scripts from the medm screen, or if you notice that the red indicator light of SENSORAY is not on, this procedure could help you. 

  11852   Sat Dec 5 21:28:33 2015 KojiHowToCamerasWhen image capture does not work...

Do we need "make" everytime? Do you mean just running "modprobe" didn't work?

  11853   Sat Dec 5 21:57:32 2015 yutaroHowToCamerasWhen image capture does not work...

I don't know if just running "modprobe" will work or not, because I didn't try it...  When the same problem happens again, we can try just running "modprobe" first.

  12617   Tue Nov 15 20:26:35 2016 JohannesUpdateCamerasBasler GigE-Camera on Optimus (+Mafalda dead)

I powered up the existing ace100gm GigE cam with the PoE injector and tried to interface with it as described in elog 4163. After a few initial problems with IP assignment and interfacing I connected it to one of the gigabit hubs and installed the most recent pre-compiled software suite on /opt/pylon5 on optimus, after which I was able to find it with the configuration software. I named it "c1gige_bas100-1" and gave it the static IP address 192.168.113.151.

Afterwards the image acquisition worked without problems.

It may be a good idea to leave the gigecam interfacing up to a dedicated machine. I was thinking I could use Mafalda for this, and also for developing the code for framegrabbing and imager settings, but found that it was dead, burnt at the stake so to say. I guess it wasn't running anything critical, since it wasn't even connected to the network and smelled like burnt electronics. I'll get a replacement desktop for it.

Attachment 1: gige_test.png
gige_test.png
  12622   Thu Nov 17 12:14:21 2016 ranaUpdateCamerasBasler GigE-Camera on Optimus (+Mafalda dead)

Indeed. I suggest discussing with Joe B. I believe we should use a dedicated cam network to get the camera signals from the ends and corner all into one machine. Do not use the main CDS FE network for this since it might produce weird collissions. How about make a diagram, post it to elog, and send link to Joe?

It may be a good idea to leave the gigecam interfacing up to a dedicated machine.

  12937   Mon Apr 10 16:00:26 2017 rebeccaUpdateCamerasPylon installation warning

When trying to install an older version of Pylon packaged for Debian that Joe B. had sent, it gave the warning that the package was of bad quality along with the details below.

Is it safe to ignore the warning? Or should I hold off on the installation?

Lintian check results for /home/controls/Downloads/pylon-2.3.3-1.deb:
Use of uninitialized value $ENV{"HOME"} in concatenation (.) or string at /usr/bin/lintian line 108.
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.IpConfigurator
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.PylonViewerApp
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.SpeedOMeter
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3.2
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3.7.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/plugins/imageformats/libqtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libXMLLoader_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApiPreProcessor
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGCBase_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGenApi_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libLog_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libMathParser_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/liblog4cpp_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige.so

  12938   Mon Apr 10 18:42:09 2017 johannesUpdateCamerasPylon installation warning

It looks like we may not need to use this old Pylon version after all. Gautam and I looked into installing SnapPy with the makefile in scripts/GigE/SnapPy/ that he modified (removed the linkage to paths that don't exist in Pylon 5). Compiling took a while (~10 minutes) but eventually succeeded. The package was installed to /ligo/apps/linux-x86_64/camera/

GV 10pm April 10 2017: We didn't actually try executing an image capture or change some settings using the python utilities, that remains to be done..

  12953   Thu Apr 27 17:55:33 2017 SteveUpdateCameraswhich camera to use for IR scatterring pictures

Yesterday I failed to take good pictures of ETMY  resonant arm of 1064 nm with Cannon Rebel T3i in RAW 22-27Mp & JPG dual- format. UFRaw file converter worked well. The IR blocker filter seems to be too good.

Today I used Olympus SP-570UZ ( without IR blocker), in raw format of 15Mp, fl 22.4mm, 15s including 2-3s flashlight,  f/8 and auto focus  This is just too much scattered IR for the Olympus.

Overexposed raw picture' jpg is shown  at the PSL with diffraction patter of the camera.

I'll go back using  the Nikon D40 with zoom 55-200mm as this Atm2 of May 2007 : manual focus, 15s, f/4-5.6, ISO 560,  826KB

Attachment 1: P4270081RAWolym.jpg
P4270081RAWolym.jpg
Attachment 2: Img0344.jpg
Img0344.jpg
  12956   Fri Apr 28 18:01:56 2017 rebeccaUpdateCamerasAttempting to Load Camera Client

Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.
 

  12958   Fri Apr 28 22:50:35 2017 johannesUpdateCamerasAttempting to Load Camera Client

You'll likely have to run camera_server.py using the same ini file first before you can use the client. Since the pylon installation is not on the shared drive but only local to optimus at the moment you would have to do it from there. You'll need to add /opt/pylon5/lib64/ to LD_LIBRARY_PATH or it won't find some required libraries. I couldn't start up the server all the way, probably because we need to define some slow EPICS channels before running the server script, as Joe points out in his document T1300202. You'll find instructions how to do that for example in this elog.

 

Quote:

Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.
 

 

  12959   Sun Apr 30 13:24:00 2017 ranaUpdateCamerasAttempting to Load Camera Client

We ought to put the camera software on the shared disk; I don't think there's any speed reasons that it needs to be local.

Its OK to use optimus as the camera server for testing at the moment, but once we have things running, we'll install a few more cameras. With ~4-5 GigE running, we may not want to share with optimus, since we're also using it for comsol and skymap calculations.

  12961   Mon May 1 17:14:58 2017 SteveUpdateCamerasETMY & MC2 ccd cameras removed

MC2 ccd camera is replaced by Olympus 570 zoom temporarly.

So as the ETMY ccd camera is replaced by Cannon Rebel.

Both viewport are under Lexan protection and covered by Aluminum foil....still, turn all lighting off if you do not want room light in the IFO

 

Do not remove Lexan shield!

 

  12973   Fri May 5 08:41:42 2017 SteveUpdateCamerasMC2 resonant pictures

Olympus SP570 UZ - without  IR blocker, set up as Atm.3  Camera distance to MC  face ~85 cm,  IOO-MC_TRANS_SUM 16,300 counts, Lexan cover on not coated viewport.

Image mode: RAW + JPG,  M-costum,  manual focus,  Lens: Olympus 4.6 - 92 mm, f2.8 - 4.5,  Apeture: F2.8 - 8,  Image pick up device: 1/2.33" CCD (primary color filter)

Atm.1,       212k.jpg of raw 15 MB,  exp 0.025s,   apeture 2.97,  f 4.6,   iso 64,  

Atm.2,        Copied through my Cannon S100  (  3.3 MB.jpg of raw from UFraw photo shop )I will look up the original raw file for details.

 

Attachment 1: P5040028MC2c.jpg
P5040028MC2c.jpg
Attachment 2: IMG_3682.JPG
IMG_3682.JPG
Attachment 3: IMG_3688.JPG
IMG_3688.JPG
  12989   Fri May 12 18:45:04 2017 rebeccaUpdateCamerasMC2 Pics with Olympus

Raw and JPG formats of the pictures are saved on the Mac in the control room and at this link:

https://drive.google.com/open?id=0B9WDJpPRYby1c2xXRHhfOExXNFU 

The camera was mounted using the JOBE arm wrapped around a small heavy piece of metal. The lights were kept on, the camera was zoomed in as closely as possible (so the light would take up most of the frame), F number of 8 was used, and shutter speeds from 1/2 to 1/100 seconds were used. 

The pictures still look a bit blurry, probably because looking back at the details of the image, the focal length was 86.34m (as short of a focal length would be ideal, and Olympus is capable of going down to 1m).

Next steps include looking at the saturation in the pictures and setting up a more stable mount. 

  12996   Wed May 17 11:10:31 2017 SteveUpdateCamerasMC2 CCD video camera back in place

Olympus camera is removed and our old CCD camera is back to monitor the face of MC2

Quote:

Olympus SP570 UZ - without  IR blocker, set up as Atm.3  Camera distance to MC  face ~85 cm,  IOO-MC_TRANS_SUM 16,300 counts, Lexan cover on not coated viewport.

Image mode: RAW + JPG,  M-costum,  manual focus,  Lens: Olympus 4.6 - 92 mm, f2.8 - 4.5,  Apeture: F2.8 - 8,  Image pick up device: 1/2.33" CCD (primary color filter)

Atm.1,       212k.jpg of raw 15 MB,  exp 0.025s,   apeture 2.97,  f 4.6,   iso 64,  

Atm.2,        Copied through my Cannon S100  (  3.3 MB.jpg of raw from UFraw photo shop )I will look up the original raw file for details.

 

 

  13020   Tue May 30 17:45:35 2017 jigyasaSummaryCamerasGigE configuration

To verify the Pylon Installation on the shared drive, I tried connecting the Basler acA640-100gm to the PoE connector and running it through Allegra.

Each time the camera was opened, I got a message on Terminal saying ‘Failed to get the node ‘AcquisitionFrameRate’ from the device’s nodemap’.

Yet, I was able to capture images in single shot and continuous shot mode. I tried to emulate the analog controls (gain at 360, Black level 121) as in Johannes’ elog  12617 and varied the exposure rate from 1 to 5 milliseconds. The camera had the Rainbow 50mm lens with which I was able to focus on some markings on the white board, however the image was extremely magnified and this lens was extremely sensitive which meant that the image went quickly out of focus.
I checked the CCD cabinet in the 40m to find 12 mm lenses which couldn’t focus properly. So I couldn’t quite get an image as Johannes had been able to obtain! I also got an image of a cable in focus but it is very dark due to the exposure time.
 WIth the components for the telescope design arriving(hopefully) by tomorrow, I should be able to assemble the telescope and capture some more images.

From Joe B’s paper and discussion with Gautam and Johannes, I came up with three models for configuring the GigE’s. Three configuration models for the GigE have been proposed which connect the camera to a computer network. While the first model is just involves connecting the camera directly to a PC with Pylon installation using a Power over Ethernet adapter, it would be only efficient in the basic IP configuration of the camera without involving a complex network. The second model describes the integration of the camera to 'Martian'. The third model combines the creation of a separate camera subnetwork and integrating this network with the main network in the lab through a switch. This model would be more efficient to employ as the number of cameras increases. The same purpose could be achieved by using a PC with two network ports one of which connects to the camera subnet while another links it to the Martian where the computers running the client script could stream desired frames.

 

Attachment 1: GigEconfiguration.pdf
GigEconfiguration.pdf GigEconfiguration.pdf GigEconfiguration.pdf
  13024   Wed May 31 18:17:28 2017 jigyasaSummaryCamerasGigE configuration

This evening I was able to obtain some images with the same lens on the GigE. 
The problem earlier, as Johannes pointed out, was that we were using too many adapters on the camera and so it was able to focus at really shallow distances or at really low depths of focus. 
So after removing the adapters we were able to focus on objects at much larger distances.

The mug for example was at a distance greater than 1.5 meters from the camera.

Here are some images that were captured on Allegra by plugging in the GigE to the PoE connector connected to the Martian. 

Quote:

I tried to emulate the analog controls (gain at 360, Black level 121) as in Johannes’ elog  12617 and varied the exposure rate from 1 to 5 milliseconds. The camera had the Rainbow 50mm lens with which I was able to focus on some markings on the white board, however the image was extremely magnified and this lens was extremely sensitive which meant that the image went quickly out of focus.

 

Attachment 1: PictureswithPylon.pdf
PictureswithPylon.pdf PictureswithPylon.pdf
  13025   Wed May 31 19:18:53 2017 jigyasaSummaryCamerasGigE configuration

And here's another picture of Kaustubh, my fellow SURF, captured in all his glory by Rana! :)

 

Quote:

This evening I was able to obtain some images with the same lens on the GigE. 
The problem earlier, as Johannes pointed out, was that we were using too many adapters on the camera and so it was able to focus at really shallow distances or at really low depths of focus. 
So after removing the adapters we were able to focus on objects at much larger distances.

The mug for example was at a distance greater than 1.5 meters from the camera.

Here are some images that were captured on Allegra by plugging in the GigE to the PoE connector connected to the Martian. 

Quote:

I tried to emulate the analog controls (gain at 360, Black level 121) as in Johannes’ elog  12617 and varied the exposure rate from 1 to 5 milliseconds. The camera had the Rainbow 50mm lens with which I was able to focus on some markings on the white board, however the image was extremely magnified and this lens was extremely sensitive which meant that the image went quickly out of focus.

 

 

Attachment 1: Image__2017-05-31__18-49-37.bmp
  13027   Thu Jun 1 15:33:39 2017 jigyasaUpdateCamerasGigE installation in the IFO area

I tried to capture some images with the GigE inside the Interferometer area in the 40m today. For that, I connected the POE injector to the Netgear Switch in 1x6 and connected it to the GigE. I then tried to access the Pylon Viewer App through Paola but that seemed to have some errors. When trying to connect to the Basler, quite a few errors were encountered in establishing connection and trying to capture the image. There were a few errors with single shot capture but the continuous shot could not even be started. To locate the problem, I tried running the Pylon installation through Allegra in the control room and everything seemed to work fine there.

Few error messages encountered

createPylondevice error :Failed to read memory at 0xc0000000, 0xd800 bytes. Timeout. No message received.
Failed to stop the camera; stopgrab: Exception Occurred: Control Channel not open


Eventually I connected Paola to the Switch with an Ethernet cable and over this wired connection, the errors were resolved and I was able to capture some images in Continuous shot mode at 103.3 fps without any problem.

In the afternoon, Steve and I tried to install the camera near MC2 and get some images of the mirrors. Due to a restricted field of view of the lens on the camera, after many efforts to focus on the optic, we were able to get this image. MC2 was unlocked so this image captures some resonating higher order mode.

With MC2 locked, I will get some images of the mirror at different exposure times and try to get an HDR image.  
As per Rana's suggestion, I am also looking up which compression format would be the best to save the images in.

 

Attachment 1: HOMMC2.pdf
HOMMC2.pdf
  13029   Thu Jun 1 16:14:55 2017 jigyasaUpdateCamerasGigE installation in the IFO area

Thanks to Steve and Gautam, the IMC was locked.

I was able to capture images with the Rainbow 50 mm lens at exposure times of 100, 300, 1000, 3000, 10000 and 30 microseconds.(The pictures are in the same order). These pictures were taken at a gain of 300 and black level 64.

Special credits to Steve spent a lot of time help me a with setting up the hardware and focusing on the beam spot with the camera. 
I can't thank you enough Steve! :) 

Quote:

In the afternoon, Steve and I tried to install the camera near MC2 and get some images of the mirrors. Due to a restricted field of view of the lens on the camera, after many efforts to focus on the optic, we were able to get this image. MC2 was unlocked so this image captures some resonating higher order mode.

With MC2 locked, I will get some images of the mirror at different exposure times and try to get an HDR image.  
 

Attachment 1: MC2.pdf
MC2.pdf MC2.pdf MC2.pdf MC2.pdf MC2.pdf MC2.pdf
  13031   Thu Jun 1 20:16:11 2017 ranaUpdateCamerasGigE installation in the IFO area

Good installation. I think the images are still out of focus, so try to resolve into some small dots at the low exposure setting.

  13040   Mon Jun 5 12:27:34 2017 jigyasaUpdateCamerasAttempt to run camera server Python code

While attempting to execute the Python/Pylon code for the camera server, camera_server.py, the compiler couldn’t locate the pylon-5.0.5.so file. So I included the path for the required .so file as

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/rtcds/Caltech/c1/scripts/GigE/pylon5/lib64

So with the file linked, the python program gets executed but then shows an error self.text= gst.elementfactory_make(“textoverlay”, “text0”)
gst.ElementNotFoundError: textoverlay
 

The code reads- 

self.text= gst.elementfactory_make("textoverlay",text0")

Not sure what I am missing here. 

  13041   Mon Jun 5 12:50:42 2017 jigyasaUpdateCamerasAttempt to run camera server Python code

I think there might be a problem with the fact that the installation of the various components such as the .ini file and the Pylon software are in directories different from the ones Joe B. specifies in his paper. 

Instead of modifying the paths in the code itself, I tried creating the paths to match the code-

Update in /ligo directory 

/cds/caltech/c1/camera/L1-CAM-MC1.ini  created and then I ran the camera_server.py from scripts/GigE/SnapPy as

./camera_server.py -c /ligo/cds/caltech/c1/camera/L1-CAM-MC1.ini 

This prompted up the following on terminal- 

finished loading settings from /ligo/cds/caltech/c1/camera/L1-CAM-MC1.ini and lists the settings in the configuration file.


However the  gst.ElementNotFoundError: textoverlay still persists. 

Probably I could try putting all files in exactly the same directories as specified in the document. 

Quote:

So with the file linked, the python program gets executed but then shows an error self.text= gst.elementfactory_make(“textoverlay”, “text0”)
gst.ElementNotFoundError: textoverlay
 

The code reads- 

self.text= gst.elementfactory_make("textoverlay",text0")

Not sure what I am missing here. 

 

  13042   Mon Jun 5 15:04:33 2017 ranaUpdateCamerasAttempt to run camera server Python code

Right - we want to be compatible with new version of the code, so instead of moving the files to where the code wants them you should make symlinks. The symlinkks go in the place that the code wants and points back to the place where we have the files now.

For the textoverlay, you can just comment it out for now. We can add it back in later once we decide on how to label the video.

  13043   Mon Jun 5 18:40:12 2017 jigyasaUpdateCamerasAttempt to run camera server Python code

[Gautam, Jigyasa]

This evening, Gautam helped me resolve the error I had been encountering. I had been trying to run the code on Allegra and that threw up the gst.elementfactory_make(“textoverlay”, “text0”); gst.ElementNotFoundError: textoverlay error.
As an attempt to resolve the error, I had set up the paths to match those mentioned in the document.
However as it turns out, it wasn't really needed.

 When Gautam ran the code from Pianosa, the following error showed up
gst.elementfactory_make(“x264enc”, “ en ”);gst.ElementNotFoundError: x264.

We found that the x264 and x264enc are different entities.
Gautam then installed the Ubuntu- restricted-extras package with the following
gstreamer0.10-plugins-bad-multiverse
gstreamer0.10-plugins-ugly-multiverse

And eventually on compilation, the message ‘starting server’ was displayed on the screen. This was interrupted by another error GenICAM_3_0_Basler_pylon_v5_0::RuntimeException’

 So there is apparently a problem executing the commands on Allegra, because the camera server starts running on Donatella and Pianosa. 

I will now be looking into this newly encountered error and also be setting up the symlinks for the various paths in the code. 

Quote:

Probably I could try putting all files in exactly the same directories as specified in the document. 

Quote:

So with the file linked, the python program gets executed but then shows an error self.text= gst.elementfactory_make(“textoverlay”, “text0”)
gst.ElementNotFoundError: textoverlay
 

The code reads- 

self.text= gst.elementfactory_make("textoverlay",text0")

Not sure what I am missing here. 

 

 

  13045   Tue Jun 6 09:14:26 2017 SteveUpdateCamerasGigE installation at MC2

50mm 1.8 lens with Basler camera at MC2 face with micro clamp 350617    Camera manuals plus

Quote:

Thanks to Steve and Gautam, the IMC was locked.

I was able to capture images with the Rainbow 50 mm lens at exposure times of 100, 300, 1000, 3000, 10000 and 30 microseconds.(The pictures are in the same order). These pictures were taken at a gain of 300 and black level 64.

Special credits to Steve spent a lot of time help me a with setting up the hardware and focusing on the beam spot with the camera. 
I can't thank you enough Steve! :) 

Quote:

In the afternoon, Steve and I tried to install the camera near MC2 and get some images of the mirrors. Due to a restricted field of view of the lens on the camera, after many efforts to focus on the optic, we were able to get this image. MC2 was unlocked so this image captures some resonating higher order mode.

With MC2 locked, I will get some images of the mirror at different exposure times and try to get an HDR image.  
 

 

Attachment 1: MC2.jpg
MC2.jpg
  13054   Fri Jun 9 09:13:26 2017 SteveUpdateCamerasGigE camera lens with AR

We should move on with getting this lens from Edmonds #67-717  at 1064 R<3% 

Computar M5018-SWIR is an other choice

AR coatings 500 - 1100nm R<1% are expensive.

 

Quote:

50mm 1.8 lens with Basler camera at MC2 face with micro clamp 350617    Camera manuals plus

 

Attachment 1: coating_curve.pdf
coating_curve.pdf
  13070   Fri Jun 16 18:21:40 2017 jigyasaConfigurationCamerasGigE camera IP

One of the additional GigE cameras has been IP configured for use and installation. 

Static IP assigned to the camera- 192.168.113.152
Subnet mask- 255.255.255.0
Gateway- 192.168.113.2
 

  13074   Tue Jun 20 14:58:08 2017 SteveUpdateCamerasGigE camera at ETMX

GigE can be connected to ethernet. AR coated 1064 f50 can arrive any day now.

Quote:

One of the additional GigE cameras has been IP configured for use and installation. 

Static IP assigned to the camera- 192.168.113.152
Subnet mask- 255.255.255.0
Gateway- 192.168.113.2
 

 

Attachment 1: ETMXgige.jpg
ETMXgige.jpg
  13083   Tue Jun 27 16:18:59 2017 jigyasaUpdateCamerasGigE camera at ETMX

The 50mm lens has arrived. (Delivered yesterday).

Also the GigE has been wired and conencted to the Martian. Image acquisition is possible with Pylon.

Quote:

GigE can be connected to ethernet. AR coated 1064 f50 can arrive any day now.

 

  13089   Fri Jun 30 11:08:26 2017 jigyasaUpdateCamerasGigE camera at ETMX
With Steve's help in getting the right depth of field for imaging and focusing on the test mass with the new AR coated lens, Gautam's help with locking the arm and trying my hand at adjusting the focus of the camera yesterday, we were able to get some images of the IR beam, with the green shutter on and off at different exposures. Since the CCD is at an angle to the optic, the exposure time had to be increased signifcantly(and varied between 0.08 to 0.5 seconds) to capture bright images. 
A few frames without the IR on and with the green shutter closed were captured.
These show the OSEM and the Oplev on the test mass. 
 
Steve's note: AR coated camera lens M5018-SW installed at ~40 degrees
                    Atm2,  pcicture is taken through dirty window
 
Quote:

Also the GigE has been wired and conencted to the Martian. Image acquisition is possible with Pylon.

 

 

Attachment 1: PicturesETMX.pdf
PicturesETMX.pdf PicturesETMX.pdf PicturesETMX.pdf PicturesETMX.pdf
Attachment 2: dirtyETMXwindow.jpg
dirtyETMXwindow.jpg
  13091   Fri Jun 30 15:25:19 2017 jigyasaUpdateCamerasGigE camera at ETMX

All thanks to Steve, we cleaned the view port on the ETMX on which the camera is installed, and with a little fine tuning of the focus of the camera, here's a really good image of the beam spot at 6 and 14 ms.

Quote:
Steve's note: AR coated camera lens M5018-SW installed at ~40 degrees

 

Attachment 1: Image__2017-06-30__15-10-05.pdf
Image__2017-06-30__15-10-05.pdf
Attachment 2: 14ms.pdf
14ms.pdf
  13092   Fri Jun 30 16:03:54 2017 jigyasaUpdateCamerasGigE camera at ETMX

 

Quote:

All thanks to Steve, we cleaned the view port on the ETMX on which the camera is installed, and with a little fine tuning of the focus of the camera, here's a really good image of the beam spot at 6 and 14 ms.

Quote:
Steve's note: AR coated camera lens M5018-SW installed at ~40 degrees

 

 

Attachment 1: 14msexposure.png
14msexposure.png
  13098   Thu Jul 6 11:58:28 2017 jigyasaUpdateCamerasHDR images of ETMX

I captured a few images of the beam spot on ETMX at 5ms, 10ms, 14ms, 50ms, 100ms, 500ms, 1000ms exposure and ran them through my python script for HDR images. Here's what I obtained. 
The resulting image is an improvement over the highly saturated images at say, 500ms and 1 second exposures. 
Additionally, I also included a colormapped version of the image. 

Attachment 1: ETMXHDRcolormap.png
ETMXHDRcolormap.png
Attachment 2: ETMXHDRimage.png
ETMXHDRimage.png
  13100   Fri Jul 7 14:34:27 2017 ranaUpdateCamerasHDR images of ETMX

i wonder how 'HDR' these images really are. is there a quantitative way to check that we are really getting more bits? also, how many bits does the PNG format allow for monochrome images? i worry that these elog images are already lossy.

 

  13118   Sat Jul 15 01:28:53 2017 jigyasaUpdateCamerasBRDF Calibrations

This evening, Gautam helped me with setting up the apparatus for calibrating the GigE for BRDF measurements.
The SP table was chosen to set up the experiment and for this reason a few things including a laser and power meter (presumably set up by Steve) had to be moved around.

We initially started by setting up the Crysta laser with its power source (Crysta #2, 150-190 mW 1064 laser) on the SP table. The Ophir power meter was used to measure the laser power. We discovered that the laser was highly unstable as its output on the power meter fluctuated (kind of periodically) between 40 and 150 mW. The beam spot on the beam card also appeared to validate this change in intensity. So we decided to use another 1064 nm laser instead.
Gautam got the LightWave NPro laser from the PSL table and set it up on the SP table and with this laser the output as measured by the same power meter was quite stable.

We manually adjusted the power to around 150 mW. This was followed by setting up the half wave plate(HWP) with the polarizing beam splitter (PBS), which was very gently and precisely done by Gautam, while explaining how to handle the optics to me.
 On first installing the PBS, we found that the beam was already quite strongly polarized as there seemed to be zero transmission but a strong reflection.
With the HWP in place, we get a control over the transmitted intensity. The reflected beam is directed to a beam dump.
I have taken down the GigE(+mount) at ETMX and wired a spare PoE injector.
We tried to interface with the camera wirelessly through the wireless network extenders but that seems to render an unstable connection to the GigE so while a single shot works okay, a continuous shot on the GigE didn’t succeed.

The GigE was connected to the Martian via Ethernet cable and images were observed using a continuous shot on the Pylon Viewer App on Paola. 

We deliberated over the need of a beam expander, but it has been omitted presently. White printer paper is currently being used to model the Lambertian scatterer. So light scattered off the paper was observed at a distance of about 40 cm from the sample.
While proceeding with the calibrations further tonight, we realized a few challenges.

While the CCD is able to observe the beam spot perfectly well, measuring the actual power with the power meter seems to be tricky. As the scattered power is quite low, we can’t actually see any spot using a beam card and hence can’t really ensure if we are capturing the entire beam spot on the active region of the power meter (placed at a distance of ~40cm from the paper) or if we are losing out on some light, all the while ensuring that the power meter and the CCD are in the same plane.

We tried to think of some ways around that, the description of which will follow. Any ideas would be greatly appreciated.

Thanks a ton for all your patience and help Gautam! :) 

More to follow.. 

  13119   Sat Jul 15 13:40:59 2017 ranaUpdateCamerasBRDF Calibrations

Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

  13120   Sat Jul 15 16:19:00 2017 gautamUpdateCamerasMakeshift PyPylon

Some days ago, I stumbled upon this github page, by a grad student at KIT who developed this code as he was working with Basler GigE cameras. Since we are having trouble installing SnapPy, I figured I'd give this package a try. Installation was very easy, took me ~10mins, and while there isn't great documentation, basic use is very easy - for instance, I was able to adjust the exposure time, and capture an image, all from Pianosa. The attached is some kind of in-built function rendering of the captured image - it is a piece of paper with some scribbles on it near Jigyasa's BRDF measurement setup on the SP table, but it should be straightforward to export the images in any format we like. I believe the axes are pixel indices.

Of course this is only a temporary solution as I don't know if this package will be amenable to interfacing with EPICS servers etc, but seems like a useful tool to have while we figure out how to get SnapPy working. For instance, the HDR image capture routine can now be written entirely as a Python script, and executed via an MEDM button or something.

A rudimentary example file can be found at /opt/rtcds/caltech/c1/scripts/GigE/PyPylon/examples - some of the dictionary keywords to access various properties of the camera (e.g. Exposure time) are different, but these are easy enough to figure out.

 

Attachment 1: pyPylon_test.png
pyPylon_test.png
  13121   Sun Jul 16 11:58:36 2017 jigyasaUpdateCamerasBRDF Calibrations

 

From what I understood froom my reading, [Large-angle scattered light measurements for quantum-noise filter cavity design studies(Refer https://arxiv.org/abs/1204.2528)], we do the white paper test in order to calibrate for the radiometric response, i.e. the response of the CCD sensor to radiance.‘We convert the image counts measured by the CCD camera into a calibrated measure of scatter. To do this we measure the scattered light from a diffusing sample twice, once with the CCD camera and once with a calibrated power meter. We then compare their readings.’

But thinking about this further, if we assume that the BRDF remains unscaled and estimate the scattered power from the images, we get a calibration factor for the scattered power and the angle dependence of the scattered power!

Quote:

Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

 

  13122   Sun Jul 16 12:09:47 2017 jigyasaUpdateCamerasBRDF Calibrations

With this idea in mind, we can now actually take images of the illuminated paper at different scattering angles, assume BRDF is the constant value of (1/pi per steradian), 

then scattered power Ps= BRDF * Pi cosθ * Ω, where Pi is the incident power, Ω is the solid angle of the camera and θ is the scattering angle at which measurement is taken. This must also equal the sum of pixel counts divided by the exposure time multiplied by some calibration factor. 

From these two equations we can obtain the calibration factor of the CCD. And for further BRDF measurements, scale the pixel count/ exposure by this calibration factor.  

Quote:

 

From what I understood froom my reading, [Large-angle scattered light measurements for quantum-noise filter cavity design studies(Refer https://arxiv.org/abs/1204.2528)], we do the white paper test in order to calibrate for the radiometric response, i.e. the response of the CCD sensor to radiance.‘We convert the image counts measured by the CCD camera into a calibrated measure of scatter. To do this we measure the scattered light from a diffusing sample twice, once with the CCD camera and once with a calibrated power meter. We then compare their readings.’

But thinking about this further, if we assume that the BRDF remains unscaled and estimate the scattered power from the images, we get a calibration factor for the scattered power and the angle dependence of the scattered power!

Quote:

Power meter only needed to measure power going into the paper not out. We use the BRDF of paper to estimate the power going out given the power going in.

 

 

  13310   Mon Sep 11 23:31:50 2017 johannesUpdateCameraspost-vent camera capture comparison

The latest pre-unintended vent captures of the test mass face cameras were taken on June 2nd, 2017. Only exposures for ITMYF, ETMYF, and ETMXF exist in /users/sensoray/SensorayCaptures/. I took new captures for those three after locking the arms and having the dither-alignment on for 5+ minutes (exposures were taken after turning the dithering off). The capture script is choking on ITMXF, saying the channel can't lock on. Maybe that's why there's also no reference image for it. Capturing QUAD3, which shows ITMXF in the lower right corner, works, but we don't have a capture for reference. I also recorded dark fields after closing the PSL shutter. Naturally, these don't subtract out as well for the three-month old pictures, but it's actually not terrible and qualitatively one can still compare the subtracted images

Visually, ITMYF and ETMYF do not show a dramatic difference between then and now. ETMXF however, does. To get a numerical estimate for the difference in counts, I worked with the subtracted images and placed an aperture about 1.5x the size of the visible beam blob. I summed up the pixel values inside and subtracted the sum of the pixel values of an equally sized area from the upper left corner of the respective image, which looks free of subtraction artifacts and looks qualitatively similar to the background in the central region.

The pixel sum has gone up by about 50% between the exposures. I still have to do the same for the YARM optics but don't expect such a large discrepancy. Unfortunately we're missing those ITMYF expsures...

All pictures are organized in this format:

Pre-vent exposure Post-vent exposure
Pre-vent subtracted Post-vent subtracted

 

ITMYF

   

   

ETMYF

   

   

ETMXF

   

   

Attachment 11: ETMXF_pre_sub.bmp
  13334   Tue Sep 26 22:11:08 2017 johannesUpdateCameraspost-vent camera capture comparison

I configured the remaining GigE-Camera to work on the 40m network. We currently have 3 operational Basler cameras:

The 120gm's have been assigned the IPs 192.168.113.152  (was already configured) and 192.168.113.153 (freshly configured) and have been labeled accordingly. Note that it was not necessary to connect the out-of-the-box camera directly to a dedicated ethernet adapter whose IP was set manually to 169.254.0.XXX as pointed out in earlier posts - a few seconds after connecting the camera to the control room switch (with PoE adapter to power it) the camera showed up in the configuration software tool which is launched via

/opt/rtcds/caltech/c1/scripts/GigE/pylon5/bin/./IpConfigurator

and can be assigned a corrected, static IP.

We have a plethora of 2" tubes for the lens assembly, but not a great variety of focal lengths for 2" lenses. Present with the camera gear were two f=250 mm and one f=150 mm 2" lenses with a NIR broadband AR coating

To determine the lens positions relativ to the sensor I assumed that the camera we're setting up looks at its test mass from a distance of 1m. Using the two available focal lengths we can look for solutions which have reasonable lens separations <~10cm and suitable magnification. We primarily want to image the central mirror area onto a 1/4" sized sensor, which can be achieved with a magnification of ~1/8.

I chose a lens separation of 6cm, which gives a theoretical magnification of -.12 and a sensor-lens 2 distance of 7.95 cm. I placed the lenses accordingly in the tubes and checked the focusing with Gautam's help:

       

It's pretty close to what we would expect. We will do the calibration using the auxiliary laser on the PSL table. For this I temporarily routed a fiber from the PSL enclosure to the SP table. Since the main cable hole is sort of cramped it's going in through a gap near the ceiling instead.  

 

Attachment 1: lens_distance.pdf
lens_distance.pdf
  13348   Mon Oct 2 12:44:45 2017 johannesUpdateCamerasBasler 120gm calibration

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The two acA640-120gm Basler GigE-Cams have been calibrated. I used the collimated output of a fiber that carried the auxiliary laser light from the PSL table. With a non-polarizing beam splitter some of the light was picked off onto a PD, and I modified the RF amplitude of the AOM drive signal to vary the power coming out of the fiber. The fiber output was directed at a white paper, which was placed 1.06m from the front of the lens tube assembly, which is where the focal plane is. Using the Pylon Viewer App I made sure that the entirety of the beam spot was imaged onto the CCD. Since the camera sensor is 1/4" across, I removed the camera from the lens tube and instead placed the Ophir power meter head at the position of the sensor and measured the power reported versus PD voltage, which turned out to be 1.5 V/uW.

The camera was put back in place and I used the Pypylon package Gautam had stumbled upon to sweep the exposure time from 100us to 10ms at different light power settings including no laser light at all for background subtraction, and rather than keeping the full bitmap data for O(100s) of images I recorded only the quantities

  1. Pixel Max
  2. Pixel Sum
  3. Pixel Mean
  4. Pixel Standard Deviation
  5. Pixel Median

I performed this procedure for both the 152 and 153 cameras and plotted the pixel sum and the pixel max vs the exposure time. All the exposures were taken at a gain setting of 100, which is the smallest possible setting (out of 100-600). To obtain the calibration factor I use the input power Pin=75nW in the 'safe' region 1ms to 10ms where the pixel sum looks smooth and the CCD is reportedly not saturated.

Camera IP Calibration Factor CF
192.168.113.152 8.58 W*s
192.168.113.153 7.83 W*s

The incident power can be calculated as Pin =CF*Total(Counts-DarkCounts)/ExposureTime.

Attachment 1: calib_20170930_152.pdf
calib_20170930_152.pdf
Attachment 2: calib_20170930_153.pdf
calib_20170930_153.pdf
  13352   Mon Oct 2 23:16:05 2017 gautamHowToCamerasCCD calibration

Going through some astronomy CCD calibration resources ([1]-[3]), I gather that there are in general 3 distinct types of correction that are applied:

  1. Dark frames --- this would be what we get with a "zero duration" capture, some documents further subdivide this into various categories like thermal noise in the CCD / readout electronics, poissonian offsets on individual pixels etc.
  2. Bias frames --- this effect is attributed to the charge applied to the CCD array prior to the readout.
  3. Flat-field calibration --- this effect accounts for the non-uniform responsivity of individual pixels on the CCDs. 

The flat-field calibration seems to be the most complicated - the idea is to use a source of known radiance, and capture an image of this known radiance with the CCD. Then assuming we know the source radiance well enough, we can use some math to back out what the actual response function of individual pixels are. Then, for an actual image, we would divide by this response-map to get the actual image. There are a number of assumptions that go into this, such as: 

  • We know the source radiance perfectly (I guess we are assuming that the white paper is a Lambertian scatterer so we know its BRDF, and hence the radiance, perfectly, although the work that Jigyas and Amani did this summer suggest that white paper isn't really a Lambertian scatterer). 
  • There is only one wavelength incident on the CCD.
  • We can neglect the effects of dust on the telescope/CCD array itself, which would obviously modify the responsivity of the CCD, and is presumably not stationary. Best we can do is try and keep the setup as clean as possible during installation.

I am not sure what error is incurred by ignoring 2 and 3 in the list at the beginning of this elog, perhaps this won't affect our ability to estimate the scattered power from the test-masses to within a factor of 2. But it may be worth it to do these additional calibration steps. 

I also wonder what the uncertainty in the 1.5V/A number for the photodiode is (i.e. how much do we trust the Ophir power meter at low power levels?). The datasheet for the PDA100A says the transimpedance gain at 60dB gain is 1.5 MV/A (into high impedance load), and the Si responsivity at 1064nm is ~0.25A/W, so naively I would expect 0.375 V/uW which is ~factor of 4 lower. Is there a reason to trust one method over the other?  

Also, are the calibration factor units correct? Jigyasa reported something like 0.5nW s / ct in her report.

Camera IP Calibration Factor CF
192.168.113.152 8.58 W*s
192.168.113.153 7.83 W*s

The incident power can be calculated as Pin =CF*Total(Counts-DarkCounts)/ExposureTime.

References:

[1] http://www.astrophoto.net/calibration.php

[2] https://www.eso.org/~ohainaut/ccd/

[3] http://www.astro.ufl.edu/~lee/ast325/handouts/ccd.pdf

  13354   Tue Oct 3 01:58:32 2017 johannesHowToCamerasCCD calibration

Disclaimer: Wrong calibration factors! See https://nodus.ligo.caltech.edu:8081/40m/13391

The factors were indeed enormously off. The correct table reads:

Camera IP Calibration Factor CF
192.168.113.152 85.8 pW*s
192.168.113.153 78.3 pW*s

I did subtract a 'dark' frame from the images, though not in the sense of your point 1, just an exposure of identical duration with the laser turned off. This was mostly to reduce the effect of residual light, but given similar initial conditions would somewhat compensate for the offset that pre-existing charge and electronics noise put on the pixel values. The white field is of course a difference story.

I wonder how close we can get to a white field by putting a thin piece of paper in front of the camera without lenses and illuminate it from the other side. A problem is of course the coherence if we use a laser source... Or we scrap any sort of screen/paper and illuminate directly with a strongly divergent beam? Then there wouldn't be a specular pattern.

I'm not sure I understand your point about the 1.5V/A. Just to make sure we're talking about the same thing I made a crude drawing:

The PD sees plenty of light at all times, and the 1.5V/uW came from a comparative measurement PD<-->Ophir (which took the place of the CCD) while adjusting the power deflected with the AOM, so it doesn't have immediate connection to the conversion gain of silicon in this case. I can't remember the gain setting of the PD, but I believe it was 0dB, 20dB at most.

Attachment 1: gige_calibration.pdf
gige_calibration.pdf
  13375   Thu Oct 12 01:03:49 2017 johannesHowToCamerasETMX GigE side view

I calculated a better lens solution for the ETMX side view with the simple python script that's attached. The camera is still not as close to the viewport as we would like, and now the front lens is almost all the up to the end of the tube. With a little more playing around there maybe a better way, especially if we expand the repertoire of focal lengths. Using Steve's wonderful camera fixture I put the beam spot in focus. I turned the camera sideways for better use of the field of view, and now the beam spot actually fills the center area of the beam, to the point where we probably don't want more magnification or else we start losing the tails of the Gaussian.

We'll take a serious of images tomorrow, and will have an estimate of the scatter loss by the end of tomorrow.

 

Attachment 1: IMG_20171011_164549698.jpg
IMG_20171011_164549698.jpg
Attachment 2: Image__2017-10-11__16-52-01.png
Image__2017-10-11__16-52-01.png
Attachment 3: GigE_lens_position_helper.py.zip
  13377   Thu Oct 12 07:56:33 2017 SteveHowToCamerasETMX GigE side view at 50 deg of IR scattering

 Telescope front lens to wall distance 25 cm,  GigE camera lenght 6 cm and cat6 cable 2cm

 Atm3,   Existing short camera  can has 16cm  lenght to lexan guard on viewport. Available 2" od periscope tube lenght is 8cm. The one in use 16 cm long.

             Note: we can fabricate a lite cover with tube that would accomodate longer telescope.

             Can we calibrate the AR coated M5018-SW and compare it's performance agains the 2" periscope

             Look at the Edmond Optics 3" od camera lens with AR

This lower priced   1" apeture Navitar lens  can be an option too.

 

 Atm1,   Now I can see dust. This is much better. The focus is not right yet.

Atm2,   Chamber viewport wiped and image refocused. Actually I was focusing on the dust.

Quote:

I calculated a better lens solution for the ETMX side view with the simple python script that's attached. The camera is still not as close to the viewport as we would like, and now the front lens is almost all the up to the end of the tube. With a little more playing around there maybe a better way, especially if we expand the repertoire of focal lengths. Using Steve's wonderful camera fixture I put the beam spot in focus. I turned the camera sideways for better use of the field of view, and now the beam spot actually fills the center area of the beam, to the point where we probably don't want more magnification or else we start losing the tails of the Gaussian.

We'll take a serious of images tomorrow, and will have an estimate of the scatter loss by the end of tomorrow.

 

 

Attachment 1: Image__2017-10-11__15-29-52_15k400g.png
Image__2017-10-11__15-29-52_15k400g.png
Attachment 2: Image__2017-10-12__15-50-18wipedRefocud2.png
Image__2017-10-12__15-50-18wipedRefocud2.png
Attachment 3: camCan16cm.jpg
camCan16cm.jpg
  13389   Wed Oct 18 11:37:58 2017 johannesHowToCamerasETMX GigE side view at 50 deg
uote:

 Telescope front lens to wall distance 25 cm,  GigE camera lenght 6 cm and cat6 cable 2cm

 Atm3,   Existing short camera  can has 16cm  lenght to lexan guard on viewport. Available 2" od periscope tube lenght is 8cm. The one in use 16 cm long.

             Note: we can fabricate a lite cover with tube that would accomodate longer telescope.

             Can we calibrate the AR coated M5018-SW and compare it's performance agains the 2" periscope

             Look at the Edmond Optics 3" od camera lens with AR

Atm1,   Now I can see dust. This is much better. The focus is not right yet.

Atm2,   Chamber viewport wiped and image refocused. Actually I was focusing on the dust.

We don't really have to calibrate the lens, just the CCD, which we've done. It's more about knowing the true aperture size to know how much solid angle you're capturing to infer the total amount of scatter. For our custom lens tubes this is the ID of the retaining ring.

The Edmund Optics lens tube looks tempting, but itcomes at a price. Thorlabs sells lens tubes that offer a more flexibility than what we have right now, so I bought a few different ones, and also more 150mm 2" lenses. This will allow for more compact solutions and offer some in-situ focusing ability that doesn't require detaching the lens tube like now. Should be here in a couple of days, then we'll be able to enclose the GigE camera in the viewport can with a similar field of view we have now.

I also bought a collimation package for the AS port fiber stuff so we can move ahead with the ringdown measurements and also mode spectroscopy.

  13391   Wed Oct 18 15:26:58 2017 johannesHowToCamerasRevision: CCD calibration

The units were still off in my previous post. Here's the corrected, sanity-checked version:

Camera IP Calibration Factor
192.168.113.152 85.8 +/- 4.3 pW*μs
192.168.113.153 78.3 +/- 3.9 pW*μs

I estimated the uncertainties based on a linear fit to the data I recorded with 75nW incident on the CCD and assumed a 5% uncertainty in that number. This is just an upper limit, to be safe. I had calibrated the power reading placing the Ophir power meter where the CCD would otherwise be and comparing it to the PD voltage of a picked off beam. In my previous figures the axes were mislabeled, so I reproduce them here:

Using the current camera position I recorded 50 exposures both with and without beam (XARM locked vs PSL shutter closed) and averaged the images to see how much the reading fluctuates. The exposure time was 10 ms, which left the maximum reported pixel value in all exposures below 3800 out of 4096. The gain setting was 100, which is what I used to calibrate the CCDs.

Counts with XARM locked 2.799 +/- 0.027 x107
Counts with shutter closed 3.220 +/- 0.047 x106
Power on CCD 193.9 +/- 2.2 nW
Power scattered into 2π (*) 254 +/- 39 μW
ETMX scatter loss (**) 25.4 +/- 3.9 ppm

(*) I calculated the lens positions to focus at a plane 65cm from the front lens. We're pretty close to that, but I can't confirm the actual distance easily, so I assumed a 5cm error on the distance, which is where most of the error is coming from. This is also assuming uniform scatter.

(**) This is assuming 10W of circulating power

Attachment 1: calib_20170930_152.pdf
calib_20170930_152.pdf
Attachment 2: calib_20170930_153.pdf
calib_20170930_153.pdf
  13868   Fri May 18 20:03:14 2018 PoojaUpdateCamerasTelescopic lens solution for GigE

Aim: To find telescopic lens solution to image test mass onto the sensor of GigE camera.

I wrote a python code to find an appropriate combination of lenses to focus the optic onto the camera keeping in mind practical constraints like distance of GigE camera from the optic ~ 1m and distance between the lenses need to be in accordance with the Thorlab lens tubes available. We have to image both the enire optic of size 3" and beam spot of 1" using this combination of lens. The image size that efficiently utilizes the entire sensor array is 1/4". Therefore the magnification required for imaging the entire optic is 1/12 and that for the beam spot is 1/4.

I checked the website of Thorlabs to get the available focal lengths of 2" lenses (instead of 1" lenses to collect sufficient power). I have tried several combination of lenses and the ones I found close enough to what is required have been listed below along with thier colorbar plots.

a) 150mm-150mm (Attachment 2 & 3)

With this combination, object distance varies like 50cm for 1" beam spot to 105cm for 3" spot. Therefore, it posses a difficulty that there is a difference of ~48cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

b) 125mm-150mm (Attachment 4 & 5)

With this combination, object distance varies like 45cm for 1" beam spot to 95cm for 3" spot. There is a difference of ~43cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

c) 125mm-125mm (Attachment 6 & 7)

The object distance varies like 45cm for 1" beam spot to 90cm for 3" spot. There is a difference of ~39cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

Sensitivity check was also done for these combination of lenses. An error of 1cm in object distance and 5mm in the distance between the lenses gives an error in magnification <2%.

The schematic of the telescopic lens system has been given in Attachment 8.

 

Attachment 1: calib_20170930_152.pdf
Attachment 2: plot_2018-05-18_tel-lens_150_150_1.pdf
plot_2018-05-18_tel-lens_150_150_1.pdf
Attachment 3: plot_2018-05-18_tel-lens_150_150_3.pdf
plot_2018-05-18_tel-lens_150_150_3.pdf
Attachment 4: plot_2018-05-18_tel-lens_125_150_1.pdf
plot_2018-05-18_tel-lens_125_150_1.pdf
Attachment 5: plot_2018-05-18_tel-lens_125_150_3.pdf
plot_2018-05-18_tel-lens_125_150_3.pdf
Attachment 6: plot_2018-05-18_tel-lens_125_125_1.pdf
plot_2018-05-18_tel-lens_125_125_1.pdf
Attachment 7: plot_2018-05-18_tel-lens_125_125_3.pdf
plot_2018-05-18_tel-lens_125_125_3.pdf
Attachment 8: tel_design.pdf
tel_design.pdf
ELOG V3.1.3-