40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 257 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  3043   Thu Jun 3 13:14:27 2010 kiwamuUpdateIOOmode measurement of new input optics

I corrected the sketch of the new IOO. 

The sketch in the last entry was also replaced by the new one. 

http://nodus.ligo.caltech.edu:8080/40m/3029 

Quote:

Just note that MMT1 has RoC of -5m (negative!). This means that it is a lens with f=-2.5 m,

  3044   Thu Jun 3 14:01:51 2010 kiwamuUpdateIOOmode measurement of new input optics

I checked the measured data of the mode profile which was taken on the last Tuesday.

For the vertical profile,

the plot shows a good agreement between the expected radius which is computed from the past measurement, and that measured on the last Tuesday.

However for the horizontal profile,

it looks like being overestimated. This disagreement may come from the interference imposed on the Gaussian spot as we've been worried. 

So I guess we should solve this issue before restarting this mode matching work.

 - The next step we should do are;

checking the effect of MMT1 on the shape of the beam spot by using a spare of MMT1

 

NOTE:

The expected curve in the attached figure were computed by using the fitted parameter listed on the entry 2984 .

In the calculation the MMT1 is placed at 1911mm away from MC3 as we measured.

And the focal length of MMT1 is set to be f=-2500mm.

  3059   Wed Jun 9 11:13:11 2010 kiwamuUpdateGreen Lockinglock with PDH box

A progress on the end PDH locking :

by using a modified PDH box the green laser on the X-end station is locked to the arm cavity.

So far the end PDH locking had been achieved by using SR560s, but it was not sophisticated filter.

To have a sophisticated filter and make the control loop more stable, the PDH box labeled "#G1" was installed instead of the SR560s.

After the installation the loop looks more stable than the before.

Some details about the modification of the PDH box will be posted later.

 

Although, sometimes the loop was unlocked because the sum-amp (still SR560) which mixes the modulation and the feedback signal going to the NPRO PZT was saturated sometimes.

Thus as we expected a temperature control for the laser crystal is definitely needed in order to reduce such big low frequency drive signal to the PZT.

  3065   Fri Jun 11 11:54:42 2010 kiwamuUpdateGreen Lockingend PDH with thermal feedback

A thermal feedback was installed to the end PDH locking and it works well. There are no saturations 

As I said the feedback signal was sometimes saturated at the sum-amp because the drive signal going to the laser PZT was large at low frequency (below 1Hz).

So I made a passive low pass filter which filters the signal controlling the temperature of the laser crystal, and put it before the temperature drive input.

Now the amount of the feedback signal got reduced when it is locked, and there are no saturations. It's very good.


(thermal property of the crystal) 

According to the specification sheet for the 1W Innolight, the thermal properties of the crystal are:

  Response coefficient : 3GHz/K 

  Temperature control coefficient : 1K/V

  Thermal response bandwidth: 1Hz 

 

(filter circuit and actuator response)

In order to feedback the signal blow 1Hz, a low pass fiter is needed. 

The attachment:1 shows the filter circuit I made.

Since I found that the drive input had an input impedance of 100kOhm, so I put relatively big resistors to have a moderate gain.

The expected actuator responses are also attached.

The blue curve represents the response of the PZT, the green is the thermal response including the low pass filter and the red curve is the total response composed of both the responses.

I assume that the PZT response is 1MHz/V according to Mott's measurement.

Also I assume that the thermal response intrinsically has two poles at 1Hz according to the specification listed above.

In the total response, there is a little gain reduction around 2Hz due to the cancelation of each other, but it still looks okay.

 

  3068   Fri Jun 11 14:31:04 2010 kiwamuUpdateIOOmode matching of new IOO

We decided not to care about the mode after MMT1.

So far Koji, Alberto and I have measured the beam profile after MMT1,

but we are going to stop this measurement and go ahead to the next step i.e. putting MMT2

There are two reasons why we don't care about the profile after MMT1:

     (1) it is difficult to fit the measured data

     (2) The position of MMT1 is not critical for the mode matching to the IFO.

The details are below.

 


(1) difficulty in fitting the data

The precision of each measured point looked good enough, but the fitting result varies every measurement.

The below shows the data and their fitted curves. 

 profile_MMT.png

In the label, "h" and "v" stand for "horizontal" and "vertical" respectively.

The solid curves represent the fitting results, varying by each measurement.

In order to increase the reliability of the fitting, we had to take some more data at further distance.

But we couldn't do it, because the beam radius already becomes 3 mm even at 2 m away from MMT1 and at this point it starts to be clipped on the aperture of the beam scan.

Thus it is difficult to increase the reliability of the fitting. 

Once if we put MMT2 the beam should have a long Rayleigh range, it means we can measure the profile at further distance, and the fitting must be more reliable.

 


(2) positioning of MMTs

Actually the position of MMT1 is not so critical for the mode matching. 

The most important point is the separation distance of MMT1 and MMT2.

As written in Jenne's document, if we slide the positions of MMT1 and MMT2 while keeping their appropriate separation distance, the mode match overlap still stays above 99%

This is because the beam coming from MC3 is almost collimated (ZR~8m), so the position of MMTs doesn't so matter. 

To confirm it for the real case, I also computed the mode overlap while sliding the position of MMTs by using real data. The below is the computed result.

dist_MMO.png

It is computed by using the measured profile after MC3 (see the past entry).

The overlap still stay above 99% when the distance from MC to MMT is between 1300 and 3000mm.

This result suggests to us putting MMT1 as we like.  

  3077   Tue Jun 15 16:28:32 2010 kiwamuUpdateIOOMode Profile after Mode Matching Telescope

We obtained a good mode match overlap of 99.0% for the new IOO.

And if we move the position of MMT2 by another 10 cm away from MMT1, we will have 99.6% overlap. 

Yesterday Jenne and I put MMT2 on the OMC table. MMT2 was carefully put by measuring the distance between MMT1 and MMT2.

The position looked almost the same as that drawn on the CAD design.

After putting it we measured the profile after the MMT.

 

The attached figure shows the computed mode overlap according to the fitting result while changing the position of MMT2 in a program code.

The x-axis is the position of MMT2, the current position is set to be zero. The y-axis is the mode match overlap.

Right now the overlap is 99.0% successfully, but this is not an optimum point because the maximum overlap can be achieved at x=100 mm in the plot.

It means we can have 99.6% by moving the position of MMT2 by another 10 cm. This corresponds to an expansion of the MMT length.

If this expansion is difficult due to the narrow available space in the chamber, maybe staying of MMT2 at the current position is fine.

  3088   Fri Jun 18 21:45:39 2010 kiwamuUpdateIOOMode Profile after Mode Matching Telescope (Round 2)

           [Joe, Kiwamu]

The better mode overlap of 99.3% was achieved by moving MMT2 by ~5 cm 

In the past measurement (elog entry #3077) we already succeeded in getting 99.0% mode overlap.

But according to the calculation there still was a room to improve it by moving MMT2 by 10 cm.

Today we moved MMT2 by ~5 cm which is a reasonable amount we could move because of the narrow space in the chamber.

Eventually it successfully got the better mode overlap.

So we eventually finished mode matching of the new IOOs 


(details)

     Actually moving of MMT2 was done by flipping the mount without moving the pedestal post as Koji suggested. 

At the same time we also flipped the mirror itself (MMT2) so that the curved surface is correctly facing toward the incident beam.

By this trick, we could move the position of MMT2 without losing precious available space for the other optics in the OMC chamber.

     The attached plot shows the result of the mode measurement after the MMT.

During the fitting I neglected the data at x=27 m and 37 m because the beam at those points were almost clipped by the aperture of the beam scan.

- - Here are the fitting results

w0_v             = 2.81183       +/- 7.793e-03  mm  (0.2772%)

w0_h             = 2.9089        +/- 1.998e-02  mm  (0.687%)

z_v             = 5.35487        +/- 0.2244     m   (4.19%)

z_h             = 1.95931        +/- 0.4151     m   (21.18%)

All the distances are calibrated from the position of MMT2 i.e. the position of MMT2 is set to be zero.

        In order to confirm our results, by using the parameters listed above I performed the same calculation of mode overlaps as that posted on the last entry (see here)

The result is shown in Attachement 2. There is an optimum point at x=62mm.

This value is consistent with what we did because we moved MMT2 by ~5 cm instead of 10 cm. 

 

  3092   Sun Jun 20 18:28:25 2010 kiwamuUpdateGreen LockingRe: lock with PDH box

On the wiki I summarized about the modification of the PDH box which is currently running on the end PDH locking. 

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/PDH_Universal_Box

The box was newly labeled "G1" standing for "Green locking #1".

Quote:

by using a modified PDH box the green laser on the X-end station is locked to the arm cavity.

  3105   Wed Jun 23 12:52:35 2010 kiwamuUpdatePhotosBS chamber before cleaning up

  3120   Fri Jun 25 12:09:27 2010 kiwamuUpdateComputersGPIB controller of HP8591E

I've just stolen a GPIB controller, an yellow small box, from the spectrum analyzer HP8591E.

The controller is going to be used for driving the old spectrum analyzer HP3563A for a while.

Gopal and I will be developing and testing a GPIB program code for HP3563A via the controller.

Once after we get a new GPIB controller, it will be back to the original place, i.e. HP8591E.

 

--- GPIB controller ----

name: teofila

address: 131.215.113.106

  3122   Fri Jun 25 20:32:30 2010 kiwamuUpdateGreen Lockinggreen power on the PSL table

The power of the green beam generated on the PSL table should be about 650uW in terms of the shot noise.

       One of the important parameters we should know is the power of the green beam on the PSL table because it determines the SNR.

The green beam finally goes to a photo detector together with another green beam coming from the arm cavity, and they make a beat signal and also shot noise.

So in order to obtain a good SNR toward the shot noise at the photo detector, we have to optimize the powers.

If we assume the green power from the arm is about 650uW,  a reasonable SNR can be achieved when these powers are at the same level. 

To get such power on the PSL table, a 90% partial reflector is needed for picking it off from the PSL as we expected.

 


  power dependency of SNR

      Suppose two lasers are going to a photo detector while they are beating (interfering).

The beat signal is roughly expressed by

      [signal]  ~ E1EE1 E2*,

                     ~ 2 ( PP2)½ cos (phi), 

 where  E1 and Erepresent the complex fileds,  Pand Prepresent their powers and phi is a phase difference.

This equation tells us that the strength of the signal is proportional to  ( PP2)½  .

At the same time we will also have the shot noise whose noise level depends on the inverse square route of the total power;

          [noise] ~ ( PP2)½.

 According to the equations above, SNR is expressed by

        SNR = [signal] / [noise] ~ ( PP2)½  / ( PP2)½.

If we assume Pis fixed,  the maximum SNR can be achieved when  P2 goes to the infinity. But this is practically impossible.

Now let's see how the SNR grows up as the power P increases. There are two kinds of the growing phase.

    (1) When PP1 , SNR is efficiently improved with the speed of  P2½.

    (2) But  when P>   P1 , the speed of growing up becomes very slow. In this regime increasing of  P2 is highly inefficient for improvement of the SNR.

Thus practically PP is a good condition for the SNR.

At this point the SNR already reaches about 0.7 times of the maximum, it's reasonably good.

 


 power estimation

         According to the fact above, we just adjust the green powers to have the same power levels on the PSL table.

 The table below shows some parameters I assume when calculating the powers.

ITM transmissivity @ 532nm  Ti 1.5 %
ETM transmissivity @ 532nm Te 4.5 %
Transmissivity of the arm cavity @ 532nm T_cav 74.4 %
Transmissivity of the BS @ 532nm T_BS 97 %
Transmissivity of  PR1 and SR1 @ 532nm T_PR 90%
Transmissivity of the PMC @ 1064 nm T_pmc 65 %
The power of the green beam at the end station P_end 1 mW
The power of the PSL  P_psl 2 W
Conversion efficiency of the PPKTP eta 3 %/W

         Attached figure shows a simplified schematic of the optical layout with some numbers. 

By using those parameters we can find that the green beam from the arm cavity is reduced to 650uW when it reaches the PSL table.

To create the green beam with the same power level on the table, the power of 1064 nm going to the doubling crystal should be about 150mW.

This amount of the power will be provided by putting a 90% partial reflector after the PMC.

 

  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.

  3195   Mon Jul 12 13:16:53 2010 kiwamuUpdateGreen LockingPZT feedback at X end

The feedback signal going to the laser PZT at the X end station was measured in the daytime and the nighttime.

It's been measured while the laser frequency was locked to the arm cavity with the green light.

arm_day_night.png

 

The red curve was measured at 3pm of 8/July Friday. And the blue curve was measured at 12am of 9/July Saturday. 

As we can see on the plot, the peak-peak values are followers

              daytime:  ~ 4Vpp

       nighttime:  ~1.8Vpp

It is obvious that the arm cavity is louder in the daytime by a factor of about 2.

Note: the feedback signal is sent to the PZT only above 1Hz because the low frequency part is stabilized mostly by the crystal temperature (see this entry)

Quote:

 What we care about is the peak-peak value of the PZT feedback signal measured on a scope for ~30 seconds.

  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)

 Adjustment of the PID parameters

  3243   Mon Jul 19 13:51:09 2010 kiwamuUpdateCDSTIming card at X end

[Joe, Kiwamu]

 

 The timing slave in the IO chassis on the new X end was not working with symptoms of no front "OK" green light, no "PPS" light, 3.3V testpoint not working and  ERROR testpoint bouncing between 5-6V.

We took out the timing slave from the X end IO chassis put in to the new Y end IO chassis .

It worked perfectly there. We took the working one from Y end put in the X end IO chassis.

We slowly added cables. First we added power , it worked fine and we saw green "OK" light. Then we added 1PPS signal by a fiber and it also worked.

We turned everything off and then we added 40pin IPC cable from the chassis and infiniband cable from the  computer.

When we turned ON it we didn't see the green light.

This means something in the computer configuration might be wrong not in the timing card, we now are trying to make contact with Alex.

We are comparing the setup of the C1SCX  machine and the working C1ISCEX machine.

  3254   Tue Jul 20 23:52:36 2010 kiwamuUpdateVACupdate: slow vent has started

The vent is still going on. At this moment the pressure inside of the chambers is about 630 Torr.

Koji and I have replaced the 2nd instrument grade compressed air cylinder by the 3rd cylinder around 9 pm.

So far the vent speed has been nicely kept at about 1 Torr / min.

  3259   Wed Jul 21 12:41:31 2010 kiwamuUpdateVACvent finished

The vent has been finished successfully in this morning.

The vent was finished successfully this morning.

  3268   Thu Jul 22 14:07:20 2010 kiwamuUpdatePSLPSL front end machine

It looks like something wrong happened around the PSL front end.  One of the PSL channel, C1:PSL-PMC_LOCALC, got crazy. 

We found it by the donkey alarm 10 minutes ago.

The attached picture is a screen shot of the PMC medm screen.

The value of C1:PSL-PMC_LOCALC ( middle left on the picture ) shows wired characters. It returns "nan" when we do ezcaread.

Joe went to the rack and powered off / on the crate, but it still remains the same. It might be an analog issue (?)

  3278   Fri Jul 23 15:54:38 2010 kiwamuUpdateSUSPRM and TT installed

[ Jenne, Koji and Kiwamu]

 We have installed the PRM and the tip-tilt (TT) in the BS chamber.

We have started the in-vac work which takes about a week.

Today's mission was dedicated to installing the PRM and two TTs, one for the PRC and the other for the SRC, on the BS table in the chamber.

The work has been smoothly performed and we succeeded in installation of the PRM and a TT for the PRC.

But unfortunately the other TT got broken during its transportation from Bob's clean room.

 


 (what we did)

 (1) opened the light door of the BS chamber.

 (2) moved the BS tower to the right position according to Koji's layout drawing.

    - Prior to this work we screwed down the earthquake stops so that the mirror is fixed to the tower. Also we disabled the watchdog.

    - When moving it we used an allen key as a lever with an screw as a fulcrum. This idea was suggested by Jenne and it really worked well.

     The reason why we used this technique is that if we slide the tower by hands the tower can't go smoothly and it may sometimes skips.

     After that we checked the postion from some reference screw holes by using a caliper and we made sure that it was on the right position.

 (3) removed all of the square-shaped mirrors.

    - After this removal the mirrors were wrapped by aluminum foils and put in a usual clear box.

 (4) removed some optics because they had made the chamber space crowded.

    - These were also wrapped by aluminum foils and put in the box. Later we will put them back to the BS table.

 (5) brought the PRM tower from the Bob's clean room  and put it on the BS table.

   - The position of the PRM were coarsely aligned since we still don't have any 1064 beam going through the PRM.

 (6) brought two TTs also from Bob's clean room and put one of the TTs on the table.  

   - The position of the installed TT was coarsely adjusted. 

   - After we brought them we removed the aluminum foils covering the TTs and we found the wire of a TT got broken.

     It may have been damaged during its transportation from Bob's room because it was fine before the transportation.

 (7) closed the door

 

(the next things to do)

  * Installation of the OSEMs to the PRM

  * Installation of the pick off mirror and its associated optics

  * Arrangement of  the pzt mirror

 

  3281   Fri Jul 23 18:55:25 2010 kiwamuUpdateSUSPRM and TT installed

I updated the last entry.

  3292   Mon Jul 26 12:31:36 2010 kiwamuUpdateCDSfront end machine for the X end

A brief report about the new front end machine "C1ISCEX" installed on the X end (old Y end).

Still the DAC is not working.

 

- Timing card

It's working correctly.

The 1PPS clock signal is supplied by the vertex clock distributer via a 40m long fiber.

 

- ADC

All 16 channels are working well.

We can see the signals in the medm screen while injecting some signals to the ADC by using a function generator.

 

-DAC

All 16 channels do NOT work.

We can not see any signals at the DAC SCSI cable while digitally injecting a signal on the medm screen.

  3294   Mon Jul 26 20:12:18 2010 kiwamuUpdateSUSOSEMs on PRM

 [Alberto and Kiwamu]

We installed the OSEMs to the new PRM.

As I wrote down on the elog (see here)  today's mission was to install the OSEMs to the PRM.

After putting them on the tower we adjusted the readout offsets by sliding the OSEMs so that they can stay in the linear sensing ranges. 

Now all of the OSEMs have almost good separation distances from the PRM.

In the attached picture you can see the OSEMs installed on the PRM tower ( middle: PRM tower, left: BS tower)


(what we did)

 1. moved the PRM tower close to the door so that we could easily access the PRM.

 2. leveled the table by putting some weights and confirmed the level by a  bubble level tool.

     - We must level the table every time when we set / adjust any OSEMs,  otherwise the readout voltages of  the OSEMs vary every time due to the tilted table.

 3. released the PRM by loosing the earthquake stops

 4. put the OSEMs with approximately right separation distances from the PRM.

      -  At this phase we can see the readout of the OSEMs, which were oscillating freely because we still didn't enable the damping.

        -  The OSEM positions were checked by looking at useful notes on the wiki (see here).

 5. turned on the damping servo of the OSEMs

       - Without changing any gains, it worked well. 

      - Then we could see stable readouts of the OSEMs which didn't show any oscillations in turn because of the damping.

 6. checked the level of the table again

 7. set each of the OSEM readouts to the half of its maximum value by sliding their positions slightly.

      - The readout offsets were at almost the half value within +/- 100 mV accuracy (this was the best accuracy we could adjust by our hands)

 8. screwed down the earthquake stops to lock the PRM.

      - Now the damping is off.

 9. closed the door

 


(to be done)

 *  Putting the PRM tower back to the designed place

 *  Installation of the pick off mirror

 *  Arrangement of the PZT mirror

  3302   Tue Jul 27 21:38:21 2010 kiwamuUpdateSUSinstallation of in-vac optics

[Alberto and Kiwamu] 

We put the PRM back approximately on the right place.

Also we installed the pick off mirrors and the PZT mirror.

Since the main beam after the MMT still has not been well aligned , we put those optics approximately on the right place. A fine alignment of those will be performed later

The offsets of the PRM OSEMs are still kind of okay.

The next things we have to do are

(1) installation of a tip-tilt for the SRC, (2) alignement of those optics by using the main laser and (3) installation of the green optics.

 


what we did

 1. put the PRM back to the designed place.

     - After this, we released the PRM from the earthquake stops and turned on the damping servo.

      - Now the earthquake stops are at a distance of approximately 1mm from the PRM. These separation distances were tuned by counting the turn number when we screwed them off.

 2. leveled the table

 3. adjusted the separation distances from the PRM to the OSEMs.

    - The table below summarize the current OSEM offsets. LL may still need to be adjusted.

  Max./2 [V]

measured offsets [V] 

after adjustment 

discrepancy [%]
UL 0.874 0.928 + 6.2 %
UR 0.848 0.777 - 8.4 %
LL 1.038 0.796 - 23 %
LR 0.967 0.845 -12 %
SD 0.840 0.745 - 11%

 4. put the PZT mirror on the right place.

      -  This PZT mirror is going to be used for beam steering after the MMT.

 5. put the pick off mirror and its associated optics.

     -  This pick off mirror provides with the beam eventually going to IP_ANG and IP_POS.

 


current status

The table below shows the current status of the installed optics.

Red letters represent the incomplete states which still need further adjustment.

Blue letters represent the complete status which don't need any further adjustment.

 

name on the drawing

(see the wiki ) 

status
BS tower BS well aligned by a caliper
PRM tower PRM approximately aligned. LL OSEM
TIp-TIlt PR3 approximately aligned
Pick off Window (wedged) IPPO

wedge is correctly set (fat part is on the left).

 approximately aligned

steering mirror IPPOSSM1 mirror is correctly flipped. approximately aligned
steering mirror IPANGSM1 mirror is correctly flipped. approximately aligned
steering mirror IPANGSM2 approximately aligned
pzt mirror SM2 approximately aligned

 

  3313   Wed Jul 28 17:32:37 2010 kiwamuUpdateSUSinstallation of in-vac optics

[Jenne, Koji and Kiwamu]

We have installed two steering mirrors and the green periscope.

Also we took the tip-tilt out from the chamber for characterization.


1. installed two steering mirrors

     - We installed IPPOSSM2 and IPPOSSM3.

    - Because IPPOSSM2 is a new 0 deg mirror so we newly engraved "Y1-LW1-2037-1064-0-AR" on the mount and deleted  the previous enegravement.

      For the 0 deg mirror itself, it had already been engraved by Koji. The wedge was horizontally aligned.

      Now IPPOSSM2 is off from the right place by 5 inch for convenience because it may touch our stomachs when we try to lean further into the chamber.

    - IPPOSSM3 is a 45 deg mirror which used to be in the chamber and had been already correctly engraved, so we didn't have to newly engrave on it. Now it's on the right place approximately.

 2. put three oplev mirrors

      - Two of them are approximately on the place, but one which is going to be on the center of the table is not on the place because there is a cable distributer sitting exactly there.

 3. installed the green periscope

      - Both the mirrors and the periscope were correctly engraved.

     - Now it's sitting on the right place approximately.

 4. removed the tip-tilt 

      -  This tip-tilt is now in the clean room and the mechanical mode will be characterized. 

 


 The next things to be done

* Cross-coupling evaluation of the PRM OSEMs

* Rearrangement of the cable distributer panel.

   - In order to do this we have to pull its cables which are attached to the stack.

* Installation of three green steering mirrors

   - All of them need to be engraved.

* Installation of two tip-tilt

  - One for the SRC and the other for the PRC

  3315   Thu Jul 29 10:39:43 2010 kiwamuUpdateSUSRe: installation of in-vac optics

I updated the last entry about the in-vac work (see here)

  3316   Thu Jul 29 11:33:38 2010 kiwamuUpdateCDSPCI5565 driver for RFM

 Yesterday I installed a PCI-5565 driver on new C1SUS in order to test the RFM.

Since the RFM on the new CDS is not working, we had to test it by using some softwares.

I installed a driver for PCI-5565 on C1SUS and ran a test script wich is one of the packaged test scripts in the driver.

So far the RFM card on C1SUS looked correctly mounted, but I didn't check the memory location and the sending/ receiving functions.

This test will continue sometime on August because right now the RFM test is not higher priority.

 


Some notes:

Driver package

      Alex suggested to use a driver package for PIC-5565 called "RFM2g Linux 32/64-bit PCIE/PCI/PMC driver for x86 kernels R7.03" , which is available on  this web site.

And the package contains some useful test scripts which exactly we want to run for RFM test.

 

Installation and test script

      I downloaded the driver and put it on C1SUS.  

After doing usual "unzip", "tar" and "make" things, I ran one of the test script called "rfm2g_util".

Currently it lives under /home/controls/Desktop/162-RFM2G-DRV-LNX-R07_03-000/rfm2g/diags/rfm2g_util on C1SUS.

It invokes an interactive shell and firstly it asks the mount point of the RFM card.

I eventually found the card was mounted on #1 which means the card is correctly mounted.

 

Some detail procedures will be summarized on the wiki later.

  3317   Thu Jul 29 12:13:28 2010 kiwamuSummaryCDSnear term plan

 [Joe and Kiwamu]

current_setup_v2.png

  3327   Thu Jul 29 22:58:25 2010 kiwamuUpdateGreen Lockingwaist positon of Gaussian beam in PPKTP crystals

- As you said, I just calculated the waist position in the crystal because the speed of light changes in a medium and eventually the waist position also changes.

- Yes, I did. Once you get a beam with the right waist size, you just put your crystal at the waist position with the offset.

  In fact you don't have to think about the rayleigh range inside of the crystal because what we care is the waist size and it doesn't change.

Quote:

 If I understand your elog, you are just calculating the the offset in position space that you get by having a refractive index.

Did you end up changing the mode matching so that the rayleigh range (which changes with refractive index) was confocally focused inside the crystal (e.g. Zr = 15 mm?

  3330   Fri Jul 30 09:51:58 2010 kiwamuUpdateGreen LockingRe: waist positon of Gaussian beam in PPKTP crystals

Okay, I guess I understand what you want to know. I did the following steps.

1. calculated the conversion efficiency as a function of the waist size. I found w~50um was the optimum waist.

  Note: the confocal relation Zr = pi * wo^2/(lamba/n) = L/2  gives us almost the same optimum waist. 

elog #2735

efficiency_waist_edit.png

  2.  Did mode matching to get w=50um

elog #2959

elog #3188

PPKTPmode.png

PSL_doubling.png

  3. calculated the offset

elog #2850

mode_in_PPKTP.png 

 4. Moved the ovens

 

Quote:

I thought we cared about satisfying the confocal focusing parameter, that is to say we want to set Zr = 2L_crystal. If Zr changes inside the crystal, this is the number we care about..isn't it NOT the waist size, but the rayleigh range we care about? I am not entirely sure what youre response is saying you did...

  1. Calculate Zr = pi * wo^2/(lamba/n)
  2. Do mode matching to get this wo in free space
  3. Calculate the offset you need to move the oven by using n
  4. Move hte ovens

OR

  1. Calculate Zr = pi*wo^2/(lamba)
  2. Do mode matching to get this in free space
  3. Calculate the offset you need to move your ovens using n
  4. Move your ovens

I guess the waist size would also let me know - are you using 69 um or 53 um waist size?

 

  3340   Sat Jul 31 10:12:05 2010 kiwamuUpdateVACRe: How to stop and start slow pumpdown

I resumed the pumping down. It started from 9:55 am.

  3341   Sat Jul 31 14:59:33 2010 kiwamuUpdateVACRe: How to stop and start slow pumpdown

I stopped the pumping at 14:50 pm because I was going back home. I did the same procedure as Koji wrote down (see here).

The P1 pressure reached 32 Torr.

Koji will take over the pumping shift tonight. 

  3353   Tue Aug 3 11:17:10 2010 kiwamuUpdateCDSDiagrams for Cables needed for CDS test

Current Wiring Setup for the Suspension Controls

sus_wiring.png

New Wiring Plan for the Suspension Controls  with the New CDS  

sus_new_wiring.png

Missing Stuff for the CDS test

Ideally we can reuse the existing cables, but some of them may not be long enough for the new wiring.

The diagram below shows extremely non-ideal case.

sus_missing_stuff.png

Some more information will be summarized on the wiki later.

 

  3405   Thu Aug 12 11:19:04 2010 kiwamuUpdateCDScurrent status

Current status of the new CDS test (summaries can be found on the wiki)

- Cables 

  All the necessary cables are in our hands, such as SCSIs, 37 pin D-sub and 3 pin power cables.

  With a big help from Jenne and Koji, we made 37 pin F/M cables and 3 pin power cables on the last Tuesday.

  Now all the cables are connected to the machines except for the 3 pin power cables.

  To install the power cables I will switch off Sorensens at new 1X5  for a minute.

 

- Suspension model file 

  The model file named C1SUS was made and I succeeded in compiling and building it. So it is ready for the test.

  But some medm screens look like not correctly complied.

  For example the channel names which are listed on C1SUS_MONITOR_ADC0.adl aren't correctly assigned.

 

- ADCs 

 All the ADC channels are working. Also the channel assignments are correct.

 I checked all the ADC channels if it was working while I ran the front end realtime code C1SUS.

 By injecting a signal from a function generator directly to the SCSIs, I could clearly see the numbers hopping on medm screens.

 

- DACs 

  None of them are working although the computer can recognize that all three DAC cards are mounted.

  I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry ) 

  I have to fix it anyhow because the DACs are very necessary part for this damping test.

 

- Binary Outputs

  They didn't work at all. Even the computer didn't recognize the binary output cards.

  I think I should put some magical components on the model files.

 

- Conversion of the filter coefficients 

  The conversion of the filter coefficients has been doen yesterday.

  It looks running well because I can load and unload these filters on medm screens.

  I manually copied the filter coefficients from the current suspension filter file to that of new filter file.

 The current file can be found under /cvs/cds/caltech/chans/,  and the new one is under /cvs/cds/rtcds/caltech/c1/chans


Suspended works

   - Binary Outputs

   - simlink realtime model with the new CDS PARTS ( see the notice from Joe )

 

To be done

   - let DACs work

   - damping tests

 

  3407   Thu Aug 12 11:59:31 2010 kiwamuHowToCDSset up ntp daemom

(sad story)

When I was working on a new front end machine c1sus, I found that make command didn't run and gave the following message.

      "make:warning:clock skew detected.Your build may be incomplete"

This was caused by a clock difference between the nfs (nodus) and the terminal machine (c1sus).

I had to set up ntp daemon to synchronize them. Here is a procedure to set up it

 


(how to)

- log in to a front end machine

              ssh c1sus

- enable the ntp daemon

              sudo ntsysv

- configure the ntpd

              vi (emacs)  /etc/ntp.conf

- below is the contents I wrote on ntp.conf

             server 192.168.113.200  minpoll 4 maxpoll 4 iburst

      driftfile /var/lib/ntp/drift

 - let the daemon run
            sudo service ntpd start
- check it if it's running
             ntpq -p
  3414   Thu Aug 12 18:30:08 2010 kiwamuUpdateCDSRe: current status

Yes.  

The medm screen C1SUS_GDS_TP.adl showed some numbers which correspond to that I wrote  on the outputs.

But I still could not get any physical voltage coming from the DACs.

Quote:

 When you write outputs on DAC_0 or DAC_1 is the C1SUS GDS TP screen showing anything? 

  3456   Mon Aug 23 15:24:24 2010 kiwamuConfigurationSUSwatchdogs off

For the new CDS test, I turned off the watchdogs for PRM, SRM, BS, ITMs and MCs.

I will restore these watchdogs after several hours from now.

 

  3457   Mon Aug 23 18:18:22 2010 kiwamuConfigurationSUSRe:watchdogs off

Now watchdogs are back.

The suspensions are well damped.

  3458   Mon Aug 23 19:55:31 2010 kiwamuUpdateCDSsome progress

 {Joe, Kiwamu}

Today we did the following works in order to get ready for the new CDS test.

 - solved the DAC issue.

 - checked all the channel assignments of the ADC and the DAC.

 - preparation for modification of the AA filter chassis. 

 - checked DAC cable length.

 - connected the power cables of the BO boards to Sorensens.

 

Although we performed those works, we still couldn't do the actual damping tests.

To do the damping tests, we have to modify the AA chassis to let the SCSIs go in it. Now Joe and Steve are working for this issue.

 Also we found that we should make three more 37pin Dsub - 40pin IDC cables.  

But this is not a critical issue because the cables and the connectors are already in our hands. So we can make them any time later.

 

(Notes)


 (DAC issue)

  Now all the DAC channels are working correctly.  

There had been a combination of some issues.

  When I posted the elog entry last time, the DAC was not working at all (see here).

 But in the last week Joe found that the IO process didn't correctly run. He modified the IOP file named 'c1x02.mdl' and ran it after compiling and installing it.

 This made the situation better because we then were able to see the most of the signals coming out from the DACs.

     However we never saw any signals associated with SIDE_COILs.

 We checked the DAC cards, their slots and their timing signals. But they all were fine.

At that time we were bit confused and spent a couple of days because the DAC signals appeared at a different slot some time after we rebooted the computer. Actually this issue still remains unsolved...

Finally we found that SIDE_COILs had an input matrix which didn't show up in the medm screen.

We put 1 in the matrix and we successfully got the signal coming out from the DAC.

 

(channel assignments)

We checked all the channel assignments of the DACs and the ADCs.

All the channels are assigned correctly (i.e. pin number and channel name).

 

(AA chassis)

 We have been planning to put the SCSI cables into the AA chassis to get the ADC signals.

As Joe said in the past entry (see here) , we need a modification on the AA chassis to let the SCSIs go in it.

Joe and Steve will put an extension component so that we can make the chassis wider and eventually SCSI can go in.

 

 

(DAC cable length)

 In the default plan we are going to reuse some DAC cables which are connected to the existing systems.

To reuse them we had to make sure that the length of those cables are long enough for the new CDS.

After stopping the watchdogs, we disconnected those DAC cables and confirmed they were long enough.

Now those cables are connected to the original place where they have been before.

The same test will be performed for the binary outputs.

 

(power cables to Sorensens)

 Since the binary output boards need +/- 15V power, we hooked up the power cables to Sorensens sitting on the new 1X5 rack.

After cabling them, we turned on the power and successfully saw the green LEDs shining on the back panel of the boards.

  3460   Mon Aug 23 22:11:52 2010 kiwamuUpdateTreasureRe:Seriously?

Woops, I am sorry about that. I've just cleaned them up.

Quote:

Bad CDS team. Bad. 

  3474   Thu Aug 26 17:10:26 2010 kiwamuUpdateCDSnew CDS test

[Joe, Kiwamu] 

Woooo Yeaaaah

With the new CDS we succeeded in damping of PRM and BS !!

  3478   Fri Aug 27 13:41:02 2010 kiwamuUpdateSUSfix watchdogs

 [Joe, Kiwamu]

We found that the vertex watchdogs were not correctly running.

After I powercycled c1susaux, the problem was fixed successfully.

 

The symptom: the watchdogs didn't disable the coil signal even when PD_VAR signals went larger than the threshold values PD_MAX_VAR.

Also we replaced the label by the correct name "C1SUSAUX" on a tag which was tied to the front end machine mounted on the new 1X5 rack.

  3479   Fri Aug 27 14:03:43 2010 kiwamuUpdateCDSWatch dogs for Vertex optics turned off

For a futher damping test, I again turned off the vertex optics watchdogs temporarily, including BS, ITMs, SRM, PRM, MCs.

  3480   Fri Aug 27 17:27:41 2010 kiwamuUpdateCDSnew CDS test

 { Joe, Kiwamu }

Yes !

We now are damping all of the vertex suspensions including PRM, BS, ITMs and MCs by the new CDS

( Note that we are not damping SRM because we don't have it in the chamber. )


 (things to be done)

- Make the binary outputs work.

- Make DTT work

  3486   Mon Aug 30 11:41:34 2010 kiwamuUpdateComputersdisable sendmail and isdn

 {Rana and Kiwamu}

Yesterday we disabled the sendmail daemon and the isdn daemon on allegra because we don't need these daemons always running.

 

-   How to disable/enable daemons:

sudo ntsysv

  3490   Mon Aug 30 22:45:49 2010 kiwamuUpdateCDSbinary outputs for the new CDS

{ Joe and Kiwamu }

Today we made some efforts to get the binary outputs (BOs) working.

They still are not working but the situation is getting better.

    So far the BO cards were not recognized by any realtime codes when we ran the codes on the new front end machine C1SUS.

We put some printk commands in an initialization code like Yoichi did (see this entry) to confirm if the initialization of the BOs properly happens or not.

Then we found that we had to put the BO modules also in an IOP model file which controls all the ADCs and the DACs.

We put the BO modules in the IOP file and then BOs started being recognized by the IOP, however they still are not fully recognized by the realtime control process.

We continue this work...

 

[Some notes]


[front end code]

First of all we looked at the front end c-code c1sus.c living under /cvs/cds/calech/cds/advLigoRTS/src/fe/c1sus/.

It was okay because there was a proper BO statement like

CDS_CARDS cards_used[] = { {CON_32DO,0}, {CON_32DO,2}};

 

[initialization code]

 There is an initialization code called map.c living under /cvs/cds/calech/cds/advLigoRTS/src/fe.

This code is complied when we do the make commands as described on the wiki.

Eventually the initialization code is executed only when the IOP starts up. This happens when we type startc1x02 at /cvs/cds/rtcs/caltech/c1/script/.

 

[printk statments]

   We made a backup file named map_20100830.c.back for map.c. Then we added to map.c some pintk statements in a while loop which looks for available BOs.   

After running the make commands for the IOP file and startc1x02, we basically can check the results of those printk statements by using dmesg.

We found that map.c was running correctly because  map.c went in the while loop 4 times which is exactly the same number as the BOs we put in the model file.

However the code failed to install the BOs each time.

 

[BO modules in IOP file]

  Joe pointed out the failure in map.c was caused by lack of the BO modules in the IOP file c1x02.mdl.

Indeed putting the BO modules in the IOP fixed the problem. 

Another thing we found at this time is that there is a maximum number of BOs we can put in a model file.

The maximum number is 4, which is not enough for us because we need to put 5 of them including a 16bit BIO and four 32bit BOs.

Now Joe is asking to Alex about this issue.

Anyway now the IOP can recognize the BO cards, this fact can be found if you look at the log file /cvs/cds/rtcds/caltech/c1/target/c1x02/logs/log.txt.

The log file saids "3 Contec 32ch PCIe DO cards found", which is a good sign. 

 

[BO modules in realtime code] 

Although the IOP started seeing the BO cards, the realtime code c1sus still didn't fully recognize the BO cards.

If we look at the log file log.txt at /cvs/cds/rtcds/caltech/c1/target/c1sus/logs/, there is an evidence that the code found some cards.

The log file saids  

   Model 6 = 10

   Model 7 = 4

   Model 8 = 4

   Model 9 = 4

   Model 10 = 0.

 It looks like these corresponds to the BO cards.

So the code found some cards, but doesn't know what they are.

We need few more debugging for the BOs... 

  3492   Tue Aug 31 02:50:45 2010 kiwamuUpdateCDSvertex suspensions controlled by the new CDS

I plugged the new CDS to the vertex suspensions. 

Now PRM, SRM, ITMs, MCs and BS are under the control of the new CDS. 

From now on we will never go back to the old system.

 

Though,  the watchdogs are still running on the old system.

So if you need to turn on/off the watchdogs, you can simply enable/disable them from the usual medm screens.

  3494   Tue Aug 31 11:50:14 2010 kiwamuUpdateCDSmaximum number of BIOs

 { Joe and Kiwamu },

 Now we  are able to compile the model file with more than 4 binary input/outputs (BIOs).

 As I wrote in a past entry (see here), the number of the BIOs was limited to 4, which is not enough for us.

 

  We modified a header file called "cdsHardware.h"  in order to allow model files having more than four BIOs.

The header file lives under /cvs/cds/caltech/advLigoRTS/src/include/drv/.

There was a sentence defining the maximum number in the file:

 #define MAX_DIO_MODULES         4.

We changed this to

 #define MAX_DIO_MODULES         8.

  3544   Wed Sep 8 11:46:53 2010 kiwamuUpdatePSLupdate of the layout

I put some green stuff on the layout drawing.

I continue to refine the positions of these stuff.

 

Notes :

 1. I flipped the reference cavity. So now the cavity is sitting on the left hand side of the layout.

  2. I removed the ISS stuf. We should think about where ISS should be.

Quote:

Also, Kiwamu has modified the layout drawing to add the green PLL stuff. This has collapsed the reference cavity's wave function placing it close to its original position.

WE (maybe Valera and Steve) can now put the reference cavity back on the table.

 

  3545   Wed Sep 8 11:56:24 2010 kiwamuSummaryCDSSeptember CDS test plan

 Joe and Kiwamu

We discussed about our CDS plan for this September. The summary of the plan and "to do list" are now on the wiki page;

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/CDS/September_CDS_plan

 

  Basically there are three major missions that we will do in this month;

1. complete damping of the vertex suspensions
2. Preparation for Green locking
3. Development of Simulated Plants
 

 We also try to keep updating the wiki page.

  3548   Thu Sep 9 05:58:04 2010 kiwamuUpdatePSLmode matching from PMC to IMC

 I started mode matching of the beam going to IMC. The work is still going on.

According to Rana's calculation (see here), I put the first lens (f=200mm) in between two steering mirrors after PMC.

The distance from PMC to the first lens was adjusted by using a metal ruler.  So I believe the accuracy is something like 1mm.

I aligned the beam path going through the broadband EOM and the mode matching lenses.

 

  I could find the optimum position for the second lens  (f=-150mm) by sliding the position of the lens and measuring the mode after it.

But the optimum position looked a bit far from the EOM. It's off by about 3-4 inch from the designed position.

Somehow I feel that the beam before the second lens goes with a smaller divergence angle than that of designed.

So tomorrow I am going to restart the work from checking the mode before the second lens.

Maybe at first I should measure the mode without going through the EOM because it changes the waist position and makes the system not straightforward.

ELOG V3.1.3-