40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 53 of 54  Not logged in ELOG logo
ID Date Author Type Category Subject
  70   Mon Jul 28 15:58:49 2008 DmassComputingDAQDaq not recording
There is still something wonky with the DAQ. Nothing appears to be writing at the moment, as I can only get 8 seconds of data from the playback in dataviewer. I may table this until I am trying to get the new system up and running.
  69   Fri Jul 25 17:07:34 2008 DmassLaserPMCCavity Pole Measurement on the PMC

Quote:
Measurement of the PMC cavity pole:

The following was done at powers of .234 W and .42 W.
I turned the laser power on the table down low (using a polarizer and a PBS to dump the majority of the beam).

I then used a function generator to input a triangle wave into the Piezo driver and sweep the cavity. This was done at a frequency of .04 Hz (for reasons dictated by dataviewer).

I found the HWHM (half width half max) of the transmitted intensity (when the DC bias was subtracted out) to be 0.00054 and 0.00053 free spectral ranges for .234 and .42 W, respectively.
I also noticed some nonlinearity in the PMC/Piezo as I scanned through more FSR's, and thus used the data from the bias voltages closest to zero.

I calculated the FSR frequency to be 713.8 MHz (in agreement to what we have on file for the PMC at the 40m).

Using the equality \delta L / L = \delta f / f, I get pole frequencies of 385 kHz and 378 kHz for .234 and .42 W, which is about a 2% agreement between measurements.

Again - the cavity pole was measured to be about 380 kHz to within a couple percent. - this differs significantly from the pole quoted for the 40m PMC at
http://www.ligo.caltech.edu/~ajw/PSLPMC.png (which is 488 kHz)


I looked back at the old data, and measured the V/cts ratio of the ADC (which at low frequency was 0.000622 V/ct). Using this, and the data from the above measurement of the cavity pole, the response of the PMC PZT is about 3.235 V/FSR.

Nota Bene:

The old data from the sweep of the PMC was taken by driving with a function generator, and tee-ing off the output of the generator to the ADC. However, I got the data from the output of one of the ADC channels, so it was post filtration. I am ALMOST POSITIVE that all gains were unity, but there is some small but finite possibility that one of them was not, and this would bebunk my number for Volts per free spectral range.
  68   Fri Jul 25 15:23:14 2008 DmassLaserPSLNew Vertical PSL
With the installation of the new "clear top" on the PSL (see picture), an interesting design feature has come to light.

There are a few noteworthy things about this feature:

-We have a vertically oriented window after the NPRO.
-The vertically oriented window shoots some beam up.
-The new clear top appears to be transparent to IR.
-The HEPA filter is right above the window.

Possible worries:

-Light leaking back into the NPRO.
-Dumping beam onto the HEPA filter might not be the best thing.

It might be a good idea to do a proper dumping of that beam. I am unsure as to whether it would be better to do so inside or outside the enclosure.
Attachment 1: NPRO.png
NPRO.png
Attachment 2: HEPA.png
HEPA.png
  67   Fri Jul 25 14:59:24 2008 DmassComputingfubardigital control broken.

Quote:
I tried to restore the hacked up oms control system via a series of escalating measures.

a) I ssh'ed into the FE computer (oms) and did "startoms"
-that seemed to run, but there were errors in the status window of screen "C2OMS_GDS_TP.adl" next to the red light FB0, of type 0x2001 if I recall correctly

b) I then tried to remake the oms FE code via the commands in Tobins elog entry
- make oms
- make install-daq-oms
- make install-oms
- make install-screens-oms
Nothing upon restarting the FE. No more error messages from the FB0 button now. possibly more broken than before.

c) Stefan and I then did a "sudo reboot" on oms, still nothing.

We found as the last line in the log file
/cvs/cds/caltech/target/c2oms/log.txt
"DAQ init failed -- exiting"

It appears that the daq no longer starts. I have sent Alex an email, and have tried calling him several times (have not gotten a pickup).
Daqconfig is also brokenish on the non FE computer (ws1). It gives "Error: can't read "y": no such variable" on startup, and will not display anything.

I will be working on getting Rich Abbott's PDH box up and running to lock the PMC while I twiddle my thumbs on the digital stuff.


With the assistance of a benevolent Rob, the above problem was identified and fixed.

While looking at the logfile for C2oms, we found the script omsfe.rtl was crapping out because there were no daq channels set to acquire. We fixed this by manually setting one of the channels to acquire in C2oms.ini and uncommenting it. We then dropkicked the framebuilder by telneting in via
> telnet fb0 8087
and doing a shutdown. This should be equivalent to clicking the DAQ Reload button on the oms FE Diagnostic medm screens. This fixed the problem of the daq not starting, and we could get realtime data via dataviewer. To start recording it in the daq again, we just need to edit "C2oms.ini" to reflect which channels we are interested in recording.

It appears we can still not toggle channels to acquire via the daqconfig gui. I will worry about that more when I have a version control screens here that I am happy with, and harrass Alex.

We also found something interesting when we tried to interact with the system via DTT. It seemed that the system wanted there to be a link tpchanm1 pointing to tpchanC2, but the creation and subsequent annhilation of this link seemed to not effect the system. When we looked closer, the file we expected to define all the test points, /cvs/cds/caltech/chans/param/tpchn_C2.par, was full of objects for the atf system. The file that the system appears to actually get its definitions of these from was /cvs/cds/advLigo/build/omsepics/oms.par.

Rob says that this was an indication that something in the series of "make ___" commands is broken, as they should have overwritten this file at some point.
  66   Wed Jul 23 12:04:01 2008 DmassElectronicsGeneralUniversal PDH box

Quote:
I just picked up the "Universal PDH Box" prototype from Rich Abbott.

A few wrinkles: One of the voltage regulators was resonating at 12.3 kHz, producing an annoying high pitched whine, so Rich added a beefy capacitor in parallel with the original SM component.

There was possible shorting of the bottom of the circuit board to the case. I added some rubber feet to the back of the board, and covered the inside of the case in some kapton tape. I will test again later (possibly when we get the NIM crate down here).

We (I) need to get a NIM crate cooking to populate with useful things like this.

Rich also advised triple checking that the board is powered correctly from the NIM supply. Will do this when I get a crate.

We did some rudimentary testing of the box in Wilson house, and it seems to be functioning as expected.

Also should make sure that we are only AC coupled to the photodiode when we finally do hook one up to the front.

Thorough (aka large) picture attached.

Also all pertinent documentation attached below picture in a pdf.


I measured the transfer function of the PDH Box between the "Servo Input" and "Piezo Drive Output" terminals on the front of the box.

I used the 4395, and for 10 Hz - 200 kHz I used a BNC T-splitter for splitting the drive signal. for 1kHz - 35MHz I used a minicircuits ZMSC-2-2 splitter (which is rated in that frequency band).

Attached are both transfer functions for posterity. I shall try to lock the PMC with this next.
Attachment 1: PDH_LF.png
PDH_LF.png
Attachment 2: PDH_HF.png
PDH_HF.png
  65   Tue Jul 22 18:43:06 2008 DmassComputingfubardigital control broken.
I tried to restore the hacked up oms control system via a series of escalating measures.

a) I ssh'ed into the FE computer (oms) and did "startoms"
-that seemed to run, but there were errors in the status window of screen "C2OMS_GDS_TP.adl" next to the red light FB0, of type 0x2001 if I recall correctly

b) I then tried to remake the oms FE code via the commands in Tobins elog entry
- make oms
- make install-daq-oms
- make install-oms
- make install-screens-oms
Nothing upon restarting the FE. No more error messages from the FB0 button now. possibly more broken than before.

c) Stefan and I then did a "sudo reboot" on oms, still nothing.

We found as the last line in the log file
/cvs/cds/caltech/target/c2oms/log.txt
"DAQ init failed -- exiting"

It appears that the daq no longer starts. I have sent Alex an email, and have tried calling him several times (have not gotten a pickup).
Daqconfig is also brokenish on the non FE computer (ws1). It gives "Error: can't read "y": no such variable" on startup, and will not display anything.

I will be working on getting Rich Abbott's PDH box up and running to lock the PMC while I twiddle my thumbs on the digital stuff.
  64   Fri Jul 18 16:14:28 2008 DmassElectronicsGeneralUniversal PDH box
I just picked up the "Universal PDH Box" prototype from Rich Abbott.

A few wrinkles: One of the voltage regulators was resonating at 12.3 kHz, producing an annoying high pitched whine, so Rich added a beefy capacitor in parallel with the original SM component.

There was possible shorting of the bottom of the circuit board to the case. I added some rubber feet to the back of the board, and covered the inside of the case in some kapton tape. I will test again later (possibly when we get the NIM crate down here).

We (I) need to get a NIM crate cooking to populate with useful things like this.

Rich also advised triple checking that the board is powered correctly from the NIM supply. Will do this when I get a crate.

We did some rudimentary testing of the box in Wilson house, and it seems to be functioning as expected.

Also should make sure that we are only AC coupled to the photodiode when we finally do hook one up to the front.

Thorough (aka large) picture attached.

Also all pertinent documentation attached below picture in a pdf.
Attachment 1: PDH_User_Manual1.pdf
PDH_User_Manual1.pdf PDH_User_Manual1.pdf PDH_User_Manual1.pdf PDH_User_Manual1.pdf PDH_User_Manual1.pdf PDH_User_Manual1.pdf PDH_User_Manual1.pdf PDH_User_Manual1.pdf
Attachment 2: UniPDH.png
UniPDH.png
  63   Thu Jul 17 16:44:27 2008 DmassLaserPSLLaser is off
Leaving laser off while I hack at screens downstairs. Feel free to turn on for anything.

I also turned the ISS drive box off.
  62   Wed Jul 16 11:47:18 2008 DmassComputingGeneralFront End Machine Namechange
The front end machine in the Bridge Basement has been renamed "atf" from "oms".

I changed /etc/sysconfig/network on oms(now atf) and
/etc/hosts on ws1 (the dual head control station)
by replacing the "oms" tag with "atf"

When you ssh into atf from ws1, it still says you are logged in as "controls@oms". There appears to be more to change.

Disambiguation of the digital locking system to follow.
  61   Mon Jul 14 16:01:45 2008 Stefan BallmerElectronicsISSH1 ISS spare tested
I tested the modified H1 ISS spare using a post-PMC sensing.
I got the expected performance in-loop (about 2e-8/Hz at 100Hz),
but the out-of-loop diode had additional acoustic noise. But that's not due to the electronics.

Also, for this test, I again locked the PMC using the digital system.
  60   Fri Jul 11 16:20:21 2008 Stefan BallmerElectronics PMC
Since the digital system was in an ambigous state I locked the PMC using a SR560.
I did this so I can use the lab setup to test the newly modified Hanford ISS spare.
  59   Sun Jun 1 18:52:49 2008 tobinComputingGeneralborkspace compiling
Following Alex's suggestions, I fixed the front-end problems we were encountering the other day.

To get the shared libraries stuff to work, I inspected the contents of /etc/ld.so.conf.d and 
found it all looking fine.  I ran /sbin/ldconfig, which updates some shared library index 
somewhere, which seemed to fix the problem with the EPICS server finding its libraries.  To create 
the /rtl_mem_atf file, I edited /etc/rc.local, adding "atf" to the list of subsystems.  I believe
that everything now works to compile and run the ATF front-end system.

As a reminder, some useful commands:

cvs update               refreshes the software distribution from CDS
make atf                 recompiles the front-end system
make install-atf         installs new front-end binary and scripts
make install-daq-atf     installs DAQ channel stuff to framebuilder
make install-screens-atf makes new generic MEDM screens

killatf                  Stop the front end code
startatf                 Stop and then start the front-end-code

If you want to change the name of the computer itself, I think you just
need to (1) edit /etc/sysconfig/network and change the hostname; and (2)
etc /etc/hosts on all the machines from which you'll be connecting to the
front-end machine (at the moment, just ws1?).

[fixed command syntax - 7/22/08 DYM]
  58   Thu May 29 20:00:48 2008 tobinComputingFuglyborkspace compiling
Dmass and I tried to compile and install a new system on the borkspace machine here.
We ran into a few difficulties.

First, the startup script for the EPICS server can't find the channel access library.
A hack to fix this is to enter this command in the terminal before running the start
script:

export LD_LIBRARY_PATH=/opt~/epics-3.14.7-x86_64/base-3.14.7/lib/linux-x86

With this, the OMS system front-end runs fine. But we can't start our new system,
ATF. The ATF front-end dies with the error:

[controls@oms advLigo]$ cat /cvs/cds/caltech/target/c2atf/log.txt
cpu clock 2412402
open failed for write on /rtl_epics (45)

I looked in the controller.c code and it appears that the front-end code wants there
to be a special file /rtl_mem_atf. I made one of these using both a hard link, and
then via mknod ("sudo mknod rtl_mem_atf u 150 132"), mirroring the existing rtl_mem_oms,
but neither attempt worked. Will ask Alex for help.
  57   Tue May 20 15:55:31 2008 DmassLaserEOMEOM Phase lag
The attached transfer function was measured with the experimental setup outlined in entry 53. The first transfer function (Raw Data) is the output of the 4395 when I calibrated away the cabling as described in the drawing in entry 53. The high frequency junk is pickup from something; it shows up with the photodiode blocked.

The second transfer function is the first one with the following model divided out:
model=@(f) (i*f).*(1./(1+i*f/380e3)).*exp(-i*2*pi*f*60e-9)
The zero at zero is due to the EOM modulating in phase, not frequency.
The time delay was generated by roughly fitting to the data (to get a white phase response)
The pole at 380 kHz is the cavity pole of the PMC (experimentally determined in entry 56)

The measured time delay based on propagation of cables/free space is 41 ns, so there is an additional time delay of 19 ns +/- 10 ns in our model.
This corresponds to a phase shift of 0.7 degrees at 100 kHz

As we can see from the transfer function - there is clearly more going on than our model takes into account (probably a number of poles). Adding poles would put a tighter constraint on the time delay, which is fine/good.




Quote:
I used the experimental setup below to measure the transfer function between the EOM (which is before the amplifier) and the reflections off the PMC. The light blue line is what I shorted to each other when I used the 4395's calibrate feature to correct for the cabling/rf components.

The "modulation summation box" is shown below the schematic. I will update this later when I figure out what the components are.
Attachment 1: RawTF.png
RawTF.png
Attachment 2: corrtf.png
corrtf.png
  56   Mon May 19 17:28:44 2008 DmassLaserPMCCavity Pole Measurement on the PMC
Measurement of the PMC cavity pole:

The following was done at powers of .234 W and .42 W.
I turned the laser power on the table down low (using a polarizer and a PBS to dump the majority of the beam).

I then used a function generator to input a triangle wave into the Piezo driver and sweep the cavity. This was done at a frequency of .04 Hz (for reasons dictated by dataviewer).

I found the HWHM (half width half max) of the transmitted intensity (when the DC bias was subtracted out) to be 0.00054 and 0.00053 free spectral ranges for .234 and .42 W, respectively.
I also noticed some nonlinearity in the PMC/Piezo as I scanned through more FSR's, and thus used the data from the bias voltages closest to zero.

I calculated the FSR frequency to be 713.8 MHz (in agreement to what we have on file for the PMC at the 40m).

Using the equality \delta L / L = \delta f / f, I get pole frequencies of 385 kHz and 378 kHz for .234 and .42 W, which is about a 2% agreement between measurements.

Again - the cavity pole was measured to be about 380 kHz to within a couple percent. - this differs significantly from the pole quoted for the 40m PMC at
http://www.ligo.caltech.edu/~ajw/PSLPMC.png (which is 488 kHz)
  55   Tue May 13 12:37:31 2008 DmassLaserFiberNew fiber
We got a box of fiber from Boston (Marie Woods). It is now on the optics table in the bridge basement.

The fiber has some writing on it. It says printed on the fiber in ink:
"OZ OPTICS LTD BC# 2887" and gives their tel # as 613-831-0981.
There is also a label on the fiber that says:
"PMJ-3AF,3AF-1064-6/125-3-60-1
SN: T872391-01"

Picture below:
Attachment 1: 00011.png
00011.png
  54   Wed May 7 04:44:31 2008 DmassComputingGeneralDTT and Fast Channels fixed
The playback in dataviewer on the fast channels was semi broken (would not display full data on a playback, but could do all else).

Also, DTT was giving an error "failed to start diagnostics kernel" whenever we attempted to launch it.

I talked to Alex and he managed to fix both of these problems.
  53   Tue May 6 18:18:59 2008 DmassLaserEOMEOM Phase lag
I used the experimental setup below to measure the transfer function between the EOM (which is before the amplifier) and the reflections off the PMC. The light blue line is what I shorted to each other when I used the 4395's calibrate feature to correct for the cabling/rf components.

The "modulation summation box" is shown below the schematic. I will update this later when I figure out what the components are.
Attachment 1: TF_setup1.png
TF_setup1.png
Attachment 2: MODSUM.png
MODSUM.png
  52   Mon May 5 20:32:50 2008 DmassComputingGeneralMEDM, FB, FE, Etc
I restarted the oms box in the rack, and was in the process of trying to get new medm control screens up with Rob. I now have neither the old mislabelled oms screens, nor the new soon to be beautiful screens, as well as no way to finish my measurement of the PMC cavity pole until I get those back up and running.

Will be reading
http://www.ligo.caltech.edu/%7Eaivanov/daq_handbook.html

and if that fails,
Will bug Alex or Stefan tomorrow.
  51   Fri May 2 22:54:44 2008 DmassComputing Screens
I made a simulink model and put it here: /cvs/cds/advLigo/src/epics/simLink/atf.mdl

as instructed by the rolf wiki:
http://lhocds.ligo-wa.caltech.edu:8000/40m/WikiOfRolfCDS?highlight=%28rolf%29

I then changed to the advLigo directory on oms, and "make atf" seemed to run successfully. Before finishing the process, I got the following error when dealing with c2atfepics:

[controls@oms c2atfepics]$ cat iocC2.log
dbLoadDatabase "dbd/a.dbd"
dbLoadDatabase "dbd/atf.dbd"
dbLoadDatabase "dbd/get_local_time.dbd"
registerRecordDeviceDriver(pdbbase)
dbLoadRecords "db/C2/local_time.db"
dbLoadRecords "db/C2/atf1.db"
iocInit
Starting iocInit
############################################################################
### EPICS IOC CORE built on Aug 10 2005
### EPICS R3.14.7 $R3-14-7$ $2004/12/06 22:31:52$
############################################################################
iocInit: All initialization complete
seq &atf,("ifo=C2, site=caltech, sys=ATF, sysnum= 10")
SEQ Version 2.0.10: Wed Aug 10 23:41:07 2005
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 46391,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
Couldn't open `/rtl_mem_atf' read/write
open("rtl_epics"): No such file or directory
  50   Fri May 2 22:00:17 2008 DmassComputing Daq Channels
I activated the channels C2:OMS-SUS_T3_ACT_OUT and C2:OMS-SUS_LEFT_IN1 in daqconfig, set both to acquire, and saved them to cvs/cds/caltech/chans/daq/C2OMS.ini

Real screens and naming conventions to follow.

[Edit: I do not know how to disable the auto smileys, so : O is seen as Yawn]
  49   Fri May 2 21:39:13 2008 DmassLaserPSLLaser power on table lowered
I have changed the polarizer before the polarizing beam splitter to minimize output power.

I did this to measure the PMC pole at as low a power as possible.

This will make power trends (which are picked off after the PBS) look VERY low for a bit.
  48   Fri May 2 21:09:26 2008 DmassLaserGeneralStrange Noise
We may want to set up a microphone and see if the noise is correlated to the sharp power fluctuations in the laser.


Quote:
Something on the table or under it is periodically making a squeeking noise. Stefan claims this is not new though neither of us can localize it (it's < 1sec duration). Unsure as to what is the offending noisemaker.

[Update - the noise happens when the laser is off, comes from side of table (possibly beneath) opposite laser]
  47   Fri Apr 25 13:33:35 2008 DmassLaserPSLpower drift
Here is a trend of the power drift taken over 10 days. The units are in counts produced by a photodiode stationed at a lower power pickoff of the beam.

The first plot is a full 10 days - you can see the times during which the laser was off where the counts go to zero.

The second plot is the full data over 10 hours, which seems to imply that the sharp increases in power are real.

Negative values correspond to an increase in power.
Attachment 1: trend2.png
trend2.png
Attachment 2: trend3.png
trend3.png
  46   Tue Apr 22 20:07:50 2008 DmassLaserPSLProfile of 35W PSL
The total power seemed to be down about 10%, and that lower number was divided between two beams at the output. They opened up the amplifier and realigned things within it, which seems to have fixed the multibeam/lower power we were encountering before.


Quote:

Quote:
I scanned the beam on the 35W laser again (for the first time since it was fixed by our German friends during the LSC meeting).



What did they fix? And how?
  45   Tue Apr 22 16:25:24 2008 robLaserPSLProfile of 35W PSL

Quote:
I scanned the beam on the 35W laser again (for the first time since it was fixed by our German friends during the LSC meeting).



What did they fix? And how?
  44   Fri Apr 11 17:15:49 2008 DmassLaserEOMTransfer Function
We traded network analyzers and now can go below 100kHz in our measurement. The following transfer function was taken with an HP 4395A.

The previous measurements were done with the PMC not locked to the laser, so the measurement was repeated using RF Reflection locking (sidebands @ 35MHz).

Another important thing we discovered was that the frame of the table is ungrounded, which led to significant noise leaking into the error signal when we let a BNC cable touch it. Schematic of experimental set up to follow.

Not all of the cables/electronics were calibrated out in the measurement below.
Attachment 1: EOM_PMC_tf.png
EOM_PMC_tf.png
  43   Fri Apr 11 16:37:03 2008 Stefan BallmerComputingGeneralSet up CDS wireless router / controlling from nokia handheld works
I set up a CDS wireless router:
IP: 131.215.113.2
SSID: cdsrana
Unname & PWD written on router

It has WEP and MAC-filtering enabled.

With that I was able to use the little Nokia handheld to control the digital system.
Example:
- start x-terminal
- 'cd'
- 'ws1'
(this just starts ssh to ws1)
- startSlider
(this bring up the offset slider for the PZT control loop), or
- startmedm
(this starts the OMS main screen)

We have to make medm screens that work for the little Nokia screen....
  42   Mon Apr 7 16:43:15 2008 DmassLaserPSLProfile of 35W PSL
I scanned the beam on the 35W laser again (for the first time since it was fixed by our German friends during the LSC meeting).

A picture of the setup is below.

Images of the profile, 2d and 3d are below as .bmp, and the generating data for these is in Apr7_08scan.asc (zipped text)

This profile is significantly cleaner than the one measured in entry 31 of the elog.
Attachment 1: scancap.png
scancap.png
Attachment 2: 3dbeamprof.bmp
Attachment 3: flatprof.bmp
Attachment 4: Apr7_08scan.asc.zip
  41   Thu Apr 3 17:56:35 2008 DmassLaserEOMTransfer Function
Transfer function part 2:

I repeated the measurement with impedence matching where I could (not inside the laser box), and did some CRUDE fitting with matlab.

I also herby acknowledge that png > jpg.

The tau is the time delay which makes the green curve on the phase plot coincide with the data at high frequency.

No locking was used. The 00 mode was reached for short periods of time through input to the laser crystal temperature during which time the measurement was taken.

-Calibration-
The input to the EOM was removed and connected to the PD output and calibrated out with the network analyzer.

The analyzer used to do this measurement has now been traded for a HP 4395A (which goes down to 10Hz).
Attachment 1: EOMPMCTF.png
EOMPMCTF.png
  40   Tue Apr 1 20:50:37 2008 DmassLaserEOMTransfer Function
(With Stefan's help) I took the transfer function between the EOM of the PSL, and the Photodiode on the PMC's reflected light. We looked at the lower frequency as well with another analyzer (up to 50 MHz).

The very low frequency features seem to be junk, and we can see what looks like ~f in the low frequency transfer function.

In the higher frequency range, there seem to be resonances corresponding to a FSR of about 22 MHz (long.) starting around 11 MHz. The low end seems to behave as expected, and go as frequency. (Note that the units on the non-log bottom plot are in x10^7 Hz)
Attachment 1: EOM_PD_xsfer.jpg
EOM_PD_xsfer.jpg
Attachment 2: HFlogxsfer.jpg
HFlogxsfer.jpg
Attachment 3: HFxsfer.jpg
HFxsfer.jpg
  39   Thu Mar 27 13:25:38 2008 Stefan BallmerLaserISSModifications to ISS (D080149-00-C)
Attachment 1: D080149-00-C.pdf
D080149-00-C.pdf D080149-00-C.pdf D080149-00-C.pdf D080149-00-C.pdf D080149-00-C.pdf
  38   Fri Mar 7 15:33:14 2008 DmassLaserEOMEOM shipped
I packaged up and shipped the EOM back to UF. The translation stage, also theirs, was sent with it. Everything is marked c/o Guido Mueller.
  37   Tue Mar 4 16:00:28 2008 DmassLaserPSLISS
I moved the (non logging) ISS PD after the PMC, and changed the mirror/camera setup some.

Setup post PMC should now have ~5% of the power going to the camera, with the rest going to a BS for the ISS photodiodes.
  36   Mon Mar 3 01:21:19 2008 ranaLaserMOPApower drift
This plot shows the power drift over the last few days.
The SIDE_OUT16 channel is the one. The y scale is zoomed in here but
zero corresponds to zero power. The faster spikes have a ~45 minute time scale.

No idea what this is yet.
Attachment 1: test.png
test.png
Attachment 2: test2.png
test2.png
  35   Wed Feb 27 17:56:45 2008 Stefan BallmerElectronicsGeneral 
The 2nd HP 6209B 320V power supply initially didn't work because one of its backplane connectors had fallen off.
It has been fixed, and is now on the shelf, ready to be used.
  34   Wed Feb 27 17:14:47 2008 Stefan BallmerElectronicsGeneralPZT driver powered up
- Powered up the PZT driver board using the 300V power supply (the one that's working).
- I haven't measured the noise or TF of the PZT driver box, but I
connected it to Ch3 (T3_ACT) and loaded a 10^2:1^2 anti-dewhitening filter.
(That's what the schematics asks for.)
- Removed the SR560 from the control loop & connected the demod error signal
to ch3 (TOP3).
- I put the control filter into the input filter module, because I needed the DOF4
control filter bank for a relief servo, and we need an offset adjust after the
relief servo for locking.
  33   Tue Feb 26 21:05:47 2008 Stefan BallmerLaserGeneral 
Additionally to what Rana mentioned, there are two more signals hooked up:

SUS_LEFT (Ch4): PMC PZ control signal (from the SR560 loop)
SUS_RIGHT (Ch5): PMC transmitted power

We also hooked up the SUS_L_ACT (Ch4) DAC to the Laser temperature control.
Using this we closed the slow loop for the PMC
  32   Tue Feb 26 19:52:08 2008 RanaElectronicsCDSchannels
Stefan, Rana

We changed the cable hookup -- to check out the AI box + ADC.
Ch1 = 3 Vpp offset from a SRS function generator    C2:OMS-SUS_TOP1_OUT_2048
Ch2 = 50 Ohms                                       C2:OMS-SUS_TOP2_OUT_2048
Ch6 = ISS SENSE PD DC output                        C2:OMS-SUS_SIDE_OUT_2048

The laser is now on and set to record the power fluctuations over a long term. The value of the SIDE input gain
is set such that SUS_SIDE_OUT16 is in units of mW on the Ophir high power head.

--------------

We also noticed that the signals coming out of the AI box are very aliased. The thing is running at 2048 Hz but we think
that the AA and AI filters have 10 kHz cutoffs (D070081-00).

Next:
-----
- Redo the FE diagram to get rid of OMC SUS and make a PSL diagram.
- Get the trending working right.
- Up the FE sample rate to 32768 Hz
  31   Sat Feb 16 15:33:25 2008 DmassLaserPSLRadial Beam Profile
The following were taken with the beam scanner (having gone through a number of optical elements).

After leaving the main laser housing, the beam hits:
polarizer -> PBS -> low reflectivity pickoff mirror -> 1m lens -> 0.5m lens -> 45-P HR mirror -> 45 P HR mirror -> beamscan.

In taking my initial waist measurements, I had the beamscan after the LR pickoff, and the beam looked similar.
Attachment 1: 2_16_0835w.bmp
  30   Sat Feb 16 13:46:19 2008 DmassLaserPSLLaser Aperture closed.
Laser was powered up with the aperture closed. It was fairly warm to the touch. I opened the aperture. I don't know if it is a "bad thing" to be dumping all 35W on the stop for large times. Sat @ 1:40.
  29   Tue Feb 12 17:00:35 2008 DmassLaserPSLMode Matching/Lock
I got a solution for mode matching the 35W to the PMC with 2 100mm (focal length) lenses. I abandoned this since they were deemed too fast by Stefan, and were seperated by ~1 focal length. We ended up using a 1m and .5m lens (all lenses from the newport kit in 058). My code choked on this solution and needs some bugs ironed out (will attach afterwards), so we used Stefan's.

We then managed to get a 00 lock, at a somewhat meager power throughput. Pictures of the layout below:
Attachment 1: PMC_MM.JPG
PMC_MM.JPG
Attachment 2: lenses_mmJPG.JPG
lenses_mmJPG.JPG
  28   Tue Feb 12 16:54:13 2008 DmassLaserPSL35W profile/waist
The beam output by the 35W in 058 was significantly elliptical (up to a 10% difference in the waist measurements). I used the profile given by the "more gaussian" axis, and found a waist 9.7 cm inside the front of the enclosure, 250 microns in radius. We ended up using this axis to mode match to, but this ellipticity will probably need to be addressed as we try to maximize the power output through the PMC.

[plots to be added]
  27   Sun Feb 10 13:27:57 2008 Stefan BallmerComputingGeneralPictures of Bork-Space setup
Attachment 1: CIMG3586.JPG
CIMG3586.JPG
Attachment 2: CIMG3587.JPG
CIMG3587.JPG
Attachment 3: CIMG3588.JPG
CIMG3588.JPG
Attachment 4: CIMG3589.JPG
CIMG3589.JPG
  26   Sun Feb 10 13:18:07 2008 Stefan BallmerLaserGeneralTrend of Laser Power over 20h
Attached is a snapshot of the laser power over the last 24h.
The input gain is such that 1 count corresponds to about 1 mWatt
of power after the polarizing beam splitter, i.e. the the lambda/2 plate
was set to about 4 Watts.

I don't know where the short surges of power come from.
Attachment 1: LaserPower20h.png
LaserPower20h.png
  25   Tue Feb 5 18:59:07 2008 Stefan BallmerLaserGeneralBork-space running
- Used the new Bork-space system to lock the PMC with a UGF of 100Hz.
- Hooked up a temporary power monitor (using the DC of one of the ISS PD's)
to ADC Channel 6. For the moment this can be used to trend the power.

- Accidentally blew the output opamp in the ISS monitoring chain - i.e. the ISS out-of-loop
monitor is currently unusable. Needs to be fixed.
  24   Wed Jan 30 12:57:53 2008 DmassLaserPSLCharacterizing Beam
1/28/08 - Took a series of beam waist measurements on the YAG.


-The polarizations (as measured by the photon beamscanner) had very different profiles. One polarization has a dual peak (probably a reflection from some optic). This shows up after the beam has passed through the polarizer, the PBS, and one mirror.

-Initial beam characterization yielded a waist inside the Laser Box by ~3", at a width of 200 microns. Will be rechecking this. (Impossible if there is a lens at the opening, which I'm not sure is the case).
  23   Tue Jan 29 12:50:00 2008 DmassThings to BuyGeneralThings to buy wiki
Temporarily located on the 40m wiki until AdhikariWiki is released.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Adhikari_To_Buy
  22   Tue Jan 29 12:47:44 2008 DmassLaserGeneralStrange Noise
Something on the table or under it is periodically making a squeeking noise. Stefan claims this is not new though neither of us can localize it (it's < 1sec duration). Unsure as to what is the offending noisemaker.

[Update - the noise happens when the laser is off, comes from side of table (possibly beneath) opposite laser]
  21   Mon Jan 28 18:02:04 2008 Stefan BallmerLaserGeneral1.2MHz Laser intensity oscillation
While working on the PDH loop for the PMC I noticed
a 1.2MHz oscillation on the laser intensity:

- It seems to be a bistable state: it was generally
started by some transient in the piezo input of the laser.
- The oscillation persists even when all control inputs to the laser
(EOM, PZT, AOM) are disconnected.
- It's extremely strong: about 20% fractional modulation
- Power-cycling the laser usually fixes the problem.
ELOG V3.1.3-