ID |
Date |
Author |
Type |
Category |
Subject |
6446
|
Mon Mar 26 18:04:43 2012 |
kiwamu | Update | IOO | mode scan at the REFL port |
For those who are interested in the actual data, I attache the actual data in zip file together with a python plot code.
The distance was set such that the 1st steering mirror (the one at the very left in the previous cartoon diagram #6445 ) in the REFL path is positioned at zero.

- - - Fitting results (chi-square fitting done by gnuplot):
All values are in unit of meter
# PRM (v) (Last tree points are excluded as the beam were clipped at the aperture of the beam scan)
w0 = 0.0015114 +/- 2.192e-05 (1.451%)
z0 = -4.46073 +/- 0.05605 (1.256%)
# PRM (h)
w0 = 0.00212796 +/- 1.287e-05 (0.6049%)
z0 = -2.53079 +/- 0.1688 (6.668%)
# ITM (v) (Last two points are excluded as the beam were clipped at the aperture of the beam scan)
w0 = 0.00190696 +/- 4.964e-05 (2.603%)
z0 = -8.09908 +/- 0.1525 (1.882%)
# ITM (h)
w0 = 0.0032539 +/- 4.602e-05 (1.414%)
z0 = -1.89484 +/- 1.524 (80.42%)
|
Attachment 2: REFLmodescan.zip
|
6447
|
Mon Mar 26 23:47:54 2012 |
Suresh | Update | IOO | Beam Profile measurement: IPPOS beam |
[Keiko, Suresh]
Keiko and I measured the IPPOS beam profile. The fit parameters are :
|
Vertical |
Horizontal |
Waist (mm) |
2.77 |
2.48 |
Rayleigh length (m) |
23.5m |
15.87 |
Waist location (m) |
0.81 m |
1.85 |

The data files are attached. |
Attachment 2: BeamProfile_IPPOS.pdf
|
|
Attachment 3: BeamProfileData_IPPOS.xlsx
|
6448
|
Tue Mar 27 02:05:40 2012 |
Suresh | Update | IOO | Beam Profile measurement: IPPOS beam |
Quote: |
[Keiko, Suresh]
|
Vertical |
Horizontal |
Waist (mm) |
2.77 |
2.48 |
Rayleigh length (m) |
23.5m |
15.87 |
Waist location (m) |
0.81 m |
1.85 |

|
If we assume the nominal wavelength of the IR light to be 1064nm and constrain the Rayleigh length to be zr = (pi w0^2)/lambda we obtain the following fit parameters: (these are compared with the beam profile measurements of June/18/2010 available in the wiki )
|
Vertical |
Vertical
06/18/2010
|
Horizontal |
Horizontal
06/18/2010
|
waist (radius) (mm) |
2.77 |
2.81 |
2.47 |
2.91 |
Rayleigh length (m) (computed) |
22.62 |
|
18.14 |
|
Waist location w.r.t. to MM2 * |
3.37 |
5.36 |
4.15 |
1.96 |
* I updated the waist waist location coz because I missed-out the distance in air from the vacuum port to the optic on the IPPOS table.

|
Attachment 1: BeamProfile_IPPOS.png
|
|
6449
|
Tue Mar 27 02:18:31 2012 |
keiko | Update | IOO | Beam Profile measurement: IPPOS beam |
Keiko, Rana, Suresh
Related to the beam profile of IPPOS today, we tried to measure the beam size at the ETMY point in order to estimate the input beam mode. We measured the beam size hitting at the suspension frame by a camera image, with two situations to see two "z" for beam profile.
(1) Input beam is slightly misaligned and the injected beam hits the end mirror frame. Assuming z=0 at the input mirror, this should be z=40m.
(2) Input beam hits the centre of the end mirror, and ITMY is slightly misaligned and the beam hits the end mirror frame after the one-round trip. Assuming z=0 at the ITM, this position should be z=120m.

The injected beam at the end point and the one round trip ligt at the end point should be the same size, if the input mode matches to the cavity mode. You can see if your injected light is good for the cavity or not. We compared and assumed the above two beam sizes by looking at the photo of the beam spot.
(1) (2) 
Assuming the zoom factor difference by the part below the beam (shown with allow in the photos. Arbitrary unit.), the beam in (2) is smaller than expected (roughly 40%?).
However this is a very rough estimation of the beam sizes! It is difficult to assume the beam size shown on the photos! It looks smaller only because the power of (2) is smaller than of (1). I don't think we can say anything from this rough estimation. One may be able to estimate better with CCD camera instead of this normal camera.
|
Attachment 1: text9149.png
|
|
6450
|
Tue Mar 27 02:46:28 2012 |
kiwamu | Update | IOO | REFL beam available |
The dump and some temporary mirrors were removed and now the REFL beam is available again.
I locked PRMI with REFL signals, it locked as usual.
Quote from #6440 |
Currently the REFL beam is bypassed by additional mirrors and blocked by a razor blade dump.
|
|
6451
|
Tue Mar 27 11:54:18 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
I'd like to know what we expect for these numbers. I've added to Kiwamu's drawing some more distances, so I can calculate the expected beam size at the IPPOS port.

Quote: |
|
Vertical |
Vertical
06/18/2010
|
Horizontal |
Horizontal
06/18/2010
|
waist (radius) (mm) |
2.77 |
2.81 |
2.47 |
2.91 |
Rayleigh length (m) (computed) |
22.62 |
|
18.14 |
|
Waist location w.r.t. to MM2 * |
3.37 |
5.36 |
4.15 |
1.96 |
|
|
6452
|
Tue Mar 27 16:06:59 2012 |
keiko | Update | IOO | Beam Profile measurement: IPPOS beam |
I changed the ETMY CCD camera angle so that we can see the suspension frame in order to repeat the same thing as yesterday. The ETMY camera is not looking at the beam or mirror right now. |
6453
|
Tue Mar 27 17:19:02 2012 |
Koji | Update | IOO | Beam Profile measurement: IPPOS beam |
The mode looks quite terrible in the plot, but in reality it is an illusion of the plot.
The actual TEM00 content in this beam is ~99.7%
mode_coupling.pdf
Based on the above document, you can calculate power coupling between two elliptic gaussian modes.
Give the parameters of one beam as
zRy1 = pi*(2.77e-3)^2 / 1064e-9
z1y = 3.37
zRx1 = pi*(2.47e-3)^2 / 1064e-9
z1x = 4.15
Then, assume a round beam for the other.
zRx2 = zRy2 = zR
z2x = z2y = z0
Then run the optimizer to find the maximum for the quantity |C|^2
|C|^2 max: 0.9967
zR = 20.19
z0 = 3.804
|
6454
|
Tue Mar 27 17:38:03 2012 |
Jenne | Update | IOO | Another possibility / thought |
I'm meditating over the mode matching from the mode cleaner to the ITMs, and I had another thought:
Have we changed the pointing of the MC significantly enough that we are no longer on the center of the MMT mirrors? To be this significant, we would probably also have had to scoot the Faraday a bit too, since it's skinny like a straw. It looks like our measurements of the input beam have been the following:
MC waist, 21 May 2010
After MMT2, 18 June 2010 (a few days before this, we flipped the MMT2 mount to 'perfect' the mode matching up to 99.3%, so I don't think the MMT has moved since then.)
After MMT2, 26 March 2012
There's a big o' ~2 year gap between our measurements, and we've been in and out of the vacuum a few times since then. I'll flip through the elog, but does anyone have any memory of us moving the Faraday after June 2010? When was the last time we made sure that we were at least close to the center of the MMT mirrors? |
6455
|
Tue Mar 27 17:52:08 2012 |
Koji | Update | IOO | Another possibility / thought |
It is quite likely that we touched the Faraday in Nov 2010.
In this entry http://nodus.ligo.caltech.edu:8080/40m/3874 I wrote that I removed the MCT optics in the chamber.
This is the pickoff between the IMC and the Faraday. This causes the beam shift. Therefore, the Faraday had
to be moved.
There were intensive in-chamber activities from Nov to Dec 2010. I am sure that almost everytime we went into
the chamber, we checked the spot position on the MMT mirrors as well as the TT and PZT mirrors.
Does the miscentering of the spots on the MMT mirrors cause the mode matching significantly changed? |
6456
|
Tue Mar 27 18:03:46 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
This is wrong! See following elog for corrected plot (and explanation)
I'm not done meditating on what's going on, but here's what I've got right now:

This is a beam profile, using the distances from the combined Kiwamu / Jenne sketch earlier today.
0 meters along the horizontal axis is meters from the Mode Cleaner waist. (Yes, I was bad and forgot to label it. Get over it.)
The pink and green dots to the left of the plot are the MC fitted waist measurements that we made in May 2010.
The pink and green dots in the ~center of the plot are the fitted waist measurements that Suresh and Keiko took yesterday, of the IPPOS path, so after the MMT.
The black dot is where we would like our non-astigmatic beam to be. This is the calculated waist size of the cavity mode, using the new ~37.76m distance, after we moved the ETMs to their current positions. The black dot indicates 3.036 mm at the ITM (averaged between the BS-ITMX and BS-ITMY distances).
The moral of the story that I'm getting from this plot: something funny is going on.
The distances Kiwamu quoted on the sketch are very close to the ones that I used for designing and checking the MMT in the first place, which were based off of measurements using rulers etc to measure distances. Steve said he looked at photos today, and agreed that Kiwamu's numbers looked reasonable also.
Something that we haven't done lately is measure the position of each optic from every other optic, along the beam path. I propose we come up with a clever way to put a target on top of / next to mirrors, and then a way to hold the laser distance measure-er at an optic, so that we can go thorough systematically and measure the actual path that our beam is seeing. Maybe this is too much work, and not worth it, but it would make me happier. In my head, these 'fixtures' are just small pieces of cleaned aluminum, one that can sit on a mirror mount, and one which we can use to align the laser ruler to approximately the front of an optic. Nothing fancy. |
6457
|
Tue Mar 27 21:20:32 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
Quote: |
The moral of the story that I'm getting from this plot: something funny is going on.
|
Yup, something funny was going on. Nic's MM code that I used, "a la mode", calls for the focal length of the optics, whereas the code that I wrote and used for ages called for the radius of curvature. f = R/2. Fixing that factor of 2 I get something more like:

This is obviously much better, in that the beam profile goes through (within some error) both of the measured sets of points - the MC waist measured in May 2010, and after the MMT measured yesterday.
So, what does it all mean? That I'm not sure of yet. |
6458
|
Tue Mar 27 21:37:51 2012 |
keiko | Configuration | IOO | Beam Profile measurement: IPPOS beam |
From the mode measurement I and Suresh have done yesterday, I calculated what beam size we expect at ETM ((1) upper Fig.1) and at ETM after one bounce ((2) lower Fig.1).

Fig.1 (Yarm)
In case of (1), we expect approximately w=6300 um (radius), and w=4800 um for one-bounce spot (2) from the measured mode, see Fig.2.

Fig.2
This roughly agree with what we observed on CCD camera. See, pic1 for (1) and pic2 for (2). The spot at the ETMY (1) is larger than the one-bounced spot (2). From the monitor it is difficult to assume the radius ratio. The observed spot of (2) is a bit smaller than the prediction. It could happnen when (A) the ETMY (as a lens) is slightly back of the ideal position (= the distance between the ITM and ETM is longer than 40m) (B) the real waist is farer than ITM position toward MC (I assumed roughly 5 m from Jenne's plot, but could be longer than that).

pic1 (left): beam spot hitting on the suspension frame. pic 2 (right): the one-bounced beam spot hitting on the suspension frame.
|
Attachment 1: expsche.png
|
|
Attachment 3: mmtdrawing.png
|
|
Attachment 4: drawing.png
|
|
Attachment 5: drawing.png
|
|
Attachment 8: drawing.png
|
|
6459
|
Tue Mar 27 23:37:35 2012 |
Suresh | Update | IOO | Beam Profile measurement: IPPOS beam |
Quote: |
Quote: |
The moral of the story that I'm getting from this plot: something funny is going on.
|
Yup, something funny was going on. Nic's MM code that I used, "a la mode", calls for the focal length of the optics, whereas the code that I wrote and used for ages called for the radius of curvature. f = R/2. Fixing that factor of 2 I get something more like:
.....
So, what does it all mean? That I'm not sure of yet.
|
In an attempt to estimate the errors on the fit parameters I upgraded my Mathematica code to use the function 'NonlinearModelFit', which allows us to define weights and also reports the errors on the fit parameters. The plots have been upgraded to show the error bars and residuals.

The parameters determined are given below and compared to the earlier measurements of 06/18/2010
Vertical Profile:
Parameter |
Estimate |
Standard Error |
95% Confidence interval |
06/18/2010 measurement |
Waist (mm) |
2.768 |
0.005 |
2.757 -- 2.779 |
2.81 |
Waist location from MMT2 (m) |
5.85 |
0.12 |
5.625-- 6.093 |
5.36 |
Horizontal Profile:
Parameter |
Estimate |
Standard Error |
95% Confidence Interval |
06/18.2010 measurement |
Waist (mm) |
2.476 |
0.009 |
2.455 -- 2.496 |
2.91 |
Waist Location from MMT2 (m) |
4.935 |
0.145 |
4.645 -- 5.225 |
1.96 |
There is a significant change in the beam waist location (as compared to previous report) because I corrected a mistake in the sign convention that I was using in measuring the distances to the waist from the zero-reference.
|
6460
|
Wed Mar 28 01:17:29 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
As I was a little dissatisfied with the inaccuracy in the distance numbers in Kiwamu's sketch, I went back to the 18 Dec 2010 table layout drawing for more accurate numbers. These are now included in this round of plots.
Also, I include astigmatism due to the incident angles on MMT1 (~3.5 deg) and MMT2 (~1 deg).
First plot, IPPOS path, using the recent (fixed) measurements from Suresh to fix the beam width. Note that the old 2010 measurements of the MC waist are consistent with this measurement.
Second plot, Main IFO path all the way to the ITM (average) position, using the 2010 MC waist measurements to fix the beam width.
Third plot, Main IFO path all the way to the ITM position, but with PRM flipped (negative RoC), using the 2010 MC measurement to fix beam width.
With the PRM correctly oriented (2nd plot), I get beam waists of (x = 2.529 mm, y = 2.646 mm), which corresponds to a mode matching to the arm cavity of (eta = 97.43%, PRM correct).
With the PRM flipped (3rd plot), I get beam waists of (x = 3.176 mm, y = 3.3 mm), which corresponds to a mode matching to the arm cavity of (eta = 99.55%, PRM flipped).
First plot:

Second plot (this is how the MMT was designed to be, before the ETMs were moved, which made the ideal waist larger):

Third plot:

For both the 2nd and 3rd plot, we can't look at the post-MMT waist measurements, since that distance on the plots is after the PRM, which is a curved optic. So the fact that the post-MMT measurements match the correct-PRM plot better than the flipped-PRM plot can't be taken to be meaningful.
Moral of the story: I'm not sure how to interpret any of this to tell us if the PRM is flipped or not, since the measurements are all of the beam profile before the beam sees the PRM. We'd have to measure the profile after the PRM somehow in order to get that information. We have okay but not great mode matching to the arm if the PRM is correct, but I don't know that we readjusted the MMT after we moved the ETMs. I don't remember recalculating any optimal telescope lengths after the arm length change. If we need better mode matching, I can do that calculation, although given how much space we don't have, it would be hard in practice to move the MMT mirrors by much at all. |
6461
|
Wed Mar 28 18:26:47 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
More calculations....
Game Plan: Using MC waist measured beam as the starting point of beam propagation, move MMT mirrors around until the beam profile fits with the IPPOS measurements from Monday.
Plot 1: Allow MMT mirrors to move as much as they want to. Note that the Y-beam goes through the IPPOS measured point. (This implies we put the MMT in the wrong place by ~half a meter. Unlikely)
Plot 2: Using MMT locations from plot 1, what does the beam look like at the ITMs?
Plot 3: Allow MMT mirrors to move as much as 2cm. Note that the Y-beam doesn't quite go through IPPOS measured point.
Plot 4: Using MMT locations from plot 3, what does the beam look like at the ITMs?
For all of the above, I was optimizing the propagation of the Y-beam profile. Since the X-beam profile measurement is so different, if I want to optimize to X and let the MMT mirrors move as much as they want, MMT1 ends up inside the MC. Unlikely. So I'm just looking at Y for now, and maybe Suresh or someone needs to rethink the error bars on their measurements or just remeasure.
Plot 1:

Plot 2:

Plot 3:

Plot 4:

|
6462
|
Wed Mar 28 20:54:02 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.
Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design). The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters. Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?

|
Attachment 1: MMT_moved_by_1pt3meters_MMT1th_25_MMT2th_12_LowRes.png
|
|
6463
|
Wed Mar 28 21:15:53 2012 |
rana | Omnistructure | Computers | Wireless router for GC |
I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.
The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed. |
6464
|
Thu Mar 29 11:29:27 2012 |
keiko | Update | LSC | POP22/POP110 amplifires |
Yesterday I and Kiwamu connected two amplifiers (mini-circuit, ZFL-1000LNB+) for POP22/110. Dataviewer can see some signals. I'll test the signal levels and freq components before the rack just in case. [Kiwamu, Keiko] |
6465
|
Thu Mar 29 13:23:05 2012 |
Jenne | Omnistructure | Computers | Wireless router for GC |
Quote: |
I installed a NETGEAR Wireless Router (WPN824N) today on the 131 network. The admin password for it as well as the wireless access password are in the usual places.
The SSID is 40EARTH. I have set it to allow WPA as well as WPA2 access, so the speed is only 54 Mbps for now. In a year or so, we can turn off the WPA support and up the speed.
|
This router was confiscated by the GC guys this morning around ~10am. They barged in and said that someone at the 40m had connected a new router, and we had magically taken down half of the GC network. The cable was plugged in to the wrong port on the back of the router.
Junaid / Christian said that they would "secure" the router, and then reinstall it. Apparently just having a password didn't satisfy them. This was the compromise, versus them just taking the router and never bringing it back.
|
Attachment 1: IMG_0079.JPG
|
|
6466
|
Thu Mar 29 18:42:11 2012 |
keiko | Update | LSC | POP22/POP110 amplifires |
Adding two amplifiers on POP22/110, I checked the signals going to the dmod board of 22 and 110.
The signal flows: Photodetector of POP --> Amp1 --> Amp2 --> RF splotter --> bandpass filter for 22MHz / 110MHz --> 22MHz / 110MHz demod board.
Here is the picture of RF spectrum just after the bandpass filter of 22MHz going to the 22MHz demod board. The signal peak at 22MHz is about -40dBm. There is a structure slightly lower than 22MHz.

The below is the RF spectrum for 110MHz branch. The peak at 110MHz is about -15dBm. The peak on the left of 110MHz is 66MHz peak.

Quote: |
Yesterday I and Kiwamu connected two amplifiers (mini-circuit, ZFL-1000LNB+) for POP22/110. Dataviewer can see some signals. I'll test the signal levels and freq components before the rack just in case. [Kiwamu, Keiko]
|
|
6467
|
Thu Mar 29 19:13:56 2012 |
Jamie | Omnistructure | Computers | Wireless router for GC |
I retrieved the newly "secured" router from Junaid. It had apparently been hooked up to the GC network via it's LAN port, but it's LAN services had no been shut off. It was therefore offering a competing DHCP server, which will totally hose a network. A definite NONO.
The new SSID is "40mWiFi", it's WPA2, and the password is pasted to the bottom of the unit (the unit is back in it's original spot on the office computer rack. |
6468
|
Thu Mar 29 20:13:21 2012 |
jamie | Configuration | PEM | PEM_SLOW (i.e. seismic RMS) channels added to fb master |
I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels:
[C1:PEM-RMS_ACC6_1_3]
[C1:PEM-RMS_GUR2Y_0p3_1]
[C1:PEM-RMS_STS1X_3_10]
etc.
I also updated the path to the other _SLOW.ini files.
I DID NOT RESTART FB.
I will do it first thing in the am tomorrow, when Kiwamu is not busy getting real work done.
Here's is a the diff for /opt/rtcds/caltech/c1/target/fb/master:h
controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1$ diff -u master~ master
--- master~ 2011-09-15 17:32:24.000000000 -0700
+++ master 2012-03-29 19:51:52.000000000 -0700
@@ -7,11 +7,12 @@
/opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini
/opt/rtcds/caltech/c1/chans/daq/C1MCS.ini
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1mcs.par
-/cvs/cds/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/RMS_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/IOP_SLOW.ini
-/cvs/cds/rtcds/caltech/c1/chans/daq/IOO_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/SUS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/MCS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/RMS_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/IOP_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/IOO_SLOW.ini
+/opt/rtcds/caltech/c1/chans/daq/PEM_SLOW.ini
/opt/rtcds/caltech/c1/target/gds/param/tpchn_c1rfm.par
/opt/rtcds/caltech/c1/chans/daq/C1RFM.ini
/opt/rtcds/caltech/c1/chans/daq/C1IOO.ini
controls@pianosa:/opt/rtcds/caltech/c1/target/fb 1$
|
6469
|
Fri Mar 30 08:58:37 2012 |
steve | Update | SAFETY | Safety glasses checked |
Bob cleaned all safety glasses in 10 % Liquinox soap in water solution first. The transmittance of glasses were checked at 100 mW 1064 nm S polarization, beam diameter 0.5 mm at 0-20 deg incident.
Coherent FieldMate power meter measured T= < 1 mW of all glasses. |
Attachment 1: safety_glasses_checked.jpg
|
|
6470
|
Fri Mar 30 09:37:13 2012 |
steve | Update | SAFETY | safety audit 2012 CORRECTIONS |
Quote: |
Correction list by visiting safety committee, Haick Issaian is not shown:
1, update laser, crane operator list and post it
2, check fire extinguishers monthly, date and initials must be on the tags
3, move drinking water tower so it does not block fire extinguisher
4, post updated crane doc at cranes
5, post present phone lists at IFO room phones
6, emergency laser shutoff at the south end must be mounted without C-clamp
7, use heavy cable tie to insure position of mag-fan on cabinet top
Additional to do list:
a, safety glasses to be cleaned
b, let the electrical shop fix Rack-AC power to optical tables at the ends
c, measure transmission of laser safety glasses
d, update IFO outside door info signs
e, update laser inventory and post it
f, schedule annual crane inspection and renew maintenance contract
g, PSL enclosure inner shelf needs a good clean up so it is earthquake safe
|
Completed with the exception of d and g |
6471
|
Fri Mar 30 10:20:51 2012 |
kiwamu | Update | LSC | locking last night |
I was trying to make the DRMI lock more robust.
Increasing the gains of the oplev on SRM helped a lot, but the lock is still not solid enough for measurements.
According to some line injection tests, the SRCL and MICH signals show up in AS55Q with almost the same amplitudes.
I tried to diagonalize the input matrix (particularly MICH-SRCL in AS55) based on the result of the line injection tests, but I ran out the time.
Work continues. |
6472
|
Fri Mar 30 10:24:14 2012 |
steve | Update | SUS | new OSEM locking plunger |
Quote: |
Quote: |
Our existing 300 series SS plungers from McMastercar #8476A43 are silver plated as Atm2 shows.
Problems: 1, they become magnetized after years being close to the magnets
2, they oxidize by time so it is hard to turn them
I looked around to replace them.
Titanium body, nose and beryllium copper spring. None magnetic for UHV enviorment.
Can be made in 7 weeks at an UNREASONABLE $169.00 ea at quantity of 50
|
In order to get a better price from Vlier's Tom Chen I changed Ti body back to SS304L-siver plated and music wire spring. The price is still ~$120 ea. at quantity 50
I will talk to Mike G about modifying the McMaster plunger with a hex nut.
|
Conclusion: There is no need to silver plate the SS plunger at the torque level we hold the OSEMs
Mike Gerfen will be done with 50 pieces by April 4 and he will give them to Bob for cleaning. They should be cleaned and baked in a jig so the springs would be compressed for better venting. |
Attachment 1: new_OSEM_locker_screw.jpg
|
|
Attachment 2: IMG_0109.JPG
|
|
Attachment 3: IMG_0111.JPG
|
|
6473
|
Fri Mar 30 17:37:09 2012 |
steve | Update | General | cutting green welding glass for beam dumps |
Quote: |
Schott, green welding glass, shade 14, 3 mm thick was measured in the beam path of 1.2W, S polarization of 1064nm at ~1 mm diameter size as MC reflected path.
Absorption 95%, R 5% at incident angle 25-50 degrees. It looks like the perfect material for beam trap.
|
The CIT Chemistry Glass Shop cuts turned out to be sloppy using diamond disc blade cutter.
East coast Precision Glass & Optics offered scribed cut and polished side. Their quote price was high and time consuming.
The GLASS HOUSE shop in Pasadena 626 / 796-9151 on Walnut did a good and cheap job. Oscar the cutter will finish the rest of the cutting by next Friday, April 6
He used scribed cutting technic and his 1" x 0.5" pieces are good. Bob will pick up them up. |
Attachment 1: IMG_0096.JPG
|
|
6474
|
Sat Mar 31 08:01:07 2012 |
kiwamu | Update | LSC | DRMI measurement |
I have measured the sensing matrix of the DRMI although the lock still doesn't stay for a long time.
As for the noise budget, it looks very tough as there are more glitches than that in the PRMI.
In this weekend I will take some more trials in the DRMI lock until I am satisfied. |
6475
|
Mon Apr 2 18:24:34 2012 |
keiko | Update | LSC | RAM simulation for Full ifo |
I extended my RAM script from DRMI (3DoF) to the full IFO (5DoF).
Again, it calculates the operation point offsets for each DoF from the opt model with RAM. Then the position offsets are added to the model, and calculates the LSC matrix. RAM level is assumed as 0.1% of the PM modulation level, as usual, and lossless for a simple model.
Original matrix without RAM:
REFL f1 : 1.000000 0.000000 0.000008 -0.000005 0.000003
AS f2 : 0.000001 1.000000 0.000005 -0.003523 -0.000001
POP f1 : -3956.958708 -0.000183 1.000000 0.019064 0.000055
POP f2 : -32.766392 -0.154433 -0.072624 1.000000 0.024289
POP f2 : 922.415913 -0.006625 1.488912 0.042962 1.000000
(MICH and SRCL uses the same sensor, with optimised demodulation phase for each DoF.)
Operation position offsets are:
PRCL -3.9125e-11 m
SRCL 9.1250e-12 m
CARM 5.0000e-15 m
and no position offsets for DARM and MICH (because they are differential sensor and not affected by RAM offsets).
Resulting matrix with RAM + RAM offsets, normalised by the original matrix:
REFL f1 : 0.001663 -0.000000 0.003519 0.000005 -0.000003
AS f2 : 0.000004 0.514424 0.000004 -0.001676 -0.000001
POP f1 : 7.140984 -0.001205 15.051807 0.019254 0.000417
POP f2 : 0.029112 -0.319792 0.042583 1.000460 0.024298
POP f2 : -0.310318 -0.014385 -1.761519 0.043005 0.999819
As you can see in the second matrix, the CARM and DARM rows are completely destroyed by the RAM offsets! The signals are half reduced in the DARM case, so the mixture between DARM and MICH are about 50% degraded.
I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?
|
6476
|
Mon Apr 2 18:58:32 2012 |
Jenne | Update | IOO | Beam Profile measurement: IPPOS beam |
Suresh noted that I never wrote down the waist positions of the beam propagated through the MMT (based on where we think it is from ruler-based measurements). This uses the MC waist measured beam as the starting point, and just propagates through the MMT, out to the IPPOS port.
Yq:
Properties:
q: 2.2488 +23.8777i
lambda: 1.0640e-06
waistSize: 0.0028 (at z = 13.2676 meters)
waistZ: 2.2488 (relative to z = 13.2676 meters)
divergenceAngle: 1.1910e-04
radiusOfCurvature: 255.7849
beamWidth: 0.0029
rayleighRange: 23.8777
So, to sum up, the vertical beam waist is 2.8438 mm at 11.0188 meters from the MC waist.
Xq:
Properties:
q: 5.1953 +24.7342i
lambda: 1.0640e-06
waistSize: 0.0029 (at z = 13.2676 meters)
waistZ: 5.1953 (relative to z = 13.2676 meters)
divergenceAngle: 1.1702e-04
radiusOfCurvature: 122.9525
beamWidth: 0.0030
rayleighRange: 24.7342
So, to sum up, the horizontal beam waist is 2.8943 mm at 8.0723 meters from the MC waist.
In pictorial form,

|
6477
|
Mon Apr 2 23:06:38 2012 |
Suresh | Update | IOO | Beam Profile measurement: IPPOS beam: Mystery deepens |
Quote: |
I fitzed by hand with the numbers for the incident angles on MMT1 and MMT2, and then let the code optimize the position of MMT1 and MMT2.
Here I have set the incident angle for MMT1 = 25deg, and MMT2 = 12deg (should be 3.5deg, 1deg by design). The length of the telescope doesn't want to change by more than 7mm, but the position of the telescope wants to change by 1.3meters. Is it possible that the distances on the Monday IPPOS measurements aren't actually correct?
|
I am trying to track down possible errors in our measurements.
So as a first step I am recomputing the IPPOS waist location with respect to the MC waist, using the same optical layout diagram as the one used by Jenne in her calculations. Pic of Jenne's lab notebook showing location of optics is attached.
IPPOS: measurement elog 6459: |
Vertical |
Std.Error |
Horizontal |
Std.Error |
Waist |
2.768 mm |
5 microns |
2.476 mm |
10 microns |
Waist location from MC waist |
12.411 m |
17 mm |
9.572 m |
54 mm |
Std Dev of residuals from fit function
|
|
37 microns |
|
54 microns |
Let us compare it with the old measurement of the IPPOS beam from June/18/2010.
IPPOS: measurement June 18th 2010 |
Vertical |
Std.Error |
Horizontal |
Std.Error |
Waist |
2. 812mm |
8 microns |
2.909 mm |
20 microns |
Waist location from MC waist |
9.265 m |
224 mm |
5.869 m |
415 mm |
Std Dev of residuals from fit function
|
|
~ 25 microns |
|
~25 microns |
Note that there is a discrepancy of about 3.2 m in the waist location for the vertical profile and about 3.5 m for the horizontal profile between these two measurements.
Let us compare these measurements with what is expected from calculations. Jenne uses the known parameters of MC waist and the locations of the MMT optics to compute the parameters for the IPPOS beam:
IPPOS: Jenne's Calculations elog 6476:
|
Vertical |
Std.Error |
Horizontal |
Std.Error |
Waist |
2.844 mm |
|
2.894 mm |
|
Waist location from MC waist |
11.019 m |
|
8.072 m |
|
As the 2010 measurements are reported wrt to MMT2 and calculations are wrt MCwaist, I have used the distance between the MCwaist to MMT2 = 3.910 m to shift the reference from MMT2 to MC waist. Refer to the attached diagram from Jenne's notes for this MMT2 <--> MC waist distance.
There is a discrepancy of 1.5 meters between the calculations and recently measured waist location. The discrepancy with the 18Jun2010 measurement is much larger, about 3 meters in both v and h.
Are such variations to be expected between two successive measurements? I looked at another case where we have two measurements of a beam to see what to expect.
I looked at the REFL (Reflection from PRM) case, where we repeated a measurement, to see how much variation could happen in w0 and zr, between repeated measurements. This was a particularly bad case as our first attempt had problems due to OL servo loop oscillations in the PRM suspension damping. We fixed that later and measurement 2 has smaller residuals. And I think we are doing okay in IPPOS case as seen by the reduced scatter of the residuals.
These are the fits from the REFL beam measurement 1
REFL: Reflection from PRM: measurement 1 |
Vertical |
Error |
Horizontal |
Error |
Waist |
1.662 mm |
4 microns |
2.185 mm |
4 microns |
Waist location from MMT2 after reflection at PRM |
1.781 m |
17 mm |
4.620 m |
53 mm |
Std.Dev. of residuals from fit function |
|
61 microns |
|
98 microns |
I have also recomputed the fits to the data from REFL beam measurement 2. They match the earlier fits reported by kiwamu in his elog 6446
REFL: Reflection from PRM: measurement 2 |
Vertical |
Error |
Horizontal |
Error |
Waist |
1.511 mm |
3 microns |
2.128 mm |
3 microns |
Waist location from MMT2 after reflection at PRM |
1.281 m |
9 mm |
3.211 m |
37 mm |
Std. Dev of residuals from fit function |
|
58 microns |
|
61 microns |
Note that between these two measurements the beam waist location has shifted by 0.5 m for the vertical and about 1.3 m for the horizontal cases. So variations of 1.5 m in the waist locations are possible if we are not careful. But this is a particularly extreme example, I think we are doing better now and the measurement is unlikely to change significantly if we repeat it.
Some notes:
Fits for IPPOS and both REFL measurements 1 and 2 are attached.
The zero reference for the z axis of the IPPOS beam plot is at a distance of 6.719 m from MC waist for a beam propagating towards the IPPOS QPD.
The zero reference for the z axis of the REFL beam plots is at a distance of 5.741 m from the MMT2 in the direction of a beam reflected by PRM and propagating towards the REFL port.
|
Attachment 1: 40mOpticsLocations.pdf
|
|
Attachment 2: Beam-Profile_IPPOS_wError.pdf
|
|
Attachment 3: Beam-Profile_PRM_1_wError.pdf
|
|
6478
|
Tue Apr 3 01:52:15 2012 |
Zach | Update | LSC | RAM simulation for Full ifo |
Quote: |
I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?
|
I don't think I understand the question. AS_DC should not have a zero crossing, correct? |
6479
|
Tue Apr 3 12:42:19 2012 |
Mike J. | Update | Computers | Hysteresis Model |
Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency2) as a solution to y''+frequency2*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code. |
Attachment 1: hysteresis1.mdl
|
Model {
Name "hysteresis1"
Version 7.6
MdlSubVersion 0
GraphicalInterface {
NumRootInports 0
NumRootOutports 0
ParameterArgumentNames ""
ComputedModelVersion "1.9"
NumModelReferences 0
... 734 more lines ...
|
6480
|
Tue Apr 3 14:11:33 2012 |
keiko | Update | LSC | RAM simulation for Full ifo |
Quote: |
Quote: |
I also would like to extend this script to use the DC readout, but don't know how to calculate the postion offset for AS_DC because the error signal is not zero-crossing for AS_DC anymore. Do you have any suggestions for me?
|
I don't think I understand the question. AS_DC should not have a zero crossing, correct?
|
That's right. I calculate the offset of the operation point (when you have RAM) from the zero-crossing point of the PDH signals. I don't know how to do that for AS_DC, because it doesn't cross zero anymore anytime. |
6481
|
Tue Apr 3 14:17:18 2012 |
keiko | Update | LSC | RAM simulation for Full ifo |
I add a flow-chart drawing what the scripts do and how the scripts calculate the LSC matrix.

(1) First, you calculate the LSC matrix WITHOUT RAM or anything, just for a reference. This is the first matrix shown in the quoted post.
(2) The script calculates the LSC matrix with RAM. Also, the heterodyne signals for all 5 DoF are calculated. The signals have offsets due to the RAM effect. The operating position offsets are saved for the next round.
(3) The script calculates the LSC matrix again, with RAM plus the offset of the operation points. The matrix is shown in the last part of the quoted post.
Now I am going to check (A) LSC matrices (matrix 2, the second matrix of above chart) with different RAM levels (B) Are pos-offsets degrade the CARM and DARM so much (See, the quated result below), is that true?
Quote: |
Original matrix without RAM:
REFL f1 : 1.000000 0.000000 0.000008 -0.000005 0.000003
AS f2 : 0.000001 1.000000 0.000005 -0.003523 -0.000001
POP f1 : -3956.958708 -0.000183 1.000000 0.019064 0.000055
POP f2 : -32.766392 -0.154433 -0.072624 1.000000 0.024289
POP f2 : 922.415913 -0.006625 1.488912 0.042962 1.000000
(MICH and SRCL uses the same sensor, with optimised demodulation phase for each DoF.)
Operation position offsets are:
PRCL -3.9125e-11 m
SRCL 9.1250e-12 m
CARM 5.0000e-15 m
and no position offsets for DARM and MICH (because they are differential sensor and not affected by RAM offsets).
Resulting matrix with RAM + RAM offsets, normalised by the original matrix:
REFL f1 : 0.001663 -0.000000 0.003519 0.000005 -0.000003
AS f2 : 0.000004 0.514424 0.000004 -0.001676 -0.000001
POP f1 : 7.140984 -0.001205 15.051807 0.019254 0.000417
POP f2 : 0.029112 -0.319792 0.042583 1.000460 0.024298
POP f2 : -0.310318 -0.014385 -1.761519 0.043005 0.999819
|
|
6482
|
Tue Apr 3 15:50:58 2012 |
keiko | Update | LSC | RAM simulation for Full ifo |
Oops, Yesterday's results for DARM was wrong!
I got more convincing results now.
> (B) Are pos-offsets degrade the CARM and DARM so much (See, the quoted result below), is that true?
Here is the new results. It does change CARM a lot, but not DARM:
Matrix1 (normalised so that the diagonals are 1):
REFL f1 : 1.000000 0.000000 0.000008 -0.000005 0.000003
AS f2 : 0.000001 1.000000 0.000005 -0.003523 -0.000001
POP f1 : -3956.958708 -0.000183 1.000000 0.019064 0.000055
POP f2 : -32.766392 -0.154433 -0.072624 1.000000 0.024289
POP f2 : 922.415913 -0.006625 1.488912 0.042962 1.000000
(=Matrix 2)
Position offsets:
only CARM, 4.6e-16 (this number changed because I increased the resolution of the calculation)
Matrix3 (normalised by matrix 1):
REFL f1 : 0.039780 -0.000000 0.003656 0.000005 -0.000003
AS f2 : 0.000008 1.000017 0.000005 -0.003499 -0.000001
POP f1 : 159.146819 -0.000138 15.605155 0.019393 0.000055
POP f2 : 1.277223 -0.154415 0.047344 1.000008 0.024289
POP f2 : -35.422498 -0.006633 -1.886454 0.042963 1.000000
- CARM got a small position offset which degrades CARM signal 2 orders of mag (still the biggest signal in the sensor, though).
- DARM was not so bad, and probably the change of the DoF mixture is mostly not changed.
- Matrices don't change only with 1e-4 RAM. It changes with position offsets.
- I'll see how the matrix changes without position offsets but only with RAM effects, changing RAM levels.
- Again, above is C1 configuration, 1e-4 RAM level of PM level.
Quote: |
I add a flow-chart drawing what the scripts do and how the scripts calculate the LSC matrix.

(1) First, you calculate the LSC matrix WITHOUT RAM or anything, just for a reference. This is the first matrix shown in the quoted post.
(2) The script calculates the LSC matrix with RAM. Also, the PDH signals for all 5 DoF are calculated. The PDH signals have offsets due to the RAM effect. The operating position offsets are saved for the next round.
(3) The script calculates the LSC matrix again, with RAM plus the offset of the operation points. The matrix is shown in the last part of the quoted post.
Now I am going to check (A) LSC matrices (matrix 2, the second matrix of above chart) with different RAM levels (B) Are pos-offsets degrade the CARM and DARM so much (See, the quated result below), is that true?
|
|
6483
|
Tue Apr 3 22:50:37 2012 |
keiko | Update | LSC | RAM simulation for Full ifo |
Koji and Jamie suggested me to include the coupling between DoFs when I calculate the last matrix. So far, I just add all the pos-offsets of 5 DoFs and re-calculate the matrix again. However, once I add one DoF pos-offset, it could already change the LSC matrix therefore different pos-offset to the other four DoF, we must iterate this process until we get the equilibrium pos-offsets for 5 DoFs.
I also noticed an error in the optical configuration file. AM mod levels were smaller than that supposed to be because of the hald power going through the AM-EOMs in the MZI paths. Also I have put PM-Mods in the MZT path which gives the smaller mod indexes. So, smaller mod levels were applied both for PM and AM. As PM-AM ratio is still kept in this, so the matrices were not very wrong, I assume. I'll modify that and post the results again. |
6484
|
Wed Apr 4 13:25:29 2012 |
jamie | Configuration | PEM | PEM_SLOW (i.e. seismic RMS) channels aquiring |
Quote: |
I've added the PEM_SLOW.ini file to the fb master file, which should give us the slow seismic RMS channels when the framebuilder is restarted. Example channels:
[C1:PEM-RMS_ACC6_1_3]
[C1:PEM-RMS_GUR2Y_0p3_1]
[C1:PEM-RMS_STS1X_3_10]
etc.
|
The framebuilder seems to have been restarted, or restarted on it's own, so these channels are now being acquired.
Below is a minute trend of a smattering of the available RMS channels over the last five days.

|
6485
|
Wed Apr 4 21:43:16 2012 |
Mike J. | Update | Computers | Better Hysteresis Model |
A better hysteresis model based on the simple harmonic oscillator equation. Useless variables have been removed and output can now be saved to workspace for plotting. The model is at "/users/mjenson/matlab/SHO_hyst.mdl". |
Attachment 1: SHO_hyst.png
|
|
6486
|
Wed Apr 4 23:57:35 2012 |
keiko | Update | LSC | RAM simulation for Full ifo |
I'm still wondering whether iteration version or simple version is closer approximation to the real situation. Sorry for few explanations here. I will try to present those on Friday.
Anyway, here is the results for both:
%*.*.*. Original matrix w/o RAM .*.*.*
REFL f1 : 1.000000 0.000000 -0.000003 -0.000005 0.000007
AS f2 : 0.000002 1.000000 0.000009 -0.003522 -0.000002
POP f1 : -3954.521443 -0.000965 1.000000 0.019081 -0.000152
POP f2 : -32.770726 -0.154433 -0.072594 1.000000 0.024284
POP f2 : 922.393978 -0.006608 1.488319 0.042948 1.000000
*** Iteration ***
%*.*.*. Resulting matrix w/ RAM .*.*.*
REFL f1 : 0.039125 -0.000000 0.003665 0.000005 -0.000007
AS f2 : 0.000010 1.000431 0.000009 -0.003500 -0.000002
POP f1 : 156.420221 -0.000246 15.586838 0.019406 -0.000154
POP f2 : 1.255806 -0.154275 0.047313 1.000008 0.024285
POP f2 : -34.814720 -0.006600 -1.884850 0.042950 1.000000
Offsets converged to:
PRCL = 2.1e-15, MICH = 1.1e-17, SRCL = -3.8e-15, CARM = 2.2e-16, DARM = 0
(POP CARMs became so much smaller compared with the other matrix below, because the offsets are added al of 5 DoFsl at once here.)
*** no iteration, offsets added for each DoF separately ***
REFL f1 : 0.020611 -0.000000 0.003600 0.000005 -0.000007
AS f2 : 0.000002 1.000000 0.000009 -0.003522 -0.000002
POP f1 : 1842.776419 -0.000198 21.533358 0.019404 -0.000132
POP f2 : -32.700639 -0.153095 -0.072481 0.999995 0.024360
POP f2 : 922.393862 -0.006435 1.488298 0.042949 0.999982
Added offsets:
PRCL = 7.5e-15, MICH = 6.25e-16, SRCL = -1.4e-14, CARM = 4.5e-16, DARM = 0
* So far, I used to add all the offsets at once. This time I add CARM and get the CARM row, add PRCL and get the PRCL row... and so on.
I
Quote: |
Koji and Jamie suggested me to include the coupling between DoFs when I calculate the last matrix. So far, I just add all the pos-offsets of 5 DoFs and re-calculate the matrix again. However, once I add one DoF pos-offset, it could already change the LSC matrix therefore different pos-offset to the other four DoF, we must iterate this process until we get the equilibrium pos-offsets for 5 DoFs.
I also noticed an error in the optical configuration file. AM mod levels were smaller than that supposed to be because of the hald power going through the AM-EOMs in the MZI paths. Also I have put PM-Mods in the MZT path which gives the smaller mod indexes. So, smaller mod levels were applied both for PM and AM. As PM-AM ratio is still kept in this, so the matrices were not very wrong, I assume. I'll modify that and post the results again.
|
|
6487
|
Thu Apr 5 01:07:08 2012 |
Mike J. | Update | Computers | Hysteresis Plots |
Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)2*y-Hysteresis. The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

|
6488
|
Thu Apr 5 06:27:51 2012 |
kiwamu | Update | LSC | AS110 sideband monitor installed |
[Jenne / Kiwamu]
We have installed a broad band PD in the AS path in order to monitor the 110 MHz signal associated with the SRC.
The PD is currently connected to the POP110 demodulation board and it seems working fine.
I know this is confusing but right now the signal appears as "POP110" in the LSC front end model.
- Installed a 50% BS at the AS path
- The AS beam is split to two path - one goes to AS55 and the other goes to the OSA.
- The new BS is installed on the way of the OSA branch therefore AS55 isn't affected by the new BS.
- Installed a PDA10A
- This is a silicon diode with a bandwidth of 150 MHz, and is fast enough to detect the 110 MHz signals.
- The 110 MHz signal seems going up to approximately -40 dBm according to a coarse measurement with an RF spectrum analyzer.
- Also a SMA-style high pass filter, HPF-100, was attached to the output to cut off unnecessary sidebands (e.g. 11, 22 MHz and etc.)
- Put a long BNC cable, which goes from the PD to LSC rack.
- The end of the cable at the LSC rack was directly connected to the POP110 demod board.
- The actual POP110 signal path is currently terminated by a 50 Ohm load and therefore this signal is unavailable.
- Adjustment of the demodulation phase
- The demod phase was adjusted to be 7 deg in the EPICS screen. This phase minimize the Q-signal.
- Locking PRMI with sidebands resonating makes the AS110 signal ~ a few counts and this level is still noticeable.
- Perhaps we may need to put an RF amplifier to get the signal bigger.
|
6489
|
Thu Apr 5 07:19:16 2012 |
kiwamu | Update | LSC | DRMI locking |
I tried locking the DRMI to the signal-extraction condition with the new trigger by AS110.
A first thing I tried was : flipping the control sign of the SRCL while keeping the same control setups for the PRCL and MICH.
Occasionally the DRMI was "sort of" locked and hence I believe this setup must be a good starting point.
As a next step I will try some different gains and demodulation phase to make it more lockable.
(Time series)

The picture above is time series of some signals when the DRMI was barely locked.
The red arrows indicate the durations when the DRMI was sort of locked.
(Green curve) REFLDC becoming a high value state, which indicates that the carrier is anti-resonant.
(Red curve) ASDC becoming dark, which indicates the MICH is in the vicinity of the dark condition.
(Brown curve) AS110 becoming a high value state, which means the 55 MHz sidebands got amplified by the SRCL.
(Blue curve) POP22 becoming a high value state, which indicates that the 11 MHz sidebands are resonating in the PRC.
According to the measurement of AS110 when PRMI was locked ( #6488), the AS110 signal went up to ~ 1 counts or so.
On the other hand when the DRMI was locked the AS110 went to up more than 10 counts as shown in the plot above.
Therefore at least some kind of signal amplification is happening for the 55 MHz sidebands in the SRC.
Looking at the AS CCD, I found that the beam looked like a TEM01 mode (two beam spots at top and bottom) every time when the DRMI was locked.
(settings)
- REFL33I => PRCL G = -0.2
- AS55Q => MICH G = -6
- AS55I => SRCL G = 1 (G = -50 for the signal recycling condition)
- AS55 demod phase = 17 deg
|
6490
|
Thu Apr 5 18:24:55 2012 |
Den | Configuration | Adaptive Filtering | oaf starts to work |
Today I tried to make the lms filter to work online. I played around with the signals (GUR1_X and MC_F) to pre-whiten them and in the end the following configuration worked out:
1. mu = 0.03, tau = 1e-5, downsample=8, nCoeff = 4000, delay = 5 (sample-and-hold delay is not included in the new code, it should be added here!)
2. witness pass: AA32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0
3. witness adaptation path: AA32 AND AI32 = cheby1("LowPass", 4, 1, 32) AND 0.1:0
4. error path: AA32 AND 0.1:0 AND anti_1Hz. Before I added anti_1Hz filter oaf did nothing. This filter tries to approximate the actuator transfer function. Note, it is not in the witness adaptation path. This is some sort of whitening.
5. correction path: AI32, gain = -1
Convergence time ~ 5 mins. The performance of the filter is far not perfect compared to the offline implementation. But it deals with a stack though.

|
6491
|
Fri Apr 6 09:57:24 2012 |
Den | Update | Adaptive Filtering | static starts to work |
I made static filter to work to evaluate the actuator TF.. Here is the result of static filtering:

What I did:
I did offline simulation of the MC_F Wiener filtering using 2 witness signals - GUR1X and GUR1Y. I've downsampled the data from 2048 to 128 Hz and applied the Wiener filter with 10000 for each witness channel:
 
Result of the filtering Filter coefficients for gur1x and then gur1y
 
Gur1x -> MC_F transfer function Gur1y -> MC_F transfer function
Then using vectfit I approximated obtained transfer functions in the region 0.5 - 20 Hz. I used a window function and then weights to get a more precise result in this range using only 8 poles and zeros.
 
I obtained the zpk-model for each witness channel and entered it into the FOTON splitting it into 2 parts before that because FOTON does not like too long filters. These zpk-models are at the C1:OAF-STATIC_STATMTX_8_8 and C1:OAF-STATIC_STATMTX_8_9 filter banks.
GUR1X:
z =
7.527339430029315 +31.603999069997801i
7.527339430029230 -31.603999069997823i
27.897703898191267 + 0.000000000000071i
-6.437806394766186 + 9.893955654289517i
-6.437806394766159 - 9.893955654289510i
1.114401249545640 + 5.479278396987240i
0.176877296954015 + 0.000000000000006i
1.114401249545616 - 5.479278396987245i
p =
-0.407251778925379 + 6.263247012022007i
-0.407251778925379 - 6.263247012022007i
-0.230672968859081 + 6.846868757063707i
-0.230672968859081 - 6.846868757063707i
-2.871419857491615 +13.707864827517826i
-2.871419857491615 -13.707864827517826i
-2.134260618362721 +18.319129999777648i
-2.134260618362721 -18.319129999777648i
k =
4.113285626223658e-04
GUR1Y
z =
17.961416874092624 +13.631821252434328i
17.961416874092642 -13.631821252434353i
-8.788634771726304 + 7.653357335975781i
-8.788634771726285 - 7.653357335975777i
-0.037906973323273 + 5.133348020858679i
-0.164348392996182 + 3.588803405511463i
-0.164348392996187 - 3.588803405511474i
-0.037906973323277 - 5.133348020858679i
p =
-0.027577318242359 + 5.174655410828068i
-0.027577318242359 - 5.174655410828068i
-0.500384298611703 + 6.310552036591990i
-0.500384298611703 - 6.310552036591990i
-0.237055716999485 + 6.881204941979009i
-0.237055716999485 - 6.881204941979009i
-1.408223271160550 +14.874570175309771i
-1.408223271160550 -14.874570175309771i
k =
-2.723835471763049e-04
Then I approximated the reversed actuator TF and placed it to the C1:OAF-SUS_MC2_OUT filter bank. The gain to the static filter output is -1.
P.S. Also the static matrix was filled with 1 for some reason. Here is the script to fix it if if will be bad again
for i in {1..8}
do
for j in {1..28}
do
element="C1:OAF-STATIC_STATMTX_"$i"_"$j"_GAIN"
ezcawrite $element 0
done
done
|
6492
|
Fri Apr 6 10:31:07 2012 |
Den | Update | Adaptive Filtering | static and adaptive |
I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

|
6493
|
Fri Apr 6 11:14:34 2012 |
Jenne | Update | Adaptive Filtering | static and adaptive |
Quote: |
I've run static and adaptive filters simultaneously. AA32 filters rotate the phase of the witness signals GUR1X and GUR1Y and now the performance of the static filter is worse. Next time I'll recalculate Wiener filter coefficients taking this into account. But still 2 filters together can deal with a stack better.

|
This is super awesome! I'm totally excited!! |
6494
|
Fri Apr 6 11:32:09 2012 |
Jenne | Update | Computers | RAID array is rebuilding.... |
Suresh reported to Den, who reported to me (although no elogs were made.....) that something was funny with the FB. I went to look at it, and it's actually the RAID array rebuilding itself. I have called in our guru, Jamie, to have a look-see. |
6495
|
Fri Apr 6 14:39:21 2012 |
Jamie | Update | Computers | RAID array is rebuilding.... |
The RAID (JetStor SATA 416S) is indeed resyncing itself after a disk failure. There is a hot spare, so it's stable for the moment. But we need a replacement disk:
RAID disks: 1000.2GB Hitachi HDT721010SLA360
Do we have spares? If not we should probably buy some, if we can. We want to try to keep a stock of the same model number.
Other notes:
The RAID has a web interface, but it was for some reason not connected. I connected it to the martian network at 192.168.113.119.
Viewing the RAID event log on the web interface silences the alarm.
I retrieved the manual from Alex, and placed it in the COMPUTER MANUALS drawer in the filing cabinet. |