I took a bunch of scans of the PSL with the Beamscan and compared them with some razorblade occlusion measurements

The first steering mirror after the beam exits the PSL was removed, and data was taken at this point in the beam path.

The numbers for the waist derived from my razorblade measurements are on the plot in green. The disagreement seems not horrible to me.

We should still fix the beamscan, and think about buying another (newer) one.

I am told that the beamscan axis drawn on the head (labeled "1" and "2"), not the slit axis is what sets the direction of the field you are sampling. Data for both vertical and horizontal spatial modes of the beam are included. There is some ellipticity to the beam that I will have to account for in choosing my (new?) mode matching solution.

Error bars are included on the green point, they are just small.

The 1W NPRO is, for the moment, being used for both the FS and Gyro experiments. Aidan and I began aligning the optics for the FS experiment today.

The beam is first passed through a quarter-waveplate to linearize its polarization. A 50-50 beamsplitter picks off the beam for the Gyro experiment. The transmitted beam (for FS) is then attenuated by a half-waveplate and PBS. We steer the transmitted beam through a lens, a Faraday Isolator, and another lens to collimate it.

A photograph of the setup is attached.

We plan to direct the beam through an AOM and couple it to the fibre so we can characterize the acquired phase noise.

 The following image contains approximations of the changes we made to the PSL steering mirrors (~5 degree accuracy)

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.

 Using the setups in the quoted post, I took manual beamscans 23" in front of the PSL enclosure, before the first steering mirror, and fit P = A erf(B*x + C)

 I measured the relative position of my razorblade with a micrometer and calculated the error from an estimated uncertainty of it's angle. This seemed to agree with repeatability of measurements for a given experimental state. Uncertainty < .002"

I watched the Power meter for ~ 60 seconds for each measurement, it fluctuated around some point and seemed to not be drifting @ DC, so the upper and lower error bars of each point included are the bounds of the fluctuation of the power meter. These were less than +/- 5mW about my points, so a fractional uncertainty of about 2% at my maximum power.

I got waists of:

Vertical: 799 +/- 4.5 microns

Horizontol 827 +/- 1.2 microns

Attached plot includes data w/ error and functional form of fit

As expected, my Chi^2 is "bad" since I am fitting the input beam to the PMC with a 00 mode description of the waist, which ignores all higher order modal content.

At Anamaria's request, I recorded the diode powers (and temperatures) of the PSL.

~5 min after power up they were:

temp/power

20C  / 29.8W

23.8C / 28.6W

24C / 25.2W

25C / 27.8W

6 hours later they were

20C / 29.0W

23.8C / 28.1W

24C / 24.8W

25C 27.3W

I will add pictures of what knobs we touched and how much each was turned by here

I got about a .002" error using a micrometer with my other setup, I expect this will suffice. If the errors in position end up too large I will use the new setup.

Actually, it would be nicer if we have a calibrated micrometer screw for the thread.
Connor and I tried to make another set of the razor blade arrangement with a micrometer.
We put it on the PSL optical table. Please use it.

Since the beamscan is in a questionable state of scanny goodness, Koji advised that I do some razor blade occlusion power measurements of the beam and then fit an erf to it to find the waist. I took data with the tinker toys pictured below.

I will compare these results with some beamscans results to verify (hopefully) that the beamscan is outputting useful results, not lies.

Koji came down to the dungeon to help me with the "what is the junk coming out of the PSL" problem.

We noticed that the beam right after the PBS looked funky, and the beam before the power amplifier stage inside the PSL looked fine.

We decided to realign the optics inside the PSL. We only touched the two steering mirrors immediately preceeding the power amplifier.

We got a 35% increase in power and the output mode looked cleaner to the eye. (No more solar flares)

We are now happy.

Alberto came over to have a look at the laser and discovered that the diode temperature was continuously increasing the longer the laser was kept on. The crystal temperature remained constant. He turned off the laser and shut the shutter, jiggled the cable connected to the laser a bit, and turned it back on. Lo! The temperature no longer increased...

So for the time being the laser seems to be fixed. If these problems start happening again, however, I may have to do some more rigorous troubleshooting/actually find out what's causing the problem.

     Aidan was in Hanford this week, so I switched gears and worked mostly on modematching the 35W PSL with Dmass.  This requires passing the beam through a couple of lenses to alter the waist size and location before it enters the PMC. Last year, he took some beamscans post-lenses. We wanted to see if this data matched with the pre-lens beam parameter. I used ray transfer matrices to perform the inverse calculation. We found a mismatch between the calculated and expected waist location, which could not be fully explained by the engineering tolerance of the lenses or by the lens orientation.

     Dmass also noticed something funny about the head of one of the lenses, so he made some changes to that and made more beamscans that we will look at.

     There are a number of objectives for the upcoming week:

     1) We believe that the 1W NPRO is elliptically polarized. I learned about Jones vectors and Jones matrices, which are a convenient linear-algebraic representation of a beam's polarization and how it changes as it passes through various optics. The beam can be linearly polarized by passing it through a quarter-waveplate (QWP) whose fast axis is correctly angled. To test this, I will pass the beam through a QWP, and aligned a half-waveplate (HWP) and polarizing beamsplitter (PBS) to find its extinction ratio for various QWP angles. (The extinction ratio is the ratio of the minimum to maximum transmitted powers of the beam as the HWP is rotated.)

     2) I'll work on coupling the 1W NPRO into a 50m fiber.

     3)I'll align a Mach-Zehnder interferometer to measure the phase noise of the 1W NPRO, and also single pass the beam in one arm through the 50m fiber and characterize the phase noise it acquires.

 I took the power supply over to the 40m to see if Alberto's laser would work when hooked up to it. It did, so I suspect that the problem lies with the laser rather than the power supply. Alberto was able to get double the drive current that we were getting, so that is also suspect. He said the "ADJ" readout (power adjustment) on the supply was usually set to zero, but when the "Pwr" readout (supposedly the power coming out of the laser) is changed, it changes the ADJ and drive current and anything else which would obviously be associated with power. I hooked up the power supply to my laser again and here's what I found:

-It lases for short periods of time, usually <5 mins, before it stops.

-It lases for longer periods of time at higher drive currents.

-I still can't get more than 1.02 A and less than 0.30 A out of the power supply.

-The "Pwr" display on the supply still doesn't correspond to the power as measured by the Ophir powermeter.

My next steps are to see if Alberto can come and take a look, in case I'm doing something on the operator side which is obviously wrong. I will also consult with Rana.

A while ago, Dmass made some beamscans of the PSL beam after it passed through two lenses. Here is a link to the Dmass Modematching elog.

We wanted to make sure that these measurements are consistent with what we think the incoming beam parameter is.  I wrote a matlab file which works backwards from his data to find the incoming beam parameter using ABCD matrices.  I used the focal lengths indicated on the lenses.

I found a disagreement of 20cm in the PSL waist location with a yesteryear elog entry  Dmass checked to see if my computation matched with his, and got the same result.

The first thing that we thought might have been wrong is that the focal lengths need to be switched, but switching them didn't significantly our change our results (in fact, it made them worse).

We also suspected that the engineering tolerance of the lenses might allow for the difference. I tried changing the focal lengths of the lenses by 10% for both lens orientations, but the computations made only small changes to our original result, so this is probably not the culprit.

 We should get back to trending the lab temperature. I think there are some long standing problems with the HVAC setup. It would help to quantify this.

I'm having some issues with the 495 mW NPRO, or possibly with its power supply. I ran the laser for about 15 minutes at 2 mW while doing some aligning. I closed the shutter to move a mirror, and upon opening the shutter the laser was no longer lasing. The power supply read 0.0 A driving current. I closed the shutter again and checked all connections between the laser and the power supply. All in order. I opened the shutter and turned the dial a bit on the power supply, and lo and behold the current was back up to 0.46 A, the lasing threshold, but still no light coming out.

The drive current jumped around a lot, sometimes to 0.0 A, and even when I put it up to around 0.54 A, which the laser should definitely be lasing at, nothing came out the aperture. The internal laser temperature was normal and not fluctuating. The lab itself is pretty warm today, in the 70s. Unless someone changed the temperature, it felt like the heat was on. I don't think this would have any effect on the laser, but I'm not really sure.

So, I'm going to search for the manual online and see if anyone over at the 40m had problems with this power supply.

 Hey Alex,

I've got a couple of questions (just for my own understanding).

- I thought the frames were supposed to overwrite old data. Why then  

did the disk appear full? And is it likely to appear full in future?  

If so how do we deal with it?

- why did you reduce the number of directories in /frame/full to 60?

Thanks for your help,

Aidan.

Aidan suggested that we try to characterize the beam width of the 1W NPRO again, this time operating the laser at high power and attenuating the beam with a half-wave plate and a polarizing beam splitter.  I aligned the optics such that at full output power (~1.19W), the power incident on the BeamScan is 145 mW.

There are a number of things I noticed about the beam profile around 10" from the laser aperture that I don't know how to deal with, so I decided not to make measurements until working things out.

While the profile of the beam is much cleaner now than it was before when we measured beam width at low power output, the width of the beam seems to depend on the driving current to the laser.  At 1.2A driving current, the beam diameter was roughly 1650 micrometers.  The width dropped down to around 1300 micrometers at 2A driving current, and then climbed back up to 1500 micrometers at full power output with 2.38A driving current.

Also, as David noted, the beam width fluctuated by up to 40 micrometers when moved to different places on the head.

This was also from Alex:

Too late, I deleted /frame/full data already, sorry.

So I changed the number of full frames dirs from 120 down to 60 and
restarted the frame builder and c2atf front-end. Looks like the data is
written out to disk now. Please check it out.

Alex

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.

I measured the waist of the input beam to the PMC after putting the mode matching lenses back. In the process of this, I noticed some problems with the beamscan.

I played with the beamscan axis until I found something that looked gaussian to the eye, and took a series of measurements, and fit the data (see attached).

I calculated the expected power loss from mode mismatch a la Dana Anderson's paper on cavity (mis)alignment and got some results:

I get estimates for power losses of:

6% due to waist position mismatch

12% due to waist size mismatch

NOTA BENE: The formulas in the Anderson paper start to break down as the linear approximations break down, which is happening for us...

If b is my mismatch parameter in waist position, my condition for the linear approximation is:

lambda*b/(pi*waist^2) <<1          but the LHS quantity is .492

and if w0' and w0 are my input beam and cavity waists, respectively, my condition is:

w0'/w0 - 1 <<1                            but the LHS is .34 here

Summary: I don't know how bad the Anderson formulas are in this regime of mismatch, but I can clearly do better in my mode matching. Next step: mode match/fix lens positions

Attached Image:

RED is roughly the PMC waist and position (based on the 40m PMC's waist - we have no measurement of this PMC's waist size yet afaik: put this on to do list)

GREEN is weighted least squares fit

BLUE is the data

We made a set of beam width measurements of the 495 mW laser using the Beamscan. All values were taken at (1/e^2) of the peak intensity, in micrometers. The distances were taken in units of inches (no metric-based rulers).

Here is our data: 

Distances (in inches): [2 3 4 5 6 7 8 9 10 12 14 16 18 20 22]

Beam Diameters (in micrometers): [357 364 413 448 528 608 690 758 854 1043 1216 1403 1624 1812 1999]

Again, we least-squared fit the data to the characteristic curve parametrized by the waist location and size, and found that the waist size is 178 micrometers, located 4.6 cm. in front of the aperture.

THINGS TO NOTE:

First, DMass mentioned he suspects that the beamscan is impaired, so we're not sure how well it is acting.

Second, Rana noted that the best indicators of the parameters of interest are data points taken far from the waist, where the beam width grows close to linearly with distance.  We took  lots of data points in the nonlinear regime, as seen on the attached plot. It might be a good idea to take more data points further away and refit our data.

Lastly, this laser is more stable than the 1W NPRO, with fluctuations of only 1-3 micrometers around the reported beam width values rather than the 40-50 we saw for the 1W.

The directory for our code is /users/cmooney/Beamscan_495mW.m

Here is the code:

%This is a graphical representation of beam width data taken for the 495 mW NPRO
%Laser, taken on July 8, 2009.

%W1 is the full width at 1/(e^2)*(peak intensity) taken at 1.00A driving
%current (around 150 mW) for the axis A1 as labelled on the BeamScan. Measurements are
%in micrometers.

W1 = [357 364 413 448 528 608 690 758 854 1043 1216 1403 1624 1812 1999];

%S1 is the standard deviation of the measurements given in W1.

S1 = [0.3 0.3 0.4 0.4 0.4 1.2 0.8 0.8 1 1 2.7 2.9 1.6 1.6 2.2];

d = 2; %distance from laser aperture to its base, from which it is easier to measure distance
D = [0 1 2 3 4 5 6 7 8 10 12 14 16 18 20]; %distances (in inches) at which measurements were taken
Ds = 2.54*(D+2)/100; %conversion to meters

W1s = 0.5*W1/(10^6);
S1s = S1/(10^6);

errorbar(Ds,W1s,S1s,'.')
title('Beam Width vs. Distance from Laser');
xlabel('Distance (m)');
ylabel('Beam Width (m)');

%This is a brief program to assist in the measurement of width of a
%Gaussian beam. Its wavelength is 1064 nm.

xdata = Ds;
ydata = W1s;
 
a0 = [.0001, .2]  % Starting guess
[a] = lsqcurvefit(@myfun,a0,xdata,ydata)

w_0 = a(1);
Zo = a(2)
L = 1064*10^(-9);
Dmax = 1;
sh = 0.35;
dt = (Dmax+sh)/10000;
Z = -sh:dt:Dmax;

Wt = w_0*(1+(((Z+Zo).*L)/(pi*w_0^2)).^2).^(1/2);

hold on;
plot(Z,Wt);

          The majority of this week has been spent learning about sources of intensity noise and the methods we use to characterize it.  The sources that I focused on were the "electronics noise" associated with various instruments (this week the instrument used was a photodetector, contributing fluctuations in intensity called "dark noise"), shot noise, and the noise produced by source itself (in our case, a 495 mW NPRO Laser).

          The theoretical method of characterizing a noisy time series is called a Power Spectrum, which is defined as the Fourier transform of the series' autocorrelation.  Intuitively, this is a frequency-domain representation of the extent to which a given frequency is represented in the time series.  Experimentally, it is more convenient to take advantage of a couple of theorems relating the Power Spectrum of a time series to its Fourier transform over a finite time interval;  The SRS spectrum analyzer that we used this week calculates the discrete Fourier transform of an input signal over a given time interval, squares that value, and divides by the time interval to get an estimation of the Power Spectrum.  Typically, we run the signal into the spectrum analyzer for many of these time intervals, and the values computed over each of these intervals are averaged.

          We measured the dark noise and the total intensity noise of a 495 mW NPRO laser using a PDA10CS photodetector, and made a theoretical prediction for shot noise based on the output power of the laser.  The data we collected is contained in yesterday's entry.

          Aidan has been working hard on getting the DAQ to its operating point, which will make measurements such as those described above easier to make.

          The plan of action for the upcoming days is to set up a Mach-Zehnder Interferometer for the same laser and characterize the phase noise its beam acquires, hopefully with the assistance of the DAQ.

We have mirrors! And clamps! And posts! In short, everything we need to actually put all the optics in their proper places. Thus, this week I have successfully placed the steering mirrors and the high reflectance mirrors into their mounts without touching/breaking any of them, and soon I'll be clamping them in their proper locations.

Connor and I  found out that Aidan's laser isn't behaving itself. The manufacturer specifies the waist as being in a different location than where we calculated it to be. We sent the beam through a half-wave plate and then a polarizing beam splitter and then measured the power along each axis, and the ratios are strange. We can't get the beam to be entirely transmitted along one axis by rotating the half-wave plate, like we should be able to if the beam is coming out linearly polarized. So the hypothesis is...it's not coming out linearly polarized. It may be elliptical. For the time being we're going to split the beam from the other NPRO and use it for both experiments, at least while the alignment is taking place. In the case of the gyro, we'll actually be feeding back to the laser and altering its frequency, so we'll definitely need separate lasers for each experiment at that time.

The 495 mW NPRO's SOP has finally been (mostly) approved and it first lased on Monday. This laser's power supply is a bit weird - the display for the power it thinks the laser is putting out doesn't match at all with what the powermeter actually says the laser is putting out. So we're not paying attention to the power display. The drive current goes up to 1.00 A, and at this maximum current, the laser is putting out ~150 mW. Apart from not being able to get a higher power than this, the laser is fairly well behaved - the power fluctuations as measured by the powermeter are small. The results of output power vs. drive currentmeasurements are on the eLog.

Connor and I also measured the electronics noise and intensity noise at various different powers, and then did a theoretical shot noise calculation for each of these. The setup and procedure are described in more detail in a recent eLog entry, which also includes graphs and the matlab code used to generate them.

Over the next week I'll be setting up the optics table for a simple PDH lock using a fabry-perot cavity, aligning the laser, and setting up the proper feedback using the DAQ. (Which I'll need to talk to Dmass about).

Oh, and we found out yesterday that Connor and I can't do any hazardous tasks in the lab without supervision, which includes aligning the lasers, even at low power. Aidan and Alastair will both be gone from tomorrow until next week Friday, so this poses a slight challenge. Hopefully Dmass will be around?

That's about it for now, I think.

We used an SRS Spectrum Analyzer in parallel with an oscilloscope to measure various sources of noise in the 495 mW NPRO laser. We sent the beam into a PDA10CS photodetector and fed that signal to the spec analyzer and the scope. We measured the dark noise, and then the total noise at 2 mW, 4 mW, 7mW, and 9mW. We then did a theoretical calculation for the shot noise, as follows:

N = (Po*dt) / (h*f)

dN = sqrt(Po*dt / h*f)

dE = sqrt(h*f*Po*dt)

dI = dE*(Responsivity of PD)

dV = dI*(Gain of PD)

We plotted all three of these noise sources in matlab. The plot and the code are attached. The directories are:

/users/mstephens/NPRONoise.m

/users/mstephens/495mW_NPRO_Noise.pdf

Fixed!

The problem was a typo that had cropped up in /cvs/cds/caltech/chans/daq/C2ATF.ini when I was editing this file. I had to fix that file and reboot oms to get the frame builder working again. Now it appears to be fine - I can telnet into fb0 again.

[controls@ws1 ~]$ telnet fb0 8087

dadq> shutdown

I tried to reboot the frame builder last night, as below, and now it won't restart and I can't log into it. If I can find the box then I can try to physically reset it.

[controls@ws1 ~]$ telnet fb0 8087

dadq> shutdown

 In general, zip and upload your files and matlab code. You or someone like you may want it later, and may really want to be able to get it remotely.

We characterized the power output vs. drive current of the 495 mW NPRO laser for the gyro experiment. The current supply  goes up to 1.00 A. Here is our data:

C = [0.46 0.52 0.60 0.66 0.74 0.80 0.88 0.94 1.00];
Pd = [2 18 38 55 71 93 110 125 146];
Pu = [2 20 39 56 72 94 110 126 147];

C is drive current, Pd is lower limit on power output in mW, and Pu is upper limit.

We graphed the results and fit a line to it. The slope is 261.5 mW/A, and the intercept is -118.2 mW. The graph is attached.

directory is: \users\cmooney\Power495mW.m

The following equipment was from 58C (old mesa beam lab) into 58D during the clean out of the former lab.

2x SR560s ([Ligo Project Property (LPP) C20862, Caltech 44961], [LPP: n/a, Caltech 44782])

2x Phillips PM 5193 programmable function generators (0.1 - 50MHz): ([LPP: n/a, Caltech 9313], [LPP: C20365, Caltech: 1348])

1x SRS DS345 function generator (<30MHz): (no tag - serial # 36560)

1x Tektronix AFG3102: (no tag - serial# AFG3102 C020795)

1x HP 8656B signal generator 1-990MHz: (LPP: n/a, Caltech 23616)

These have all been labelled "John Miller Lab" to indicate where they came from. (None of the equipment was plugged in)

I've finalized the DAQ_MAP screen. All the current channels are accounted for. I've added some standard LIGO medm screen paraphenalia, such as the information button and the title bar.

I'd like to incorporate this into the build of a front end so that this screen is generated automatically. I'm a bit stumped as to how to get the LOST/SAVED indicators to work automatically. Maybe we can write something that will run in the startup of fb0.

A couple of extra notes:

1. The names of the channels in the frame builder do not exactly match the names in EPICS. This makes it impossible to drag and drop channel names into data viewer. Example:

C2:ATF-QPD1_SEG1 is the  channel defined in Simulink. C2:ATF-QPD1_SEG1_INMON is the channel as it appears in EPICS and C2:ATF-QPD1_SEG1_IN1_32768 is the channel as it appears in the frame builder. Can we add a channel in the frame builder that has the same name as the corresponding EPICS channel?

2. There seems to be a problem with CH32. It's working, in the sense that the channel exists, but when I plug the signal generator into the corresponding BNC connector on the DAQ I don't see any response on EPICS. Need to triple check that I haven't done made a typo anywhere.

I've added some indicators to the DAQ_MAP medm that show whether channels are saved to frame ("SAVED") or not ("LOST"). I'll have to add a routine to the frame builder start up so that these are updated whenever the frame builder is rebooted.

I've created an medm screen that displays the current data channels associated with each of the connectors on the front of the DAQ. Basically its supposed to make it really easy to figure out what each channel in the DAQ physically corresponds to. I've added a link (DAQ MAP button) to it on the main medm screen

Eventually this should be automatically generated every time we rebuild the front end. I'd also like to include an indication on there of the units of each channel and whether they are in the frame or not.

medm screen: /cvs/cds/caltech/medm/c2/atf/C2ATF_DAQ_MAP.adl

Please do not edit this screen in the medm editor. I've added some comments to the file and moved the definition of each of the channels to the end of the file. The comments get erased when the screen is edited and the channel definitions get moved back to different places in the file.

There appears to be something screwy going on with the frame builder - have some things been compiled and others not? Either that or I don't understand the system well enough.

We plugged a signal generator output a 0.1Hz sine wave into CH9 of the DAQ. This showed up in Alastair's medm Gyro screen (C2ATF_GENCONT.adl) in channel C2:ATF-GENERIC_GEN1_INMON. When we want this written to the frame, however, I have to uncomment the channel C2:ATF-CTRL_SIG_1_IN1_32678 in /cvs/cds/caltech/chans/daq/C2ATF.ini. This channel shows up in Dataviewer and the 0.1Hz signal is clearly visible.

I suspect that things have been only partially compiled recently and we need a clean rebuild of the front end and daq and frame builder. Anyway, we can get signals at the moment so we're actually going to do something useful, like characterize the intensity noise of the NPRO.

Who was the author of the previous entry? It wasn't Connor apparently.

I've done a few things this week. Connor and I characterized his laser's beam divergence, the results of which can be found on a previous entry. I'll do the same measurement for my laser once we're allowed to turn it on. The table now has a mock-up of the Fabry-Perot cavity locking scheme, it's still missing a few mirrors but the gist of it is there. I also changed the setup for our actual gyro design. In order to increase the finesse of the cavity, we got rid of one of the partially transmitting mirrors in the triangular cavity. So there is now a setup with two highly reflective mirrors and one partially transmitting, and both the clockwise and the counterclockwise beams will be injected into that one. We're also going to set it up so the clockwise mode goes through the AOM twice in order to double the effect. My first progress report is attached to my 40m wiki page. (Sorry, no LaTeX yet, will figure that out).

Attached here is the new diagram for the gyro setup.

 FORMAT PLEASE!

I fired up the 35W, and everything was still working as per my last entry - we still could lock the PMC, and were generating small amounts of green.

• I replaced the old home made mode matching lens slider mounts with real slider mounts
• I then realized that I had no transverse adjustment with these sliders, which ended up being a royal PITA for alignment
• I went back to the old mounts and tried to restore their position very faithfully, but had not documented their placement
• I am now not aligned well into the PMC, and can't find the 00 - some combination of lens position adjustment and angular alignment should fix this.

I took a series of beam scans to find the waist size/position of the beam coming into the PMC and noticed a few things:

• The beam scan IS UNHAPPY <edit with specific error> when it boots up the software
• This *seems* to be making a number of features unavailable (i.e. the position dot, the contour plots, dual axis display...)
• All of the things that I was unable to get to work involved needing both axes of the beamscan to work.
• It seems like there is at least one ghost beam which is ~ on axis. I am unsure as to whether this is modal content of the PSL or a ghost from some optic.
• The horizontal axis was FUGLY in modal content; the near vertical was pretty, and resembled a guassian. <Pics to be attached>

NEXT:

• Troubleshoot: Look at the beamscan documentation regarding its startup errors/running the features that were "greyed out"
• Enter data into mode matching program - get desired adjustments to lens positions
• Verify orientation of lenses (both are plano convex, and I currently have the curved surfaces pointed towards each other)
• Once I get a lock to the 00 mode, do fine tune of mode matching and angular alignment by hand
• Move on to making my SHG more efficient, and maybe move up to tens of uW

We used the BeamScan to characterize the divergence of the NPRO laser as a function of distance. Measurements were taken at (1/e^2)*Imax. We then fit the data to the function characteristic of gaussian divergence to find the location and size of the waist. The results are shown graphically in the attached file. Extrapolating, we found that the waist is 21.5 cm behind the laser aperture, and the (virtual, assuming that the laser beam encounters a diverging lens before the aperture) waist size is 124 micrometers.

Here is our data:

The distances, measured in inches from the base of the laser, are

[0 0.5 1 3 5 7 9 11 13 15 17 19 21 23 25]. The distance from the aperture of the laser to the base is 0.75 inches.

The beam sizes, measured in micrometers along one axis, are

[1334 1399 1542 1655 1968 2234 2537 2785 3063 3359 3638 4001 4253 4561 4708]

The directories for each of the Matlab files used to generate a graph of the data and carry out a least-squares regression are

/users/cmooney/BeamScans.m

/users/cmooney/myfun.m

Over the course of the first week here I've done several things. The first thing we're going to try to do in the lab (once we have all our parts in) is lock a simple cavity using Pound-Drever-Hall. I've been reading some of the literature on that and familiarized myself with that technique. Through these readings, I've come across various terms and equipment used in optical setups that I was unfamiliar with, so I've become acquainted with those. I attended the laser safety training meeting and have started to find my way around the lab. Connor and I also began characterization of the Nd-YAG laser. While I will not be working with that one, I will have to do the same thing for the one I will be working with. We first made some measurements of its output power versus the drive current, and results from that can be found in an entry to the eLog on 6-23-09. Today we are going to use the BeamScan to figure out the divergence of the laser.

Various other things that I've done over the past week include learning how to work with Matlab and Linux (both of which I am relatively unfamiliar with), and attending talks about the LIGO project by Dr. Weinstein.

To use the small Nokia wireless device:

1) Connect to cdsrana

2) Check what the ip of the machine you want to use is (/sbin/ifconfig)   - 131.215.113.56 at the time of this entry

3) run an x-terminal on the nokia (under extras)

4) enter into the command line :   ssh controls@IP

5) It will prompt you for a password, enter.

you can now run simple medm screens of your design from anywhere with wireless access to the cdsrana network!

We measured the output of the FS NPRO Laser at drive currents between 1 and 2.4 A, with 0.1A imcrements. The OPHIR powermeter was used with a 50W head, and was set to the 0.8W-6W range. The model is L50A-SH. We took two sets of measurements. For the first, the curve found was non-linear, starting off shallow, then becoming steeper, and finally levelling off. We weren't sure why the curve exhibited this behavior and we took a second set of measurements to verify our results. For the second set, we took the maximum and minimum values of the power fluctuations at each current. We found an average power from these values and generated error bars.

C = [1.002 1.101 1.201 1.301 1.400 1.501 1.600 1.701 1.801 1.901 2.00 2.100 2.200 2.301 2.384];
Pd = [6 46 94 154 225 301 398 501 625 759 870 978 1062 1131 1191];
Pu = [9 49 98 158 229 312 405 514 679 772 890 985 1068 1140 1198];

C is an array of the current values in Amperes.

Pd and Pu are the lower and upper bounds of power ouptut , in milliwatts, measured  at the power meter.

The directory in which the above data was analyzed is /users/cmooney/power2.m

The chiller was making funny noises (tens of seconds time scale brief grating type noises - like if you took a piece of paper and let it touch a high speed fan). It was also below the "min fill level" line for water. I watered the thirsty beast and it is now quiet.

We may have been running the PSL with the chiller underfilled. I have been keeping it off lately for other reasons (the filters), though no longer feel the need to do so after talking to some people (Anamaria) about what they do at LHO. We may want to eventually change them, but we don't need DI water for the chiller.

I think it is fine to turn the PSL back on.

 I checked my files and could find no record of the delivery of the QWP and the partial reflector from CVI. The purchase orders were PO S064180 and PO S064169, respectively.