3-4-2009

Crack Test of the si substrate to be used in the low scatter table beam dump.

Attached are a few pdf’ and Jpg’s showing various setups

Beam Dump Construction

The beam dump will be constructed of a mirror polished Stainless sq. cone {16 deg.} this cone will be baked, and a layer of oxidation will occur on its surface to absorb the beam energy at the rate of ~80% for each of 9 bounces.  The first bounce off an si substrate itself absorbing approx 98 percent ( the major portion ) of the energy.

The mount feet will be a small path, stainless material limiting the conductive flow to the table. The dump assembly can be mounted in a vertical or horizontal configuration at 3” and 4” heights from the table.

This assembly has been setup with a 40 watt fire rod to test the convection flow, with the fins vertical and horizontal showing that no point on the assembly exceeded 100 F.

SI Substrate Durability Test

The test is to determine if  the substrate will crack due to temperature differential in the substrate

local to the beam incidence.

The si mirror was set at brewster's angle ~73.4 deg for maximum absorption of the laser energy.

Rana and I set up the si substrate by simply clamping it to a stage, and adjusting, and orienting it to center the 1064 laser  beam.

Initially the laser output was 8.6 watts, the si substrate did not crack, the temperature rose to a steady 105 F after

about one minute.

Next after Peter King adjusted the laser internally a retest was made at 32 watts, this also did not crack the substrate and after about one minute the substrate temp rose to a steady 206 F. given the beam is smaller in diameter  than the actual beam, Rana’s opinion was it ‘passed’ the test and we should proceed with the design.

The beam dump when assembled will have a finned aluminum heat sink in contact with the substrate.

An additional test will be made to determine compatibility of the si interface material, re. thermal expansion of the

aluminum heat sink / bonding material / si substrate, in the end we can just pot it, and use the cone to secure the si in a machined recess in the heat sink body.

Thanks to the help of all the people I've been hassling about this, the DAQ system is up and running.

I'll try to put together more of an 'idiot's guide to the RCG' at some point in future to supplement the information in the manual.  In the mean time for those that are interested in what's running, we have a model that looks something like the attached images (OMS.mdl which can be found in /cvs/cds/advLigo/src/epics/simLink/)

The model has four inputs from the ADC (the ADC is the lower BNC connector unit in the rack, labelled 'BNC anti-alias chassis'), followed by input filters on each channel.  These then go to an input matrix.  The ouput also has a filter on each channel followed by an output matrix.  The signals then go to the DAC.

I've tested the input with a siggen, and we can see realtime stuff in dataviewer, and frequency domain in DTT.  This is all working now.  It's running at 64khz at the moment and we'll be altering this down to 32 at some point soon.

I have also built some filters in foton, and after some fiddling with the settings they're running at the correct frequency.

Next up I want to make sure I can get a sensible signal back out of the DAC and then do some noise measurements on the input and output of the system.

We now have the right cable to connect audio equipment with a standard 2.5mm headphone jack (ipods etc) to the hi-fi.  Just set the stereo to 'game' and you're away.

The output from the DAQ is now working, and the timing etc looks sensible, though still at 64khz.  I've only tested the four outputs I've setup in my model, but they all work when I use the output matrix to patch the signal to them.

I was trying to get the ATF.mdl or OMS.mdl system back up and running, but neither could see fb0.

I telneted in with

>telnet fb0 8087

daqd> shutdown

to reboot fb0. It didn't fix the problem.

I also rebooted oms.

I discovered in the course of this that the oms.mdl file was overwritten with Alastair's model. I (saved and) replaced it with an old copy of the oms.mdl file from ws1, and did

make oms

make install-oms

make install-daq-oms

make install-screens-oms

startoms

but was no longer able to get a connection to fb0.

I then reinstalled Alastair's model, since it was the last thing I saw communicate with the fb succesfully. I am unsure what I am forgetting, possibly some command I need to run on oms after rebooting it. I was unable to get Alastair's model back up and talking to the framebuilder and I have thus left the DAQ slightly more broken than I found it.

We're starting to accumulate a lot of loose data sheets and other paraphernalia. We should arrange to get a small filing cabinet down here. I'm sure Office Depot can serve us well on that one.

Also DMass and I think we should get a third IAC Industries workbench (the white ones with the Linux machines on them).

A.

I found the 35W on with the shutter closed @ 4pm Sunday. It was off as of 8pm friday, with the shutter closed. I checked the power out, and it was ~ 29W. The steering mirrors into the PMC are gone, and the DAQ system is down, so there will be no trending of power from the pickoff diode.

Since there seems to be nothing useful to do with the PSL without an unknown amount of troubleshooting, I am turning off the laser rather than leaving ir dumping onto the shutter, which is now nice and toasty.

I hope to have the DAQ and PMC Servo back soon.

The chiller has been begging for new filters for a while. I don't know if we ever starting loggin the chiller data, but I expect the water to have the conductivity of lemon juice by now.

This all started when I did a cvs update. I have forwarded my concerns, trials, and tribulations to the russian.

This from Alex:

"Looks like we changed GM nodename from fb into fb0 in the code, so I had
to rename the node in /etc/gm/hostname.

It is up and running"

This got the oms system back up and running. Data was going into the ADC, through the filters, and back out the DAC.

I got the ATF system up and running, but had to change one more thing.

in the /cvs/cds/caltech/target/fb/master file there is a line which tells you which .ini file to use (in /cvs/cds/caltech/chans/daq/) If this is not set correctly nothing will really work.

We can configure it to have more than one system run at the same time by giving them different dcuids, but until we want to do that, to change to a new system, after you configure your sys.ini file, you have to manually put it in the master file.

On to medm screens.

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

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

C2ATF_MASTER has links to what is there.

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

Pics to be included later.

Enjoy.

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

Had problems compiling/making the Realtime Code Generator (RCG) example application in the document T080135-00-C.

Got Dmass onto the case and we tried the following things:
1. Renamed the file AFB.mdl so that it was lowercase: afb.mdl - result: 'make' still failed
2. Replaced the mux/demux elements in the ETMX subsystem with standard 8x8 matrices - called 'Matrix' and 'Matrix1' - result: 'make' still failed
3. Renamed the output elements in the ETMX subsystem so that there were no lowercase names: ULOut -> UL_OUT, UROut -> UR_OUT, etc. Result: 'make' still failed
4. I compared the 'make' output of making oms.mdl, which is a working version of the same example application, with the 'make' output of making afb.mdl. Initially the making of afb.mdl differed because it couldn't find the elements ETMX_Matrix and ETMX_Matrix1. I renamed these matrices in afb.mdl with all uppercase names (IN_MTRX and OUT_MTRX) and the make of afb.mdl progressed further before encountering an error and failing again.

At this point it gave the following complaints:
../AFB/AFB.c: In function `feCode':
../AFB/AFB.c:88: error: structure has no member named `AFB'

To be honest, I suspected that there was some residual junk code somewhere from all the previous failed compliations and the renaming of the filename from uppercase to lowercase

I copied the simuLink model afb.mdl to afc.mdl, a completely clean and shiny new name, and tried making afc.mdl instead. And it worked fine.

So the good news is that the simLink example I created makes and that 'make' itself is working fine.

The bad news is that some combination of the above actions has, presumably, left some junk files somewhere that are screwing up the making of afb.mdl. So ... how do i completely clean up an old and failed make?

Found uninstall solution in DMass's elog entry:

Useful things to try when making Simulink models with RCG

1. When making a new model foo.mdl use the following text
make uninstall-daq-foo
make clean-foo foo install-foo
make install-daq-foo
make install-screens-foo

2. start the MEDM screen C2FOO_GDS_TP.adl

2. A. kill whatever is running:
e.g. on oms > killoms
       > killatf
2. B.  find the .ini (C2FOO.ini) and edit it so that at least one channel is acquiring - do this whenever an install or reinstall are run.
2. C. manually edit the master file in fb0 to point to C2FOO.ini
  /cvs/cds/caltech/target/fb/master
2. D. start foo on oms > startfoo

see if things start to light up on the MEDM screen C2FOO_GDS_TP.adl

check if the front end is running
      /sbin/lsmod
  - should see 'foofe' and 'gm' running

look at the log file in /cvs/cds/caltech/target/c2foo
 - log.txt - will either be a couple of lines with an error message or a lot of stuff that looks like things are working:

3. go to /etc/rc.local and add foo to file. file is read-only so use 'sudo vi rc.local'
e.g. /etc/setup_shmem.rtl ipc sas test oms atf afb afc foo&

update shared library index (see Tobin's entry)
   > /sbin/ldconfig

4. try a restart of oms
   > sudo reboot

try 'startfoo' again - hopefully at this stage parts of the MEDM screen should start lighting up

5. if still problems (parts of GDS MEDM screen are still white), try to reboot fb0
   > telnet fb0 8087
      > shutdown
 
try to start again
   > killfoo
   > startfoo

6. check last line of log file /cvs/cds/caltech/target/c2foo/log.txt -
might require BURT restore

go to C2FOO_GDS_TP.adl MEDM screen and set BURT restore value to 1

should be okay now ...
 

I have been working at relocking the PMC and have been running into a lot of problems.

The table layout when I approached it - the old mode matching lenses were still in place, but the last two the steering mirrors into the PMC after the lenses were gone. I looked at an old elog photo and put the last two mirrors back about at the right place.

Then I

1. Minimized the table power by rotating almost everything into s before the polarizing beam splitter ~100mW of P on the table.
2. Aligned crudely aligned to the PMC until I got fringes out the other side.
3. Aligned more by hand, sweeping the cavity with a funciton generator until I started to see what looks like 00, then try to crudely maximize this by hand/eyeball
4. Then I set up a PDH locking using

•  A Marconi at 10 dBm and 35 MHz into a splitter
•  One output of the splitter into the EOM
•  The other output through a 3 dB attenuator into the L channel of a ZAD-6 Mixer
•  A Thorlabs PDA10A photodiode (not the best for 1064 - Si) on PMC REFL
•  The output of the PD into the RF of the Mixer
• The Output of the Mixer into an SR560 amplifier
• The output of the SR560 into the DAQ

I was unable to get a good error signal /unable to lock by toggling a 1 Hz pole as I swept through resonance with various DC gains and offsets

Things I tried:

• Changing the PD cable length by 1.4m (about .437*pi)
• Changing the gain of the SR560 to get in the middle of the dynamic range of my ADC
• Changing the sign of my feedback to be wrong (desparation?)
• Checked the alignment onto the photodiode on a scope (tens of mV)
• Checked the output of the mixer into an HP4395A to make sure the EOM was working - I saw the 35MHz mixed down sideband beat signal - so yes, the eom works.
• Went to measure the beam waist (maybe my coupling is so bad that even perfectly aligned my error signal would be buried in the noise?) and noticed a serious ghost beam almost coaxial
• Qualitatively compared the modal content of the beam to an old measurement to see if I had a bimodal PSL output
• Replaced the first mirror after the mode matching lenses by one with a wedge in a non circular mount.
• Not using the SR560 and just using an analog passive low pass filter (pole at 1.9 MHz) to kill my mixed down 35 MHz sideband beat
• Putting an offset on my DAQ input based on what I see as the input when I sweep through 00
• Using the 35.5 MHz Wenzel frequency doodad (on principle - not as troubleshooting)

In the course of troubleshooting the PMC locking I took some beam scans of the PSL output.

They can be compared to the old scans

The scan in the attachement was taken right after the polarizing beam splitter.

Do we now have two beams coming out of the PSL?

I will wait for Rana or Stefan to get back before I chase th at one, as it's inside the PSL

• Instead of using the polarizer all the way, set the polarizer to transmit a few W and then use a fixed BS to attenuate down to 10-30 mW before doing the PMC alignment.
  
• The ZAD-6 is a level 7 mixer so you have to give it 7 dBm. So there should be no attenuator after the splitter for the LO.
  
• Have to AC couple (or DC block) the PDA signal before going into the mixer. It wants AC only.
  
• The mixer output should go into the 1.9 MHz low pass and then get terminated with 50 Ohms (like with a T). Then the other output of the T can go to the DAQ or into the SR560 for some gain but you shouldn't need very much gain. Certainly the SR560 should have no filter clicked on.
  
• If you use the SR560, make sure the output is zero with no light on the PD. There's a trim pot on the front.
  
• In the digital world there should be a single pole around 1 Hz. Make sure the output actually goes to the PZT driver.
  

• I have now added a 95% Beamsplitter right after the PBS to dump most of the power into another big beam dump from the 40m
  
• The ZAD-6 is now geetting exactly 7dBm of 35MHz from the Marconi
  
• I put a DC Block on the PD Output before the mixer.
  
• I terminated the input into the DAC with a 50 Ohm terminator at the DAC off a T, after the LP Filter
  
• I stopped using the SR 560
  
• The digital world has a single pole at 1 Hz toggled. The ouput goes to the PZT drive box.
  

• Removed an extra mirror from in front of the refl PD which was giving me real low optical gain. I have now all of refl (25ish mW) on the PD.
  
• Realigned "by eye" (dithered a drive signal about the 00 mode and did a really low BW servoing.
  
• Swapped in and out a pi/2 phase shift onto my drive every time I changed anything, since I have no idea if the phase is right.
  
• Changed the sign of my feedback any time it was obvious it was doing something ridiculous (I think I got a sign flip through the SR560 one time, and this may have been the only instance of having to insert a negative)
  
• Changed the offset slowly by hand when it would start to hang out on the 00 fringe to try to force it to find the peak.
  

• The mode overlap between the cavity and input beam is awful (crude alignment and no tune up of modematching means that I might be very mismatched in all 4 degrees of freedom). Maybe that means no good change in my signal on refl PD. Test this by looking at Ptrans with another photodiode.
  
• There is blue sharpie on the ZAD-6 mixer indicating that it wants +1 dBm of RF. When I plug in this signal (after the DC block) I don't see anything but noise in an HP4395A (I would expect some 35 MHz signal from the pre demod signal...I think) Do I need an amplifier or a different mixer?
  
• There is something stupid that I am not doing. The sign of my feedback was wrong after I had fixed everything else.
  
• There are two beams from the PSL that are roughly parallel (see a couple elogs back about scans). If I am hitting my PMC with both of these, there might be weird coupling going on between the misaligned one and the sidebands that puts lots of informationless 35 MHz signal on my photodiode. If this is the case we might need to open up the PSL and realign things until we aren't tempted to use more than one eigenbasis when talking about the modal content.
  
• There is something clever that I am not doing.
  
  

They're here, hot, and ...stable?

I'd like to use ADC channels 13-16 for the photodiodes in the FS experiment. Also going to use DAC channel 16 for feeding back to the AOM. We should decouple the signals on the MEDM screens so that you can't, inadvertantly, feed gyro error signals to the FS output.

Started work on a FS control screen (C2ATF_FS_CONTROL.adl shown below). It's accesible from the C2ATF_MASTER screen (also shown below). There won't be that much too it ... just an box allowing you to control the in-loop signals and the feedback to the frequency of the AOM. The lower box will simply be the input  signals from the out-of-loop PDs.

 They also make green.

I succeeded in getting some number of microwatts (very very dim with the lights out - so much dimmer than commercial laser pointers) of green having locked the PMC. I changed the table layout a lot today, I will post a full entry on that later. More information to follow.

The chiller wants new filters really badly. It was also making funny noises (somewhere around 1 Hz) that didn't sound all that healthy. I have turned the PSL and chiller off.

I have included pictures of the new table layout below. I labeled what I consider "non obvious optics"

 I've started to to block out the parts for the fiber stabilization experiment as in the attached layout ... basically to check that everything is there.

Nothing is aligned and some of the lenses are just standing in right now. 

The photos show before and after for the table. I think we're going to need a rack or bench nearby for scopes, analyzers, power supplies, etc.

Unless there is another stash somewhere, we are now short of clamps (two or three are now spare), 3" pedestals (four or five spare), mirror mounts (maybe half a dozen left) and InGaAs photodiodes.

We should put together a general order for this stuff in the near future.

I have blocked out the FS experiment. The following stuff is not installed:

1. Partial reflector (PR1-1064-95-IF-1037)

2. A QWP

3. A second AOM at 80MHz

According to Techmart, I ordered the Partial Reflector and QWP back in January, however, I remember that CVI had contacted me about a couple of longer lead time items - can't quite remember what they were. Will check the delivery notes.

 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.

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.

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

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!

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.

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

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

 FORMAT PLEASE!

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.

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

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.

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.