0.1720m waist position
NAOJ GW Elog Logbook 3.2

[Logan, Marc]
Fixed amplifier and clock with kapton tape.
Seems clock and LNVR are quite hot (no heatsink) maybe the reason for their degradation?
Recabled all DDS connections
SHG alignment : fundamental = 1.6V ; hom = 64+88mV ie 91.3% mode-matching. not sure why the previous spurious HOM diaspeared..
after some tweaking we got kind of similar values so it seems hard to further optimize without moving the matching lens.
IRMC fund = 320mV, hom = 32 + 18mV ie 87% mode-matching after alignment (only acting on lens) funad = 364mV and hom = 24mV ie 94% mode-matching

Logan, Michael
We found the source of the problem regarding beam size. Before the PBS there is a telescope consisting of two 100mm lenses but they were quite poorly centered. We took them out and adjusted the reference alignment to lie at 74mm height above the usual designated set of screw holes on the breadboard, then put in the lenses, both times centering them by recovering the reference alignment, approximately. After I fixed them, the beam waist moved a bit closer towards the source than before, but we could see from measurements of the beam divergence that now we have the beam diameter changing by approximately 150 um per screw hole of z displacement, going to and from the beam waist. The beam waist diameter is approximately 250-300 um, we didn't measure super precisely but it seems enough for the purpose of using modulators to the OPO.
Basically, always set a reference target before inserting optical components that require precise centering.
Next step is to construct the beam path to test the OPO. The beam size as is is probably fine for modulators but the beam size increases when going to the Korean Faraday isolator experiment. Guessing from Gaussianbeam.exe rough calculations and looking at the size of the sensor card, we can also get about 1.5mm diameter collimated beam from small fiddling of the mode matching telescope. I should check again what is the clear aperture of Korean FI but I suppose they can always put a lens before their periscope if they really need a smaller beam.
I originally designed some beam size parameters to put a 2.3mm diameter beam into the fiber SHG. However, the Taiwan New Years visitors used a completely different setup to what I wrote down. In some sense my design was not very good (I left the bare minimum of space for QWP/HWP/Faraday/Mode matching after the laser, for no good reason), although I asked a few people about it and no-one pointed out these issues. The 2.3mm beam diameter was a parameter given to me by Chien-Ming Wu for the fiber input, and given he used this type of fiber SHG before I just trusted him on the number. But it seems the people who set it up had other ideas. I need to check.

[Hugo, Marc, Shalika]
We installed the lens found by Shalika on 5cm tube attached to the camera.
We installed the camera and prepared alignment.
WIthout sample, the polarization was quite off pure s-polarized light so we started to optimize the input polarization. However, we were quickly limited by the 0.1deg rotation resolution of the HWP and QWP so we swapped their mount for higher manual precision ones. During this process, we found a small scratch at the edge of the HWP so we replaced it.
We started to tune the input polarization and achieved quite nice polarization with 0.01deg fluctuations in azimuth and ellipticity. However, it seems the camera alignment should be further optimized as we only have about 0.9mW reaching the camera (from the 1.6mW injected).

It truns out that there was some issue with the cooling tower on top of building 2 so the water being pumped was warm. I will do a standalone test next time the water supply to Matsuo-san lab can be turned off.

We wish to add polarization camera in the readout section on the PCI. We don't have a lot of space but do require a beam of divergence less than 2deg for camera and less than 3mm in diameter.
For this we used the initial beam characteristics and chose a lens which could fit itself alongwith the camera in the readout.
At 2 cm after box The beam characteristics looks like shown here.
At 0.5 cm after box beam characteristics looks like shown here.
so, we can probably add the F=100mm lens 2cm after the box starts. The farther we go the beam divergence and beam diameter incident on the camera will increase, which is not desirable in our case.

Overview: Tested the cryocooler operation with water supply to Matsuo-san lab shut off.
Conclusion (Hypothesis): Closing supply at Matuso-san lab may have cut off the supply to the GWSP cryocooler.
Details: I turned on the cryocooler at 8:27. The cryocooler turned off on it's own at 8:47. The following errors were displayed:
- Helium Temperature Err
- Water Temperature Err
- Water Flow Err
Observations: The cryocooler body was not hot. The helium supply tube was hot. The return supply tube was cold. The Temperature of both water supplies was normal. Note: All these temperature measurements are subjective to me holding the parts.
I am thinking that the water supply to our section was also cut off by the valve Matsuo-san shut.
Next: Confirm if the water is flowing into the cryooler.
It truns out that there was some issue with the cooling tower on top of building 2 so the water being pumped was warm. I will do a standalone test next time the water supply to Matsuo-san lab can be turned off.

Logan, Michael
We took out the Faraday isolator and set the beam profiler as a reference target. There was 2.7 mW incident. We set the Faraday isolator on a pedestal pillar and aligned it so that the beam profiler shape looks good, with no obvious HOM, and there is a decent amount of power, about 2.3 mW. Maybe not optimal transmission but good enough.
Then we checked the beam profile on the s-pol path. It is still doing that weird behaviour where ithe beam divergence coming out of the waist is about half the rate of beam convergence going into the waist, which applies to both the horizontal and vertical components. I don't know what is causing this, it doesn't seem to be the beam profiler since Hugo took it. I don't think it's anything to do with my Faraday technique since I just took it out of the box and I also did the Faraday for speed meter experiment and that is fine. There is one mode matching telescope before the PBS which seems a bit off centre but I feel like it's not enough to be causing the issue. The laser has a bit of difference between horizontal and vertical size but I think this was the same last time I did the OPO characterization. So I don't know what is causing the problem.
In some sense perhaps it is not important to find out either. That mode matching telescope was originally intended to make a 2.3mm collimated beam, so maybe we should just reset it to the original intention.

similar to elog 3581
we do stability check of setup before LC. The camera is place in the transmission of the mirror which steers the main beam to the QWP at the start of LC setup path.
filename C:\Users\atama\OneDrive\LC-Experiment\Measurement Data\Stability Check\Mon, Jun 3, 2024 5-20-28 PM.txt
The measurement will be started after an hour of switching on the laser.

from injection breadboard to blackbox 27 cm
from injection to readout breadboard 34 cm
last steering mirror to injection breadboard 5.5cm
size of camera 5.5 cm
beam after last steering mirror at 0
0.1720m waist position

Also, In "Move read write with Cam" Vi there is a place where the lockin data was used to make the matrix for the map which is visible in the main VI. Since the previous configuration only allowed one input here, I only added ellipticity from the camera. Not sure how to introduce azimuth here on one single map.

In the averaging filter VI made copy of the previous filter 6 times to be able to filter Azimuth, Ellipticity, Power, S1, S2, S3. All of their output were added in cluster for ease of transfeering data from one Vi to another. In the Buffer filter file also I made the buffer for all variables.
The output of averaging filter was connected to the graphical displays on the main VI. The VI is perhaps ready for initial tests and for checking if everything was replaced in a proper manner.

Tried to resolve labview crash/disappearing issue by
1. Tools>> Advanced>>Clear Compiled Object Cache
2. Windows Update
3. Added exclusion in windows defender for .vi programs

After an hour(ish) there was 460 points.
So, I have increased the wait time to 30s and had started measurment for long term yesterday
filename: C:\Users\atama\OneDrive\LC-Experiment\Measurement Data\Stability Check\Wed, May 29, 2024 11-25-51 PM.txt
Also, for some time I have noticed an isssue with Labview on Bigfoot PC. It closes automatically on its own. I don't know if something is crashing but this is happening even when there is no windows update. But, has been happening more since last windows update. Unsure if its due to some bug.

We are now just saving some data at 10 seconds interval for about an hour, to see
1. size of file generated (to understand what should be the wait time inlabview to have reasonable file size with same measurement continued for 1 day)
2. see how much deviation can the setup have if nothing is changing.
The camera is in transmission after BS.
foldername=C:\Users\atama\OneDrive\LC-Experiment\Measurement Data\Stability Check
The wait time is 10s and averaging is off
filename = Wed, May 29, 2024 9-47-22 PM.txt
After an hour(ish) there was 460 points.
So, I have increased the wait time to 30s and had started measurment for long term yesterday
filename: C:\Users\atama\OneDrive\LC-Experiment\Measurement Data\Stability Check\Wed, May 29, 2024 11-25-51 PM.txt
Also, for some time I have noticed an isssue with Labview on Bigfoot PC. It closes automatically on its own. I don't know if something is crashing but this is happening even when there is no windows update. But, has been happening more since last windows update. Unsure if its due to some bug.
Tried to resolve labview crash/disappearing issue by
1. Tools>> Advanced>>Clear Compiled Object Cache
2. Windows Update
3. Added exclusion in windows defender for .vi programs

In "MovereadWritewithCam" file, I replaced the items where lockin amp signal were sent to write into measurement file with the ones from camera

Further Modification that were done
1. Duplicated average filter that was used and made modification to accomodate Azi, Ell, Power, S1, S2, S3 from camera.
2. Duplicated "Move, wait, read, write" VI to make new and introduced pol cam control subvi inside it. Can save signal from camera now here, instead of lockin amp
3. Create a new global variable file for variable from camera

With Matsuo-san
Overview: Today, we tested if the cryocooler in our Lab can be operated in parallel with Matsuo-san cryocooler.
Conclusion: We cannot operate them together.
Deatils: One of the cryocolers in Matsuo-san's lab was already operating. At first, we closed the valve connected to the input of the GWSP cryocooler and observed the water pressure in Matsuo-sans lab.
The pressure with the valve open was: 0.25 MPa
After closing the valve, the pressure was: 0.28 MPa
Based on this we concluded that water was flowing into the GWSP cryocooler. After confirming this, we opened the valve again and turned on the cryocooler. At this point, I realized I had made some errors in the temperature sensor cabling as the readings were all over. Since the goal was to confirm the parallel operation, I continued with cooling. The cryocooler was turned on at 11:28 and was atleast working until 11:50 when I left the lab. When I returned around 12:50, the cryocooler was off and showed "Motor Temp: Err", so I concluded that the water pressure was insufficient for parallel operation and the compressor overheated. However, the compressor was not too hot to touch but may have just turned off a while ago. One thing to note is that the manual suggests using the arrow key and confirming that the LED display also shows "Water Flow Err" to confirm the issue is low water pressure, but I forgot to do this. In any case, the conclusion is that two cryocoolers can't be operated in parallel.
Side Note: As previously reported, there are two sensors somewhere inside the cryostat, but I could not see them (I asked about it to Satoshi Tanioka at GWADW but he doesn't remember). However, since the temperature of this sensor did not drop drastically, I concluded they are not connected to the cold-head. I will look for them again when I open the cryostat.
Next Step: I am now discussing with Matsuo-san to have standalone test for our cryocooler to confrim if the water pressure is enough. Also, we should try to install a pressure guage near the water supply for our cryocooler.

The error was due to mismatch between 64bit windows and 32 bit labview version. The problem has been resolved and the version of thorlabs labview module was synced to identify libraries for 32 bit

1. ON PCI PC: We needed Thorlabs camera in PCI. There was conflict between the version of labview that was used to make VIs for Bigfoot pc and the PCI pc. Sadly, we can't open labview made in new version in a labview of olderversion. Which meant had to make it again for pci pc.
2. In any case, the three subvi are prepared for start, control and closing the camera. Just need to resolve the issue of identifying camera by labview. Currently labview can't detect the software and libraries of camera. We had similar issue in past which happened due to poor installation methods (like plugging in camera before installation, or not restarting the pc)
The error was due to mismatch between 64bit windows and 32 bit labview version. The problem has been resolved and the version of thorlabs labview module was synced to identify libraries for 32 bit
Further Modification that were done
1. Duplicated average filter that was used and made modification to accomodate Azi, Ell, Power, S1, S2, S3 from camera.
2. Duplicated "Move, wait, read, write" VI to make new and introduced pol cam control subvi inside it. Can save signal from camera now here, instead of lockin amp
3. Create a new global variable file for variable from camera
In "MovereadWritewithCam" file, I replaced the items where lockin amp signal were sent to write into measurement file with the ones from camera
In the averaging filter VI made copy of the previous filter 6 times to be able to filter Azimuth, Ellipticity, Power, S1, S2, S3. All of their output were added in cluster for ease of transfeering data from one Vi to another. In the Buffer filter file also I made the buffer for all variables.
The output of averaging filter was connected to the graphical displays on the main VI. The VI is perhaps ready for initial tests and for checking if everything was replaced in a proper manner.
Also, In "Move read write with Cam" Vi there is a place where the lockin data was used to make the matrix for the map which is visible in the main VI. Since the previous configuration only allowed one input here, I only added ellipticity from the camera. Not sure how to introduce azimuth here on one single map.
The format of saving is of the form:
X, Y, Azimuth, Ellipticity, Power, s1, s2, s3
"Birefringence Map with Camera.vi" modified to take into account std and 100 averaging
file will save in format
X, Y, Azimuth, std azi, Ellipticity, std ell, Power, s1, s2, s3

1. On Bigfoot PC: Increase buffer size for enhanced averaging. Can do upto 200 averages.
2. Also, decrease time in iterating while loop to do long term stability checks.
I did some check based on fiber equations that you can find on Thorlabs or Newport.
The fiber to the SHG is PM980 (polarization maintaining 980nm in-fiber wavelength) with a mode field diameter 6.6 um. This gives f/D = pi*MFD/(4 lambda) = 4.8. Thorlabs FC/ACP connector fiber collimators are sold with f = 2.0, 4.6, 7.5, 11.0, 15.3, 18.4mm focal lengths, giving input beam diameters D = 0.41, 0.94, 1.53, 2.26, 3.14, 3.8 mm. The clear apertures are 2.0, 4.9, 4.5, 4.4, 5.0, 5.5 mm. In retrospect, maybe I should have picked the f = 4.6mm. But it's maybe not super important. exp(-2*(r/w0)^2) = 0.00051 (510 ppm diffraction loss) for the current coupler. r > 2.7 w0 gives < 1 ppm diffraction loss.