40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 239 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  7463   Tue Oct 2 15:14:54 2012 jenne, jamieUpdateIOOPZT diagnosis

pzt2 mod signals matched slider vals for both pitch and yaw

  pzt2 yaw mon output = 6
  pzt2 pitch mon output = 11.3

From the PZT connector-converter board we determined the following pin-outs:

  X=Yaw:  red=1, white=14, black=3 
  Y=Pitch:  red=2, white=15, black=16

We believe that red is signal, white/black/shield are all ground.  We also believe (although this is from the PMC PZT) that the expected capacitance of the PZTs should be in the 100's of nF range.

Here are the readings from the two PZT dsub connectors:

  pin 1:14   PZT1 = ".003" on 2uF scale
             PZT2 = ".184"
   
  pin 2:15   PZT1 = ".002" on 2uF scale
             PZT2 = ".202"

So we think this means (given this crappy capacitance meter) that PZT2 is showing roughly 200nF, which sounds ok, but that PZT1 is indeed bad.

So next we investigate the PZT2 driver.

 
  7673   Tue Nov 6 16:38:37 2012 jenne, jamie, ayaka, manasaUpdateAlignmentAlignment back under control again

We had a big alignment party early this morning, and things are back to looking good.  We have been very careful not to bump or touch tables any more than necessary.  Also, we have removed the apertures from the BS and PRM, so there are no more apertures currently left in the chambers (this is good, since we won't forget).

We started over again from the PZTs, using the PRM aperture and the freestanding aperture in front of PR2, to get the height of the beam correct.  We then moved PZTs to get the beam centered on BS, ITMY, ETMY.  We had to do a little poking of PR2 (and PR3?) to get pitch correct everywhere.

We then went to ETMX to check beam pointing, and used BS to steer the beam to the center of ETMX.  We checked that the beam was centered on ITMX.

We went through and ensured that ITMX, ITMY, PRM, SRM are all retroreflecting.  We see nice MICH fringes, and we see some fringes (although still not so nice...) when we bring PRM and SRM into alignment.

We checked the AS path (with only MICH aligned), and made sure we are centered on all of the mirrors.  This included steering a little bit on the mirrors on the OMC table, in yaw.  Initially, AS was coming out of the vacuum, but hitting the side of the black beam tube.  Now it gets nicely to the table.

For both AS and REFL, we made sure there is no clipping in the OMC chamber.

I recentered the beams for AS and REFL on their respective cameras.

IPPOS was centered on the QPD.  This involved moving the first out-of-vac steering mirror sideways a small amount, since the beam was hitting the edge of the mirror.  IPANG was aligned in-vac, and has been centered on the QPD.

Right now, Manasa, Jamie and Ayaka are doing some finishing touches work, checking that POY isn't clipping on OM2, the second steering mirror after the SRM, and they'll confirm that POX comes out of the chamber nicely, and that POP is also still coming out (by putting the green laser pointer back on that table, and making sure the green beam is co-aligned with the beam from PR2-PR3.  Also on the list is checking the vertex oplevs.  Steve and Manasa did some stuff with the ETM oplevs yesterday, but haven't had a chance to write about it yet.

  3916   Sun Nov 14 16:26:31 2010 jenne, valeraUpdateElectronicsSRM side OSEM noise with no magnet

We realized that the SRM sensors are connected to the readout but just sitting on the BS in vacuum table with no magnets and therefore no shadows in them. We swapped the inputs to the SRM and PRM satellite boxes to use the higher transimpedance gain of the PRM side sensor. The attached plot shows the current spectrum in this configuration. The PD readback voltage was 9.5 V. Since this is close to the rail we put a slightly higher voltage into the AA of this channel to test that we can read out more ADC counts to make sure we are not saturating. The margin was 15800 vs 15400 counts with p-p of 5 counts on the dataviewer 1 second trend. We returned all cables to nominal configuration.

The calibration from A to m is 59 uA/1 mm.

Attachment 1: SRM-SD-Current-NoMagnet.pdf
SRM-SD-Current-NoMagnet.pdf
  12998   Thu May 18 15:20:29 2017 jigyasaSummarytelescope designTelescope Design for the Gig-E cameras

With the objective of designing a telescope system for the Gig-E, a system of two lenses is implemented. A rough schematic of the telescope system is attached. Variables in the system include the focal lengths of the two spherical lenses(f1, f2), distance between the lenses(t), distance between the test mass and the lens combination(u), distance between the other lens and the sensor(v). Also the size of the object to be desired ranges from 3’’ which is the size of the test mass to 1’’ which is approximately focusing on the beam spot implying that the required magnification ranges from 0.06089 to 0.1826 (since the sensor image circle size if ¼”)
The lenses are selected to be 2” in diameter so as to ensure sufficient collected power.

Going through the focal lengths available, namely 50, 100, 150, 200, 250 mm, and noting that the object distance would be within the ranges of 1500 to 2500 mm, plots of various accessible u and v for different values of t were obtained. This optimization was done to ensure the proper selection of the lenses. Additionally, a sensitivity analysis was performed and plots depicting the dependence of magnification on the precision limiting measurements of u (1 mm) and t (5 mm) were obtained. (These were scatter plots quantifying the deviation from the desired magnification ranges). The plots depict the error term induced on the magnification if there was an error in measuring the distance between the lenses as 5mm and if the precision in measuring the object to lens distance by 1mm.

The telescope design might be limited by spherical aberrations and coma, which might be resolved by either using aspherical lenses or by increasing the f-number (typically with an f number around 5 or 6). The use of aspherical lenses particularly parabolic lenses was considered, however this was found to be quite an expensive route. 

Analyzing the plots and taking into consideration the restrictions of the slotted lens tubes, the precision in measurement of the distances, a 150 mm- 250mm focal length solution is proposed. With a diameter of 2”, the f number is computed to be 2.95 and 4.92. With this combination and the object distances lying between 1500 to 2500 mm, the image distance to the sensor varies between 51 to 100mm. So a slotted lens tube controlling the distance between the lenses would be required.

I also considered a combination of focal lengths 250mm and 250mm, as then both of the lenses would at least have an f number of 4.92. The results for this combination are also attached. The image distance from the lens combination is about a 100 to a 140 mm. However, this would require much longer slotted length tubes thereby adding to the cost of the system. The number of accessible u-v points is the same as that for the 150-250 combination. 

I am still trying to search for a much more concrete way of quantifying aberrations.

Attachment 1: ray.png
ray.png
Attachment 2: Schematic.png
Schematic.png
Attachment 3: 150-250uv.png
150-250uv.png
Attachment 4: 150-250error.png
150-250error.png
Attachment 5: 250-250.png
250-250.png
Attachment 6: 250-250error.png
250-250error.png
  13000   Mon May 22 10:15:14 2017 jigyasaSummarytelescope designLens tubes and object distances

Since the f numbers of the lenses in the proposed design with biconvex lenses are a little less than 5 and the conjugate ratio(that is the ratio of object to image distance) is greater than 5, I explored the use of plano convex lenses, but with the same focal lengths, the accessible u-v range is restricted with the planoconvex rather than biconvex lenses.
On Friday, I had a discussion with Gautam and Steve about the hardware that is the cylindrical enclosures for the camera and the telescope and we examined two such aluminum cylindrical enclosures. One of them was the one being currently employed for the cameras. The dimensions were measured and the length was found to be 8’’ and an outer diameter of 26 cm within an error of 0.5 cm.
The other enclosure was longer with a length of 52 cm(±0.5 cm), outer diameter of 10”(±0.1”) and an inner diameter of 23.7cm(±0.1cm). Pictures of these enclosures are attached.
Both of these enclosures have internal optical rail to mount the camera and the telescope system. Depending on the weight of the telescope system(that includes the weight of the slotted lens tubes, the lenses), it might be more efficient to clamp the telescope system itself on the rails with the low weight camera mounted on the lens tube.
I also went around to get an idea of distance of the GigE from the test masses. This was just a step to verify if the object distances were really in the ranges being taken into consideration, that is between 1500 and 2500 mm. I also tried to cross check the measurements with the CAD drawing of the 40m. However, as I have been informed, the distances in the CAD version are not updated.

The distances from the optic to the CCD detector would range from around 75.1 cm for MC2, 94.01 cm for ITMX, 97.21 cm for ETMX, 117.19 cm for ITMY and 88.463 cm for ETMY. The illuminator for the ETMY was disconnected, so Gautam helped me access the manual lamp control to enable me to take measurements.
The values for ETMX, MC2 and ITMY are subject to an error of ±1’’. Due to a lot of obstructions, the values for ETMY and ITMX may be subject to a lot more error. Even so, these distances are clearly less than 2 meters, prompting me to run the simulations again and verify that the chosen combination is still useful.

As for the slotted lens tubes to mount the 2” lenses, the following options are available on the Thorlabs catalog. CVI and Edmunds do not seem to offer much of the stackable lens tubes.

SM2L30C is a lens tube onto which the optic can be mounted without the need of a spanner wrench. It also has a length of 3”. However, it has a rotatable slip shield which can be rotated open as and when the access to optic is required. However, there might be a slight compromise with rigidity here.

SM2L30 is a lens tube with internal thread depth of 3”, the optic can be mounted using spanner wrench and a retainer ring. The optic cannot be accessed from both ends of the tube here.
SM2M30 is a lens tube with no external threads, therefore lens tube couplers would be required to stack the tubes. The optic is accessible from both ends here though.

Considering the merits and demerits of all these available options, the use of SM2L30 might be considered as it provides a quick and efficient way of stacking multiple lens tubes. As for accessing the optic from both sides, using multiple tubes helps overcome the problem and still ensures that we are able to access a number of separation distances as per requirement.
Thorlabs also offers an internal C to external SM2 adapter so that the lens tube could be fixed onto the C mount of the camera. 

I would be examining the use of 1" diameter lenses for the eyepiece as suggested by Rana, as that might give us more flexibility. 

Attachment 1: Pictures1.pdf
Pictures1.pdf Pictures1.pdf Pictures1.pdf Pictures1.pdf
  13004   Mon May 22 15:01:41 2017 jigyasaUpdatetelescope designUpdated Telescope design with 1'' eye piece

I examined the use of a single lens system for the available range of focal lengths, for the required magnification and found that a focal length of at most 100 mm would be required to sufficiently cover the object distance range. This would greatly compromise with the f-number and hence lead to a lot more spherical aberrations.

Therefore, a two lens system would be more useful to implement. Using an eyepiece of 1” puts an additional constraint on the system such that the separation between the lenses must now at least equal or be greater than half the image distance from the first lens to ensure that no light from the light cone is lost. This is clarified in the schematic. The image from the first lens in absence of the second lens would form at point A, subtending an angle θ. In order to ensure that no part this light cone emerging from the first lens is lost, the second lens must be placed at a distance atleast v/2 from the first lens.

A combination of 125mm focal length 2” diameter objective with a 250 mm 1” eyepiece covers the required range of object distances (650mm to 1500 mm). Increasing the focal length of the eye piece increases the minimum object distance accessible to 700 mm. 

A glance at the accessible u, v points shows that all magnifications are not possible at a given object distance. To image the entire surface of the test mass, a distance of at least 1.25m is required from the objective, while a beam spot of 1'' diameter can be imaged easily at upto 1200 mm from the objective . This holds true even for the 150-250 mm biconvex 2" lens combination proposed earlier. 

If this sounds reasonable, we could proceed with ordering the lenses.

Attachment 1: 1incep.pdf
1incep.pdf
  13013   Thu May 25 16:42:41 2017 jigyasaUpdateComputer Scripts / ProgramsMaking pylon installation on shared directory

I have been working on interfacing with the GigE’s. I went through Joe Be’s paper and the previous elogs and verified that the code files are installed.

I then downloaded and extracted a copy of the Pylon software onto my home directory on Allegra. Gautam helped me find installation instructions on Johannes’ directory so that I could make the installation on the shared directory.

So far , according to instructions, these commands need to be executed so that the installation takes place and the rules for camera permissions are set up.

sudo tar –C /opt/rtcds/caltech/c1/scripts/GigE –xzf pylon SDK*.tar.gz

followed by ./setup-usb.sh

The Pylon viewer can then be accessed with /scripts/GigE/pylon5/bin/PylonViewerApp 

Should I go ahead with the installation in the shared directory?

  13014   Thu May 25 18:37:11 2017 jigyasaUpdateComputer Scripts / ProgramsMaking pylon installation on shared directory

Gautam helped me execute the commands mentioned above and Pylon has now been installed on the shared directory. We extracted the pylon installation from Johannes's directory to the shared drive and executing the command tar –C /opt/rtcds/caltech/c1/scripts/GigE –xzf pylon SDK*.tar.gz created an unzipped pylon5 folder in /scripts. The ./setup-usb.sh set up the udev rules for the GigE.

The installation took place without any errors.

The Pylon viewer app can now be accessed at /opt/rtcds/caltech/c1/scripts/GigE/pylon5/bin followed by ./PylonViewerApp 

Quote:

Should I go ahead with the installation in the shared directory?

 

  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
  13023   Wed May 31 14:23:42 2017 jigyasaUpdateComputer Scripts / ProgramsEstablishing the EPICs channels for the GigE

To set up the EPICs channels for the GigE, Gautam and I followed the steps in the elog by him  8957 .

We copied the 11 required channels from scripts/GigE/SnapPy/example_camera.db to c1cam.db that we created, however due to conflicts with the existing CAM-AS_PORT channels, the channels could not be accessed.

We later changed the database file to Video.db and on restarting the slow machine, it was verified that the channels indeed could be written to and read from.

11 channels were added

C1: CAM-MC1_X (X centroid position)
C1: CAM-MC1_Y (Y centroid position)
C1: CAM-MC1_WX (Gaussian width in the X direction)
C1: CAM-MC1_WY (Gaussian width in the Y direction)
C1: CAM-MC1_XY (Gaussian width along XY line)
C1: CAM-MC1_SUM (Pixel sum)
C1: CAM-MC1_EXP (Exposure time in microseconds)
C1: CAM-MC1_SNAP (Control signal for taking snapshots)
C1: CAM-MC1_FILE(File name for image to saved to - time stamp automatically appended)
C1: CAM-MC1_RELOAD (Reloads configuration file)
C1: CAM-MC1_AUTO (1 means autoexposure on, 0 means autoexposure off)

The procedure followed –

  • Add the channel names to the file C0EDCU.ini (path = /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini).
  • Make a database (.db) file so that these channels are actually recorded (path = /cvs/cds/caltech/target/c1aux/Video.db).
  • Restarted the slow machine. FB
  • Verify that the channels indeed exist and can be read and written to using ezcaread and ezcawrite.

GV: Initially, I made a new directory called c1cam in /cvs/cds/caltech/target/ and made a .db file in there. However, the channels were not accessible after re-starting FB (attempting to read these channels threw up the "Channel does not exist" error). On digging a little further, I saw that there were already some "C1:CAM-AS_PORT" channels in C0EDCU.ini. The corresponding database records were defined inside /cvs/cds/caltech/target/c1aux/Video.db. So I just added the new records there. I also had to uncomment out the dummy channel in C0EDCU.ini to keep an even number of channels. Restarting FB still did not allow read/write access to the channels. Looking through the files in /cvs/cds/caltech/target/c1aux, I suspected that the epics database records are loaded when the machine is first booted up - so on a hunch I re-started c1aux by keying the crate, and this did the trick. The channels can now be read / written to (tested using Python cdsutils).

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

 

  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. 

 

 

  13056   Fri Jun 9 16:37:29 2017 jigyasaUpdateComputer Scripts / ProgramsOpenCV installation

OpenCV 3.1.0 has been installed by following the commands locally on Donatella

git clone https://github.com/Itseez/opencv.git
cd opencv
git checkout 3.1.0
git clone https://github.com/Itseez/opencv_contrib.git
cd opencv_contrib
git checkout 3.0.0
cd ~/opencv
mkdir release
cd release
cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D OPENCV_EXTRA_MODULES_PATH=/~/opencv_contrib/modules/ ~/opencv/

In ~/opencv/release, make and sudo make install were executed.

This completed the installation. The version of the installation was verified pkg-config --modversion opencv which showed 3.1.0. Also verified the import of cv2 module in python and it seems to work fine. 

 

  13066   Thu Jun 15 18:56:31 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight.

The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa

Apologies for any inconvenience.
Data analysis will follow.

  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
 

  13072   Mon Jun 19 18:32:18 2017 jigyasaUpdateComputer Scripts / ProgramsSoftware Installation for image analysis

The IRAF software from the National Optical Astronomy Observatory has been installed locally on Donatella(for testing) following the instructions listed here at http://www.astronomy.ohio-state.edu/~khan/iraf/iraf_step_by_step_installation_64bit
This is a step towards "aperture photometry" and would help identify point scatterers in the images of the test masses.

I will be testing this software, in particular, the use of DAOPHOT and if it seems to work out, we may install it on the shared directory.
Hope this isn't an inconvenience.

 

 

  13073   Mon Jun 19 18:41:12 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The previous run of the script had produced some dubious results!

The script has been modified and now scans the transmission sum for a longer duration to provide a better estimate on the average transmission. The pitch and yaw offsets have been set to the values that were randomly generated in the previous run as this would enable comparison with the current data.

I am starting it on Donatella and it should run for a couple of hours.

Apologies for the inconvenience.

Quote:

A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight.

The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa

  13076   Tue Jun 20 17:44:12 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The script didn't run properly last night, due to an oversight of variable names! It's been started again and has been running for half an hour now.

Quote:

I am starting it on Donatella and it should run for a couple of hours.

Apologies for the inconvenience.

Quote:

A python script to randomly vary the MC2 pitch and yaw offset and correspondingly record the value of MC transmission has been started on Donatella in the control room and should run for a couple of hours overnight.

The script is named MC_TRANS_1.py and is located in my user directory at /users/jigyasa

 

  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.

 

  13084   Tue Jun 27 18:47:49 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The values generated from the script were analyzed and a 3D scatter plot in addition to a 2D map were plotted. 

Yesterday, Rana pointed me to another method of collecting and analyzing the data. So I worked on the code today and have left a script (MC2rerun.py) running on Ottavia which should run overnight.

Quote:

The script didn't run properly last night, due to an oversight of variable names! It's been started again and has been running for half an hour now.

 

 

  13087   Thu Jun 29 10:04:18 2017 jigyasaUpdateComputer Scripts / ProgramsMC2 Pitch-Yaw offset

The script is being executed again, now.

Quote:

I worked on the code today and have left a script (MC2rerun.py) running on Ottavia which should run overnight.

 

 

  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
  13105   Mon Jul 10 17:13:21 2017 jigyasaUpdateComputer Scripts / ProgramsCapture image without pylon GUI

Over the day, I have been working on a C++ program to interface with Pylon to capture images and reduce dependence on the Pylon GUI. The program uses the Pylon header files along with opencv headers. While ultimately a wrapper in python may be developed for the program, the current C++ program at, 

/users/jigyasa/GigEcode/Grab/Grab.cpp when compiled as

g++ -Wl,--enable-new-dtags -Wl,-rpath,/opt/pylon5/lib64 -o Grab Grab.o -L/opt/pylon5/lib64 -Wl,-E -lpylonbase -lpylonutility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 `pkg-config opencv --cflags --libs`

returns an executable file named Grab which can be executed as ./Grab

This captures one image from the camera and displays it, additionally it also displays the gray value of the first pixel.

I am working on adding more utility to the program such as manually adjusting exposure, gain and also on the python wrapper (Cython has been installed locally on Ottavia for the purpose)!

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

  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.

 

 

  4394   Thu Mar 10 01:28:47 2011 joe, jamie, rana, chrisSummaryCDSSimSuspension !

Today was a banner day for Simulated Plants.

Joe and Jamie have been working to get it all happening and this afternoon we started stuffing filters into the plant to make it act like the:

40mETMY.png

We put in the following features so far:

  1. Anti-Imaging filters (these are hacked to be approximate since the real ones are 7570 Hz LP filters and the SimAI only can have filters up to 8192 Hz).
  2. Dewhitening filters (copied from the SimDW in the SUS-ETMY screens)
  3. Coil Driver transimpedance (1 / 200 Ohms)
  4. Magnet-coil force constant (0.016 N/A)
  5. Conversion from Coil to DOF Basis
  6. All DOFs of the mechanical model are represented as simple harmonic oscillators with Q~100 and f ~ measured free swinging peaks.
  7. Signals/Noise can be injected either as force noise on the test mass or as displacement noise at the suspension point.
  8. Conversion from DOF to Shadow Sensor basis.
  9. Optical Levers (with whitening)
  10. Shadow Sensors have 2V/mm readout gain and whitening filters before being digitized by the SimADC.

We have also changed the switching logic for the SUS and SimETMs for the shadow sensor whitening. It used to be that either the hardware OR the software whitening was on. Now we have made it like all of the other whitening/antiwhitening in LIGO and the whitening/antiwhitening come on together. Joe and Jamie are going to propagate this to the other SUS. The hardware filter is a 30,100:3 (poles:zeros) whitening filter. The digital filter used to also be 30,100:3 with a DC gain = 1. I've changed the FM1 filter in the XXSEN filter banks into a 3:30 for the ETMY so that it now comes on and just compensates the hardware filter. This change should be propagated to all other SUS and the MEDM screens updated to show the new situation.

After this change, we decided to calibrate the {UL,UR,LL,LR,SD}SEN channels into units of microns. To do this we have made an FM6 filter called 'cts2um' that accounts for the OSEM gain and the ADC conversion factors. These channels are now in units of microns without applying any calibration in the DTT or Dataviewer. The plot below shows the OSEM shadow sensor time series with all damping loops ON and a very rough version of seismic noise being injected in all 6 DOFs (note that the y-axis is microns and the x-axis is seconds).

dvsim.png

Next, Jamie is adding the angular calibrations (so that SUSPIT and SUSYAW are in rads) and Chris is making vectift quality seismic noise injectors.

We also need to add coating thermal noise, suspension thermal noise, substrate thermal noise, ADC/DAC noise and a lot of MEDM screen indicators of what state we're in. I myself can't tell from the OSEM time series if its real or Sim.

redpill_bluepill.jpg

  2624   Mon Feb 22 11:38:05 2010 joe, jenne and steveConfigurationVACvacuum is back to normal

Morning condition: vacuum rack power is still off, no MEDM screen reading.....meaning unknown vacuum pressure.We closed PSL shutter immediately.

Joe restored c1iscepis and Jenne powered up the vac-rack UPS. Now the rest of the vac-rack power were restored from starting at the top to bottom.

P1 was reading 15 mTorr.  We restarted pumps and  set vacuum valve positions. V1 opening required Rob's recipe of elog # 1863 to defeat interlock that

has a non communicating gauge: PTP1

CC1 pressure just reached 1e-6 Torr at VAC NORMAL configuration.

  12849   Thu Feb 23 15:48:43 2017 johannesUpdateComputersc1psl un-bootable

Using the PDA520 detector on the AS port I tried to get some better estimates for the round-trip loss in both arms. While setting up the measurement I noticed some strange output on the scope I'm using to measure the amount of reflected light.

The interferometer was aligned using the dither scripts for both arms. Then, ITMY was majorly misaligned in pitch AND yaw such that the PD reading did not change anymore. Thus, only light reflected from the XARM was incident of the AS PD. The scope was showing strange oscillations (Channel 2 is the AS PD signal):

For the measurement we compare the DC level of the reflection with the ETM aligned (and the arm locked) vs a misaligned ETM (only ITM reflection). This ringing could be observed in both states, and was qualitatively reproducible with the other arm. It did not show up in the MC or ARM transmission. I found that changing the pitch of the 'active' ITM (=of the arm under investigation) either way by just a couple of ticks made it go away and settle roughly at the lower bound of the oscillation:

In this configuration the PD output follows the mode cleaner transmission (Channel 3 in the screen caps) quite well, but we can't take the differential measurement like this, because it is impossible to align and lock the arm but them misalign the ITM. Moving the respective other ITM for potential secondary beams did not seem to have an obvious effect, although I do suspect a ghost/secondary beam to be the culprit for this. I moved the PDA520 on the optical table but didn't see a change in the ringing amplitude. I do need to check the PD reflection though.

Obviously it will be hard to determine the arm loss this way, but for now I used the averaging function of the scope to get rid of the ringing. What this gave me was:
(16 +/- 9) ppm losses in the x-arm and (-18+/-8) ppm losses in the y-arm

The negative loss obviously makes little sense, and even the x-arm number seems a little too low to be true. I strongly suspect the ringing is responsible and wanted to investigate this further today, but a problem with c1psl came up that shut down all work on this until it is fixed:

I found the PMC unlocked this morning and c1psl (amongst other slow machines) was unresponsive, so I power-cycled them. All except c1psl came back to normal operation. The PMC transmission, as recorded by c1psl,  shows that it has been down for several days:

Repeated attempts to reset and/or power-cycle it by Gautam and myself could not bring it back. The fail indicator LED of a single daughter card (the DOUT XVME-212) turns off after reboot, all others stay lit. The sysfail LED on the crate is also on, but according to elog 10015 this is 'normal'. I'm following up that post's elog tree to monitor the startup of c1psl through its system console via a serial connection to find out what is wrong.

  12851   Thu Feb 23 19:44:48 2017 johannesUpdateComputersc1psl un-bootable

Yes, that was one of the things that I wanted to look into. One thing Gautam and I did that I didn't mention was to reconnect the SRM satellite box and move the optic around a bit, which didn't change anything. Once the c1psl problem is fixed we'll resume with that.

Quote:

The fringes seen on the oscope are mostly likely due to the interference from multiple light beams. If there are laser beams hitting mirrors which are moving, the resultant interference signal could be modulated at several Hertz, if, for example, one of the mirrors had its local damping disabled.

 

Speaking of which:

Using one of the grey RJ45 to D-Sub cables with an RS232 to USB adapter I was able to capture the startup log of c1psl (using the usb camera windows laptop). I also logged the startup of the "healthy" c1aux, both are attached. c1psl stalls at a point were c1aux starts testing for present vme modules and doesn't continue, however is not strictly hung up, as it still registers to the logger when external login attempts via telnet occur. The telnet client simply reports that the "shell is locked" and exits. It is possible that one of the daughter cards causes this. This seems to happen after iocInit is called by the startup script at /cvs/cds/caltech/target/c1psl/startup.cmd, as it never gets to the next item "coreRelease()". Gautam and I were trying to find out what happends inside iocInit, but it's not clear to us at this point from where it is even called. iocInit.c and compiled binaries exist in several places on the shared drive. However, all belong to R3.14.x epics releases, while the logfile states that the R3.12.2 epics core is used when iocInit is called.

Next we'll interrupt the autoboot procedure and try to work with the machine directly.

Attachment 1: slow_startup_logs.tar.gz
  12852   Fri Feb 24 20:38:01 2017 johannesUpdateComputersc1psl boot-stall culprit identified

[Gautam, Johannes]

c1psl finally booted up again, PMC and IMC are locked.

Trying to identify the hickup from the source code was fruitless. However, since the PMCTRANSPD channel acqusition failure occured long before the actual slow machine crashed, and since the hickup in the boot seemed to indicate a problem with daughter module identification, we started removing the DIO and DAQ modules:

  1. Started with the ones whose fail LED stayed lit during the boot process: the DIN (XVME-212) and the three DACs (VMIVME4113). No change.
  2. Also removed the DOUT (XVME-220) and the two ADCs (VMIVME 3113A and VMIVME3123). It boots just fine and can be telnetted into!
  3. Pushed the DIN and the DACs back in. Still boots.
  4. Pushed only VMIVME3123 back in. Boot stalls again.
  5. Removed VMIVME3123, pushed VMIVME 3113A back in. Boots successfully.
  6. Left VMIVME3123 loose in the crate without electrical contact for now.
  7. Proceeded to lock PMC and IMC

The particle counter channel should be working again.

  • VMIVME3123 is a 16-Bit High-Throughput Analog Input Board, 16 Channels with Simultaneous Sample-and-Hold Inputs
  • VMIVME3113A is a Scanning 12-Bit Analog-to-Digital Converter Module with 64 channels

/cvs/cds/caltech/target/c1psl/psl.db lists the following channels for VMIVME3123:

Channels currently in use (and therefore not available in the medm screens):

  • C1:PSL-FSS_SLOW_MON
  • C1:PSL-PMC_PMCERR
  • C1:PSL-FSS_SLOWM
  • C1:PSL-FSS_MIXERM
  • C1:PSL-FSS_RMTEMP
  • C1:PSL-PMC_PMCTRANSPD

Channels not currently in use (?):

  • C1:PSL-FSS_MINCOMEAS
  • C1:PSL-FSS_RCTRANSPD
  • C1:PSL-126MOPA_126MON
  • C1:PSL-126MOPA_AMPMON
  • C1:PSL-FSS_TIDALINPUT
  • C1:PSL-FSS_TIDALSET
  • C1:PSL-FSS_RCTEMP
  • C1:PSL-PPKTP_TEMP

There are plenty of channels available on the asynchronous ADC, so we could wire the relevant ones there if we done care about the 16 bit synchronous sampling (required for proper functionality?)

Alternatively, we could prioritize the Acromag upgrade on c1psl (DAQ would still be asynchronous, though). The PCBs are coming in next Monday and the front panels on Tuesday.

 

 

Some more info that might come in handy to someone someday:

The (nameless?) Windows 7 laptop that lives near MC2 and is used for the USB microscope was used for interfacing with c1psl. No special drivers were necessary to use the USB to RS232 adapter, and the RJ45 end of the grey homemade DB9 to RJ45 cable was plugged into the top port which is labeled "console 1". I downloaded the program "CoolTerm" from http://freeware.the-meiers.org/#CoolTerm, which is a serial protocol emulator, and it worked out of the box with the adapter. The standard settings fine worked for communicating with c1psl, only a small modification was necessary: in Options>Terminal make sure that "Enter Key Emulation" is set from "CR+LF" to "CR", otherwise each time 'Enter' is pressed it is actually sent twice.

  12854   Tue Feb 28 01:28:52 2017 johannesUpdateComputersc1psl un-bootable

It turned out the 'ringing' was caused by the respective other ETM still being aligned. For these reflection measurements both test masses of the other arm need to be misaligned. For the ETM it's sufficient to use the Misalign button in the medm screens, while the ITM has to be manually misaligned to move the reflected beam off the PD.

I did another round of armloss measurements today. I encountered some problems along the way

  • Some time today (around 6pm) most of the front end models had crashed and needed to be restarted GV: actually it was only the models on c1lsc that had crashed. I noticed this on Friday too.
  • ETMX keeps getting kicked up seemingly randomly. However, it settles fast into it's original position.

General Stuff:

  • Oscilloscope should sample both MC power (from MC2 transmitted beam) and AS signal
  • Channel data can only be loaded from the scope one channel at a time, so 'stop' scope acquisition and then grab the relevant channels individually
  • Averaging needs to be restarted everytime the mirrors are moved triggering stop and run remotely via the http interface scripts does this.

Procedure:

  1.     Run LSC Offsets
  2.     With the PSL shutter closed measure scope channel dark offsets, then open shutter
  3.     Align all four test masses with dithering to make sure the IFO alignment is in a known state
  4.     Pick an arm to measure
  5.     Turn the other arm's dither alignment off
  6.     'Misalign' that arm's ETM using medm screen button
  7.     Misalign that arm's ITM manually after disabling its OpLev servos looking at the AS port camera and make sure it doesn't hit the PD anymore.
  8.     Disable dithering for primary arm
  9.     Record MC and AS time series from (paused) scope
  10.     Misalign primary ETM
  11.     Repeat scope data recording

Each pair of readings gives the reflected power at the AS port normalized to the IMC stored power:

\widehat{P}=\frac{P_{AS}-\overline{P}_{AS}^\mathrm{dark}}{P_{MC}-\overline{P}_{MC}^\mathrm{dark}}

which is then averaged. The loss is calculated from the ratio of reflected power in the locked (L) vs misaligned (M) state from

\mathcal{L}=\frac{T_1}{4\gamma}\left[1-\frac{\overline{\widehat{P}_L}}{\overline{\widehat{P}_M}} +T_1\right ]-T_2

Acquiring data this way yielded P_L/P_M=1.00507 +/- 0.00087 for the X arm and P_L/P_M=1.00753 +/- 0.00095 for the Y arm. With \gamma_x=0.832 and \gamma_x=0.875 (from m1=0.179, m2=0.226 and 91.2% and 86.7% mode matching in X and Y arm, respectively) this yields round trip losses of:

\mathcal{L}_X=21\pm4\,\mathrm{ppm}  and  \mathcal{L}_Y=13\pm4\,\mathrm{ppm}, which is assuming a generalized 1% error in test mass transmissivities and modulation indices. As we discussed, this seems a little too good to be true, but at least the numbers are not negative.

  12869   Mon Mar 6 12:34:30 2017 johannesSummaryASSASS light injection scenarios

What we want from the light source for the AS port light injection:

  • Frequency control for locking and maintaining known offset from arm cavity resonances -> see below
  • Fast extinguishing light in the IFO -> AOM first order switching

We have four possible laser sources that we can use for the injection of 1064 nm from the back:

  • There are ~65 mW of IR power coming from the PSL doubling oven, of which ~2mW are used for the fiber beat box. The remaining light is currently dumped on the PSL table and would be available. It is picked off after the PMC and does not have any of the sidebands.
  • There is a ~200 mW Lightwave NPRO on the PSL table that is currently unused.
  • Koji said he has a ~500mW NPRO in the OMC lab that has no PZT actuation. I contacted a couple companies about fiber-coupled variable AOM frequency shifters that we can pair with this laser.
  • I don't think using the high power beam of the PSL itself is a good idea, especially if we want to map the loss on the optics, because' we'll need it for the dither locking

I think for maximum flexibility it's best to fiber-couple whichever source we choose on the PSL table and then just collimate it out of a fiber on the AS table. This way if we want to add fiber-coupled modulators of any kind it's a plug-and-play modification.

Different frequency control schemes are:

  • Modulate sidebands on the light and stabilize directly to the arm, using POX/Y or back-reflection at AS
    • Free-space resonant EOM
    • Free-space broadband EOM with Rich's resonant amplifier attachment
    • Fiber-coupled EOM
  • Offset phaselock:
    • PSL IR: Transfer mode-cleaner stability
      • Can lock arms while measurement in progress, but will have PSL IR light on PDs
    • Green from the end;
      • Broadly tunable laser frequency and no interference from IR.

Either way we'll need a few things:

  • Faraday Isolator
    • required for PDH locking, optional if we phaselock instead
  • AOM
    • We have free-space available, looking into fiber-coupled ones with frequency tuning
    • Fast switching electronics
  • Various fiber stuff
    • We have enough to set up the fiber coupling of one light source. I'm starting with the 200 mW NPRO but this is technically interchangable.

I'm working on how to best set this up at the AS port and interfere with normal operation as little as possible. Ideally we use a Faraday just like for squeezed light injection, but this requires some modification of the layout, although nothing that involves mode-matching.

 

 

  12874   Wed Mar 8 18:18:51 2017 johannesUpdateComputer Scripts / Programsloss script

I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

  12879   Thu Mar 9 22:28:11 2017 johannesUpdateComputer Scripts / Programsloss script

loss map script running on Rossa that moves the beam on ETMX. Yarm was misaligned for this, most recent PIT and YAW settings were saved beforehand. This will take until late at night, I estimate 2-3 am.

Quote:

I started a loss script on Donatella that will scan the beam spot across ETMY, recording the reflected power from the arm via the networked scope at the AS port until later tonight (should be done by 9 pm). ITMX is currently strongly misaligned for this, but can be restored with the saved values. I mostly adapted the mapping scipts for the scope readout but still have to iron out a few kinks, which is why I'm running this test. In particular, I still need to calibrate how much the spot actually moves on the optic and control the ASS demodulation offsets to keep the beam stationary on ITMY.

 

  12882   Fri Mar 10 19:48:56 2017 johannesUpdateComputer Scripts / Programsloss script

Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

  12883   Sat Mar 11 20:11:58 2017 johannesUpdateComputer Scripts / Programsloss script

Yarm script running on Pianosa. Still working on visualization of the ETMX lossmap.

Quote:

Loss script running again, on Pianosa this time. Due to an oversight in the code the beam wasn't actually moved across ETMY last night. This time I confirmed that the correct offset value is written as a demodulation parameter to the correct mirror degree of freedom. Script will probably run through the night. Yarm is currently misaligned but previous alignment was saved.

 

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

  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.
 

 

  12965   Wed May 3 16:12:36 2017 johannesConfigurationComputerscatastrophic multiple monitor failures

It seems we lost three monitors basically overnight.

The main (landscape, left) displays of Pianosa, Rossa and Allegra are all broken with the same failure mode:

their backlights failed. Gautam and I confirmed that there is still an image displayed on all three, just incredibly faint. While Allegra hasn't been used much, we can narrow down that Pianosa's and Rossa's monitors must have failed within 5 or 6 hours of each other, last night.

One could say ... they turned to the dark side cool

Quick edit; There was a functioning Dell 24" monitor next to the iMac that we used as a replacement for Pianosa's primary display. Once the new curved display is paired with Rossa we can use its old display for Donatella or Allegra.

  13235   Mon Aug 21 20:11:25 2017 johannesSummaryGeneralLoss measurements plan

There are three methods we (will soon) have available to evaluate the round-trip dissipative losses in the arms that do not suffer from the ITM loss dominance:

  • DC reflection method:
    • Compare reflected light levels from [ITM only] vs [arm cavity on resonance]
  • Basler CCDs:
    • Infer large (or small) angle scatter loss with calibrated CCDs
  • Reflection ringdowns:
    • Need AS port light injection, principle is similar to DC method but better (?)

DCREFL

The DC method comparing reflectivities has been used in the past and is relatively easy to do. After the recent vacuum troubles the first step should be to re-perform these as CDS permits (needs some ASS functionality and of course the MC to behave). It wouldn't hurt to know the parameters this depends on, aka mode overlap and modulation depths with better certainty. Maybe the SURF scripts for mode-spectroscopy can be applied?

CCDs

With the new CCD cameras calibrated, pre-vent we can determine the magnitude of the large-angle scatter loss (assuming isotropic scatter) of ETMX and possibly ETMY. Can we look past ETMX/ETMY from the viewports? Then we can probably also look at the small angle scatter of ITMX and ITMY. If not, once we open one of the chambers there's the option of installing mirrors as close as possible to the main beam path. The easiest is probably to look at ITMX, since there is plenty of space in the XEND chamber, and the camera is already installed.

ASPORT

This requires a lot of up-front work. We decided to use the spare 200mW NPRO. It will be placed on the PSL table and injected into an optical fiber, which terminates on the AS table. The again free space beam there needs to be sort-of mode-matched into the SRC ("sort-of" because mode-spectroscopy). We want to be able to phaselock this secondary beam to the PSL with at least a couple kHz bandwidth and also completely extinguish the beam on time-scales of a few microseconds. We will likely need to purchase a few components that we can salvage from other labs, I'm still going through the inventory and will know more soon (more detailed post to follow). We need to settle for the polarization we want to send in from the back.

 

Tentative Schedule (aggressive)

Week Aug 21 - Aug 27:

  • Update mode-overlap estimates
  • Obtain current DC refl estimates
  • Spatial profile of auxiliary NPRO
  • Fiber setup concept; purchasing
  • CCD software prep work

Week Aug 28 - Sep 3:

  • Re-evaluate modulation indices if necessary
  • Optical beat AS Port Auxiliary Laser (ASAL) - PSL
  • PLL setup
  • CCD large angle prep work

Week Sep 4 - Sep 10:

  • PLL CDS integration
  • Amplitude-modulation preparation
  • CCD large angles

Week Sep 11 - Sep 17:

  • Fiber-injection
  • AS table preliminary mode-matching
  • Faraday setup
  • CCD small angle prep work

Week Sep 18 - Sep 24:

  • ASAL amplitude switching
  • CCD small angles

Week Sep 25 - Oct 1:

  • AS port ringdowns

 

  13241   Tue Aug 22 16:56:54 2017 johannesSummaryGeneralAS laser existing components inventory

I surveyed the lab today to see what we may need to buy for the AS laser setup.

We have:

NPRO 200 mW + Driver

Faraday Isolator from cabinet

ISOMET Model 1201E: This is a free space AOM I found in the modulator cabinet. It needs to be driven at 40MHz (to be confirmed) with ~6W of electrical power. For a 500 micron beam it can allegedly achieve rise times of '93' [units not specified, could this be nanoseconds?]. I did not find a dedicated driver for it, however there was a 5W minicircuits amplifier ZHL-5W-1 in the RF cabinet and a switch ZSDR-230, which has a typical switch time of 2 microseconds, however I'm not sure how this translates to rise/fall times of the deflected power. It seems we have everything to set this up, so we'll by the end of the week if we can use a combination of these things or if we need to buy additional driver electronics.

New Focus model 4004 broadband phase modulator which is labeled as dusty, and in fact quite dirty when looking through. We should attempt to clean this thing and maybe we can use it here or at the ends.

Probably all the optics we need for the PSL table setup.

 

We need:

Beat PD: How about one of these: EOT ET-3000A? I didn't find a broadband PD for the beat with the PSL

Fiber Stuff: coupler & polarization maintaining fiber 20m & collimator. There are a couple options here, which we can discuss in the meeting.

Faraday Isolator: If we want to inject P-polarization. If S is okay we can use a polarizing plate beamsplitter instead.

Possibly some large lenses for mode-matching to IFO (TBD)

 

 

ELOG V3.1.3-