40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 207 of 330 Not logged in
ID Date Author Type Category Subject
6237   Mon Jan 30 16:18:51 2012 steveUpdatePEMRoscolux colored film transmittance at 1064 nm

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.

10605   Tue Oct 14 17:38:31 2014 ericqUpdateComputer Scripts / ProgramsRossa and Allegra wiped, Ubuntu 12.04 installed

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.

10606   Tue Oct 14 23:44:42 2014 diegoUpdateComputer Scripts / ProgramsRossa and Allegra wiped, Ubuntu 12.04 installed

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
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
12) add t1-xfree86-nonfree ttf-xfree86-nonfree xfonts-75dpi xfonts-100dpi, needed by diaggui/awggui (needs reboot)

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 groupmod -g <NEWGID> <GROUP>
sudo find /home/ -user <OLDUID> -exec chown -h <NEWUID> {} \;
sudo find /home/ -group <OLDGID> -exec chgrp -h <NEWGID> {} \;

8643   Fri May 24 14:44:34 2013 JenneUpdateGeneralRossa freezes all the time

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}

10045   Mon Jun 16 21:22:16 2014 JenneUpdateComputer Scripts / ProgramsRossa having a bad day

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

10063   Wed Jun 18 19:30:28 2014 JenneUpdateComputer Scripts / ProgramsRossa having a better day

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

10540   Thu Sep 25 15:41:15 2014 ericqUpdateComputer Scripts / ProgramsRossa having a better day

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.

2229   Tue Nov 10 19:19:57 2009 AlbertoUpdateABSLRotated polarizer on the PSL table, along the MC input pick off beam

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

5541   Sat Sep 24 20:14:36 2011 KojiUpdateLSCRough estimation of the PR gain

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: TR=0.0575, tR=sqrt(TR)

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

PPRM_mialign = Pin tR2
PPRM_resonant = Pin [tR/(1-rR rMI)]2

G = tR2 PPRM_resonant / PPRM_mialign = 8000/70*0.0575 = 6.5

This is way too low compared with the design (G>40)
This corresponds to rMI2=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

Pin = Pjunk + (Pin-Pjunk)

PPRM_mialign = Pin tR2
PPRM_resonant = (Pin-Pjunk) [tR/(1-rR rMI)]2

PREFL_antires ~ Pin
PREFL_resonant = Pjunk+(Pin-Pjunk)[-rR+(tR2 rMI)/(1-rR rMI)]2

===>

PPRM_resonant / PPRM_mialign = (1-Rmm) /(1-rR rMI)2=8000/70
PREFL_resonant /PREFL_antires= Rmm+(1-Rmm)[-rR+(tR2 rMI)/(1-rR rMI)]2=0.6

here Rmm= Pjunk/Pin is the mode matching ratio

Solving the last two equations, we obtain

Rmm=0.6,
rMI2= 0.939 (loss of 4-5%)

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

7564   Wed Oct 17 08:04:31 2012 SteveUpdateVACRoughing pumps on for oil change

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

7597   Tue Oct 23 16:18:03 2012 SteveUpdateVACRoughing pumps on for oil change

 Leybold D30AQuote: 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 next time. 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.

Attachment 1: oilchange.jpg
4901   Tue Jun 28 16:52:37 2011 SonaliUpdateGreen LockingRouting of fibre to PSL complete.

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.

Attachment 1: coupled_fibre.jpg
Attachment 2: the_fibre_route.jpg
Attachment 3: ETMY_aftr_fibre_coupling2.png
3398   Wed Aug 11 12:58:56 2010 JennaUpdateElectronicsRubidium clock phase noise

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.

Attachment 1: 08_11_Rb_crazybox.pdf
Attachment 2: 08_11_Rb_comparison.pdf
3400   Wed Aug 11 15:27:16 2010 JennaUpdateElectronicsRubidium clock phase noise

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

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.

Attachment 1: 08_11_Rb_withspec.pdf
3402   Wed Aug 11 16:38:02 2010 JennaUpdateElectronicsRubidium clock phase noise

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

3423   Fri Aug 13 20:58:20 2010 JennaSummaryElectronicsRubidium clock phase noise measurement

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.

3392   Tue Aug 10 15:23:35 2010 JennaUpdateElectronicsRubidium clock time constant

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

3361   Wed Aug 4 19:50:58 2010 ranaConfigurationElectronicsRubidium clocks too hot: hut removed

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.

Attachment 1: beat.png
12071   Tue Apr 12 09:14:57 2016 SteveUpdateSUSRuby wire - v - groove cut pictures

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.

Attachment 1: Sapphire_prism_wire_standoff.JPG
11878   Mon Dec 14 14:08:49 2015 SteveUpdateSUSRuby wire standoffs update

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 ?

11075   Thu Feb 26 10:56:34 2015 manasaUpdateGeneralRunning cables

[Steve, Manasa]

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

13022   Wed May 31 12:58:30 2017 Eric GustafsonUpdateLSCRunning the 40 m PD Frequency Response Fiber System; Hardware and Software

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.

Attachment 1: Overall_schematic_D1300603-v2.pdf
11662   Sun Oct 4 13:53:30 2015 jamieUpdateLSCSENSMAT oscillator used for EPICS tests

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

3663   Wed Oct 6 22:46:36 2010 kiwamuUpdateGreen LockingSHG at PSL table

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

3188   Fri Jul 9 12:25:25 2010 kiwamuUpdateGreen LockingSHG on PSL table

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.

Attachment 1: PSL_doubling.png
3203   Tue Jul 13 11:00:29 2010 kiwamuUpdateGreen LockingSHG on PSL table : optimum temeprature

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)

Attachment 1: power_temp.png
3204   Tue Jul 13 11:20:07 2010 DmassUpdateGreen LockingSHG on PSL table : optimum temeprature

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
5797   Thu Nov 3 16:43:44 2011 KatrinUpdateGreen LockingSHG temperature (YARM)

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.

 w/o BNC cable at slow plug w/ BNC cable at slow plug T (°C) 29.776 29.776 LT (°C) 39.2 48.4 1064nm power (mW) 440 448 Temp. at TC200 (°C) 35.7 36.4 532nm power in front of Isolator (mW) 1.0 1.0

5798   Thu Nov 3 17:04:23 2011 KojiUpdateGreen LockingSHG temperature (YARM)

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.

5800   Thu Nov 3 17:24:59 2011 ZachUpdateGreen LockingSHG temperature (YARM)

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

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

5809   Fri Nov 4 13:53:33 2011 KatrinUpdateGreen LockingSHG temperature (YARM)

Quote:

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

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

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?

11492   Tue Aug 11 11:30:19 2015 IgnacioUpdateIOOSISO (T240-X) FF of MCL

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.

Attachment 1: MCL.png
Attachment 2: MCTRANS.png
Attachment 3: YARM.png
3481   Fri Aug 27 19:30:31 2010 ranaUpdateCDSSLOW controls

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

10015   Mon Jun 9 22:26:44 2014 rana, zachUpdateCDSSLOW controls recovery

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 >

10025   Wed Jun 11 14:36:57 2014 JenneUpdateCDSSLOW controls recovery

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.

2008   Sun Sep 27 14:45:45 2009 KojiUpdatePSLSLOWscan result

I ran (script dir)/PSL/FSS/SLOWscan on op440m from 11:30 to 12:30 on 27th. Although Rana and later I myself set "timed bombs" for the scan, they did not work as they have probably been ran on Linux. After the scan I relocked PMC, FSS, and MZ . MC locked automatically.

Observation:

1. To keep away from the mode hop, FSS_SLOWDC is to be at around 0. The values -5 ~ -6 is the place for the power, which is my preference for now. BTW, the mode hop only appears to the PSL output (=AMPMON) is this normal?

2. The PSL output looks dependent on the NPRO wavelength. The NPRO output and the PSL output tends to be high when the FSS_SLOWDC is low (= LTMP: Laser Crystal Temp is low). Also there is a step at the LTMP where we think the mode hop is present. This may cause the daily PSL output variation which induced by the daily change of the reference cavity length.

My naive speculation is that the NPRO wavelength is too long (= hot side) for the MOPA absorption as the MOPA heads are cooled to 19deg.

3. Scanning of -10 to +10 changes the LTMP from 42-49deg. This is almost 1/10 of the NPRO capability. The manual told us that we should be able to scan the crystal temperature +/-16deg (about 30deg to 60deg).

What I like to try:
a) Change the NPRO temp to more cold side.
b) Change the MOPA head temp to a bit hot side.
c) Tweak the MOPA current (is it difficult?)

Attachment 1: SLOWscan_090927.png
Attachment 2: Pages_from_miser_126_manual.png
2009   Sun Sep 27 15:25:58 2009 KojiUpdatePSLSLOWscan result
Oh, AMPMON dependence could be an artifact of the ND filter???
For my case, it should be real dependence on the NPRO wavelength,
as the other PDs like the PMC reflection (PMC_RFPDDC) and the RC reflection (FSS_RFPDDC) show the same dependence.
Attachment 1: power_dependence.png
2010   Sun Sep 27 23:21:14 2009 ranaUpdatePSLSLOWscan result

 Quote: What I like to try: a) Change the NPRO temp to more cold side. b) Change the MOPA head temp to a bit hot side. c) Tweak the MOPA current (is it difficult?)

I think that the AMPMON ND problem was just that the responsivity changes with angle. So when I aligned it a little we got some few% improvement in the signal which is not a real power increase.

I don't think we can adjust any of the MOPA parameters because the controller is broken, but we can try the NPRO crystal temperature.

15775   Wed Jan 20 19:12:16 2021 gautamUpdateCDSSLwebview fixed

After fixing multiple issues, the model webviews are updating, should be done by tomorrow. It should be obvious from the timestamps on the index page which are the new ones. These new screens are better than the old ones and offer more info/details. Please look at them, and let me know if there are broken links etc. Once we are happy with this new webview, we can archive the old files and clean up the top directory a bit. I don't think this adds anything to the channel accounting effort but it's a nice thing to have up-to-date webviews, I found the LLO ones really useful in setting up the AS WFS model.

BTW, the crontab on megatron is set to run every day at 0844. The process of updating the models is pretty heavy because of whatever MATLAB overhead. Do we really need to have this run every day? I modified the crontab to run every other Saturday, and we can manually run the update when we modify a model. Considering this hasn't been working for ~3 years, I think this is fine, but if anyone has strong preference you can edit the crontab.

If someboy can volunteer to fix the MEDM screenshot that would be useful.

1867   Sat Aug 8 15:08:14 2009 ranaConfigurationPSLSMOO settings updated in psl.db and SVN updated

I have added/modified SMOO settings to all of the records in psl.db appropriately. Changes checked in to SVN.

As a reminder, you should check in to the SVN all changes you make to any of the .db files or any of the .ini files in chans.

7947   Mon Jan 28 19:07:45 2013 ManasaUpdateGeneralSN6 Laseroptik mirror - Tranmittance measurements

I repeated the measurements using NPRO instead of Crystalaser. I am attaching optical layouts for these measurements for future reference.

Lesson learnt : Do not use Crystalaser for transmission measurements and always separate the transmitted main beam from other beams that result from the wedged surface of the mirror.

### Measurements match specs provided by Laseroptik

p-polarization

T percentage = 0.10% 42 deg
0.092% 44 deg
0.086% 46 deg
Minimum transmittance = 0.081% 52deg

s-polarization

T percentage = 0.048% 42 deg
0.047% 44 deg
0.047% 46 deg
Minimum transmittance = 0.047% 46 deg

12553   Wed Oct 12 15:01:22 2016 steveUpdateSUSSOS ITM baffles plates are ready

The two 40 mm apeture baffles at the ends were replaced by 50 mm one. ITM baffles with 50 mm apeture are baked ready for installation.

 Quote: Green welding glass 7" x 9"   shade #14 with 40 mm hole and mounting fixtures are ready to reduce scatter light on SOS PEEK 450CA shims and U-shaped clips  will keep these plates damped.

Attachment 1: baffle7x9_1.5.jpg
Attachment 2: baffle_holder.jpg
Attachment 3: baffle_top_view.jpg
14587   Thu May 2 10:41:50 2019 gautamUpdateSUSSOS Magnet polarity

A concern was raised about the two ETMs and ITMX having the opposite response (relative to the other 7 SOS optics) in the OSEM PDmon channel in response to a given polarity of PIT/YAW offset being applied to the coils. Jon has factored into account all the digital gains in the actuation part of the CDS system in making this conclusion. I raised the possibility of the OSEM coil winding direction being opposite on the 15 OSEMs of the ETMs and ITMX, but I think it is more likely that the magnets are just glued on opposite to what they are "supposed" to be. See Attachment #6 of this elog (you'll have to rotate the photo either in your head or in your viewer) and note that it is opposite to what is specified in the assembly procedure, page 8. The net magnetic quadrupole moment is still 0, but the direction of actuation in response to current in the coil in a given direction would be opposite. I can't find magnet polarities for all the 10 SOS optics, but this hypothesis fits all the evidence so far..

13429   Thu Nov 16 00:14:47 2017 Udit KhandelwalUpdateSUSSOS Sapphire Prism design

Summary:

• SOS solidworks model is nearly complete
• Having trouble with the design of the sensor/actuator head assembly and the lower clamps
• After Gautam's suggestion, installed Abaqus on computer. Teaching it to myself to eventually do FEM analysis and find resonant frequency of the system
• Goal is to replicate frequency listed in the SOS documents to confirm accuracy of computer model, then replace guide rods with sapphire prisms and change geometry to get same results

Questions:

• How accurate do the details (like fillet, chamfer, placement of little vent holes), and material of the different SOS parts need to be in the model?
• If I could get pictures of the lower mirror clamp (document D960008), it would be helpful in making solidworks model. Document is unclear. Same for sensor/actuator head assembly.
13430   Thu Nov 16 00:45:39 2017 gautamUpdateSUSSOS Sapphire Prism design

 Quote: If I could get pictures of the lower mirror clamp (document D960008), it would be helpful in making solidworks model. Document is unclear. Same for sensor/actuator head assembly.

If you go through this thread of elogs, there are lots of pictures of the SOS assembly with the optic in it from the vent last year. I think there are many different perspectives, close ups of the standoffs, and of the OSEMs in their holders in that thread.

This elog has a measurement of the pendulum resonance frequencies with ruby standoffs - although the ruby standoff used was cylindrical, and the newer generation will be in the shape of a prism. There is also a link in there to a document that tells you how to calculate the suspension resonance frequencies using analytic equations.

15922   Tue Mar 16 14:37:36 2021 YehonathanUpdateBHDSOS SmCo magnets Inspection

In the cleanroom, I opened the nickel-plated SmCo magnet box to take a closer look. I handled the magnets with tweezers. I wrapped the tips of the tweezers with some Kapton tape to prevent scratching and magnetization.

I put some magnets on a razor blade and took some close-up pictures of the face of the magnets on both sides. Most of them look like attachment 1.

Some have worn off plating on the edges. The most serious case is shown in attachment 2. Maybe it doesn't matter if we are going to sand them?

I measure the magnetic flux of the magnets by just attaching the gaussmeter flat head to the face of the magnet and move it around until the maximum value is reached.

For envelope #1 out of 3 the values are: (The magnet ordering is in attachment 3):

 Magnet # Max Magnetic Field (kG) 1 2.57 2 2.54 3 2.57 4 2.57 5 2.55 6 2.61 7 2.55 8 2.52 9 2.64 10 2.58

Going to continue tomorrow with the rest of the magnets. I left the magnet box and the gaussmeter under the flow bench in the cleanroom.

Attachment 1: 20210316_142906.jpg
Attachment 2: 20210316_165626.jpg
Attachment 3: 20210316_165838.jpg
15931   Wed Mar 17 14:40:39 2021 YehonathanUpdateBHDSOS SmCo magnets Inspection

Continuing with envelope number 2

 Magnet number Magnetic field (kG) 1 2.89 2 2.85 3 2.92 4 2.75 5 2.95 6 2.91 7 2.93 8 2.9 9 2.93 10 2.9 11 2.85 12 2.89 13 2.85 14 2.88 15 2.92 16 2.75 17 2.97 18 2.88 19 2.85 20 2.87 21 2.93 22 2.9 23 2.9 24 2.89 25 2.88 26 2.88 27 2.95 28 2.88 29 2.88 30 2.9 31 2.96 32 2.91 33 2.93 34 2.9 35 2.9 36 3.03 37 2.84 38 2.95 39 2.89 40 2.88 41 2.88 42 2.93 43 2.97 44 2.74 45 2.84 46 2.85 47 2.85 48 2.87 49 2.88 50 2.8

I think I have to redo envelope 1 tomorrow.

15964   Thu Mar 25 14:58:16 2021 YehonathanUpdateBHDSOS SmCo magnets Inspection

Redoing magnet measurement of envelope 1:

 Magnet # Max Magnetic Field (kG) 1 2.89 2 2.82 3 2.86 4 2.9 5 2.86 6 2.73 7 2.9 8 2.88 9 2.85 10 2.93

Moving on to inspect and measure envelope 3 (the last one):

 Magnet # Max Magnetic Field (kG) 1 2.92 2 2.85 3 2.93 4 2.97 5 2.9 6 3.04 7 2.9 8 2.92 9 3 10 2.92 11 2.94 12 2.92 13 2.92 14 2.95 15 3.02 16 2.91 17 2.89 18 2.9 19 2.86 20 2.9 21 2.92 22 2.9 23 2.87 24 2.93 25 2.85 26 2.88 27 2.92 28 2.9 29 2.9 30 2.89 31 2.83 32 2.83 33 2.8 34 2.94 35 2.88 36 2.91 37 2.9 38 2.91 39 2.94 40 2.88

16326   Tue Sep 14 16:12:03 2021 JordanUpdateSUSSOS Tower Hardware

Yehonathan noticed today that the silver plated hardware on the assembled SOS towers had some pretty severe discoloration on it. See attached picture.

These were all brand new screws from UC components, and have been sitting on the flow bench for a couple months now. I believe this is just oxidation and is not an issue, I spoke to Calum as well and showed him the attached picture and he agreed it was likely oxidation and should not be a problem once installed.

He did mention if there is any concern from anyone, we could take an FTIR sample and send it to JPL for analysis, but this would cost a few hundred dollars.

I don't believe this to be an issue, but it is odd that they oxidized so quickly. Just wanted to relay this to everyone else to see if there was any concern.

Attachment 1: 20210914_160111.jpg
16328   Tue Sep 14 17:14:46 2021 KojiUpdateSUSSOS Tower Hardware

Yup this is OK. No problem.

ELOG V3.1.3-