[Joe and Kiwamu]

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

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.

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

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.

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.

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.

 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

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.

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.

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.

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.

 Here's an overview of the rubidium measurement:

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

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

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

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.

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.

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

 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;

 We also try to keep updating the wiki page.

 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. 

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.

 Notes:

- NPRO injection current 1.0 A

- PMC losses ~32%

- FSS AOM diffraction efficiency ~52%

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.

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.

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?

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.

 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.

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

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.

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.

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.

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.192² * 0.1905²)

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-r²/R²)      (note: this can be expanded as r²/(2 R)+O(r³) )

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. 

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)

 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.

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:

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

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. 

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.

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?

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.

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.

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.

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.

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

After replacing filters, MC suspensions damped  last night.

Further measurement next time.

(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

- 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

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.

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

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.

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:

   Please add other stuff you need.

Below is an example of how the color code works:

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

Setup:


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.



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

Unsatisfactory.

Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:

scripts/general/netgpibdata/

which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

Background:
  I measured CDS time delay last week, but because of my lack of understanding the system, it was incorrect.
  IOP has an anti-aliasing filter before downsampling from 64kHz(65536Hz) to 16kHz(16384Hz) and also has an anti-imaging filter before upsampling from 16kHz to 64kHz.
  So, I should have take feCoeff4x into account twice.


Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.



Plan:
 - make AWG(, diaggui TF measurement, tdssine) work
 - check input/output filter switching (using tdssine & tdsdmd)
 - measure openloop TF of MC suspension damping
 - divide it with my expectation and see if there are any filters I don't know

Um, Beautiful.

Actually, 123.5usec is almost exactly twice of 1/16384Hz.
Because of the loop, we have 1/16384Hz delay. I wonder where we do have the delay.

In order to understand the behaviour of the system can I ask you to test the following things?

1) What are the delay without IOPs with f_sampl of 16k, 32k, 64k?

2) What are the delay with IOP with f_sampl of 32k, 64k?

Frame builder died again!!

Background:
  We want to do angle to length measurement to optimize the beam position and increase visibility of MC locking.
  In order to do A2L measurement, we need excitation point, but AWG is currently not working.
  The better way is to use LOCKIN stuff like we had for OMC and put it to C1IOO WFS.
  A software oscillator in LOCKIN shakes the suspension, and demodulate the length signal.
  We can choose whatever DOF to shake, whatever signal to demodulate. It would be useful not just for A2L.

What I did:
  I started to put C1IOO WFS signal into C1SUS MC suspension RT model, but after compiling new c1mcs, fb crashed.
  Looks like daqd and mx_streams are running, but DAQ is not working(red).
  I don't know how to restart in a new way!