Zero order beam PMC ringdown

On Wednesday I installed 3 PDs (see attached photos) measuring: 

1. The input light to the PMC. Flip-mirror was installed (sorry Shruti) on the beam path to the fiber coupler.

2. Reflected light from the PMC.

3. PMC transmitted light.

I connected the three PDs to the oscilloscope and the AOM driver to a function generator. I drive the AOM with a square wave going from 1V to 0V.

I slowly increased the square wave frequency. The PMC servo doesn't seem to care. I reach 100KHz - it seems excessive but still works. In any case, I get the same results doing a single shut-down from a DC level.

I download the traces. I normalize the traces but I don't rescale them (Attachment 4) so that the small extinction can be investigated.

I notice now that the PDs show the same extinction. It probably means I should have taken dark currents data for the PDs.

Also, I forgot to take the reflected data when the PMC is out of resonance with the laser which could have helped us determine the PMC transmission.

Again, the shutdown is not as sharp as I want. There is a noticeable smoothening in the transition around t = 0 which makes the fit to an exponential difficult. I suspect that the function generator is the limiting device now. I hooked up the function generator to the oscilloscope which showed similar distortion (didn't save the trace)

I try to fit the transmission PD trace to a double exponential and to Zucker model (Attachment 5).

The two exponentials model, being much less restrictive, gives a better fit but the best fit gives two identical time constants of 92ns.

The Zucker model gives a time constant of 88ns. Both of these results are consistent with more or less with the linewidth measurement but this measurement is still ridden with systematics which hopefully will become minimized IMC ringdowns.

Zeroth order IMC ringdown setup

Following Gautam's IMC ringdown setup, I took the REFL PD form the PMC ringdown experiment and installed it in the IMC REFL path blocking WFS2 (Attachment 1).

I also ran a BNC cable from the transmission PD that Gautam installed on the IMC table to the vertex where the signals are measured on the scope. 

I offloaded the WFS servo output values onto the MC alignment (using the WFS servo relief script) so that its dc values would be correct when the servo is off.

Unfortunately, it seems like the script severely misaligned the MC mirrors at some point when the MC got unlocked. We should fix the script such that it stops when the offloading is complete.

We got the MC realigned but left it in a state where it is not locking easily.

It's fine to block the WFS while doing ringdowns but please return the config to normal so I don't have to spend time every night recovering the interferometer before doing the locking. As I mention in that post, it is possible to do this in a non-invasive way without having to run any extra cables / permanently block any beams. If there is some issue with the data quality, then we can consider a new setup. But I see no reason to re-invent the wheel.

The IMC was also massively misaligned. I had to re-align both MC1 and MC2 to recover the lock. I took this opportunity to reset the WFS offsets. Please do not disturb the alignment of the existing optical layout unless you verify that everything is working as it should be after your changes.

And for whatever reason, ITMX was misaligned. If you do something with the interferometer, no matter how minor it seems, please leave a note on the ELOG. It will save many painful debugging hours.

As I fix these, the seismic activity has gone up . I'll wait around for an hour, but not an encouraging restart to the locking 😢 

A recap of the ringdown measurements made at the 40m in mid 2012, the hardware that was installed for the same and results from the measurements.

IMC ringdown:

Hardware installed 
A trans PD was installed (elog 7122).
This PD does not exist in the trans path anymore.

Measurements
The polarity in the MC servo was flipped with the MC WFS disabled and the PD trans signal was used to look at the cavity ringdown. 
Ringdown time = 13 us
Cavity finesse from the measurement = 453 (inconsistent with actual finesse). 

Attachment: Ringdown measurement and fits

PMC ringdown:

Hardware installed
The AOM was installed before the PMC. The AOM was driven by the driver installed on the PSL table. (RF power ~1.5W @ 80MHz @1.0V modulation input). An RF switch was installed to control the AOM driver input. ZASWA-2-50DR+ was installed.
Note: The AOM was used by the ISS crew after this. So the RF switch has been removed and the AOM is no more a part of the ringdown setup.

Measurements
No measurements were made as we could not obtain relevant TTL signals to control the switch remotely.

To do this better:

1) Just step the analog input to the AOM (i.e. no RF switch) and measure the PMC trans output with a fast DC coupled PD. IMC should be unlocked and disable during this part. We want the PMC ringdown to be faster than 1 us.

2) Re-install a fast PD in the MC trans path without disrupting the existing MC trans QPD setup.

3) Measure IMC ringdown and fit the data to find the cavity losses.

4) Think about how to use the Isogai, et. al (2013) technique to better measure the losses, taking into account the mirror transmissions.

 [Jenne, EricQ, Nic, MattA]

* TT1 is in place, aligned so beam hits center of TT1, hits center of MMT1 (used pitch biases to finish pitch).

      * Riser installed, dogged down with 1 dog.

      * TT1 sitting on top of riser, 3 dogs holding TT to table, with riser squished in between.

* IOO table leveled.

      * Almost all of the weights on the IOO table were just sitting there, not screwed down!  One didn't even have a screw, 3 had screws, but they were totally loose.  2 of those screws were in as far as they could go, but they weren't holding the weight.  This means the screw was too long, and should have been replaced (which I did today).  Just because the existing screw was too long, doesn't mean it should be left as-is.  Everything in the chambers must be tightly clamped down, as soon as work on that item is complete!  Anyhow, after finalizing the leveling, I tightened down all of the weights on the IOO table.

* MMT1 tweaked so beam hits center of MMT2. 

* MMT2 tweaked so beam hits center of PZT2.

* Light access connector installed.

Sadface notes:

* I dropped a Class B golden-colored 3/16 allen key to the bottom of the IOO chamber.  I can't see it, but Nic thinks he might be able to see it with a mirror, from the BS chamber.  We should look for it when we look for the IR card that is still down there.

* We have an ant in the IOO chamber.  Unfortunately my hands were on the TT1 optic holder ring when I saw it, so I couldn't dash quickly enough to grab it.  I saw it run over the side of the table, and down, but looked under the table and couldn't find him.  Not so good, but I don't know what to do about it right now.  If anyone sees it, get it out please.

[Jenne, with backup from Koji and Steve]

Short version:

TT1 was installed without a riser, optic is too low, riser we have doesn't fit, cannot proceed with alignment.  Sadface.

Long version:

I had gotten to the point of checking that the beam coming out of the Faraday was hitting the center of TT1, when I realized that we had forgotten to install the risers.  The TTs are designed for 4" beam height, but we have a beam height of 5.5" in-vac.  This means that the beam out of the Faraday was hitting the top of the optic / the optic holder.

Steve showed me where all of the active TT equipment is stored (down the X arm, almost all the way to the flow bench...there is a plastic tub full of baked items (individually wrapped and bagged)), and I got one of the 1.5" risers.

Upon opening the riser package, and comparing it with the base plate of the active tip tilt, the screw holes don't match!

It looks like for the passive tip tilts, we had holes machined at the far corners of the base plate, then had these risers made.  You can see in the photo of SR3 below that the original holes are there, but we are using 1/4-20 holes at the far corners of the base plate.

Unfortunately, without checking the base plate, I had asked Steve to get 4 more of the same risers we used for the passive tip tilts.  So, now the base plate holes and the riser holes don't match up.  In a perfect world, we would have installed the risers on the TTs as soon as they were baked and ready, and would have discovered this a while ago....but we don't live in that world.

 The reason we had originally chosen to put the new 1/4-20 holes on the corners of the passive tip tilts was so that when we tightened the screws, we wouldn't bend the base plate, due to the groove at the bottom of the base plate being directly under the screws.  Since the new aLIGO TT base plates have the groove underneath going the opposite direction, we didn't need to move the holes to the corners.

Also, you can't really see this from the photos, but the active TT base plate is slightly longer (in the beamline direction) than the riser, but only by a little bit.  Koji is currently trying to measure by how much from the CAD drawings.

Also, also, because of the way TT1 will hang off the table, I'm concerned about the underneath groove on the riser being the direction it is.  I'm concerned that the grooved part will be what wants to touch down on the back corner of the table, such that either the TT is insufficiently supported, or it is tilting backwards.  Neither of these will be acceptable.

I propose that we re-make the risers quickly.  We will have the holes match the active TT base plate, the size of the riser should match the size of the active TT base plate, and the underneath groove should be perpendicular to the way it is in the current version.

Koji and I were looking for an extender card to aid with MZ board testing.  Rob went off on a quest to find one.  He found 2 (in addition to the one in the drawer near the electronics bench which says "15V shorted"), and put them in some empty slots in 1X1 to test them out.  Somehow, this burned a few pins on each board (1 pin on one of them, and 3 pins on the other). We now have 0 functioning extender cards: unfortunately, both extender cards now need fixing.  The 2 slots that were used in 1X1 now have yellow electrical tape covering the connectors so that they do not get used, because the ends of the burnt-off pins may still be in there. 

In other, not-Rob's-fault news, the Martian network is down...we're going to try to reset it so that we have use of the laptops again.

This happened when I plugged the cards into a crate with computers, which apparently is a no-no.  The extender cards only go in VME crates full of in-house, LIGO-designed electronics.

We are celebrating Rob's promotion to thesis poetry.  These pictures were taken on December 9, 2009

Rob has finished all his measurements in the lab and is officially well prepared to graduate.

I assume it's the rock tumbler, although it could be something else, but the MC has had trouble staying locked yesterday and today (yesterday Yaakov and I went over there and they were doing stuff almost constantly - it's super loud over there), and today even the PMC has fallen out of lock twice.  I just relocked it again, since it went out of lock just after Journal club started.

Anyhow, I think this will be good data for Masha, and then also for the Masha+Yaakov triangulation project.

I think the "Rogue Master" setting on the RFM network may be doing some good. 5 mins, ago, all the CDS indicators were green, but I noticed an amber light on the c1rfm screen just now (amber = warning). Seems like at GPS time 1294691182, there was some kind of error on the RFM network. But the network hasn't gone down. I can clear the amber flag by running the global diag reset. Nevertheless, the upgrade of all RT systems to Dolphin should not be de-prioritized I think.

 Roscolux filter films  #74 night blue,  0.003" thick  and  #26 light red, 0.002" thick  were measured in the beam path of  ~6 mm diameter,  1W 1064 nm .

T 90%  + - 5% at 0-30 degrees of  incident angles and R ~10 % 

These sandwitched thin films of policarbonate-polyester filters are not available in thicker forms. Rosco is recommending them to be cooled by air if used in high power beam.

These filters did not get warm at all in 1W, so absorption must be very small.

When I came in, Rossa was booted to Ubuntu 10. I tried rebooting to select 12, but couldn't ever successfully boot again. Since Diego was setting up Allegra from scratch, I've wiped and done the same with Rossa. 

Allegra and Rossa wiped and updated to Ubuntu 12.04.5 by me and Ericq; the following procedure was followed:

1) create "controls" user with uid=1001, gid=1001
2) setup network configuration (IP, Mask, Gateway, DNS), .bashrc, /etc/resolv.conf
3) add synaptic package manager (Ubuntu Software Center used by default)
4) add package nfs-common (and possibly libnfs1) to mount nfs volumes; mount nfs volume adding the line "chiara:/home/cds/       /cvs/cds/       nfs     rw,bg   0    0" in /etc/fstab
5) add package firmware-linux-nonfree, needed for graphics hardware recognition (ATI Radeon HD 2400 Pro): due to kernel and xorg-server versions of 12.04.5, and because ATI dropped support for legacy cards in their proprietary driver fglrx the only solution is to keep Gallium drivers
6) add packages libmotif3 grace, needed by dataviewer
7) add repository from https://www.lsc-group.phys.uwm.edu/daswg/download/repositories.html (Debian Squeeze); install lcssoft-archive-keyring as first package or apt-get will complain
8) add package lscsoft-metaio libjpeg62, needed by diaggui/awggui (Ericq: used lalmetaio on rossa)
9) add packages python-numpy python-matplotlib python-scipy ipython
10) change ownership of /opt/ to controls:controls
11) add csh package
12) add t1-xfree86-nonfree ttf-xfree86-nonfree xfonts-75dpi xfonts-100dpi, needed by diaggui/awggui (needs reboot)
13) add openssh-server

Ubuntu creates the first user during installation with uid=1000 and gid=1000; if needed, they could be changed afterwards using a second user account and the following procedure (twice, if the second users gets the 1001 uid and gid):

sudo usermod -u <NEWUID> <LOGIN>   
sudo groupmod -g <NEWGID> <GROUP>
sudo find /home/ -user <OLDUID> -exec chown -h <NEWUID> {} \;
sudo find /home/ -group <OLDGID> -exec chgrp -h <NEWGID> {} \;
sudo usermod -g <NEWGID> <LOGIN>

I am getting tired of having to restart Rossa all the time.  She freezes almost once per day now.  Jamie has looked at it with me in the past, and we (a) don't know why exactly it's happening and (b) have determined that we can't un-freeze it by ssh-ing from another machine.

I wonder if it's because I start to have too many different windows open?  Even if that's the cause, that's stupid, and we shouldn't have to deal with it.

\end{vent}

[Jenne, Rana]

Today, Rossa has been hanging at bootup.  You get the desktop, and most of the gui things, and can move the mouse pointer around, but clicking the mouse or using the keyboard have no effect.  Once you try clicking something, the mouse pointer turns into the spinning ball, and stays like that.

If, upon rebooting (soft rebooting from another machine, through an ssh session), you hold down the Shift key, you should get to a Grub menu.  If you arrow-key down and select the next-most-recent version (not the recovery mode, but just the regular earlier version), and press Enter, Rossa starts up nice and happily.

I am not sure how to make Rossa always boot into this version of things, or how to get rid of the newest version so that the version that works is the most recent, but I'm hoping one of my Linux buddies will help me out on this one.  I think (maybe) that I need to find out what package was recently updated and could have caused problems, and then revert that one package.  (I think I can look at tail /var/log/apt/history.log to tell me what has recently been updated).

I have modified the /etc/default/grub file, so that we're loading up the previous linux kernel version on reboot.  Now Rossa boots up (at least one time so far) without any fancy button-pushing.

(Note, if things go south again, we have to push "shift" starting after the Dell screen is gone.  Holding it down while the Dell screen is still up doesn't seem to make it register that you want the grub menu).

The grub file USED to look like:

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

but now it looks like:

GRUB_DEFAULT=2
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Note that the first line, GRUB_DEFAULT has changed from 0 (first item in grub menu, if you successfully hit shift and get to it) to 2 (the third item in the list).  I think that the GRUB_HIDDEN_TIMEOUT_QUIET=false is supposed to force it to show the countdown time when you can push shift, but I didn't see any difference there.

To edit this file, you must use "sudo [text editor] grub".  I like emacs, so I used "sudo emacs grub".  After an edit, before a reboot, you must run "sudo update-grub".  Then you can reboot (sudo shutdown -r now is what I use), and hopefully it will boot as you directed.

Right now, the 0th (first) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic".  The 2nd (third) entry is "Ubuntu, with Linux 2.6.32-58-generic".  If we install a new kernel version, the 61 version will bump down in the list, and we'll be booting that, which I assume will fail.  We should not update Rossa until we're ready to go to Ubuntu 12, and when we do, we must ensure that the grub file first line reads GRUB_DEFAULT=0.  (As a side note, the 1st (really 2nd) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic (recovery mode)", which we don't want.  The 58 version has a recovery mode as the next line item, since it alternates version-N, version-N recovery mode, version-(N-1), version-(N-1) recovery mode, etc.)

I think I found out why rossa was mad. 

An apt-get update on the 18th downloaded kernel 2.6.32-65-generic, so 2.6.32-58-generic, which what was previously chosen as a working kernel, had moved down in the grub ordering.

It turns out the grub configuration accepts strings, so I changed it to GRUB_DEFAULT="Ubuntu, with Linux 2.6.32-58-generic", ran sudo update-grub, and Rossa now seems to boot happily. 

Aligning the beam for the PLL of the AbsL Experiement I rotated the polarizer along the path of the MC Input pick off beam (= the pick off coming from the MC periscope).

POXDC (i.e. POY DCout)
PRM misaligned: 70cnt
CA resonant PRMI: ~8000cnt (max)

REFLDC
PRMI antiresonant = 5200cnt
PRMI resonant = ~3000cnt
==> Visivility = 0.6

PRM
Transmissivity: T_R=0.0575, t_R=sqrt(T_R)

Rough estimation of the power recycling gain (assuming perfect mode matching)

P_{PRM_mialign} = P_in t_R²
P_{PRM_resonant} = P_in [t_R/(1-r_R r_MI)]²

G = t_R² P_{PRM_resonant} / P_{PRM_mialign} = 8000/70*0.0575 = 6.5

This is way too low compared with the design (G>40)
This corresponds to r_MI²=0.885 (loss of 10%) in the power recycling cavity.
But this yields visibility of 16%, instead of 60% which we saw. This is inconsistent.

If mode matching is not perfect, effective incident power of PRMI decreases
and this discrepancy may be explained

P_in = P_junk + (P_in-P_junk)

P_{PRM_mialign} = P_in t_R²
P_{PRM_resonant} = (P_in-P_junk) [t_R/(1-r_R r_MI)]²

P_{REFL_antires} ~ P_in
P_{REFL_resonant} = P_junk+(P_in-P_junk)[-r_R+(t_R² r_MI)/(1-r_R r_MI)]²

^===>

P_{PRM_resonant} / P_{PRM_mialign} = (1-R_mm) /(1-r_R r_MI)²=8000/70
P_{REFL_resonant} /P_{REFL_antires}= R_mm+(1-R_mm)[-r_R+(t_R² r_MI)/(1-r_R r_MI)]²=0.6

here R_mm= P_junk/P_in is the mode matching ratio

Solving the last two equations, we obtain

R_mm=0.6,
r_MI²= 0.939 (loss of 4-5%)

Can we believe that the mode matching is 60% and the loss is 5%???

PR1, PR2 and RP3 turned on for warming up for oil change. Oil changed with 3.2L of  MVT-19 fluid in each. This substitute for HE-175 will be used at the next oil change - it has 1E-6 Torr vapor pressure.

To finish this job tomorrow: 1, check oil creeping upstream  2, change air filter of air purge if pressure drops <350 mTorr  3, measure venting time of pump

 . Leybold D30A manual is here. Exhaust filter traps were drained. No oil creeping was found. The pump venting time is < 1 minute.

PR-2 needs new secu-valve. PR1 & 2 are in excellent condition.

1. Suresh and I completed the alignment of the fibre and the three mirrors on the ETMY table.

2. We managed to get an output beam power of around 60% using the Ophir(Orion/PD) power meter to finetune the alignment. The power of the input beam is 74.4 mW and of the output beam is 38.5 mW.

3. The coupler on the output side of the fibre which had been put there to help in the alignment has been removed.

4. The picture of the ETMY layout as of now has been attached.

5. The labels A stands for the mirror used to turn the beam direction and B and C stand for the three mirrors used in the alignment of the beam into the coupler,D.(attachment 3).

6. The fibre we used is 50m in length which was barely sufficient to reach the PSL table.

7. So, the fibre has been routed to the PSL table using the fibre tray running below the Y-arm tube as this was the shortest route possible(even though it is a rather acccident prone zone).

8. The fibre has been tied down at regular intervals so that it does not get snagged and pulled up inadvertently.

9. We will start with the preparation of the layout of the PSL table to superpose the two beams on Monday.

I took some measurements of the clock this morning, first without the box, then with the box, then without the box again. All the noise levels look pretty much the same. When I first put the box on, it was only propped up on one side, so I think the clocks got a bit overheated and the data looks ridiculous, which is the first plot. I took it off and let them cool down a bit, and then put the box on, this time with a generous 3 inch gap at the bottom all the way around, and it seemed to be fine after that.

The calibration for the data is pi (rad) /6415 (counts) /100.

Aidan: I edited this post to change the plots from Postscripts to PDFs.

We unsynched the clocks by unhooking the 1pps locking. I've added it to the plot of the other measurements here, and we've divided by a factor of sqrt(2) in the calibration to get the phase noise from just one clock, so the calibration is now

pi (rad) /6415 (counts) /100/sqrt(2).

I've also added the noise of the clock according to SRS to the plot.

The units of this plot are rad/rt(Hz). I've no idea why it just says magnitude.

 This is a known thing (at least to me and Rana), so it's not just you.  When you put in some points like your PD Spec, the units disappear, and I've never figured out how to get them back while keeping the points.  Thanks for putting the units in your entry though.  If anyone else does know how to get the units to 'stick' where they're supposed to be, that would be helpful. 

 Here's an overview of the rubidium measurement:

 We have two SRS FS275 Rubidium clocks which are locked together using the built-in PLL through the 1pps input/output. The default time constant for this locking is 18.2 hours because it's designed to be locked to a GPS. We changed this time constant to .57 hours (as decribed in this elog entry) to get the clocks to more reliably lock to each other. We then mix the 10MHz outputs together using a 7dbm mixer (see elog here and picture below)

The signal then goes through an AC-coupled SR560 with a gain of 100 and LPF at 10kHz, and is then fed into the DAQ. In the first picture below you can make out what all the lights are labeled, and in the second you can see what lights are on. I couldn't get a picture that did both in one, sadly.

[Jenna & Alastair]

We changed the locking time constant on one of the Rubidium clocks using the RbMon software that came with it. We had to use the ancient Dell laptop latitudeD810 because it has a serial port built in, and we couldn't get the usb->serial adapter to work right with the clock. We tried the usb connector on more than one computer, and we had installed the right adapter and the computer seemed to recognize it fine, it just wouldn't communicate with the clock. We even tried it with the Dell latitute laptop and it still failed to work, so the only way seems to be to use the serial port directly.

The clock has a default time constant of 18.2 hours because it's designed to be locked to a GPS clock which is less stable than the Rb clock itself, so we changed it to a time constant of .57 hours. We also changed the length of the BNC cables to get the DC offset to 10mV, but then as I was typing this, we opened up data viewer to look at the real time data and saw the output suddenly leap up, and found that the offset is now -5mV mysteriously, so we went to investigate and found that the gain of the SR560 was still set to 1 from a calibration. We beat one of the clocks with a marconi for a few minutes with the gain still at this level to do another calibration, and then hooked the clocks back up together and upped the gain to 100. The DC offset is currently about 2.5mV. We're going to leave them alone for a few hours, and then check to see what the signal looks like over that period.

Alastair found that the foam hut that he and Jan put on top of the Rb clocks to temperature stabilize them was too good of an insulator. The Rb boxes had gotten very hot and became internally unlocked as seen on the front panel.

After we let them cool down with the box off, I turned them back on. After several minutes the 'Locked' light came back on. Some minutes after that the '1PPS Sync' light also came on, indicating that the two had become somewhat synchronized. It really means that the frequencies are kind of close: I think its roughly that f1-f2 < 2 mHz.

I put the yellow box back on and have left it with a small gap on the bottom so that the hot air can get out. Hopefully, this will protect the clocks from the wind, but not cause them to overheat.

The signal going to the DAQ right now is DC-coupled, with a gain of 1. The peak-peak beat signal in this situation is 6300 counts.

My guess is that the clocks will by synchronized by tomorrow afternoon so that we can get the measurement done. Please don't disturb the clocks or the yellow box around them. Try to minimize any activity around that area.

The ruby wire standoff V groove cuts are looking good.

I will request free sample of  sapphire prizm where one side would have SOS's R cylindrical surface.

The present plan to have the v-groove on this prism.

Two companies are willing to  make the ruby grooves and the third one is still working on their quote.

The price is ~$100 each. The cost goes down 10% if we  order 50 instead of 30 pieces.

How many should we get ?

[Steve, Manasa]

We ran power cables and sma cables for the FOL fiber module from the PSL table to the IOO rack.

Overall Design

A schematic of the overall subsystem diagran in attachment.

RF and Optical Connections

Starting at the top left corner is the diode laser module.  This laser has an input which allows it to be amplitude modulated.  The output of the laser is coupled into an optical fiber which is connectorized with an FC/APC connector and is connected to the input port of a 1 by 16 Optical Fiber Splitter. The Splitter produces 16 optical fiber outputs dividing the input laser power into 16 roughly equal optical optical fiber outputs.  These optical fibers are routed to the Photodiode Receivers (PD) which are the devices under test. All of the PDs are illuminated simultaneously with amplitude modulated light. The Optical Fiber outputs each have a collimating fiber telescope which is used to focus the light onto the PDs. Optical Fiber CH1 is routed to a broadband flat response reference photodiode which is used to provide a reference to the HP-4395A Network Analyzer.  The other Channel outputs are connected to an RF switch which can be programmed to select one of 16 inputs as the output.  The selected outputs can then be sent into channel A of the RF Network Analyzer. 

RF Switch

The RF switch consists of two 8 by 1 Multiplexers (National Instruments PXI-254x) slotted into a PXI Chassis (National Instruments PXI-1033).  The Multiplexers have 8 RF inputs and one RF output and can be programmed through the PXI Chassis to select one and only one of the 8 inputs to be routed to the RF output.) The first 8 Channels are connected to the first 8 inputs of the first Multiplexer.  The first Multiplexer’s output is then connected to the Channel 1 input of the second Multiplexer. The remaining PD outputs are connected to the remaining inputs of the second Multiplexer. The output of the second Multiplexer is connected to the A channel of the RF Network Analyzer.  Thus it is possible to select any one of the PD RF outputs for analysis.

Software

Something on this tomorrow.

I've taken over one of the SENSMAT oscillators for a test of the EPICS system.

These are the channels I've modified, with their original and current settings:

controls@donatella|~ > caget C1:LSC-OUTPUT_MTRX_7_13 C1:CAL-SENSMAT_CARM_OSC_FREQ C1:CAL-SENSMAT_CARM_OSC_CLKGAIN
C1:LSC-OUTPUT_MTRX_7_13          -1
C1:CAL-SENSMAT_CARM_OSC_FREQ    309.21
C1:CAL-SENSMAT_CARM_OSC_CLKGAIN   0
controls@donatella|~ > caget C1:LSC-OUTPUT_MTRX_7_13 C1:CAL-SENSMAT_CARM_OSC_FREQ C1:CAL-SENSMAT_CARM_OSC_CLKGAIN
C1:LSC-OUTPUT_MTRX_7_13           0
C1:CAL-SENSMAT_CARM_OSC_FREQ      0.1
C1:CAL-SENSMAT_CARM_OSC_CLKGAIN   3
controls@donatella|~ >

 I put some optics to get the green SHG on the PSL table.

Now a green light successfully comes out from the doubling crystal.

Since the optical layout of the PSL table was dramatically changed, I had to re-setup the green SHG stuff. 

 - what I did

I put a steering mirror after the 90/10% pick off mirror, and then a half wave plate and a convex lens.

The lens is approximately on the right place.

 To get the green beam easily, temporarily I raised the current of the NPRO up to 2 A.

I connected the oven to the heat controller, set the temperature to 36.8 deg which is the set point previously used.

After putting and aligning the oven, I finally obtained the green beam.

At the end of the work I set the NPRO current back to 0.9 A and relocked the PMC.

- things to be done

 1. more precise mode matching

 2. optimization of the temperature 

In order to increase the green power on the PSL table, I moved the position of the Second Harmonic Generation (SHG) crystal by ~5cm.

After this modification, the green power increased from 200 uW to 640 uW. This is sufficiently good.

     As I said in the past elog entry (# 3122), the power of the green beam generated at the PSL table should be about 650 uW.

I measured the green power by the Ophir power meter and found it was ~200 uW, which made me a little bit sad.

Then I performed the beam scan measurement to confirm if the crystal  was  located on the right place. And I found the postion was off from the optimum position by ~5cm.

So I slided the postion of the SHG oven to the right place and eventually the power got increased to 640 uW.

some notes: 

(power measurement)

        The outgoing beam from the SHG crystal is filtered by Y1-45S to eliminate 1064nm.

According to Mott's measurement Y1 mirrors are almost transparent for green beams (T~90%), but highly reflective for 1064nm (T~0.5%).

All the green power were measured after the Y1 mirror by the Ophir configured to 532nm, though, the measured power might be offseted by a leakage of 1064nm from the Y1 mirror.

I didn't take this effect into account.

(beam scanning and positioning of crystal)

          Here is the properties of the incident beam. These numbers are derived from the beam scan measurement.

w0h             = 52.6657      +/- 0.3445 um

w0v             = 52.4798      +/- 0.1289  um

z0h             = 0.574683         +/- 0.001937 m

z0v             = 0.574325         +/- 0.0007267 m

Where the suffixes "h" and "v" stand for "horizontal" and "vertical" respectively.

The distances are calibrated such that it starts from the lens postion.

Both waist size are already sufficiently good because the optimum conversion can be achieved when the waist size is about 50um ( see this entry)

The measured data and their fitting results are shown in attachement 1.

         According to my past calculation the center of the crystal should be apart from the beam waist by 6.8mm (see this entry). 

So at first I put the oven exactly on the waist postion, and then I slided it by 6.8mm.

(to be done)

        I need to find an optimum temperature for the crystal in order to maximize the green power.

Previously the optimum temperature for the crystal was 38.4 deg. But after moving the position I found the optimum temperature is shifted down to around 37deg.

The optimum temperature for the doubling crystal on the PSL table was found to be 36.8 deg.

I scanned the temperature of the crystal from 44 deg to 29 deg, in order to find the optimum temperature where the frequency doubled power is maximized. 

(method) 

The method I performed is essentially the same as that Koji did before (see this entry).

(1) First of all, I enabled the PID control on the temperature controller TC200 and set the temperature to 44 deg.

(2) After it got 44 deg, I disabled the PID control.

(3) Due to the passive cooling of the oven, the temperature gradually and slowly decreased. So it automatically scans the temperature down to the room temperature.

(4) I recorded the power readout of the power meter: New Port 840 together with the temperature readout of TC200. The power meter was surely configured for 532 nm.

(result)

The measured data are shown in the attachment. 

The peak was found at T=36.8 deg where the power readout of  532 nm was 605 uW.

Compared with Koji's past data (see this entry), there are no big side lobes in this data. I am not sure about the reason, but the side lobes are not critical for our operation of the green locking.

 (to be done)

 Adjustment of the PID parameters

 It seems like you might inherit an offset by using step (3) b/c of the temperature gradient between the crystal and the sensing point. Depending on how large this gradient is you could increase the linear coupling from temperature to intensity noise from zero to a significant number. Phase noise should not be effected.

SInce these things (ovens) are so low time constant, shouldn't we

1. Lock to a temperature
2. Let the oven equilibrate for however long - a few tau maybe - my oven has a time constant of 60 sec, don't know if this is fast or slow compared to that
3. Measure P_532/P_1064
4. Change the setpoint
5. Go back to step 1

Plugging in the thermal feedback BNC cable to the laser reduced the DC voltage of the green PDH photo diode from 3.12 V to 1.5V off resonance.

The power emitted by the laser was the same as in the case without that cable. Note LT, i.e. measured crystal temperature, of the laser show a

different value when the BNC is connected, but the manual clearly states that this display does not work properly if a cable is connected to the

slow BNC plug, an offset is added.

The power of the 532nm light behind the SHG oven has been reduced from 1mW to 0.4mW. I changed the crystal temperature such that the power

of the green light is 1mW. With this new temperature setting the laser can be locked again.

Changing the crystal temperature changes the laser frequency. This will causes the beat note missing at the vertex.

In other words, you will find the beat note at the vertex when the actual temperature of the crystal is reproduced as before,
no matter how the dial setting/temp voltage input is.

I must confess that I changed the temperature of the laser via the dial yesterday. I believe the initial (displayed) temperature was ~19^o, whereas it is now probably in the high 20s. Sorry.

Okay, my elog entry was not clear I changed the temperature of the SHG which only changes the conversion efficiency. 

Anyhow, since the laser set temperature and thus the laser frequency has been changed by Zach and I couldn't find a note

of the original laser crystal temperature, my plan is to reset the SHG temperature to the old value, set the laser crystal temperature

around 19°C and do fine adjustment of that temperature by optimising the doubling efficiency. Okay?

Last night we finally got some online subtraction going. The filter used is described in the post this eLOG is @eLOG 11488. 

The results were as follow:

The filter worked as expected when subtracting noise out of MCL,

There is about a factor of 6 subtraction at the ~3Hz resonant peak. The static IIR filter predicted a factor of 6-7 subtraction of this peak as well.

The 1.2 Hz resenonant feature improved by a factor of 3. This should improve quite drastically when I implement the y-channel of the T240 seismo.

There is some high frequency noise being injected, not very noticeable, but present. 

We then took a look at the power in the MC when the filter was on,

The power being transmitted in the cavity was not as stable as with the feedforward on. We believe that the filter is not at fault for this as Eric mentioned to me that the MC2 actuator lacked some sort of compensation that I need to understand a bit better.

YARM was then locked when the filter was on and we took a look at how it was doing. There was stationary sound arising from the locking of the YARM, leading us to believe that the filter might have injected some noise in the signal. IT DID.

The filter injected nasty high frequency noise at YARM from 11 Hz and on. This is to be expected since the filter did not roll off to zero at high frequencies. Implementing a 1/f rolloff should mitigate some of the injected noise.

 Also, as one can see above, subtraction by around a factor of 2 or so, was induced by the mode cleaner feedforward subtraction.

For the future SLOW controls our current plan is to keep using the VME based stuff and associated processors (Baja, Motorola, etc.). This is not

a sustainable plan since these are obsolete and eventually will die. One option is to use these boxes from Diamond Systems:

http://www.diamondsystems.com/products/octavio

 All of the SLOW computers were in limbo since the fileserver/nameserver change, but me and Zach brought them back.

One of the troubles, was that we were unable to telnet into these computers once they failed to boot (due to not having a connection to their bootserver).

1. Needed special DB9-RJ45 cable to connect from (old) laptop serial ports to the Motorola VME162 machines (e.g. c1psl, c1iool0, c1aux, etc.); thanks to Dave Barker for sending me the details on how to make these. Tara found 2 of these that Frank or PeterK had left there and saved us a huge hassle. Most new laptops don't have a serial port, but in principle there's a way to do this by using one of our USB-Serial adapters. We didn't try this, but just used an old laptop. The RJ45 connector must go into the top connector of the bottom 4; its labeled as 'console' on some of the VME computers. Thanks to K. Thorne for this very helpful hint and to Rolf for pointing me to KT.
2. Installed 'minicom' on these machnes to allow communication via the serial port.
3. Had to install RSH on chiara to allow the VME computers to connect to it. Also added the names of all the slow machines in /etc/hosts.equiv to allow for password-less login. Without this they were not able to load the vxWorks binary. It was tricky to get RSH to work, since its an insecure and deprecated service. 'rsh-server' doesn't work, but installing 'rsh-redone-server' did finally work for passwordless access. Must be that linux1 has RSH enabled, but of course, this was undocumented.
4. Some of the SLOW machines didn't have their own target names or startup.cmd in their startup boot parameters (???). I fixed these.
5. For C1VAC1, I have updated the boot parameters via bootChange, but I have not rebooted it. Waiting to do so when Koji and Steve are both around. We should make sure to not forget doing this on C1VAC2. Steve always tells us that it never works, but actually it does. It just crashes every so often.
6. Leaving C1AUXEX and C1AUXEY for Q and Jacy to do, to see if this ELOG is good enough.
7. The PSL crate still starts up with a SysFail light turned on red, but that doesn't seem to bother the c1psl operation. We (Steve) should go around and put a label on all the crates where SysFail is lit during 'normal' operation. Misleading warning lights are a bad thing.

We still don't have control completely of the MC Servo board, so we need the morning crew to start checking that out

An example session (using telnet, not the laptop/serial way) where we use bootChange to examine the correct c1aux config:

controls@pianosa|target> telnet c1aux
Trying 192.168.113.61...
Connected to c1aux.martian.
Escape character is '^]'.

c1aux > bootChange

'.' = clear field;  '-' = go to previous field;  ^D = quit

boot device          : ei
processor number     : 0
host name            : chiara
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks
inet on ethernet (e) : 192.168.113.61:ffffff00
inet on backplane (b):
host inet (h)        : 192.168.113.104
gateway inet (g)     :
user (u)             : controls
ftp password (pw) (blank = use rsh):
flags (f)            : 0x0
target name (tn)     : c1aux
startup script (s)   : /cvs/cds/caltech/target/c1aux/startup.cmd
other (o)            :

value = 0 = 0x0
c1aux >

 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.  (Edit, JCD, 9July2014:  Startup a terminal session, and then type "minicom" and press enter to get a Minicom session).

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot".  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.