40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 47 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  3232   Thu Jul 15 19:27:04 2010 ranaSummaryPSLRC trend after the insulation removal

Untitled.png

As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:

a.pngb.png

I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).

As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured.

  3247   Mon Jul 19 21:47:36 2010 ranaSummaryDAQDAQ timing test

Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:

I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.

The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.

This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).

  3260   Wed Jul 21 15:43:38 2010 MeganSummaryPSLCopper Layer Thickness on the Reference Cavity

Using the equation for thermal resistance

Rthermal = L/(k*A)

where k is the thermal conductivity of a material, L is the length, and A is the surface area through which the heat passes, I could find the thermal resistance of the copper and stainless steel on the reference cavity. To reduce temperature gradients across the vacuum chamber, the thermal resistance of the copper must be the same or less than that of the stainless steel. Since the copper is directly on top of the stainless steel, the length and width will be the same for both, just the thickness will be different (for ease of calculation, I assumed flat, rectangular strips of the metal). Assuming we wish to have a thermal resistance of the copper n times less than that of the stainless steel, we have

RCu = RSS/n

or

L/(kCu*w*tCu) = L/(kSS*w*tSS*n)

so that

tCu/tSS = n*kSS/kCu

We know that kSS = 401 W/m*K and KCu = 16 W/m*K, so

tCu/tSS = 0.0399*n

By using the drawings for the short reference cavity vacuum chamber (the only one I could find drawings for online) I found a thickness of the walls of 0.12 in or 0.3048 cm. So for the same thermal resistance in both metals, the copper must be 0.0122 cm thick and for a thermal resistance 10 times less, it must be 0.122 cm thick. So we will have to keep wrapping the copper on the vacuum chamber!

  3299   Tue Jul 27 16:03:36 2010 ranaSummaryDAQDAQ timing test

Quote:

Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:

I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.

The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.

This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).

 This is the 0.3 mHz BW spectrum of this test - as you can see the apparent linewidth (assuming the width is all caused by the DAQ jitter) is comparable to the BW and therefore not resolved.

Basically, the Hanning window function is not sharp enough to do this test and so I will do it offline in Matlab.

Attachment 1: Untitled.png
Untitled.png
  3300   Tue Jul 27 16:33:50 2010 KojiSummaryGeneralHigh school students tour

Jenne made the 40m tour for the annual visit of 30-40 students.

c.f.

Tour 2009 http://nodus.ligo.caltech.edu:8080/40m/1717

Tour 2008 http://nodus.ligo.caltech.edu:8080/40m/737

 

Attachment 1: IMG_2657.jpg
IMG_2657.jpg
  3317   Thu Jul 29 12:13:28 2010 kiwamuSummaryCDSnear term plan

 [Joe and Kiwamu]

current_setup_v2.png

  3318   Thu Jul 29 12:31:09 2010 KojiSummaryGeneralLab Schedule

July
29 Thu BS chamber work: Move cable towers / green steering mirrors / (2 TTs with TT charactrization) / Put the heavy door by 5PM.
30 Fri Pumping down
31 Sat WFS work by Nancy

Aug
1 Sun - 5 Thu WFS work by Nancy
5 Thu PSL Table prep
6 Fri PSL Table prep / Likely to shut down the PSL

9 Mon PSL Table prep / shutting down of the PSL (optional)
10 Tue PSL box Frame lifting
12 Thu PSL table tapping

16 Mon - 17 Tue concrete pouring preparation
19 Thu - 23 Fri Tripod placement
24 Tue - 26 Thu concrete pouring

Attachment 1: PSL_work_schedule.pdf
PSL_work_schedule.pdf
  3324   Thu Jul 29 20:43:32 2010 GopalSummaryOptic StacksModeling Tips and Tilts

I have discovered a method of completely characterizing the 6x6 response of all six types (x-,y-, and z- translational/rotational) of oscillatory disturbances at the base of the stack.

  • "Tipping" drives are trivial, and simply require a face load in the appropriate direction.
  • "Tilting" drives could use a torque, but I am instead implementing multiple edge loads in opposing directions to create the appropriate net curl. This curl will be kept constant across the three axes for sake of comparing the resulting transfer functions.
  • "Tipping" responses are once again trivial, and merely require the displacement vector of the top center coordinate to be recorded.
  • "Tilting" responses require the normal vector to be recorded and manipulated to produce the angular coordinates (assuming right-handed coordinate system):
    • θx = tan-1(x/z)
    • θy = tan-1(y/z)
    • θz = tan-1(y/x)

The first three concepts have been confirmed through simulations to produce correct transfer functions. The last test seems to be producing some problems, in that the vector normal to the equilibrium position (an obvious and useless piece of information) is sometimes given instead of the vector normal to the position of maximum displacement. This means that, as of now, I have the capability of measure the half of the complete 6x6 matrix of transfer functions in the coming weeks. The first three of eighteen transfer functions are attached below and will be included in my progress report.

XTrans_XDisp.pngYTrans_XDisp.pngZTrans_XDisp.png

  3339   Sat Jul 31 04:03:11 2010 GopalSummaryOptic StacksComplete Displacement Translational Transfer Function Matrix

Over the past 36 hours, I've run full-fledged FDAs on KALLO.

The transfer functions for translational drives and responses are neatly described by the attached transfer function "matrix."

Progress_Report_2.png

Next steps:

1) Extend the 3x3 analysis to include tilts and rotations in a 6x6 analysis.

2) Figure out how to do the same types of tests for phase instead of displacement.

  3345   Sun Aug 1 21:04:45 2010 ranaSummaryComputer Scripts / ProgramsMC Autolocker fixed

Someone had left a typo in the MC autolocker script recently while trying to set the lock threshold to 0.09. As a result, the autlocker wouldn't run.

I repaired it, made a few readability improvements, and checked in the new version to the SVN. If you make script changes, check them in. If you think its too minor of a change for a SVN checkin, don't do it at all.

  3346   Sun Aug 1 21:40:27 2010 ranaSummaryPSLFSS: SLOWDC response

I bet you thought that the NPRO slow actuator response could be well represented by a pole at ~0.1 Hz? Well, that's just what they want you to believe.

I attach the response measured in FSS-FAST (with no feedback to the SLOW actuator) when the SLOW is given a step. As you may remember from

kindergarten, the response of a single pole low pass should just be an exponential. Clearly, there's more here than 1 pole.

 I also inserted a factor of 0.01 in the FSSSlowServo code so I could make the gain sliders have reasonable values (they used to all be ~1e-3). The SVN and the MEDM snapshot are updated.

Attachment 1: Untitled.png
Untitled.png
  3378   Fri Aug 6 17:47:36 2010 steveSummaryGeneralcranes load tested at 1998 lbs

Quote:

Quote:

Quote:

The guy from KroneCrane (sp?) came today and started the crane inspection on the X End Crane. There were issues with our crane so he's going to resume on Monday. We turned off the MOPA fur the duration of the inspection.

  1. None of our cranes have oil in the gearbox and it seems that they never did since they have never been maintained. Sloppy installation job. The crane oiling guy is going to come in on Monday.
  2. They tried to test the X-End crane with 2500 lbs. (its a 1 ton crane). This tripped the thermal overload on the crane as intended with this test. Unfortunately, the thermal overload switch disabled the 'goes down' circuit instead of the 'goes up' circuit as it should. We double checked the wiring diagram to confirm our hypothesis. Seems the X-End crane was wired up incorrectly in the first place 16 years ago. We'll have to get this fixed.

The plan is that they will bring enough weight to test it at slightly over the rating (1 Ton + 10 %) and we'll retry the certification after the oiling on Monday.

 The south end crane has one more flaw. The wall cantilever is imbalanced: meaning it wants to rotate south ward, because its axis is off.

This effects the rope winding on the drum as it is shown on Atm2

Atm1 is showing Jay Swar of KoneCrane and the two 1250 lbs load that was used for the test. Overloading the crane at 125% is general practice at load testing.

It was good to see that the load brakes were working well at 2500 lbs. Finally we found a good service company! and thanks for Rana and Alberto

for coming in on Saturday.

 Jeff Stinson, technician of KoneCrane inspected the south end crane hoist gear box. This was the one that was really low on oil. The full condition require

~ 950cc of EPX-7 (50-70W) high viscosity gear oil. The remaining 120 cc oil was drained and the gear box cover was removed. See Atm 1

He found the gear box, load brake and gearing in good condition. The slow periodic sound of the drive was explained by the split bearings at Atm 3

The Vertex and the east end crane gear boxes needed only 60 cc oil to be added to each Atm 4 and their drives were tested.

Conclusion: all 3 gear boxes and drives are in good working condition.

Tomorrow's plan: load test at 1 ton and correct-check  3 phase wiring.

 Atm1, service report: load test were performed at max horizontal reach with 1998 lbs ( American Ton is 2000 lbs)

          Vertical drives and brakes worked well. The 5 minutes sagging test showed less than 1 mm movement .

          The wiring is correct. Earlier hypothesis regarding the wiring ignored the mechanical brake action.

Our cranes are certified now. Operator training and SOP is in the work.

Vertex Folding I -beam will get latch-lock and the south end I-beam will be leveled.

Atm2, south end

Atm3, east end

Atm4, folding crane at ITMX at 14 ft horizontal reach

Attachment 1: 0.9ton.PDF
0.9ton.PDF
Attachment 2: P1060523.JPG
P1060523.JPG
Attachment 3: P1060532.JPG
P1060532.JPG
Attachment 4: P1060541.JPG
P1060541.JPG
  3382   Sat Aug 7 10:47:38 2010 KojiSummaryelogelog restarted / source of the trouble eliminated

Nancy notified me that the elog crashed. It was fixed.


I restarted elog, but it kept crashing. Some of the entries on Aug 6th caused the trouble.

I tried to refresh the pictures in entries 3376, 3377, 3378. Still it kept crashing.
I started to dig into the elog file itself. (/cvs/cds/caltech/elog/elog-2.7.5/logbooks/40m/100806a.log)

FInally I found that there was some invalid reply links in the entry 3379.

Date: Fri, 06 Aug 2010 19:29:59 -0700
Reply to: 3379
In reply to: 3379

The entry is refering this entry itself. That is weird. So I deleted the reply-to and in-reply-to lines.
Then elogd got happy.

In fact, 3379 was a dupulication of 3380, so I deleted this entry.

  3385   Sat Aug 7 21:57:56 2010 ranaSummaryDMFseisBLRMS restarted

The green xterm on op540m which is running the seisBLRMS DMF got stuck somehow ~3 days ago and lost its NDS connection. I closed the matlab session and restarted it. Seismic trends are now back online.

Attachment 1: Untitled.png
Untitled.png
  3395   Tue Aug 10 22:40:55 2010 KojiSummaryPEMAccelerometer located on and below the PSL table

Result of the accelerometer measurement

Introduction

We wanted to characterize the PSL table before the work before its lifting up.
We put a set of three-axis Wilcoxon accelerometers on the ground and another set on the PSL table through the weekend.

Result

- The data at 9th Aug 00:00(UTC) is used. This was Sunday 5PM in the local time.
- The freq resolution was 0.01Hz. The # of avg was 50.

- The accelerometer signals were calibrated by the value 1.2e-7 V/(m/s^2). We use this absolute value of the spectrum for the comparison purpose.

- The accelerometers were aligned to North(X), East(Y), and Up(Z). There was the coherence observed from 2~20Hz.
  The transfer functions are valid only this frequency region although we still can set the lower bound of them.

- The transfer functions in the horizontal directions show huge peaks at around 20Hz. The Q of the peaks are ~30 to ~100.
  The vertical transfer function shows somewhat lower peak at around 50Hz with Q of ~10.

Some thoughts

- The low resonant freq and the high Q of the horizontal mode comes from the heaviness of the table.

- We are going to raise the table. This will usually mean that we get the lower resonant freq. This is not nice.

- So, the decision to use 6 tripods rather than 4 was right.
- The steel tripods are expected to give both more rigidity and more damping than the chep-looking hollow Newport legs.
- Concrete grouting of the tripods will also lower the effective height and will benefit for us.

 

Attachment 1: PEM_100809.pdf
PEM_100809.pdf
  3403   Wed Aug 11 16:56:00 2010 KojiSummaryEnvironmentCovering of the IFO

Katharine, Sharmila, Gopal, Kiwamu, Jenne, Aidan, Steve, and Koji

A guy from the carpenter shop has done the drilling work in the morning.

In the afternoon we wrapped the central part of the interferometer with plastic sheets in order to avoid the dusts from the tile ripping that will happen tomorrow.

Attachment 1: IMG_2732.jpg
IMG_2732.jpg
  3423   Fri Aug 13 20:58:20 2010 JennaSummaryElectronicsRubidium clock phase noise measurement

 Here's an overview of the rubidium measurement:

rubidium_diagram.png

HPIM3871.JPG

 

HPIM3880.JPG

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

HPIM3872.JPG

 

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

HPIM3878.JPG

HPIM3876.JPG

  3472   Wed Aug 25 16:13:32 2010 steveSummaryPEMPSL optical table is back into operation at 32.75" level

The tile work was done yesterday after noon.

This morning Mike Gerfen and me lowered the enclosure frame to normal height.

Keven- janitor and I removed plastic covers from chambers, racks, SP, MC2 and clean tool boxes.

 

The afternoon Jenne, Kiwamu, Joe and Aiden cleaned the enclosure inside out. The particle count measured zero inside the enclosure with HEPAs on when the covers were

removed. The MOPA and all other components were happy to see us in excellent condition.

This table height is very user friendly!

 

Safety grounds were reconnected.

 

Atm1, new tiles around the concrete slab

Atm2, frame lowered with low cross bars reinstalled

Atm3, the enclosure frame's north west foot is connected to ground

Atm4, PSL optical table is connected to ground at the north east corner through 1 Mohm

Atm5, PSL optical table level at a stimulating, back-friendly height

Attachment 1: P1060764.JPG
P1060764.JPG
Attachment 2: P1060768.JPG
P1060768.JPG
Attachment 3: P1060777.JPG
P1060777.JPG
Attachment 4: P1060776.JPG
P1060776.JPG
Attachment 5: P1060780.JPG
P1060780.JPG
  3487   Mon Aug 30 13:57:25 2010 KojiSummaryPSLPSL table vibrational performance after the upgrade

Jenne and Koji

Last week Jenne has put the accelerometers on and under the PSL table immediately after the plastic sheets were removed.

So I took the same measurement as I did on 9th Aug.

Here is the comparison of the vibrational performance of the table before and after the modification.

Basically the table is now stiffer and more damped than it was before.
We don't find any eminent structure below (at least) 70Hz.

This result is obtained despite elevating of the table.

1) Attachment 1

For the horizontal comparison (top),  it is clearly seen that the large resonant peak at 20Hz was eliminated.
At least the new resonances went up to 70-90Hz region. Y is basically equivalent to X.

For the vertical comparison (bottom), it is clearly seen that the resonant peaks at around 50 & 70Hz were eliminated. 
At least no new resonance is seen.

2) Attachment 2

All-in-one plot for the measurement --- spectra, coherences, transfer functions --- after the upgrade. I put the same plot for the one before the upgrade.

Attachment 1: PEM_100830_SPE.pdf
PEM_100830_SPE.pdf
Attachment 2: PEM_100830.pdf
PEM_100830.pdf PEM_100830.pdf
  3488   Mon Aug 30 18:22:00 2010 ranaSummaryPSLPSL Enclosure is UNSTABLE

The lifting and resetting of the BLUE PSL enclosure has made it unstable somehow. When I push on it a little it rocks back and forth a lot.

Steve, please look into what's happening and stiffen it if you can. Its too unstable right now.

  3513   Thu Sep 2 14:11:17 2010 steveSummaryPEMsouth end crane balancing is completed

The crane I -beam now leveled at all degrees of rotation.  The lower hinge was moved southward  about 1/4 of an inch.  Performance was tested at 2000 lbs

 

Atm1, work in progress

Atm2, load test at 1 Ton

Atm3, service report

Attachment 1: P1060798.JPG
P1060798.JPG
Attachment 2: P1060800.JPG
P1060800.JPG
Attachment 3: P1060804.JPG
P1060804.JPG
  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.

  3567   Mon Sep 13 12:09:42 2010 kiwamuSummaryGeneralelog restarted

 Elog didn't respond, so I restarted it with the script.

Before killing the process somehow two elog daemons were running at the same time. I killed those two manually. 

  3576   Wed Sep 15 14:34:57 2010 josephbSummaryCDSPlan for RFM switch over

Steps for RFM switch over:

1) Ensure the new frame builder code is working properly:

   A) Get Alex to finish compiling the frame builder and test on Megatron.

   B) Test the new frame builder code on fb40m (which is running Solaris) in a reversible way.  Change directory structure away from Data1, Data2, to use actual times.

   C) Confirm new frame builder code still records slow channels (c1dcuepics).

2) Ensure awg, tpman, and diagnostic codes (dtt) are working with the new front end code.

3) Physically move RFM cables from old front ends to the new front ends.  Remove excess connections from the network.

4) Merge the megatron/c1sus/c1iscex/c1ioo network with the main network.

   A) Update all the network settings on the machines as well as Linux1

   B) Remove the network switch separating the networks.

4) Start the new frame builder code on fb40m.

  3579   Wed Sep 15 19:29:13 2010 valeraSummary PSL power budget
 Location  Power (mW)
 NPRO - after HWP  252
 Rejected by input FI polarizer  38
 After output FI polarizer  175
 Into PMC  164
 PMC reflected  37
 PMC transmitted  71
 PMC leakage  1.5
 After PMC TRANS PD/Camera BS

 1.2

 After RefCav EOM  1.1
 Into RefCav  0.3

 Notes:

- NPRO injection current 1.0 A

- PMC losses ~32%

- FSS AOM diffraction efficiency ~52%

  3596   Thu Sep 23 02:23:04 2010 koji,taraSummaryElectronicsTesting new TTFSS

I tested the new table top frequency stabilization system(TTFSS),
I haven’t finished it yet, and accidentally fried one amplifier in the circuit.

We received three sets of a new TTFSS system which will replace the current FSS.
It needs to be checked that the system works as specified before we can use it.

- Result

I followed the instruction written on E10000405-v1
The first test inspected how much the currents were drawn from the +/- 24 V power supply.
+24 V drew 350 mA and -24 V drew 160 mA as shown on pwr supply’s current monitor.
They exceeded the specified value which was 200 +/- 20 mA, but nothing went wrong during the test.
Nothing got overheated, all voltage outputs were correct so I proceeded.
I have gone down the list to 6, and everything works as specified.

- Correcting the document for the test procedure

I found a few errors on the instruction document. I’ll notify the author tomorrow.

- How GVA-81 amplifier on D0901894 rev A got fried

During the test, I used a mirror on a stick that looked like a dental tool to see under the board.
Unfortunately, the steel edge touched a board and caused a spark. The voltage on -24 dropped to -16.
I think this happened because the pwr supply tried to decrease the current from shorted circuit,
as I shorted it only short time ( a blink of an eye), it could not reduce the voltage to zero.
When I was checking the power supply and about to adjust the voltage back to the right value
(about 4-5 seconds after the spark,) smoke came out of the circuit.

Koji investigated the circuit and found that a GVA 81 amplifier was broken.

This was checked by applying 5V to the amp, and slightly increasing the current.
The voltage dropped to zero as the amp was broken, so its circuit was shorted.

I’ll see if I can replace this at EE lab at Downs.
If I cannot find a spare one, I’ll replace it with a resistor and resume the test procedure.
Because it amplifies LO signal, which won’t be used during the test.

  3597   Thu Sep 23 02:45:30 2010 KojiSummaryComputersnodus gracefully rebooted

Zach> Nodus seemed to be working fine again, and I was browsing the elog with no
Zach> problem. I tried making an entry, but when I started uploading a file it
Zach> became unresponsive. Tried SSHing, but I get no prompt after the welcome
Zach> blurb. ^C gives me some kind of tcsh prompt (">"), which only really
Zach> responds to ^D (logout). Don't know what else to do, but I assume someone
Zach> knows what's going on.

By gracefully rebooting nodus, the problem was solved.


It (">") actually was the tcsh prompt, but any commands with the shared or dynamic link libraries looked unfunctional.

I could use
    cd /.../...
and
    echo *
to browse the directory tree. The main mounted file systems like /, /usr, /var, /cvs/cds/caltech looked fine.
I was afraid that the important library files were damaged.

I tried
    umountall
and
    mountall
in order to flush the file systems.
These should run even without the libraries as mount must properly work even before /usr is mounted.

They indeed did something to the system. Once I re-launch a new login shell, the prompt was still ">"
but now I could use most of the commands.

I have rebooted by usual sudo-ing and now the services on nodus are back to the functional state again.

# nodus was working in the evening at around 9pm. I even made an e-log entry about that.
# So I like to assume this is not directly related to the linux1 incident. Something else could have happened.

  3603   Thu Sep 23 23:24:43 2010 rana, johnny, taraSummaryPSLAM modulate AOM to measure RefCav Thermo-Optic coefficient

Big Johnny and I hacked a function generator output into the cross-connect of the 80 MHz VCO driver so that we could modulate the

amplitude of the light going into the RefCav. The goal of this is to measure the coefficient between cavity power fluctuations and the

apparent length fluctuations. This is to see if the thermo-optic noise in coatings behaves like we expect.

 

To do this we disconnected the wire #2 (white wire) at the cross-connect for the 9-pin D-sub which powers the VCO driver. This is

called VCOMODLEVEL (on the schematic and the screen). In the box, this modulates the gain in the homemade high power Amp which

sends the actual VCO signal to the AOM.

 

This signal is filtered inside the box by 2 poles at 34 Hz. I injected a sine wave of 3 Vpp into this input. The mean value was 4.6 V. The

RCTRANSPD = 0.83 Vdc. We measure a a peak there of 1.5 mVrms. To measure the frequency peak we look in

the FSS_FAST signal from the VME interface card. With a 10 mHz linewidth, there's no peak in the data above the background. This signal

is basically a direct measure of the signal going to the NPRO PZT, so the calibration is 1.1 MHz/V.

 

We expect a coefficient of ~20 Hz/uW (input power fluctuations). We have ~1 mW into the RC, so we might expect a ~20 Hz frequency shift.

That would be a peak-height of 20 uV. In fact, we get an upper limit of 10 uV.


 Later, with more averaging, we get an upper limit of 1e-3 V/V which translates to 1e-3 * 1.1 MHz / 1 mW ~ 1 Hz/uW. This is substantially lower

than the numbers in most of the frequency stabilization papers. Perhaps, this cavity has a very low absorption?

  3620   Wed Sep 29 12:08:28 2010 josephb, alexSummaryCDSLast burt save of old controls

This is being recorded for posterity so we know where to look for the old controls settings.

The last good burt restore that was saved before turning off scipe25 aka c1dcuepics was on September 29, 11:07.

  3647   Tue Oct 5 11:42:20 2010 kiwamuSummaryGreen Lockingdeveloping green locking plant

 With a help from Joe, I made a diagram of the simulated plant for green locking in order to get better understanding and consensus.

Eventually these simulated plants will help us developing (sometimes debugging) the digital control systems.

Here is the diagram which tells us how we will setup and link the control/plant models and on which machine they will be running.

green_sm3.png

 

Basically upper side represents the realtime control, and the lower side is the simulated plant.

The models are talking to each other via either a local shared memory (orange line) or the reflective memory network (purple line).

 Each model is stil not systematically named, at some point we have to have an absolute standard for naming the models.

 

- current model names -

  GCV = Green Control model at Vertex

  GCX(Y) = Green Control model at X (Y) end

  GPV = Green Plant model at Vertex

 

 - things to be done -

1. let the RFM work

2. revise the old plant models : SUP, SPX(Y) and LSP

 

  3655   Tue Oct 5 18:27:18 2010 Joonho LeeSummaryElectronicsCCD cable's impedence

Today I checked the CCD cables which is connected to the VIDEOMUX.

17 cables are type of RG59, 8 cables are type of RG58. I have not figured out the type of other cables(23 cables) yet.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

To check the impedance of each CCD cable, I went to the VIDEOMUX and looked for the label on the cable's surface.

Type of RG59 is designated to the cable of impedance 75ohm. I wrote down each cable's input or output channel number with observation(whether it is of type RG59 or not).

The result of observation is as follows.

Type channel number where it is connected to
Type 59 in#2, in#11, in#12, in#15, in#18, in#19, in#22, in#26, out#3, out#4, out#11, out#12, out#14, out#17, out#18, out#20, out#21
Type 58 in#17, in#23, in#24, in#25, out#2, out#5, out#7, out#19
unknown type others

 

For 23 cables that I have not figured out their type, cables are too entangled so it is limited to look for the label along each cable.

I will try to figure out more tomorrow. Any suggestion would be really appreciated.

  3657   Wed Oct 6 00:32:01 2010 ranaSummaryDAQNDS2

This is the link to the NDS2 webpage:

https://www.lsc-group.phys.uwm.edu/daswg/wiki/NetworkDataServer2

We should install this so that we can use this modern interface to get 40m data from outside and inside of the 40m.

  3660   Wed Oct 6 14:49:54 2010 ranaSummaryloreSteve on the sea

jacques.jpg

  3685   Sun Oct 10 18:09:02 2010 KojiSummaryCOCPhase map interferometer calibration for the data on Oct 8th, 2010

Summary:

Calibration of the phase map interferometer was calculated for the data on Oct 8th, 2010.
The calibration value is 0.1905 mm/pixel.

This is slightly smaller than the assumed value in the machine that is 0.192mm/pixel.
This means that the measured radii of curvature must be scaled down with this ratio.
(i.e. RoC(new) = RoC(old) / 0.1922 * 0.19052)


Motivation:

Our tagets of the phasemap measurement are:

1. Measure the figure errors of the mirrors
2. Measure the curvature of the mirrors

The depth of the mirror figure is calibrated by the wavelength of the laser (1064nm).
However, the lateral scale of the image is not calibrated.
Although Zygo provides the initial calibration as 0.192 mm/pixel, we should measure the calibration by ourselves.

Method:

We found an aperture mask with a grid of holes with 2mm diameter and 3mm spacing (center-to-center).
Take the picture of this aperture and calibrate the pixel size. The aperture is made of stainless and makes not interference
with the reference beam. Thus we put a dummy mirror behind the aperture. (UPPER LEFT plot)

As the holes are aligned as a grid, the FFT of the aperture image shows peaks at the corresponding pitches. (UPPER MIDDLE plot)
As the aperture was slightly rotated, the grids of the peaks are also slanted.

We can obtain the spacing of the peak grids. How can we can that values precisely? I decided to make an artificial mask image.
The artificial mask (LOWER LEFT plot) has the similar FFT pattern (LOWER MIDDLE plot). The inner product of the two
FFT results (i.e. Sum[abs(fft1) x abs(fft2)]), quite a large value is obtained if the grid pitch and the aperture angle agrees between those images.
Note that the phase information was discarded. The estimated grid spacing of the artificial mask can be mathematically obtained.

Result:

The grid pitch and the angle were manually set as initial values. Then the parameters to give the local maximum was obtained by fminsearch of Matlab.
UPPER RIGHT and LOWER RIGHT plots show the scan of the evaluation function by changing the angle and the pitch. They behave quite normal.

The obtained values are

Grid pitch: 15.74 pixel
Angle: 1.935 deg

As the grid pitch is 3mm, the calibration is

3 mm / 15.74 pixel = 0.1905 mm/pixel

Discussion:

A spherical surface can be expressed as the following formula:

z = R - R Sqrt(1-r2/R2)      (note: this can be expanded as r2/(2 R)+O(r3) )

Here R is the RoC and r is the distance from the center. This means that the calibration of r quadratically changes the curvature.
We have measured the RoC of the spare SRM. We can compare the RoCs measured by this new metrology IFO and the old one,
as well as the one by Coastline optics. 

 

Attachment 1: calibration.pdf
calibration.pdf
  3686   Sun Oct 10 18:28:25 2010 kiwamuSummarySUSITMX OSEM offsets

Because of the in-vac work on Oct. 4th (see this entry) , ITMX's OSEM offsets were changed.

The two upper OSEMs are still fine, but LL and LR seem to be out of the OSEM's range. 

The plot below shows the trends of LL's and LR's readouts for about two weeks. (The channel name are in the old convention, i.e. ITMY)

OSEM.png

 Some data were missing due to the upgrade of the frame builder.

 It is apparent that the offsets are changed after the in-vac work on Oct. 4th, and now they just show almost zero numbers.

 

The damping of ITMX can still work, if LL and LR are disabled.

At some point before pumping down, we have to check the leveling of the ITMX table again.

  3689   Mon Oct 11 16:09:10 2010 yutaSummarySUScurrent OSEM outputs

Background:
 The output range of the OSEM is 0-2V.
 So, the OSEM output should fluctuate around 1V.
 If not, we have to modify the position of it.

What I did:
 Measured current outputs of the 5 OSEMs for each 8 suspensions by reading sensor outputs(C1:SUS-XXX_YYPDMON) on medm screens.

Result:

  BS ITMX ITMY PRM SRM MC1 MC2 MC3
UL 1.20 0.62 1.69 1.18 1.74 1.25 0.88 1.07
UR 1.21 0.54 1.50 0.99 1.77 1.64 1.46 0.31
LR 1.39 0.62 0.05 0.64 2.06 1.40 0.31 0.19
LL 1.19 0.88 0.01 0.64 1.64 1.00 0.05 1.03
SD 1.19 0.99 0.97 0.79 1.75 0.71 0.77 0.93

 White: OK (0.8~1.2)
 Yellow: needs to be fixed
 Red: BAD. definitely need fix

  3694   Mon Oct 11 23:55:25 2010 Joonho LeeSummaryElectronicsCCD cables for output signal

Today I checked all the CCD cables which is connected output channels of the VIDEOMUX.

Among total 22 cables for output, 18 cables are type of RG59, 4 cables are type of RG58.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

 

Today, I labeled all cables connected to output channels of VIDEO MUX and disconnect all of them since last time it was hard to check every cable because of cables too entangled.

With thankful help by Yuta, I also checked which output channel is sending signal to which monitor while I was disconnecting cables.

Then I checked the types of all cables and existing label which might designate where each cable is connected to.

After I finished the check, I reconnected all cables into the output channel which each of cable was connected to before I disconnected.

 

4 cables out of 22 are type of RG58 so expected to be replace with cable of type RG59.

The result of observation is as follows. 

Ch#
where its signal is sent type
1 unknown 59
2 Monitor#2  58
3 Monitor#3 59
4 Monitor#4 59
5 Monitor#5 58
6 Monitor#6 59
7 Monitor#7 58
8 unknown / labeled as "PSL output monitor" 59
9 Monitor#9 59
10 Monitor#10 59
11 Monitor#11 59
12 Monitor#12 59
13 Unknown 59
14 Monitor#14 59
15 Monitor#15 59
16 unknown / labeled as "10" 59
17 unknown 59
18 unknown / labeled as "3B" 59
19 unknown / labeled as "MON6 IR19" 58
20 unknown 59
21 unknown 59
22 unknown 59

I could not figure out where 10 cables are sending their signals to. They are not connected to monitor turned on in control room

so I guess they are connected to monitors located inside the lab. I will check these unknown cables when I check the unknown input cables.

Next time, I will check out cables which is connected to input channels of VIDEIO MUX. Any suggestion would be really appreciated.

  3738   Mon Oct 18 18:33:46 2010 KojiSummaryCOCSummary of the main mirrors & their phasemap measurement

I have made a summary web page for the 40m upgrade optics.

https://nodus.ligo.caltech.edu:30889/40m_phasemap/

I made a bunch of RoC calculations along with the phase maps we measured.
Those are also accommodated under this directory structure.

Probably.... I should have used the wiki and copy/paste the resultant HTML?

  3739   Mon Oct 18 22:11:32 2010 Joonho LeeSummaryElectronicsCCD cables for input signal

Today I checked all the CCD cables which is connected input channels of the VIDEOMUX.

Among total 25 cables for output, 12 cables are type of RG59, 4 cables are type of RG58, and 9 cables are of unknown type.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

 

Today, I check the cables in similar way as I did the last time.

I labeled all cables connected to input channels of VIDEO MUX and disconnect all of them since last time it was hard to check every cable because of cables too entangled.

Then I checked the types of all cables and existing label which might designate where each cable is connected to.

After I finished the check, I reconnected all cables into the input channel which each of cable was connected to before I disconnected.

 

4 cables out of 25 are type of RG58 so expected to be replace with cable of type RG59.

9 cables out of 25 are of unknown type. These nine cables are all orange-colored thick cables which do not have any label about the cable characteristic on the surface.

The result of observation is as follows.

Note that type 'TBD-1' is used for the orange colored cables because all of them look like the same type of cable.

 

Channel number where its signal is coming type
1 C1:IO-VIDEO 1 MC2 TBD-1
2 FI CAMERA 59
3 PSL OUTPUT CAMERA 59
4 BS  C:1O-VIDEO 4 TBD-1
5 MC1&3 C:1O-VIDEO 5 59
6 ITMX C:1O-VIDEO 6 TBD-1
7 C1:IO-VIDEO 7 ITMY TBD-1
8 C1:IO-VIDEO 8 ETMX TBD-1
9 C1:IO-VIDEO 9 ETMY TBD-1
10 No cable is connected
(spare channel)
 
11 C1:IO-VIDEO 11 RCR 59
12 C1:IO-VIDEO RCT 59
13 MCR VIDEO 59
14 C1:IO-VIDEO 14 PMCT 59
15 VIDEO 15 PSL IOO(OR IOC) 59
16 C1:IO-VIDEO 16 IMCT TBD-1
17 PSL CAMERA 58
18 C1:IO-VIDEO 18 IMCR 59
19 C1:IO-VIDEO 19 SPS 59
20 C1:IO-VIDEO 20 BSPO TBD-1
21 C1:IO-VIDEO 21 ITMXPO TBD-1
22 C1:IO-VIDEO 22 APS1 59
23 ETMX-T 58
24 ETMY-T 58
25 POY CCD VIDEO CH25 58
26 OMC-V 59

Today I could not figure out what impedance the TBD-1 type(unknown type) has.

Next time, I will check out the orange-colored cables' impedance directly and find where the unknown output signal is sent. Any suggestion would be really appreciated.

  3749   Thu Oct 21 01:11:48 2010 ranaSummaryComputerselog change and rossa tex

I deleted a bunch of categories from the elogd.cfg file. Not every kind of locking and activity gets its own activity. All of the things related to length sensing and control should be LSC. If there's a high pollen count its under PEM. etc., etc., etc.

I decided that the 'tetex' distribution which comes with CentOS is total BS and I removed it from rossa using 'yum erase tetex'. I installed TexLive using the instructions on the web; its much better, actually works, and also has RevTex 4.1 which allows Jenne and I to write our paper.

Eventually, we'll standardize our workstation setups.

Yuta has also successfully set up zita to run the projector, so we should clear our some of the boxes and bookshelves in that area so that the projection can be larger.

  3753   Thu Oct 21 13:05:19 2010 KojiSummaryComputerselog change and rossa tex

This is cool though the projector is flashing the blue screen alternately.

I gave the dual head video card (ATI RADEON something) to Yuta a month ago.
It is on the top of Zita. This would make the things more fun.

Quote:

Yuta has also successfully set up zita to run the projector, so we should clear our some of the boxes and bookshelves in that area so that the projection can be larger.

 

  3765   Fri Oct 22 19:53:27 2010 yutaSummaryCDSconversion failure in digital filters

(Rana, Joe, Yuta)

We now understand that we never succeeded in converting old fiter files to new filter files.

For example, we just changed the sampling rate with coefficients remained and foton confused, or we forgot to rename some of the module names(ULSEN -> SUS_MC1_ULSEN) ......

This is why we sometimes damped and sometimes didn't, depending on filter switches. New filter files has been always wrong.

So, we started to convert them again.
We have to figure out how to convert the files that Foton accepts correctly.

  3770   Sat Oct 23 14:42:01 2010 yutaSummaryCDSdamped MC suspensions

After replacing filters, MC suspensions damped  last night.

Further measurement next time.

Attachment 1: dam.png
dam.png
  3771   Sun Oct 24 18:06:35 2010 kiwamuSummaryLockingsetup for green beat

green_beat_note.png

(notes on signal level)

 The signal level of the observed peak was -48dBm.

However I was expecting it is like -28dBm with some ideal assumptions.

There may be a 20dB unknown loss which sounds big to me.

 

The expectation was calculated by using the following simple math.

                       SIGNAL = A x Z x G_RF x sqrt(P1 / 2) x sqrt (P2 / 2)

 where A is the responsibility of the PD and Z is the trans impedance gain. G_RF is a gain of the RF amplifier.

The laser powers of green beams, P1 and P2, are divided by 2 due to a beam splitter. 

I was assuming the parameters are like:

           A = 0.39 [A/W]   (assuming 90% quantum efficiency at 532nm)

           Z = 240 [V/A]  

           P1 = 17 uW  (measured by Newport power meter)

           P2 = 30 uW (measured by Newport power meter)

           G_RF = 23 dB

 

  3774   Mon Oct 25 02:14:38 2010 KojiSummaryLockingsetup for green beat

- What is the actual photocurrent for the beam1 and beam2? We don't care how much power do you have before the BS, but care how much current do you have on the PD.

- How much is the visibility? There is mismatching of the beams. i.e. The beam diameter looked quite different. Also the beams are not TEM00 but have fringes probably comes from the TT mirrors. You maybe able to measure the visibility by the DC output, making the beat freq go through df=0 slowly.

- What is the measured gain of the RF amp? Does it include the voltage division by the output/input impedance?

---------------------

 The signal level of the observed peak was -48dBm.

However I was expecting it is like -28dBm with some ideal assumptions.

There may be a 20dB unknown loss which sounds big to me.

I was assuming the parameters are like:

           A = 0.39 [A/W]   (assuming 90% quantum efficiency at 532nm)

           Z = 240 [V/A]  

           P1 = 17 uW  (measured by Newport power meter)

           P2 = 30 uW (measured by Newport power meter)

           G_RF = 23 dB

  3815   Thu Oct 28 23:17:15 2010 yutaSummaryCDS[EMERGENCY] accidentally deleted daqd

Rana showed me that if c1sus machine runs c1mcs stuff(and c1x02 stuff) only, we can use dataviewer without crashing fb.
Also, if we set correct NDS server and port(fb/8088), we can use diaggui on every machine.


During my investigation on what he did, I accidentally deleted daqd......
I am very very sorry.

I don't know if it helps or not, but all I have is the following information:

[Backup?]
    /opt/rtcds/caltech/c1/target/fb/daqd.25sep10


[What I deleted]
   -rwxr-xr-x 1 controls controls 6583071 Oct  1 11:57 daqd


[help message for daqd existed]
CDS Data Acquisition Server, Frame Builder, version 2.0
California Institute of Technology, LIGO Project
Client communication protocol version 11.4

Usage:
        daqd [-f <input frame file name>]
        [-c <configuration file (default -- $HOME/.daqdrc)>]

        [-s <frame writer pause usec (default -- 1 sec)>]


This executable compiled on:
        Fri Oct  1 10:33:18 PDT 2010
        Linux fb 2.6.34.1 #7 SMP Fri Sep 24 14:09:53 PDT 2010 x86_64 Dual-Core AMD Opteron(tm) Processor 8220 AuthenticAMD GNU/Linux



Please help me, Joe.

  3816   Fri Oct 29 01:18:03 2010 KojiSummarySUSPRM standoff glued

[Suresh Koji]

The standoff glued. The incandescent lamp set for curing the epoxy.


Jenne and Suresh did the balancing job. The next job was to glue it.

They ran out of the clear epoxy, and tried to use the grey epoxy which we used on the other suspensions for the upgrade.
They found that the solution A with grey color one was dried out and grainy.

We made a test piece of the grey epoxy (mixed with the solution B) in order to see the glue is still usable or not.
After the PMA party, we found that the glue was not stiffening but brittle. We judged that the grey epoxy is no longer useful.

Steve found a pack of Vac Seal in the chemical fridge. We decided to use this one for the gluing of the standoff.

After the gluing, we set an incandescent lamp to make the glue warm. 

Finally, we wrapped the suspension tower with Al foils and turned the HEPA fans again.

Attachment 1: IMG_3674.jpg
IMG_3674.jpg
  3821   Fri Oct 29 11:25:15 2010 josephb, yutaSummaryCDS[EMERGENCY] accidentally deleted daqd

Problem:

Missing daqd file, i.e. the framebuilder executable.

Solution:

1) Go to /opt/rtcds/caltech/c1/core/advLigoRTS/

2) Look in the Makefile for a likely build suspect.  In this case it was build dc, which stands for data concentrator.

3) So we ran "make dc"

4) Go to the sub-directory build/dc/ and then copy the daqd file there to the /opt/rtcds/caltech/c1/target/fb directory

5) Test it to ensure we're getting channels (Yay!)

Future Safeguards:

Place the new target directory under SVN control.

 

  3828   Fri Oct 29 18:37:33 2010 yutaSummaryCDSdaqd and current CDS status

Background:
  Before Joe left(~ 1 hour ago), fb was working for a while. But after he left, daqd core dumped.
  This is maybe because we started c1sus and c1rms again for a delay measurement, just before he left.

What I did:
  I restarted IOP(c1x02) and FE models.
  Now it seems OK (we can use dataviewer and diaggui), but daqd reports bunch of errors like;

CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:SUS-ITMX_TO_COIL_0_3_INMON", Connecting to: 192.168.113.85:42367, Ignored: c1susdaq:42367"
    Source File: ../cac.cpp line 1208
    Current Time: Fri Oct 29 2010 18:07:39.132686519
..................................................................


tp node xx invalid  (xx is 38 to 36)

Current CDS status:

MC damp dataviewer diaggui AWG c1ioo c1sus c1iscex RFM Sim.Plant  ...
                   ... 

   Please add other stuff you need.

Below is an example of how the color code works:

06-25-2009.NN_24ThreatLevel.GJH2L69BK.1.jpg

  3829   Sat Oct 30 05:27:53 2010 yutaSummaryCDSCDS time delay measurement

Motivation:
  We want to know the time delay of CDS in the IOP scheme.

Setup:
delaysetup.png

What I did:
1. Plugged out SCSI cable from ADC card 2 and DAC card 0 on C1SUS machine.
   ADC card 2 is ADC 0
   DAC card 0 is DAC 0

2. Measured tranfer function between ADC and DAC by SR785 and compared with the downsampling filter in IOP with 65534Hz(=4x16384Hz) sampling frequency.

  As ADC_0_0 corresponds to PRM ULSEN input and DAC_0_0 corrsponds to ULCOIL output, we turned all the filters off and set gains to 0 or 1 so that TF between ULSEN to ULCOIL will be ideally 1. (see this wiki page for channel assigns)

  The filter coefficients for the down sampling filter was found in;
    /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/fe/controller.c
  It was named feCoeff4x.

static double feCoeff4x[9] =
        {0.014805052402446,
        -1.71662585474518,    0.78495484219691,   -1.41346289716898,   0.99893884152400,
        -1.68385964238855,    0.93734519457266,    0.00000127375260,   0.99819981588176};


3. Calculated the time delay dt using the following formula;
  dt = [pm - pc]/f/360deg    (pm: measured phase, pc: calculated phase from feCoeff4x, f: frequency)

4. Measured TF between the SCSI cables to estimate the effect of the cables and others.
  Disconnected SCSI cables from ADC and DAC, and connected A aad B(see setup).
  I measured both when input coupling of SR785 is DC and AC and see what happens.

Result:
  [time delay of the CDS]  (left, middle)
    The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
    However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
    I neglected TF of upsampling this time.

  [cable and other effect]  (right)
    The effect to the time delay measurement was tiny by a factor of 10^4 to 10^3 (few nsec).
    But the total cable length was about 5 m and assuming signal speed is 0.6c, delay will be about 30 nsec.
    I don't know what's happening.

CDSdelay.png

Plan:
  - make a model that does not go through IOP and see the delay caused by IOP

By the way:
  fb daqd is still running for hours!
  Every FEs are running(c1sus,rms,mcs).

ELOG V3.1.3-