ELOG QIL

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

Mon May 5 20:32:50 2008

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.

Tue May 6 18:18:59 2008

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

Attachment 2: MODSUM.png

Wed May 7 04:44:31 2008

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

Tue May 13 12:37:31 2008

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

Mon May 19 17:28:44 2008

Cavity Pole Measurement on the PMC

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)

Tue May 20 15:55:31 2008

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:

Attachment 1: RawTF.png

Attachment 2: corrtf.png

Thu May 29 20:00:48 2008

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.

Sun Jun 1 18:52:49 2008

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]

Fri Jul 11 16:20:21 2008

Stefan Ballmer

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.

Mon Jul 14 16:01:45 2008

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.

Wed Jul 16 11:47:18 2008

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

Thu Jul 17 16:44:27 2008

Leaving laser off while I hack at screens downstairs. Feel free to turn on for anything.

I also turned the ISS drive box off.

Fri Jul 18 16:14:28 2008

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

Attachment 2: UniPDH.png

Tue Jul 22 18:43:06 2008

fubar

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

Wed Jul 23 12:04:01 2008

Quote:

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

Attachment 2: PDH_HF.png

Fri Jul 25 14:59:24 2008

fubar

digital control broken.

Quote:

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.

Fri Jul 25 15:23:14 2008

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

Attachment 2: HEPA.png

Fri Jul 25 17:07:34 2008

Cavity Pole Measurement on the PMC

PMC

Quote:

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.

Mon Jul 28 15:58:49 2008

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.

Tue Jul 29 00:47:37 2008

As per dmass's prodding, I am putting up some pictures of what I'm doing.

Currently there is a working Mach Zehnder, but it needs to be improved.
Right now the fluctuations due to phase are about 15% of the total DC voltage,
where they were over 50% back at the 40m.On the list are more stable mounts
and better mode matching for fiber input and output with the laser. Also, we
will be putting in an AOM in the fiber arm.

Attachment 1: setup1.JPG

Attachment 2: setup3.JPG

Attachment 3: setup4.JPG

Tue Jul 29 00:58:36 2008

Masha

first fiber noise measurement

I'm attaching the fiber noise measurement from one mach zehnder channel
along with some noise sources. The total rms phase noise comes out to about
0.075 radians, which translates to a frequency noise of 20Hz rms.

I will take spectra at lower frequencies once the DAQ is back up so I don't
have to wait an hour for the spectrum analyzer.

Attachment 1: MZnoise_sources0727.png

Fri Aug 1 14:52:27 2008

Quote:

I abducted Rob from the 40m to look at this, and he thinks it has something to do with the fact that awgtpman (the test point manager) will not run. He beat at it with his kung-fu, but the computer would not yield. Ws1 does not yet know fear, but it shall soon learn.

Fri Aug 1 15:06:11 2008

I made a preliminary generic model in simulink. This is stored on ws1 as /users/dmass/atf.mdl

I copied this to /cvs/cds/advLigo/src/epics/simLink/atf.mdl on machine oms.

I changed directories to /cvs/cds/advLigo and ran the make commands. Everything seemed to run, but there was no data coming through (fb0 seemed to not start up). I then found this post in the SUS_Lab elog by Sam. I ran the commands it said to run because of the 'broken nature of the DAQ code,' and everything seemed to work.

In the end, I ran the following sequence of commands on oms in the /cvs/cds/advLigo directory, and was able to get the frontend up and receiving data. The daq, however, is still not writing anything.

*make clean-atf atf install-atf
*rm /cvs/cds/caltech/chans/daq/C2ATF.ini (this step is needed because the DAQ install code isn't quite right at the time of this writing
*make install-daq-atf
*make install-screens-atf

Tue Aug 5 15:23:38 2008

Quote:

The rm /cvs... command should be replaced by make uninstall-daq-atf. It does the removal and slightly more.

Mon Aug 11 14:15:57 2008

Quote:

I talked to Alex, and he told me something about "your frames file is full, let me empty it and call you back," and he did so.

I did a reinstall of the daq
make unistall-daq-oms
and
make install-daq-oms

then I edited the .ini files with the channel names I wanted information about in

/cvs/cds/caltech/chans/daq/
C2OMS.ini is the file with the information I want in it.
oms.ini is the file which daqconfig interfaces with.

I edited the files via the daqconfig, and then overwrote the C2OMS.ini file with it, then data seemed to be recording and I could access it via dataviewer.

One concern/piece of information:
Apparently at some point they decided to change the convention on file suffixes for channel names. C2OMS.ini has a *_32768 tacked onto the end of
the channel name upon generation by the make scripts, whereas the oms.ini file has a *_DAQ in its place. This seemed to be the cause for some
of the noncooperation between the various sytems. Daqconfig likes the *_DAQ suffix, and this seems to jive with the data now writing, so we shall
go with that.

Mon Aug 11 15:32:00 2008

Stefan Ballmer

no DAC output voltage when running OMS didgital system

I tried to use the OMS digital system for a measurement, but I couldn't get the DAC output to work.

Symptoms:
- All EPICS buttons work, and digital read-backs make sense
- ADC works just fine
- DAC output voltage is zero, no matter what the filter module output says
- Watchdog is enabled (green)

Fri Aug 15 02:17:46 2008

no DAC output voltage when running OMS didgital system

Quote:

I talked to Alex, he suggested it was a hardware problem. I then talked to Rich, who in turn suggested it was a software problem.

As far as we know, nothing has changed about the hardware configuration since it was working earlier this year.
That said, I tried several things to troubleshoot.

I borrowed the SCSI breakout board from Wilson house, and plugged it into the anti aliasing box.
I was able to drive the AA box and see the signal make it through.

I turned everything in the crate off.

Then I moved the LASTI timing box below the blue PCIX box so I could open the latter up.
I grounded myself with a static strap, and the breakout board with a wire to the chassis of the PCIX box.

I then put the breakout board directly at the output of the DAC inside the blue PCIX box. I was
careful to elevate it via rubber feet and not let the bottom touch anything.

I then turned everything back on and restarted the fe machine with:
*ssh oms
*startoms
and from ws1:
*telnet fb0 8087
*shutdown
:noteworthy errors from the above follow at the end of this entry:
This got everything up and as working as it was before I started tinkering. I sent a booming signal through the ADC into the
system and (supposedly) to the DAC at channel 1. I was not able to see any difference on the scope when looking at channel one of the DAC.

I could not do a similar test to the ADC for comparison because it was not a SCSI connector inside the box.
I was able to see my signal when I connected the breakout board to the ADC input outside the PCIX box.

I then turned everything off, undid my troubleshooting rig, and closed the PCIX box up. I restarted again, and appear
to have all former functionality, so it seems I broke nothing new in my exploration.

I now suspect that it has something to do with the following errors in the code:

when I do a startoms after ssh'ing in, I get (among other things):
epicsThreadOnce0sd epicsMutexLock failed

Also, in the log file located at /cvs/cds/caltech/target/c2oms/log.txt the last three lines read:

Triggered the ADC
Net fail to fb0
DIAG RESET

Both of these things sound ominous, so I shall point them out to either Rob or the Russian, whoever I can get my hands on first.

Fri Aug 15 15:59:07 2008

DAQ

DAC DAQ and ADC working

The problem was the timing. I changed what the simulink .mdl file wanted for a clock signal to what it was actally getting (64 kHz), and everything was magically ok.

It appears that the ADC can function at 32kHz with a 64kHz clock signal, but the DAC apparently can not.

Several PC board were removed and/or inspected before I realized that I should change this.

Mon Aug 18 23:46:42 2008

It appeared today that the DAQ channels wouldnt record. Only one would write no matter how I edited the .ini file.

I rebuilt everything, and the channels had the _32xxx suffix instead of the _DAQ suffix, and proceeded to write to the DAQ, allowing Masha to continue to slave away.

Wed Aug 20 23:19:39 2008

Preliminary Doubling MZ Setup

Doubling

A prelim expermintal setup for measuring the phase/freq noise of 532 nm light generated by PPKTP crystals relative to the 1064 nm seed light from the YAG laser.

The mirrors in the Mach-Zehnder will all be dichroically reflective. The pink mirrors on the output will be reflective in one wavelength, and transmissive in the other.

I may need to add some sort of absorption/reflection before the PPKTP crystals for the green light if it is emitted in both directions by the SHG process.

I should be able to look at the difference between the MZ output in 1064 and 532 to isolate the more interesting sources of noise (phase/frequency) from the acoustic noise.

Attachment 1: MachZenderPPKTP.PNG

Tue Sep 2 11:01:00 2008

Fiber stabilization loop diagram

Attached is a diagram of the current version of the stabilization loop. The beam (red) into the AOM is the output from the fiber and the other red line represents the reference beam.

Tue Sep 2 15:06:42 2008

Attempted 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

Tue Sep 2 22:48:47 2008

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

Tue Sep 2 23:09:38 2008

Attempted calibration of fiber noise. NPRO current = 1.903A

Quote:

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

Wed Sep 3 13:35:56 2008

Calibrated 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

Attachment 2: noise_calibrated_080902.eps

Wed Sep 3 16:43:56 2008

Aidan, Bram

Fringe visibility fluctuation ... Bram's suggestions

Quote:

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

Wed Sep 3 18:22:20 2008

Calibrated noise spectra ... does not agree with previous measurements

Quote:

Apparently the previous measurements were with a different fiber.

Fri Sep 5 03:24:37 2008

Quote:

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.

Tue Sep 9 15:49:22 2008

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.

Tue Sep 9 16:36:01 2008

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:

Tue Sep 16 22:55:30 2008

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:

Fri Sep 19 13:18:00 2008

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.

Sun Sep 21 15:45:21 2008

Quote:

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

Mon Sep 22 18:03:34 2008

DAQ IS BACK - as is the 35W

DAQ

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.

Mon Sep 22 20:20:25 2008

Fringe 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

Attachment 2: 00003.jpg

Tue Sep 23 10:15:15 2008

Fringe magnitude fluctuation investigation - why isn' the maximum 45 degrees from the minimum?

Quote:

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.

Tue Sep 23 12:10:08 2008

Maximized 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)

Wed Oct 8 13:40:02 2008

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.

100

Thu Oct 9 08:47:54 2008