the lead spheres that were placed below the granite slab have been flattened by hammering to have lesser degree of wobbling of the slab.

the height of each piece, and the flatness of their surfaces was checked by placing another slab over them and checking by the spirit level.

Jordan, Chub, Paco

Chub and I went into the lab this morning to leak check the new gate valve after pumping over the weekend. This would be done through the RGA and spraying helium around the newly installed flanges. The RGA is set to monitor the partial pressure of helium versus time and we visually watch for any spikes in pressure to indicate an air leak.

So, I mistakenly thought the gate valve was opened and both sides were being pumped on, this was not the case. The vavle was closed so there was a pressure differential whenI turned the handle it tripped the interlocks and closed V4. I closed VM3 to the RGA volume to prevent the filament from being damaged.

Then the medm screen for the vac controls started flashing rapidly, I closed the window and reopened the controls to find all the panels were white, but we could still see the read only vac screen. So Paco restarted c1vac and the controls were restored. V7 closed, but was then reopened.

We now need to restart pumping with the odd pressure differentials between V4 and VM3.

Plan

- TP2 turned off along with the AUX pump

- VM3 opened to vent RGA volume (RGA turned off, filament cooled)

- Open the manual vent screw on TP1 to bring the RGA+TP1 volume back to atmosphere, now no pressure diff. on V4

- Open V4, restart AUX pump to rough out the volume

- Connect RP1/3 line to the pump scroll, turn on RP1/3 RGA+TP1 volume went to mtorr

- Slowly open the manual gate valve

- Connect AUX pump to TP2 and rough out

- Restart TP2, once at speed open V4, close V6 and turn off RP1/3

Now we are pumping on the RGA/TP1 volume with TP2, leak check attempt #2 will happen tomorrow morning

This morning Chub and I leak checked the manual gate valve with the RGA and helium. There was no change in the helium partial pressure while spraying helium around the flanges, all looks good.

I also took a 100 AMU analog scan, after the filament had warmed up overnight and the plot was quite noisy even with the lowest scan speed. I recommend this unit go back to SRS for a filament replacement/recalibration. I am worried yesterday's "vent" of the RGA volume may have burned the filament. See the comparison of yesterday's analog scan to today's below.

SURFS want some locking of IMC for camera adjustment.

So I left the IMC with intermediate gains so that it keeps locking and unlocking.

VCO (overall) iMC gain of -32, FSS common gain 3, and the FAST gain 20. I believe MC2tickle is ON too.

Q. When should we use plano-convex lenses, and when should we use bi-convex?

As I had the same question from Jenne and Dmass in a month,
I just like to introduce a good summary about it.
Lens selection guide (Newport)
http://www.newport.com/Lens-Selection-Guide/140908/1033/catalog.aspx

At a first order, they have the same function.
Abberation (= non-ideal behavior of the lens) is the matter.

Since the f numbers of the lenses in the proposed design with biconvex lenses are a little less than 5 and the conjugate ratio(that is the ratio of object to image distance) is greater than 5, I explored the use of plano convex lenses, but with the same focal lengths, the accessible u-v range is restricted with the planoconvex rather than biconvex lenses.
On Friday, I had a discussion with Gautam and Steve about the hardware that is the cylindrical enclosures for the camera and the telescope and we examined two such aluminum cylindrical enclosures. One of them was the one being currently employed for the cameras. The dimensions were measured and the length was found to be 8’’ and an outer diameter of 26 cm within an error of 0.5 cm.
The other enclosure was longer with a length of 52 cm(±0.5 cm), outer diameter of 10”(±0.1”) and an inner diameter of 23.7cm(±0.1cm). Pictures of these enclosures are attached.
Both of these enclosures have internal optical rail to mount the camera and the telescope system. Depending on the weight of the telescope system(that includes the weight of the slotted lens tubes, the lenses), it might be more efficient to clamp the telescope system itself on the rails with the low weight camera mounted on the lens tube.
I also went around to get an idea of distance of the GigE from the test masses. This was just a step to verify if the object distances were really in the ranges being taken into consideration, that is between 1500 and 2500 mm. I also tried to cross check the measurements with the CAD drawing of the 40m. However, as I have been informed, the distances in the CAD version are not updated.

The distances from the optic to the CCD detector would range from around 75.1 cm for MC2, 94.01 cm for ITMX, 97.21 cm for ETMX, 117.19 cm for ITMY and 88.463 cm for ETMY. The illuminator for the ETMY was disconnected, so Gautam helped me access the manual lamp control to enable me to take measurements.
The values for ETMX, MC2 and ITMY are subject to an error of ±1’’. Due to a lot of obstructions, the values for ETMY and ITMX may be subject to a lot more error. Even so, these distances are clearly less than 2 meters, prompting me to run the simulations again and verify that the chosen combination is still useful.

As for the slotted lens tubes to mount the 2” lenses, the following options are available on the Thorlabs catalog. CVI and Edmunds do not seem to offer much of the stackable lens tubes.

SM2L30C is a lens tube onto which the optic can be mounted without the need of a spanner wrench. It also has a length of 3”. However, it has a rotatable slip shield which can be rotated open as and when the access to optic is required. However, there might be a slight compromise with rigidity here.

SM2L30 is a lens tube with internal thread depth of 3”, the optic can be mounted using spanner wrench and a retainer ring. The optic cannot be accessed from both ends of the tube here.
SM2M30 is a lens tube with no external threads, therefore lens tube couplers would be required to stack the tubes. The optic is accessible from both ends here though.

Considering the merits and demerits of all these available options, the use of SM2L30 might be considered as it provides a quick and efficient way of stacking multiple lens tubes. As for accessing the optic from both sides, using multiple tubes helps overcome the problem and still ensures that we are able to access a number of separation distances as per requirement.
Thorlabs also offers an internal C to external SM2 adapter so that the lens tube could be fixed onto the C mount of the camera. 

I would be examining the use of 1" diameter lenses for the eyepiece as suggested by Rana, as that might give us more flexibility. 

Les Guthman interviews  gradstudent Graig.

Main laser emergency shut off was acuated by accident during this fiming. The laser is turned on.

[Koji,Joe]

PART 1:

Koji was unable to build his c1lst model first thing this morning.  Turns out there was  a bug with RCG parser that was introduced on Friday when we did the RCG updates.  We talked Alex who did a quick comment fix.  The diff is as follows:

Index: Parser3.pm
==============================

This was some code to remove TAGs from the .mdl file for some reason which I do not understand at this time.  I will ask tommorrow in person so I can understand the full story.

PART 2:

Koji then rebuilt and started the c1lst process.  This is his new test version of the LSC code.  We descovered (again) that when you activate too many DAQ channels (simply uncommenting them, not even recording them with activate=1 in the .ini file) that the frame builder crashes.  In addition, the c1lsc machine, which the code was running on, also hard crashed.

When a channel gets added to the .ini file (or uncommented) it is sent to the framebuilder, irregardless of whether its recorded or not by the frame builder.  There is only about 2 megabytes per second bandwidth per computer.  In this case we were trying to do something like 200 channels * 16384 Hz * 4 bytes = 13 megabytes per second.

The maximium number of 16384 channels is roughly 30, with little to no room for anything else.  In addition, test points use the same allocated memory structure, so that if you use up all the capacity with channels, you won't be able to use testpoints to that computer (or thats what Alex has led me to believe).

The daqd process then core dumped and was causing all sorts of martian network slowdowns.  At the same time, the c1lsc computer crashed hard, and all of the front end processes except for the IOP on c1sus crashed.

We rebooted c1lsc, and restarted the c1sus processes using the startc1SYS scripts.  However, the c1susfe.ko apparently got stuck in a wierd state.  We were completely unable to damp the optics and were in general ringing them up severely.  We tried debugging, including several burt restores and single path checks.

Eventually we decided to reboot the c1sus machine after a bit of debugging.  After doing a burt restore after the reboot, everything started to damp and work happily.  My best guess is the kernel module crashed in a bad way and remained in memory when we simply did the restart scripts.

Lessons learned on the beam spot centering (so far)

Well-known fact:

The spot position on MC2 can be adjusted by the alignment of the mirror while maintaining the best overlapping between the beam and the cavity axes.

In general, there are two methods:

1) Use the cavity as a reference:
Move the MC mirrors such that the cavity eigenmode hits the centers of the mirrors.
-> Then adjust the incident beam to obtain the best overlapping to the cavity.

2) Use the beam as a reference:
Move the incident beam such that the aligned cavity has the spots at the centers of the mirrors.
-> Then adjust the incident beam to obtain the best spot position while the cavity mirrors keep tracking
the incident beam.

Found the method 1) is not practical.

This is because we can move the eigenmode of the cavity only by very tiny amount if we try to keep the cavity locked.
How much we can move by mirror alignment is smaller than the waist radius or the divergence angle.
For the MC, the waist radius is ~2mm, the divergence angle is 0.2mrad. This means the axis
translation of ~1mm is OK, but the axis rotation of ~4mrad is impractical.

Also it turned out that adjustinig steering mirror to the 10-m class cavity is quite difficult.
A single (minimum) touch of the steering mirror knob is 0.1mrad. This already change the beam position ~0.1mm.
This is not an enough resolution.

Method 2) is also not so easy: Steering mirrors have singular matrix

Indeed! (Remember the discussion for the IMMT)

What we need is the pure angle change of 4mrad at the waist which is ~2m distant from the steering mirror.
This means that the spot at the steering mirror must be moved by 8mm (= 4mrad x 2m). This is the result of the
nearly-singular matrix of the steering mirrors.

We try to avoid this problem by moving the in-vac mirror (IM1), which has somewhat independent move.
The refl beam path also has the big beam shift.
But once the vacuum manifold is evacuated we can adjust very little angle.

This can also be a good news: once the angle is set, we hardly can change it at the PSL side.

You guys must work harder.

All simulink diagrams being used at the 40m are now under version control. I have compiled, installed, and restarted all current models to make sure that the files are all in a working state, which they seem to be. I have checked the latest version of the userapps svn repository to /opt/rtcds/userapps2.9, to compare the files therein with our current state. 

Surprisingly, only two files in the userapps svn have been changed since they were checked out here, and only one of these is a real change of any kind. 

LSC_TRIGGER.mdl was edited at some point simply to align some drawn lines; no functionality was changed. 

SCHMITTTRIGGER.mdl was edited to change the "INVERT" epics channel from an arbitrary EPICS input, to binary (true/false) input. This does not change the connectivity diagram, and in fact, I don't think we use this option in any of our scripts, nor is it exposed on our medm screens. 

Thus, I think that the only place for block changes can bite us is changes in the fundamental blocks in CDS_PARTS that are used in our custom 40m library parts. 

For posterity, these are the files used in compiling all of our running models. (Path base: /opt/rtcds/userapps/release)

Electrical Shop came in today to replace the lightbulbs around 40m. I supervised the entire visit, inside and outside the lab area. I was sure to use the ladders which were already inside the lab area. Although, while I was crawling under the MC beam tube, I came up too quickly and bumped it. This may have caused MC to become misaligned. Anyways, Yehonathan and I are realigning now.

[Steve, Diego, Manasa]

Since the beatnotes have disappeared, I am taking this as a chance to put the FOL setup together hoping it might help us find them.

Two 70m long fibers now run along the length of the Y arm and reach the PSL table.

The fibers are running through armaflex insulating tubes on the cable racks. The excess length ~6m sits in its spool on the top of the PSL table enclosure.

Both the fibers were tested OK using the fiber fault locator. We had to remove the coupled end of the fiber from the mount and put it back in the process. So there is only 8mW of end laser power at the PSL table after this activity as opposed to ~13mW.  This will be recovered with some alignment tweaking.

After the activity I found that the ETMY wouldn't damp. I traced the problem to the ETMY SUS model not running in c1iscey. Restarting the models in c1iscey solved the problem.

[Valera, Suresh]

   We wanted to continue the work with WFS servo loops.  As the current optical paths on the AP table do not send any light to the WFS, I changed a mirror to a 98% window and a window to a mirror to send about 0.25mW of light towards the WFS.   The MC locking is unaffected by this change.   The autolocker works fine.

   When the power to the MC is increased, these will have to be replaced or else the WFS will burn.

The Lightwave NPRO power supply which is being shared between the AS table and the ETMY table has been shifted back to the ETMY table. 

The current to the laser is set at 1.5A.  The laser output is 200mW at this current level.

[Suresh / Kiwamu]

 We did the following things :

   - Took the LightWave NPRO out from the MOPA box

   - Temporarily took out the laser controller which has been connected to the Y end laser.

   - Put the LightWave on AP table and plugged the laser controller and confirmed that it still emits a beam

[Things to be done]

   - measure the beam profiles and power

   - get a laser controller, which will be dedicated for this laser, from Peter King

[Background and Motivation]

 The PRC and SRC length have to be precisely measured before the vent.

In order to measure those absolute length we are going to use the Stochino technique, which requires another laser to scan the cavity profiles.

The LightWave NPRO laser in the MOPA box was chosen for the Stochino laser because it has a large PZT range of 5 MHz/V and hence allows us to measure a wider frequency range.

The laser in the MOPA box had been connected to home-made circuits, which are not handy to play with. So we decided to use the laser with the usual laser controller.

Peter King said he has a LightWave laser controller and he can hand it to us.

Until we get the controller from him we do some preparations with temporary use of the Y end laser controller.

• N/S ARM FL.
• N/S ARM INC.

These two lights inside the 40m-lab are not working.

I've moved the following components that was a part of Koji's setup from the PSL table to the SP table so that I may measure the beam profile of the beam from the spare Lightwave NPRO and work on a mode-matching solution for the X-end.

• Lightwave laser
• Lightwave controller
• Interlock switch (Newport)
• HWP and PBS

I did some preliminary characterization of the beam from the Lightwave - in the power controlled mode, setting the "ADJ" parameter to 0 (which is the state recommended in the manual) gives an output power of ~240mW. I used the HWP and PBS to dump most of this into a "Black Hole" beam dump, but I was still getting about 300uW of power after this. This was saturating the CCD in the beam profiler (even though 300uW for a beam of ~1mm should be well within the recommended operating limits as per its manual - maybe the ND filter on the camera isn't really ND4.0), and so I further reduced the "ADJ" parameter on the laser controller to -20, such that I had no saturation of the CCD. I will try and take some data later today. The laser is presently in "Standby" mode, and the SP table is fully covered again.

jiIn fact, it is one of the most difficult type mode profiling to measure a beam directly out from a laser source.

If you reduce the power by ADJ, this significantly changes the output mode as the pumping power varies temperature gradient of the laser crystal and thus thermal lensing in it. I'd recommend you to keep the nominal power.

If you use a PBS for power reduction, you should increase the transmission ~x10 from the minimum so that you are not dominated by possible junk polarization.

Any transmissive BK7 components where the beam is small can cause thermal lensing. In order to avoid this issue, I usually use two noncoated (or one AR coated) optical windows made of UV fused silica to pick off the beam. Once the beam power is reduced I suppose it is OK to use an additional ND filter in front of the CCD.

Another more reliable method is an old-good knife edge measurement.

As Koji pointed out in the previous elog, the CCD beam profiler was ill suited for this measurement. Nevertheless, to get a rough idea of the beam profile, I made a few rearrangements to my earlier setup:

• Kept the HWP at the same place it was, as this is roughly the configuration that is going to be used at the endtable anyways. It was ~7cm from the shutter housing on the laser head (unfortunately, I neglected to take a picture).
• Moved the PBS downstream till it was ~40 cm away (so as to minimize the thermal lensing effect from the ~300mW beam) from the laser head. Rotated the HWP till I got about 6mW of transmitted power (dumped the rest into a black hole)
• Installed a 95% reflecting BS to further attenuate the power to a level suitable for the CCD (dumped the reflected part onto a razor beam dump)
• Installed the CCD beam profiler and captured an image, at ~60cm from laser head. In this configuration, I was able to get a clean image capture without the CCD saturating. Unfortunately, I could not transfer it off the laptop used to operate the beam profiler, I will upload a screen capture tomorrow once I get it. Anyways, the main observation was that the beam appeared quite elliptical (ellipticity ~0.6). It was also not clear to what extent thermal lensing at the PBS/BS was afftecting this measurement.

Following Koji's suggestion, I decided to do a knife-edge measurement as well. The measurement configuration was similar to the one described above, except the PBS/BS were removed, and a 1.0 neutral density filter was was installed ~80cm from the laser head (here the ~300 mW beam was >2mm in diameter, as judged by eye). I used the Ophir power meter, which was why I had to install an ND filter as it is rated for 100mW max power. I will put a picture up tomorrow. Thermal lensing shouldn't be of much consequence here, as we just need the whole beam to fall onto the power meter active area (verified by eye), and only the relative change in power levels as the knife edge cuts the beam matters. I took the cross-sectional profile of the beam by translating the knife in the x-direction (i.e. cut the beam "left to right" ).

Attachments 1 and 2 are the results from todays measurements. It remains to repeat by cutting the beam along the y direction, and see what ellipticity (if any) shows up. I also found some "nominal" numbers in page 4 of the Lightwave datasheet - it tells us to expect a waist 5cm from the shutter housing, with horizontal and vertical 1/e^2 diameters of 0.5mm and 0.38mm respectively. My measurement suggests a horizontal diameter of ~0.25mm (half the "nominal" value?!), and the waist location to be 8.22cm from the shutter housing. I wonder if this discrepancy is a red flag? Could it be due to the HWP? I'm reasonably sure of my calculations, and the fits have come out pretty nicely as well...

I don't think the discrepancy is a serious issue as long as the mode is clean. The mode is determined by the NPRO crystal and is hard to change by anything except for the thermal lensing in the crystal.

And I never succeeded to reproduce the mode listed in the manual.

One thing you'd better to take care is that clipping of the beam produces diffraction. The diffracted beam spreads faster than the nominal TEM00 mode. Therefore the power meter should to be placed right after the razor blade. i.e. As you move the longitudinal position of the razor blade, you need to move the power meter.

I've repeated the measurement for the x-direction and also did the y-direction, taking into account Koji's suggestion of keeping the power meter as close as possible to the knife edge. Attachment #1 shows a picture of the setup used. Because an ND filter is required to use this particular power meter, the geometrical constraints mean that the closest the power meter can be to the knife edge is ~3cm. I think this is okay. 

The result from the re-measured X-scan (Attachments #2 and #4) is consistent with the result from yesterday. Unfortunately, in the y-direction (Attachments #3 and #4), I don't seem to have captured much of the 'curved' part of the profile, even though I've started from pretty much adjacent to the HWP. Nevertheless, the fits look reasonable, and I think I've captured sufficient number of datapoints to have confidence in these fits - although for the Y-scan, the error in the waist position is large. The ellipticity as measured using this method is also significantly smaller than what the CCD beam profiler was telling us. 

If we are happy with this measurement, I can go ahead and work on seeing if we can arrive at a minimally invasive mode-matching solution for the X-end table once we switch the lasers out...

I attempted to measure the frequency noise of the extra Lightwave NPRO we have that is currently sitting on the PSL table. I did the following:

1. Turn the Lightwave NPRO back on.
2. Disable MC autolocker and close the PSL shutter.
3. Checked the alignment of the pick off from the PSL beam and the beam from the Lightwave NPRO onto the PDA10CF. These seemed okay, and I didn't really have to tweak any of the steering optics. I was getting a DC signal level of ~7V (the PD should drive a 1Mohm load up to 10V so it wasn't saturated).
4. Swept the crystal temperature on the Lightwave using the dial on the front panel of the controller. I found beatnotes at 48.1831 degrees and 45.3002 degrees. However, the amplitude of the beatnote was pretty small (approx. -40dBm on the Agilent NA). I tried playing around with the beam alignment and laser power on the Lightwave NPRO to see if I could increase the beatnote amplitude, but was unsuccessful - turning up the laser power (from the nominal level of 55mW as per the front panel display) caused the PD to saturate at 10V, while as far as I could tell, the alignment of the two beams onto the PD is reasonably good. This seems inconsistent with the numbers Koji has reported in this elog, where he was able to get a beatnote of ~1Vpp for a DC of 2.5 V. 
5. I tried locking the PLL (in roughly the same configuration as reported here) with this small amplitude beatnote but was unsuccessful. 

I've turned the Lightwave NPRO back to standby for now, in anticipation of further trials later today. I've also restored the IMC. 

After adjusting the alignment of the two beams onto the PD, I managed to recover a stronger beatnote of ~ -10dBm. I managed to take some measurements with the PLL locked, and will put up a more detailed post later in the evening. I turned the IMC autolocker off, turned the 11MHz Marconi output off, and closed the PSL shutter for the duration of my work, but have reverted these to their nominal state now. The are a few extra cables running from the PSL table to the area near the IOO rack where I was doing the measurements from, I've left these as is for now in case I need to take some more data later in the evening...

Summary of the work done today:

Alignment and other work on PSL table

As mentioned in a previous elog, the beatnote amplitude I obtained was tiny - so I checked the alignment of the two beams onto the PD. I did this as follows:

• Checked the alignment of the two beams on the recombination BS. Moved the steering mirror for the PSL beam until the two were aligned, as verified by eye using an IR card
• Turn the steering mirror just before the fast focusing lens and thorlabs PD (kept the fork fixed, just loosened the screw on the post to do this) such that the far-field alignment of the two beams could be checked. I used the BS to tweak this alignment as necessary
• Iterate the previous two steps till I was happy with the alignment
• Return steering mirror before the PD to its original position, tweak alignment until DC level on the PD was maximized (as verified using an oscilloscope) 
• Adjust the HWP just after the lightwave laser such that the power arriving at the PD from the PSL beam and the lightwave beam were approximately equal - verified by blocking each beam and checking change in the DC level

After doing all of this, I found a beatnote at ~-10dBm at a temperature of 45.3002 degrees on the Lightwave. The DC level was ~8V (~4V contribution from each beam). 

PLL and frequency nosie measurements:

Pretty much the same procedure as that described in this elog was followed for setting up the PLL and taking the measurements, except that this time, I used the two SR560s in a better way to measure the open loop TF of the PLL. This measurement suggested a UGF of ~ 10kHz, which seems reasonable to me. I turned the 11MHz marconi off because some extra peaks were showing up in the beat signal spectrum. I judged that the beatnote was not large enough to require the use of an attenuator between the PD and the mixer. I was able to lock the PLL easily enough, and I've attached spectra of the control signal (both uncalibrated and calibrated). To calibrate the spectrum, I did a quick check to determine the actuator gain of the spare Lightwave laser, by sweeping the fast PZT with a low frequency (0.5Hz) 1Vpp sine wave, and looking at the peak in the beat signal spectrum move on the network analyzer. This admittedly rough calibration suggests that the coefficient is ~5MHz/V, consistent with the other Lightwave. Eric suggested a more accurate way to do this would be to match up spectra taken using this method and by locking the PLL by actuating on the FM input of the Marconi - I didn't try this, but given the relatively large low-frequency drifts of the beatnote that I was seeing, and that the control signal was regularly hitting ~2V (i.e shifting the frequency by ~10MHz), I don't think this is viable with a low MHz/V coefficient on the Marconi, which we found is desirable as described here. 

Bottom line:

The spare Lightwave frequency noise seems comparable to the other two measurements (see attachment #2). If anything, it is a factor of a few worse, though this could be due to an error in the calibration? I'm also not sure why the shapes of the spectra from today's measurement differ qualitatively from those in elog 11929 above ~7kHz. 

Some random notes:

• Do we want to do an AM/PM characterization of the spare Lightwave laser as well? It might be easier to do the PM measurement while we have this measurement setup working
• Yesterday, I noticed some peaks in the spectrum of the PD output while only the PSL beam was incident on it, at ~35MHz and ~70 MHz. They were pretty small (~-50dBm), but still clearly discernible over the analyzer noise floor. It is unclear to me what the source of these peaks are.

Before distrubing the beat setup with the spare Lightwave laser, I wanted to see if I could resolve the apparent difference in behaviour between the measured free running noise of the spare Lightwave laser and my earlier measurements with the existing X and Y end lasers above ~5kHz. So I redid the measurement, but this time, on Eric's suggestion, while taking spectra on the SR785, I was careful to maintain the same "CH1 input range" while measuring the control signal spectrum and the measurement noise spectra. The level used was -20dBvpk. I think the measured spectrum shape now makes sense - above ~4kHz, the SR560 noise means that the SNR is poor and so we can only trust the spectra up to this value (the spectra for the end lasers are from earlier measurements where I did not take care to keep the input range constant). Anyways, I think the conclusion is that the spare Lightwave seems to have a free-running frequency noise that is approximately a factor of 3 worse than the Lightwave laser at the Y-end, though this may be because I didn't take the measurement at the optimal operating conditions (diode current, power etc). But I guess this is tolerable and that we can go ahead with the planned swapping out of the existing Innolight at the X-end with this laser. 

I will now move the Lightwave laser off the PSL table onto the SP table where I will do some beam characterization and see if I can come up with a satisfactory mode-matching solution for the swap. I've borrowed a beam profiler from the TCN lab for this purpose.

[Koji,gautam]

Lightwave NPRO information:

Model: 126-1064-700

Serial Number: 337

Manufactured: December 1998!!

Details of checks performed:

Koji tuned the parameters on the laser controller and we observed the following:

1. Turning "ADJ" to +10 and the pumping current all the way up to the maximum (2.62A) allowed us to recover an output power of 300mW, at a laser crystal temperature of ~45degrees
2. The output power increased almost monotonically as a function of the laser crystal temperature - why? We were able to see powers as high as 250mW (at ADJ=0) for the maximum crystal temperature of ~60 degrees.
3. We checked that we could believe the readout of the power meter by measuring the power using the Scientech power meter - we saw ~270mW after the Faraday with this meter, accounting for ~10% loss through the Faraday, this corresponds to an output power of 300mW (all this was done at ADJ=+10, DC=2.62A). I suspect that the display is dodgy though, because changing the Diode Current from 2.52A to 2.62A increased the output power by almost 100mW, which seems hard to believe?
4. The Lightwave NPRO does not have heat dissipation fins attached - could this be affecting the power output somehow? In any case, this has to be rectified. So if we decide to keep the Lightwave NPRO, the layout will still need minor changes to accommodate the heat fins. Steve, do we have these in hand?

Way forward

Ericq has begun the characterization of the repaired Innolight. We checked that it outputs 1W of power. We will now have to perform the following measurements:

• Frequency noise using PLL
• AM/PM response of the PZT
• Laser power output as a function of diode current - this will be useful for diagnostic purposes in the future
• AUX temperature vs PSL temperature at which beatnotes can be found
• Waist measurement - the mode matching and optical layout upstream of the doubling oven at least will have to be modified significantly

All of these will have to be done before installing this laser at the endtable.

I believe the consensus as of now is to go ahead with carrying out the above measurements. Meanwhile, we will keep the Lightwave NPRO on and see if there is some miraculous improvement. So the decision as to whether to use the Innolight is deferred for a day or two.

I re-measured the power levels today.

We have ~205mW out of the NPRO, and ~190mW after the Faraday. It doesn't look like the situation is going to improve dramatically. I'm going to work on a revised layout with the Innolight as soon as I've profiled the beam from it, and hopefully, by Monday, we can decide that we are going ahead with using the Innolight.

I set the limitters of the MC WFS servos not to inject the feedback more than 2000.

The residual of the WFS shakes the MC SUSs at every lock loss.

Because I keep taking a long time to search for these, since I can't remember the keywords in the different entries, here are the links:

elog 3759 : Green X end aux laser temperature setting vs. PSL laser temperature setting

elog 4439 : Green Y end aux laser temperature setting vs. PSL laser temperature setting

More words: beat note, doubling, second harmonic.

Relevant results: 

T_Xend = 8.31 + 0.9293*T_PSL

T_Yend = 6.9825 + 0.87326*T_PSL

Also, C1:GCY-SLOW_SERVO2_OFFSET was 29725 (twenty nine thousand seven hundred twenty five) cts when we sat down to start today.

C1:GCX-SLOW_SERVO2_OFFSET was 80 (eighty) cts when we sat down to start today.  Why the offsets are so different, I don't know.  But I was able to find the X green beatnote with this small number offset, so it is approximately correct.

 Alex switched the mount point for /cvs/cds on Linux1 to the 1.5 TB RAID array after he finished copying the data from old drives.  This required a reboot of linux1, with all the resulting /cvs/cds mount points on the other computers becoming stale.  Easiest way to fix that he found was to do a reboot of all the control room machines.  In addition, a reboot fest should probably happen in the near futuer for all the front end machines since they will also have stale mount points as well from linux1.

The 1.5 TB RAID array mount is now mounted on /home of linux1, which was the old mount point of the ~300 GB drive.  The old drive is now at /oldhome on linux1.

While meditating on other things, I have noticed / found the following today:

YARM ASS works okay.  Yesterday I measured the sensing matrix for the ASS for both arms (although I forgot to copy one of the matrix elements to my text file for Xarm - needs remeasuring).  I put the Yarm matrix in (after appropriate inversion, only non-zero pitch-to-pitch, yaw-to-yaw elements).  I turned on the Yarm ASS, and  the yaw converged pretty quickly (couple of minutes), with gains of -1 in the servos, overall gain of anywhere between 0.005 and 0.010.  The pitch took much longer, and I had to 'pause' several times by turning off the overall gain for the yarm ass when the MC lost lock (which has happened several times tonight - unknown cause).  Eventually, the pitch settled out, and quit changing, but the lockin outputs weren't zero, even though the error signal for the servos were almost zero (gains for the pitch servos were -0.5, overall gain ~0.005 was better than 0.01 - higher gain caused oscillations in the lockin outputs).  I think this means that I need to remeasure the yarm pitch ass matrix.  It's still much, much faster to just turn on the dithers, watch the striptool of the lockin outputs, and align the cavity by hand.

I think the ETMX Trans camera view is clipped a little bit.  I went down there, and it doesn't seem to be on the last optic before the camera, and moving the spot on the camera doesn't change the shape of the image, so I don't think it's on the camera.  We should look into this, since it's either clipping on the BS that separates some camera beam from the TRX beam, or TRX is getting a clipped beam too.  If the clipping is any earlier in the Trans path, the Trans QPD could also have some clipping.  This requires investigation.  The xarm trigger needs to be reset/disabled so we don't lose lock every time we block the TRX beam (as was happening to me).

XARM really doesn't like to relock unless the POX whitening is turned off.  Good flashes, doesn't really catch (10+ min waiting (while working on Yarm stuff) ).  After turning off the whitening, it catches almost immediately. Even though it's on the to-do list to rethink the tuning of our whitening, we should probably implement the whitening triggering now anyway.  It'll make things easier.

The double integrator that Rana implemented in the X and Y arm servo filters last week take 8 seconds to turn off (due to Foton settings), so even though they are triggered to turn off immediately upon lockloss, they sit around and integrate for 8 seconds, so have huge signals.  If the cavity flashes and the locking trigger engages during that 8 seconds, we send a huge kick to the ETMs.  I'm modeling the response of the filters to an impulse and noise, particularly in the case of ramping on the double integrators.  The problem is that a flat filter has 0deg phase, but the double integrator has 180deg phase at low frequencies, so there's some weird sign flipping that can happen as we ramp - this is part of what I'm modeling.

MC is losing lock unusually often tonight.  Everything on the servo board screen looks normal (which is good since that's all set by the autolocker).  I just disabled the test exc in, but that's been left enabled for a while now, and it hasn't (I think?) been a problem since there shouldn't be anything connected to the board there.  PMC transmission is a little low, 0.816, and FSS is starting to get near -1 on the slow actuator adjust, but we've seen locking of the PMC problems around -1.5 or -2 of the FSS, and the adjust value was at -0.8 earlier tonight and we still had MC locking problems.  I have had the seismic channels open on Dataviewer for the last several hours, and I'm not seeing any spikes in any of the Guralp channels which correspond to the times that the MC loses lock.  BLRMS don't seem particularly high, so MC lockloss cause is still a mystery for today.

The ETMX monitor selector on the VIDEO screen seems not to be switching the actual camera that's shown on the monitor.  Using the script command itself works, so my screen is wrong.

I'd like to get a concrete list of measurements written down, so that it's clear what needs to be done before I graduate.

Noise couplings:

• Laser amplitude noise coupling to DARM
  • We don't have an AOM for ISS right now, but we should be able to just stick it back in the beam path, right?  I think Koji checked that the AOM was all okey-dokey recently.
  • AOM calibration should tell me how much the single-pass amplitude changes as a function of input signal.
• Laser frequency noise coupling to DARM
  • Inject signal at the CM board input, which should be calibrated by looking at response to calibrated MC2 motion.
• Marconi phase noise coupling to DARM
  • Marconi can produce internally or accept via BNC 0-10 rad of phase modulation.  Marconi spec sheet should give me rad/V for the input calibration.
• Marconi amplitude noise coupling to DARM
  • Using external input of Marconi.  Marconi spec sheet should give me input calibration.
• MICH err to DARM
  • Compare with Optickle model
• PRCL err to DARM
  • Compare with Optickle model

Noise cancellation:

• PRC angle
• MICH noise removed from DARM (compare flat gain FF vs. Wiener FF)
• PRCL noise removed from DARM (compare FF shape from model vs. Wiener FF)
• MC length noise (equiv. to laser freq noise) removed from CARM & DARM

Are there things that I'm missing?  I've never had an IFO to characterize before.

Here are some tests we should script.

1. Checking Coil Vmons, OSEM PDmons, and watchdog enable wiring
   • Disable input to all the coil output filter modules using C1:SUS-<OPTIC>_<COIL>_SWSTAT (this is to prevent the damping loop control signals from being sent to the suspension)
   • Set ramptimes for these filter modules to 0 seconds.
   • Apply a step of 100 cts (~15 mV) using the offset field of this filter module (so the test signal is being generated by the fast CDS system).
   • Confirm that the step shows up in the correct coil Vmon channel with the appropriate size (in volts), and that other Vmons don't show any change (need to check the sign as well, based on the overall gain in this filter module).
   • Confirm that the largest response in the PDmon signals is for the same OSEM. There will be some cross-coupling but I think we always expect the largest response to be in the OSEM whose magnet we pushed provided the transimpedances are the same across all 5 coils (which is true except for PRM side), so this should be a robust criterion.
   • Take the step off using the watchdog enable field, C1:SUS-<OPTIC>_<COIL>_COMM. This allows us to confirm the watchdog signal wiring as well.
   • Reset ramptimes, watchdogs, input states to filter modules, and offsets to their pre-test values.
   • This test should tell us that the wiring assignments are correct, and that the Acromag ADC inputs are behaving as expected and are calibrated to volts.
   • This test should be done one channel at a time to check the wiring assignments are correct.
2. Checking the SUS PD whitening
   • Measure spectrum of individual PD input (fast CDS) channels above 30 Hz with the whitening in a particular state
   • Toggle the whitening state.
   • Confirm that the whitened sensor noise above 30 Hz is below the unwhitened case (which is presumably ADC noise.
   • This test should be done one channel at a time to check the wiring assignments are correct.

Checking the Acromag DAC calibration is more complicated I think. There are measurements of the actuator calibration in units of nm/ct for the fast DACs. But these are only valid above the pendulum resonance frequency and I'm not sure we can synchronously drive a 10 Hz sine wave using the EPICs channels. The current test which drives the PIT/YAW DoFs with a DC misalingment and measures the response in the PDmon channels is a bit ad hoc in the way we set the "expected" response which is the PASS/FAIL criterion for the test. Moreover, the cross-coupling between the PDmon channels may be quite high. Needs some thought...

Never mind.  This is just the low pass filter that Den put in to try to deal with the moving cavity pole. 

Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines.  This had no effect other than to keep me searching and measuring until I figured it out.  If I turn off the low pass, the phase pops back up to very close to the reference.  The low pass currently comes on automatically as part of the carm_cm_up script.

I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.

Also this evening, I went to the Yend and did another tweak-up of the green beam alignment. 

[Rana, Jenne]

We opened up the little Thorlabs battery operated PD to see what was inside.  Rana took some pictures, and I drew a schematic (attached).  It's just a diode, biased with a battery (albeit a crazy 22.5V battery).

---------------
Comment by KA: PD is Hamamatsu S1223-01 Si PIN diode.

What a crazy battery. The main point is that it looks like this can be used for reasonable purposes: uses a load resistor on the BNC connector and you can use some pre-amp (e.g. Busby box or SR560) to have a low noise PD readout. You can also use the SR560 in its A-B mode as an 'opamp'. Ground the A input and the use a pole at 1 Hz and make the Output go into the B input through some large series resistor. The BNC from the PD gets Teed into the B input as well.

Then this becomes a transimpedance circuit readout of the diode, using the current noise of the SR560 as the limit.

I tried to figure out why offline LMS filter subtract seismic noise much better from MC_F then the Wiener filter. I did the calculations twice - with my codes and with Matlab in-build functions, the results are the same. So this is not a code error.

The coherence between GUR 1, 2 and MC_F is still poor. Wiener filter is linear and its performance is confined to the frequency ranges where we see coherence. Lms filter is non-linear and it may be possible to subtract the noise even if non-linear effects are present in the system.

I've checked seismometer readout box again. I've soldered 50 Ohms to plus and minus inputs to VERT 1,2 N/S 1,2, E/W 1,2 - GUR 1 and 2 use these channels. Then I put the box back and connected it to the ADC.

The plot shows that the readout box noise is below the ADC noise. It is possible that amplifiers introduce non-linear effects. To check this I plotted the coherence between OSEM sensors and GUR1X signal:

The coherence between OSEM sensors and GUR1X is pretty good, so may be witness path is not responsible for low coherence at 0.1 - 0.5 Hz between MC_F and GUR 1,2. IT seems that MC_F is bad at low frequencies. I terminated the input to the Channel 1 of the Pentek Generic board, where MC_F is plugged in.

ADC is also good. Something else is wrong.

 Larry and Nicolas

Larry's transfer function measurements suddenly started returning 0dB 0degrees when before there was some fake filter in the C1:ALS-OFFSETTER2 filter bank.

We looked in the filter bank and his filter was gone. So I created a new filter called LARRYP in FM2. We also disabled the output so he could drive the filter bank and test his TF code.

I'll bring a file binder "40m wiring diagram" to home at the next chance.
There is another one on the shelf in the control room.

(I thought I put it in my bag, but it looks like that I left it somewhere around the fax area)

Koji has provided a 2TB USB3 external hard drive that will get daily backups of chiara:/home/cds, the idea being that if the internal HD at /dev/sdb1 fails, we can physically open the external up, and swap the hard drive into chiara. 

We're running an rsync job on it right now, which should be done in a few hours. (USB3 is fast!)

I've also written a backup script at scripts/backup/rsync_chiara.backup which keeps its books in scripts/backup/rsync_chiara.backup.log 

I'm adding a entry to the root crontab on chiara to execute the script every day at 7am. 

 I had some syntax errors in the script that prevented the script from doing the right thing. The backup is now up to date, and the cronjob should work. 

[Jon, gautam]

We found that the caput commands were taking much longer to execute on megatron than on pianosa (for example). Suspecting that this had something to do with the fact that megatron was using EPICS binaries from the shared NFS drive which were compiled for a much older OS, I installed the latest stable release of EPICS on megatron. The new caput commands execute much faster. I also added the local EPICS directory to the head of the $PATH variable used by the MC autolocker and FSS Slow scripts, so that they use the new caput command. But mcup is still slow - maybe my new path definition isn't picked up and it is still using the NFS binaries? To be looked into...

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "en_US.ISO8859-1",
        LC_MONETARY = "en_US.ISO8859-1",
        LC_CTYPE = "en_US.ISO8859-1",
        LC_COLLATE = "en_US.ISO8859-1",
        LC_MESSAGES = "C",
        LC_NUMERIC = "en_US.ISO8859-1",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan. 

From those talks, here is my current understanding of the plan, in a Ward-style cartoon:

 (This is a 2 page document - description of steps is on 2nd page)

If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using.  To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.

Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.

There are several things at this point that we know we need to look into:

* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)

* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)

* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)

* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports?  Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier?  (Simulation)

* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)

* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases.  If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash.  (Simulation)

* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be.  If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI?  We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined).  (Simulation)

* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)

* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)

* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion?  PRM angular motion? ALS noise?) (Calculation)

Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon. 

Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals. 

This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .

This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.

I tried locking single arm this morning, but I was unable to because the triggers were set to lock strictly to MICH. Anchal explained this to me and helped me out. I figured this information would be useful and should be logged somewhere. In red, this is accessed through the IFO --> Configure. Choosing X Arm and Y Arm will change the triggers on the C1LSC page for the single arm locking (In the Black Box.)