40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 3 of 56  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  120   Thu Apr 23 15:25:35 2009 DmassComputingDAQATF Screens/DAQ up and running.

I made screens for the lab from the atf.mdl file which is in the /cvs/cds/advLigo/src/epics/simLink/ directory

They live in /cvs/cds/caltech/medm/c2/atf/

C2ATF_MASTER has links to what is there.

We have two 8 in ---> 8 out filtered matrixed subsystems.

 

Pics to be included later.

Enjoy.

 

P.S. The DAQ is now writing at 16 kHz. If you want data at a different speed, there may be funniness that needs to happen with the /frames/full directory.

  121   Sat Apr 25 12:11:54 2009 ranaComputingDAQATF Screens/DAQ up and running.
Cool. For properness all of the medm screens should be in the /cvs/cds/caltech/medm/ directory. We should
also pull down the medm/c1/ directory from the 40m SVN, since its always useful for copy-paste
operations. And all of the FE code (models, etc.) should be in the caltech/target/ dir.

How about second-trend and minute-trend? How far is the lookback? Do we need a bigger disk?
  2092   Wed Apr 26 18:40:30 2017 ranaComputingGeneralATF Wiki updated

to 2017-02-19b "Frusterick Manners" +CAPTCHA +Wrap +Upgrade +VideoShare +Gallery

  1553   Tue Oct 18 16:38:27 2011 ZachMiscstuff happensATF floppy drive is missing

 Please bring it back---sharing is caring.

  1643   Sun Mar 11 15:40:54 2012 ZachMiscOpticsATF lens inventory

I appraised the lab's lens collection, and here is what I found in mounted lenses. There are more in the lens kit, but I didn't look at those as they were beyond my laziness horizon.

 

ATF mounted lenses
P/N fnom (mm) f @ 1064nm (mm)
KBX076 (x2) 200 205.6
KPX097 125 128.5
KPX085 62.9 64.7
PLCX-25.4-25.8 (x2) 50.9 50.9
KPX100 (x3) 150 154.2
KPX093 (wrong P/N?) 175 179.9
KBX073 175 179.9
KPX115 400 411.2
KBX052 50.2 51.6
KPX109 250 257
PLCX-25.4-51.5 (x2) 101.7 101.7
KPX106 200 205.6
PLCX-25.4-18.0 35.5 35.5
LB1811-C 35 36 (inferred)
"f = 150" 150 154.2 (inferred)

 

Hmm.. I probably should have done that in some sort of sensible order...

  427   Sun Nov 8 14:10:06 2009 FrankLab InfrastructureGeneralATF particle counter - first data available

here is the data for the last 11 days:

  • measurements were taken every 5min for 10sec
  • data is calibrated to particles per ft^3
  • particle sizes shown in the legend are micrometers
  • location: second optical table, between both lasers

AdhikariLab_data_091107_104657_new.jpg

 

  473   Tue Dec 8 15:33:49 2009 FrankLab InfrastructureGeneralATF particle counts

i finally found some time to analyze the data i took from the particle counter in the ATF some time ago. I still have the problem that tha data i get from the counter via the RS232 interface has some corrupt entries (data transmission errors) which do not change if i change the speed to somewhere between 300 or 19200. I have no idea where it comes from. i tried different cable length (2ft to 25ft as well). So to plot the data i have to manually edit the (half megabyte) textfile in order to fix these errors before i can plot it. I hope we can soon switch to the automated readout of this data....

Here are the results:

AdhikariLab_data_191107.jpg

  74   Fri Aug 1 15:06:11 2008 DmassComputingCDSATF system
I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf
  75   Tue Aug 5 15:23:38 2008 DmassComputingCDSATF system

Quote:
I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf


The rm /cvs... command should be replaced by make uninstall-daq-atf. It does the removal and slightly more.
  76   Mon Aug 11 14:15:57 2008 DmassComputingCDSATF system

Quote:
I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf


I talked to Alex, and he told me something about "your frames file is full, let me empty it and call you back," and he did so.

I did a reinstall of the daq
make unistall-daq-oms
and
make install-daq-oms

then I edited the .ini files with the channel names I wanted information about in

/cvs/cds/caltech/chans/daq/
C2OMS.ini is the file with the information I want in it.
oms.ini is the file which daqconfig interfaces with.

I edited the files via the daqconfig, and then overwrote the C2OMS.ini file with it, then data seemed to be recording and I could access it via dataviewer.

One concern/piece of information:
Apparently at some point they decided to change the convention on file suffixes for channel names. C2OMS.ini has a *_32768 tacked onto the end of
the channel name upon generation by the make scripts, whereas the oms.ini file has a *_DAQ in its place. This seemed to be the cause for some
of the noncooperation between the various sytems. Daqconfig likes the *_DAQ suffix, and this seems to jive with the data now writing, so we shall
go with that.
  1087   Wed Sep 29 11:56:04 2010 AlastairComputingGeneralATF wiki

I've changed the template for the wiki and it now has most of the structure there.  I haven't put up the DAQ stuff yet.

The new template has some weird issues with the sidebar where it is able to go down through the namespace structure but doesn't want to come all the way back up to the root namespace even if you specify the page location explicitly, for example using :home.  For this reason we should only create pages that are inside the namespaces that we are using higher up.

I have set it up with everything inside the namespace 'main' which then contains all the sub-namespaces.  If you just keep to this convention then the sidebar navigation works just fine.  The directory structure is currently like this:

main

    experiments

        ring_gyro

        doubling_noise

        fiber_stabilization

    resources

        atf_internals

            lab_cleaning

            SOPs

            the_lab

            how_to

                computing

There's a couple of other things I'd like to fix with it: the main page has a lot of 'edit' boxes for reasons I don't understand. Also I'm not sure we want the second sidebar box on the left.  The bottom trace doesn't seem to show the full backlink history, it just randomly changes sometimes rather than following the full path that you have navigated through, so we might just switch the trace off.

Other than that I'm pretty happy with the way the wiki works.  It seems to generate nice looking tables and is flexible enough in terms of how the headings look and the sidebar navigation seems nice.

  1088   Wed Sep 29 13:36:57 2010 AlastairComputingGeneralATF wiki

I got rid of the trace bar at the bottom, and I've solved the issue that caused the extra navigation bar at the side.  The 'edit' boxes that were appearing on the main page appear whenever you use more than one heading on a page.  I just moved everything on the first page into a table and that has got rid of those.

Other than that the wiki is now ready to be populated.  If anyone has any comments on the wiki send them my way - otherwise I will leave it as it is for people to use.

  2518   Wed Nov 11 16:09:22 2020 anchalSummaryECDLAUX wavelength finesee requirements in mariner - Added Excess Scatter Noise

An issue was raised with last calculation about the fact that our sensing of PDH signal isn't ideal and in the real world there is scattering, clipping extra adding excess noise in the PDH loop. This noise primarily comes by the intensity noise imparted on promptly reflected light from the cavity via various shaking optics etc on the table before it goes to the PDH reflection RF photodiode.

This noise's coupling to the PDH loop is identical to how shot noise of light couples into the PDH loop i.e.:

  • Intensity noise of light is converted into voltage oise by the PDH photo diode.
  • This is compared against the cavity finesse amplified real PDH error siganl at this stage.
  • Therefore, in frequency noise, the affect of this intensity noise is smaller for higher finesse cavities since cavity finesse only amplifies the PDH signal anf not the scattering noise.

Excess noise estimate

  • I used this measurement taken in 40m with Koji to estimate this noise.
  • This measurement contained a beatnote between IR coupled AUX light and the main laser IR pick-off when X-arm is locked to the main laser and AUX laser is locked to X-arm.
  • So this noise measurement is an upper bound on the total noise in AUX laser frequency when it is locked to the X-arm.
  • I compared this against the noise budget model for AUX PDH loop I have which uses the same control loop as the uPDH box used here.
  • I found a bulge of excess noise below 100 Hz and it seemed to go done as 1/f^2 there. I was reminded by a chat I had with Rana and another professor sometime last year when Rana mentioned scattering noise showing up as "Scatter shelf" looking something like this.
  • So I modeled excess noise as the difference between the noise budget and the measured noise with it extending after 100 Hz with the same roll off as in 10-100 Hz.

Calibration noise budget

  • I took the excess noise measured, converted it to W/rtHz by using current AUX PDH discriminant and photodiode gain, and normalized by the power (9.6mW) to get this noise in RIN/rtHz.
  • Then I assumed that the same RIN would be imparted in the Mariner AUX loop and calculated excess intensity noise at the PDH loop by multiplying the above number with assumed 10mW of incident power to get it in W/rtHz.
  • From here, I fed it to the same input as I feed the shot noise in the loop and calculated the effect in the overall noise budget.
  • For high bandwidth and gain PDH loops required for calibration, this kind of noise would dominate up to a kHz before getting taken over by the residual laser frequency noise.
  • I have again plotted cases for three choices of finesse/mirror transmission. If we used 99.95% reflectivity (1000 ppm transmission, finesse of 3140) we would be fine for most calibration lines except the one around 40 Hz. (assuming drive strength of 1e-13 m everywhere).
  • Otherwise, if possible, we should go for higher finesse. Case (c) plotted here (Page 3), shows that for 99.995% reflectivity (100 ppm transmission, finesse of 31415), we will be fine in all over the range with cavity pole dropping to 63 Hz. This would be really nice of course, if it is possible.
  • So we recommend HR coatings for 1418 nm in the Mariner to be 99.995% reflective (giving total power transmission of 100 ppm).
Attachment 1: AUX_Finesse_Study_With_ECDL.pdf
AUX_Finesse_Study_With_ECDL.pdf AUX_Finesse_Study_With_ECDL.pdf AUX_Finesse_Study_With_ECDL.pdf
  2515   Mon Nov 9 10:08:38 2020 anchalSummaryECDLAUX wavelength finesee requirements in mariner with 1418 nm ECDL (Preliminary)

I have a preliminary calculation to post here. This does not include noise sources from cavity fluctuations and main frequency noise. But it gives some idea about shot noise and frequency noise of AUX laser conttribution to the noise in calibration.


What's included?

  • I have put in measured PZT transfer function of ECDL at ANU upto 25 kHz. Above this point, they did not measure it so I couldn't make it artificially dirty. I just assumed 1/f roll off above (which is definitely incomplete picture).
  • I have included phase effects of cavity FSR in the loop by adding the resonance features as mentioned here.
  • I have added attempted resonance compensation for 1kHz and 2kHz features in the PZT after fitting the data with poles and zeros and iverting them.
  • 10mW of incident AUX light is assumed on the arm cavity.
  • Total 10 mW of combined power at 709 nm is assumed to fall on the beatnote. So AUX light would be frequency doubled for this beatnote.

What's left?

  • Need to add seismic noise and other measured excess noise that come from the cavity motion.
  • Need to add laser frequency noise of main laser, however, it must be small since it is locked to mode cleaner.
  • Need to add digital delay of Red Pitaya or whatever filter would be used for PZT resonance compensation.
  • Need to model PZT transfer function of ECDL above kHz properly. ANU replied that they can't measure it for higher frequencies due to lack of time.
  • Need to do time domain stability analysis. This I haven't been able to do as I have just been using python-controls package as black box to compute impulse and step responses of state space systems. When simply adding easured transfer function data, I couldn't create the state stpace representation for the system. I tried to fit multiple resonances above 2 kHz but couldn't really capture the magnitude of the response well. Maybe I can just assume higher harmonics of the 1kHz and 2kHz resonances?

Attachments:

  • Page 1 is the measured PZT transfer function fo 1900 nm ECDL from ANU along with the modeled 1/f roll off after 25 kHz.
  • Page 2 is the open loop transfer function of the AUX PDH loop for the three different finesse cases studies. Note that the blue curve is hidden beneate the other two curves. Before objections came, I know this is unreal and incomplete, but I have to start somewhere.
  • Page 3 is the calibration noise budget with different colors showing the three finesse cases.
    • This is also incomplete but we can takeaway what the shot noise contribution would look like and initiate a dialogue about the integration time chosen (which is 100s here), the SNR aim chosen (1000 here) and what drive strength would be good enough.
    • From notes of Craig and Gautum, I think we can drive the mirrors at 0.1pm ampltude in the calibration band. From my first and only calibration measurement in 40m, I could drive upto a pm without loosing lock in the cavities.
    • But that was a simple single arm lock and full ifo lock must be more sensitive. So is 0.1 pm drive strength good enough or do we want to aim lower?
Attachment 1: AUX_Finesse_Study_With_ECDL.pdf
AUX_Finesse_Study_With_ECDL.pdf AUX_Finesse_Study_With_ECDL.pdf AUX_Finesse_Study_With_ECDL.pdf
  230   Wed Aug 5 15:14:55 2009 DmassComputingCDSAWG and TP now up

I emailed Alex and:

 

Hi David,
looks like you have switched from running om1/om2 pair to running atf.
When you do that you have to alter testpoint.par file:


[controls@oms param]$ pwd
/cvs/cds/caltech/target/gds/

param
[controls@oms param]$ ls -alt testpoint.par
-rw-r--r-- 1 controls controls 330 Aug  5 08:52 testpoint.par

I changed om1 to atf there.

Testpoints are working now.
 
Test points and AWG are now up.

  2617   Sun Jul 25 21:45:46 2021 KojiSummaryCryo vacuum chamberAbout the radiation heat transfer model

The following radiation cooling model well explained the cooling curve of the test mass (until ~150K)

\dot{Q}=0.15 A\,\sigma (T_{\rm SH}^4-T_{\rm TM}^4)

where dQ/dt is the heat removed from the test mass, A is the surface area of the test mass, \sigma is the Stefan-Boltzmann constant, T_SH and T_TM are the temperatures of the surrounding shield and the test mass.

Can we extract any information from this "0.15"?


I borrowed "Cryogenic Heat Transfer (2nd Ed)" by Randall F. Barron and Gregory F. Nellis (2016) from the library.
P.442 Section 8.5 Radiant Exchange between Two Gray Surfaces can be expressed by Eq 8.44

\dot{Q} = F_e F_{1,2} \sigma A_1 (T_2^4-T_1^4)

where T_i is the temperature of objects 1 and 2. For us, OBJ1 is the test mass and OBJ2 is the shield. A1 is the surface area of A1. F_1,2 is the view factor and is unity if all the heat from the OBJ1 hits OBJ2. (It is the case for us.)

F_e is an emissivity factor.

The book explains some simple cases in P 443:

Case (a): If OBJ2 is much larger than OBJ1, F_e = e_1 where the e_i is the emissivity of OBJi. This means that the radiated heat from OBJ1 is absorbed or reflected by OBJ2. But this reflected heat does not come back to OBJ1. Therefore the radiative heat transfer does not depend on the emissivity of OBJ2.

Case (b): If OBJ1 and OBJ2 has the same area, \frac{1}{F_e} = \frac{1}{e_1} + \frac{1}{e_2} -1. The situation is symmetric and the emissivity factor is influenced by the worse emissivity between e1 and e2. (Understandable)

Case (c): For general surface are ratio,  \frac{1}{F_e} = \frac{1}{e_1} + \left(\frac{A_1}{A_2}\right)\left(\frac{1}{e_2} -1 \right ). OBJ2 receives the heat from OBJ1 and reradiates it. But only a part of the heat comes back to OBJ1. So the effect of e2 is diluted.

For our case, OBJ1 is the Si mass with DxH = 4in x 4in, while the shield is DxH = 444mm x 192mm. A1/A2 = 0.12.
We can solve this formula to be Fe=0.15. e1 = (0.147 e1)/(e2-0.0178).

Our inner shield has a matte aluminum surface and is expected to have an emissivity of ~0.07. This yields the emissivity of the Si test mass to be e1~0.2

How about the sensitivity of e1 on e2? d(e1)/ d(e2) = -0.95 (@e2=0.07).


Can Aquadag increase the radiative heat transfer?

Depending on the source, the emissivity of Aquadag varies from 0.5 to 1.
e.g. https://www.infrared-thermography.com/material-1.htm / https://www.mdpi.com/1996-1944/12/5/696/htm

  • Assuming Aquadag's emissivity is ~1
    • If only the test mass is painted, F_e increases from 0.15 to 0.39 (x2.6)
    • If the inner shield is also painted, F_e increases to 1, of course. (pure black body heat transfer)
    • If shield panels are placed near the test mass with the inner surface painted, again F_e is 1.
  • Assuming Aquadag's emissivity is ~0.5
    • If only the test mass is painted, F_e increases from 0.15 to 0.278
    • If the inner shield is also painted, F_e increases to 0.47.
    • If shield panels are placed near the test mass with the inner surface painted, F_e is 0.33 assuming the area ratio between the test mass and the shield panels to be unity.

It seems that painting Aquadag to the test mass is a fast, cheap, and good try.

  1489   Thu Aug 4 11:56:57 2011 Alastair & ZoeLaserGYROAccelerometer calibration

 We put the two accelerometers we are going to use on a shaker and calibrated them relative to each other.  Here is the time series with the two calibrated.

Attachment 1: accelerometer_calib.pdf
accelerometer_calib.pdf
  1490   Thu Aug 4 16:01:34 2011 ranaLaserGYROAccelerometer calibration

to get a high precision relative calibration you ought to do a huddle test like what Jenne does. And plot the residual instead of 2 lines on top of each other. You probably want to get the balance to be better than 0.1%.

  1492   Thu Aug 4 17:31:39 2011 AlastairLaserGYROAccelerometer calibration

No problem, I'll plot the residuals.  There is a small offset between them as well that we should be taking into account.

 

Quote:

to get a high precision relative calibration you ought to do a huddle test like what Jenne does. And plot the residual instead of 2 lines on top of each other. You probably want to get the balance to be better than 0.1%.

 

  1518   Fri Aug 12 12:13:38 2011 Alastair, Rana, ZoeLaserGYROAccelerometer calibration

 This is the measured data for the two accelerometers we are using (number 8 [serial no. C107774] and number 4 [serial no. C107766]).  The two accelerometers were mounted to a metal plate on top of a B&K shaker.  The TF was taken by sweeping the shaker with a spectrum analyser and measuring the output of number 8 / number 4.  They seem reasonably well behaved above ~10Hz.  We'll use this relative calibration for future measurements.  I've attached the calibration file for future use.

Attachment 1: accel_calib.jpg
accel_calib.jpg
Attachment 2: calib.mat
  1488   Wed Aug 3 15:34:56 2011 AlastairLaserGYROAccelerometer channels

I've hijacked channels 12 and 13 for the two accelerometers.  There are the PLL_ACT and PLL_ERR channels so data can be taken from

C2:ATF-GYRO_PLL_ACT_OUT

C2:ATF-GYRO_PLL_ERR_OUT

I've also added PLL_ERR_OUT to the frames, so I have done pkill daqd and hit 'DAQ reload' in MEDM.

EDIT: I've also hijacked channel 14 to use to acquire the waveform that is going into the shaker.  We'll use this to measure phase shifts.  The channel was already acquiring, but only at 256 so I have increased it to 32k and then done pkill daqd and 'DAQ reload' in medm.

  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.

YOU MUST SET A NEW ADMIN PASSWORD

  2211   Wed Jul 11 16:30:40 2018 Vinny W.Summary2micronLasersAcoustic and Thermal Sensitivity

I found some relevant work done on the discussion of acoustic and thermal sensitivity within a optic fiber. For reference, it's important to have an idea of the geometrics of the fiber. The core, cladding, and coating are 11 +/- 1 um , 125 +/- 1 um, and 245 +/- 10um in diameter, respectively. Though the cladding is pure silica, the coating is Ge-doped. ( http://www.thorlabs.com/drawings/65f0b20de1051938-7503B425-91B4-7335-B52672A2FD1F6447/SM2000-SpecSheet.pdf ). Additionally, the fiber's sensitivity to some pressure depends on its characteristic elastic coefficients ( Young's Modulus, E, and Poisson's Ratio, \sigma) and Pockels coefficients, P_{12} and P_{44} [1]. The elastic coefficients for fused silica can be found online but are also referenced below. 

Acoustic Sensitivity:
To have an idea of the approximate sensitivity we could expect, we can consider some preform silica cylinder that is undergoing a uniform pressure. Many of the references I found measured that pressure from variations of the relative phase change between two interferometer arms- one static and the other undergoing a pressure difference relative to it. The optical phase retardation per unit of pressure (in dyne/cm^2) can be expressed as:

\frac{\Delta\phi}{\phi} = \frac{(1-2\sigma)}{E}[\frac{n^2}{2}(3P_{12}+2P_{44})-1]

This comes out to be approximately  -1.23*10^{-14}${dyn}/{cm^2}$ .

Obviously there's more to the picture than just that. We need to consider the differences in refractives indices and and elastic coefficients between the different materials present in our optic fiber, as well as account for the radial and axial displacements in the "cylinder" caused by some pressure. The approach in reference [2] consideres a two layer cylinder, and assumes that the center is of homogenous material much like the example above. We can place the optic fiber in a cylindrical coordinate system as shown below:

(Insert crudely made cylinder coordinate system here)

Following reference [2], we'll assume that the axial stress at the very ends of the fiber is zero. ( \sigma _{22} = 0 at z = \pm L, where 2L is the full length of the fiber). This is referred to as the radial model, a form of boundary condition. Since axial symmetry is also assumed, the stresses and strains will be functions of r and z. For a single material solid cylinder, the solutions for the differential equations for the axial/radial displacements are expressed as products the trigonometric and modified Bessel functions. When we consider a multilayered cylinder, the general solution will be the the series expansion of those products, and their coefficients are determined by the boundary conditions.

It was shown both experimentally and theoretically that a 2D model of the above scenario (i.e. a plane strain ) gives nearly identical results as the 3D model, and involves much less calculation power. The reference goes in-depth at how the following equation was is derived, but to keep this concise, the average induced fractional phase change can be expressed as:

\frac{\Delta \phi}{\phi}= e_z-\frac{1}{2}n^2[2e_r(p_{11}-p_{44})+e_z(p_{11}-2p_{44})]

where e_z,e_r are the axial and radial strain, respectively. When the strains are a function of position along the axis of the fiber, we would need to average of its length:

\frac{\Delta \phi}{\phi} = \frac{1}{2L}[\int_{-L}^{+L}e_zdz-\frac{n^2}{2}[2(p_{11}-p_{44})\int_{-L}^{+L}e_rdz+(p_{11}-2p_{44}\int_{-L}^{+L}e_zdz)]]

 

[Work in progress. -Vinny (7/19/18)]

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

MATLAB license had expired on QIL-WS2 so I had to activate it again.

  1582   Tue Dec 20 14:52:05 2011 ZachComputingComputingAdded 'sitemap' alias to fb0

Somehow it wasn't there.

...aaand for some reason it doesn't work. Loads screens fine, but monitors are all blank instead of containing numbers. Odd.

  194   Thu Jul 23 07:33:41 2009 AidanComputingCDSAdded C2 MEDM screens to 40m SVN.

 

I've added our medm screens from the ATF to the 40m SVN. They can be found in 

https://nodus.ligo.caltech.edu:30889/svn/trunk/medm/c2/atf/

  1389   Tue Apr 12 22:47:38 2011 AidanComputingDAQAdded TCS channels and restarted daqd

http://nodus.ligo.caltech.edu:8080/TCS_Lab/135

  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
TCS-AWC_port_fwd.jpg
  449   Tue Nov 17 16:27:17 2009 AidanLaserFiberAdded cylindrical lenses to fiber transmission

Quote:

Here is the measured beam propagation from the fiber side of the fiber. The ellipticity is coming from the AOM.

 I added a couple of cylindrical lenses after the partial retro-reflector on the far side of the fiber. They are placed at the point +/-5mm where the horizontal and vertical beam sizes are the same. The horizontal beam is diverging faster than the vertical. Therefore I used an f=150mm lens in the horizontal and f =250mm lens in the vertical to give the beams approximately the same curvatures at the point where they have the same beam size - hence making the beam roughly circular.

I measured the beam propagation after these lenses. The results are shown below. The beam is now mostly circular.

Attachment 1: 2009_11_17-beam_propagation_from_PRR_post_cylindrical.pdf
2009_11_17-beam_propagation_from_PRR_post_cylindrical.pdf
  1101   Tue Oct 5 12:53:26 2010 AidanComputingGeneralAdded link to the users directory in the root directory on ws1

/users links to /cvs/users

(syntax to do this was "ln -s /cvs/users /users")

  658   Tue Mar 9 21:13:24 2010 DmassLaserISSAdding ISS

There are about 17 mW coming through the PMC. I changed around the optical path behind the PMC, adding a waveplate and a PBS.

I am going to use a Thorlabs PDA10CS for the ISS, I checked and it has enough SNR to get the 2 decades I want up to 200 Hz. (It is actually ~10^3 at 100 mHz to 100 Hz)

Current laser RIN after the PMC: 6e-4 at 1 Hz

  659   Tue Mar 9 23:55:29 2010 DmassLaserISSAdding ISS

Quote:

There are about 17 mW coming through the PMC. I changed around the optical path behind the PMC, adding a waveplate and a PBS.

I am going to use a Thorlabs PDA10CS for the ISS, I checked and it has enough SNR to get the 2 decades I want up to 200 Hz. (It is actually ~10^3 at 100 mHz to 100 Hz)

Current laser RIN after the PMC: 6e-4 at 1 Hz

 

I measured the transfer function of the NEOS 21080-AM with the HP35670A (using a swept sine with a 0.8V DC offset like I will be using at ISS operation. It looks flat out to 50 kHz, which is what I wanted to confirm.

For the measurement, I used a ZSC-2-1W and a ZAD-1-1. I mixed the RF output of the NEOS AOM driver down with itself using a path length difference in the cables equal to a 180 degree phase shift, and appropriate attenuation levels (6.5 dBm LO and .5 dBm RF). I put a 20 dB attentuator before the splitter so that I was onbly sending about 10 mW through it (it wants no more than 125 mW).

I used the HP 4395 to establish my RF levels coming out of the AOM driver.

As well as having a DC reference for the PD signal, I also need a DC offset into my AOM driver (for several reasons, not the least of which is that the power amplifier is saturated, so I need to dump an appreciable amount of seed power before I see an intensity modulation in the output beam. I have been trying to look up the Spec sheet for the NEOS driver, but can only find bare bones documents from G&H (googling NEOS 21080-2AM). I am trying to see what the input impedance is, so that I know what my options are for adding in a DC offset (whether I can use any op amp to do this, or if I need to choose something which can actually push current).

Currently, all I have found is something from G&H which says that the input impedance is 50 Ohms for +/- 1 V, but this seems wrong. That's a lot of power to be sucking from my AM input...Dmass is now confused.

 

Below is a schematic of what I plan on doing in lab, replacing the SR560 with a real op amp when I find a loop shape that makes me happy. The op amp to NEOS connection is what I am questioning above

Attachment 1: ISS.png
ISS.png
  660   Wed Mar 10 12:52:10 2010 DmassLaserISSAdding ISS

I tried to tune the alignment of the AOM to get better modulation in my AOM...

I used a function generator (with 50 Ohm output) to make a 10 Hz 1V sine wave (0.5 V + 0.5V sin...), and tried to change the angle of the angle of the AOM w.r.t. the beam to maximize this output. The best I got for 1V (which is equal to 1.5 W if I did my tuning of the NEOS driver correctly) is a decrease of

(3.76-440 mV)/3.76 = 12%. I will work with this for now, but Frank seems to think this means there is something wrong with the AOM alignment.

I have not yet retuned the alignment into the power amplifier. I should do this later.

  2543   Fri Mar 19 15:13:25 2021 AidanComputingGeneralAdding fb4:/usr/share/advligorts to QIL-WS2

Adding fb4:/usr/share/advligorts to QIL-WS2 to /etc/fstab file

Should help access to CDS_PARTS model file in Simulink on QIL-WS2

Except access is denied by FB4

  211   Fri Jul 31 12:27:19 2009 Aidan, ConnorLaserFiberAdjusting angle of fiber-input-HWP to minimize fluctuations in the output

The attached time series shows measurements of the power in the s and p polarizations (via ThorLabs PDA10CS PDs) for different input HWP settings. This just shows the raw data from the experiment  described here ...

Attachment 1: 2009-07-31_matching_input_polarization.pdf
2009-07-31_matching_input_polarization.pdf
  2392   Mon Aug 12 12:09:00 2019 Nathan HollandSummary2micronLasersAdjusting the Voltage/Frequency Offset on the Brimrose AOM Driver.

The 80 MHz brimrose AOM driver, which came with the AOM, can actually drive between 75 MHz and 85 MHz. It has an input port, which accepts between 0V and 10V, for altering the frequency.

 

Previously, before Friday 2019-08-09, I had set the offset to + 5V, using a signal generator because that was what was available in the QIL lab. The signal generator, for some unclear reason, had then moved this offset to +4.4 V, when plugged into the AOM driver. Attachment 1 shows a power spectrum, from the BB PD, One notices a large peak negatively detuned from the 80 MHz signal frequency. Attachement 2 shows a zoom in, around 70 MHz, revealing this peak to be two peaks, one near 78 MHz, and another smaller one near 79 MHz.

I decided to adjust the voltage, input to the frequency port, to minimise the RF sidebands I observed. The results of this adjustment can be seen in attachments 3, and 4. Notice that there no observable sidebands. This was achieved with an offset of 4.52V.

 

Attachement 5 is the manual for the AOM, and its driver. (Removed by KA)

Attachment 1: 2um_MachZehnder_wide_PowerSpectrum_Screenshot.png
2um_MachZehnder_wide_PowerSpectrum_Screenshot.png
Attachment 2: 2um_MachZehnder_narrow_PowerSpectrum_Screenshot.png
2um_MachZehnder_narrow_PowerSpectrum_Screenshot.png
Attachment 3: 2um_MachZehnder_wide_PowerSpectrum_adjusted_Screenshot.png
2um_MachZehnder_wide_PowerSpectrum_adjusted_Screenshot.png
Attachment 4: 2um_MachZehnder_narrow_PowerSpectrum_adjusted_Screenshot.png
2um_MachZehnder_narrow_PowerSpectrum_adjusted_Screenshot.png
  2123   Thu Jun 22 16:45:17 2017 DhruvaLaserWOPOAdvR Waveguide Spec Sheet

Here is the spec sheet for the squeezing waveguide

Please, don't place proprietary documents on public web pages (=ELOGs).
Instead, place them on secured wikis and place only links to the
elogs. Thanks (Koji)

 

Edit - 

I have put the spec sheet on the ATF wiki. Here's the link - 

https://nodus.ligo.caltech.edu:30889/ATFWiki/lib/exe/fetch.php?media=main:experiments:wopo:advr.pdf

  2519   Tue Nov 17 17:51:44 2020 AidanUpdate2um PhotodiodesAgilis piezo mirror installed in JPL PD testing apparatus

I installed the Agilis mirror before the lens and cryo-chamber. Used the USB interface to align the beam onto the PD. So we can control the alignment remotely now (or once I’ve properly connected the USB cable instead of today’s janky test connection).
 

Attachment 1: IMG_9401.jpg
IMG_9401.jpg
Attachment 2: IMG_9400.jpg
IMG_9400.jpg
  2520   Thu Nov 19 16:25:30 2020 AidanUpdate2um PhotodiodesAgilis piezo mirror installed in JPL PD testing apparatus

Here's the python code I used to control this. 

I incorrectly used the Move to Limit command ('1MV-3': axis 1, MoVe, negative direction, speed 3', where the speeds are given in the manual, see Section 4.7 in particular). Once this command is issued, the stage will keep moving until it receives the stop command. The JOG command would be more appropriate.

I confirmed a smooth change in the PD output as the beam translated across it.

Quote:

I installed the Agilis mirror before the lens and cryo-chamber. Used the USB interface to align the beam onto the PD. So we can control the alignment remotely now (or once I’ve properly connected the USB cable instead of today’s janky test connection).
 

 

Attachment 1: Screen_Shot_2020-11-19_at_4.27.17_PM.png
Screen_Shot_2020-11-19_at_4.27.17_PM.png
  1399   Tue Apr 26 01:28:09 2011 ZachLaserGYROAha! (?)

Since it looks like AM at the input side is not the root of our current low-frequency problem, we have been trying yet again to come up with new sources. Alastair had the idea that pointing noise of the beam going into the cavity might be causing us a problem in some not-yet-well-understood way (this was first discussed in the context of 19 MHz jitter from the EOM being converted to RFAM as it could be in the AOM, but the cavity should have very little response at 19 MHz with which to do this).

I decided to look at the low-frequency spectrum of the DC_TRANS signal to see if there was the same type of behavior as in the gyro spectrum. As it turns out, there is. Below is a plot of the two compared side-by-side (though I had to scale the DC_TRANS plot up by a factor of ~10 to get it to coincide). There is extremely good agreement in the shape of the curves, and I think we'll see that the HF floor of the DC_TRANS plot is just the noise floor of the (broadband wide-area Thorlabs) PD.

dc_trans_vs_gyro_noise.png

I can't say that I can think of any obvious coupling mechanism here. I think it's feasible that pointing drift of the input beam is causing the spatial eigenmodes of the cavity to wander differentially (i.e., the points at which the supported mode in one direction touches the mirrors all move horizontally across the mirrors a bit, making the whole square 'rotate'---this is dependent on the input beam and can thus happen independently in each direction). In this case, the cavity length would differ in the two directions, resulting in a gyro signal.

We need to do some more work to figure out what exactly is going on, but this is another data point that helps with the diagnosis. I think the next step is to look at the power at some pickoff point close to the laser to see if this is an input power drift or something caused by varying degree of coupling into the cavity (as from misalignment).

  1400   Tue Apr 26 10:34:29 2011 AlastairLaserGYROAha! (?)

In terms of a coupling mechanism, I'm wondering about this:  If the pointing of the carrier as it goes into the cavity is moving around at low frequency, then that's going to modulate the coupling into the cavity and give us some AM on the reflection PD  (I'm not talking about RFAM here, but low frequency AM as the coupling to the cavity wanders around).  This then causes the AOM to try to act, so we see noise superimposed on the reflection and transmitted beam.

It seems that whatever the cause, if we are seeing AM at low frequency in the transmitted beam then it is likely that we will also be seeing the exact same signal on our REFL PDs.

EDIT:  Zach pointed out to me that there needs to also be some phase shift between the carrier and sidebands for us to get an errors signal.  I think that I'm not clear now how we ever expected the RFAM to show up as noise.  Where is the phase shift there?

 

Quote:

Since it looks like AM at the input side is not the root of our current low-frequency problem, we have been trying yet again to come up with new sources. Alastair had the idea that pointing noise of the beam going into the cavity might be causing us a problem in some not-yet-well-understood way (this was first discussed in the context of 19 MHz jitter from the EOM being converted to RFAM as it could be in the AOM, but the cavity should have very little response at 19 MHz with which to do this).

I decided to look at the low-frequency spectrum of the DC_TRANS signal to see if there was the same type of behavior as in the gyro spectrum. As it turns out, there is. Below is a plot of the two compared side-by-side (though I had to scale the DC_TRANS plot up by a factor of ~10 to get it to coincide). There is extremely good agreement in the shape of the curves, and I think we'll see that the HF floor of the DC_TRANS plot is just the noise floor of the (broadband wide-area Thorlabs) PD.

dc_trans_vs_gyro_noise.png

I can't say that I can think of any obvious coupling mechanism here. I think it's feasible that pointing drift of the input beam is causing the spatial eigenmodes of the cavity to wander differentially (i.e., the points at which the supported mode in one direction touches the mirrors all move horizontally across the mirrors a bit, making the whole square 'rotate'---this is dependent on the input beam and can thus happen independently in each direction). In this case, the cavity length would differ in the two directions, resulting in a gyro signal.

We need to do some more work to figure out what exactly is going on, but this is another data point that helps with the diagnosis. I think the next step is to look at the power at some pickoff point close to the laser to see if this is an input power drift or something caused by varying degree of coupling into the cavity (as from misalignment).

 

  1401   Tue Apr 26 15:25:24 2011 ZachLaserGYROAha! (?)

That is for some near-DC AM to be converted to AM of the 19-MHz beat frequency. The idea before was that jitter at 19 MHz would turn into a 19-MHz signal from misalignment into the AOM or via any other mechanism that turns jitter->AM (e.g., clipping). This looks like a DC error offset. Then, any low-frequency noise (e.g., slow pointing drift of the steering mirror on the way into the AOM, slow translation of some aperture relative to the beam) causes low-frequency AM of the 19 MHz signal, which looks like a time-varying error signal (noise). AM of the AM.

So, there is some 19 MHz oscillation set up by jitter->clipping or polarization->AM or some gremlin waving his hand steadily across the beam coming out of the laser at 19 MHz. Then, the amplitude envelope of this oscillation is modulated by some low-frequency noise source, and this is what looks like noise when demodulated by the PDH setup.

The question I'm wondering about now has nothing to do with envelope modulation of a 19 MHz signal. Instead, there could be low-frequency pointing noise on the way into the cavity. The cavity reflectivity looks like a real number close to 1 for the sidebands, independent of small angular misalignments. So, any existing 19-MHz signal is not amplitude modulated. The question is: how does this sort of thing become noise? I thought perhaps the eignenmodes of the cavity rotate with respect to each other since the beams are not being injected from symmetric points, and this could cause some relative length change that looks BIG in the gyro signal compared to what a common-mode length change would look like via FSR modulation. This could be why we don't see it in the primary (laser) actuation signal.

I think you raised the possibility that the same low-frequency pointing that causes us to see noise in the DC_TRANS signal could also produce RFAM via clipping or whatever, but in this case we would still see the noise with the cavity obstructed, which we do not.

Quote:

In terms of a coupling mechanism, I'm wondering about this:  If the pointing of the carrier as it goes into the cavity is moving around at low frequency, then that's going to modulate the coupling into the cavity and give us some AM on the reflection PD  (I'm not talking about RFAM here, but low frequency AM as the coupling to the cavity wanders around).  This then causes the AOM to try to act, so we see noise superimposed on the reflection and transmitted beam.

It seems that whatever the cause, if we are seeing AM at low frequency in the transmitted beam then it is likely that we will also be seeing the exact same signal on our REFL PDs.

EDIT:  Zach pointed out to me that there needs to also be some phase shift between the carrier and sidebands for us to get an errors signal.  I think that I'm not clear now how we ever expected the RFAM to show up as noise.  Where is the phase shift there?

 

 

 

 

  165   Thu Jul 9 10:45:16 2009 AidanComputingDAQAlex's frame builder problem diagnosis ...

 

This from Alex: 

 

The filesystem is full. If you look at the log messages:

[controls@oms fb]$ pwd
/cvs/cds/caltech/target/fb
[controls@oms fb]$ tail -5 logs/daqd.log.19816 
[Thu Jul  9 10:07:51 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194464-16.gwf' for writing; errno 28
[Thu Jul  9 10:07:51 2009] Couldn't open full trend frame file
`/frames/trend/second/data2/C-T-931194420-60.gwf' for writing; errno 28
[Thu Jul  9 10:08:07 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194480-16.gwf' for writing; errno 28
[Thu Jul  9 10:08:23 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194496-16.gwf' for writing; errno 28
[Thu Jul  9 10:08:39 2009] Couldn't open full frame file
`/frames/full/data38/.C-R-931194512-16.gwf' for writing; errno 28
[controls@oms fb]$ df -h /frames/
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     275G  261G     0 100% /frames


I stopped the frame builder for now until we figure out the data
directories. Can I delete all the data in /frames/full and recreate a new
set of directories? Otherwise this is too messy to rearrange. Let me know.

-alex


On Wed, 8 Jul 2009, Aidan Brooks wrote:


Hi Alex,

I fixed the problem with being able to telnet into fb0. There was just a typo in the file:
/cvs/cds/caltech/chans/daq/C2ATF.ini
Once I fixed that the frame builder rebooted just fine.

The problem at the moment is that the data does not appear to be writing to file. If I rebuild the front end from the start, so I go to oms and run the following commands:

cd /cvs/cds/advLigo
make realclean
make atf
make install-atf
make install-daq-atf
make install-screens-atf

And if I edit the file C2ATF.ini so that a single channel, e.g. C2:ATF-CTRL_PMC_REFL_IN1_DAQ is set to acquire. 

and killatf, followed by startatf and reboot the frame builder

Then: the front end starts okay and I can see signals in the EPICS screen that make sense. I can run StripTool and see the real time time series of a channel, I can start dataviewer and see C2:ATF-CTRL_PMC_REFL_IN1_DAQ in the list of fast channels. I can run the realtime viewer in dataviewer and see that channel realtime in a Grace window. However, I cannot get a playback of that channel to work and if I run dtt I can only get a spectrum if I specify a start time for that spectrum within the last (approximately) 30s in the past.

The data rate in the .mdl simulink model is 16K, the data rate in the C2ATF.ini files is 16K, the data rate in the file:
/cvs/cds/caltech/target/fb/daqdrc is set to 16K and there are 120 data directories in the /frames/full directory.

I can't think of any reason why the data is not being written to file. Can you log in and figure out what's wrong? You should be able to get access via controls@131.215.114.183

Thanks for your help,
Aidan.
 

  183   Sun Jul 19 09:44:09 2009 AidanComputingGeneralAliases added for standard LIGO tools

 

I've updated the /home/controls/.bashrc file to include some aliases to standard ligo tools. These should now be accessible anywhere from the command line.

alias dtt="/bin/diaggui"
alias dmt="/bin/dmtviewer"
alias foton="/bin/foton"
alias dv="dataviewer"
 
StripTool is already accessible from the command line.

  191   Wed Jul 22 20:36:37 2009 Aidan, ConnorLaserFiberAligned beam into fiber ... mode-matching needs a little work

Connor and I got the beam aligned into the fiber today. After a little optimization of the fiber coupled XYZ I'd estimate we were getting maybe 10-15% transmission. I'm pretty sure we can improve this with some work. We caculated the input mode (which I will reproduce elsewhere) but it's looking for a mode size of approximately 6.6 microns diameter. With a 10X microscope objective (f = 16.5mm) we want the intput beam to the coupler to be around 3.4mm diameter - which we have.

We mounted the AOM and inserted it into the setup. We should be able to get an 80MHz frequency shifted beam through the fiber tomorrow measure the fiber noise. That same setup can be used in a PLL to suppress the fiber noise.

 

  2015   Wed Feb 10 00:17:31 2016 KojiNMiscPD QEAlignment of the single mode fiber and re-measurement of the beam profile

The beam measued yesterday was very elliptic.

Thus, for obtaining a round beam, we decided to use a single mode fiber.

The single mode fiber was aligned with KojiA's instruction.

(There is the specific method in the last of this log)

As a result, the obtained mode matching ratio was 64.5%. (Input power for the fiber was 18.7 mW, and output power of the fiber was 12.07 mW.)

Then, the setup as shown in Fig. 1 was prepared.

In this setup, the beam profile after the single mode fiber was measured as shown in Fig. 2.

When Fig. 2 is observed, there is still a kind of lines in the y-direction and we consider it comes from the problem of camera.

The measured data and fitted curves are shown in Fig. 3.(Zero point of the distance was set at the position of the collimator #2)

 

Specific method to align the single mode fiber

1. place the collimator #1 at the focal point of the laser

2. align the laser light (IR light) to the collimator #1 roughly with steering mirror

3. unset the collimator #2 and set a fiber illuminator instead of the collimator #2

4. at just after the Iris #2, align the laser from the fiber illuminator (Red light) to the IR light with knobs of the collimator #1 holder.

5. at just before the collimator #1, align the IR light to the Red light with the steering mirror #1

6. repeat step 4. and 5. a few times

7. unset the fiber illuminator and confirm the IR laser is ouput from the collimator #2. (If the IR light cannot be observed, go back to step 3.)

8. set a power meter after the collimator #2

9. maximize the IR light power using yaw knobs of the collimator #1 holder and the steering mirror #1

10. maximize the IR light power using pitch knobs of the collimator #1 holder and the steering mirror #1

11. repeat step 9. and 10.

12. If a good mode matching ratio can be obtained, this fiber alignment is finished. If the good mode matching ratio cannot be obtained, change the Lens #1 and re-start from step 1.

Fig. 1 current setup.
Fig. 2 Screen of the beam profiler.
Fig. 3 Measured data and fitted curves of the beam profile.

 

  262   Thu Aug 13 03:31:12 2009 DmassLaserDoublingAlignment/optimization of PMC and oven

Using a photodiode on the PMC transmission I optimized:

  • The alignment of common and differential DOFs of the steering mirrors into the PMC
  • The mode matching (waist size and position) by moving the (temporary?) mode matching lenses

I eyeballed the SHG Oven to be collinear with the beam into it, and aligned into the aperture via knobs and looking at the transmitted spot.

I adjusted the position of my f = 5 cm "mode matching" lens right before the oven by looking at the brightness of the green spot transmitted. This was easy to do.

  • I emailed Raicol (the crystal makers) and they told me they had no data for damage thresholds of PPKTP.
  • N.B. on the above: Kirk says 1W in 30 microns is probably fine. This is something under 100 mW in 25 microns, so I should be OK.

I tried to eyeball where the optimum temperature of the oven (and thus PPKTP) was based on the brightness of the spot.

 

I played around with the Thorlabs Equilateral Dispersing Prism that I bought some time ago in an attempt to split the beams, but was unable to get it to do anything intelligent

  • I tried most orientations I could think of, wiggling the thing around
  • I tried both S and P (I have a 45 degree QWP in the beam path with pickoffs)
  • I was not able to get any green or 1064 transmitted through the second face.
  • Maybe there is something non intuitive about this, or maybe I missed what the thing was supposed to do...

I also played with a short pass filter but apparently this doesn't reject past 800 nm or so. I see no stock filter which rejects 1064 and passes 532.


Up Next/Soon:

  • Make some calibrated measurement of PMC transmission (within 1% or so)
  • Split the 532 and 1064 and get a measurement of my SHG efficiency
  • Sweep the temperature of my oven and get a phase matching curve
  1434   Mon Jun 20 20:12:18 2011 ZachThings to BuyGYROAll PDH2 stuff purchased

 I finished purchasing all the components for the PDH2 today, including the RF stuff from MiniCircuits and CoilCraft, SMA/SMP adapters and miscellaneous switches/LEDs/pots/etc from DigiKey, Allied and Mouser. I also ordered 6 NIM front panels from FrontPanel Express to go with the 6 boards that were ordered (in production now) form Sunstone last week. Lead times will vary I suppose, but everything I ordered was in stock.

  300   Fri Sep 4 15:35:53 2009 FrankLaserDAQAll laser channels online

all 35W laser channels are online now and i checked if the data is valid for all individual channels. seems to be fine so far, except some channels which i cant test because i can't change the value (like diode interlocks of the NPRO)

  2803   Wed Oct 19 18:46:49 2022 RadhikaDailyProgressEmissivity estimationAlumina samples

I'm documenting new 75x75mm alumina strip samples brought to the QIL by Chris. We have 5 strips 120um thick [Attachments 1, 2] and another 5 strips 40um thick [Attachments 3,4].

I've modeled cooldowns in Megastat's current configuration for the two strip thicknesses [Attachments 1, 2]. For both, the strip is modeled sitting atop 3 ceramic ball bearings, as in the Si wafer setup.

An important note is that the emissivities of these strips is much lower (effectively transparent) than typically quoted for alumina ceramic, due to how thin they are (emissivity proportional to bulk absorption, dependant on bulk thickness). This means the 120um and 40um strips also likely have different effective emissivities. Bulk transmission decays exponentially as exp(-c*z) for some c, so the effective emissivity of the 40um strip is likely much much smaller than that of the 120um strip. The model doesn't consider this dependence analytically - I've made a guess for emissivity of 0.02 for the 120um strip, and 0.005 for the 40um strip. Despite these low values, the plots still show significant cooling of the samples because their mass is very tiny. 

This analysis could be improved by deriving an analytic model of alumina emissivity as a function of sample thickness.

Attachment 1: IMG_3813.jpeg
IMG_3813.jpeg
Attachment 2: IMG_3816.jpeg
IMG_3816.jpeg
Attachment 3: IMG_3814.jpeg
IMG_3814.jpeg
Attachment 4: IMG_3815.jpeg
IMG_3815.jpeg
Attachment 5: alumina_wafer_120um_cooldown.pdf
alumina_wafer_120um_cooldown.pdf
Attachment 6: alumina_wafer_40um_cooldown.pdf
alumina_wafer_40um_cooldown.pdf
ELOG V3.1.3-