40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 36 of 344 Not logged in
ID Date Author Type Category Subject
6462   Wed Mar 28 20:54:02 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.

Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design).  The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters.  Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

6476   Mon Apr 2 18:58:32 2012 JenneUpdateIOOBeam Profile measurement: IPPOS beam

Suresh noted that I never wrote down the waist positions of the beam propagated through the MMT (based on where we think it is from ruler-based measurements).  This uses the MC waist measured beam as the starting point, and just propagates through the MMT, out to the IPPOS port.

Yq:

Properties:
q: 2.2488 +23.8777i
lambda: 1.0640e-06
waistSize: 0.0028  (at z = 13.2676 meters)
waistZ: 2.2488    (relative to z = 13.2676 meters)
divergenceAngle: 1.1910e-04
beamWidth: 0.0029
rayleighRange: 23.8777

So, to sum up, the vertical beam waist is 2.8438 mm at 11.0188 meters from the MC waist.

Xq:

Properties:
q: 5.1953 +24.7342i
lambda: 1.0640e-06
waistSize: 0.0029   (at z = 13.2676 meters)
waistZ: 5.1953    (relative to z = 13.2676 meters)
divergenceAngle: 1.1702e-04
beamWidth: 0.0030
rayleighRange: 24.7342

So, to sum up, the horizontal beam waist is 2.8943 mm at 8.0723 meters from the MC waist.

In pictorial form,

6477   Mon Apr 2 23:06:38 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Mystery deepens

 Quote: I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2. Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design).  The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters.     Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

I am trying to track down possible errors in our measurements.

So as a first step I am recomputing the IPPOS waist location with respect to the MC waist, using the same optical layout diagram as the one used by Jenne in her calculations.  Pic of Jenne's lab notebook showing location of optics is attached.

 IPPOS: measurement elog 6459: Vertical Std.Error Horizontal Std.Error Waist 2.768 mm 5 microns 2.476 mm 10 microns Waist location from MC waist 12.411 m 17 mm 9.572 m 54 mm Std Dev of residuals from fit function 37 microns 54 microns

Let us compare it with the old measurement of the IPPOS beam from June/18/2010.

 IPPOS: measurement June 18th 2010 Vertical Std.Error Horizontal Std.Error Waist 2. 812mm 8 microns 2.909 mm 20 microns Waist location from MC waist 9.265 m 224 mm 5.869 m 415 mm Std Dev of residuals from fit function ~ 25 microns ~25 microns

Note that there is a discrepancy of about 3.2 m in the waist location for the vertical profile and about 3.5 m for the horizontal profile between these two measurements.

Let us compare these measurements with what is expected from calculations.  Jenne uses the known parameters of MC waist and the locations of the MMT optics to compute the parameters for the IPPOS beam:

 IPPOS: Jenne's Calculations elog 6476: Vertical Std.Error Horizontal Std.Error Waist 2.844 mm 2.894 mm Waist location from MC waist 11.019 m 8.072 m

As the 2010 measurements are reported wrt to MMT2 and calculations are wrt MCwaist, I have used the distance between the MCwaist to MMT2 = 3.910 m to shift the reference from MMT2 to MC waist. Refer to the attached diagram from Jenne's notes for this MMT2 <--> MC waist distance.

There is a discrepancy of 1.5 meters between the calculations and recently measured waist location.  The discrepancy with the 18Jun2010 measurement is much larger, about 3 meters in both v and h.

Are such variations to be expected between two successive measurements?  I looked at another case where we have two measurements of a beam to see what to expect.

I looked at the REFL (Reflection from PRM) case, where we repeated a measurement, to see how much variation could happen in w0 and zr, between repeated measurements. This was a particularly bad case as our first attempt had problems due to OL servo loop oscillations in the PRM suspension damping.  We fixed that later and measurement 2 has smaller residuals. And I think we are doing okay in IPPOS case as seen by the reduced scatter of the residuals.

These are the fits from the REFL beam measurement 1

 REFL: Reflection from PRM: measurement 1 Vertical Error Horizontal Error Waist 1.662 mm 4 microns 2.185 mm 4 microns Waist location from MMT2 after reflection at PRM 1.781 m 17 mm 4.620 m 53 mm Std.Dev. of residuals from fit function 61 microns 98 microns

I have also recomputed the fits to the data from REFL beam measurement 2.  They match the earlier fits reported by kiwamu in his elog 6446

 REFL: Reflection from PRM: measurement 2 Vertical Error Horizontal Error Waist 1.511 mm 3 microns 2.128 mm 3 microns Waist location from MMT2 after reflection at PRM 1.281 m 9 mm 3.211 m 37 mm Std. Dev of residuals from fit function 58 microns 61 microns

Note that between these two measurements the beam waist location has shifted by 0.5 m for the vertical and about 1.3 m for the horizontal cases.  So variations of 1.5 m in the waist locations are possible if we are not careful.  But this is a particularly extreme example, I think we are doing better now and the measurement is unlikely to change significantly if we repeat it.

Some notes:

Fits for IPPOS and both REFL measurements 1 and 2 are attached.

The zero reference for the z axis of the IPPOS beam plot is at a distance of 6.719 m from MC waist for a beam propagating towards the IPPOS QPD.

The zero reference for the z axis of the REFL beam plots is at a distance of 5.741 m from the MMT2 in the direction of a beam reflected by PRM and propagating towards the REFL port.

6526   Thu Apr 12 01:17:56 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Possible Clipping

[Suresh, Jenne]

The input beam is most probably being clipped at the Faraday Isolator.

Evidence:

a)  The beam scan of the IPPOS beam showed a nongaussian beam in the horizontal direction.  This was visible in the beam scan since it overlays a gaussian-fit over the data.

b)  I was able to remove this departure from gaussian profile by introducing an offset of 5 into the C1:IOO-WFS2_YAW_OFFSET.

c)   We made a few measurements of the beam diameter as a function of distance at an offset of 7.  At a distance of beyond 3 m the deviation from gaussian profile was once again apparent.

d)  We increased the offset to 14 to remove this deviation.

e)  When we measured the beam diameter again with this new offset the horizontal diameter and vertical diameters dropped by 2.sigma.  Indicating there the beam was clipped till then.

f)   We increased the offset to 16 and the beam diameter did not change further (within 1.sigma). Implying no more clipping, hopefully.

And then the earthquake stopped us from proceeding further.

We plan to investigate this further to be sure..  Data attached.

Subsidiary effects to keep track of:

1) Introducing an offset into the WFS loops decreases the coupling from PSL into MC.

2) If the beam is being clipped at the Faraday Isolator then the REFL beam would also show lesser clipping with WFS offsets.

6531   Thu Apr 12 23:12:16 2012 SureshUpdateIOOBeam Profile measurement: IPPOS beam: Possible Clipping

 WiQuote: [Suresh, Jenne]   The input beam is most probably being clipped at the Faraday Isolator.   Evidence:  ..... We plan to investigate this further to be sure..  .....

I tried to determine an optimal WFS2YAW offset to be used so that we may avoid clipping.

Initially, I just measured the beam diameter as a function of offset.  If the beam diameter would become independent of offset if it is not clipped.  However a systematic effect became apparent when I shifted the beam on the detector to a slightly different location.  So I repeated the measurements while recentering the beam to the same location everytime  (centered at -1650+/- 50 for both H and V directions).

I have attached plots of the scans for both cases, with recentering and without.    I have not been able to figure out what is going on since the beam diameter does not become independent of the offset.  While the beam profile becomes more gaussian beyond offsets of about 7 or so, the beam diameter does not seem to follow a clear pattern.  The measurements are repeatable (within one sigma) so the experimental errors are smaller than 1 sigma.

The photographs below show the improvement of Horizontal beam profile with WFS2Yaw offset.  These seem to indicate a good gaussian beam for offsets beyond 7 or so.  At offsets more than 12 the MC unlocks.

 Offset = -2 Offset = 0 Offset = 2 Offset = 8

 This seems to indicate that the beam diameter does not vary for WFS2Yaw offset > 8 But if we recenter the beam for each measurement this effect seems to vanish

Will continue tomorrow.   Jenne wants to do some IFO locking now.

6458   Tue Mar 27 21:37:51 2012 keikoConfigurationIOOBeam Profile measurement: IPPOS beam

From the mode measurement I and Suresh have done yesterday, I calculated what beam size we expect at ETM ((1) upper Fig.1)  and at ETM after one bounce ((2) lower Fig.1).

Fig.1 (Yarm)

In case of (1), we expect approximately w=6300 um (radius), and w=4800 um for one-bounce spot (2) from the measured mode, see Fig.2.

Fig.2

This roughly agree with what we observed on CCD camera. See, pic1 for (1) and pic2 for (2). The spot at the ETMY (1) is larger than the one-bounced spot (2). From the monitor it is difficult to assume the radius ratio. The observed spot of (2) is a bit smaller than the prediction. It could happnen when (A) the ETMY (as a lens) is slightly back of the ideal position (= the distance between the ITM and ETM is longer than 40m) (B) the real waist is farer than ITM position toward MC (I assumed roughly 5 m from Jenne's plot, but could be longer than that).

pic1 (left): beam spot hitting on the suspension frame. pic 2 (right): the one-bounced beam spot hitting on the suspension frame.

6441   Fri Mar 23 05:10:46 2012 SureshUpdateIOOBeam Profile measurements: Errors too large to yield good fits.

[Kiwamu, Suresh]

Today we attempted to measure the beam profile of the REFL beam under two conditions:

(a) with PRM aligned and ITMs misaligned

(b) with PRM misaligned and ITMs aligned

The raw data is shown below.  In each of the above conditions we measured in both the vertical (v) and horizontal (h) directions.   The measurements in the vertical direction were better than the ones in the horizontal direction because the optics had a horizontal oscillation which gave larger errors in measurement.

Looking at the general trend of these lines it is clear that modes are not matched since the beam reflected by the PRM has a different divergence than that reflected from ITMs.  The beam is also astigmatic as the vertical and horizontal directions have different divergences.

I could find beam parameters only for the Blue line above (Profile in the vertical direction while PRM was aligned).   The fit is quite sensitive to the data points close to the waist, so we need to make better (lower St.Dev.) measurements near the AP table closer to the beam waist.  The intensity with only one ITM aligned is too low and also contributes to the errors.   The beam size is close to 6mm in the horizontal direction, this coupled with yaw oscillations give large errors in this measurement.

Here is the only reliable fit that could be obtained, which is for the prompt reflection from the PRM in the vertical direction

The fit function I used is  Beam Dia = Waist { Sqrt [ 1+  ((z + z0)/zr)^2). The fit parameters we get for this data are

z0 = 7.7 m

Waist = 2.4 mm

zr = 6.9 m

Will make another attempt later today...

15529   Mon Aug 17 15:18:26 2020 gautamUpdateEquipment loanBeam Profiler + peripherals --> 40m

Gabriele left the DataRay beam profiler + peripherals (see Attachment #1) in his office. I picked them up just now and brought them over to the 40m.

13002   Mon May 22 10:53:02 2017 DhruvaUpdateOptical LeversBeam Profiling Results

 Quote: Andrew and I set up the razor blade beam profiling experiment for He-Ne lasers on the "SP" table.  Once I receive the laser safety training, I will make power measurements and fit it to an erfc curve from which I will calculate the gaussian profile of the beam. I'm attaching some pictures of the setup.  Least count of the micrometer - 2 microns  Laser  : Lumentum 22037130:1103P Photodetector : Thor Labs PDA100A

I had measured the y-profile of the beam of Friday at 5 axial locations and fit them to an erfc function using the lsqcurvefit function of MATLAB.

The results were as follows -

z(cm)    w (in)

4          0.0131

10        0.0132

15        0.0137

20       0.0139

25        0.0147

I left w in inches in the intensity plots as MATLAB gave more accurate fits for those values.

I converted these to S.I while making the spot-size vs z plot and the corresponding values in microns were

332.74, 335.28, 347.98, 353.06, 373.38.

On fitting these values to the formula for the spot size of a Gaussian beam, the beam waist came out to be 330.54 microns and the location of the beam waist was at z=-2cm, where z=0 marks the head of the laser.

TO-DO : Measure the spot size of the beam at more axial points to obtain a better fit.

Measure the x-profile of the beam.

Analyse the error in the spot sizes and corresponding error in the beam waist.

13006   Tue May 23 10:27:24 2017 DhruvaUpdateOptical LeversBeam Profiling Results

I have attempted to calculate the instrument error (micrometer least count) using the values of the spot size obtained by the least squares fitting method. This error is large towards the centre of the beam as the power varies significantly between adjecent markings of the micrometer. Using the new values of error obtained, I used the chi-square fitting minimisation method to further optimise the waist size.

The modified values are -

z(cm)    w (in)

4         0.0134

10        0.0135

15        0.0140

20        0.0142

25        0.0150

And the revised values for the beam waist and location are 338.63 microns and -2.65 cm respectively.

I will now try to use the chi-square stastitic to estimate the error in spot size.

13007   Tue May 23 15:22:04 2017 ranaUpdateOptical LeversBeam Profiling Results
1. Include several sources of error. Micrometer error is one, but you should be able to think of at least 3 more.
2. There should be an error bar for the x and y axis.
3. Also, use pdftk to put the PDFs all into a single file. Remove so much whitespace.
4. Google 'beautiful plots python' and try to make your plots for the elog be more like publication quality for PRL or Nature.
13008   Tue May 23 16:33:00 2017 SteveUpdateOptical LeversBeam Profiling Results

You may compare your results with this.

RXA: please no, that's not the right way

13021   Tue May 30 18:31:54 2017 DhruvaUpdateOptical LeversBeam Profiling Results

​Updates in the He-Ne beam profiling experiment.

1. I've made intensity profile plots at two more points on the z-axis. The additition of this plots hasn't affected the earlier obtained beam waist significantly.
2. I have added other sources of error, such as the statisitical fluctuations on the oscilloscope(which is small compared to the least count error of the micrometer) and the least count of the z-axis scale.
3. I have also calculated the error in the parameters obtained by fiiting by calculating the covariance matrix using the jacobian returned by the lsqcurvefit function in MATLAB.
4. I have also added horizontal error bars to all plots.
5. All plots are now in S.I. units

13053   Thu Jun 8 12:43:42 2017 DhruvaUpdateOptical LeversBeam Profiling Results

 Quote: ​Updates in the He-Ne beam profiling experiment. ​

New and improved plots for the He-Ne profiling experiment

Font size has been increased to 30.

The plots are maximum size (Following Rana's advice, I saved the plots as eps files(maximized) and converted them to pdf later).

There is a shaded region around the trendline that represents the parameter error.

Function that I fit my data to (should have mentioned this in my earlier elog entries)

$P = \dfrac{P_0}{2}\Bigg[1+erf\Big(\dfrac{\sqrt2(X-X_0)}{w}\Big) \Bigg]$

Description of my error analysis -

1. I have assumed a 20% deviation from markings in the micrometer error.

2. Using the error in the micrometer, I have calculated the propogated error in the beam power :

$\delta P = \sqrt{\dfrac{2}{\pi}}{P_0}\dfrac{\delta x}{w}\exp\Bigg({\frac{-2(X-X_0)^2}{w^2}}\Bigg)$

I added this error to the stastistical error due to the fluctuation of the oscilloscope reading to obtain the total error in power.

3. I found the Fisher Matrix by numerically differentiating the function at different data points $P_b$ with respect to the parameters $p_i =$  $P_0, X_0$ and $w$.

$F_{ij} = \sum_{b} {\frac{\partial P_b}{\partial p_i}\frac{\partial P_b}{\partial p_j}}$$\frac{1}{\sigma^2_b}$

I then found the covariance matrix by inverting the Fisher Matrix and found the error in spot size estimation.

12997   Wed May 17 18:08:45 2017 DhruvaUpdateOptical LeversBeam Profiling Setup

Andrew and I set up the razor blade beam profiling experiment for He-Ne lasers on the "SP" table.  Once I receive the laser safety training, I will make power measurements and fit it to an erfc curve from which I will calculate the gaussian profile of the beam. I'm attaching some pictures of the setup.

Least count of the micrometer - 2 microns

Laser  : Lumentum 22037130:1103P

Photodetector : Thor Labs PDA100A

1724   Wed Jul 8 18:46:56 2009 DmassAoGElectronicsBeam Scan Funky

The beam scan (which has been living in the bridge subbasement for a bit now) is in a state of imperfection.

I noticed that:

• The waist reading seems to change by not insignificant amounts as you move the spot across the head, even for just small perturbations about the center.
• None of the features which require two slits seem to be working (unsure if this is software or hardware related)

I took some pictures to try and illuminate the situation - The inverted images are included to make it easier to see the flecks (?) in the slits

I am not sure how to figure out if any bit of the scan is/has been fried.

Pending further investigation, enjoy large error bars in your scan measurements!

PICTURES OF BOTH SLITS ON THE BEAMSCAN HEAD:

6431   Tue Mar 20 17:50:44 2012 SureshUpdateComputersBeam Scan machine fixed

There was something wrong with the Beam Scan PC.  The  mouse and screen were not responding and the PC was asking for drivers for any new hardware that we plugged in.  We called in the services of Junaid and co. since we do not have a Win98 Second Edition installation disk in the lab.   Junaid came with the disk, we changed the screen and the mouse and installed everything.

We tried to get the network going on the PC so that we could update stuff easily over the net.  This didnt succeed. For now, we still have to depend on a Win98se CD to get drivers if any new hardware is connected to this machine.

For future reference, some notes:

1)  We will get a copy of Win98SE for the lab from Junaid

2) We have to use a USB mouse from Dell. We have several spares of this. The drivers for these are present in the machine.

The Beam Scan is working okay now.  We will proceed with the beam profile measurements.

10106   Fri Jun 27 10:09:10 2014 HarryUpdateGeneralBeam Waist Measurement

Purpose

To use a razorblade to measure beam waist at four points along the optical axis, so as to later extrapolate the waist. This information will then be used to effectively couple AUX laser light to fibers for use in the frequency offset locking apparatus.

Data Acquisition

1) Step the micrometer-controlled razorblade across the beam at a given value of Z, along optical axis, in the plane orthogonal to it (arbitrarily called X).

2) At each value of X, record the corresponding output of a photodiode, (Thorlabs PD A55) here given in mV.

3) Repeat in Y plane at the same value of Z

4) Repeat process at multiple points along Z

Analysis

Data from each iteration were fitted to the error function shown below.

y(x) = (.5*P)*(1-erf((sqrt(2)*(x-x0))/wz))

'P' corresponds to peak power, 'x0' to the corresponding value of x (or y, as the case may be), and 'wz' to the spot size at the Z value in question.

The spot sizes from the four Z values were then fit to:

y(x) = w0*sqrt(1+((x*x)/(zr*zr)))

Where 'w0' corresponds to beam waist, and 'zr' to Rayleigh Range.

Conclusion

This yielded a Y-Waist of 783.5 um, and an X-Waist of 915.2 um.

The respective Rayleigh ranges were 2.965e+05 um (Y) and 3.145e+05  um (X).

Next

I will do the same analysis with light from the optical cables, which information I will then use to design a telescope to effectively couple the beams.

10204   Tue Jul 15 18:26:40 2014 HarryUpdateGeneralBeam Waist, Telescope, and Fiber Coupling

Goal

To design an optical setup (telescope / lens) to couple 1064nm NPRO light into PANDA PM980 fibers in order to characterize the fibers for further use in the frequency offset locking setup.

Design

Calculations

The beam waist of the NPRO was determined as 233um 6cm in front of the NPRO. This was used as the seed waist in ALM.

The numerical aperture of the fiber was given as 0.12, which allowed me to calculate the maximum angle of light it would accept, with respect to the optical axis, as NA = sin(theta) where theta is that angle.

Given that the coupler has a focal length of 2mm, I used the formula r = f * tan(theta), to yield a "target waist" for efficient coupling into the fiber. This ended up being 241.7um.

Since there was not a huge difference between the natural beam width of the NPRO and our target waist, I had no need for multiple lenses.

I used 230um as a target waist for a la mode, to leave myself some room for error while coupling. This process gave me a beam profile with a lens (f=0.25m), and a target waist of 231um, located 38.60cm from the coupling lens

I have attached ALM code, as well as the beam profile image. Note that the profile takes zero to be the location of the NPRO waist.

Next Steps

After this setup is assembled, and light is coupled into the fibers, we will use it to run various tests to the fiber, for further use in FOL. First of all, we wish to measure the coupling efficiency, which is the purpose of the powermeter in the above schematic. We will measure optical power before and after the fibers, hoping for at least ~%60 coupling. Next is the polarization extinction ratio measurement, for which we will control the input polarization to the fibers, and then measure what proportion of that polarization remains at the output of the fiber.

10139   Mon Jul 7 14:42:33 2014 HarryUpdateGeneralBeam Waists

I was finally able to get a reasonable measurement for the beam waist(s) of the spare NPRO.

Methods

I used a razorblade setup, pictured below, to characterize the beam waist of the spare 1064nm NPRO after a lens (PLCX-25.4-38.6-UV-1064) in order to subsequently calculate the overall waist of the beam. The setup is pictured below:

After many failed attempts, this was the apparatus we (Manasa, Eric Q, Koji, and I) arrived with. The first lens after the laser was installed to focus the laser, because it's true waist was at an inaccessible location. Using the lens as the origin for the Z axis, I was able to determine the waist of the beam after the lens, and then calculate the beam waist of the laser itself using the equation wf = (lambda*f)/(pi*wo) where wf is the waist after the lens, lambda the wavelength of the laser, f the focal legth of the lens (75.0 mm in this case) and wo the waist before the lens.

We put the razorblade, second lens (to focus the beam onto the photodiode (Thorlabs PDA255)), and the PD with two attenuating filters with optical density of 1.0 and 3.0, all on a stage, so that they could be moved as a unit, in order to avoid errors caused by fringing effects caused by the razorblade.

I took measurements at six different locations along the optical axis, in orthogonal cross sections (referred to as X and Y) in case the beam turned to be elliptical, instead of perfectly circular in cross section. These measurements were carried out in 1" increments, starting at 2" from the lens, as measured by the holes in the optical table.

Analysis

Once I had the data, each cross section was fit to V(x) = (.5*Vmax)*(1-erf((sqrt(2)*(x-x0))/wz))+c, which corresponds to the voltage supplied to the PD at a particular location in x (or y, as the case may be). Vmax is the maximum voltage supplied, x0 is an offset in x from zero, wz is the spot size at that location in z, and c is a DC offset (ie the voltage on the PD when the laser is fully eclipsed.) These fits may all be viewed in the attached .zip file.

The spot sizes, extracted as parameters of the previous fits, were then fit to the equation which describes the propagation of the spot radius, w(z) = wo*sqrt(1+((z-b)/zr)^2)+c, w(z) = w0*sqrt(1+((((z-b)*.000001064)^2)/((pi*w0^2)^2))) where wo corresponds to beam waist, b is an offset in the z. Examples of these fits can be viewed in the attached .zip file.

Finally, since the waists given by the fits were the waists after a lens, I used the equation wf = (lambda*f)/(pi*wo), described above, to determine the waist of the beam before the lens.

Plots

note: I was not able to open the first measurement in the X plane (Z = 2in). The rest of the plots have been included in the body of the elog, as per Manasa's request.

Conclusion

The X Waist after the lens (originally yielded from fit parameters) was 90.8 27.99 ± .14 um. The corresponding Y Waist was 106.2 30.22 ± .11 um.

After adjustment for the lens, the X Waist was 279.7 907.5 ± 4.5 um and the Y Waist was 239.2 840.5 ± 3.0 um.

edit: After making changes suggested by koji, these were the new results of the fits.

Attachments

Attached you should be able to find the razor blade schematic, all of the fits, along with code used to generate them, plus the matlab workspace containing all the necessary variables.

NOTE: Rana brought to my attention that my error bars need to be adjusted, which I will do as soon as possible.

10144   Mon Jul 7 18:11:04 2014 KojiUpdateGeneralBeam Waists

- Plots should be directly attached on the elog. (Attaching codes in a zip is OK.)

- Plot legends should not touch or hide any data points.

- Don't exclude data points.

- The model for the beam profile fitting is incorrect: zr and w0 are dependent

- The code needs to be reviewed by someone for refinement.
(
EricQ, or possibly Jamie, Jenne while he is absent).

10170   Wed Jul 9 23:02:33 2014 HarryUpdateGeneralBeam Waists via Beamscan

Today, I borrowed the beam profiler from Brian (another SURF) in order to double check my razor blade measurement figures, using the below setup:

Measurements are included in the a la mode code that is attached entitled beamfit.m. The beam fitting application yielded me waists (after the lens) of 35.44 um in the x plane, and 33.26 um in the y plane. These are both within 3 um of the measurements I found using the razor blade method. (I moved and resized the labels for the waists in the figure below for readability purposes.)

I then plugged these waists back into ALM, in addition to the lens specifications, to determine waist size and location of the NPRO, which turned out to be 543 um in the x located at Z = 1.160m, and 536 um in the y, located at 1.268m. These measurements are based upon zero at the waist after the lens, and the positive direction being back toward the NPRO.

The only systemic difference between these measurement and my original razor blade measurements was that I had taken the focal length of the lens as 75mm, which is advertised on the manufacturer's site. However, the more detailed specs revealed that the focal length was 85.8mm at 1064nm, which made a difference of about 400 um for the final waist determination.

1784   Thu Jul 23 20:30:23 2009 AlbertoUpdatePSLBeam aligned to the Farady

After yesterday's changes in the MC cavity state today it was necessary to optimize the alignment to the Faraday.

The way I did it was by tuning the PSL periscope in pitch and yaw trying to maximize TRX with the arm locked. After a small change in either one of the two directions I first maximized the MC transmitted power and then I ran the alignment script for the X arm.

I explored the space for both pitch and yaw and the max that I could get from TRX was 0.91. I'm not sure whether the increase in TRX is entirely due to a better alignment to the Farady rather than to a higher MC transmitted power.

Also I'm not sure I'm well interpreting the image from the camera pointing at the Farady. I guess I need someone more familiar with it to tell me if it shows any sign of clipping.

Anyway, last week, even before the MC got misaligned, TRX didn't go above 0.90. So now I wonder whether it's the MC's fault or something else's if we have that value..

7590   Mon Oct 22 21:20:36 2012 JenneUpdatePSLBeam attenuation optics in place

[Jenne, Raji (before dinner)]

We put the beam attenuation optics in place.  Before putting any optics down, I centered the IOO QPDs, then adjusted the HWPs and PBS such that we remained centered on those QPDs.

Now, I'm about to unblock the beam and let ~100mW into the vacuum so I can lock the MC.  Steve and Manasa were putting on the light access connector when I left earlier, so I'm excited to use it!

14919   Tue Oct 1 18:35:12 2019 gautamUpdateGeneralBeam centering campaign
1. With TRX and TRY maximized using ASS, I centered the Oplev spots on the respective QPDs for the four test masses and the BS. I also centered the spot onto the IPPOS QPD by moving the available steering mirror.
2. At EX, I tweaked the input pointing of the green beam into the arm by manually twiddling with the PZT mirrors. I was able to get GTRX~0.4.
3. On the AS table - Koji and I found that there was a steering mirror placed in the AS beam path such that there was no light reaching the AS110 or AS55 PDs. Please - when you are done with your measurement, return the optical configuration to the state it was in before so that the usual locking activity isn't disturbed by a needless few hours troubleshooting electronics.

Once Koji is done with his checkout of the whitening electronics, I will try and lock the PRMI.

11766   Mon Nov 16 11:48:34 2015 yutaroUpdateOptical LeversBeam centering for the oplev of ETMY

[yutaro, ericq]

We made the beam spot on QPD for the oplev of ETMY centered by changing the orientation of the mirror just before the QPD.

Before doing this, we ran dithering for Y arm and froze the output of ASS for Y arm.

11783   Wed Nov 18 17:32:36 2015 yutaroUpdateOptical LeversBeam centering for the oplev of ITMY

[yutaro, Koji]

We made the beam spot on QPD for the oplev of ITMY centered by changing the orientation of the mirror just before the QPD.

Before doing this, we ran dithering for Y arm and froze the output of ASS for Y arm.

11805   Tue Nov 24 11:18:47 2015 yutaroUpdateOptical LeversBeam centering for the oplev of ITMY

I made the beam spot on QPD for the oplev of ITMY centered by changing the orientation of the mirror just before the QPD.

Before doing this, I ran dithering for Y arm and froze the output of ASS for Y arm.

8279   Tue Mar 12 14:02:22 2013 JenneUpdateAlignmentBeam drift - mystery partially solved?

Steve just told those of us in the control room that the custodian who goes into the IFO room regularly steps on the blue support beams to reach the top of the chambers to clean them.  Since we have seen in the past that stepping on the blue tubes can give the tables a bit of a kick, this could help explain some of the drift, particularly if it was mostly coming from TT2.  The custodian has promised Steve that he won't step on the blue beams anymore.

This doesn't explain any of the ~1 hour timescale drift that we see in the afternoons/evenings, so that's still mysterious.

7837   Mon Dec 17 11:20:58 2012 JenneUpdateSUSBeam dumps on vertex oplevs removed

I'm not sure when this was done, but there were beam dumps in front of the lasers for BS/PRM oplevs as well as ITMY/SRM oplevs.  MICH wasn't holding lock very nicely, so I poked around, and the Sum values for all of these optics' oplevs seemed too low, so I went to look, and found dumps.  I have removed these, and now BS and ITMY oplevs are back to normal.  (PRM and SRM are still misaligned right now, so I'll check those later, but they should be fine).

BS's oplev has been enabled while non-existant, at least for the whole weekend, since I found it enabled.  ITMY I found misaligned, so it's oplev servos were off.

In other news, we should get back in the habit of restoring all optics before we leave for the night / whenever locking activities are finished.

12066   Thu Apr 7 12:51:24 2016 gautamUpdateendtable upgradeBeam height differences

Steve has finished installing the enclosure on the new endtable. So Eric and I decided to try and lock the X arm and measure the beam height of the transmitted IR beam relative to the endtable. We initially thought of using POX DC as a the LSC trigger but this did not work as there was no significant change in it when the arm was flashing. Eric then tried misaligning the ITM and using AS110 as a trigger - this worked. We then recompiled the ASS model to take AS110 as an input, and ran the dither alignment. After doing so, I measured the beam height at two points on the new endtable.

Bottom line:

• The beam is roughly level across the table (along the North-South direction, within the precision to which I could place the irides and measure the height). The table has also been levelled pretty well...
• The beam height is ~4.7" across the endtable

So the beam is about 0.7" higher relative to the endtable than we'd like it to be. What do we do about this?

• Is it even possible to raise the table by 0.7" so we can have a level beam everywhere? Are there some constraints related to how the enclosure is attached to the window?
• Are we okay with tolerating a solution where we keep the beam level at 4", and use Y10 and Y11 (see layout in elog 12060) to raise the beam by 0.7", and then have slightly higher posts for the optics downstream of this point?

I've also placed two irides extending the cavity axis on the endtable. These should be helpful in aligning the green to the arm eventually.

4222   Fri Jan 28 13:07:31 2011 JenneUpdateIOOBeam is back on the WFS

The MC WFS have had beam dumps in front of them for the past ~2 weeks, until I could find the appropriate optic to put in the WFS path, to avoid melting the WFS' electronics.

Koji noted that Steve had a W2-45S in a secret stash near his desk (which Steve later had put into the regular optics storage shelves down the Yarm), so I used that in front of the black hole beam dump on the AS table.  Now the beam is ~1W reflected from the unlocked mode cleaner, and ~100mW goes to the MC REFL PD.  The other 900mW now goes to this W2, and only ~5mW is reflected toward the MC WFS.  Most of the 900mW is transmitted through the window and dumped in the black hole.  There is a ghost beam which is reflected off the back surface of the wedged window, and I have blocked this beam using a black anodized aluminum dump.  I will likely change this to a razor dump if space on the table allows.  I have aligned the beam onto WFS1 and WFS2, although I did not re-align the mode cleaner first, so this alignment of the WFS will likely need to be redone.

WFS1 has about 2mW incident, and WFS2 has about 3mW incident, when the mode cleaner is unlocked.  I have not yet measured the power incident when the MC is locked, although obviously it will be much smaller.

Except that I might temporarily remove one of the WFS for more quantum efficiency measurements later today, the WFS should be ready to turn back on for alignment stabilization of the mode cleaner.

 Quote: My goal this afternoon was to measure the quantum efficiency of the MC WFS.  In the process of doing this, I discovered that when I reverted a change in the MCWFS path (see elog 4107 re: this change), I had not checked the max power going to the WFS when the MC unlocks. Current status: MC locks (is locked now).  No light going to WFS at all (to prevent MC WFS french-fry action).  Quantum Efficiency measured. The Full Story: Power to WFS: Rana asked me to check out the quantum efficiency of the WFS, so that we can consider using them for aLIGO.  This involves measuring the power incident on the PDs, and while doing so, I noticed that WFS1 had ~160mW incident and WFS2 had ~240mW incident while the mode cleaner was unlocked.  This is bad, since they should have a max of ~10mW ever.  Not that 200mW is going to destroy the PD immediately, but rather the current out, with the 100V bias that the WFS have, is a truckload of power, and the WFS were in fact getting pretty warm to the touch.  Not so good, if things start melting / failing due to extended exposure to too much heat. The reason so much power was going to the WFS is that it looks like Yuta/Koji et. al., when trying to use the WFS as a MC1 oplev, changed out 2 of the beam splitters in the MC WFS / MC Refl path, not just one.  Or, we've just been crispy-frying our WFS for a long time.  Who knows?  If it is option A, then it wasn't elogged.  The elog 3878 re: BS changeout only mentions the change of one BS. Since the MC Refl path has a little more than ~1W of power when the MC is unlocked, and the first BS (which was reverted in elog 4107) is a 10% reflector, so ~100mW goes to the MC Refl PD, and ~900mW goes to the MC WFS path.  In front of a Black Hole beam dump was sitting a BS1-33, so we were getting ~300mW reflected to be split between the 2 WFS, and ~600mW dumped.  The new plan is to put a W2 window in place of this BS1-33, so that we get hopefully something like 0.1% reflected toward the WFS, and everything else will be dumped.  I could not find a W2-45S (everything else is S, so this needs to be S as well).  I found a bunch of W2-0deg, and a few W2-45P.  Does anyone have a secret stash of W2-45S's???  To avoid any more excessive heat just in case, for tonight, I have just left out this mirror entirely, so the whole MC WFS beam is dumped in the Black Hole.  The WFS also have aluminum beam dumps in front of them to prevent light going in.  None of this affects the MC Refl path, so the MC can still lock nice and happily.

10325   Fri Aug 1 22:56:27 2014 KojiUpdateGeneralBeam lost in the chamber???

I was investigating several issues on the IFO. As many of you noticed and not elogged, ITMX had frequent kicking without its oplev servo.
Also I had C1:LSC-TRY_OUT flatted out to zero even though I could see some fringes C1:SUS-ETMY_TRY_OUT.

Restarted all of the realtime models (no machine reboot).

Now I don't find any beam on REFL/AS/POP cameras.

If I look at BS-PRM camera, I can see big scattering, the beam is in the BS chamber.
I jiggled TT1 but cannot find neither a Michelson fringe nor POP beam.

So far I can't figure out what has happened but I'm leaving the lab now.

IMC is locked fine.
I can see some higher order mode of the Yarm green, so the Y arm alignment is no so far from the correct one.

11839   Wed Dec 2 17:14:33 2015 yutaroUpdateLSCBeam on POX11 is possibly not centered well

I checked how POXDC level changes when the angle of ITMX is varied. ETMX was misaligned.

Then I found that in YAW direction the POXDC level is maximized but it doesnt have plateau, and in PIT direction it is not maximized so that it is at the slope and it doesnt have plateau, as shown in attached figures. These results indicate that the beam size on POX11 is not small enough compared to the size of the diode and it is not centered well.

11847   Fri Dec 4 12:33:52 2015 yutaroUpdateLSCBeam on POX11 is possibly not centered well

To focus POX beam on POX11 PD, I added an iris and a lens before POX11 PD as you can see in Attachment 1.

It seemed that the beam is well focused, but the behavior of POXDC has not changed, as shown in Attachments 2 & 3.

11850   Fri Dec 4 23:02:13 2015 yutaroUpdateLSCBeam on POX11 is possibly not centered well

[yutaro, Koji]

Now, the beam on POX11 PD is well centered and well focused.

We found out why POXDC had behaved as reported in elog 11839. There were a few reasons: the beam was not focused enough, hight of a mirror was not matched to the beam well, path of the light reflected by misaligned SRM was occasionally close to the path of POX beam.

Then, What we did is following:

- changed orientation of SRM slightly

- changed the hight of the mirror whose hight had not matched well, by changing the pedestal (hight of which mirror was changed is shown in Attachment 1.)

- put a lens with f=250 mm (where the lens is located is shown in Attachment 1.)

- refined alignment for the POX beam to hit on the center of POX11 PD.

As a result, POX DC level behaved as shown in Attachment 2&3 when the orientation of ITMX was varied (Attachment 2: POX DC vs ITMX PIT, Attachment 3: POX DC vs ITMX YAW).

You can see broad plateau when varied in both PIT and YAW directions, and the beam is at the center of the plateau if ITMX is aligned ideally.

8331   Fri Mar 22 01:28:56 2013 ManasaUpdateLasersBeam profile of NPRO from ATF

The NPRO from ATF has been installed on the POY table.

I have been making measurements to characterize the beam profile of this laser. I am using an AR coated laser window as a beam sampler at 45deg and the razor blade technique to measure the beam size along z. Details of the procedure along with analysis and results from this will follow.

12081   Mon Apr 18 00:29:00 2016 gautamUpdateGeneralBeam profiling + injection current scan

Summary

I've finished up the remaining characterization of the repaired 1W Innolight NPRO - the beamscan yielded results that are consistent with an earlier beam-profiling and also the numbers in the datasheet. The output power vs diode current plot is mainly for diagnostic purposes in the future - so the plot itself doesn't signify anything, but I'm uploading the data here for future reference. The methodology and analysis framework for the beamscan is the same as was used here.

Attachment #1 - Beam-scan results for X-direction

Attachment #2 - Beam-scan results for Y-direction

Attachment #3 - Beam profile using fitted beam radii

Attachment #4 - Beam-scan data

Attachment #5 - Output power vs Injection current plot

Even though I remember operating at a diode current of 2.1A at some point in the past, while doing this scan, attempting to increase the current above 2.07A resulted in the "Clamp" LED on the front turning on. According to the manual, this means that the internal current limiting circuitry has kicked in. But I don't think this is a problem as we don't really even need 1W of output power. This is probably an indicator of the health of the diode as well?

Attachment #6 - Output power vs Injection current data

It remains to redo the mode-matching into the doubling oven and make slight modifications to the layout to accommodate the new laser + beam profile.

I plan to do these in the morning tomorrow, and unless there are any objections, I will begin installing the repaired 1W Innolight Mephisto on the X endtable tomorrow (18 April 2016) afternoon.

511   Mon Jun 2 12:20:35 2008 josephbBureaucracyCamerasBeam scan has moved
The beamscan has been moved from the Rana lab back over to the 40m, to be used to calibrate the Prosilica cameras.
7367   Sat Sep 8 00:04:53 2012 JenneUpdateGeneralBeam scan measurement plan - to do Monday morning.

[MikeJ, Jenne]

We have a plan for how we're going to measure the beam after PR3.  Mike is going to write up a nifty program that will spit out the waist of the beam if you give it a bunch of razor blade measurement data.

Since the beam bounced off of the pitched ITMX is coming out of the chamber so high, it's kind of a pain to setup optics to steer the beam down the walkway next to the Yarm.  So, I have a new vision.

I think that we can get the beam right after PR3 onto the PRM/BS oplev table using 3 clean mirrors (of which we have many spares, already clean).  Once on the oplev table, we can put a 2" Y1 mirror to steer the beam down the walkway, after taking off the short east side of the table.  Then we can use the little breadboard on the mobile blue pedestal for the razor blade / power meter setup.

The razor blade on a micrometer translation stage will be the first thing on that table that the beam sees. Then, a 2" lens to get the beam small enough to fit on the power meter.  Then, obviously, the power meter.  We can measure the distance between the oplev table and the razor blade using the laser range finder, which has pretty good accuracy (it's sub-centimeter, but I don't remember the exact number for the precision).

A lens is not okay if we're trying to get the beam directly onto the beam scanner, since it will distort the beam.  However, as long as the razor blade is before the lens, and we're just using the lens to get the full intensity of the non-obscured part of the beam onto the power meter, I think using a lens should be fine.  If we don't / can't use a lens, we're going to run into the same problem we have with the beam scanner, since the power meters all have a fairly small aperture.  Even the big 30W power meter's aperture will be on the order of the size of the beam, so we won't be able to guarantee non-clippage.

The main problem I see with the technique as I have described it, is that the beam is going to hit 4 mirrors (3 in-vac, one outside) before going to the razor/lens/power meter.  We have to make sure that we're not clipping on any of those mirrors.  Also, this measurement version takes the beam after PRM, PR2 and PR3, but not after the BS and ITM.  I don't think we're concerned with either of those 2 optics, (especially since this is refl off the front of the BS, so won't see any potential clipping on the BS cage), but just in case we are, this measurement isn't so useful, and we'd have to come up with a different way of placing the mirrors on the in-vac tables to get a beam bounced off  of  a yaw-ed ITMX.

Perhaps it would be easier to just go with the pitched ITMX version of the measurement, but I could use some ideas / advice on how to mount mirrors and lenses ~4 feet off the ground outside of the chambers, and not have them waving around on skinny sticks.

EDIT: Another idea is to instead use the beam transmitted through the BS, put a single clean steering mirror in the ITMY chamber, and get the beam out of the ITMY door.  This could either be the beam before the ITM, or we could yaw the ITM a little and take the reflected beam.

7369   Mon Sep 10 08:50:35 2012 SteveUpdateGeneralBeam scan measurement plan - to do Monday morning.

I misaligned ITMX pitch on Friday and brought out the beam at 44" height. The beam was bouncing to much. I only realized it this morning why. The OSEM voltages are 1.8, 1.7, 0.2 and 0.9V  Even with a stable 8-9 mm diameter beam you would be clipping

on the beam scanner 9 mm aperture. You can bring out the beam with one mirror right after  PR3, just remove  PRMOP2

14018   Tue Jun 26 10:50:14 2018 poojaUpdateCamerasBeam spot tracking using OpenCV

Aim: To track the motion of beam spot in simulated video.

I simulated a video that moves the beam spot at the centre of the image initially by applying a sinusoidal signal of frequency 0.2Hz and amplitude 1 i.e. it moves maximum by 1 pixel. It can be found in this shared google drive link (https://drive.google.com/file/d/1GYxPbsi3o9W0VXybPfPSigZtWnVn7656/view?usp=sharing). I found a program that uses Kernelized Correlation Filter (KCF) to track object motion from the video. In the program we can initially define the bounding box (rectangle) that encloses the object we want to track in the video or select the bounding box by dragging in GUI platform. Then I saved the bounding box parameters in the program (x & y coordinates of the left corner point, width & height) and plotted the variation in the y coordinates. I have yet to figure out how this tracker works since the program reads 64*64 image frames in video as 480*640 frames with 3 colour channels and frame rate also randomly changes. The plot of the output of this tracking program & the applied signal has been attached below. The output is not exactly sinusoidal because it may not be able to track very slight movement especially at the peaks where the slope = 0.

3864   Thu Nov 4 17:57:27 2010 steveUpdateGeneralBeamScanner is working again

Koji, Suresh and Steve,

The beam scanner is back from repair.  Koji and Suresh helped to move the I/O address jumpers on the interface card from default position  300 to 320

It is working again.

14058   Thu Jul 12 15:15:47 2018 SandrineUpdate Beat Note Measurements for Cavity Scans

(Gautam, Sandrine)

We calculated the expected power of the beat note for Annalisa's Y arm cavity scans.

Beat Note Measurement

We began by calculating the transmitted power of the PSL and AUX. We assumed that the input power of the PSL was 25 mW and the input power of the AUX was 250 uW. We also assumed a loss of 25 ppm for the ITM and ETM. We used T1 = 0.0138 and T2 = 25 x 10-6.

$P_{t} = \frac{t _{1}^{2}t_{2}^{2}}{1+r_{1}^{2}r_{2}^{2}-2r_{1}r_{2}}$

$t = \sqrt{T}$

$r = \sqrt{1-T-L} = {\sqrt{R}}$

The transmitted power of the PSL is approximately 100 uW, and the transmitted power of the AUX is approximately 0.974 uW.

$P_{t}^{PSL} = 100 uW$                          $P_{t}^{AUX} = 0.974 uW$

The beat note was calculated with the following:

$P_{beat} = 2\sqrt{P_{PSL}P_{AUX}} = 20 uW$

The  expected beat note should be approximately 20 uW.

10333   Tue Aug 5 19:05:41 2014 AkhilUpdateGeneralBeat Note Testing on EPICS Channels

Finally,  the efforts put in the Frequency Counter paid off . I tested the working of both the FC and EPICS channels that I created by displaying the beat note on MEDM screens. EricQ helped me locking the X arm ( Y arm free) thus acquiring only the X arm beat note from the frequency counter. We plotted the beat note on MEDM and clearly could see a stable beat note when the arm was locked. Now it can be said that the FC(two of course) can replace the spectrum analyzer outside and also get the beat-note frequencies  into EPICS channels. The channel names of these two beat note frequencies are:

X Arm:          C1:ALS-XBEAT_FREQ_MHZ

Y Arm:          C1:ALS-YBEAT_FREQ_MHZ

(Note: There are many problems in alignment of the arms and we could have beat note only for some time after putting a lot of effort).

8721   Wed Jun 19 01:45:49 2013 ManasaUpdateGreen LockingBeat frequency sweep for 3FSR

Measurements:

1. Calibrating offset :

I measured the shift in the beat frequency while scanning through the offset. Offset stepped by 50 resulted in 1MHz shift of the beat frequency.

2. Anti-whitening filter for beatbox output:

I made an anti-whitening filter for the beatbox output in the ALS_BEATX_FINE_I module by inverting the whitening filters that Jamie had installed in the beatbox earlier (elog).  I have kept the old anti-whitening filter in the module as well for the time-being because the new anti-whitening filter was not as good as the old one in stabilizing the servo (large error signals and unstable ALS).

3. Beat frequency scan for 3FSR:

With ALS loop enabled, I did an offset sweep corresponding to 3FSR (FSR = c/2L = 3.7MHz). The loop doesn't seem to be stable enough to reduce the arm fluctuation to get a resonance for IR. Time series of scan is shown below:

4. No-loop and in-loop spectrum:

I measured the spectrum of the error signal (C1:ALS-BEATX_FINE_I_IN1) with ALS loop enabled and disabled. To suppress the peaks at 3.2Hz and 16.5Hz, I turned ON the corresponding filters. I have recorded the error signal spectrum with only 16.5Hz res gain filter turned ON. Turning ON res gain 3.2Hz filter kicked ETM.
Spectrum of error signal shown below:

To resolve:

1. What is wrong with the new anti-whiteing filter?

2. Why would the res gain filters kick ETM and show no noise suppression?

11470   Thu Jul 30 15:58:00 2015 ericqUpdateLSCBeat note Alignment fluctuation effects measured
 However, I wonder how much of the low frequency noise can be explained by instability of the beat alignement on the PSL table, and how this might be quantified.

I followed my hunch, and the truth comes out.

I recalled that the aLIGO demod board has a handy DB9 output on the back panel for the detected power at the RF and LO inputs. I hooked this up into the BEATY ADC channels while checking the ALSX spectrum in IR lock.

This is assuredly the limiting factor in our ALS sensitivity.

Note: I'm calling the fluctuations of the beatnote amplitude "RF Amplitude RIN," to put things in reasonble units. I haven't looked up the board's conversion of dBm to V, but the LO should be around 0dBm in this measurement.

The coherence between the phase tracker output and the LO amplitude is significant over a broad range, mostly dipping where real cavity motion peeks up into the spectrum.

Also, the feature from 10-100Hz in the RIN spectrum is one I've often seen directly in ALS spectra when beatnote alignement is bad or the beatnote frequency is high, convincing me further that this is what's to blame.

So: what do we do? Is there anything we can do to make the green alignment more stable?

11478   Tue Aug 4 03:02:30 2015 ericqUpdateLSCBeat note Alignment fluctuation effects measured

Notes from tonight's work:

• PMC alignment tweaked. Not much gained
• WFS/MC2 offsets tweaked after recentering beams on WFS and some hand alignment.
• Vertex oplevs realigned for the first time in forever
• With an RF coupler, measured the X green beatnote to be +5dBm into the splitter. This resulted in -33dBm at the control room analyzer.
• Switched the ALS demod board inputs, from piping the delayed signal to the RF input, to sendingit to the LO input. This was motivated by wanting the mixer closer to compression, hopefully to reduce beatnote amplitude fluctuation sensitivity. This won some noise >100Hz.
• This led to record ALS noise levels - X:217Hz, Y:203Hz
• +2dBm into the board still leaves us some headroom for futher amplification. Board schematic lists +10dBm LO as "nominal," but maybe this isn't worth it...
• PRFPMI locking is still stalled at bringing in the RF signals. Debugging continues.
• Some beatnote amplitude fluctuation investigations (see below)
• Note to self: demod board schematics include an unspecified RF lowpass. Check out what got stuffed in there.

I've explored the beatnote fluctuations a bit further.

First, I realized that we already had a channel than functions much like an RF level monitor: the phase tracker Q output. I verified that indeed, the Q signal agrees with the RF monitor signals from the demod board within the phase tracker bandwidth. This simplifies things a little.

I also found that the Y beat suffers a fair bit less from these effects; which isn't too surprising given our experience with the alignment stability.

One possible caveat to my earlier conclusions is that the beatnote amplitude could be fluctuating due to real RIN of the green light transmitted through the cavity. In fact, this effect is indeed present, but can't explain all of the coherence. If it did, we would expect the DC green PDs (ALS-TR[X/Y]) to show the same coherence profile as the RF monitors, which they don't.

The next thing I was interested was whether the noise level predicted via coherence was realistic.

To this end, I implemented a least-squares subtraction of the RF level signal from the phase tracker output. I included a quadratic term of the RF power, but this turned out to be insiginficant.

Indeed, using the right gain, it is possible to subtract some noise, reproducing nearly the same spectrum as the coherence based estimate. The discrepency at 1Hz is possible from 1Hz cavity RIN, as suggested by the presence of some coherence with TRX.

However, this is actually kind of weird. In reality, I would've expected the coupling of RF level fluctuations to be more like a bilinear coupling; changing the gain of the mixer, rather than directly introducing a linearly added noise component. Maybe I just discovered the linear part, and the bilinear coupling is the left over low frequency noise... I need to think this over a little more.

4502   Thu Apr 7 21:58:57 2011 AidanSummaryGreen LockingBeat note amplitude

Having convinced myself that the green Hartmut PD is giving an acceptable response at RF frequencies I decided to double-check the beatnote at IR (fiber transmission from the X-end beating with the PSL). This took a while because I had to realign the beam into the fiber at the X-end (I had a PD monitoring the output from the fiber on the PSL table and 40m of BNC cable giving me the signal from it at the X-end).

Eventually, I managed to get a beatnote on the PD. At first there was no signal at the temperature calculated using Koji and Suresh's calibration, but it turned out that the mode-overlap wasn't good enough on the PD. Now I can clearly see beats between a couple of modes, one of which is much stronger than the other. I think we should use a frequency discriminator on the output from the IR PD to servo the end laser and keep the strong beat note within <100MHz of DC.

4534   Fri Apr 15 22:54:20 2011 Aidan, BryanUpdateGreen LockingBeat note amplitude on Vertex PD

I was investigating the beat note amplitude on the vertex PD again yesterday. The incident power on the PD was 150uW in the PSL green beam and 700uW in the X-ARM green beam. With perfect overlap and a transimpedance of 240, I expected to get a beat note signal of around 25mV or -19dBm. Instead, the size was -57dBm. Bryan and I adjusted the alignment of the green PSL beam to try and improve the mode overlap but we couldn't do much better than about -50dBm. (The noise floor of the PD is around -65dBm).

When we projected the beams to the wall of the enclosure, the xarm beam was 2 to 3x as large as the PSL green beam, indicating that the beam size and/or curvatures on the PD were less than ideal. There is a telescope that the XARM beam goes through just before it gets to the PD. I mounted the second lens in this telescope on a longitudinal translation stage. With some finagling of the position of that lens we were able to improve the beatnote signal strength to -41dBm.

Obviously the ideal solution would be to measure the beam size and RoC of the PSL beam and XARM beams and then design a telescope that would match them as precisely as possible because there's still another 20dB signal strength to be gained.

ELOG V3.1.3-