40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 54 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  132   Fri May 15 17:53:25 2009 DmassLaserPSLChiller making funny noises

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.

  131   Fri May 15 17:41:43 2009 DmassLaserDoublingSHG Ovens

Quote:

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

 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.

Attachment 1: SmallFirstlight.png
SmallFirstlight.png
  130   Fri May 15 17:32:30 2009 AidanComputingFiberStarted screen for Fiber Stabilization - and claiming CDS channels

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.

 

 

 

Attachment 1: Screenshot-C2ATF_FS_CONTROL.adl.png
Screenshot-C2ATF_FS_CONTROL.adl.png
Attachment 2: Screenshot-C2ATF_MASTER.adl.png
Screenshot-C2ATF_MASTER.adl.png
  129   Fri May 15 14:13:18 2009 DmassLaserDoublingSHG Ovens

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

Attachment 1: shgoven.png
shgoven.png
  128   Fri May 15 04:23:19 2009 DmassLaserPMC Relocking the PMC
Let there be lock. Picture included below.

  • 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.
I Also:
  • 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.

W.A.G.s and musings
  • 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.


Quote:
  • 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.
Attachment 1: Pmclock.png
Pmclock.png
  127   Thu May 14 20:57:22 2009 ranaLaserPMC Relocking the PMC
  • 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.
  126   Wed May 13 17:13:29 2009 DmassLaserPSLBeam Scans

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

 

Attachment 1: afterPBS.bmp
  125   Wed May 13 16:57:28 2009 DmassLaserPMC Relocking the PMC

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)

 

  124   Tue May 5 16:36:40 2009 AidanComputingCDSRealtime code generation (RCG) troubleshooting

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 ...
 

  123   Tue May 5 14:43:05 2009 AidanComputingCDSRCG make screwiness - how do i clean up old and failed makes?

 

Found uninstall solution in DMass's elog entry:

 

Quote:

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?

 

  122   Fri May 1 16:39:12 2009 AidanComputingCDSRCG make screwiness - how do i clean up old and failed makes?

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?

  121   Sat Apr 25 12:11:54 2009 ranaComputingDAQATF Screens/DAQ up and running.
Cool. For properness all of the medm screens should be in the /cvs/cds/caltech/medm/ directory. We should
also pull down the medm/c1/ directory from the 40m SVN, since its always useful for copy-paste
operations. And all of the FE code (models, etc.) should be in the caltech/target/ dir.

How about second-trend and minute-trend? How far is the lookback? Do we need a bigger disk?
  120   Thu Apr 23 15:25:35 2009 DmassComputingDAQATF Screens/DAQ up and running.

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.

  119   Wed Apr 22 14:47:47 2009 DmassComputingDAQDAQ back 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.

 

Quote:

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"

 

 

 

  118   Wed Apr 22 11:33:24 2009 DmassComputingDAQDAQ back up and running

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"

 

 

  117   Mon Apr 20 18:03:44 2009 dmassComputingDAQADC no longer working!

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

 

Quote:

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.

Quote:

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.

 

 

 

  116   Sun Apr 19 16:08:03 2009 dmassLaserPSLThe chiller wants new filters

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.

  115   Sun Apr 19 16:01:35 2009 dmassLaserPSLLaser On

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.

 

  114   Fri Apr 17 20:05:59 2009 AidanLab InfrastructureGeneralAnother workbench and a filing cabinet

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.

 

 

  113   Fri Apr 17 20:04:17 2009 dmassComputingDAQADC no longer working!

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.

Quote:

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.

 

 

  112   Thu Apr 9 11:26:21 2009 alastairComputingDAQDAC now working

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.

  111   Thu Apr 9 10:02:24 2009 alastairLab InfrastructureGeneralAudio/mp3

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.

  110   Thu Apr 9 09:52:54 2009 alastairLab InfrastructureDAQDAQ up and running

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.

Attachment 1: model1.png
model1.png
Attachment 2: model2.png
model2.png
  109   Thu Mar 5 19:24:06 2009 ken mailandLaserGeneral35 watt table beam dump

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.

 

Attachment 1: Vertical_Test_Beam_Dump_Heat_Sink.jpg
Vertical_Test_Beam_Dump_Heat_Sink.jpg
Attachment 2: 32_watt_test.jpg
32_watt_test.jpg
Attachment 3: Beam_Dump_Assem_.jpg
Beam_Dump_Assem_.jpg
Attachment 4: Beam_Dump_Assem_.pdf
Beam_Dump_Assem_.pdf
  108   Wed Mar 4 15:20:14 2009 pkingLaserPSLlaser re-aligned
I fired up the laser this afternoon because Ken Mailand wanted to
test the silicon beam dump. The output power of the laser was pretty low,
around 8W or so. I re-aligned things a bit and now the output power is
around 32W. Further improvement involves opening up the amplifier I think.
This was all without adjusting any diode currents and wotnot. Just the
alignment.
  107   Fri Jan 23 16:48:29 2009 DmassLaserPSLChiller noise and DeI water
John Miller emailed me about the chiller once again whining. The water level was almost at the "min" line, and he filled it. This appears to not have been the culprit for the alarm. The screen on the chiller read "filters" and the noise stopped when I touched a button. The light in back which turned red when the water started to fail the deionized test is still red.

To my knowledge the following is the story

The new chiller wants Deionized water. It has brass fittings in it's plumbing, and by 40m lore, we do not mix brass fittings and deionized water - also Peter King said that it would be ok to use distilled water - I filled it with distilled water, and after a few weeks of stable operation (no noise or leaks) the red light on the back of the chiller went off (which I believe is triggered by the resistance of the water dropping too low). The high pitched whine of an alarm noise would periodically come on, and I would periodically turn it off. After this last time which I was notified of ~1 week ago by John Miller, the readout on the chiller said "filters" instead of "dei". I do not know how much attention we should pay to the purity of the water, and we may want to look into disabling the alarm if we continue using distilled water with the deionized water system.
  106   Wed Jan 14 18:14:23 2009 AidanThings to BuyFiberResidual things to buy for FS - extra photodiodes

Quote:

Quote:

A large fraction of the equipment is already in the lab from Masha's experiment earlier in the year. The following is required for the latest design of the experiment. In the interim we can probably use the Marconi to drive AOM1.


Specifics
---------
2x Half wave plates - QWPO-1064-05-2-R10
1x Quarter wave plate - QWPO-1064-05-4-R10
3x rotation stages - New Focus 9401


General
-------
Partially transmitting retro-reflector
AOM # 2
Mode-matching lenses (possibly - might have enough downstairs)
RF photodiodes - (10-MHz InGaAs Photoreceiver (Free Space input) Model 2053-FS?)
VCO + power amp for AOM#1 - center frequency probably 77.5MHz, ~2W to AOM
Crystal oscillator + power amp for AOM#2 - probably 80MHz, ~2W to AOM
Oscillator for demod - probably 5MHz, 17dBm

What else? hmm ...


Ordered the following:
2x Half wave plates - CVI - QWPO-1064-05-2-R10
1x Quarter wave plate - CVI - QWPO-1064-05-4-R10
3x rotation stages - New Focus - 9401
1x partially transmitting retro-reflector: CVI - PR1-1064-95-IF-1037 - 95% reflectance



Also ordered 2x Thorlabs - PDA10CS 17MHz InGaAs photodiodes
  105   Wed Jan 14 11:33:58 2009 AidanThings to BuyFiberResidual things to buy for FS - QWPs, HWPs, output coupler

Quote:

A large fraction of the equipment is already in the lab from Masha's experiment earlier in the year. The following is required for the latest design of the experiment. In the interim we can probably use the Marconi to drive AOM1.


Specifics
---------
2x Half wave plates - QWPO-1064-05-2-R10
1x Quarter wave plate - QWPO-1064-05-4-R10
3x rotation stages - New Focus 9401


General
-------
Partially transmitting retro-reflector
AOM # 2
Mode-matching lenses (possibly - might have enough downstairs)
RF photodiodes - (10-MHz InGaAs Photoreceiver (Free Space input) Model 2053-FS?)
VCO + power amp for AOM#1 - center frequency probably 77.5MHz, ~2W to AOM
Crystal oscillator + power amp for AOM#2 - probably 80MHz, ~2W to AOM
Oscillator for demod - probably 5MHz, 17dBm

What else? hmm ...


Ordered the following:
2x Half wave plates - CVI - QWPO-1064-05-2-R10
1x Quarter wave plate - CVI - QWPO-1064-05-4-R10
3x rotation stages - New Focus - 9401
1x partially transmitting retro-reflector: CVI - PR1-1064-95-IF-1037 - 95% reflectance
  104   Thu Jan 8 19:59:50 2009 AidanMiscGeneralEarthquake ...

Just felt the building shake. Didn't feel as a large as last year's quake.

Apparently a 5.0 in San Bernadino ...
  103   Tue Nov 25 17:30:32 2008 AidanLaserFiberPreliminary noise budgets for fibre stabilization

Here are some preliminary noise budgets for the FS experiment ... or rather, the setup shown in attached figure. Looks like the laser frequency noise dominates.
Not surprising given that the optical path length difference is ~150m.

The photodiode noise is not particularly high, although if we stabilize the frequency and intensity of the NPRO it might become a factor.

Anyway, the phase and frequency noise plots are attached. Will post references to the origin of the actual curves for the different noise sources soon.
Attachment 1: simulation_v1B.jpg
simulation_v1B.jpg
Attachment 2: phaseNoiseBudget-NPRO-PDA255.pdf
phaseNoiseBudget-NPRO-PDA255.pdf
Attachment 3: freqNoiseBudget-NPRO-PDA255.pdf
freqNoiseBudget-NPRO-PDA255.pdf
  102   Tue Nov 25 17:12:01 2008 AidanThings to BuyFiberResidual things to buy for FS

A large fraction of the equipment is already in the lab from Masha's experiment earlier in the year. The following is required for the latest design of the experiment. In the interim we can probably use the Marconi to drive AOM1.


Specifics
---------
2x Half wave plates - QWPO-1064-05-2-R10
1x Quarter wave plate - QWPO-1064-05-4-R10
3x rotation stages - New Focus 9401


General
-------
Partially transmitting retro-reflector
AOM # 2
Mode-matching lenses (possibly - might have enough downstairs)
RF photodiodes - (10-MHz InGaAs Photoreceiver (Free Space input) Model 2053-FS?)
VCO + power amp for AOM#1 - center frequency probably 77.5MHz, ~2W to AOM
Crystal oscillator + power amp for AOM#2 - probably 80MHz, ~2W to AOM
Oscillator for demod - probably 5MHz, 17dBm

What else? hmm ...
Attachment 1: adhikari_lab_v1C.jpg
adhikari_lab_v1C.jpg
  101   Sat Nov 8 21:38:17 2008 DmassLaserPSLChiller Noise

Quote:
The new chiller was making a noise (as reported to me by John).

It was emitting a continuous high pitched tone, and the display alternated between the set point temp, and "d1" or "di".
I hit enter twice, and it stopped. To be safe, I have turned the 35W off until I spend some time down here and make sure
that the chiller is ok. I have left the chiller on.


The chiller was making the noise again. Again it said di on the screen. The noise and warning went away when I pushed any button on the front panel. I think it's just a warning that the water no longer qualifies as DI, as the light on the back of the chiller was red (it's green when the resistance is high, red when low - either change the di cartridge or figure out how toe disable the noise. As we don't necessarily want to use DI water because of the metal plumbing, I am inclined to disable the warning noise if I can.
  100   Thu Oct 9 08:47:54 2008 AidanLaserFiberDismantled fiber stabilization setup


Packed up the current setup. Am going to rebuild with beam double passed through the fiber and an 80MHz AOM.
  99   Wed Oct 8 13:40:02 2008 DmassLaserPSLChiller Noise
The new chiller was making a noise (as reported to me by John).

It was emitting a continuous high pitched tone, and the display alternated between the set point temp, and "d1" or "di".
I hit enter twice, and it stopped. To be safe, I have turned the 35W off until I spend some time down here and make sure
that the chiller is ok. I have left the chiller on.
  98   Tue Sep 23 12:10:08 2008 AidanLaserFiberMaximized fiber coupler ROLL angle.

Set the input fiber coupler roll angle to 190 degrees on the graduated scale. Rotated the half wave plate after the output of the fiber to maximize the fringe magnitude output from the MZ.

Vpp max = 4.52V (peak-to-peak value of demodulated output of PD with residual 20Hz signal)
Vpp min = 4.22V

Fringe magnitude fluctuation = 7% of maximum fringe magnitude.

(All this was running open loop in the fiber stabilization, by the way)
  97   Tue Sep 23 10:15:15 2008 AidanLaserFiberFringe magnitude fluctuation investigation - why isn' the maximum 45 degrees from the minimum?

Quote:

The attached photo shows the fiber coupler in question and the ROLL angle adjustment and graduations (set to 120 degrees)

Using Masha's fiber stabilization setup, I looked at the interference fringe magnitude on transmission through the fiber. The frequency difference between the two arms in the MZ interferometer was (200MHz + 20Hz = 200.000020MHz). I demodulated the output by exactly 200MHz leaving a 20Hz signal on the output. I observed this output on an oscilloscope and monitored the fringe magnitude over time. In the past, the magnitude has been observed to drift (Eric G thinks this is most likely due to the input into the polarization maintaining fiber not being injected with the correct polarization). Over a period of 2-3 minutes I recorded the maximum and minimum fringe magnitudes (the maximum and minimum peak-to-peak values). I did this for several of ROLL rotation angles for the input fiber coupler (FC1). I only did a quick job of optimizing the output of the fiber when it was rotated to a new position, but I did secure it into that position once it was optimized.

Here are the results:
Fringe Size (Vpp)
ROLL ANGLE | MAXIMUM (V) | MINIMUM (V)
--------------------------------------------
120 deg | 3.27 | 0.04
139 deg | 4.00 | 1.60
150 deg | 4.74 | 2.64
165 deg | 4.94 | 3.62
180 deg | 4.42 | 3.88
195 deg | 3.80 | 3.48
210 deg | 3.36 | 2.54
225 deg | 2.53 | 1.47
240 deg | 1.84 | 0.68
255 deg | 1.46 | 0.15
---------------------------------------------

We can define the relative fluctuation in the fringe visibility/magnitude as the difference between the maximum and minimum divided by the maximum fringe size. The results are shown in the attached plot. It's obvious that the optimum rotation angle to be at is at arodun 190 degrees.


The reason that the output polarization wanders is as follows: the fiber is birefringent and will, in general, convert linearly polarized light into elliptically polarized light unless the input is aligned with the fast axis of the fiber. So, in this respect, it functions exactly like every other birefringent material. The fiber complicates matters because small changes in its length (e.g. due to temperature fluctuations) will vary the phase delay between the fast and slow axes and cause the ellipticity of the output light to fluctuate ... again, assuming that the light is not aligned with the fast axis.

So if the input field is mostly aligned with the fast axis (e.g. in the 175 - 205 degree range) then the output polarization fluctuates between being linearly polarized and slightly elliptically polarized. If it is far from being aligned then the polarization of the output is expected to fluctuate by a large amount.

Which leaves a problem ... shouldn't the maximum amount of polarization fluctuation occur at 45 degrees from the fast axis? After all, if the input field is 100% aligned to the slow axis then one would naively expect that the polarization should be insensitive to fluctuations in length. It might be time to get a PBS into the system to look at the output from the fiber.
  96   Mon Sep 22 20:20:25 2008 AidanLaserFiberFringe magnitude fluctuation investigation

The attached photo shows the fiber coupler in question and the ROLL angle adjustment and graduations (set to 120 degrees)

Using Masha's fiber stabilization setup, I looked at the interference fringe magnitude on transmission through the fiber. The frequency difference between the two arms in the MZ interferometer was (200MHz + 20Hz = 200.000020MHz). I demodulated the output by exactly 200MHz leaving a 20Hz signal on the output. I observed this output on an oscilloscope and monitored the fringe magnitude over time. In the past, the magnitude has been observed to drift (Eric G thinks this is most likely due to the input into the polarization maintaining fiber not being injected with the correct polarization). Over a period of 2-3 minutes I recorded the maximum and minimum fringe magnitudes (the maximum and minimum peak-to-peak values). I did this for several of ROLL rotation angles for the input fiber coupler (FC1). I only did a quick job of optimizing the output of the fiber when it was rotated to a new position, but I did secure it into that position once it was optimized.

Here are the results:
Fringe Size (Vpp)
ROLL ANGLE | MAXIMUM (V) | MINIMUM (V)
--------------------------------------------
120 deg | 3.27 | 0.04
139 deg | 4.00 | 1.60
150 deg | 4.74 | 2.64
165 deg | 4.94 | 3.62
180 deg | 4.42 | 3.88
195 deg | 3.80 | 3.48
210 deg | 3.36 | 2.54
225 deg | 2.53 | 1.47
240 deg | 1.84 | 0.68
255 deg | 1.46 | 0.15
---------------------------------------------

We can define the relative fluctuation in the fringe visibility/magnitude as the difference between the maximum and minimum divided by the maximum fringe size. The results are shown in the attached plot. It's obvious that the optimum rotation angle to be at is at arodun 190 degrees.
Attachment 1: fiber_coupler_rotation_angle_output_fluctuation.jpg
fiber_coupler_rotation_angle_output_fluctuation.jpg
Attachment 2: 00003.jpg
00003.jpg
  95   Mon Sep 22 18:03:34 2008 DmassComputingDAQDAQ IS BACK - as is the 35W
The Chiller appears to not be leaking.
There are no squeaks coming from under the table.
The 35W is on.
The DAQ is recording again (fix detailed below)
The 35W is being trended at a pickoff post-MOPA
The 2W NPRO will be trended when I get my hands on the PD schematic from the Germans. PK emailed them


I talked to Alex, and it seems the problem was in
controls@oms > /frames/full/dataxx

I had changed the filesize apparently (by changing the sample rate), and the software doesn't correct for that in the number of files it keeps.

I had to edit /cvs/cds/caltech/target/fb/daqdrc

I deleted all the files in /frames/full, then decreased the sample rate in
/cvs/cds/caltech/chans/daq/C2OMS.ini to 16 kHz for the channels I am interested in.

Then I upped the number of dataxx files to 120 from 60 to correct for the factor of 2 it was off by before, and the factor of four division in sample rate I gave it in daqdrc.

Then I tried to make everything again in advLigo by running:
* make uninstall-daq-oms
* make clean-oms oms install-oms
* make install-daq-oms
* make install-screens-oms
* startoms


I looked at the log files for the fb in /cvs/cds/caltech/target/fb/logs/* and found errors about the dataxx files (which I had deleted) not existing, so I replaced them by hand with the following in a bash file (filename.sh):
#!/bin/bash
for i in `seq 0 119`; do
mkdir "data$i"
done

and running it with >bash filename.sh in the /frames/full directory.

I then rebuilt everything, restarted the fb by telneting in
* telnet fb0 8087
daqd>shutdown


and reset the daq in the oms medm screens via the reset button. After all this the data was writing again.
  94   Sun Sep 21 15:45:21 2008 DmassLaserPSLChiller on. 35W on.

Quote:
Peter got word back from Christian and told me how to modify the adapter he made (schematic to be posted later when he emails it to me). The errors disappeared and then we modified the chiller settings to LZH specifications except for

r.start (we had to set it to off rather than on to get the chiller to turn on).

The chiller has shown no signs of leaking and it has been on for ~24 hours now.
The 35W is back on. There is something wrong with the DAQ again, and I can not get it to write. I do not think anyone has modified anything at our end since we last had it working.

I am turning the laser off over the weekend since we are not trending. I am leaving the chiller on with a bucket underneath the new fittings incase it develops a drip.


There appears to have been a small (a few cc's over a couple days) leak coming from the circled fitting. I tightened the offending wireclamp significantly (~3.5 turns) without worrying about damaging the hose as we are using the incredibly thick walled clear plastic hose. I also noticed some wetness coming from the joint indicated in the picture by the green arrow. I removed it, replaced the teflon tape, and re-tightened it.

I also used some cable ties to support the plumbing so it wouldn't put all the weight on my plumbing joint.

I left the bucket underneath, and will be checking the chiller daily to see if the leak is still there.

There was no apparent wetness after several hours.
Attachment 1: Chiller_Back.png
Chiller_Back.png
  93   Fri Sep 19 13:18:00 2008 DmassLaserPSLChiller on. 35W on.
Peter got word back from Christian and told me how to modify the adapter he made (schematic to be posted later when he emails it to me). The errors disappeared and then we modified the chiller settings to LZH specifications except for

r.start (we had to set it to off rather than on to get the chiller to turn on).

The chiller has shown no signs of leaking and it has been on for ~24 hours now.
The 35W is back on. There is something wrong with the DAQ again, and I can not get it to write. I do not think anyone has modified anything at our end since we last had it working.

I am turning the laser off over the weekend since we are not trending. I am leaving the chiller on with a bucket underneath the new fittings incase it develops a drip.
  92   Tue Sep 16 22:55:30 2008 DmassLaserPSLConnectors needed
Peter King and I hooked up the chiller to itself and ran it looking for "gunk" in the system. We satisfied ourselves that there was none, and I connected it to the laser and control box after a minor undertaking to get the adapters we need to hook the new chiller up to the old hardware. I ended up only adding one 3 inch piece of tubing with barbed 3/8 inch connections + wire clamps to hold it on.

We turned on the system and there are no obvious leaks. I replaced the DI water with distilled, since there are loads of brass fittings in the new chiller (PK agreed with this logic). There was a small light on the back which goes red if the conductivity of your water is too high. It did.

There is also a DI filter to reduce the conductivity of your water. It seems to work, as our warning light turned to green after about 10 minutes of running.

Peter gave me a dongle (15 pin dsub to 15 pin dsub) to adapt the the new chiller to the old control box. He made this via Christian's instructions. We were unable to get the diode box to turn the diodes on, and were presented with the following errors:
Flow control error - system off (when nothing was connected) and:
Chiller overtemp error - system off (when we had the adapter connected),

We tried using the old breakout "cheater" board to short the various pins to each other, and were unable to bypass the diode control box's unhappiness. PK is contacting Christian about this.

The chiller seems ok - but it will not play nice with the control box, so the 35W is still off at this point


Quote:
I got the replacement chiller (a Neslab Thermoflex1400) from 046 W. Bridge. I unpacked it and moved it by the PSL optics table in 058 W. Bridge. Peter King called LZH and is going to make the connector adaptation we need for the new Chiller unit.

I also siphoned the water out of the old chiller to see what plumbing fittings we may need in moving to the new unit. It was delicious.

I will not be firing the 35W laser back up until I have had the all clear from Rana after I make the chiller swap.

Update: The plastic pipe fittings from the old unit are 3/8" BSPT tapered threads. The new chiller takes 1/2" normal threads. The 1/2" male to 3/8" female adapter I got from Home Depot are relatively useless as a long term solution and would probably damage the BSPT tapered threading. We can either get some cheap barbed style T-splitter and make stuff with hoses or order some BSPT adapters. I am inclined to order both and sort it out later as they are relatively cheap. This appears to be the only remaining hitch in the chiller swap.

Update2: I have ordered more new fittings from McMastercarr. I will make a summary post of all the wonderful things learned in this process.



Quote:

Quote:
I am trying to chase down the source of the long time scale sharp fluctiations in intensity. I need to start reading out the diagnostic PD from inside the MOPA head unit to see if the power fluctuations are coming before or after the amplification (e.g. NPRO or MOPA problems).

I need the following connectors from Wilson house:



Update: I talked to Peter King about swapping the chiller which appears to be the cause of the fluctuations in the power. Our current model, as the prototype, is an earlier generation from what he has, which is current with what is on site. He needs to talk to LZH to figure out if there is any additional hardware we need for the swap.

He also said that the sites used Deionized water for cooling, but said that filtered water would probably be fine. I did not get a good definition on what "filtered" consisted of. If we did move to DeI, then we might need some new plumbing. I told Peter that if things needed to be purchased we would find the money if it meant pulling copper piping from homes in Inglewood.

As we think this is the problem, I may wait on setting up data logging from the diagnostic (pre-mopa) photodiode in the head unit.
  91   Tue Sep 9 16:36:01 2008 DmassLaserPSLConnectors needed
I got the replacement chiller (a Neslab Thermoflex1400) from 046 W. Bridge. I unpacked it and moved it by the PSL optics table in 058 W. Bridge. Peter King called LZH and is going to make the connector adaptation we need for the new Chiller unit.

I also siphoned the water out of the old chiller to see what plumbing fittings we may need in moving to the new unit. It was delicious.

I will not be firing the 35W laser back up until I have had the all clear from Rana after I make the chiller swap.

Update: The plastic pipe fittings from the old unit are 3/8" BSPT tapered threads. The new chiller takes 1/2" normal threads. The 1/2" male to 3/8" female adapter I got from Home Depot are relatively useless as a long term solution and would probably damage the BSPT tapered threading. We can either get some cheap barbed style T-splitter and make stuff with hoses or order some BSPT adapters. I am inclined to order both and sort it out later as they are relatively cheap. This appears to be the only remaining hitch in the chiller swap.

Update2: I have ordered more new fittings from McMastercarr. I will make a summary post of all the wonderful things learned in this process.



Quote:

Quote:
I am trying to chase down the source of the long time scale sharp fluctiations in intensity. I need to start reading out the diagnostic PD from inside the MOPA head unit to see if the power fluctuations are coming before or after the amplification (e.g. NPRO or MOPA problems).

I need the following connectors from Wilson house:



Update: I talked to Peter King about swapping the chiller which appears to be the cause of the fluctuations in the power. Our current model, as the prototype, is an earlier generation from what he has, which is current with what is on site. He needs to talk to LZH to figure out if there is any additional hardware we need for the swap.

He also said that the sites used Deionized water for cooling, but said that filtered water would probably be fine. I did not get a good definition on what "filtered" consisted of. If we did move to DeI, then we might need some new plumbing. I told Peter that if things needed to be purchased we would find the money if it meant pulling copper piping from homes in Inglewood.

As we think this is the problem, I may wait on setting up data logging from the diagnostic (pre-mopa) photodiode in the head unit.
  90   Tue Sep 9 15:49:22 2008 DmassLab InfrastructureHVACHEPA Filters
I had turned off the east HEPA filter with Masha for a noise measurement, and I forgot to turn it back on until today. Also, it looks like someone had unplugged the west HEPA filter and not plugged it back in. The latter I noticed while changing the power cabling, so it's possible that the west HEPA was running the whole time and I only noticed that I had just unplugged it...but I think this was a long term situation.

Also, the particle counter was reclaimed by the 40m during the vent after the earthquake, so we haven't had one on the table for some time. I had not been running the laser that much during the time when both filters may have been off, but it is worth noting in case there is unexplained dirtiness noticed in the future.
  89   Fri Sep 5 03:24:37 2008 DmassLaserPSLConnectors needed

Quote:
I am trying to chase down the source of the long time scale sharp fluctiations in intensity. I need to start reading out the diagnostic PD from inside the MOPA head unit to see if the power fluctuations are coming before or after the amplification (e.g. NPRO or MOPA problems).

I need the following connectors from Wilson house:



Update: I talked to Peter King about swapping the chiller which appears to be the cause of the fluctuations in the power. Our current model, as the prototype, is an earlier generation from what he has, which is current with what is on site. He needs to talk to LZH to figure out if there is any additional hardware we need for the swap.

He also said that the sites used Deionized water for cooling, but said that filtered water would probably be fine. I did not get a good definition on what "filtered" consisted of. If we did move to DeI, then we might need some new plumbing. I told Peter that if things needed to be purchased we would find the money if it meant pulling copper piping from homes in Inglewood.

As we think this is the problem, I may wait on setting up data logging from the diagnostic (pre-mopa) photodiode in the head unit.
  88   Wed Sep 3 18:22:20 2008 AidanLaserFiberCalibrated noise spectra ... does not agree with previous measurements

Quote:
I recorded the closed loop, open loop and electronics noise in the current fiber stabilization system (single-pass through fiber, AOM after fiber). The NPRO current level was set to 1.500A. The calibrations were applied to convert from counts to radians (see here for details). The results are plotted in the attached diagram (available in JPG and EPS flavours for your viewing pleasure).

I'm concerned that the magnitude of these results are not consistent with the noise measurements made previously using the spectrum analyzer(?) ... (see here). It's probably something straightforward that I'm missing.


Apparently the previous measurements were with a different fiber.
  87   Wed Sep 3 16:43:56 2008 Aidan, BramLaserFiberFringe visibility fluctuation ... Bram's suggestions

Quote:

I tried to calibrate the fiber phase noise measurements in DTT by determining the fringe visibility (peak-to-peak size) in counts (to determine radians per count). I shifted the carrier on the VCO by 100Hz to 200.0001MHz and left the other signal generator (LO for both mixers) at exactly 200MHz. The demodulated signals from the PDs then looked like nice 100Hz sine waves. It was only then that I noticed that the amplitude of these sine waves was varying by 50% over a timescale of 20 seconds to a number of minutes.

NPRO level: 1.500A

I plotted 20 minutes worth of Max-Min data from the 2 PDs in DataViewer (see attached pdf) - there was 100Hz frequency difference between the signal generators for all but the first four minutes or so of this plot. In principle this plot shows the fringe visibility in counts and can be used for calibration purposes. As you can see, though, the pk-pk value is fluctuating with time. Presumably, as nothing has been altered on the table over the last week, the fringe visibility has been fluctuating for all previous noise measurements. Therefore only a rough calibration is possible. So here it is ...

C2: OMS-SUS_TOP1_INI_65536: pi radians: [-2750, -700] counts -> ~1500 urad/count
C2: OMS-SUS_TOP2_INI_65536: pi radians: [-3600, 4000] counts -> ~410 urad/count

Eric G happened to come in shortly after I had discovered this. He suggested that the mode-matching between the two beams may not be good enough. I will look into this.



Just got this email from Bram ... will check the state of the polarization coming out of the fiber and see if it fluctuates in the sync with the fringe visibility.


Quote:

Hi Aidan,

I just saw your elog entries about the fluctuations of the fringe visibility. If you are using PM fiber, make sure you inject into the one of the axis of the fiber, otherwise there will be power fluctuations after the fiber. If I recall on the photos you made earlier, you don't have any polarising optics in the layout.

I guess some waveplates (and maybe even a PBS) will do the trick before the fiber to align the polarisation with one of the fiber axis, and after the fiber to align the polarisation with the LO.

If I recall if you within 6 degrees of the fiber axis you can get ~ -20dB fluctuations, if going within ~2 degrees then this will drop to -30dB (got this out of an article form the Ozoptics website).

Hope this helps,

Cheers,
Bram

PS. We have exactly the same problem....:)

  86   Wed Sep 3 13:35:56 2008 AidanLaserFiberCalibrated noise spectra ... does not agree with previous measurements
I recorded the closed loop, open loop and electronics noise in the current fiber stabilization system (single-pass through fiber, AOM after fiber). The NPRO current level was set to 1.500A. The calibrations were applied to convert from counts to radians (see here for details). The results are plotted in the attached diagram (available in JPG and EPS flavours for your viewing pleasure).

I'm concerned that the magnitude of these results are not consistent with the noise measurements made previously using the spectrum analyzer(?) ... (see here). It's probably something straightforward that I'm missing.
Attachment 1: noise_calibrated_080902.jpg
noise_calibrated_080902.jpg
Attachment 2: noise_calibrated_080902.eps
noise_calibrated_080902.eps
  85   Tue Sep 2 23:09:38 2008 AidanLaserFiberAttempted calibration of fiber noise. NPRO current = 1.903A

Quote:

I tried to calibrate the fiber phase noise measurements in DTT by determining the fringe visibility (peak-to-peak size) in counts (to determine radians per count). I shifted the carrier on the VCO by 100Hz to 200.0001MHz and left the other signal generator (LO for both mixers) at exactly 200MHz. The demodulated signals from the PDs then looked like nice 100Hz sine waves. It was only then that I noticed that the amplitude of these sine waves was varying by 50% over a timescale of 20 seconds to a number of minutes.

NPRO level: 1.500A

I plotted 20 minutes worth of Max-Min data from the 2 PDs in DataViewer (see attached pdf) - there was 100Hz frequency difference between the signal generators for all but the first four minutes or so of this plot. In principle this plot shows the fringe visibility in counts and can be used for calibration purposes. As you can see, though, the pk-pk value is fluctuating with time. Presumably, as nothing has been altered on the table over the last week, the fringe visibility has been fluctuating for all previous noise measurements. Therefore only a rough calibration is possible. So here it is ...

C2: OMS-SUS_TOP1_INI_65536: pi radians: [-2750, -700] counts -> ~1500 urad/count
C2: OMS-SUS_TOP2_INI_65536: pi radians: [-3600, 4000] counts -> ~410 urad/count

Eric G happened to come in shortly after I had discovered this. He suggested that the mode-matching between the two beams may not be good enough. I will look into this.


I repeated this measurement with the NPRO drive current set to 1.903A as per noise measurements made by Masha before she left. The same behaviour in the fringe visibility was seen. Additionally I noticed that the SR560 for channel 2 was periodically overloading. I didn't alter the gain on this amplifier because this was the state that the system was in for Masha's measurements. Attached is the max-min counts in the presence of a 100Hz frequency difference between the VCO and LO carrier frequencies. The following estimates for the radians/count calibrations are quite rough.


CH2: OMS-SUS_TOP1_IN1_65536: pi radians: [-4500, 1000] counts -> 570 urad/count
CH2: OMS-SUS_TOP2_IN1_65536: pi radians: [-6500, 6500] counts -> 240 urad/count
Attachment 1: peak_peak_calibration_1903mA.eps
peak_peak_calibration_1903mA.eps
  84   Tue Sep 2 22:48:47 2008 DmassLaserPSLConnectors needed
I am trying to chase down the source of the long time scale sharp fluctiations in intensity. I need to start reading out the diagnostic PD from inside the MOPA head unit to see if the power fluctuations are coming before or after the amplification (e.g. NPRO or MOPA problems).

I need the following connectors from Wilson house:
Attachment 1: connectors.png
connectors.png
  83   Tue Sep 2 15:06:42 2008 AidanLaserFiberAttempted calibration of fiber noise ... issues!

I tried to calibrate the fiber phase noise measurements in DTT by determining the fringe visibility (peak-to-peak size) in counts (to determine radians per count). I shifted the carrier on the VCO by 100Hz to 200.0001MHz and left the other signal generator (LO for both mixers) at exactly 200MHz. The demodulated signals from the PDs then looked like nice 100Hz sine waves. It was only then that I noticed that the amplitude of these sine waves was varying by 50% over a timescale of 20 seconds to a number of minutes.

NPRO level: 1.500A

I plotted 20 minutes worth of Max-Min data from the 2 PDs in DataViewer (see attached pdf) - there was 100Hz frequency difference between the signal generators for all but the first four minutes or so of this plot. In principle this plot shows the fringe visibility in counts and can be used for calibration purposes. As you can see, though, the pk-pk value is fluctuating with time. Presumably, as nothing has been altered on the table over the last week, the fringe visibility has been fluctuating for all previous noise measurements. Therefore only a rough calibration is possible. So here it is ...

C2: OMS-SUS_TOP1_INI_65536: pi radians: [-2750, -700] counts -> ~1500 urad/count
C2: OMS-SUS_TOP2_INI_65536: pi radians: [-3600, 4000] counts -> ~410 urad/count

Eric G happened to come in shortly after I had discovered this. He suggested that the mode-matching between the two beams may not be good enough. I will look into this.
Attachment 1: peak_peak_calibration.pdf
peak_peak_calibration.pdf
ELOG V3.1.3-