I saw that you guys are planning on turning the input mirror to get a Mach-Zehnder-type thing going... any plans to do that soon? I ask because this should give us the displacement noise directly, right?

In terms of the damage of the optics, I have never seen the CVI mirror is damaged by this level of the power density.

What I have seen was a newport BK7 cube BS melting with the 10W focused on the <100um waist radius.

 This is the noise of the cavity if we just lock the laser to the cavity using the fast actuator (no slow actuation) and look at the control signal to the laser.  I used a potential divider to reduce the voltage going to the spectrum analyser (I used 1.023kOhm and 9.32kOhm to give approx 10 times reduction).

The plot here is taking the V/rt(Hz) and multiplying it back up again to the full voltage, then converting to frequency using the piezo spec from the laser spec sheet of 4.11471MHz/V.

We maybe want to plot this on the main noise plot to see how far away we are from measuring a useful mirror displacement noise, so I have included the .mat file that I used to make the plot

All the previous plots are junk - I will replace them. I made a stupid typo and propagated it through the mode matching I did, and thus nothing I did on the table made any sense.

I have mode matched to the PMC, and see what I think is TEM-00 when scanning it.

I need either an EOM, or need to use the laser PZT to put audio sidebands on the light and lock with those (as we discussed doing with the NPROs at the end stations in the VGL scheme for aLIGO / 40m)

EDIT - Removed old BS plot - the below plot is good!

 I was unable to find a two lens mode matching solution using any of the available lenses in the lab constraining myself to the existing layout - I will try 3 lens solutions briefly then consider changing the optical layout. I wanted to avoid this in the interest of time, but may have to do this for the same reason.

 Today I mounted the mode matching lenses on translation stages, and Alastair and I re-aligned the CCW beam into the cavity. We hooked up the PDH servo and brought the beam into lock. Alastair noted that it was staying locked much longer than it ever had before, but of course a slight bump to the table would bring it out of lock  (or back again). I've attached a picture of the monitor output for the locked beam.

I unpacked the NPRO Rick sent me from the H1 PSL, and put it on the table.

I measured the total power output to be 1.574 W with the high power meter.

Waist measurements were taken with the WinCamD.

I saw what seemed to me to be a lot of junk light / scatter coming out of the NPRO. I am going ahead with putting it into the PMC in the interest of finishing.

The old plot was wrong. It seems I chaotically clicked blue buttons when taking my waist measurements. I attempted to mode match and noticed that what happened on the table was crazy.

[Edit - New plot added]

 These translation stages are from a cabinet on the x-arm of the 40m. Rana is ordering some new stages from Newport, but in the meantime I'll use these to optimize the lens positions.

 After I installed the mode matching lenses last week, I aligned the CCW beam into the cavity. The solid red lines in the picture below are the incoming beam, and I've included a picture of the CCD camera output on the monitor and the photodetector output on the oscilloscope. The beam is currently being scanned at .1 Hz. I've also aligned the beam coming out (dashed red line) and through the Faraday isolator and into the photodetector. I haven't had a chance yet to look at the output of this though.

Alternately, I can write the really simple equation for phase noise...

equation 5.24a from the Bloembergen paper (non depleted pump approx with plane waves):

Phi2 = 2*Phi1-pi/2+deltak*z/2

and just write the phase noise in terms of the phase mismatch. Note that this can be in terms of temperature.

I think I have found the answer to the doubling phase noise after a few pages of algebra and differential equations. I will have to confirm this at a later date, but for now I assume it's correct:

When I lock the phase of the Mach Zehnder in the IR, the phase of the green is:

Phi = Constant + w1/c*[(n1-n2)*dL/dT+(dn1/dT-dn2/dT)*L]*delta_T

• w1 is the frequency of the field @ 1064 nm (radians / sec)
• L is the length of the crystal
• n1 is the refractive index of PPKTP @ 1064 nm
• n2 is the refractive index of PPKTP @ 532 nm
• delta_T is the temperature fluctuation at the crystal

In summary for the "locked Mach Zehnder scheme"

If I treat the phase of the IR as my error signal, and push it to zero (or to some constant), the fluctuations in my green (and thus sensing noise), will be dominated by temperature fluctuations of the oven.

• If this is true, any suppression of temperature noise should be seen as a reduction in the phase noise of the green when the Mach Zehnder is locked.

 The lenses I'm using for the mode matching telescope are Newport KPX103 AR.18 (175mm) and KPX097 AR.18 (125mm). I contacted to the company to check how the focal length would change for 1064nm. These focal lengths are calculated for a wavelength of 589nm, but the index of refraction for the BK7 glass they're made of decreases from 1.51673 at 589nm to 1.05663 at 1064nm, so the focal lengths increase by 2% (assuming a thin lens).

If I left the lenses in their current positions which were calculated for 125 and 175mm, this gives a power coupling value of eta=.7674, so I have calculated the new distances for the adjusted focal lengths of 127.5mm and 178.5m. The 125mm lens should now be located 597.42mm from the mirror at the corner of the table (4w2l), and the 175mm lens should be 345.21mm from that. These positions give eta=.9910.

I've plotted how eta changes as a function of the lens positions as well. Lens 1 is the 125mm (or rather 127.5mm lens) and Lens 2 is the 175/178.5m. These plots cover +/- 10mm from the calculated ideal position. For lens 1 this value is 597.42mm, as quoted earlier, and for lens 2 it is 2383.46mm, which is the distance from lens 2 to the input mirror.

We wasted some time today looking around for the IR viewer. We found that it had been taken into the TCS lab with no notice left about it being borrowed.

This is unacceptable and the second time this has happened. The next time anyone from the TCS lab tries to borrow equipment, refuse.

Tell whomever it is to come and talk to me if they have a problem with this policy.

Here is the spherical lens solution that doesn't take into account the astigmatism of the cavity. All of these values were calculated using the programs that I posted in my earlier mode matching post.

The required beam waist size for the cavity at the input mirror is 931µm. I got this number by calculating the X and Y components of the waist separately and then averaging them. 

The mode matching solution I get from the program is to use a 125mm and a 175mm lens. The 125mm lens should be located 232.292mm from the mirror in the corner of the table (at 4W2L), and the 175mm lens 337.616mm from that.  This lens solution gives a beam waist size of exactly 931µm, and an offset from the input mirror of 1.7µm. Taking into account the astigmatism of the cavity, this gives an overlap function value of η=.9910.

This eta value is still very high even with the astigmatism of the cavity, and doesn't change much until you move the lenses dramatically. I need to modify one of my programs to plot the eta value as the lens position changes, and I'll add a plot once I get that written to better quantify this. 

 Alastair and I went down to the lab today and changed the input mirror in the cavity to a two inch mirror and switched out the 6m mirrors with 9m ones. The input mirror has a transmission of 6515ppm, and the output mirror has a transmission of 5700ppm.

I think its still worth measuring. If you really measure just the frequency noise of the laser that's great. For the second measurement you just rotate the output mirror by 90 deg and make a balanced homodyne Mach Zender measurement of the mirror motions which rejects frequency noise.

Is there any reason to assume that it will be quieter on our table than it is on the 40m PSL table? I would imagine that our top-notch temperature control system ruins us at low frequency, while the chiller and all our other equipment must do wonders for us in the audio band.

It looks like the laser frequency noise will be slightly too high to measure the vibration of the mirrors in the cavity using the control signal for the locking, especially if our cavity is quieter than the MZ at the 40m (which we are hoping it will be).  It would still be nice to get a measurement of the mechanical noise of the mirrors somehow.

 Here is a plot of laser frequency noise from a Lightwave NPRO 126 laser converted into m*Hz^-1/2 for comparison with mechanical noise taken from the MZ at the 40m.

 done

When posting MATLAB code to the elog - attach as an archive so it doesn't take up many pages when viewing all posts in the elog

 Here is the code I've been working on for mode matching to the cavity. MM.m is adapted from goo2.m from Rana's page (http://www.ligo.caltech.edu/~rana/mat/MM/PMCmatch/), and there you can also find the functions called by MM.m that I didn't edit, such as chaindo. It finds the optimum focal lengths and distances for the lenses.

EtaCalcSimple calculates the overlap function for the beam assuming a non-astigmatic beam and an astigmatic cavity. 

MMplot plots the values for z (distance from the waist) and w as a function of the changing distance from the mirror to the first lens.

Calculate allows you to change values such as the distances to see how this affects the values for eta, the waist size, and z.

***EDIT  Alastair Heptonstall ***

I've taken all of the .m files and put them in an archive file.

Done.

the network connection is down again, so our router has to be restarted ...

whoever will go to the lab on Monday first plz powercycle the linksys router...

 Making sense of this - I spent a couple minutes sitting down and writing down the right equation for the complete open loop transfer function. Assuming an integral gain of "fast", we have:

OLTF = 3.68e-3*Kp*(s+8.5/Kp)/s/(s+0.0167)

Where Kp is the proportional gain. When we make Kp 50, we put the zero from the PI loop at 0.17, where the pole is at 0.0167. This makes a nice long chunk of f^-2 in the loop, murdering the phase. As we crank the gain up to 300, we push this zero down, and shorten the stretch of f^-2.

Ideally with an integral gain of "fast" we would have a proportional gain of ~500.

If we go to "slow", then we have for our complete open loop transfer function:

OLTF = 3.68e-3*Kp*(s+1.6/Kp)/s/(s+0.0167)

For a gain of "1 slow", as in the plot, we find the zero is 2 orders higher than the pole, which is consistent with this setting ringing way more than the others. A gain of "100 slow" would work for balancing the zero and pole. Our highest proportional gain available with a "slow" setting is 50, which is similar to the situation above, where the zero is about a factor of 2 before the pole, thought with a lower UGF than above.

Here is the in loop temperature for various loop settings.

Legend: The first number is proportional gain, the F is integral gain ("fast" as called by the 3040) To note:

• I don't know why the loop oscillates for lower gain settings
• The loop seems most stable for the highest possible gain settings ("300 Fast"), so I will use this.
• This is actually Kelvin/rtHz

The USB-to-serial converter is back at 40m.
The  new ones Rana bought are not working properly so the got the one from the ATF which we use for the particle counter.

We now have two temperature controllers in the lab:

A couple of weeks ago they installed a second temperature controller on the South Wall. This drives the HVAC heater that is above the stereo.

The original temperature controller (West Wall) was also upgraded to have a fancy new 1960's-style mechanical display of the setpoint-needle on the front type. Maybe in 50 or 60 years we can get a digital controller in here.

At the moment the second controller has not been calibrated to match the original controller.

1. 00001.jpg - new controller on South Wall
2. 00002.jpg - close up of South Wall controller
3. 00003.jpg - upgraded West Wall controller

the two graphs show the temperature fluctuation in the ATF for 14 days each. The first graph from March, the second for the last 14 days.
scale is the same for both graphs.
Couldn't plot a single graph for the last couple of month as the dataviewer stops displaying most of the June data if you want to plot more than 40 consecutive days or so even if it tells you to do it right.

This is a measurement of the open loop temperature of the oven - the blue box is "off", so this may be higher than the temperature noise the servo normally has to supress.

• It is worth noting that the readout of the box has 0.0076 K precision (this is the difference between values).
• I don't know if it does this (12/14 bit?) rounding in the servo loop or not

THIS IS POWER!! - that is sad. take a square root of the spectrum to translate it into amplitude spectral density - using this as a clipboard because I somehow don't have pwelch on my Ubuntu MATLAB install o.O. That is also sad.

ovenCL50a=load('CLtemp1.txt');
ovenCL100=load('CLtemp2.txt');
ovenCL300=load('CLtemp3.txt');
ovenCL50b=load('CLtemp4.txt');
ovenOL=load('OLtemp.txt');

Fs=1;
nfft=200*Fs;
[pwrOL,frOL]=pwelch(detrend(ovenOL),hanning(nfft),nfft/2,nfft,Fs);
Fs=4; % sample frequency in Hz
nfft=200*Fs;
[pwr50b,fr50b]=pwelch(detrend(ovenCL50b),hanning(nfft),nfft/2,nfft,Fs);
[pwr100,fr100]=pwelch(detrend(ovenCL100),hanning(nfft),nfft/2,nfft,Fs);
[pwr300,fr300]=pwelch(detrend(ovenCL300),hanning(nfft),nfft/2,nfft,Fs);


figure(1)
loglog(...
    frOL,sqrt(pwrOL),'r',...
    fr50b,sqrt(pwr50b),'k',...
    fr100,sqrt(pwr100),'cyan',...
    fr300,sqrt(pwr300),'magenta',...
    'LineWidth',1)
axis tight
grid

• the dates where they tried to fix the leaks are around/after the first peak in particle counts (04/23/2010)
• i don't have data for a few days after that because nobody saved the data from the counter i guess and it starts to overwrite it after some while (the white gap).
• the latest peak from last week was due to some technical issues with the HVAC system which they fixed immediately (06/17/2010)

edited the code to the following. This will save the data ~ 1x / second (I don't really care about a slight cumalative error in this since it's constant - it'll just be a systematic error in my frequency scaling)

global SERPORT
set SERPORT [open "/dev/ttyS0" "w+"]

fconfigure $SERPORT -mode 9600,n,8,1 -handshake none -buffering line

proc run_query { command } {
global SERPORT

puts $SERPORT "$command"
flush $SERPORT
gets $SERPORT line

return $line
}

#@puts [run_query "BEEP?"]

         set filename "/users/dmass/scripts/test.txt"
         set fileId [open $filename "w"]

 for { set i 1 } { $i <= 2000 } { incr i } {
#       puts "[clock format [clock seconds]]\t[run_query "TEC:T?"]"
                puts $fileId [run_query "TEC:T?"]
        after 1000
        }
close $fileId

I asked Vladimir in passing how he preferred to talk to things via the serial port, and he wrote this. It is now contained in /users/dmass/scripts/serial_test.tcl :

#!/usr/bin/env tclsh

global SERPORT
set SERPORT [open "/dev/ttyS0" "w+"]

fconfigure $SERPORT -mode 9600,n,8,1 -handshake none -buffering line

proc run_query { command } {
global SERPORT

puts $SERPORT "$command"
flush $SERPORT
gets $SERPORT line

return $line
}

#@puts [run_query "BEEP?"]

while { 1 } {

    puts "[clock format [clock seconds]]\t[run_query "TEC:T?"]"
    after 100
    }

To talk to the Temperature controller via RS 232, use

> sudo minicom

set this via the minicom software

• baud rate = 9600
• no parity
• 8 data bits
• 1 stop bit
• Then do
• E for echo on
• do "BEEP?", should get 0 or 1
• Reset the modem if you don't get a response
• do "BEEP?" again, success, we are talking to the newport 3040

Next up - have a script dump the response to a temperature query every second or so to a file. This is inferior to using some AD590s to sense the temperature via the front end, because of the time constants involved in loading / reading out files. I will buy some AD590s for future use (though they will get here after I am finished with this).

Useful command(s)

• TEC:T? - queries the temperature of the TEC sensor (and RTD in my case)
• TEC:SET:T? - queries the temperature set point
• TEC:T xxxxxx - can set the temperature setpoint
• sudo stty -F /dev/ttyS0 -parenb echo

I was having problems because /dev/ttyS0 was set to root permissions, and a sudo wouldn't cut it when I tried to echo something to it. I changed the permissions and this now works:

• echo "TEC:T?">/dev/ttyS0

very nice measurement!
how large was the external modulation input span? disabled?
if disabled, did you measure the phase noise with the input enabled (but terminated) and set to a usefull range as well?

RA: c.f. the entry below for html link to description.

There is a 10x improvement in the Marconi phase noise spectrum when locking it to the FS725 Rubidium clock.

To see if we could improve on the Marconi spectra for use in the Gyro/RefCav measurements I set up two of the 40m Marconis for "Direct External 10 MHz Reference" lock.

In the attached plot you see the BLUE trace (free running Marconis) is higher than the PURPLE (locked to Rubidium) trace. The BROWN dots are the SSB phase noise specs

for the FS725 Rubidium clock. In this case, I have the FS725 locked to the 1PPS from our GPS receiver, but I think it doesn't have any effect above 10 mHz.

Some Notes:

1. The 'Direct' lock mode of the IFR2023A implies that it locks directly to the external reference. The 'Indirect' mode means that it first locks an internal TCXO to the external reference and then uses the TCXO as the internal reference. Since the FS725 has a better SSB phase noise spec than the IFR2023's internal PLL, I used the 'Direct'.
2. As you can tell from the noise improvement, it looks like the internal PLL has a ~1kHz UGF but only has a gain of ~10 below there. That's pretty strange if true. We should purchase another Rubidium clock to beat with this one to see if its really as good as its spec.
3. As usual, the beat spectra shown are the quadrature sum of 2 oscillators, so divide by sqrt(2) to estimate the noise of an individual IFR/Marconi.
4. In all my previous phase noise measurements, I had neglected to compensate for the 30 mHz AC coupling of the SR560 I am using as a pre-ADC preamp. I've corrected for this in the calibration of these measurements. Its almost a negligible effect but I include it anyway for my internal satisfaction.
5. Because of the high input impedance of the 10 MHz inputs of the IFRs, I have daisy-chained the 2 by using a BNC T on the back of the first one. The cable connecting to the bottom one is terminated with an in-line 50 Ohm terminator.
6. As described previously in the 40m elog, the measurement setup is using a ZP-3MH mixer as a phase detector. Looking at the peak-peak signal with free running oscillators allows us to calibrate the phase detector slope when locked. An AC coupled SR560 with G=1000 is used as the preamp between the mixer and the ADC. Between the mixer's IF output and the SR560, there is a 50 Ohm inline term and a 1.9 MHz BNC low pass filter from Mini-Circuits.
7. Since the FS725 spec is better than the PURPLE trace, I am assuming that the PURPLE measurement is real. If the FS725 was noisier, we would be fooling ourselves by cancelling out the common-mode noise of the FS725, but in our case we are dominated by the internal noise of the Marconis.
8. Simply taking the FS725's 10 MHz output and deriving a 95 MHz or 160 MHz signal wouldn't gain us much, since the phase noise would also increase by the multiplication factor. For the Refcav experiment, the best option may be to bring the beat down into a reasonable regime by using 2 lasers rather than an AOM. Then we may be able to put the beat frequency below the Nyquist of the digital system and forego any RF demodulation.

This was wrong.

I bought about a million converters - Koji has most of them, but I left one with Jan so that you can take that one to get the particle data.  Along with the HVAC, this will be a combination of low temperature and particle physics. Very advanced.

And a measurement of the oven's step response

• I used a lab power supply as a current source for the TEC on the oven
• I tweaked the current nob to make a current step
• I looked at the step response
• I used a phone video of the readout on the front of the Newport 3040 to get time stamps b/c it was so easy
• (I will still be hooking up the RS232)

Results

• I get a time constant of 60 seconds
• This is an oven pole frequency of 16.7 mHz

a minute ago a guy showed up in the lab and wanted to talk to Aidan but couldn't find him. He told me that the air conditioning is now working again and i should let him know.

Particle count in the ATF was about 1.5million before, now decreasing and already below 100k. Can't post data as the usb-to-serial converter is still used at 40m...

 A Couple more measurements yielded:

• I = Slow <=> 0.0172 A/s/K
• P = 1 <=> 0.0098 A/K

And

• I = Fast <=>0.0848 A/s/K

Next I am hooking up the RS232 connector to one of the computers to see if I can get temperature logged, so that I can actually do something with it.

3040 P/I settings -

I = Slow <=> 0.0162 A/s/K

P = 2 <=> 0.0172 A/K

After talking to Koji, and learning a little about how digital integrators worked, I understood the wording of the manual differently. I now believe it to mean

"I have a true integrator with two gain settings, and a proportional term with ~12"

http://www.teamwavelength.com

e.g. these things is not entirely useless

http://www.teamwavelength.com/products/product.asp?part=19

http://www.teamwavelength.com/products/product.asp?part=58

http://www.teamwavelength.com/products/product.asp?part=29

Dmass and Koji

We rebooted ws1 during the work, and started not to have X11 working.
So far the single monitor (with cloning) is working.

The machine claimed that it could not find the driver named nvidia.
I switched the driver to the generic driver (VESA Generic Driver) using a diagnostic dialog
which appeard when we could not run the X11 during the boot.

Using the generic driver we now can display 1280x1024 but can not use the dual head function.
I removed the existing nvidia driver (which also did not work) in order to reinstall it.
Then I tried to reinstall it, but the machine could not download it from the fedra site.

I will investigate the driver situation for nVidia GeForce 7600 GT and will try to install the alternative driver later.

The plot I attached and didn't explain is:

• Green = Voltage across the Ohm Ranger as driven and read out by the (unknown) bridge of the Newport 3040
• Red = Voltage across a high power 5 Ohm resistor I am using on the current output of the Newport 3040
• Units are standard DAQ conversion ~ 1600 counts / Volt

Notes:

• I use an SR560 to buffer the signal from the ohm ranger before inputting it into the AA chassis
• The resistance between the inner BNC leads of the AA box was ~2 kOhms - FOR SEVERAL DIFFERENT CHANNELS
• I have the PI (no D) servo set at its lowest settings, so lowest integral gain, and lowest proportional gain.
• I make step responses in the green curve via the ohm ranger.
• I should see step responses of the red from the proportional term, and changes in the slope of the integration following these step responses.
• I see SLOPE IN THE GREEN. This is weird.
• The slope in the green goes away when I unplug the voltage (from the TEC drive current) across the 5 ohm resistor from the front end.
• The slope in the green stops when the current rails.
• I don't understand the coupling, but since I don't have circuit diagrams for the 3040 - I stopped thinking about it, and just used a USB stick in a scope to take this data.

Moral:

• The 3040/ front end acts funny when you try to read out the current and the voltage of the thermometer.
• I don't really care that this is the case.
• The front end seems to be working close to all the way

i think i have a loose connection on the timing pcb in the blue chassis in the psl lab. I had this "no sync" problem the day before i left too and after i checked all connections and wiggled all the cables everything was fine when i checked again. So try to do that with the 1Hz BNC sync cable connected at the back of the chassis. The psl model uses only the first card in the chassis and was working. I will replace the board beginning next week. If one of the models doesn't sync the framebuilder doesn't start.

Another option: Because we need both systems running in order to work with it i will try to use the bad frontend computer at a lower sampling rate. The spikes in the timing are about 280us. If the model is running at 2k we have about 480us cycle time, so it shouldn't matter anymore. I've mounted everything in the rack already to try that but had no time to look into details...

The front end (fb0) was freezing at "Starting udev" every time I tried to boot it. I googled a tad and found some people somewhere said that this happened to them when some cables were loose, so I wiggled all the cables and rebooted.

FB0 now boots.

I think something may have been jiggled loose from the back of fb0 when the rack was manhandled, possibly during the fixing of the ceiling leaks.

• I sshed into fb0
• I did "startatf" and "startpsl"
• I set both burtrestores to 1 -
• Nothing worked yet - framebuilder kept respawing at 5 minute intervals
• I checked the log files and noticed nothing obvious
• I added a channel in the C2ATF.ini because I wasn't sure there was one
• I restarted both processes again
• The ATF model up with both ADC and DAC channels started working
• I am unsure if the PSL model is working, the GDS_TP screen says "NO SYNC" under sync source.