ELOG 40m

PSL

Broken PMC Servo Board

I broke the PMC servo board (on accident).

I was trying to measure the resistance of the extra resistor that someone put between the board and the HV OUT connector, since this is part of an RC filter (where C is the capacitance of the PZT on the PMC) that I need to know the values of as part of my mission to make a 14.6kHz notch for the PMC body mode. The resistance is 63.6k. I had to pull the board to get in to measure this resistance.

This resistor between the board and the center pin of the panel-mount HV OUT connector made a rigid connection between the board and the panel. When I was putting the board back in, I must have strained this connection enough that it broke. We don't have any of the same kind of resistor here at the 40m, so I'm waiting until after lunch to go to Wilson house and see if they've got any. The IFO is down until I get this sorted out.

877

Mon Aug 25 11:43:55 2008

Frogs

MC REFL PD cable had been disconnected through out the weekend

Most of my morning was wasted by the MC REFL PD cable, which was disconnected on the generic LSC PD interface board.
I know who did this. *ME*. When I pulled out the MC board, which is sitting next to the PD interface, on Friday, I must have
disconnected the PD cable accidentally. The connector of the PD cable (D-Sub) does not have screws to tighten and easily comes off.
I wrote this entry to warn other people of this potential problem.

876

Mon Aug 25 10:51:06 2008

psl headtemp is coming down

PSL

The laser water cooler was overflowing this morning.
I removed 500 cc water from the chiller.

The 4 days plot shows clearly:
that the capacity of the chiller is depending on the water level.
Overflowing water is a heat load for the chiller, so laser head temp goes up.

Attachment 1: ht4dw.jpg

875

Mon Aug 25 10:23:53 2008

Rack 1Y7 double violation:

BNC cables left to be jammed by door

and see destroyed BNCs

RED fibers should be rerouted.
I placed protective obstacle in position
so the door can not be closed.

Please do not do this!

DNA analysis is in progress on your finger prints.

Attachment 1: cablkill.png

Attachment 2: cablkll2.png

874

Mon Aug 25 10:07:35 2008

Numbers for the PMC servo board (Re: entry # 873)

PSL

Jenne, Rana

These are the numbers that go along with Rana's entry #873:

The existing notch in the PMC servo is at 31.41kHz.

The power spectrum of the PMC has a peak at 14.683kHz when it is just sitting on the PSL table (no extra mass). When we put a pile of steel and aluminum (~20lbs) on top of the PMC, the body resonance moves to 14.622kHz, but is decreased by about 40 dB!

Rana has ordered a lead brick + foil that should arrive sometime this week. To complete the mechanical part of this installation, we need to extend the earthquake mounts around the PMC so that the lead brick can't fall off of the PMC onto the rest of the table.

873

Sat Aug 23 09:39:51 2008

Jenne, Rana

We scoped out the PMC situation yesterday.

Summary: Not broke. UGF ~ 500 Hz. Needs some electronics work (notches, boosts, LPFs)

Ever since we swapped out the PMC because of the broken PZT of the previous one, the UGF has been
limited to a low value. This is because the notches no longer match the mechanical resonant
frequencies of the body. The old one had a resonance at 31.3 kHz which we were notching using
the LC notch on the board as well as a dangling Pomona box in the HV line to the PZT. The one
has a resonance at ~14.5 kHz which we don't yet have a notch for. Jenne has all the real numbers and
will update this entry with them.

Todo:

Implement the 4th order Grote low pass after the mixer.
Replace the AD797 with an OP27.
Change servo filter to have a boost (need DC gain)
Make a 14.5 kHz notch for the bode mode.
Put a 20 lb. gold-foil wrapped lead brick on the PMC.

Here's the link about the modified PMC board which we installed at LHO:
LHO PMC elog 2006

872

Fri Aug 22 17:03:41 2008

I measured the open loop TF of the overall MC loop using the sum-amp A of the MC board.
I used the Agilent 4395A network analyzer and saved the data into a floppy disk. However, the data was corrupted when
I read it with my computer. I had the same problem before. The floppy is not reliable. Anyway, I have to re-measure the TF.
From what I remember, the UGF was around 25kHz and the phase margin was less than 15deg.
Above this frequency, the open loop gain was almost flat and had a small bump around 100kHz.
This bump has a gain margin of less than 4dB (the phase is more than 180deg delayed here).
So the MC is marginally stable and either decreasing or increasing the gain will make it unstable easily.
Probably, the broken FSS is responsible for this. We have to fix it.

During the measurement, I also found that the input connectors (IN1 and IN2) of the MC board are freaky.
These are TNC connectors directory mounted on the board. Gently touching the cables hooked up to those connectors
caused a large offset change in the output.
When Rana pulled the board out and pushed it in firmly, the strange behavior went away. Probably, the board was
not correctly inserted into the backplane.
This could have been the reason for the MC unlocks.

871

Fri Aug 22 16:06:29 2008

particle counter replaced, flowbenches & HEPAs checked

PEM

MetOne #2 counter was swapped in (on the top of IOC, facing SW direction, at ~75 deg upwards)
with channel one size 0.3 micron and channel two size 1.0 micron.
Sampling time was reduced from 60s to 6 sec at 0.1 cf/min at 25 min rate.

This means that displayed number needs to be multiplied by x100 to get particles/cf/min

HEPA filters and flow benches were checked:

PSL enclosure closed, HEPA speed at 60% 0-0 particles on optical table NW corner

AP covered optical table 1,000 particles of 0.3micron and 10 of 1.0 micron at NE corner

Flow bench at SE 0-0 particle (p)

on the top of SP cover at SE corner 60,000 p of 0.3 micron and 530 p of 1.0 micron

Mobile HEPAs 10cm from output screen in the center 800 p of 0.3 micron and 0 p of 1 micron
These filters will be replaced.

Clean assembly room:
both flow benches 0-0 p for 0.3-1.0 micron
east side bench 520 p of 0.3 micron and 210 p of 1.0 micron

Large hood in baking room with fan on 1.7 million p of 0.3 micron
and 16,000 p of 1.0 micron

Pasadena air just outside of main entrance:
3 million p of 0.3 micron and 30,000 p of 1.0 micron

My desk 743,000 p of 0.3micron, 63,000 p of 0.5 micron and 5,500 p of 1.0 micron cf/min

NOTE: existing COCHECKLIST.adl PEM displays needs to be corrected so it shows the 10 fold increase
and change particle size on this screen to 0.3 micron

870

Fri Aug 22 13:58:39 2008

Trend of the Wiener TF

In order to understand if we really need an adaptive filter, I used old data of MC_L and the accelerometers and seismometer to see if the Wiener (ideal) TF between MC_L and the others really changes all the time.
Two tests I made:

Compare the TF after different segments of time, starting from the same point. Meaning, measuring the TF after 5,10,15,20... minutes, looking when and if the TF stablizes (stops changing).

Compare the TF between same-length segments, from different times. Meaning, comparing for example 2 segments of 10 minutes taken from different times.

Results:

As you can see in the attached PDF, the changes start being minor after 200,000 data points, which correspont to 200,000/256 s, which is approximately 13 minutes.
If you look at the PDF file, it is arranged from shorter times to longer in the order of: 3, 6, 13, 26 and 39 minutes.

As expected, the TF between different segmants of the same length is not completely the same. Again, you can look at the attached PDF.
Sorry the titles are the same. Each 2 consecutive pages represent the same length of segment in different times. The order of segment's lengths is: 3, 13, 26 and 39 minutes

How do I explain what's going on?
Since the Wiener filter finds the correlation matrix between the data and the noise signals, it will maintain some kind of familiar shape when we don't add a significant amount of unusual data. I am assuming that if I had looked at longer time periods, we could see a more significant change in the TF in time. When looking at different times, the average noise is likely to be different which can explain the change in the correlation matrix and the TF.

To sum up
I think we should give adaptive filtering a go.

Attachment 1: Same_start_time1.pdf

Attachment 2: same_length.pdf

869

Fri Aug 22 10:39:41 2008

Taking Free Swinging spectra of PRM, SRM, ITMX, BS

I'm taking free swinging spectra of PRM, SRM, ITMX and BS, so I've turned off their watchdogs for now. I should be done around 11:15am, so I'll turn them back on then.

868

Thu Aug 21 18:13:24 2008

rana

MC WFS Control signals not responsible for lock losses

This is a 4 hour, second-trend of the MC WFS error and control signals.

There is no sign that the MC loses lock because of feedback signal saturations.

Attachment 1: Untitled.png

867

Thu Aug 21 17:55:14 2008

I ran the McWFS_dc_offsets script to trim out the DC offsets on the MC WFS DC signals.

Rob says "who cares?"

866

Thu Aug 21 16:28:59 2008

SAFETY

safety glasses required

I just opened the MOPA shutter so PA is warming up.

High power beam path is cleared and laser safety glasses required.

865

Thu Aug 21 10:24:20 2008

laser safe mode condition

SAFETY

The MOPA and PSL shutters are closed.
Manual beam blocks are in place.
Enclosure interlock is enabled.
No other high power laser is in operation.

We are in laser safe of operation for visiting students from Japan

NO safety glasses required

864

Wed Aug 20 18:09:48 2008

Being suspicious of FSS PC path as the culprit of the MC unlocks, I opened the FSS box and connected a probe to the TP7,
which is a test point in the PC path (before high voltage amplifier).
The signal is routed to an unused fast DAQ channel in the IOO rack. It is named C1:IOO-MC_TMP1 and recorded by the frame
builder. You can use this channel as a generic test DAQ channel later.

By looking at the attachment, the PC path (C1:IOO-MC_TMP1) goes crazy at the same time as other channels. So probably
it is not the trigger for the MC unlock.

Then I noticed the WFS signals drift away just before the unlock as shown in the attached plot. So now the WFS is the
main suspect.
Rob tweaked MC1 pitch to center the WFS QPDs while the MC is not locked. It improved the shape of the MC reflection.
However, the sudden MC unlock still happens. We then lowered the WFS gain from 0.5 to 0.3. Did not change the situation.
It looks like the MC length loop starts oscillating after the WFS signals drift away.
We will measure the WFS and MC OPLTF to see the stability of the loops tomorrow.

Attachment 1: MC-unlock.png

863

Wed Aug 20 17:02:01 2008

More FIR to IIR

I tested another method for converting from FIR to IIR other than the 2 mentioned in post 841.
I got this one from Yoichi, called poles fitting, you can read about it more if you want at: http://www.rssd.esa.int/SP/LISAPATHFINDER/docs/Data_Analysis/DA_Six/Heinzel.pdf.

Seems it's not doing much good for us though.

I am attaching a PDF file with the plots, which have N=50,100,600,1000, respectivaly.

Attachment 1: polefit1.pdf

862

Wed Aug 20 13:23:32 2008

I was able to lock the DRMI this afternoon. All the optical levers have been centered.

861

Wed Aug 20 12:39:11 2008

I attempted to model the noise produced by the mirror defects in the ETMX images, in order to better assure that the fit to the beam Gaussian in these images is actually accurate. My first attempt involved treating the defects as random Gaussians which were scaled by the power of the beam's Gaussian. This didn't work at all (it didn't really look like the noise on the ETMX), and resulted in very different behavior from the fitting software (it fit to one of the noise peaks, instead of the beam Gaussian). I'll try some other models another time.

I made a copy of the ezcaservo source code and added options to it that allow the addition of minimum value, maximum value, and slew rate limits. This should allow the camera code to servo on ITMX without accidently driving the mirror too far or too fast. In order to get the code to recompile, I had to strip out part of the servo that changed the step value based on the amount of time that had elapsed (it relied on some GDS libraries and header files). Since the amount of time that passes is reasonably constant (about 2-3 steps per second) and the required accuracy for this particular purpose isn't extremely high, I didn't think it would matter very much.

I put together two MATLAB functions that attempt to convert pixel position in an image to actual position in real space. The first function takes four points that have known locations in real space (with respect to some origin which the camera is pointing at) and compares them to where those 4 points fall in the image. From the distortion of the four points, it calculates the three rotational angles of the the camera, as well as a scaling factor that converts pixels to real spatial dimensions. The second function takes these 4 parameters and 'unrotates' the image, yielding the positions of other features in the image (though they must be on the same flat plane) in real space. The purpose of this is to allow the cameras to provide positions in terms of physically meaningful units. It should also decouple the x and y axes so that the two dimensions can be servo'd on independently. Some results are attached; the 'original' image is the image as it came out of the camera (units in pixels), while the 'modified' image is the result of running the two functions in succession. The four points were the corners of the 'restricted access' sign and of the TV screen, while the origin was taken as the center of the sign or the TV. The accuracy of the transformation is reasonably good, but seems to depend considerably on assuring that the origin chosen in real space matches the origin in the image. To make these the same, they will be calculated by taking the intersections of the 2 lines defined by 2 sets diagonal points in each image. The first function will remain in MATLAB, since it only needs to be run once each time the camera is moved. The second function must be ported to C since the transformation must be done in realtime during the servo.

Joe and I attempted another scan of the PMC this morning. We turned the laser power down by a factor of ~50 (reflection off of the unlocked PMC went from ~118 to ~2.2) and blocked one beam in the MZ. We scanned from 40 V to 185 V ( -1 to -4.25 on the PZT ramp channel) with periods of 60 seconds and 10 seconds. In both cases, thermal effects were still clearly visible. We turned the laser power down by another factor of 2 (~1 on the PMC reflection channel), and did a long scan of 300 seconds and a short scan of 10 seconds. The 10 second scan produced what may be clean peaks, although there was clear digitization noise, while the peaks in the 300 second scan showed thermal effects. I've yet to actually analyze the data closely, however.

Attachment 1: OriginalSignImage.png

Attachment 2: ModifiedSignImage.png

Attachment 3: OriginalTVImage.png

Attachment 4: ModifiedTVImage.png

860

Wed Aug 20 12:04:47 2008

Better diagonalization of PRM input matrix

The values here should replace those in entry #851 from yesterday.

After checking the results of the input matrix diagonalization, I have determined that Sonia's method (described in LIGO-T070168) is more effective at isolating the eigenmodes than Shihori's method (LIGO-T040054).

So, the actual new PRM input matrices are as follows:

	POS	PIT	YAW
UL	0.9678	1.000	0.7321
UR	1.000	0.8025	-0.9993
LR	0.7235	-1.1230	-1.0129
LL	0.6648	-1.0452	1.0000

Attached are plots of the spectra of the eigenmodes, using both Shihori's and Sonia's methods. Note that there isn't a good way to get the side peak out of the eigenmodes.

I've put these into the SUS-PRM MEDM screen.

Attachment 1: PRM_Eigmodes_shihori.png

Attachment 2: PRM_Eigmodes_sonia.png

859

Wed Aug 20 11:50:10 2008

To restart the striptools on op540m:

cd /cvs/cds/caltech/scripts/general/

./startstrip.csh

858

Wed Aug 20 11:42:49 2008

I've installed pdftk on all the control room machines.

http://www.pdfhacks.com/pdftk/

857

Tue Aug 19 19:14:17 2008

DAQ

Fixed C1:IOO-MC_RFAMPDDC

Yoichi, Rob

C1:IOO-MC_RFAMPDDC, which is a PD at the transmission port of the MC, was not recording sensible values.
So I tracked down the problem starting from the centering of the beam on the PD.
The beam was hitting the PD properly. The DC output BNC on the PD provided +1.25V output when the light was
falling on the PD. The PD is fine.
The flat cable from the PD runs to the IOO rack and fed into the LSC PD interface card.
The output from the interface card is connected to a VMIC3113A DAQ card, through cross connects.
The voltages on the cross connects were ok.
The VMIC3113A was controlled by an EPICS machine (c1iool0). So it provides only a slow channel.
By looking at C1IOOF.ini and tpchn_C1.par, I figured that C1:IOO-MC_RFAMPDDC is using chnnum=13639 in the RFM
network and it is named C1:IOO-ICS_CHAN_15 in the .par file. So it is reading values from the ICS DAQ board.
Actually nothing was connected to the channel 15 of the ICS board and that was why C1:IOO-MC_RFAMPDDC was reading
nothing. So I took the PD signal from the cross connect and hooked it up to the Ch15 of the ICS DAQ through
the large black break out box with 4-pin LEMOs. Now C1:IOO-MC_RFAMPDDC reads the DC output of the PD.
I also put an ND filter in front of the RFAMPD to avoid the saturation of the ADC. The attenuation should have been done
electronically, but I was too lazy. Since the ND filter changes the Stochmon values, someone should remove it and reduce the
gain of the LSC PD interface accordingly.

856

Tue Aug 19 18:55:41 2008

MC unlock study update

In entry 849, I reported that the MC transmitted power drops before the sudden unlocks.
However, because C1:IOO-MC_TRANS_SUM is a slow channel, we were not sure if we can believe the timing.
So I wanted to use C1:IOO-MC_RFAMPDDC, which is a fast channel, to monitor the transmitted light power.
However, this channel was broken. So I fixed it. Details of the fixing work is reported in another entry.
The attached plot shows a recent unlock event. It is clear that in the fast channel (i.e. C1:IOO-MC_RFAMPDDC),
there is no delay between the drop of the MC power and the crazy behavior of control signals.
So it was concluded that the apparent precedence of the MC power drop in the slow channels (i.e. C1:IOO-MC_TRANS_SUM)
is just an artifact of timing inaccuracy/offset of the slow epics channels.

Sometime around 5PM, the MC started to be unwilling to even lock. It turned out that the PC drive of the FSS was going
crazy continuously. So I changed the normal values of the common gain and the fast gain, which the mcup script uses.
Now with this new setting, the MC locks happily, but still keeps unlocking.

Attachment 1: MC-unlock.png

855

Tue Aug 19 17:15:34 2008

MEDM

I plugged in the gains I got for the accelerometers in the accelerometers' filters in the PEM screen of the adaptive filter

854

Tue Aug 19 17:00:19 2008

Wiener TF calibration - update

This is an update for post 814

I added the calibration gains I got for the accelerometers (I realize I am just calibrating the accelerometers to themselves and this is not m/m exactly since we don't really know which accelerometer is doing exactly what we want it to do. However, since we are talking on relative small numbers, this shouldn't really change much).

I also added another missing gain for the seismometer. Rana has previously installed a 4300 ohm resistor in the seismometer, which changed the gain to 4300/(4300+5000) = 0.46 (this is from the manual). Moreover, there is a gain of 100 on the SR560. This comes up to an extra gain of 46, meaning multiplying the seismometer's counts by 1/46.

Attachment 1: m_per_m.png

853

Tue Aug 19 14:25:38 2008

Accelerometer's calibration - update

PEM

Goal - Make sure the accelerometers are calibrated among themselves (have the same power spectrum when they are all together reading the same movements).

What I did - took the accelerometers off their usual X Y Z setting and set the 3 MC2's and 3 MC1's next to each other covered by a box.
Then I brought MC2 X to MC1 X and placed them in a box so I have a referance between the 2 groups.

Result - Seems MC1 accelerometers are much alike and have the same power spectrum when placed together for all frequencies. MC2 accelerometers seem to do the same until approximately 30 Hz. (decided not to correct for that since we don't really care about the accelerometers in such high frequencies).

When comparing the 2 X's, they also seemed to be almost perfectly correlated. I chose the gain by dividing the two and finding the mean of that in the range of 2 to 30 Hz. After correcting for all the accelerometers, I matched the gains of each group to its X accelerometer.

You can see the plots, taking into consideration that the groups were never together (pretty messy getting the cables all around).

Here are the numbers, when the MC2 and MC1 gains are calculated by comparing them to their X direction.

gain MC1 X_over_MC2 X=

1.0870

gain_MC2_Y =

0.9944

gain_MC2_Z =

0.9479

gain_MC1_Y =

1.0394

gain_MC1_Z =

0.9149

Attachment 1: acccalibafter.png

Attachment 2: acccalibbefore.png

852

Tue Aug 19 13:34:58 2008

Switched c1pem1, c0daqawg, c0daqctrl over to new switches

Computers

Moved the Ethernet connections for c1pem1, c0daqawg, and c0daqctrl over to the Netgear Prosafe switch in 1Y6, using new cat6 cables.

851

Tue Aug 19 13:12:55 2008

Diagonalized PRM Input Matrix

NOTE: Use the values in elog #860 instead (20Aug2008)

Using the method described in LIGO-T040054-03-R (Shihori's "Diagonalization of the Input Matrix of the Suspension System"), I have diagonalized the input matrices for the PRM.

Notes about the method in the document:

Must define the peak-to-peak voltage (measured via DataViewer) to be NEGATIVE for PitLR, PitLL, YawUR, YawLR, and POSITIVE for all others
As Osamu noted in his 3 Aug 2005 elog entry, all of the negative signs in equations 4-9 should all be plus.

New PRM Input Matrices:

	POS	PIT	YAW
UL	1.000	1.000	1.000
UR	1.1877	1.0075	-1.0135
LR	0.8439	-0.9425	-0.9653
LL	0.9684	-1.0500	1.0216

850

Tue Aug 19 10:36:34 2008

Calibrating accelerometers

I took apart the accelerometers near MC1 and MC2.
The 2 sets of 3 accelerometers are now covered by a box on the floor. Please try not to move them... I will place it all back once I am done calibrating.

849

Mon Aug 18 22:47:12 2008

As rob noted, the MC keeps unlocking in a few minutes period.
I plotted time series of several signals before unlocks.
It looks like the MC alignment goes wrong a few hundred msec before the unlock (the attached plot is only one example, but all unlocks
I've looked so far show the same behavior).
I will look for the cause of this tomorrow.

The horizontal axis of the plot is sec. The data values are scaled and offset-removed appropriately so that all curves are shown
in a single plot. Therefore, the vertical axis is in arbitrary units.

Attachment 1: MC-Unlock.png

848

Mon Aug 18 17:37:14 2008

I removed the beam block after the PSL periscope and opened the PSL shutter.

There was no MC Refl beam on the camera, so I decided to trust the PSL launch
and aligned the MC to the PSL beam. Here are the old and new values for
the MC angle biases:

 __Epics_Channel_Name______   __OLD_____    ___New___
 C1:SUS-MC1_PIT_COMM          4.490900        3.246900 
 C1:SUS-MC1_YAW_COMM          0.105500	      -0.912500
 C1:SUS-MC2_PIT_COMM          3.809700	      3.658600 
 C1:SUS-MC2_YAW_COMM          -1.837100	      -1.217100
 C1:SUS-MC3_PIT_COMM          -0.614200	      -0.812200
 C1:SUS-MC3_YAW_COMM          -3.696800	      -3.303800

After this, the beam looks a *little low* going into the Faraday Isolator.
Nonetheless, after turning on the IFO input steering PZTs, I was able to
quickly steer the PRM get a beam on the REFL camera and into the REFL OSA.
The PRM optical lever beam is also striking the quad.

I then used the ETMX optical lever as a reference for realigning. After
steering around the input PZTs and ITMX, I saw some flashes in Xarm trans, then got
it locked and ran the alignment script ~5 times. The arm power went
up to 0.9, so I tweaked the MC1 to put the MC refl beam back on MCWFS.
The XARM power then went up to .96. Good enough for now.

Then I started to try and re-align the YARM. Since the oplevs for both ITMY
and the BS are untrustworthy, I first tried to get the beam bouncing off ITMX
and the BS back into the AS OSA, to try and recover some BS alignment. This
didn't work, as the AS OSA may not be a good reference anyways. After
wandering around in the dark for a little while, I decided to try an automated
scan of the alignment space. I used the trianglewave script to scan
the angle biases of BS, ITMY, & ETMY, then looked at the trend of the transmitted
power to find the gps time when there were flashes. I then used
time_machine_conlog to restore the biases to that time. This was close
enough to easily recover the alignment. After several rounds of aligning &
centering oplevs, things look good.

Also locked a PRM. Will work on the DRM tomorrow.

I'm leaving the optics in their "aligned" states over night, so they can
start their "training."

Note: The MC is not staying locked. Needs investigation.

For tomorrow:

lock up the DRM
fix the mode cleaner
re-align mode cleaner to optimize beam through Faraday
re-align all optics again (will be much easier than today)
re-align beam onto all PDs after good alignment of suspended optics is established.

Attachment 1: flatlissa.png

847

Mon Aug 18 15:32:18 2008

How to multicast with gstreamer and Gige Cameras

Cameras

In order to get multicasting to work, one simply needs to understand the address scheme.

In general, the address range 224.0.0.0 - 239.255.255.255 are reserved for multicasting. Within in this address space, there are some base level operations in the 224.0.0.x range which shouldn't be interfered with.

For a single site, the address range between 239.252.0.0 and 239.255.255.255 is probably best.

Gstreamer and the current 40m network hubs are designed to handle this kind of communication already, so one merely needs to point them at the correct addresses.

While in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode type:

CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host=239.255.1.1 port=5000

This will multicast to the 239.255.1.1 address, using port 5000.

On the machine you wish to subscribe type:

gst-launch udpsrc multicast-group=239.255.1.1 port=5000 ! smokedec ! ffmpegcolorspace ! ximagesink sync=false

846

Mon Aug 18 11:50:29 2008

In vacuum free swinging results

The first attachment is the results of the free swinging spectra measurement performed in vacuum this morning.
They are freely swinging, but the suspensions in the BS chamber got even more extra peaks.
Especially, the SRM spectrum looks like a forest.
If those extra peaks are inter-modulations of the primary suspension modes, the heights of them should be
enhanced (compared to the in-the-air case) by the increased quality factors of the primary modes (due to the less air friction).
This might explain the observed increase in the extra peaks.

While doing the free swinging, we had two big spikes in the OSEM signals of the ETMs and only in ETMs.
Those spikes screwed up the spectra of the ETMs. So the ETM spectra were calculated using the time series
after the spikes.
The second attachment shows one of those spikes. It looks like a computer glitch.

Attachment 1: 2008-8-18.pdf

Attachment 2: spike.pdf

845

Mon Aug 18 09:19:55 2008

It took 11 days to fix earth quake triggered sus problems of ITMX, SRM and PRM
Only ITMX north and BSC north vac doors were removed.

The PRM sus had to be removed form the vac envelope for "hip replacement"-new wire stand off was
epoxied in place.
Note: the PRM has no guide rod on the other side

ITMX, SRM and BS osems were optimized in place.
No crosscoupling optimization was performed.
Beam block was removed from ITMXC, it was too close to the main beam.

POX pick off mirror and mount will be replaced next vent.

Vac viewports were inspected from the inside.

Attachment 1: ventprm.jpg

844

Mon Aug 18 08:07:10 2008

Suspension free swinging

I've started a free swinging measurement of OSEM spectra now. Please leave the watchdogs untouched.

843

Fri Aug 15 19:32:49 2008

I have just reached vacuum normal. The maglev peaked at 49.8C body temp with aux fan on at 3.2 Torr
cc1 1e-4Torr

note: pumpdown was put on hold for Koji's goodby lunch

Attachment 1: pdprm.jpg

842

Fri Aug 15 17:38:41 2008

OSEM free swinging spectra before the pump down

I ran an overnight measurement of the free swinging OSEM spectra.
The attm1 shows the results. Everything look ok except for the ITMY UL OSEM.
The time series from that OSEM was very noisy and had many spikes.
We suspected the cable from the satellite box to the computer rack because we disconnected the cable
when we tested a spare cable which was used to connect the spare OSEMs to the PRM suspension in the clean room.
Janne remembered when she put the cable back, she trusted the latch on the connector and did not push it in too hard.
However, Rob suggested the latch does not work well. So she pushed the connector again. Then the signal from
the ITMY UL OSEM got back to normal.
The second attachment shows the ITMY spectra after the cable push.
We decided to pump down after confirming this.

There are still a lot of extra peaks especially in the suspensions in the BS chamber.
These may be inter modulations (by the non-linearities of the OSEMs) of the modes of the multiple
suspensions sitting on the same stack.

Attachment 1: 2008-8-15.pdf

Attachment 2: ITMY2.pdf

841

Fri Aug 15 16:45:43 2008

Converting from FIR to IIR

I have been looking into different techniques to convert from FIR to IIR. This is so we can see how effective the adaptive FIR filter is in comparison to an IIR one with fewer taps.
For now I tried 2 matlab functions: Prony and stmcb (which works on LMS method).
I used the FIR wiener code, MC1_X, (c1wino) and applied the FIR to IIR algorithm.
Seems like the stmcb one works a bit better, and that there isn't much effect for having 1000 and not 400 taps.

Will keep updating on more results I have, and hopefully have the MC in time to actually check this live.

Attachment 1: fir2iir50.png

Attachment 2: fir2iir400.png

Attachment 3: fir2iir1000.png

840

Fri Aug 15 14:12:31 2008

Bureaucracy

SAFETY

safety glasses required

The MOPA shutter is opened,
the PSL enclosure is switched to bypass mode,
manual block removed from PMC,

the PSL output is still blocked and the mechanical shutter is still closed.

Pumpdown is at 300 Torr continuing

Laser safety glasses are required!

839

Fri Aug 15 11:52:32 2008

Multi-computer display and recording of digital camera output

Cameras

Through the magic of gstreamer, I've been able to live play on one machine, compress the image, send it to another machine via udp, and also display it there. The "tee" function also allows one to save at the same images at time as well.

The command line used on the "server", say Rosalba or Mafalda is:

CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! tee name=t1 t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! ximagesink t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host="131.215.113.103" port=5000

This both displays the image and sends it to the host 131.215.113.103 in this case.

I've written a primitive shell script that does most of this.

It requires at the minimum an IP address. You can also give it a number of images (the -m number) and also the exposure value (-E 20000).

Currently in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/ there is a script called CameraServerScript.

Typing in "CameraServerScript 131.215.113.107" would send it to that IP address.

Typing in "CameraServerScript 131.215.113.107 500 40000" would run for 500 images at an exposure value of 40000.

To actually receive, you need gstreamer installed and run the following command:

gst-launch udpsrc port=5000 ! smokedec ! queue ! ffmpegcolorspace ! ximagesink sync=false

Make sure you have the right IP address to send to.

Still working on multicasting (basically a server is constantly sending out images, and the client subscribes to the multicast).

838

Thu Aug 14 21:52:51 2008

Koji

Abs. Len. Meas. ~ summary of my Summer

General

I have made the summary of the absolute length measurement.
It is attached here. The file is a bit big (~8.6MB).

Attachment 1: mode_spacing_measurement_080816_v2.pdf

837

Thu Aug 14 19:35:54 2008

PRM in the chamber, ready to pump!

Rob, Yoichi, Jenne, Steve

Summary: Everything is back in the chamber, we just need to put on the big doors, and start pumping in the morning.

After letting the PRM's standoff epoxy cure overnight, it was time to put the optic back in the BS Chamber. Rob put the optic cage back in the chamber, as close to the guide points that Rana had placed as possible. A handy technique was discovered for pushing the cage into place: put a long screw into the table, leaving an inch or so above the table, then use that as a push-off point so that you can push the base of the cage with your thumb. According to Rob, this is probably just about as effective as using a pusher-screw.

The guides were helpful in getting the PRM back to its original position, but one of them was placed in such a way that it could move when pushed against. The clamp that was used as a guide point was placed with one of the screws half on the edge of a hole, so that when the cage was pushed against the guide point, that screw could wiggle around, causing the clamp to rotate thus no longer being a definite guide point.

Just after putting the PRM in place, Rob found the standoff that had gone missing. (see elog #835)

Once the PRM was back in place, we put the OSEMs back, and reinstalled the satellite boxes that had been removed (PRM's, which Ben has fixed - an op-amp was blown, and BS's, which we used over in the clean room with the spare OSEMs). We found a problem with the LR PRM OSEM reading on Dataviewer. It was saturating when the OSEM was just sitting on the table, with nothing between the LED and the sensor. We measured the output from the satellite box with the octopus cables, and measured 2.3 volts, which is too much for the DAQ. It seems fine when we install it in the cage, and the magnet is blocking part of the light. We should investigate the gain of the satellite box when convenient. This is not something that needs to be done prior to pump-down. Also, when we put an allen wrench to block the light while checking which OSEM was which, we noticed that the Dataviewer reading would go down to -2V, then come back to 0V when the light was completely blocked. This may be some incorrect compensation for some whitening. Again, we should look into this, but it is not terribly time-sensitive.

Once the OSEMs were centered, we tried to turn on the damping for the PRM. This was successful, so we are confident that we have put all of the OSEMs back in their correct places.

We found that we were easily able to get the PRM's oplev back on the QPD, so we ~centered the oplev, and then centered all of the PRM's OSEMs. This assumes that the oplev was in a good place, but I think we've determined that this is the case.

We did the same thing for the SRM and the BS, to check the OSEM values before we close up for good. We found that some of the SRM OSEMs were reading low (magnet too far in), and that all of the BS OSEMs were low, perhaps as if the table were tilted a tiny bit after removing and replacing the weight of the PRM. We recentered all of the OSEMs for both of these optics.

We checked that all of the pigtails for the PRM OSEMs were anchored to the PRM cage using some copper wire as tie-downs.

We checked that all of the earthquake stops were within 1mm or so of each of the 3 optics in the BS chamber. The SRM's earthquake stops were fairly far out. One of the bottom ones was far enough that when Yoichi turned it the wrong way (accidentally), it fell out. He put it back in, and adjusted all of the earthquake stops appropriately. This 1mm distance comes from Seji, and the specs for the optics' cages.

We did a look-through of the chamber, and took out all of the tools, and other things that were not bolted down to the table.

We have left the damping of the PRM off for the night.

To do: put the doors back on, and start the pump down.

836

Thu Aug 14 19:08:14 2008

Free swing measurement going on

I started free swinging spectra measurement of all the suspensions now Aug 14 19:05 (PDT).
The watch dogs are all shutdown. Please do not turn them back on until tomorrow morning.

835

Thu Aug 14 15:51:35 2008

FOUND! The Missing Standoff!

Cameras

We used a zoom lens on the GC750 to take this picture of the standoff while inside a plastic rubber-glove bag. The standoff with bag is currently scotch-taped to the periodic table of the elements.

Attachment 1: standoff.png

834

Thu Aug 14 11:39:06 2008

particle counter is out of order

PEM

The 40m ifo paricle counter sensor failed last night.

833

Thu Aug 14 10:26:45 2008

HowTo

sus cable pin cheater for out of vac damping

The 40m D25 vacuum feed troughs give you a mirror image pin count.

Sus damping outside of the vacuum envelope require this cheater cable where
on the male D pin 1 is connected to female D 13 and so on
and male D pin 14 is connected to female D 25 and so on

Attachment 1: suscabmin.png

832

Wed Aug 13 20:13:35 2008

PRM stand-off is glued

Steve, Janne, Rob, Bob, Koji, Yoichi

We finally managed to balance the PRM and the stand-off is now glued.

The whole procedure was something like this:

(1) Measure the levelness of the optical table. It was done by a bubble level claiming that
the sensitivity is 60 arcsec (roughly 0.3 mrad).
There was no noticeable tilt along the longitudinal direction of the table.

(2) We put a He-Ne laser on one end of the table. Mounted a QPD on a X-Y-Z stage. Put the QPD very
close to the laser and centered it by moving the QPD.
Then we moved the QPD far away from the laser and centered the beam spot in vertical direction
by changing the tilt of the laser mount.
We then moved the QPD close to the laser again and adjusted the height to center it. By repeating
the centering at two locations (near and far) several times, we aligned the laser beam parallel to
the table.

(3) The PRM suspension tower was put on the other end of the optical table, i.e. far from the laser.
The QPD was moved next to the laser to form an optical lever. The height of the QPD is preserved from
the previous step.

(4) A stand-off was picked by a pair of tweezers. By gently lifting the mirror by the bottom earthquake stops,
the tension of the wire was relieved. Then the stand off was slid in below the guide rod.

(5) Using the microscope, it was confirmed that the wire is in the grooves on both sides.

(6) Without damping, it was too much pain to balance the mirror. So we put spare OSEMs in the suspension and
pulled a long cable from the suspension rack to the clean room with a satellite amp.

(7) It turned out that the pinout of the cable is flipped because of the vacuum feed through. So we asked Ben for help.
He made conversion cables. We also found UR OSEM was not responding. Ben opened the satellite box, and we found an op-amp was burnt.
Probably it was because we connected OSEMs wrongly at first and the LED current driver was shorted. We switched the satellite box
from the PRM one to the BS one. Ben will fix the PRM box.
Bob cleaned up some D-Sub converters for the interface with the clean OSEM pigtails.

(8) While waiting for Ben, we also tried to short the OSEM coils for inductive damping. We saw no noticeable change in the Q.

(9) After the OSEMs were connected to the digital control system, Rob tweaked the damping gains a bit to make it work efficiently.

(10) I pushed the stand-off back and forth to make the reflected beam spot centered on the QPD. I used the PZT buzzer to gently move the stand-off.
For fine tune, just touching it is enough. I found it useful to touch it without clamping the mirror, because if it is clamped, we can easily push
it too hard. When the mirror is freely hanging, once the tip of the buzzer touches the stand-off, the mirror escapes immediately. If the mirror
swings wildly by your touch, you pushed it too hard.

(11) After about an hour of struggle, I was able to level the mirror. We used about 1.5m optical lever arm. A rough calibration tells us that the
beam spot is within 0.6mm of the center of the QPD. So the reflected light is deflected by 0.4mrad. That means the mirror
is rotated by 0.2mrad. The OSEMs should have about 30mrad of actuation range. So this should be fine.

(12) We mixed the Vac Seal epoxy and put it under vacuum for 15min to remove bubbles. Actually 15min was not enough for removing bubbles completely. But
stopped there because we did not want the epoxy to be too stiff.
I dipped a thin copper wire into the epoxy and applied it on the top of the stand-off. I found the epoxy is already not fluid enough, so Steve made
another Vac Seal mixture. This time we put it under vacuum for only 3 min.
I also applied the epoxy to the sides of the stand-off.
While working on this, I accidentally touched the side of the PRM. Now there is a drop of epoxy sitting there (upper left of the attached picture).
We decided not to wipe it out because we did not want to screw up the levelness.

(13) We put an incandescent light about 1m away from the suspension to gently warm up the epoxy but not too much. We will leave it overnight to cure the
epoxy.

Attachment 1: img1.jpg

831

Wed Aug 13 17:00:59 2008

The PRM sat amp is broken. Ben is working on it.
The BS sat amp was removed from the BS sus and it is used with the PRM in
order to damp it for wire stand-off alignment.

830

Tue Aug 12 21:38:19 2008

John

Accidental higher order mode resonances in the arms

LSC

Recently we had been having some trouble locking the full IFO in the spring configuration (SRC on +166).
It was thought that an accidental higher order mode resonance in the arms may have been causing problems.

I previously calculated the locations of the resonances using rough arm cavity parameters(Elog #690). Thanks to Koji
and Alberto I have been able to update this work with measured arm length and g factors for the y arm (Elog #801,#802).
I have also included the splitting of the modes caused by the astigmatic ETM. Code is attached.

I don't see any evidence of +166MHz resonances in the y arm.

In the attached plot different colours denote different frequencies +33, -33, +166, -166 & CR.
The numbers above each line are the mn of TEMmn.
Solid black line is the carrier resonance.

Attachment 1: HOMresonances.png

Attachment 2: HOMarms2.m

%Check for accidental resonances of HOM in the arms (maybe due to
%sidebands). At the moment there is only data for the y arm.

clear all
close all
clc


%Stuff one might change often
modeorder = 0:5;          % Look for TEMmn modes where m,n run over modeorder

... 157 more lines ...

829

Tue Aug 12 19:48:24 2008