40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 ATF eLog, Page 8 of 57 Not logged in
ID Date Author Type Category Subject
2195   Thu Feb 22 12:13:27 2018 awadeComputingGeneralReset Gateway Router

I reset it and the all the routers in the ATF lab about three times yesterday .  Something is configured wrong somewhere that is jamming up the DHCP issuing of IP addresses.

We need to address the way the ATF network is structured, but its a real pain and will take a lot of time with little science dividend.

 Quote: The gateway router went down sometime since yesterday. I reset it, and it is accessible again.

2196   Thu Mar 8 13:23:57 2018 Craig, awadeComputingGeneralgateway Linksys router was wiped via factory-reset, awade saves the day

This morning, the Linksys gateway router was hung.  Craig went into the ATF lab to reset it, and foolishly pushed the "Reset" button on the Linksys router.

DO NOT push the reset button on the gateway router!  This factory-resets the settings of the router, and does not cycle the internet connection as Craig expected.  To cycle the internet connection, simply unplug and replug the power cable.

Fortunately, awade had taken a screenshot of the Linksys settings on ws2 in the ATF, and was able to quickly get everything working again.

Craig took some similar screenshots and is posting them here for future reference.

2197   Mon Apr 23 12:44:07 2018 Jon RichardsonComputingGeneralAdded TCS/AWC Lab Port Forwards back to Linksys Router

Here they are for future reference.

Attachment 1: TCS-AWC_port_fwd.jpg
2200   Sun May 27 16:10:27 2018 awadeComputingComputingAccessing 3com switch from screen on mac

Somehow I lost access to the 3com switch in the PSL lab.  The default config IP was lost and from there we have been unable to edit its settings.

The 3com model 2920-SFP switches don't have a reset button.  They can only be reset from the serial port.  Larry Wallace lent me a USB serial to RJ45 cable but I have been unable to obtain a connection through a terminal PuTTY session until now.

The instructions for resetting the router can be found HERE

I found that serial connections through MacOs terminal 'screen' utility just returned random characters. It turns out that the problems with the USB serial connection were the baud rate. In this case it must be set to 38400

## Connecting to 3com routers with USB converter

To launch a serial USB session with a converter device. Run

> ls /dev/*usb*

then plug in the USB converter device (USB to serial DB9 + DB9 to RJ45) and run the above command again to see what appears when the device is initialized. You should see something like /dev/cu.usbserial-xyz appear, where cu.usbserial-xyz is serial converter you want to connect to.

Then launch screen with

> screen -L /dev/cu.usbserial-A4007BdM 38400 -L

Power cycle the 3com router and it should return a bunch of sensible startup dialog like

Starting......

    ************************************************************************     *                                                                      *     *              3COM 2920-SFP Plus BOOTROM, Version 113                 *     *                                                                      *     ************************************************************************     Creation Date       : Jun  1 2009     CPU L1 Cache        : 32KB     CPU Clock Speed     : 333MHz     Memory Size         : 128MB     Flash Size          : 128MB     CPLD Version        : 002     PCB Version         : Ver.B     Mac Address         : 002473850035 Press Ctrl-B to enter Extended Boot menu...0

As instructed hit Control-b (Not command-b) then follow the instructions in the LINK above. Note that where they say "<blank>" for password they actually mean enter nothing.

From there you can configure IP addresses etc from command line.  However, it is probably just easier to let the top level router DHCP allocate an IP address and then do it directly from the browser.

2224   Fri Jul 27 15:50:16 2018 AidanComputingTempCtrlFB4 has stopped recording second trends

FB4 is down. The DAQD appears to be running on the machine but no data is being written to file.

I was looking yesterday and discovered that FB4 had stopped. Some digging revealed that the last recorded frames were from May-29.

2302   Mon Mar 11 08:49:11 2019 Aidan, ChubComputingCymacsBuilding FB4 Cymacs

We started migrating equipment for the FB4 Cymacs to the QIL on Friday. See attached list and images.

Attachment 1: IMG_8851.jpg
Attachment 2: IMG_8852.jpg
2367   Sat Jun 29 09:50:20 2019 JonComputingCDSCymac workstation setup

I moved a new Dell Precision 3430 onto the lab bench near the door. It's replacing the older unused machine that was in that spot (IP=10.0.1.33). The intention is for the new machine to provide MEDM (sitemap) access to the QIL cymac and to run the full CDS utils suite (awg, NDS, etc.).

There are two operating systems that have CDS package support: Debian 9 and Scientific Linux 7. Unfortunately neither of these operating systems is officially supported for this model computer according to Dell.

I attemped to install base Debian 9.9, which can be done successfully and booted. However, the installer is unable to locate the drivers for the network card, leaving the machine without network capability. This is likely because the network card (Intel i219-LM) is brand new and support hasn't been incorporated into the distributions yet. I next tried installing the latest weekly snapshot (testing build) of Debian with additional commercial firmware included. This time the network card was recognized, and the installation appeared to complete entirely successfully. However, the system then failed to boot the new OS. I tried first just reinstalling the GRUB (boot) loader, then entirely reinstalling the OS, both with the same result. Something in the test build is preventing the hard disk from being recognized as a bootable device.

I have one more idea to try next week: Again install base Debian 9.9 (without network capability), then attempt to manually install the i219-LM drivers provided by Intel.

2369   Wed Jul 10 17:37:09 2019 JonComputingCymacsNew QIL workstation

I finally succeeded getting Debian installed on the new workstation with a working network card. I installed Debian 10.0, which was just released last week and will be supported for five years. After installing the OS, I

• Configured the machine (network interface, user account, etc) following my standard procedure
• Installed the cds-workstation superpackage following Jamie's instructions.

The user name is controls as usual and it has the standard W. Bridge password. The lscsoft repo for Buster (Debian 10.0) is still missing many packages, so I installed the cds packages for Stretch (Debian 9.9) instead. They seem to be compatible with 10.0 as far as I can tell. The machine is at the same IP as the one it replaced, 10.0.1.33.

To be able to interface with the cymac, there is still an RTS environment (environment variables and an NFS mount) that needs to be set up. I'm looking into what this involves.

Attachment 1: IMG_3493.jpg
2370   Mon Jul 15 19:02:21 2019 JonComputingCymacsCymac RTS Environment Set Up

Chris and I set up the LIGO RTS environment on the QIL cymac, using code copied from the cryolab cymac. Specifically, the script /opt/rtcds/rtcds-user-env.sh was edited to match the cryolab version and added to the /home/controls/.bashrc file. We also downloaded a copy of the CDS user apps SVN to /opt/rtcds/userapps/release. Tools like dataviewer and ndscope now work on the cymac (fb4: 10.0.1.156).

Our plan is to set up a network drive on a third machine to host the /opt/rtcds directory currently located on the cymac. This way, the directory can be shared with any number of workstations as well as the cymac itself, and the NFS mounts will be unaffected by frequent reboots of the cymac.

I also unsuccessfully attempted to diagnose the race condition that occurs between all the RTS services on boot. Right now the services all start correctly only about 1/3 of the time. I tried setting the order that the services are started and adding a 15-second delay after each service start. However, this did not make things become deterministic.

2371   Mon Jul 22 18:11:59 2019 JonComputingCymacsNew Monitors for QIL Workstation

Two new 27" LED monitors arrived today for the QIL workstation. I've installed them.

Attachment 1: IMG_3523.jpg
2397   Tue Aug 13 19:14:04 2019 JonComputingCymacsNFS server set up

I rebuilt one of our old desktop machines to serve as NFS server for the cymac. It is running Debian 10.0 and assigned IP 10.0.1.169 (hostname qil-nfs). I installed a new 2 TB hard drive dedicated to hosting the LIGO RTS software and frame builder archive, which is shared with all other lab machines via NFS.

I have moved the new machine into the server rack and copied the contents of /opt/rtcds on the cymac into the shared location. Functionality like sitemap and the CDS tools can now be run directly from the QIL workstation (plus any other machine on which we add the NFS mount).

Attachment 1: IMG_3587.jpg
2427   Tue Oct 1 19:25:08 2019 JonComputingCymacsIP address changes

Someone (not me) has recently changed the IP addresses of the lab machines. I see the new assignments are the following:

 10.0.1.14 ? QIL Lab fb4 10.0.1.20 ? QIL Lab qil-nfs 10.0.1.21 ? QIL Lab qil-ws1 10.0.1.22 ? QIL Lab qil-ws2
2469   Fri Dec 6 00:13:12 2019 ChrisComputingCDSarbitrary waveform streaming on the cymac

Recently Duo wanted to make an arbitrary waveform excitation using the QIL cymac, but it wasn't working.  An excitation would die after 10 seconds or so, with awgtpman reporting that the data was too far in the future.

It turns out this was caused by a missing leap second in the RTS software.  It is now fixed upstream, and we're running a patched version of awgtpman on fb4, until the change propagates to the packaged version.

2542   Fri Mar 19 13:51:16 2021 AidanComputingGeneralActivated MATLAB on QIL-WS2

Except access is denied by FB4

2544   Thu Mar 25 12:28:19 2021 AidanComputingCymacsDAC channels not outputting voltages

Noticed that the DAC channels were not producing a corresponding output in the real world (I changed the Laser Current FM12 value and got not corresponding change on the laser diode driver display).

Sent the following to Chris: "Can you log into the QIL FB4 workstation to see if there is an issue with the DAC? I restarted the C4TST model last week and I don’t seem to have working DAC outputs anymore. The ADC channels still work and the model appears to be running. It just seems that I can’t output any voltages."

After observing that the "DK" (DACKILL) bit in the state word on the IOP status screen was red, the resolution to this was to restart the IOP and TST models.

2545   Mon Mar 29 14:16:33 2021 AidanComputingCDSRebuilding C4TST with frames added to file

Added Simulink > Model-Wide Utilities > Model Info block to c4tst.mdl. Text inside that block is:

#DAQ Channels

FM31_OUT 16384

--

Now following https://nodus.ligo.caltech.edu:8081/QIL/2336

And it failed. See attached screenshot. Then I copied c4tst.mdl to the simLink directory. Compile still failed.

Attachment 1: Screen_Shot_2021-03-29_at_2.29.53_PM.png
2546   Wed Mar 31 11:06:53 2021 AidanComputingCymacsRebuilding the Cymacs software to compile models

[Aidan, Jon, Chris W, Ian]

Summary: We rebuilt the Cymacs C4TST today to get FM31_OUT into frames

Main points:

• Had to make this directory viewable on other machines by editing the /etc/exports file on FB4
• Had to update the /etc/fstab file on QIL-WS2 to give it the location of the new directory
• Had to manually mount the directoy on QIL-WS2 to avoid rebooting machine to achieve this (reboot will automatically mount the drive)
• C4TST model would not compile on FB4. Issue was two-fold:
• Compilation was done in wrong build directory
• Compilation was done using sudo
• To fix this, we had to clean up the compilation files from the failed sudo efforts
• sudo make clean-c4tst was run (didn't completely solve problem)
• Once the old compiles were cleaned up, we could compile models (not as sudo) in /opt/rtcds/rtbuild/
• Ran the following commands to manually restart the models (ignore the line numbers)
 1982  sudo /sbin/rmmod c4tst c4iop
1983  cd /opt/rtcds/caltech/c4/target/c4iop/scripts/
1984  ./startupC4rt
1985  cd ../../c4tst/scripts/
1986  ./startupC4rt
1987  systemctl start rts-awgtpman@c4iop.service
1988  cd .././../
1989  ls
1990  cd gds
1991  ls
1992  cd awgtpman_startup/
1993  ls
1994  ./awgtpman_c4iop.cmd
1995  ./awgtpman_c4tst.cmd
1996  systemctl restart daqd@standiop.service
1997  systemctl
1998  systemctl status daqd@standiop.service
1999  systemctl stop daqd@standiop.service
2000  sudo systemctl restart daqd@standiop.service


2653   Fri Aug 27 15:33:28 2021 AidanComputingCymacs

Got the DAC working by reactivating entries in the C4TST_cdsMuxMatrix.

• FM12-DAC12 = 1 (laser current) works
• FM13-DAC13 = 1 (bias) works
• FM15-DAC15 = 1 doesnn't work, No output on BNC at the AI chassis

No problems with channels 12-14. However, channel 15 doesn't output anything at the AI chassis.

Using channel 14 on the AI chassis with FM15 input into it.

• FM15-DAC14

2658   Tue Sep 7 08:12:50 2021 AidanComputingCymacs+/-18V power supply to AI/AA chassis was actually +18V, -14.5V

[Aidan]

I was working in the QIL on Friday and I heard a clicking sound coming from the rack where the DAQ is installed. It turned out to be the DC power supply for the AI/AA chassis. One of the voltage was floating around from ~14.2V to ~14.8V and the unit was clicking as it did this. Since the AA/AI chassis expect +/-18V which is regulated down to +/-15V, this was, to use the scientific term, bad.

I set the low voltage channel back to 18V. We have noticed previous drifts DAC channels - it's possible this was the cause.

Attachment 1: IMG_4578.jpg
Attachment 2: IMG_4577.jpg
2660   Tue Sep 7 11:52:40 2021 ranaComputingCymacs+/-18V power supply to AI/AA chassis was actually +18V, -14.5V

We should not have a bench power supply installed permanently. Can you install a Sorensen in that rack or use one of the nearby ones?

2669   Thu Sep 16 10:33:59 2021 AidanComputing2um PhotodiodesAutomation and analysis scripts for 2um data taking

The attached files are the scripts used to take data during the PD temperature cycling/testing and to retrieve and analyze data after the fact.

• ~/JPL_PD/scripts/autorun2021.sh
• ~/JPL_PD/scripts/piezo_mirror/maximize_output_power.py
• ~/JPL_PD/data/A1_analysis/A1_analysis.py
Attachment 1: autorun2021.sh
#diode name
i=1001
diode=A1
caput C4:TST-FM15_OFFSET 0
sleep 1
while :; do
#-----------------------------------------------------
# dark current
echo =======================
echo ----- TOP OF LOOP -----

... 141 more lines ...
Attachment 2: maximize_output_power.py
# script to maximize the output power of the piezo
import serial
import time
import os, sys, subprocess
import numpy as np

def slowDownJog(ser):
ser.write('1SU50\r\n')
time.sleep(0.1)

... 195 more lines ...
Attachment 3: A1_analysis.py
# analysis od the A1 JPL PD diode
# Aidan Brooks - 10-Sept-2021

import cdsutils
import numpy as np
import matplotlib.pyplot as plt
import os, glob
import scipy.signal


... 172 more lines ...
2670   Mon Sep 20 14:26:38 2021 ranaComputing2um PhotodiodesAutomation and analysis scripts for 2um data taking

you can put these in the GIT repo for the QIL Cryo tests that Radhika set up. Otherwise, they'll get lost. And we should probably change autorun to a .py script and document these in the README on the repo.

 Quote: The attached files are the scripts used to take data during the PD temperature cycling/testing and to retrieve and analyze data after the fact. ~/JPL_PD/scripts/autorun2021.sh ~/JPL_PD/scripts/piezo_mirror/maximize_output_power.py ~/JPL_PD/data/A1_analysis/A1_analysis.py

2818   Wed Dec 14 17:02:24 2022 ChrisComputingCDSfb4 fixed

The framebuilder is now running again. It relies on the c4iop front end model for timing, and that was not running either. (Maybe there was a power outage and the system wasn't brought back up afterward.)

The cryo lab has a gitlab CI script that complains to us on mattermost when its DAQ stops working. The QIL can probably use something like that, too.

2819   Wed Dec 14 17:11:13 2022 RadhikaComputingCDSfb4 fixed

Thanks Chris! Did you run startc4iop in /opt/rtcds/caltech/c4/scripts/?

CW: Yes, that's right. Perhaps after this cooldown we can find some time to upgrade the system to the new RCG that starts things automatically on reboot (like at the 40m).

I think that's a good idea - I'll get started on it.

 Quote: The framebuilder is now running again. It relies on the c4iop front end model for timing, and that was not running either. (Maybe there was a power outage and the system wasn't brought back up afterward.) The cryo lab has a gitlab CI script that complains to us on mattermost when its DAQ stops working. The QIL can probably use something like that, too.

2705   Wed Dec 31 15:59:59 1969 StephenDailyProgressCryo vacuum chamberRadiative Cooling of Si Mass, with worse inner shield inner surface emissivity - retry run was successful

This post will host plots and trends from this radiative cooling run (QIL/2704).

Preliminarily, it looks like the reconfiguration to remove a hardware mistake or two led to a healthier run. The comparison below clarifies the two runs:

• QIL/2702 - conductive link between inner shield and outer shield (twisted pair from an RTD lead accidentally clamped); possibly another conductive link between outer shield and baseplate (outer shield more wobbly than usual on spacers)
• this data set should only be used to study the impact of a known conductive link between inner and outer shields.
• this run demonstrates that there will be more effective, faster cooling if the outer shield is conductively cooled!
• QIL/2704 - resolved above mistakes!
• this data set may be used to gain understanding of the impact of emissivity changes to the inner surface of the inner shield.
• may be compared to QIL/2695, a run that is equivalent except with a higher emissivity inner surface of the inner shield

Run ended with cryocooler shutdown at 12:27 pm (actual duration just under 92 hours). System will warm up with pumps on for the rest of the break, unless I am inspired to come in and run one of the next intended runs discussed in QIL/2704. I did not run any heat input test for this data set, as I am not planning to come in frequently enough to monitor the heating safely.

Data:

Attachment 1 compares QIL/2704 (solid) to QIL/2702 (dashed). As expected, the outer shield temperature from the latter run stays warm since the conductive short was resolved. Due to the reduction of the inner shield's thermal load, the inner shield is able to cool faster and plateau at a colder temperature. As Stephen pointed out, however, the test mass is not cooled as efficiently compared to when the outer shield was conductively cooled.

Fitting Results:

Attachment 2 is a current model diagram of the various components being considered, and their thermal couplings. Attachment 3 plots the fitted model (dashed) over the temperature data (solid). The fit parameters were the following emissivities: aluminum foil, rough aluminum, and aquadag. Notes from the fit:

1. With the conductive shorting of the outer shield resolved, the model (which considers only radiative cooling of the OS) is well fit to the OS temperature data

2. The inner shield model is missing some key term(s) affecting its time constant and steady state temperature.

3. The above error propagates to the test mass model (I believe).

Given these caveats, the fit results are as follows: aquadag e = 0.92, Al foil e = 0.04, rough Al e = 0.19. These all initially seem reasonable, and I'm happy to see that the aquadag emissivity is higher than previously estimated.

Next steps:

1. Separate the cold plate from the inner shield, and model their conductive and radiative link. Also model the radiative link between the cold plate and the test mass.

2. Cover the test mass in foil (to best of our ability) to refine the radiative link between the test mass and inner shield. Doing so will mean both elements have the same emissivity, so there is only one unknown parameter.

Attachment 1: cooldown_12-21_vs_12-10.pdf
Attachment 3: 12_21_cooldown_fit.png
2363   Wed Dec 31 15:59:59 1969 ShubhabrotoDailyProgress Little PMC Assembly
I collected the following things to assemble one unit of little PMC (attachment 1)
 Item Name Quantity Aluminium Spacer 1 Clamp 2 Endcap 1 Curved Mirror 1 Plane Mirror 2 Piezoelectric Transducer (PZT) 1 O ring 2 Epoxy 30 CL 1

Procedure:
1. Start by assembling the plane mirror to the clamp. First, put an O ring inside the clamp envelope(attachment 2) and then gently place the flat mirror on that(attachment 3). Rotate it 45 degrees and bolt this setup with the metal spacer using screws and Allen Key, Follow the same procedure for another plane mirror as well. The plane mirror is 99% reflecting on one side and transmitting on the other. The reflecting surface should be placed facing inside the clamp. An easy method to find the coating of the mirror is to hold it from the sides (never touch the middle part) and then checking if the bottom surface of the mirror is visible. If the bottom part is visible, then the side facing you transmits light and hence should be towards the outside. After this stage of assembly, it will look similar to attachment 4. Note: 3/8'' screw was used for this step.

2. Next, proceed to assemble the endcap unit. The PZT should be glued centered on the endcap and the curved mirror should be glued centered on the PZT. As is it very difficult to align them properly, a jig can be used for gluing purpose. The external space has the same diameter of the PZT, the internal one has the same diameter of the curved mirror. The slots on the edges are used for the wires of the PZT. Epoxy 30 CL can be used for this purpose. A necessary support system can be assembled as per need.

I was assembling two units of the little PMC yesterday night. I followed step 1 of the procedure. It went uneventful. While assembling the 2nd unit, an unfortunate incident happened.
I was working on attaching the plane mirror between the spacer and the clamp(with O-ring). I bolted all the 3 bolts then observed a small crack in the mirror. To investigate further I opened the bolts. Then I observed that one of the bolts broke inside. The exact cause of the breaking of the bolt is not known. One possibility could be that it was a bit misaligned as it was the first bolt to be bolted and in the process got stuck to something. Not knowing what to do further, I wrapped up everything, kept all the things at their appropriate places, locked the lab and left.
Attachment 5 shows the broken screw on the left and a normal screw on the right. Attachment 6 shows a cracked mirror. Attachment 7 shows the broken screw fixed inside the spacer.

Today morning, Anchal and I went back to investigate the situation. It is quite unlucky to have a bolt broken from very near to the edge and getting it stuck in the spacer. Further investigation is required on how to take the broken screw out.
Attachment 1: Materials_Required.jpg
Attachment 2: O_ring.jpg
Attachment 3: Mirror_in_clamp.jpg
Attachment 4: Mirror_placed.jpg
Attachment 5: Bolt.jpg
Attachment 6: Cracked_Mirror.jpg
Attachment 7: Broken_Bolt_inside_spacer.jpg
2134   Mon Jul 10 12:05:49 2017 Amani GDailyProgressScatterometerInitial Build and Some Measurements

What I have so far is a scatterometer using two InGaAs photodiodes.

## Set Up:

There is a square plate that I found, and screwed onto a rotating plate. I then put that on 2 4inch posts, once I have the motor running I will but it underneath. The laser comes in from the right through the fiber, which is carefully screwed into the table via a fiber organizer. The laser then moves through a collimator, a waveplate polarizer, another polarizer (making sure we have horizontally polarized light), and then reaches a 90/10 beam splitter. 10% of the beam is directed onto a post that is screwed into the square plate, through an iris, and focused on a photodiode. This gives us a baseline of how much power is coming out of the laser. The other 90% of the beam is sent through the chopper, which is being driven at 164Hz and produces a square wave (the 3rd image is from testing the chopper, ch.1 is the chopper driver, ch.2 is the chopped beam). The beam then goes through the silicon sample, where the light transmitted is dumped, and the light scattered is focused via an iris and recorded with another photodetector. I made sure to dump any light that was reflected off of the sample and off of the chopper.

## Initial Results:

The osciolloscope is triggered off of the choppers driver, which produces a square wave at 164Hz. Initially I looked at the light transmitted through the sample, and then slowly rotated the sample to see how the light changed. After integrating, I was able to see the scattered light at theta = 0, at other angles it quickly dropped to zero (maybe the photodetector isn't sensitive enough, or there is a steep drop off at other angles). For theta = 0, there was a delta of 5.04 mV. The trigger's high was -19.7mV, adn the signal's high was -14.6mV, this is the 4th image.

## Moving Foward:

The raspberry pi is up and running, once I have the camera I should be able to set up a script that triggers the camera and spins the sample using the stepper motor. I would like to test the camera to see what kind of signal I get from it, and if that differs from the photodetectors. I need to find a way to connect the stepper motor to the rotation stage, maybe 3D print an attachable washer I can screw into the rotation stage. Also I will try to 3D print a large box that I can paste beam-dump wrap to so that I can block out room lights. Any other thoughts to improve the experiment are welcome!

Attachment 1: IMG_1854.JPG
Attachment 2: prototype.jpg
Attachment 3: IMG_1762.JPG
Attachment 4: IMG_1862.JPG
2136   Tue Jul 11 12:21:00 2017 awadeDailyProgressScatterometerInitial Build and Some Measurements

Great, its good to see a first setup.

For your power monitoring, it my be a good idea to characterize the W/V conversion of the what you see on the monitor photo diode voltage vs the power incident on the sample.

The Thorlabs PD that you are using will have a certain responsivity and gain, and, your beam splitter will be 90:10 ± 1-2 %;

it is easiest to measure power incident on the sample directly with a power meter and compare voltage on your photo detector  for a few different power settings. Make an elog of this.

Separate verbose elogs are good, as soon as you take the data post something. Also be verbose, include model numbers of things like photo detectors, lasers, lenses, oscilloscopes etc, this makes posts searchable: more information is better.

For beam dumping from chopper and other optics, maybe see if you can fit aluminum beam dumps panels to provide maximum coverage.

Now that you have a camera a nice side project would be to get the full 40 mW of your laser and have a look how it scatters of different beam dumping materials.

I've bought some black foil from Thorlabs, some brand new razor blade dumps, black glass dumps and anodized aluminum panels. I have a feeling they not as black as you'd think at wavelengths that matter.

That would be a one day project to make up an imaging lens system for the camera and shine some light on some black stuff. A detailed elog entry of course.

With the data, we're going to need to find something that lets you get files that you can plot in Matlab or python.  You do see photo screen shots often in the elogs, but there is a strong preference for logging the data and plotting it nicely.

That way you can also characterize the noise. Maybe you would also like to measure the dark noise of the detector.  I can show you how to use the SR785 to do this. (Another thing for your todo list).

The schematic is good, but it would be nice to include dimensions and part model numbers.  There are number of different Thorlabs detectors for instance.

Sorry, this is a lot of stuff. But easier to respond on elog altogether.

I noticed that the sample isn't centered along the axis of rotation, how do you think this well affect the measurement? Is there any way to mitigate this?

Good news on the Rasberry Pi, if you're able to get a python package up and running to activate certain pins then maybe we can work out how to

make a buffering/conditioning circuit that will trigger the camera properly from a digital output signal. I've ordered another 16 Gb SD card, but the order is

taking forever in shipping, it should be here in a day or two. Let me know if you need access to Solidworks or other cad stuff; we have a windows box that you can

get a username for and work over screen forwarding.  Otherwise onshape is a good free solution for drawing things.

Good work.

2143   Fri Jul 21 09:52:57 2017 Amani GarvinDailyProgressScatterometerSet Up Changes

Set Up Changes Over the Past 2 weeks:

I built a new cable to connect the raspberry pi to the camera so that we have an external trigger.

Also drilled a hole in one of our rotation stages so that we can fit the motor inside of it, and drive it from the raspberry pi. There is another rotation stage that I took apart to see how it worked, ball bearings went everywhere but I think I got them all back in.

The transistor chip to drive the motor from the pi came in this week, so that should be running by today.

I changed the set up last week, so now the camera is rotating around the sample, instead of the sample mounted on an optics stage with the other optics. This will make motorizing the camera's rotation extremely easy.

When I ran the camera without the lense everything was in black/white and unfocused. The camera now has a lense with a 10cm focal length, an aperture, and a 10cm tube connected to it. I glued two tubes together since we needed a male/male connection between the camera and the lense. I need to play around with the camera settings and get that all together by today, so we have some initial images.

I have the code ready for the raspberry pi already, the only thing left to do is to set up a static ip address on it and connect the stepper motor.

2147   Mon Jul 24 11:31:41 2017 Amani GarvinDailyProgressScatterometerFirst Image, Need to Clean Things Up

So right now the camera is set up with a 10cm tube, a 10cm focal length coated lense, and an aperture.

I tried to mimic Aidan's experiment, and set up the camera 25 cm away from the sample, then taking 100 images with the laser on, and 100 with the laser off. I then averaged the light images, averaged the dark images, and subtracted them from each other.

Below is the averaged light image:

Below is the averaged dark image:

And this is our subtracted image (it's nasty):

I think what's happening here, is that the tube is causing a major loss in aperture controle, and the focal length on the lense is way too large for a short range image. This is probably causing some major distortions, and just giving a super noisy image. I'm going to look for a lense that has a shorter focal length, and do this a few times today until we get a better image.

Another note is that this is using the factory calibration file (NUC file). I tried to generate my own NUC file earlier last week. This was done by putting the cap on the camera and taking multiple dark shots, then shining the laser directly on the camera and taking multiple light shots. Wimby 3.3 has some script to generate a NUC file from those images, but it only led to the camera's view being completely orange. So I stuck with the factory settings. Seeing as though there's no real difference in the light/dark images in this report, I might try a different NUC file.

2150   Tue Jul 25 10:54:46 2017 Amani GarvinDailyProgressScatterometerFirst Image, Need to Clean Things Up

 Quote: So right now the camera is set up with a 10cm tube, a 10cm focal length coated lense, and an aperture.  I tried to mimic Aidan's experiment, and set up the camera 25 cm away from the sample, then taking 100 images with the laser on, and 100 with the laser off. I then averaged the light images, averaged the dark images, and subtracted them from each other.  Below is the averaged light image:   Below is the averaged dark image:     And this is our subtracted image (it's nasty): I think what's happening here, is that the tube is causing a major loss in aperture controle, and the focal length on the lense is way too large for a short range image. This is probably causing some major distortions, and just giving a super noisy image. I'm going to look for a lense that has a shorter focal length, and do this a few times today until we get a better image. Another note is that this is using the factory calibration file (NUC file). I tried to generate my own NUC file earlier last week. This was done by putting the cap on the camera and taking multiple dark shots, then shining the laser directly on the camera and taking multiple light shots. Wimby 3.3 has some script to generate a NUC file from those images, but it only led to the camera's view being completely orange. So I stuck with the factory settings. Seeing as though there's no real difference in the light/dark images in this report, I might try a different NUC file.

So 2 ways I'm trying to clean up this image right now:

1. A new lens system.

I would like to build a telecentric lens system. Right now I have two Newport lenses with focal lengthes of 23.31mm for 1550, with AR coatings for 1000-15000 nm. By placing an aperture at their cofocal lengths, I should be able to create a bi-telectric effect. However I can't find the correct tube length, or an aperture that will fit into a tube (and I don't think Andrew reaaaally wants me to saw one of the tubes in half). So I'm fine will just making a telecentric system for now, and wait for an adjustable aperture/tube to come in from Thorlabs.

Telecentric lens: Just put an aperture at the focal length of the lens

Basically all of the rays that hit the camera will now be parrallel with the optical axis.

2. Calibration of the Camera

I'm going to look into how the Wimby software calibrates its images before I try to do it myself, for now I'm going to stick with the factory calibration. Looking at Aidan's image, I'm guessing that's what he did so I don't want to mess with it too much.

2151   Wed Jul 26 09:48:12 2017 Amani GarvinDailyProgressScatterometerFirst Image, Need to Clean Things Up

Okay so I tried it again with the new lens setup, and you can ~almost~ see the silicon.

exposure time: 200,000us

# of images with laser on: 100

# of images with laser off: 100

subtracted image:

This, at least does not look so random, the light orange rectangle in the center corresponds with the silicon block. I wrote a code that smooths the image

So I think this would benefit from calibration. I talked with Jigyasa at the 40m yesterday, and she showed me how she calibrated her camera using white matte paper. I'll write up another post explaining that, and the set up that I'll make for it today.

Quote:

 Quote: So right now the camera is set up with a 10cm tube, a 10cm focal length coated lense, and an aperture.  I tried to mimic Aidan's experiment, and set up the camera 25 cm away from the sample, then taking 100 images with the laser on, and 100 with the laser off. I then averaged the light images, averaged the dark images, and subtracted them from each other.  Below is the averaged light image:   Below is the averaged dark image:     And this is our subtracted image (it's nasty): I think what's happening here, is that the tube is causing a major loss in aperture controle, and the focal length on the lense is way too large for a short range image. This is probably causing some major distortions, and just giving a super noisy image. I'm going to look for a lense that has a shorter focal length, and do this a few times today until we get a better image. Another note is that this is using the factory calibration file (NUC file). I tried to generate my own NUC file earlier last week. This was done by putting the cap on the camera and taking multiple dark shots, then shining the laser directly on the camera and taking multiple light shots. Wimby 3.3 has some script to generate a NUC file from those images, but it only led to the camera's view being completely orange. So I stuck with the factory settings. Seeing as though there's no real difference in the light/dark images in this report, I might try a different NUC file.

So 2 ways I'm trying to clean up this image right now:

1. A new lens system.

I would like to build a telecentric lens system. Right now I have two Newport lenses with focal lengthes of 23.31mm for 1550, with AR coatings for 1000-15000 nm. By placing an aperture at their cofocal lengths, I should be able to create a bi-telectric effect. However I can't find the correct tube length, or an aperture that will fit into a tube (and I don't think Andrew reaaaally wants me to saw one of the tubes in half). So I'm fine will just making a telecentric system for now, and wait for an adjustable aperture/tube to come in from Thorlabs.

Telecentric lens: Just put an aperture at the focal length of the lens

Basically all of the rays that hit the camera will now be parrallel with the optical axis.

2. Calibration of the Camera

I'm going to look into how the Wimby software calibrates its images before I try to do it myself, for now I'm going to stick with the factory calibration. Looking at Aidan's image, I'm guessing that's what he did so I don't want to mess with it too much.

2152   Thu Jul 27 11:41:45 2017 Amani GarvinDailyProgressScatterometerCalibrating the Camera

Ok so I should have a calibration file done by today. The idea is to measure the surface scatter distribution from a known scatter element. White paper can be approximated as a lambertian scatter source, meaning that it's BRDF is a constant 1/pi sr^-1.

By definition:

$BRDF = P_s / P_i*\Omega *cos(\Theta _s)$

Where P is the measured scattered light, Pi is the incindent light on the sample, $\Omega$ is the solid angle, and $\theta$ is the angle the light is scattered through. There is a cosine corrected version of the BRDF in Stover that drops the cosine term, and accounts for bulk scatter.

Regardless, a lambertian scatter source is a constant independent of angle:

$BRDF = 1/\pi$

The calibration function can then be calculated using this constant:

$F_c = BRDF*cos(\theta_s )/ARB_c_a_m_e_r_a$

The ARB of the cameara is defined as the sum of the photon counts divided by the exposure time, over the incindent power, this basically gives a ration between the power recorded on the camera to the power incindent on the sample. :

$ARB_c_a_m_e_r_a = \Sigma_k V_k /\tau _e_x_p*P_i$

Which means the the calibration function is a ratio of the power of the scattered light and the light recorded by the camera. Once we have this function, we can multiply by the images we have in order to calibrate them.

I have already set up the paper to be used to measure the scatter. However I realize that I messed up the lens set up so I'm redoing that now, should be done with re-measurements in a bit. lots of thanks to Jigyasa.

2154   Wed Aug 2 14:50:03 2017 Amani GarvinDailyProgressScatterometerCalibrating the Camera

Results from camera calibration!

After some more direction from Rana I was able to record the BRDF of the white matte paper and compare that with the expected BRDF of a lambertian surface.

With a calibration constant Fc_array of

[  5.80173338e-13  -8.13104927e-13   8.88762806e-13  -6.81240016e-13

-6.89416046e-13   9.02894516e-13  -8.46491614e-13   4.95011517e-13]

I made the following plot of the data points, and it lines up nearly perfectly:

2155   Mon Aug 7 15:09:35 2017 ranaDailyProgressScatterometerCalibrating the Camera

Fonts too small - and theres no such thing as negative BRDF.

2156   Tue Aug 8 11:09:04 2017 Amani GarvinDailyProgressScatterometerCalibrating the Camera

This calibration was done using the setup constructed above, and replacing the sample with a white piece of paper. Following the procedure above resulted in a calibration constant of:

F_c = 3.73*10^{-12}  Watt*sec*counts^{-1}*str^{-1}

In the two images above, we have the normalized ARB of the camera plotted against the cosine function, and the BRDF of the sample plotted against an ideal Lambertian BRDF. From the first graph, we see that the ARB falls off along cosine theta as expected. From the second graph we can see that there is a small constant offset between the measured BRDF and the ideal Lambertian BRDF. This is due to the assumption that the reflectivity of white paper is 1. However, typical reflectivity constants of white paper are closer to .8. We can recalculate our calibration constant, using a recorded value of paper reflectivity: .8.

F_c = 2.99*10^{-12} Watt*sec*counts^{-1}*str^{-1}

2157   Tue Aug 8 11:12:27 2017 Amani GarvinDailyProgressScatterometerCalibrating the Camera

Finally got an image of the beam through the sample. I thought I had it before, but it was actually the beam reflected by the surface of the scatter. So far the beam through the sample has been imaged. This was done by summing up 100 images of the sample at an exposure of 2000$$\mu s$$, and subtracting 100 dark images of the sample.

One can see a small scatter feature in the silicon along the laser's path at (400,200). One can also see the reflection of the laser beam going in and out of the edges of the silicon sample. The red background is due to an error in rounding 0 and the max. The signal to noise ratio of the scatter feature here is about 90:40 counts.

Attachment 1: bkgsub_beam.png
2158   Tue Aug 8 16:27:29 2017 Amani GarvinDailyProgressScatterometerWhat Was Though to be the Laser Is Actually Backscatter

I thought that I was imaging the beam here, but if you rotate it a bit you can see that this is coming out of reflection off of the back image. If you take a laser card and look at the reflected beam, you see that there are actually 2 one reflected off of the front surface and one coming off of the back surface. Going straight through the beam gives a dark image, since it will be coming in normal to the surface. We can see this in the 3rd image below.

Attachment 1: image_56.png
Attachment 2: image_14.png
Attachment 3: beam_0_7.png
2160   Thu Aug 10 18:32:51 2017 Amani GarvinDailyProgressScatterometerImages of Beam through Silicon

.tif files, 16bit

Each image is at a different exposure time, naming convention goes: exposureTimeus_0.tif

Attachment 1: zipped_images_of_beam_through_silicon.zip
2161   Mon Aug 14 00:10:37 2017 Amani GarvinDailyProgressScatterometerImages of Beam through Silicon

I worked on adapting the HDR code to use tiff images, which store 16 bit pixel values, also using matplotlib to view those images.

Below is an image of the beam going through the silicon at the camera's highest exposure time: 100,000 us. In the code plot_tiff.py, I convert pixel space to detector space, and counts to Joules/str. In the image you can see two splotches higher than the background, those are the beam going in and out through the sample.

I also created an HDR image with exposure times: 2000, 4000, 8000, 10000, 20000, 100000 us. The signal looks a bit clearer, some background subtraction might be needed. Also still can't see the laser inside of the silicon.

 Quote: .tif files, 16bit   Each image is at a different exposure time, naming convention goes: exposureTimeus_0.tif

Attachment 1: highest_exposure.png
Attachment 2: hdr_aug13.png
2162   Mon Aug 14 09:22:09 2017 Amani GarvinDailyProgressScatterometerImages of Beam through Silicon

The highest exposure time on the camera is 200ms, I reran all of the sum_images scripts I had to use the tiff images with it. The first image is a background subtracted image of the beam through the sample. The second image is the HDR code run with all subtracted background images at all of the exposure times up to 200ms. The first image is obviously less saturated than the HDR image, with a higher signal to noise ratio.

Quote:

I worked on adapting the HDR code to use tiff images, which store 16 bit pixel values, also using matplotlib to view those images.

Below is an image of the beam going through the silicon at the camera's highest exposure time: 100,000 us. In the code plot_tiff.py, I convert pixel space to detector space, and counts to Joules/str. In the image you can see two splotches higher than the background, those are the beam going in and out through the sample.

I also created an HDR image with exposure times: 2000, 4000, 8000, 10000, 20000, 100000 us. The signal looks a bit clearer, some background subtraction might be needed. Also still can't see the laser inside of the silicon.

 Quote: .tif files, 16bit   Each image is at a different exposure time, naming convention goes: exposureTimeus_0.tif

Attachment 1: 200ms_exposure_subtracted.png
Attachment 2: hdrim_subtractedimages.png
2163   Mon Aug 14 12:29:54 2017 Amani GarvinDailyProgressScatterometerImage of Scatter in Silicon Sample

I think I've finally imaged scatter in the silicon sample.

This image was taken as a tiff with the Wimby camera, with an exposure time of 200ms, and all of the roomlights off. The camera is looking at the sample from an angle, so you can see the beam going through the back of the sample. I first summed 100 images, and then subtracted the sum of 100 background images.The background image was taken by just turning the laser off. Background subtraction was able to get rid of hot pixels.

On the side you see 2 bright spots, they are in a white box which I drew on the image. You can tell that these are intrinsic to the sample and not just noise, I repeated the same process at 5 different angles, 3 are shown below. Near a scattered angle of 90 degrees you can't see the scatter anymore.

Attachment 1: beam_aug14_0.png
Attachment 2: beam_aug14_1.png
Attachment 3: beam_aug14_2.png
2164   Mon Aug 14 16:56:54 2017 Amani GarvinDailyProgressScatterometerImage of Scatter in Silicon Sample

Images that created this image:

folders 1-5 : each contain 100 tif images of the sample from 5 different angles

folder dark: containt 100 dark images of the sample with the laser off

folder outputs: graphs of the outputted background subtracted files

 Quote: I think I've finally imaged scatter in the silicon sample.  This image was taken as a tiff with the Wimby camera, with an exposure time of 200ms, and all of the roomlights off. The camera is looking at the sample from an angle, so you can see the beam going through the back of the sample. I first summed 100 images, and then subtracted the sum of 100 background images.The background image was taken by just turning the laser off. Background subtraction was able to get rid of hot pixels.    On the side you see 2 bright spots, they are in a white box which I drew on the image. You can tell that these are intrinsic to the sample and not just noise, I repeated the same process at 5 different angles, 3 are shown below. Near a scattered angle of 90 degrees you can't see the scatter anymore.

Attachment 1: 1.zip
Attachment 2: 2.zip
Attachment 3: 3.zip
Attachment 4: 4.zip
Attachment 5: 5.zip
Attachment 6: dark.zip
2165   Tue Aug 15 16:40:46 2017 Amani GarvinDailyProgressScatterometerImage of Scatter in Silicon Sample

So this is an image of the silicon with my iphone camera from about the same angle that the camera was viewing it.

 Quote: I think I've finally imaged scatter in the silicon sample.  This image was taken as a tiff with the Wimby camera, with an exposure time of 200ms, and all of the roomlights off. The camera is looking at the sample from an angle, so you can see the beam going through the back of the sample. I first summed 100 images, and then subtracted the sum of 100 background images.The background image was taken by just turning the laser off. Background subtraction was able to get rid of hot pixels.    On the side you see 2 bright spots, they are in a white box which I drew on the image. You can tell that these are intrinsic to the sample and not just noise, I repeated the same process at 5 different angles, 3 are shown below. Near a scattered angle of 90 degrees you can't see the scatter anymore.

Attachment 1: IMG_2158.JPG
2166   Tue Aug 15 20:34:40 2017 Amani GarvinDailyProgressScatterometerBack of the Envelope Calculation

Assuming Rayleigh Scattering (which is a rough approximation), I calculated how much scatter would come from SiO2.

n = 1.431, d = 100nm

The rayleigh cross section is 2.36*10^-18 m^2

For a number density of about 10 si02 scatter sites/ volume of silicon, N = 1.736 * 10^5 cm^-3

N*cross section = amount of light scatted per distance traveled

That's 4.09*10^-15 ammount of light scattered per centimeter. The distance between the silicon and the lens is 9cm

Over 9cm the intensity of light recorded is 1.87*10^-13 Watts.

Our calibration constant is 2.99 *10^-12 counts/m^2/str.

This means that for a scatter source of this size, index of refraction, and at 1550, the camera will record less than 1/10th of a count.

Moving Forward:

I will get a signal before I leave Saturday morning! It will happen!

I'm going to play around with the distance between the lens and the silicon, try to really zoom in on the scatter.  If that doesn't work, maybe put a larger lens in front of it. I don't know, I'll do anything. I'm desperate. :D

Attachment 1: Screen_Shot_2017-08-15_at_20.20.51.png
2167   Wed Aug 16 10:16:25 2017 Amani GarvinDailyProgressScatterometerVarying the Distance Between Camera and Silicon

So Rana and I talked about moving the camera closer to the Silicon to try and observe scatter. I varied the distance by 1cm increments, refocused the camera, keeping the camera's angle at 30 degrees from the normal. These images are being taken from the same angle as the image I uploaded yesterday in the visible. I will attach the zipped folders of the raw images in another elog. These subtracted images use the summed dark image file that is attached here, and are a result of 100 images at that distance being summed, and the dark image being subtracted from it. There seems to be some over subtracting here, since there are values less than zero. The dark image was taken at the Silicon with the laser turned off.

Attachment 1: 7cm_from_Silicon.tif
Attachment 2: 8cm_from_Silicon.tif
Attachment 3: 9cm_from_Silicon.tif
Attachment 4: 10cm_from_Silicon.tif
Attachment 5: 11cm_from_Silicon.tif
Attachment 6: 12cm_from_Silicon.tif
Attachment 7: 13cm_from_Silicon.tif
Attachment 8: 14cm_from_Silicon.tif
Attachment 9: 15cm_from_Silicon.tif
Attachment 10: Dark_Image.tif
2168   Wed Aug 16 19:04:47 2017 Amani GarvinDailyProgressScatterometerImage of Beam in Silicon

So I talked to Aidan this morning!

So I took the original image of the Silicon, 16.5cm away from it, 200ms exposure. I took 100 images with the laser on, and 100 with the laser off. I then summed the "laser on" images and the "laser off" imags. I subtracted the laser off images from the laser on images. The background subtraction code now accounts for oversubtraction, so any oversubtracted pixels are set to zero. This produced the first image.

I then made a graph that plots the sum of each row over the y-axis, to see where the peak counts were. This is the first plot. This showed me that the laser was between pixel space 250 and 320. I then summed over the x-axis the laser space. The edges gave a high pixel count of over 200, while there was a lower distribution between 20-100 counts. I then rescaled the colormap to show between 0 and 100 counts, multiplied by the calibration factor, and that gives us the image of the laser through the sample below.

The beam is around 1.8*10^-10 W/str, which is a few factors off what I calculated yesterday. I will look into that...

Attachment 1: 200ms_Beam_Through_Sample.tif
Attachment 2: y_norm_axis_counts.png
Attachment 3: x_axis_counts.png
Attachment 4: LASERBEAM_calibrated.tif
2187   Wed Jan 3 20:20:07 2018 awadeDailyProgressWOPOReboot WOPO

## Laser restarted + 1064 for Shotnoise + SQZ measurment

I've restarted the Diabolo and am checking the alignment into fibers. The current configuration coming out of the WOPO breadboard is a fiber 50:50 beam splitter followed by two matched F240APC-1064 nm fiber collimators.  There is a HT532HR1064 dichroic mirrors in each of the split arms remove any remaining residual green.  The plan is to use a single NF1811 in one arm to see if we can see SQZ out at RF.  It will be lossy and susceptible to RIN, but we will be measuring at very high frequency.

Power of 1064 nm after the power-control PBS is 3.12 mW, at the other end of the fiber I am seeing 300 uW.  At the output of the HD fiber colimators there is an even split of about 148 uW: about what we should expect. I will try to check the alignment tomorrow and see if I can identify shot noise on the NF1811 above the dark noise. I haven't don the calculations, will check these number tonight.

---

## Temperature control WOPO

I also tracked down the Newport 3040 temperature controller (found in the PSL lab).  I've reattached this to the WOPO butterfly mount and am able to get a temperature readout from the 10kΩ thermistor with a 10 µA test current (this should deliver 0.1V to the NP3040 ADC). There is an option for 100 µA excitation of the sensor (have used this in the past), but I figured less current means less self heating. Not sure what the situation is with S/N inside the box, its an expensive mystery.

Settings on the Newport 3040 are basically the same as before, see ATF:2124,  for good measure here are the full settings list:

Newport 3040 settings WOPO
Setting Value [units]
Sense type 10 [µA]
Mode Const T
Gain 2 Slow
Limit Ite 0.65 [A]
Tol time 1.0 [s]
Tol Temp 0.1 [C]
Limit Tl 18.00 [C]
Limit Th 70 [C]
C1 1.0445e-3
C2 2.5075e-4
C3 0
Ts (set point) 61.93 [C]

The NP3040 does give you explicit gain levels for P and I terms in the feedback loop real values. It just has mystery numbers 0.2, 0.6, 1, 2, 3, 5, 6, 10...300 with either "fast" or "slow". I used 2 Fast, and then gain 10 Fast.  Integration doesn't seem to be aggressive enough as its not reaching the set point.  Any more proportional gain and it overshoots and hits the shutdown rail on loop startup. A current of 0.4 A is needed to reach a set point of 61.93 C, so there is plenty of actuation headroom.  Its not an ideal PID loop but I'll leave this for now, it is enough to just move the set point a little higher.

---

## LO phase scanning

There is a 1064 nm mirror mounted on a PZT just before coupling into the fiber. Wires have been soldered to a BNC and solidly mounted to a L-bracket on the table. I have obtained a thorlabs HV driver that can do upto 150 V from 10 V .  There is an adjustable range with a switch on the back (75V, 100V or 150V), I need to check the voltage range allowable for this PZT before powering up.  The plan is to scan 1064 nm phase over a few wavelengths to scan the detected SQZ phase. About 100V will do it.

Something to check is the impact of banana shapped motion of the mirror+PZT, in the past this changed power through modecleaners by misaligning with the voltage scan. However, that was on very long PZT stacks. Might expect a similar effect coupling into fiber, its just something to calibrate out in the baseline shotnoise curve as a function of scan voltage.

---

I haven't checked the 532 nm coupling efficiency or made a shot noise measurement.  I have a  NF1811 + power supply and will try to look at this tomorrow with a spectrum analyzer.

2188   Wed Jan 10 17:03:55 2018 awadeDailyProgressWOPOWOPO some shot noise numbers

Summary, here are some numbers relating to requirements for for the WOPO squeezing detection:

In order to obtain some coherent light inducing some measurable shot noise, 1064 nm light is coupled in to fiber and injected into one of the legs of the fiber 50:50 beam splitter; the other leg of the 50:50 splitter is to be connected to the WOPO directly. If we can see shot noise then injecting a 1 dB squeezed state with 50% loss should give use a roughly 0.47 dB of squeezing. The variance of the prepared state will go as

$V^\textrm{(out)} = \eta_\textrm{total} V^\textrm{(in)}+(1-\eta_\textrm{total})$

where $\inline \dpi{100} \eta_\textrm{total} = \prod_i \eta_i$ is the total loss from the point of amplification. Computing dB of squeezing is then found by normalizing the squeezing the the LO shot noise level, taking 10*log10(V_in/V_shot).

Initially I will try to see squeezing with a single detector out of one of the legs of the fiber beam splitter.  This means a 50% hit in terms of loss and also that the detector is susceptible to intensity noise of the 1064 nm local oscillator (although we might expect this to be much low in the >1MHz range).   With about 1 mW of light on an ideal (eta=1, lossless) photo diode we should we photocurrent of order

$i_\textrm{DC} = \frac{Pe^\text{-}\lambda}{hc} = 0.856 P \approx 0.856\textrm{ mA}$

The shot noise current  at this power is given by:

$i_\textrm{sn} = \sqrt{2e^\text{-} i_\textrm{DC}} = e^\text{-} \sqrt{\frac{2\lambda}{hc}P} = 0.52 \sqrt{P} \textrm{ nA/}\sqrt{\textrm{Hz}} \approx 16.6 \textrm{ pA/}\sqrt{\textrm{Hz}}$

We want to look at the quantum noise at around 1 MHz and for it to be above all of the typical noise sources with reasonable margin (i.e. 6 to 10 dB clearance).  A New Focus 1811 detector is an OK choice as its quoted dark noise, or NEP, is 2.5 pW/sqrtHz. This is given for peak responsivity 1.05 A/W @ 1550 nm.  Scaling to equivalent NEP at 1064 nm amounts to rescaling NEP by the relative responsivity ratio

$NEP_\textrm{@1064 nm} = \textrm{NEP}_\textrm{1550nm}\frac{\mathcal{R}_\textrm{1550nm}}{\mathcal R_\textrm{1064nm}} = 2.5 \textrm{ pW/}\sqrt{\textrm{Hz}} \frac{1.05 \textrm{A/W}}{0.80\textrm{A/W}} \approx 3.3 \textrm{ pW/}\sqrt{\textrm{Hz}}$

The equivalent current is 2.6 pA/sqrtHz. Which gives a shot noise clearance above PD dark noise of 8.0 dB.  For order of 10 dB shot noise clearance we would need 2.5 mW: this is still within a factor of two of the maximum power of the detector.

At the moment I can't find at spare working NF1811. Here are some options that don't work (for the record):

A New Focus 1611 is not such a good choice. Peak responsivity NEP is 20 pW/sqrtHz; gain is also lower 700V/A. Here the current dark noise for the given responsivity of 1.05 A/W is is 21 pA/sqrtHz.  To get shot noise equivalent to detector dark noise we would need 1.48 mW. To get to 10 dB clearance I would need 148 mW. So no good here.

The Thorlabs PDA10CF has a NEP of 1.2e-11 W/sqrtHz @ 1.04 A/W.  At this current noise of 12.5 pA/sqrtHz we would need 58 mW for 10 dB clearance.

Maybe...

Looking at Zach's M2 ISS board (ATF:1888) it looks like it will clear the dark noise with 10 dB clearance, but nobody can tell me where that already built unit is or the spare PCB.  From what I know, the main issue with ordering more is sorting out whether using a MAX333A in place of the MAX333 will have sufficiently low through resistance (the MAX333A is about 20 Ω, compaired to the 100Ω MAX333 that Zach used in the initial test model.  There was also an issue with the size of some of the inductors compared to the design footprint, not sure if that is resolved.  Its also not RF.

---

### Coupling into fibers

At the moment with the best alignment (30 minutes effort) the efficiency of coupling into the fibers is 75% for 1064 nm and 50 % for 532 nm.  The 50:50 fiber beam splitter appears to have close to 1-2% loss.  Its rated up to 1W so we can easily get 1-10 mW out the other end.

Some more effort needs to be put into the 532 nm in coupling.  We will need order 10s mW.  I just don't want to burn the ends by just jamming a bunch of power in.  Need to check the cleanness of fiber ends with a microscope before upping the power: it seems this is how the last fibers were damaged.

ELOG V3.1.3-